[U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot

[Stefano Babic <sbabic@denx.de>]

Hi Igor, hi Tim

On 17/04/2014 13:22, Igor Grinberg wrote:

> 
> get_ram_size() works on cm-fx6 all DRAM configurations.

As on most boards in mainline ;-)

> 
>>
>>>> SPL is thought to generally load an image (of course, in most cases it
>>>> is u-boot). In Falcon mode, the kernel is started without running
>>>> u-boot, making this structure useless. Do we really need such a way (but
>>>> then, it must be generalized as SPL API), or can we get rid of it ?
>>>
>>> As we have an EEPROM on the board that tells us the physical ram size,
>>> I use that to avoid the lockup.
>>
>> It seems weird. There is several boards in mainline (I am sure about
>> Freescale's PowerPC) discovering the mounted RAM. Of course, this is
>> simpler if many parameters (row/columns/...) are the same, I am not sure
>> about this.
> 
> Even if the parameters are different, this should not result in lockup...
> AFAICS, lockup of that type has nothing to do with the DRAM itself, but
> the controller configuration.

Exactly, this is what I meant. Thanks for clarifying it better.

> 
>> Are we sure it is not possible here ? What does it happen
>> with an inconsistent value in EEprom ?
>>
>>> Eventually I would like to read and
>>> validate the entire EEPROM once in SPL and pass this to u-boot.img to
>>> avoid reading and validating it again. I think this is a good example
>>> of why sharing data between SPL and u-boot.img could be useful.
>>
>> I am not sure, and I doubt it is a good idea to use persistent data to
>> store that. It is potentially dangerous, and if some reasons the EEprom
>> is changed, the board could not boot at all.
> 
> This is more a question of design and definition of what purpose the eeprom
> should serve, so I would let the vendor decide if he wants to depend on eeprom
> or not.

Agree. Parsing and evaluating vendor specific information can be done
inside board specific part, as now in read_eeprom inside gw_ventana.c.

Anyway, if there is a way to detect at runtime the hardware
configuration, it remains a better way as to store the size into the Eeprom.

Best regards,
Stefano

-- 
=====================================================================
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de
=====================================================================