hw/sd/sd.c | 26 +++++++++++++------------- 1 file changed, 13 insertions(+), 13 deletions(-)
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
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
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
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
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.
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(-)
>
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
© 2016 - 2025 Red Hat, Inc.