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

[Tim Harvey]

On Thu, Apr 17, 2014 at 4:44 AM, Stefano Babic <sbabic at denx.de> wrote:
> 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 ;-)
>

It looks like I mis-interpreted the failure. This issue is that
get_ram_size() only works with powers of 2 and maxes out at 2GB due to
32bit addressing. I was simply passing in a bogus value. I'm not sure
how you would deal with detecting systems with 4GB but I don't need to
support that for my boards currently.

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

I agree and I definitely see the merits of completely de-coupling the
SPL from u-boot.img so I will resort to reading the EEPROM in both
places.

Regards,

Tim