On 23/07/2025 14:38, Peter Maydell wrote:
On Wed, 23 Jul 2025 at 13:47, Alex Bennée <alex.ben...@linaro.org> wrote:
Ben Dooks <ben.do...@codethink.co.uk> writes:
(Add maintainers to CC)
You should get your patch workflow to use scripts/get_maintainer.pl so
they get CC'd and reduces the chance of it being missed in the fire-hose
of qemu-devel.
$ git show | ./scripts/get_maintainer.pl
"Philippe Mathieu-Daudé" <phi...@linaro.org> (odd fixer:SD (Secure Card))
Bin Meng <bmeng...@gmail.com> (odd fixer:SD (Secure Card))
qemu-bl...@nongnu.org (open list:SD (Secure Card))
qemu-devel@nongnu.org (open list:All patches CC here)
so, no maintainers listed, just sent to the two lists.
If we get "ssi_sd: error: Unexpected response to cmd" then having
the bad s->arglen would be useful debug and does not add any complexity
to the code.
Generally we should be removing the old-style DPRINTF debug and
replacing them with tracepoints where they are warranted. The main
problem with the old style DPRINTF's is the format strings tend to
bitrot because they are not enabled by default.
Signed-off-by: Ben Dooks <ben.do...@codethink.co.uk>
---
hw/sd/ssi-sd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hw/sd/ssi-sd.c b/hw/sd/ssi-sd.c
index 6c90a86ab4..f1441d2c97 100644
--- a/hw/sd/ssi-sd.c
+++ b/hw/sd/ssi-sd.c
@@ -183,7 +183,7 @@ static uint32_t ssi_sd_transfer(SSIPeripheral *dev,
uint32_t val)
s->response[0] = 1;
memcpy(&s->response[1], longresp, 4);
} else if (s->arglen != 4) {
- BADF("Unexpected response to cmd %d\n", s->cmd);
+ BADF("Unexpected response to cmd %d, arglen=%d\n", s->cmd,
s->arglen);
That said BADF is defined in both cases (although the exit(1) for the
debug leg is a bit aggressive). Is this an error of the guest
miss-programming the device with invalid data?
There could be an argument for using:
qemu_log_mask(LOG_GUEST_ERROR, "Unexpected response to cmd %d, arglen=%d\n",
s->cmd, s->arglen);
instead.
This unexpected response comes from QEMU's SD card emulation,
so I'm not sure to what extent LOG_GUEST_ERROR is appropriate.
Is this triggered by the guest doing something silly, or by
a bug in QEMU itself?
I am currently trying to track down two errors with mmc-spi.
The first looks like u-boot is sending a couple of CMDs (9, 10)
in the wrong state (currently this works however with a real SD
card) so I have a tmp-fix in to just ignore the two checks in
these and u-boot is now working.
I'm also getting multiple versions of linux failing with QEMU10
on Debian/testing and my own close to the current git tree with
Linux and CMD13...
[ 0.579845] EXT4-fs (mmcblk0): INFO: recovery required on readonly
filesystem
[ 0.580222] EXT4-fs (mmcblk0): write access will be enabled during
recovery
ssi_sd: error: Unexpected response to cmd 13, arglen=16
ssi_sd: error: Unexpected response to cmd 13, arglen=16
ssi_sd: error: Unexpected response to cmd 13, arglen=16
ssi_sd: error: Unexpected response to cmd 13, arglen=16
Then the system stops working.
Systems are riscv sifive_u and my own cva6 machine
--
Ben Dooks http://www.codethink.co.uk/
Senior Engineer Codethink - Providing Genius
https://www.codethink.co.uk/privacy.html
