[U-Boot-Users] Ideas on U-Boot configuration with FDT
Jerry Van Baren
gerald.vanbaren at smiths-aerospace.com
Fri May 18 17:29:39 CEST 2007
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
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
> 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).
More information about the U-Boot