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

[Tim Kientzle]

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?

Tim