How does loader(8) decide where to load the kernel?

[Rafal Jaworowski]

On 2012-05-13, at 09:17, Tim Kientzle wrote:

> On May 12, 2012, at 4:36 PM, Tim Kientzle wrote:
>> 
>> On May 10, 2012, at 5:32 AM, Marcel Moolenaar wrote:
>> 
>>> On May 8, 2012, at 1:32 AM, Tim Kientzle wrote:
>>>> 
>>>> On the AM3358, the DRAM starts at 0x8000 0000
>>>> on boot, so I'm trying to find a clean way to convince
>>>> the loader's ELF code to put the kernel there.
>>> 
>>> Look at what I did for ia64. All that frobbing should be done
>>> in the machine specific implementation of arch_copyin, arch_copyout
>>> and arch_readin. It's a kluge to do it in elf_loadimage.
>> 
>> That sounds like a reasonable approach.  I've started
>> working down that path…  but it looks like I'll have to fix
>> a lot of the FDT code along the way.
> 
> I'm getting close.  In particular, I've reworked the FDT code
> so that it correctly uses copyout() to parse data in the
> kernel.  Of course, in order to use libfdt to actually
> manipulate the device tree, I have to copyout() the
> entire blob into a malloc'ed buffer.
> 
> So now I need to understand how to copyin() the
> blob back into the kernel address space.
> 
> Should I overwrite the FDT in the kernel with the
> edited FDT?  That doesn't feel quite right, but it's
> essentially what the FDT code here was trying to
> do before.
> 
> I could also implement something similar to file_loadraw()
> that would allow me to create a new module from an
> in-memory buffer.  I think that might be a little cleaner.
> 
> Is there already something like this?


A given DTB (loaded dynamically or statically embedded in the kernel) has some small amount of free space inside it so it is possible to perform in-place modifications, adding properties / nodes until you run our of this space (libfdt code will handle cases when exceeding this and would fail gracefully). The fixup mechanism currently implemented does minor modifications of the device tree in this fashion.

My understanding is that if you'd like to modify the blob in a major way you need to relocate it into a new location with more padding (there's facility for relocation in libfdt already) and then modify it accordingly. This won't be possible however with the statically embedded DTB in the kernel as you cannot grow this space easily. The way to go here would be to create a DTB metadatum (as if the DTB was loaded dynamically from standalone blob file) with sufficient space, relocate the statically embedded original content into this metadatum, do modifications there and pass this new copy (as part of regular loader(8) metadata) to the kernel for processing. The building blocks are there (DTB loaded as metadata) and should work.

Rafal