[PATCH v2 0/2] sd:sdhci Fix data transfer did not complete

[PATCH v2 0/2] sd:sdhci Fix data transfer did not complete

[Jamin Lin via]

v1:
1. Fix boundary_count overflow
2. Fix data transfer did not complete if data size is bigger then SDMA Buffer Boundary

v2:
1. fix typo
2. update to none RFC patch
3. check the most upper byte of SDMA System Address Register (0x00) is written,
   then restarts SDMA data transfer.

Jamin Lin (2):
  hw/sd/sdhci: Fix boundary_count overflow in
    sdhci_sdma_transfer_multi_blocks
  hw/sd/sdhci: Fix data transfer did not complete if data size is bigger
    than SDMA Buffer Boundary

 hw/sd/sdhci.c | 20 ++++++++++++++++----
 1 file changed, 16 insertions(+), 4 deletions(-)

-- 
2.34.1

[PATCH v2 1/2] hw/sd/sdhci: Fix boundary_count overflow in sdhci_sdma_transfer_multi_blocks

[Jamin Lin via]

How to reproduce it:
1. The value of "s->blksie" was 0x7200. The bits[14:12] was "111", so the buffer
   boundary was 0x80000.(512Kbytes). This SDMA buffer boundary was the same as
   u-boot default value.
   The bit[11:0] was "001000000000", so the block size was 0x200.(512bytes)
2. The SDMA address was 0x83123456 which was not page aligned and
   "s->sdmasysad % boundary_chk" was 0x23456. The value of boundary_count was
   0x5cbaa.("boundary_chk - (s->sdmasysad % boundary_chk)" -->
   "(0x80000 - 0x23456)")

However, boundary_count did not align the block size 512 bytes and the SDMA
address was not page aligned(0x80000), so the following if-statement never be true,
```
if (((boundary_count + begin) < block_size) && page_aligned)
````

Finally, it caused boundary_count overflow because its data type was uint32_t.
Ex: the last boundary_count was 0x1aa and "0x1aa - 0x200" became "0xffffffaa".
It is the wrong behavior.

To fix it, change to check boundary_count smaller than block size if system
address did not page align

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
---
 hw/sd/sdhci.c | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 37875c02c3..f1a329fdaf 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -618,7 +618,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
                 sdbus_read_data(&s->sdbus, s->fifo_buffer, block_size);
             }
             begin = s->data_count;
-            if (((boundary_count + begin) < block_size) && page_aligned) {
+            if (((boundary_count + begin) < block_size) && !page_aligned) {
                 s->data_count = boundary_count + begin;
                 boundary_count = 0;
              } else {
@@ -634,7 +634,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
             if (s->data_count == block_size) {
                 s->data_count = 0;
             }
-            if (page_aligned && boundary_count == 0) {
+            if (boundary_count == 0) {
                 break;
             }
         }
@@ -642,7 +642,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
         s->prnsts |= SDHC_DOING_WRITE;
         while (s->blkcnt) {
             begin = s->data_count;
-            if (((boundary_count + begin) < block_size) && page_aligned) {
+            if (((boundary_count + begin) < block_size) && !page_aligned) {
                 s->data_count = boundary_count + begin;
                 boundary_count = 0;
              } else {
@@ -659,7 +659,7 @@ static void sdhci_sdma_transfer_multi_blocks(SDHCIState *s)
                     s->blkcnt--;
                 }
             }
-            if (page_aligned && boundary_count == 0) {
+            if (boundary_count == 0) {
                 break;
             }
         }
-- 
2.34.1

[PATCH v2 2/2] hw/sd/sdhci: Fix data transfer did not complete if data size is bigger than SDMA Buffer Boundary

[Jamin Lin via]

According to the design of sdhci_sdma_transfer_multi_blocks, if the
"s->blkcnt * 512" was bigger than the SDMA Buffer boundary, it break the
while loop of data transfer and set SDHC_NISEN_DMA in the normal interrupt
status to notify the firmware that this SDMA boundary buffer Transfer Complete
and firmware should set the system address of the next SDMA boundary buffer
for the remained data transfer.

However, after firmware set the system address of the next SDMA boundary buffer
in the SDMA System Address Register(0x00), SDHCI model did not restart the data
transfer, again. Finally, firmware break the data transfer because firmware
did not receive the either "DMA Interrupt" or "Transfer Complete Interrupt"
from SDHCI model.

Error log from u-boot
```
sdhci_transfer_data: Transfer data timeout
 ** fs_devread read error - block
