From owner-freebsd-arm@FreeBSD.ORG Wed Mar 6 21:58:00 2013 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id CDEE2A1F for ; Wed, 6 Mar 2013 21:58:00 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by mx1.freebsd.org (Postfix) with ESMTP id 821CFAD5 for ; Wed, 6 Mar 2013 21:58:00 +0000 (UTC) Received: by mail-ob0-f174.google.com with SMTP id 16so3915194obc.19 for ; Wed, 06 Mar 2013 13:58:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to:x-mailer:x-gm-message-state; bh=gEO4QFfVL/ahUqNJp9PJ7PIX+ZWHdj1yzISEjYrl6pw=; b=IqbHNAH+w+rIdeEAOwJxIIVxUDOgRgGL+PLKf4WRHRG5N0K2oH/iCuwnC/MSbPlD2j 33yTQT5GVFYsIOYHhpzwfUUUQrIZ0H2UvRRzUKH1fJ6ltglOiPzVq1p5pyKI2RXTx7FU rKgwVg8prunyR3V6/fzWJ+3a3cCnsvAEZcK1aEn7/AQLRY22rJN6BP73/KyCLnW5p126 Jblmg3dPFGLuPOgAftVIFJ4J9sQgLammCEmpSU7VFTwoCLDQQ4tOiMWuCCKyLwqP+3St H3WgrMPNk1L9+N2B5QLYIk0Xq+hHIm6hl3YnuY1+SlWYtAaDBkz7TYtAkC2ZDEShZQig Mqzg== X-Received: by 10.60.32.113 with SMTP id h17mr24006326oei.54.1362607080152; Wed, 06 Mar 2013 13:58:00 -0800 (PST) Received: from monkey-bot.int.fusionio.com ([209.117.142.2]) by mx.google.com with ESMTPS id t9sm39325331obk.13.2013.03.06.13.57.58 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Mar 2013 13:57:59 -0800 (PST) Sender: Warner Losh Subject: Re: GENERIC kernel issues Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130306234004.bf113967.ray@freebsd.org> Date: Wed, 6 Mar 2013 14:57:56 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: <4C0099FA-BBBE-4F93-8C97-CE5B79465829@bsdimp.com> References: <1362445777.1195.299.camel@revolution.hippie.lan> <3DFABC9A-876A-4F34-9E15-E4C630D7B077@bsdimp.com> <1362542286.1291.94.camel@revolution.hippie.lan> <4CF23AFE-DD69-40AA-ACFB-46F055F0AA3F@bsdimp.com> <1362594744.1291.132.camel@revolution.hippie.lan> <20130306234004.bf113967.ray@freebsd.org> To: Aleksandr Rybalko X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkcargwfFQuMh0imeffpj6xXbRECFP1YBq/bLBzJZaLujwi8S8osqCiYbuOqYi4UPOlz/Do Cc: freebsd-arm@FreeBSD.org, Ian Lepore X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting FreeBSD to the StrongARM Processor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2013 21:58:00 -0000 On Mar 6, 2013, at 2:40 PM, Aleksandr Rybalko wrote: > On Wed, 6 Mar 2013 12:33:11 -0700 > Warner Losh wrote: >=20 >>=20 >> On Mar 6, 2013, at 11:32 AM, Ian Lepore wrote: >>=20 >>> On Wed, 2013-03-06 at 10:03 -0700, Warner Losh wrote: >>>> On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote: >>> [...] >>>>> We essentially pull off the same mapping trick with the kernel, >>>>> except that very early in locore.s the code is carefully crafted >>>>> to work right whether on physical or virtual addressing, just >>>>> long enough to get the MMU turned off. Then it sets up page >>>>> tables to map the physical pages the kernel has been loaded into >>>>> to match the virtual addresses it was linked for. All of that >>>>> only works if the low-order bits of the virtual address it was >>>>> linked for match the physical address it was loaded at. That is, >>>>> if linked for 0xC0001000 it must be loaded at 0xNNNN1000 >>>>> physical, where the N bits can be anything. >>>>=20 >>>> Right, but can't we get that from the virtual address. >>>=20 >>> Not always. You can always figure out the right virtual address if >>> you have the physical (you just OR-in 0xC0000000), but you can't >>> always go the other way. If all you know is 0xC0010000 you have no >>> idea whether the underlying physical address might be 0x00010000 or >>> 0x80010000. Our current code that assumes you can do >>> phys=3Dpc&0xf0000000 is wrong for the same reason (but has been >>> working okay by accident). >>=20 >> The phys segment is pc & 0xf0000000 before you turn on the MMU >> (assuming 256MB chip select offsets, adding another F would get that >> down to 16MB chip selects, which is definitely good enough). After we >> MMU start, it isn't, and our code shouldn't do that, unless it is >> followed by oring in the physical segment... >>=20 >>> That's part of why I've been working towards getting our arm >>> ldscript to put proper physical addresses in the elf headers >>> instead of virtual, in the fields that are supposed to have >>> phsyical addresses in them (entry and program-header paddr fields). >>=20 >> But that doesn't matter for the kernel so much... >>=20 >>> With this scheme SoC-specific kernels will be linked with PHYSADDR=3D >>> the real physical address and can be loaded by any standard elf >>> loader because the headers are correct. A generic kernel will be >>> linked with PHYSADDR=3Doffset where offset is just the low-order = part >>> of the address and ubldr can load the kernel into whatever physical >>> memory is available as long as the offset part stays the same. >>=20 >> OK. That part makes perfect sense now. >>=20 >> Warner >> _______________________________________________ >> freebsd-arm@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-arm >> To unsubscribe, send any mail to = "freebsd-arm-unsubscribe@freebsd.org" >=20 > Maybe we should just let ubldr to enable MMU for us? Like we do for > i386, IIRC. One weak reason is that uboot and other loaders that are used to loading = Linux are forbidden from having the MMU enabled when they transfer = control to the kernel they boot. We'd want to still work there, and = would need extra/different code to cope with the booted with the MMU = enabled and booted without the MMU enabled. Warner