[U-Boot-Users] FDT intentions in u-boot

[Jerry Van Baren <vanbargw@gmail.com>]

Haavard Skinnemoen wrote:
> On Thu, 18 Oct 2007 15:29:28 -0400
> Jerry Van Baren <gerald.vanbaren@ge.com> wrote:
> 
>> I would not advocate embedding the FDT blob in u-boot but, if I were
>> to do so, I would use the dtc to generate an assembly language output 
>> (actually, a lot of define byte statements) and then compile that in
>> the u-boot build.
> 
> Why not just generate a binary file (possibly compressed) and suck it
> into an assembly file using .incbin?

Yet Another Way to do the same thing.  Dtc produces a binary blob or 
human readable assembly, might as well output assembly and skip the 
.incbin, but to each their own.

Compressing probably isn't profitable, a blob is a few K uncompressed. 
On the other hand, u-boot knows how to uncompress, so anything is 
possible...

>> A better approach IMHO (subject to change) is to burn the FDT blob
>> into a separate flash area so it can be updated later without
>> rebuilding u-boot or downloading it via TFTP.  Obviously, this would
>> be an engineering tradeoff and /your/ best choice for your situation
>> is quite likely different from someone else's choice for their
>> (different) situation.
> 
> Yes, having a mutable device tree probably makes more sense for a
> development board. But embedding it in the u-boot binary could save
> some space in the "production" image. Is it possible to support both?

Yes.  Ultimately u-boot (mboot/linux) takes the address of the blob. 
You can store it anywhere you want, as long as it has an address.  If it 
doesn't have an address (e.g. i2c eeprom, NAND flash), you simply need 
to copy it somewhere addressable (RAM) first.  U-boot knows how to cp 
too.  :-)

> I don't know all that much about FDT, so I could be way off. I would
> like to try it out with avr32 at some point though, after all the
> basics are in place.
> 
> H?vard

You have the concepts OK.  FDT is pretty cool stuff, much better than 
shared "bd" structures.

gvb