Date: Fri, 01 Mar 2013 09:33:52 -0700 From: Ian Lepore <ian@FreeBSD.org> To: Tim Kientzle <tim@kientzle.com> Cc: freebsd-arm@FreeBSD.org Subject: Re: PHYSADDR Message-ID: <1362155632.1195.120.camel@revolution.hippie.lan> In-Reply-To: <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com> References: <E886046B-1612-425B-902B-72D4B0E93618@freebsd.org> <1362068453.1195.40.camel@revolution.hippie.lan> <674A08B3-6600-4B77-8511-9EF54E4B9B1F@FreeBSD.org> <8FEA3237-8ABF-4564-B672-4B4C0C6EF291@kientzle.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 2013-02-28 at 09:44 -0800, Tim Kientzle wrote: > On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: >=20 > >=20 > > On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > >=20 > >> On Wed, 2013-02-27 at 22:27 -0800, Tim Kientzle wrote: > >>> Starting to look at what is needed for a Generic ARM kernel. > >>> There's a lot here; I sincerely hope I'm not the only one=85 ;-) > >>>=20 > >>> First up: Can we get rid of PHYSADDR? > >>>=20 > >>=20 > >> If you mean, can we get rid of it within the runtime kernel, I'd say > >> yes, because we can use a global variable instead which is easily > >> settable in the entry code. > >=20 > > It doesn't seem to be used in the runtime kernel. As far as > > I can see, it's purely a bootstrap concept. > >=20 Well, it's used to set up the early-init page tables in locore.s then again to set up the real page tables and related things in initarm() and then I think it isn't used after that, so I should have said "within the kernel init". The main point I was getting at is that I don't think we need a compile-time constant of any sort related to the physical address at which the kernel is loaded. We can get the physical address of the entry point (_start) using pc-relative math, and we can get the linker to give us a constant symbol which is the offset of the _start symbol within the load image. So we can get the load address at runtime without guessing what low-order bits to mask. > >> On the other hand, I've been working > >> towards getting that value set correctly in the kernel elf headers a= t > >> link time. >=20 > A-ha! I think I just figured something out. >=20 > How would the following work: >=20 > * Rename PHYSADDR to KERNPHYSADDR_BASE >=20 > * in the top of locore.s, we have a single conditional: >=20 > #ifdef KERNPHYSADDR_BASE > _kpa_base =3D KERNPHYSADDR_BASE; > #else > _kpa_base =3D pc & 0xF0000000; > #endif >=20 > I think this would DTRT on all of the configurations > we currently have in SVN. Hmm, so the basic assumption is that every SoC will have some physical memory aligned to a 256mb boundary. E.G., there'll never be a SoC with memory at 0xN1000000 that doesn't have memory at 0xN0000000. I'm not sure that's a safe assumption given things like the rpi where the gpu carves off some memory for itself and gives the rest to the arm. It works with the way rpi carves up the ram, but I could see similar designs that wouldn't work. >=20 > * We redefine KERNPHYSADDR to be an *offset* > against _kpa_base. Then we could negotiate a single > offset (64k?) that works well on many platforms and use > that for the GENERIC kernel. Boot loaders would be > responsible for loading the kernel at an address that > preserves the KPA_OFFSET. The KPA_OFFSET would > be used in the ELF headers. >=20 > Then there are routine code transformations to use _kpa_base > instead of the compile-time symbol and to use > _kpa_base + KERNPHYSADDR instead of KERNPHYSADDR. >=20 > Does this sound reasonable as a starting point? >=20 There are even more assumptions here about what would work in every case. Given the basic sequence of boot2->u-boot->ubldr->kernel, every one of those components has to load the next component at the physical address it's linked for, and that has to not overlap the addresses being used by the thing doing the loading. The MMU is off during all of this so we can't just map our way out of any conflicts. Whatever arbitrary address we pick for the kernel is sure to conflict eventually with the memory occupied by u-boot on some random system. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1362155632.1195.120.camel>