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

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. :-)
> 
> -Scott

Yeah, I had a ruder term than "fixate" but changed it for public 
consumption.  ;-)

Best regards,
gvb



More information about the Linuxppc-dev mailing list