From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Harvey Date: Thu, 17 Apr 2014 23:35:34 -0700 Subject: [U-Boot] [PATCH 06/11] MX6: add struct for sharing data between SPL and uboot In-Reply-To: <534FBEB3.3030909@denx.de> 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> <534FBEB3.3030909@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Thu, Apr 17, 2014 at 4:44 AM, Stefano Babic 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