Re: [PATCH 3/4] Use embedded libfdt in the bootwrapper

[Scott Wood <scottwood@freescale.com>]

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.

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

> In the u-boot world, we fixate on memory maps and putting things in 
> specific places.

I've noticed. :-)

-Scott