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
