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

[Jerry Van Baren <gerald.vanbaren@smiths-aerospace.com>]

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.

Hi Timur,

You totally lost me on that assertion.  What do you mean when you say 
"macro commands?"

If you are talking preprocessor #define macros, you are comparing a 
hardcoded address (after compilation) to a runtime modifiable address in 
an env variable.

If you mean a hush script when you say "macro commands", that would be a 
way of setting an env variable, so how is that more flexible?  We 
already have the "fdt addr" command at the hush level that can be used 
by hand or in scripts to set the fdt blob address, but that is _way_ 
later in the boot cycle than what Wolfgang will be using.

[snip]

Best regards,
gvb