Zach Sadecki wrote:
Jerry Van Baren wrote:
Zach Sadecki wrote:
I have some confusion about FDT and what the intentions are for its support and usage in u-boot.
[snip]
What is the intent for future support? Creation of a device tree from scratch? That seems to be what the original (open firmware) intention of FDTs were. (Allowing a bootloader to pass a implementation specific hardware list up to an operating system.) And the current Linux implementation is a little backwards from that (let kernel compiler give you a device tree which you then have to give to the bootloader to pass back up to the kernel during boot). It would seem to make more sense (in my limited understanding of FDT) to allow the bootloader to be able to generate this itself without dependence on a prior kernel compilation for that particular hardware...
There is no intention to create blobs from scratch in the boot loader (u-boot). If you look at some of the SOC (8[3456]xx) blobs, you would see that that would be a nightmare, your fingers would be bloody stubs by the time you typed it all in, and then you would find you had a syntax error and have to start all over. http://pez.multiply.com/journal/item/75/Computer_Frustration (I think that is the link, the filters at work don't let me browse it.)
What I meant was not typing it in by hand, but setting it up in your board.h file so that it can be generated during compile or during boot. But if you can embed it into the u-boot image itself, maybe this is unnecessary. It seems as I look deeper into the code it does support this to some extent (ft_build.c), but I think that it might not be as thorough as it would need to be to work.
Hmmm /me thinks you are confusing libfdt and The Other Way of supporting FDT blobs with the reference to ft_build.c. While it is theoretically true that you could generate the blob from nothing, modifying and augmenting a static initial blob makes more sense.
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.
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.
On the other hand, 98% of the typical FDT blob (to make up a statistic) is static. The intent of u-boot FDT support is to externally (via the dtc) generate a blob with the 98% already filled in and have u-boot configure the 2% that is board-specific or user selected.
The blob can be baked into u-boot, stored in flash separately from u-boot, or loaded as part of the kernel (baked into the kernel image in ROM, tftped separately from the kernel, tftped as part of the kernel image).
We are in the tool business, how to use the tool is up to the user. ;-)
If the plans aren't for u-boot to have the ability to generate a device tree would it be reasonable to create one and embed it in the u-boot binary somehow? (so that another unique binary wouldn't have to be loaded into another separate flash partition)
Thanks, Zach
That option is already there as a multi-image boot image, one part of the image being a FDT blob.
I've seen a little info on using mkimage to add an initrd, but nothing specifically with fdt (or dtb). I've seen no info on 'baking it into u-boot' that you mentioned above... Is there any documentation on how to do either of these?
Thanks, Zach
I haven't tried to make a multi-image linux/FDT blob/RAM disk an may have misspoke about it being an option. What I was recalling is something Timur did which was using mkimage to wrap a standalone blob. http://thread.gmane.org/gmane.comp.boot-loaders.u-boot/28207/focus=28242
Baking in - explained above, use dtc to generate assembly and link it in with u-boot. It may make sense in places, but I would think hard about if it made sense before doing it.
gvb