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