[U-Boot-Users] Ideas on U-Boot configuration with FDT
Wolfgang Grandegger
wg at grandegger.com
Fri May 18 11:09:30 CEST 2007
Hello,
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;
else
struct fdt_header *fdt = NULL;
#endif
- 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
necessary.
- 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
kernel.
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.
Wolfgang.
More information about the U-Boot
mailing list