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

[Wolfgang Grandegger <wg@grandegger.com>]

Timur Tabi wrote:
> 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

OK.

> 2) The address in RAM where the FDT should be placed before Linux is 
> booted.

This should be some kind of default address. Also be aware, that the 
blob can be within a uImage created with mkimage. Then the load address 
defined in the uImage should be used.

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

You might be right. The _IS_IN_ is used for the ENV, I have to check 
what the rational behind it is (if there is one at all).

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

I'm not sure if you understand the intended purpose. The address of the 
_initial_ blob could be stored in the env variable "fdtaddr" to select 
_one_ blob out of many in the FLASH.

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

Good, and for booting the FDT must be in RAM anyhow.

>>> "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.

I tend to leave it up to the board specific code where and how to verify 
the FDT. There are already various entry points like checkboard() or 
misc_init_r().

Wolfgang.