summaryrefslogtreecommitdiff
path: root/common/menu.c
diff options
context:
space:
mode:
authorFabio Estevam <fabio.estevam@freescale.com>2015-02-09 07:29:33 -0200
committerStefano Babic <sbabic@denx.de>2015-02-10 12:48:50 +0100
commitaee0013e53b339a573e2a8d66062fe87765aa3bd (patch)
tree901ce16e1e92abd900fb0549bd4d2c88e03b6bae /common/menu.c
parent2d6286ab7983b1fca45b7cc2d670286ec4898ffd (diff)
downloadu-boot-imx-aee0013e53b339a573e2a8d66062fe87765aa3bd.zip
u-boot-imx-aee0013e53b339a573e2a8d66062fe87765aa3bd.tar.gz
u-boot-imx-aee0013e53b339a573e2a8d66062fe87765aa3bd.tar.bz2
mx53loco: Fix boot hang during reboot stress test
Currently by running the following test: => setenv bootcmd reset => save => reset , we observe a hang after approximately 20-30 minutes of stress reboot test. Investigation of this issue revealed that when a single DDR chip select is used, the hang does not happen. It only happens when the two chip selects are active. MX53 reference manual states at "28.6.2 Memory ZQ calibration sequence": "The controller must keep the memory lines quiet (except for CK) for the ZQ calibration time as defined in the Jedec (512 cycles for ZQCL after reset, 256 for other ZQCL and 64 for ZQCS)." According to the SDE_0 and SDE_1 bit descriptions from register ESDCTL_ESDCTL: "Writing 1 to SDE0 or SDE1 will initiate power up delays as JEDEC defines. Power up delays are a function of the configured memory type (DDR2/DDR3/LPDDR2)" So make sure to activate one chip select at time (CS0 first and then CS1 later), so that the required JEDEC delay is respected for each chip select. With this change applied the board has gone through three days of reboot stress test without any hang. Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com> Acked-by: Stefano Babic <sbabic@denx.de>
Diffstat (limited to 'common/menu.c')
0 files changed, 0 insertions, 0 deletions