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

Wolfgang Grandegger wg at grandegger.com
Fri May 18 11:09:30 CEST 2007


here are my ideas on what is basically necessary to use FDT for U-Boot 
configuration. I tried to keep it simple:

- If CFG_FDT_ADDR is defined in the boards configuration file, the
   global variable "fdt", already used by the FDT command, will be set
   at compile time to that address:

     #ifdef CFG_FDT_ADDR
             struct fdt_header *fdt = CFG_FDT_ADDR;
             struct fdt_header *fdt = NULL;

- 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().

- After relocation, the blob is copied into memory via fdt_open_into()
   to a defined place and "fdt" is updated accordingly. 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 the basic mechanism should also work _without_ FDT commands
   (cmd_fdt.c, getting ride of quit some code).

- bootm should then automatically use the address of "fdt" to boot the

Some more comments. I realized rather heavy consistency checks on almost 
any public FDT function via fdt_check_header. I actually would prefer to 
have one extended check function at the beginning, which also ensures 
the compatibility with the board and reduce the other checks to just 
verify the magic number.

Other related issues? Do we also need to maintain a checksum of the 
blob? At least it's on Jerry's to-do list.

What do you think? I'm going to show a first patch soon.


More information about the U-Boot mailing list