Date: Sat, 2 Mar 2013 22:53:21 +0100 From: Daan Vreeken <Daan@vitsch.nl> To: Ian Lepore <ian@freebsd.org> Cc: Tim Kientzle <tim@kientzle.com>, freebsd-arm@freebsd.org Subject: Re: PHYSADDR Message-ID: <201303022253.21210.Daan@vitsch.nl> In-Reply-To: <1362155632.1195.120.camel@revolution.hippie.lan> References: <e886046b-1612-425b-902b-72d4b0e93618@freebsd.org> <1362155645-2157952719.da2bf251f6@bliksem.vehosting.nl> <1362155632.1195.120.camel@revolution.hippie.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi all, On Friday 01 March 2013 17:33:52 Ian Lepore wrote: > On Thu, 2013-02-28 at 09:44 -0800, Tim Kientzle wrote: > > On Feb 28, 2013, at 8:58 AM, Tim Kientzle wrote: > > > On Feb 28, 2013, at 8:20 AM, Ian Lepore wrote: > > >> 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 ;-) > > >>> > > >>> First up: Can we get rid of PHYSADDR? > > >> > > >> 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. > > > > > > It doesn't seem to be used in the runtime kernel. As far as > > > I can see, it's purely a bootstrap concept. > > 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. I like this approach. We have a board on which the bootloader loads a small= =20 binary blob that's in front of the kernel together with the kernel, all in= =20 one go. This results in the kernel living at an offset of a number of pages= =20 from the start of RAM. This means that this : > > _kpa_base =3D pc & 0xF0000000; wouldn't work. Calculating the exact location of the start of the kernel im= age=20 would work on all boards and memory/loader configurations. Regards, =2D-=20 Daan Vreeken Vitsch Electronics http://Vitsch.nl/ http://VitschVPN.nl/ tel: +31-(0)40-7113051 KvK nr: 17174380 =2D- Machines en netwerken op afstand beheren? Vitsch VPN oplossing! Kijk voor meer informatie op: http://www.VitschVPN.nl/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201303022253.21210.Daan>