[U-Boot-Users] Ideas on U-Boot configuration with FDT

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

Timur Tabi wrote:
> Wolfgang Grandegger wrote:
> 
>> - In the early boot phase, before relocation, the FDT is checked and an
>>   error message printed in case it's not found or invalid: 
>>
>>      CPU:  MPC5200 v1.0, Core v1.1 at 396 MHz
>>            Bus 132 MHz, IPB 66 MHz, PCI 33 MHz
>>      FDT:  FDT_ERR_BADMAGIC (or OK, or version number?)
>>
>>     At this level also the compatibility of the FDT tree could be checked
>>     using fdt_boardcheck().
> 
> I think fdt_checkboard() (or boardcheck) should be run from inside the 
> fdt_open_into() command.  This takes advantage of the existing mechanism 
> of fdt_open_into() to return an error.  It also allows for a device tree 
> to be opened after U-Boot has booted.

NO.  fdt_open_into() is part of libfdt, which is a _generic_ fdt 
library.  fdt_check_board() would be board specific and any call-out to 
it from the generic libfdt would be a mistake because it would make 
libfdt u-boot specific.

If we implement a fdt_checkboard(), I agree with Wolfgang that it would 
be called early in the board-specific start up code.

If we implement a fdt_checkboard(), I would create a new subcommand for 
it.  While it could be added to the "fdt addr" command to verify the 
user pointed to a valid fdt, I would strongly resist that.  "UNIX was 
not designed to stop its users from doing stupid things, as that would 
also stop them from doing clever things." ? Doug Gwyn
   <http://en.wikipedia.org/wiki/Unix_philosophy#Quotes>

The above quote is another reason for my shouting "NO" above.

>> - After relocation, the blob is copied into memory via fdt_open_into()
>>    to a defined place and "fdt" is updated accordingly. 
> 
> So we'll need to have CFG_FDT_ADDR_FLASH and CFG_FDT_ADDR_RAM.
> 
>> Not sure, what
>>    location in RAM to use, but it should fit into the existing scheme.
>>    Any recommendations?
>>
>> - When U-Boot is up, "fdt" points to a valid FDT, e.g. "fdt addr" is not
>>    necessary.
> 
> I think this feature needs to be optional.  That is, if CFG_FDT_ADDR_xxx 
> are defined, then we can enable this feature.  Otherwise, fdt_addr will 
> still be necessary.  Remember, we'll still need to support architectures 
> that don't have device trees.

"fdt addr" (no underscore) is the subcommand that allows the user to 
change the fdt address (implementation: it sets the C variable "fdt"). 
I would be reluctant to remove the "addr" subcommand because the 
user/scripts may want to change which fdt is used.  Given Wolfgang's 
thoughts/proposals above, it will not be used very often, but it would 
still be useful for developers.

"fdt addr" would also be more useful if "fdt addr" printed out the 
current value of the variable "fdt" (I don't believe it is implemented 
this way currently).

Best regards,
gvb