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

[Jerry Van Baren <gerald.vanbaren@ge.com>]

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