[PATCH] hw/ssi: aspeed: Deselect chip to reset state in command mode

[Andrew Jeffery]

This is probably a bug elsewhere, maybe in the kernel driver. However,
this workaround/fix appears to resolve the squashfs/UBI corruption we've
been seeing for quite some time in QEMU with e.g. witherspoon-bmc and
associated images.

The problem is the chip is left in e.g. read mode and the deselect is
necessary to reset it back to idle for the current command to issue
correctly. Failure to deselect leads to command-mode access of data at
unexpected addresses (the state mismatch means the command/address are
potentially ignored) and the result presents as data corruption.

Something I don't yet understand is the symptom (squashfs corruption)
wasn't overly deterministic. I would have expected more widespread
symptoms given the change. Having said that, UBI hammers the flash with
its wear-leveling (somewhat ironically). Its approach appears to be
somewhat complex, so maybe it's not surprising that the results are so
variable.

Cc: Andrew Geissler <geissonator at gmail.com>
Signed-off-by: Andrew Jeffery <andrew at aj.id.au>

---

An early Christmas present for Andrew G.
---
 hw/ssi/aspeed_smc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/hw/ssi/aspeed_smc.c b/hw/ssi/aspeed_smc.c
index 7755eca34976..c8713f3e3347 100644
--- a/hw/ssi/aspeed_smc.c
+++ b/hw/ssi/aspeed_smc.c
@@ -739,6 +739,7 @@ static uint64_t aspeed_smc_flash_read(void *opaque, hwaddr addr, unsigned size)
         break;
     case CTRL_READMODE:
     case CTRL_FREADMODE:
+        aspeed_smc_flash_unselect(fl);
         aspeed_smc_flash_select(fl);
         aspeed_smc_flash_setup(fl, addr);
 
-- 
2.20.1