[PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0

[PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0

[Bin Meng]

The U-Boot community reported a CI failure [1] where the
`sifive_unleashed` target failed to boot from an SD card after
upgrading from QEMU v8.2.0 to v9.2.3.

At that time, the issue was traced to commit da954d0e
("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")
which was introduced in v9.1.0.

Testing with the latest QEMU mainline shows that the problem still
persists, although the underlying cause has changed due to refactoring
since then.

This series fixes the broken `ssi-sd` model. After applying these
patches, U-Boot successfully boots again on the `sifive_unleashed`
target using QEMU’s `sifive_u` machine.

[1] https://gitlab.com/qemu-project/qemu/-/issues/2945


Bin Meng (2):
  hw/sd: Fix incorrect idle state reporting in R1 response for SPI mode
  hw/sd: Fix ACMD41 state machine in SPI mode

 hw/sd/sd.c | 26 +++++++++++++-------------
 1 file changed, 13 insertions(+), 13 deletions(-)

-- 
2.34.1

[PATCH 1/2] hw/sd: Fix incorrect idle state reporting in R1 response for SPI mode

[Bin Meng]

Since commit b66f73a0 ("hw/sd: Add SDHC support for SD card SPI-mode"),
the CARD_POWER_UP bit in the OCR register has been set after reset.
Therefore, checking this bit against zero in sd_response_r1_make() to
determine the card’s idle state is incorrect in SPI mode. As a result,
QEMU makes the U-Boot mmc-spi driver believe the card never leaves the
reset state.

Fixes: 1585ab9f ("hw/sd/sdcard: Fill SPI response bits in card code")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
---

 hw/sd/sd.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index 9c86c016cc..5aae541363 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -789,8 +789,7 @@ static size_t sd_response_size(SDState *sd, sd_rsp_type_t rtype)
 static void sd_response_r1_make(SDState *sd, uint8_t *response)
 {
     if (sd_is_spi(sd)) {
-        response[0] = sd->state == sd_idle_state
-                   && !FIELD_EX32(sd->ocr, OCR, CARD_POWER_UP);
+        response[0] = sd->state == sd_idle_state;
         response[0] |= FIELD_EX32(sd->card_status, CSR, ERASE_RESET) << 1;
         response[0] |= FIELD_EX32(sd->card_status, CSR, ILLEGAL_COMMAND) << 2;
         response[0] |= FIELD_EX32(sd->card_status, CSR, COM_CRC_ERROR) << 3;
-- 
2.34.1

Re: [PATCH 1/2] hw/sd: Fix incorrect idle state reporting in R1 response for SPI mode

[Philippe Mathieu-Daudé]

On 10/11/25 12:05, Bin Meng wrote:
> Since commit b66f73a0 ("hw/sd: Add SDHC support for SD card SPI-mode"),
> the CARD_POWER_UP bit in the OCR register has been set after reset.
> Therefore, checking this bit against zero in sd_response_r1_make() to
> determine the card’s idle state is incorrect in SPI mode. As a result,
> QEMU makes the U-Boot mmc-spi driver believe the card never leaves the
> reset state.
> 
> Fixes: 1585ab9f ("hw/sd/sdcard: Fill SPI response bits in card code")
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945
> Reported-by: Tom Rini <trini@konsulko.com>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> ---
> 
>   hw/sd/sd.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

[PATCH 2/2] hw/sd: Fix ACMD41 state machine in SPI mode

[Bin Meng]

In SPI mode, the ACMD41 argument only defines bit 30 (HCS); all other
bits are reserved. The current implementation incorrectly checks the
voltage window bits even in SPI mode, preventing the state machine
from transitioning to the READY state. As a result, the U-Boot
mmc-spi driver falls into an endless CMD55/ACMD41 loop.

Fixes: 3241a61a ("hw/sd/sdcard: Use complete SEND_OP_COND implementation in SPI mode")
Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945
Reported-by: Tom Rini <trini@konsulko.com>
Signed-off-by: Bin Meng <bmeng.cn@gmail.com>

---

 hw/sd/sd.c | 23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/hw/sd/sd.c b/hw/sd/sd.c
index 5aae541363..11c3a64080 100644
--- a/hw/sd/sd.c
+++ b/hw/sd/sd.c
@@ -2289,20 +2289,21 @@ static sd_rsp_type_t sd_cmd_SEND_OP_COND(SDState *sd, SDRequest req)
         }
     }
 
-    if (FIELD_EX32(sd->ocr & req.arg, OCR, VDD_VOLTAGE_WINDOW)) {
-        /*
-         * We accept any voltage.  10000 V is nothing.
-         *
-         * Once we're powered up, we advance straight to ready state
-         * unless it's an enquiry ACMD41 (bits 23:0 == 0).
-         */
-        sd->state = sd_ready_state;
-    }
-
     if (sd_is_spi(sd)) {
+        sd->state = sd_ready_state;
         return sd_r1;
+    } else {
+        if (FIELD_EX32(sd->ocr & req.arg, OCR, VDD_VOLTAGE_WINDOW)) {
+            /*
+            * We accept any voltage.  10000 V is nothing.
+            *
+            * Once we're powered up, we advance straight to ready state
+            * unless it's an enquiry ACMD41 (bits 23:0 == 0).
+            */
+            sd->state = sd_ready_state;
+        }
+        return sd_r3;
     }
-    return sd_r3;
 }
 
 /* ACMD42 */
-- 
2.34.1

Re: [PATCH 2/2] hw/sd: Fix ACMD41 state machine in SPI mode

[Philippe Mathieu-Daudé]

On 10/11/25 12:05, Bin Meng wrote:
> In SPI mode, the ACMD41 argument only defines bit 30 (HCS); all other
> bits are reserved. The current implementation incorrectly checks the
> voltage window bits even in SPI mode, preventing the state machine
> from transitioning to the READY state. As a result, the U-Boot
> mmc-spi driver falls into an endless CMD55/ACMD41 loop.
> 
> Fixes: 3241a61a ("hw/sd/sdcard: Use complete SEND_OP_COND implementation in SPI mode")
> Resolves: https://gitlab.com/qemu-project/qemu/-/issues/2945
> Reported-by: Tom Rini <trini@konsulko.com>
> Signed-off-by: Bin Meng <bmeng.cn@gmail.com>
> 
> ---
> 
>   hw/sd/sd.c | 23 ++++++++++++-----------
>   1 file changed, 12 insertions(+), 11 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0

[Philippe Mathieu-Daudé]

Hi Bin, Tom,

On 10/11/25 12:05, Bin Meng wrote:
> 
> The U-Boot community reported a CI failure [1] where the
> `sifive_unleashed` target failed to boot from an SD card after
> upgrading from QEMU v8.2.0 to v9.2.3.
> 
> At that time, the issue was traced to commit da954d0e
> ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")
> which was introduced in v9.1.0.
> 
> Testing with the latest QEMU mainline shows that the problem still
> persists, although the underlying cause has changed due to refactoring
> since then.
> 
> This series fixes the broken `ssi-sd` model. After applying these
> patches, U-Boot successfully boots again on the `sifive_unleashed`
> target using QEMU’s `sifive_u` machine.

Thanks for fixing this issue!

Do you mind adding this test as a functional one, so we get this
code path covered?

> 
> [1] https://gitlab.com/qemu-project/qemu/-/issues/2945
> 
> 
> Bin Meng (2):
>    hw/sd: Fix incorrect idle state reporting in R1 response for SPI mode
>    hw/sd: Fix ACMD41 state machine in SPI mode
> 
>   hw/sd/sd.c | 26 +++++++++++++-------------
>   1 file changed, 13 insertions(+), 13 deletions(-)
> 

Re: [PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0

[Bin Meng]

Hi Philippe,

On Mon, Nov 10, 2025 at 7:57 PM Philippe Mathieu-Daudé
<philmd@linaro.org> wrote:
>
> Hi Bin, Tom,
>
> On 10/11/25 12:05, Bin Meng wrote:
> >
> > The U-Boot community reported a CI failure [1] where the
> > `sifive_unleashed` target failed to boot from an SD card after
> > upgrading from QEMU v8.2.0 to v9.2.3.
> >
> > At that time, the issue was traced to commit da954d0e
> > ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")
> > which was introduced in v9.1.0.
> >
> > Testing with the latest QEMU mainline shows that the problem still
> > persists, although the underlying cause has changed due to refactoring
> > since then.
> >
> > This series fixes the broken `ssi-sd` model. After applying these
> > patches, U-Boot successfully boots again on the `sifive_unleashed`
> > target using QEMU’s `sifive_u` machine.
>
> Thanks for fixing this issue!
>
> Do you mind adding this test as a functional one, so we get this
> code path covered?
>

Sure, I will try to add a test in v2.

Regards,
Bin

Re: [PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0

[Philippe Mathieu-Daudé]

On 10/11/25 12:05, Bin Meng wrote:

> Bin Meng (2):
>    hw/sd: Fix incorrect idle state reporting in R1 response for SPI mode
>    hw/sd: Fix ACMD41 state machine in SPI mode

Series queued, thanks.

Re: [PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0

[Michael Tokarev]

On 11/10/25 14:05, Bin Meng wrote:
> 
> The U-Boot community reported a CI failure [1] where the
> `sifive_unleashed` target failed to boot from an SD card after
> upgrading from QEMU v8.2.0 to v9.2.3.
> 
> At that time, the issue was traced to commit da954d0e
> ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")
> which was introduced in v9.1.0.
> 
> Testing with the latest QEMU mainline shows that the problem still
> persists, although the underlying cause has changed due to refactoring
> since then.
> 
> This series fixes the broken `ssi-sd` model. After applying these
> patches, U-Boot successfully boots again on the `sifive_unleashed`
> target using QEMU’s `sifive_u` machine.
> 
> [1] https://gitlab.com/qemu-project/qemu/-/issues/2945

Hi!

This seems to be a qemu-stable material.

The refactoring mentioned above happened between 10.1.0-rc1 and
10.1.0-rc2, which is quite a hot spot for a refactoring.   So the
changes are definitely relevant for 10.1.x series, where I applied
them already.

But we've 10.0.x series which supposed to be long-term support
series, where we have the problem too (since the issue were
introduced before 10.0), but the 2 fixes here don't apply to 10.0,
obviously, due to refactoring.

Now I wonder should we fix this in 10.0.x at all, should we
create some unique fix for 10.0.x, or should we pick the
refactoring done in 10.1.0-rc stage, to 10.0.x?

This is the original refactoring patchset:
https://lore.kernel.org/qemu-devel/20250804133406.17456-1-philmd@linaro.org/

The patchset applies cleanly to 10.0.x, with these 2 fixes on
top, and the resulting thing seem to work fine, so far anyway:
https://gitlab.com/mjt0k/qemu/-/commits/10.0-sdcard
(and with local tests, including the test in the above series).

What do you think?  How important it is to make this whole
thing work in 10.0.x lts series (including distribution(s)
based on this, such as current debian stable "trixie")?

Thanks,

/mjt

Re: [PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0

[Michael Tokarev]

On 11/19/25 13:44, Michael Tokarev wrote:
...
> This is the original refactoring patchset:
> https://lore.kernel.org/qemu-devel/20250804133406.17456-1- 
> philmd@linaro.org/
> 
> The patchset applies cleanly to 10.0.x, with these 2 fixes on
> top, and the resulting thing seem to work fine, so far anyway:
> https://gitlab.com/mjt0k/qemu/-/commits/10.0-sdcard
> (and with local tests, including the test in the above series).
> 
> What do you think?  How important it is to make this whole
> thing work in 10.0.x lts series (including distribution(s)
> based on this, such as current debian stable "trixie")?

And I already considered picking this patchset to 10.0.x, see
https://lore.kernel.org/qemu-devel/39982478-b3fb-46b0-bef0-c0839c123300@tls.msk.ru/
and the reply to its message :)

Thanks,

/mjt

Re: [PATCH 0/2] hw/sd: Fix broken ssi-sd implementation since v9.1.0

[Tom Rini]

[-- Attachment #1: Type: text/plain, Size: 2504 bytes --]

On Wed, Nov 19, 2025 at 01:44:47PM +0300, Michael Tokarev wrote:
> On 11/10/25 14:05, Bin Meng wrote:
> > 
> > The U-Boot community reported a CI failure [1] where the
> > `sifive_unleashed` target failed to boot from an SD card after
> > upgrading from QEMU v8.2.0 to v9.2.3.
> > 
> > At that time, the issue was traced to commit da954d0e
> > ("hw/sd/sdcard: Add spi_cmd_SEND_CSD/CID handlers (CMD9 & CMD10)")
> > which was introduced in v9.1.0.
> > 
> > Testing with the latest QEMU mainline shows that the problem still
> > persists, although the underlying cause has changed due to refactoring
> > since then.
> > 
> > This series fixes the broken `ssi-sd` model. After applying these
> > patches, U-Boot successfully boots again on the `sifive_unleashed`
> > target using QEMU’s `sifive_u` machine.
> > 
> > [1] https://gitlab.com/qemu-project/qemu/-/issues/2945
> 
> Hi!
> 
> This seems to be a qemu-stable material.
> 
> The refactoring mentioned above happened between 10.1.0-rc1 and
> 10.1.0-rc2, which is quite a hot spot for a refactoring.   So the
> changes are definitely relevant for 10.1.x series, where I applied
> them already.
> 
> But we've 10.0.x series which supposed to be long-term support
> series, where we have the problem too (since the issue were
> introduced before 10.0), but the 2 fixes here don't apply to 10.0,
> obviously, due to refactoring.
> 
> Now I wonder should we fix this in 10.0.x at all, should we
> create some unique fix for 10.0.x, or should we pick the
> refactoring done in 10.1.0-rc stage, to 10.0.x?
> 
> This is the original refactoring patchset:
> https://lore.kernel.org/qemu-devel/20250804133406.17456-1-philmd@linaro.org/
> 
> The patchset applies cleanly to 10.0.x, with these 2 fixes on
> top, and the resulting thing seem to work fine, so far anyway:
> https://gitlab.com/mjt0k/qemu/-/commits/10.0-sdcard
> (and with local tests, including the test in the above series).
> 
> What do you think?  How important it is to make this whole
> thing work in 10.0.x lts series (including distribution(s)
> based on this, such as current debian stable "trixie")?

With my U-Boot hat on (which is where we found the issue), it's not
critical. I need to get us in the habit of "do a release, upgrade
ancillary tooling we test too" so that we find potential problems like
this much quicker. We should be, but aren't, on 10.1.x already for
v2026.04 and on 10.0.6 not 10.0.2 for v2026.01.

-- 
Tom

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]