[PATCH 3/4] Use embedded libfdt in the bootwrapper
Jerry Van Baren
gvb.linuxppc.dev at gmail.com
Sat Nov 10 12:14:59 EST 2007
Scott Wood wrote:
> Jerry Van Baren wrote:
>> My concern from the u-boot side is that u-boot has to know exactly
>> *where* to put the expanded blob because it has to pass it to linux
>> and keep it out of linux' way so it doesn't get "stepped on." Linux
>> has an advantage in that it "owns" all of memory and can allocate and
>> deallocate whatever and wherever and it won't step on itself (hopefully).
> Linux is pretty careful not to step on the device tree; it marks the
> area as reserved, and moves it if it really has to. The only scenario I
> think would be problematic is if the kernel is started somewhere other
> than zero, and has to relocate itself, and the relocation clobbers the
> device tree. That's easily avoided by making sure the device tree is at
> a higher address than the kernel -- and is really not much different
> than the old bd_t mechanism, which didn't use a user provided address
That is good to know, makes things much easier.
>> I'm assuming your boot wedge has the advantage of being able to use
>> linux's malloc() and thus don't have to worry about coordinating with
>> linux on memory allocation.
> No, it uses its own malloc.
>> With the current u-boot fdt command, you can resize the blob, and this
>> can be done in a script with all the (somewhat limited) capabilities
>> of the u-boot shell (an adaptation of hush).
> OK, I'm just going by the behavior of the default boot commands on (at
> least some of) our boards, which just give you an error if the blob
> isn't already enlarged.
> Maybe I should just poke Kim et al. about fixing our default environment
> -- though I'm guessing it'd still have to know from the script how much
> to enlarge the blob.
Currently it is a manual thing, my point was that it is potentially
scriptable (but would probably take a genius or 3 days of
experimentation to make the script work ;-). If we can settle on a safe
way to expand the blob automatically, I'm all for that.
>> In the u-boot world, we fixate on memory maps and putting things in
>> specific places.
> I've noticed. :-)
Yeah, I had a ruder term than "fixate" but changed it for public
More information about the Linuxppc-dev