On Thu, Apr 17, 2014 at 4:44 AM, Stefano Babic sbabic@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