[U-Boot-Users] Dynamic U-Boot configuration via FDT

[Wolfgang Grandegger]

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%40grandegger.com&forum_name=u-boot-users

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.



-------------- next part --------------
A non-text attachment was scrubbed...
Name: u-boot-fdt-for-dynamic-config.patch
Type: text/x-patch
Size: 5787 bytes
Desc: not available
Url : http://lists.denx.de/pipermail/u-boot/attachments/20070921/c01210e1/attachment.bin