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

[Wolfgang Grandegger]

Timur Tabi wrote:
> Wolfgang Grandegger wrote:
>> 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. 
> 
> Any default address is most likely board-specific.  It would be nice if 
> U-Boot could determine the best address automatically when possible.
> 
>> 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.
> 
> Yes.
> 
>> 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).
> 
> It's handy if you want to use the same macro to represent different 
> types of addresses. Personally, I don't see much value in that.  I would 
> rather that a particular macro be used to represent only one kind of 
> value.  When I see CFG_FDT_ADDR_RAM, I know that the value is a virtual 
> address that the CPU can dereference at any time.
> 
>> 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.
> 
> Hmm....
> 
> I can see value in that, but then that variable can contain completely 
> different addresses depending on the type of storage, which I don't 
> like.  Plus, I would rather that we use macro commands to set the FDT 
> address, rather than an environment variable.  This gives us more 
> flexibility.

What do you mean with "macro commands"? Simply macro definitions in the 
board's config file? Such an address is fixed at compile time pointing 
to one FDT blob. The purpose of the env variable "fdtaddr" is to select 
that address at run time. Again, this allows to hold more than one blob 
in FLASH and select one via env setting. This would allow for _one_ 
combination of images of U-Boot + Linux + Blobs for a _set_ of boards 
which might reduce the effort to bring up board. Nevertheless, regard it 
as useful add-on.

>> I tend to leave it up to the board specific code where and how to 
>> verify the FDT. 
> 
> fdt_checkboard() *is* board-specific code.
> 
> There are already various entry points like checkboard() or
>> misc_init_r().
> 
> But this functions don't normally know where the FDT is.  

They know. The global variable "fdt" will point to the blob and a very 
early common check has then already be done. Note that the FDT commands 
also uses the global "fdt" variable.

> fdt_checkboard() would be designed specifically to validate an FDT from 
> a board-specific point-of-view.  It's good to have that code isolated 
> from other board-specific code.

Why more entry points if there are already suitable ones. I'm still not 
sure if we need an extra function.

Wolfgang.