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