GENERIC kernel issues

[Ian Lepore]

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.
> 
> Right, but can't we get that from the virtual address.

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=pc&0xf0000000 is wrong for the
same reason (but has been working okay by accident).

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

With this scheme SoC-specific kernels will be linked with PHYSADDR= 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=offset 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.

-- Ian