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