summaryrefslogtreecommitdiff
path: root/drivers/rtc/m41t60.c
diff options
context:
space:
mode:
authorMichael Schwingen <michael@schwingen.org>2008-02-18 23:16:35 +0100
committerStefan Roese <sr@denx.de>2008-02-21 17:12:19 +0100
commit1ba639da5604a64b3ed884a2cbb1c5414a9fa728 (patch)
tree67fc8f460e38a920281717647949a69fdd9956c2 /drivers/rtc/m41t60.c
parent928d1d77f8623c120d8763e20e1ca58df9c5c4c6 (diff)
downloadu-boot-imx-1ba639da5604a64b3ed884a2cbb1c5414a9fa728.zip
u-boot-imx-1ba639da5604a64b3ed884a2cbb1c5414a9fa728.tar.gz
u-boot-imx-1ba639da5604a64b3ed884a2cbb1c5414a9fa728.tar.bz2
CFI: Do not use uninitialized cmd_reset
Do not use uninitialized cmd_reset; issue both AMD and Intel reset commands instead From a short test, it looks like AMD-style flash roms treat *any* unknown command write as a reset, at least when in CFI Query mode, so issuing the Intel reset command to AMD-style flashs seems safe (from the small sample I have), plus the 3-cycle magic sequence should kick the state machine into the right state even without a reset command. Since the AMD-style flashs require the unlock sequence for real operation, I chose to try the AMD reset command first, so that Intel flashs do no see an invalid command prior to the CFI query. I have tested the patch on AM29LV320-style flashs from Fujitsu and Macronix, plus Intel StrataFlash. Signed-off-by: Michael Schwingen <michael@schwingen.org> Signed-off-by: Stefan Roese <sr@denx.de>
Diffstat (limited to 'drivers/rtc/m41t60.c')
0 files changed, 0 insertions, 0 deletions