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

[Stefano Babic <sbabic@denx.de>]

Hi Tim,

On 17/04/2014 08:07, Tim Harvey wrote:
> On Mon, Apr 14, 2014 at 5:35 AM, Stefano Babic <sbabic@denx.de> wrote:
>> Hi Tim,
>>
>> I see checking your patch that the MXS uses the same concept. And as far
>> as I can see, boot_mode_idx is used only to print the boot devioce
> 
> Stefano,
> 
> yes, that is where I got the concept from.

Well, it slipped into mainline, but adding such a structure only to have
a better print is not very useful...

> I've been told this before, but I've found that get_ram_size() will
> hang on an i.MX6 if you pass it a maxsize larger than the memory in
> your system. Perhaps you can verify you see the same behavior?

get_ram_size() works if the memory is accessible, that means that no
exception is generated when it tries to access. If the RAM controller is
programmed for a larger amount of memory, because you can have board
with different capacity of RAM, get_ram_size() finds dynamically the
soldered value.

However, if the RAM controller is programmed for an amount of RAM
smaller as what get_ram_size() tries to identify, an exception is
raised. In get_ram_size(start, size) we pass the maximum amount of
memory that the function is allowed to check. I can imagine we are
running in this case. Checking on i.MX6, we have both boards checking
the size with get_ram_size() as mx6sabresd, as well as boards fixing at
compile time the value of the RAM (nitrogen6x).

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

On the other side, I like the current concept that the SPL is simply a
loader and can load images of different types, and fixing an API between
SPL and U-Boot goes against this concept.

Best regards,
Stefano Babic

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