From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 1 Feb 2013 09:37:33 -0500 Subject: [U-Boot] [PATCH 1/7] ARM: OMAP4+: emif: Detect SDRAM from SDRAM config register In-Reply-To: <510B60F5.20406@ti.com> References: <1359611525-19017-1-git-send-email-r.sricharan@ti.com> <1359611525-19017-2-git-send-email-r.sricharan@ti.com> <510A9C06.6030102@ti.com> <510B60F5.20406@ti.com> Message-ID: <510BD32D.4000401@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 02/01/2013 01:30 AM, R Sricharan wrote: > On Thursday 31 January 2013 09:59 PM, Tom Rini wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> On 01/31/2013 12:51 AM, R Sricharan wrote: >>> From: Lokesh Vutla >>> >>> Now SDRAM initialization is done on the basis of omap >>> revision. Instead this should be done on basis of SDRAM type >>> read from EMIF_SDRAM_CONFIG register. This will be helpful to >>> avoid unnessecary cpu checks for new boards >>> >>> Signed-off-by: R Sricharan Signed-off-by: >>> Lokesh Vutla >> >> Does this mean the ROM is already doing some basic EMIF >> programming here? I swear I looked down this path before, when I >> wanted to share this code with am33xx and the problem is that >> while the registers aren't reset on warm boot, on cold boot they >> always come up in a default value, for both DDR2 and DDR3. >> >> Or are you able to get by as the platforms come up with >> different default values? >> > Not the ROMCODE, the default value for SDRAM_CONFIG register is > exported from control module register based on efuse settings. We > did see that this default value was correct depending upon LPDDR2 > or DDR3 in the case of OMAP. OK, good. > So does this mean that am3xx did not have the logic to load this > register dynamically based on efuse settings ? If that is the only > exception, then we can hardcode the register during startup only > in that case. Except for this, where you able to use the > emif-common driver in your case ? In my initial testing, it was not being setup correctly. I think it was between that, and trying to abstract out further the PM-related changes there wasn't much common EMIF code left, so I set the project aside at the time. I'll try and take another whack at it as I know someone is adding ti814x support currently and did find a good match-up with this EMIF code rather than the am33xx version, so maybe that will help me to see what's going on. And with all of that: Reviewed-by: Tom Rini - -- Tom -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJRC9MsAAoJENk4IS6UOR1WjVkP/AzWShG1HSZR77Wk3Ax9kfs6 6P5cHTMX8Am9R+2SUk2j5LV54CzBYwGwUpdH3tDdE5nZQ0IieXs1MhYsx5kqSFHF mIZHMeO8CVM4n/VjguKybAItYCmaXjQ3QVPkN63FuVgK50AZJPeBJZJV5m0pICSq YnAQdQSirTHuJEZlhA4aJ9H5h7w1yRLeZ8YWtfX+feGotQoZgn/ZsieljfTc7MBY PowXxUbZmxjcv+9WRd/ExQxWrbGhb2Jvq3bxnJMvPoTpYgYs9MBf1lv1bO5BRqnq eD4hQjgVYWp7Et1ENHL1SEL9BCjeNmSho49a/27zV3KH+HeCnA1kwDJiwMvyxsI9 fN8rqHl87TZEOVi++VB5wtM9ksKWVcZW4IGLxExG5XCUI5rYYZjKYGW5yx4H4481 E5fS+bQohHr1PcGXvTmYJjSs/pIBvgqbmEM61Pd5AApRc0s7SVXfsHeKz0TTnFLU JaclcxGlBqa2LO3Ysard51t/+wrSz5gin5eQhwMux+IdRM2XErLh0xyBpyzc+iQR d/eG1KpUpmLOHBEk5c8lAGhkJX2t2SL7MXTiYbVgu74nUndPyJR8UR/hCF5ilh/M iDFN4tV70cc9gyuYVasJ+Qw4Ufct1THh4o5cAlew0FLCIEqdSGy/3LgVkFF28QuF xv45NQhl2nuA+Zk6Fb/M =l80i -----END PGP SIGNATURE-----