```

According to the following mention from SDMA System Address Register of SDHCI
spec,
'''
This register contains the system memory address for an SDMA transfer in
32-bit addressing mode. When the Host Controller stops an SDMA transfer,
this register shall point to the system address of the next contiguous data
position.
It can be accessed only if no transaction is executing (i.e., after a transaction
has stopped). Reading this register during SDMA transfers may return an
invalid value.
The Host Driver shall initialize this register before starting an SDMA
transaction.
After SDMA has stopped, the next system address of the next contiguous
data position can be read from this register.
The SDMA transfer waits at the every boundary specified by the SDMA
Buffer Boundary in the Block Size register. The Host Controller generates
DMA Interrupt to request the Host Driver to update this register. The Host
Driver sets the next system address of the next data position to this register.
When the most upper byte of this register (003h) is written, the Host Controller
restarts the SDMA transfer.
''',

restart the data transfer if firmware writes the most upper byte of SDMA System
Address, s->blkcnt is bigger than 0 and SDHCI is in the data transfer state.

Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
---
 hw/sd/sdhci.c | 12 ++++++++++++
 1 file changed, 12 insertions(+)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index f1a329fdaf..a632177735 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -1180,6 +1180,18 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val, unsigned size)
                     sdhci_sdma_transfer_single_block(s);
                 }
             }
+        } else if (TRANSFERRING_DATA(s->prnsts)) {
+            s->sdmasysad = (s->sdmasysad & mask) | value;
+            MASKED_WRITE(s->sdmasysad, mask, value);
+            /* restarts the SDMA transfer if the most upper byte is written */
+            if ((s->sdmasysad & 0xFF000000) && s->blkcnt &&
+                SDHC_DMA_TYPE(s->hostctl1) == SDHC_CTRL_SDMA) {
+                if (s->trnmod & SDHC_TRNS_MULTI) {
+                    sdhci_sdma_transfer_multi_blocks(s);
+                } else {
+                    sdhci_sdma_transfer_single_block(s);
+                }
+            }
         }
         break;
     case SDHC_BLKSIZE:
-- 
2.34.1

RE: [PATCH v2 0/2] sd:sdhci Fix data transfer did not complete

[Jamin Lin]

> From: Jamin Lin <jamin_lin@aspeedtech.com>
> Sent: Friday, December 13, 2024 11:12 AM
> To: Philippe Mathieu-Daudé <philmd@linaro.org>; Bin Meng
> <bmeng.cn@gmail.com>; open list:SD (Secure Card)
> <qemu-block@nongnu.org>; open list:All patches CC here
> <qemu-devel@nongnu.org>
> Cc: Jamin Lin <jamin_lin@aspeedtech.com>; Troy Lee
> <troy_lee@aspeedtech.com>; Yunlin Tang <yunlin.tang@aspeedtech.com>
> Subject: [PATCH v2 0/2] sd:sdhci Fix data transfer did not complete
> 
> v1:
> 1. Fix boundary_count overflow
> 2. Fix data transfer did not complete if data size is bigger then SDMA Buffer
> Boundary
> 
> v2:
> 1. fix typo
> 2. update to none RFC patch
> 3. check the most upper byte of SDMA System Address Register (0x00) is
> written,
>    then restarts SDMA data transfer.
> 
> Jamin Lin (2):
>   hw/sd/sdhci: Fix boundary_count overflow in
>     sdhci_sdma_transfer_multi_blocks
>   hw/sd/sdhci: Fix data transfer did not complete if data size is bigger
>     than SDMA Buffer Boundary
> 
>  hw/sd/sdhci.c | 20 ++++++++++++++++----
>  1 file changed, 16 insertions(+), 4 deletions(-)
> 

Hi Philippe, SDHCI Maintainer,

Happy New Year 2025!

Sorry to bother you.
If you have time, could you please help review this patch series?

Thanks,
Jamin

> --
> 2.34.1

Re: [PATCH v2 2/2] hw/sd/sdhci: Fix data transfer did not complete if data size is bigger than SDMA Buffer Boundary

[Bernhard Beschow]

Am 13. Dezember 2024 03:12:05 UTC schrieb Jamin Lin via <qemu-devel@nongnu.org>:
>According to the design of sdhci_sdma_transfer_multi_blocks, if the
>"s->blkcnt * 512" was bigger than the SDMA Buffer boundary, it break the
>while loop of data transfer and set SDHC_NISEN_DMA in the normal interrupt
>status to notify the firmware that this SDMA boundary buffer Transfer Complete
>and firmware should set the system address of the next SDMA boundary buffer
>for the remained data transfer.
>
>However, after firmware set the system address of the next SDMA boundary buffer
>in the SDMA System Address Register(0x00), SDHCI model did not restart the data
>transfer, again. Finally, firmware break the data transfer because firmware
>did not receive the either "DMA Interrupt" or "Transfer Complete Interrupt"
>from SDHCI model.

I ran into a similar problem in u-boot, too. Apparently its Freescale uSDHCI driver expects the SD command to fill the whole buffer. Here are some thoughts:

AFAIU, the SDMA buffer needs to be big enough to hold all s->blkcnt * s->blksize bytes and a guest would typically expect the SD command to fill the buffer in one go (please correct me if I'm wrong). Furthermore, I believe on real hardware the command would run in the background, allowing the guest to do real work rather than wait. After all, the block attributes register allows for up to 4GiB to be filled on some hardware (again, please correct me if I'm wrong).

The problem is that sdhci_sdma_transfer_multi_blocks() blocks QEMU, i.e. does not run in the background. If a guest asks for huge amounts of data to be transferred, then this would disturb emulation and QEMU would freeze for a while. To avoid that, it seems to me as if the implementation chooses to exit the while loop prematurely, relying on the guest to poke it again. This, unfortunately, doesn't work for all guests. So ideally, sdhci_sdma_transfer_multi_blocks() should read all data and run in the background, e.g. in a thread or in even in a coroutine? What do you think?

Best regards,
Bernhard

>
>Error log from u-boot
>```
>sdhci_transfer_data: Transfer data timeout
> ** fs_devread read error - block
>```
>
>According to the following mention from SDMA System Address Register of SDHCI
>spec,
>'''
>This register contains the system memory address for an SDMA transfer in
>32-bit addressing mode. When the Host Controller stops an SDMA transfer,
>this register shall point to the system address of the next contiguous data
>position.
>It can be accessed only if no transaction is executing (i.e., after a transaction
>has stopped). Reading this register during SDMA transfers may return an
>invalid value.
>The Host Driver shall initialize this register before starting an SDMA
>transaction.
>After SDMA has stopped, the next system address of the next contiguous
>data position can be read from this register.
>The SDMA transfer waits at the every boundary specified by the SDMA
>Buffer Boundary in the Block Size register. The Host Controller generates
>DMA Interrupt to request the Host Driver to update this register. The Host
>Driver sets the next system address of the next data position to this register.
>When the most upper byte of this register (003h) is written, the Host Controller
>restarts the SDMA transfer.
>''',
>
>restart the data transfer if firmware writes the most upper byte of SDMA System
>Address, s->blkcnt is bigger than 0 and SDHCI is in the data transfer state.
>
>Signed-off-by: Jamin Lin <jamin_lin@aspeedtech.com>
>---
> hw/sd/sdhci.c | 12 ++++++++++++
> 1 file changed, 12 insertions(+)
>
>diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
>index f1a329fdaf..a632177735 100644
>--- a/hw/sd/sdhci.c
>+++ b/hw/sd/sdhci.c
>@@ -1180,6 +1180,18 @@ sdhci_write(void *opaque, hwaddr offset, uint64_t val, unsigned size)
>                     sdhci_sdma_transfer_single_block(s);
>                 }
>             }
>+        } else if (TRANSFERRING_DATA(s->prnsts)) {
>+            s->sdmasysad = (s->sdmasysad & mask) | value;
>+            MASKED_WRITE(s->sdmasysad, mask, value);
>+            /* restarts the SDMA transfer if the most upper byte is written */
>+            if ((s->sdmasysad & 0xFF000000) && s->blkcnt &&
>+                SDHC_DMA_TYPE(s->hostctl1) == SDHC_CTRL_SDMA) {
>+                if (s->trnmod & SDHC_TRNS_MULTI) {
>+                    sdhci_sdma_transfer_multi_blocks(s);
>+                } else {
>+                    sdhci_sdma_transfer_single_block(s);
>+                }
>+            }
>         }
>         break;
>     case SDHC_BLKSIZE:

Re: [PATCH v2 2/2] hw/sd/sdhci: Fix data transfer did not complete if data size is bigger than SDMA Buffer Boundary

[Philippe Mathieu-Daudé]

On 7/1/25 08:10, Bernhard Beschow wrote:
> 
> 
> Am 13. Dezember 2024 03:12:05 UTC schrieb Jamin Lin via <qemu-devel@nongnu.org>:
>> According to the design of sdhci_sdma_transfer_multi_blocks, if the
>> "s->blkcnt * 512" was bigger than the SDMA Buffer boundary, it break the
>> while loop of data transfer and set SDHC_NISEN_DMA in the normal interrupt
>> status to notify the firmware that this SDMA boundary buffer Transfer Complete
>> and firmware should set the system address of the next SDMA boundary buffer
>> for the remained data transfer.
>>
>> However, after firmware set the system address of the next SDMA boundary buffer
>> in the SDMA System Address Register(0x00), SDHCI model did not restart the data
>> transfer, again. Finally, firmware break the data transfer because firmware
>> did not receive the either "DMA Interrupt" or "Transfer Complete Interrupt"
>>from SDHCI model.
> 
> I ran into a similar problem in u-boot, too. Apparently its Freescale uSDHCI driver expects the SD command to fill the whole buffer. Here are some thoughts:
> 
> AFAIU, the SDMA buffer needs to be big enough to hold all s->blkcnt * s->blksize bytes and a guest would typically expect the SD command to fill the buffer in one go (please correct me if I'm wrong). Furthermore, I believe on real hardware the command would run in the background, allowing the guest to do real work rather than wait. After all, the block attributes register allows for up to 4GiB to be filled on some hardware (again, please correct me if I'm wrong).
> 
> The problem is that sdhci_sdma_transfer_multi_blocks() blocks QEMU, i.e. does not run in the background. If a guest asks for huge amounts of data to be transferred, then this would disturb emulation and QEMU would freeze for a while. To avoid that, it seems to me as if the implementation chooses to exit the while loop prematurely, relying on the guest to poke it again. This, unfortunately, doesn't work for all guests. So ideally, sdhci_sdma_transfer_multi_blocks() should read all data and run in the background, e.g. in a thread or in even in a coroutine? What do you think?

Yes, ideally this would be using the "system/dma.h" API,
dma_blk_io() and dma_buf_read/dma_buf_write(). Current
implementation was a good enough start, then nobody had
time to improve.

> 
> Best regards,
> Bernhard