PHYSADDR

Tim Kientzle tim at kientzle.com
Thu Feb 28 17:44:53 UTC 2013


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.
> 
>> On the other hand, I've been working
>> towards getting that value set correctly in the kernel elf headers at
>> link time.

A-ha!  I think I just figured something out.

How would the following work:

 * Rename PHYSADDR to KERNPHYSADDR_BASE

 * in the top of locore.s, we have a single conditional:

#ifdef KERNPHYSADDR_BASE
    _kpa_base = KERNPHYSADDR_BASE;
#else
    _kpa_base = pc & 0xF0000000;
#endif

I think this would DTRT on all of the configurations
we currently have in SVN.

  * 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.

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.

Does this sound reasonable as a starting point?

It doesn't solve the trampoline problem, but I'm willing to
defer that.

Tim



More information about the freebsd-arm mailing list