GENERIC kernel issues

[Warner Losh]

On Mar 5, 2013, at 8:58 PM, Ian Lepore wrote:

> On Mon, 2013-03-04 at 21:30 -0700, Warner Losh wrote: 
>> On Mar 4, 2013, at 6:09 PM, Ian Lepore wrote:
>>> On Sun, 2013-03-03 at 11:43 -0800, Tim Kientzle wrote:
>>>> 
>>>> ** PHYSADDR/KERNPHYSADDR hardwiring.  Ian has made a
>>>> lot of progress and I'm working on some related changes to
>>>> address this.  I think we understand how to eliminate these
>>>> constants and replace them with run-time detection of the
>>>> load address.  I'm still not sure what changes might be needed
>>>> to the loader to make this work. 
>>> 
>>> I don't think anything more needs to be done to the loader to be able to
>>> load a kernel built with the ldscript changes, beyond the change I did a
>>> week or two ago to make it work right with elf headers that contain
>>> physical addresses.
>>> 
>>> On the other hand, I haven't got anything to offer on the problem of the
>>> loader needing to be linked differently for each board or SoC, since
>>> they all have physical memory in differing address ranges.
>> 
>> Well, the Phyiscal memory load address is just a hint after all. Any way to leave it blank and have ubldr cope by putting it in the first available phyiscal memory slot from the FDT?
>> 
>> Warner
>> 
> 
> It's not just a hint, the executable is linked to run at that address
> and no other.  There is no relocation info in the file at all.  That's
> true of both the kernel and ubldr.  It's also true of any old
> static-linked executable, but in that case the object is just mapped at
> the virtual address it's linked for by the kern/imgact_elf.c code.

It is just a hint, since we can load it at any physical address.  Well, almost any. But we can get the almost from the virtual part.

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

> Unfortunately, I don't think we can pull the same kind of trick with
> ubldr.  In locore.s for the kernel we build simple page tables which are
> just enough to get us to the code in initarm() that builds them for
> real.  No SoC-specific stuff has to happen along the way (or if it does,
> SoC-specific code is invoked via various hooks to board support
> routines).  In ubldr we mess with the hardware (via the u-boot drivers),
> so if we turn on the MMU to map the memory ubldr is running from, we
> also have to map the hardware va=pa for those drivers to work.  I don't
> know that there's any way to get the needed info for that from u-boot.

So long as the code is PIC up until the time we turn on the MMU, then we're fine. We can and should still do this in locore.S.

I guess I'm being dense this morning.. I'm not sure I understand what the big deal is...

Warner