From mboxrd@z Thu Jan 1 00:00:00 1970 From: Stefano Babic Date: Thu, 17 Apr 2014 13:44:51 +0200 Subject: [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot In-Reply-To: <534FB95B.3030206@compulab.co.il> References: <1396504871-1454-1-git-send-email-tharvey@gateworks.com> <1396504871-1454-7-git-send-email-tharvey@gateworks.com> <534BD60F.3030504@denx.de> <534F9F1B.5080209@denx.de> <534FB95B.3030206@compulab.co.il> Message-ID: <534FBEB3.3030909@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de 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: sbabic at denx.de =====================================================================