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: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot