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

[Zach Sadecki <zach.sadecki@ripcode.com>]

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.
>>
>> From what I understand so far, u-boot only supports modifying a FDT
>> already loaded into memory.  Isn't this kind of an odd usage of a device
>> tree?  I thought a unique tree should be created for each hardware
>> implementation (a.k.a. system board) and therefore you shouldn't be
>> modifying it.  If changes are made a new device tree should be created.
> 
> You can only _modify_ a blob when it is in RAM.  You can store a blob in 
> ROM (flash) and copy it to RAM for modification.
> 
> If you don't need to modify the blob in order to boot linux, there is no 
> need (that I'm aware of) for loading/copying it to RAM.  *However* it is 
> unlikely that you (u-boot/linux) will be able to use an unmodified blob. 
>  For instance, the "chosen" node is (or should be?) generated by the 
> boot loader (u-boot) to let the kernel know about certain choices that 
> were made by the boot loader and/or the user.
> 
> The intent is to set properties (values) that can change from boot to 
> boot or from board to board.  The classic example are clocks.  Boards, 
> when they boot, can typically figure out and often can set clock rates. 
>  Having a thousand FDTs with all the combinations of possible clocks is 
> a maintenance nightmare.  Having u-boot set the clocks or probe for the 
> clock rates is great.
OK, I see your point here.  That makes sense...

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