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

Timur Tabi timur at freescale.com
Mon May 21 17:19:13 CEST 2007


Wolfgang Grandegger wrote:

> Then something similar to the ENV could be chosen:
> 
>   CFG_FDT_ADDR
>   CFG_FDT_IS_IN_FLASH
>   CFG_FDT_IS_IN_xxx

We need two addresses:

1) The address where the FDT is stored when the system is powered up
2) The address in RAM where the FDT should be placed before Linux is booted.

Therefore, we can't have just CFG_FDT_ADDR.  We need CFG_FDT_ADDR_xxxx

My vote is to have xxxx be the type of memory.  So if CFG_FDT_ADDR_FLASH is defined to 
value X, that means that the FDT is stored in flash at address X.  If CFG_FDT_ADDR_EEPROM 
is defined instead, then it means that FDT is located in EEPROM at address X.

This would eliminate the "CFG_FDT_IS_IN_xxx"-type macros, which I think are redundant.

>>> CFG_FDT_ADDR_BY_ENV:
>>>     If defined, the env variable "fdtaddr" is looked up early in the
>>>          boot and "fdt" is set accordingly. This allows to hold more 
>>> than

I would rather that the FDT subsystem *set* the fdtaddr variable, instead of the other way 
around.

>>> CFG_FDT_ADDR_RAM:
>>>     If defined, the blob is moved to RAM after relocation for
>>>          further preparation or for performance reasons. "fdt" is re-set
>>>          accordingly. The blob is then ready and in place for booting
>>>          Linux. If CFG_FDT_ADDR_RAM is set to 0, the blob will be copied
>>>     to a default location, e.g. before the initrd location.

I think we're going to have to always relocate the FDT to RAM.  Considering the level of 
functionality that libfdt provides, and considering how much of that functionality depends 
on being able to write to the FDT, it makes sense to require it to be in RAM.

>> "checkboard()" is a name that can mean anything. If the  function  is

The purpose of the function is to provide board-specific code that validates the FDT.  The 
amount of checking performed is at the discretion of the function.

For example, checkboard() *should* compare the values in the board header file with the 
FDT to verify that the memory mappings map, for instance.

-- 
Timur Tabi
Linux Kernel Developer @ Freescale




More information about the U-Boot mailing list