GENERIC kernel issues

[Warner Losh]

On Mar 6, 2013, at 11:32 AM, Ian Lepore wrote:

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

The phys segment is pc & 0xf0000000 before you turn on the MMU (assuming 256MB chip select offsets, adding another F would get that down to 16MB chip selects, which is definitely good enough). After we MMU start, it isn't, and our code shouldn't do that, unless it is followed by oring in the physical segment...

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

But that doesn't matter for the kernel so much...

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

OK. That part makes perfect sense now.

Warner