Hello,
it want to report on my experience with using FDT to configure U-Boot dynamically for a custom board based on the MPC823. The customer wanted _one_ U-Boot and Linux image for various variants of that board mainly to simplify software maintenance. The following devices required configuration via FDT blob:
- LCD panel (type, orientation, color, etc.) - RTC - PCMCIA/IDE - DTT - CAN controller - Some custom devices
For most devices it was sufficient to check their presence. Only the LCD panel and the CAN controller required a more sophisticated FDT-based initialization. The FDT was used in a minimalistic and way. This project still uses the good old Linux 2.4.25 from DENX and therefore it's not a good food for discussion. I have attached a patch implementing the essential parts to configure IDE of my Icecube MPC5200 eval board:
- The macro definition CFG_FDT_ADDR points to the FDT blob in the Flash. Note that it can also be used before relocation.
- After relocation and availability of the U-Boot environment, the function fdt_relocate() copies the blob to a bootable address in RAM defined by the environment variable "fdt_boot_addr". bootm is aware of that address and will use it to boot Linux 2.6 (without third bootm argument). Moving to RAM that early has the advantage of faster access to the FDT and it could be updated by board specific code.
- fdt_relocate() calls the board specific function fdt_fixup_board() if the corresponding macro is defined. It might make sense to use the already existing ft_board_setup() for that purpose.
- The function cmd_disable() is used to disable U-boot commands for unavailable devices. Note that it cannot be used before relocation.
- A lot of dynamic configuration using fdt_find_compatible_node() or fdt_find_node_by_type() could be done in board specific code. Common code like U-Boot commands or device drivers must use the FDT directly. Unfortunately, it requires adding FDT code in many places. For the next generation of U-Boot, FDT probing should therefore be done by a clever device interface. The patch demonstrates how to configure IDE by looking for the "ata" node in the FDT.
Limitation, improvements, ideas and further comments:
- The LIBFDT can only be used for addresses accessible via pointer. Therefore it cannot be used as-is before relocation and for this reason I have just defined and implemented CFG_FDT_ADDR (FDT in EEPROM or NAND is not supported).
- Many drivers do not yet support multiple configurations like DTT, RTC, LCD, etc.
- A suitable default address for FDT blob relocation could be used instead of an address defined by the U-Boot environment variable "fdt_boot_addr", (or both).
- fdt_relocate() could also heck for a FDT U-Boot image at the address (CFG_FDT_ADDR - 64) and act accordingly.
- The U-Boot command "fdt" works right away.
- We might want to support multiple FDT blobs, which could be selected through an U-Boot environment variable. But such blobs could not be used in the early boot phase.
In May there was already some basic discussion on this topic: See http://sourceforge.net/mailarchive/forum.php?thread_name=464D6D4A.4000200%40...
The central question is to what extend we want to use the FDT to configure U-Boot. I already regard the extensive use of the FDT in Linux 2.6 as kind of overkill.
Please comment.
Thanks.
Wolfgang.