PHYSADDR

Daan Vreeken Daan at vitsch.nl
Sat Mar 2 21:53:25 UTC 2013


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… ;-)
> > >>>
> > >>> 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 
binary blob that's in front of the kernel together with the kernel, all in 
one go. This results in the kernel living at an offset of a number of pages 
from the start of RAM.

This means that this :

> >     _kpa_base = pc & 0xF0000000;

wouldn't work. Calculating the exact location of the start of the kernel image 
would work on all boards and memory/loader configurations.


Regards,
-- 
Daan Vreeken
Vitsch Electronics
http://Vitsch.nl/
http://VitschVPN.nl/
tel: +31-(0)40-7113051
KvK nr: 17174380
--
Machines en netwerken op afstand beheren? Vitsch VPN oplossing!
Kijk voor meer informatie op: http://www.VitschVPN.nl/


More information about the freebsd-arm mailing list