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

[Tim Kientzle]

On May 15, 2012, at 9:38 AM, Rafal Jaworowski wrote:
>> 
>> 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.
> 
> 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.

I've fixed the code in sys/boot/fdt/ to do all access through copyout/copyin.
I'm waiting for a "make universe" to make sure I didn't break something
inadvertently, and will probably commit it tomorrow.

Right now, this just copies the DTB to a malloc-ed area, modifies
the copy and then writes it back to the same place (either in the kernel
or in a separately-loaded blob).  It seems to work correctly even when
copyout/copyin are doing address translations.

> ... if you'd like to modify the blob in a major way you need to relocate it into a new location with more padding …. create a DTB metadatum (as if the DTB was loaded dynamically from standalone blob file) with sufficient space, …. 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.

Yes, I see how that would work.

Is there a real use for this?  I could take a look at it once I'm
finished with the current ubldr work I'm doing.

Tim