aboutsummaryrefslogtreecommitdiff
path: root/hw/sd
AgeCommit message (Collapse)Author
2021-05-02hw: Do not include qemu/log.h if it is not necessaryThomas Huth
Many files include qemu/log.h without needing it. Remove the superfluous include statements. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210328054833.2351597-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-05-02hw: Do not include hw/irq.h if it is not necessaryThomas Huth
Many files include hw/irq.h without needing it. Remove the superfluous include statements. Signed-off-by: Thomas Huth <thuth@redhat.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210327050236.2232347-1-thuth@redhat.com> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-03-22hw/sd: sdhci: Reset the data pointer of s->fifo_buffer[] when a different ↵Bin Meng
block size is programmed If the block size is programmed to a different value from the previous one, reset the data pointer of s->fifo_buffer[] so that s->fifo_buffer[] can be filled in using the new block size in the next transfer. With this fix, the following reproducer: outl 0xcf8 0x80001010 outl 0xcfc 0xe0000000 outl 0xcf8 0x80001001 outl 0xcfc 0x06000000 write 0xe000002c 0x1 0x05 write 0xe0000005 0x1 0x02 write 0xe0000007 0x1 0x01 write 0xe0000028 0x1 0x10 write 0x0 0x1 0x23 write 0x2 0x1 0x08 write 0xe000000c 0x1 0x01 write 0xe000000e 0x1 0x20 write 0xe000000f 0x1 0x00 write 0xe000000c 0x1 0x32 write 0xe0000004 0x2 0x0200 write 0xe0000028 0x1 0x00 write 0xe0000003 0x1 0x40 cannot be reproduced with the following QEMU command line: $ qemu-system-x86_64 -nographic -machine accel=qtest -m 512M \ -nodefaults -device sdhci-pci,sd-spec-version=3 \ -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \ -device sd-card,drive=mydrive -qtest stdio Cc: qemu-stable@nongnu.org Fixes: CVE-2020-17380 Fixes: CVE-2020-25085 Fixes: CVE-2021-3409 Fixes: d7dfca0807a0 ("hw/sdhci: introduce standard SD host controller") Reported-by: Alexander Bulekov <alxndr@bu.edu> Reported-by: Cornelius Aschermann (Ruhr-Universität Bochum) Reported-by: Sergej Schumilo (Ruhr-Universität Bochum) Reported-by: Simon Wörner (Ruhr-Universität Bochum) Buglink: https://bugs.launchpad.net/qemu/+bug/1892960 Buglink: https://bugs.launchpad.net/qemu/+bug/1909418 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146 Tested-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20210303122639.20004-6-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-03-22hw/sd: sdhci: Limit block size only when SDHC_BLKSIZE register is writableBin Meng
The codes to limit the maximum block size is only necessary when SDHC_BLKSIZE register is writable. Tested-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20210303122639.20004-5-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-03-22hw/sd: sdhci: Correctly set the controller status for ADMABin Meng
When an ADMA transfer is started, the codes forget to set the controller status to indicate a transfer is in progress. With this fix, the following 2 reproducers: https://paste.debian.net/plain/1185136 https://paste.debian.net/plain/1185141 cannot be reproduced with the following QEMU command line: $ qemu-system-x86_64 -nographic -machine accel=qtest -m 512M \ -nodefaults -device sdhci-pci,sd-spec-version=3 \ -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \ -device sd-card,drive=mydrive -qtest stdio Cc: qemu-stable@nongnu.org Fixes: CVE-2020-17380 Fixes: CVE-2020-25085 Fixes: CVE-2021-3409 Fixes: d7dfca0807a0 ("hw/sdhci: introduce standard SD host controller") Reported-by: Alexander Bulekov <alxndr@bu.edu> Reported-by: Cornelius Aschermann (Ruhr-Universität Bochum) Reported-by: Sergej Schumilo (Ruhr-Universität Bochum) Reported-by: Simon Wörner (Ruhr-Universität Bochum) Buglink: https://bugs.launchpad.net/qemu/+bug/1892960 Buglink: https://bugs.launchpad.net/qemu/+bug/1909418 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146 Tested-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20210303122639.20004-4-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-03-22hw/sd: sdhci: Don't write to SDHC_SYSAD register when transfer is in progressBin Meng
Per "SD Host Controller Standard Specification Version 7.00" chapter 2.2.1 SDMA System Address Register: This register can be accessed only if no transaction is executing (i.e., after a transaction has stopped). With this fix, the following reproducer: outl 0xcf8 0x80001010 outl 0xcfc 0xfbefff00 outl 0xcf8 0x80001001 outl 0xcfc 0x06000000 write 0xfbefff2c 0x1 0x05 write 0xfbefff0f 0x1 0x37 write 0xfbefff0a 0x1 0x01 write 0xfbefff0f 0x1 0x29 write 0xfbefff0f 0x1 0x02 write 0xfbefff0f 0x1 0x03 write 0xfbefff04 0x1 0x01 write 0xfbefff05 0x1 0x01 write 0xfbefff07 0x1 0x02 write 0xfbefff0c 0x1 0x33 write 0xfbefff0e 0x1 0x20 write 0xfbefff0f 0x1 0x00 write 0xfbefff2a 0x1 0x01 write 0xfbefff0c 0x1 0x00 write 0xfbefff03 0x1 0x00 write 0xfbefff05 0x1 0x00 write 0xfbefff2a 0x1 0x02 write 0xfbefff0c 0x1 0x32 write 0xfbefff01 0x1 0x01 write 0xfbefff02 0x1 0x01 write 0xfbefff03 0x1 0x01 cannot be reproduced with the following QEMU command line: $ qemu-system-x86_64 -nographic -machine accel=qtest -m 512M \ -nodefaults -device sdhci-pci,sd-spec-version=3 \ -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \ -device sd-card,drive=mydrive -qtest stdio Cc: qemu-stable@nongnu.org Fixes: CVE-2020-17380 Fixes: CVE-2020-25085 Fixes: CVE-2021-3409 Fixes: d7dfca0807a0 ("hw/sdhci: introduce standard SD host controller") Reported-by: Alexander Bulekov <alxndr@bu.edu> Reported-by: Cornelius Aschermann (Ruhr-Universität Bochum) Reported-by: Sergej Schumilo (Ruhr-Universität Bochum) Reported-by: Simon Wörner (Ruhr-Universität Bochum) Buglink: https://bugs.launchpad.net/qemu/+bug/1892960 Buglink: https://bugs.launchpad.net/qemu/+bug/1909418 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146 Tested-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20210303122639.20004-3-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-03-22hw/sd: sdhci: Don't transfer any data when command time outBin Meng
At the end of sdhci_send_command(), it starts a data transfer if the command register indicates data is associated. But the data transfer should only be initiated when the command execution has succeeded. With this fix, the following reproducer: outl 0xcf8 0x80001810 outl 0xcfc 0xe1068000 outl 0xcf8 0x80001804 outw 0xcfc 0x7 write 0xe106802c 0x1 0x0f write 0xe1068004 0xc 0x2801d10101fffffbff28a384 write 0xe106800c 0x1f 0x9dacbbcad9e8f7061524334251606f7e8d9cabbac9d8e7f60514233241505f write 0xe1068003 0x28 0x80d000251480d000252280d000253080d000253e80d000254c80d000255a80d000256880d0002576 write 0xe1068003 0x1 0xfe cannot be reproduced with the following QEMU command line: $ qemu-system-x86_64 -nographic -M pc-q35-5.0 \ -device sdhci-pci,sd-spec-version=3 \ -drive if=sd,index=0,file=null-co://,format=raw,id=mydrive \ -device sd-card,drive=mydrive \ -monitor none -serial none -qtest stdio Cc: qemu-stable@nongnu.org Fixes: CVE-2020-17380 Fixes: CVE-2020-25085 Fixes: CVE-2021-3409 Fixes: d7dfca0807a0 ("hw/sdhci: introduce standard SD host controller") Reported-by: Alexander Bulekov <alxndr@bu.edu> Reported-by: Cornelius Aschermann (Ruhr-Universität Bochum) Reported-by: Sergej Schumilo (Ruhr-Universität Bochum) Reported-by: Simon Wörner (Ruhr-Universität Bochum) Buglink: https://bugs.launchpad.net/qemu/+bug/1892960 Buglink: https://bugs.launchpad.net/qemu/+bug/1909418 Buglink: https://bugzilla.redhat.com/show_bug.cgi?id=1928146 Acked-by: Alistair Francis <alistair.francis@wdc.com> Tested-by: Alexander Bulekov <alxndr@bu.edu> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Message-Id: <20210303122639.20004-2-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-03-22hw/sd: sd: Actually perform the erase operationBin Meng
At present the sd_erase() does not erase the requested range of card data to 0xFFs. Let's make the erase operation actually happen. Signed-off-by: Bin Meng <bin.meng@windriver.com> Message-Id: <1613811493-58815-1-git-send-email-bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-03-22hw/sd: sd: Fix build error when DEBUG_SD is onBin Meng
"qemu-common.h" should be included to provide the forward declaration of qemu_hexdump() when DEBUG_SD is on. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210228050609.24779-1-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-21Merge remote-tracking branch ↵Peter Maydell
'remotes/vivier2/tags/trivial-branch-for-6.0-pull-request' into staging Pull request trivial patches 20210220 # gpg: Signature made Sat 20 Feb 2021 12:34:21 GMT # gpg: using RSA key CD2F75DDC8E3A4DC2E4F5173F30C38BD3F2FBE3C # gpg: issuer "laurent@vivier.eu" # gpg: Good signature from "Laurent Vivier <lvivier@redhat.com>" [full] # gpg: aka "Laurent Vivier <laurent@vivier.eu>" [full] # gpg: aka "Laurent Vivier (Red Hat) <lvivier@redhat.com>" [full] # Primary key fingerprint: CD2F 75DD C8E3 A4DC 2E4F 5173 F30C 38BD 3F2F BE3C * remotes/vivier2/tags/trivial-branch-for-6.0-pull-request: MAINTAINERS: Fix default-configs/ entries target/avr/cpu: Use device_class_set_parent_realize() hw/scsi/megasas: Remove pointless parenthesis u2f-passthru: put it into the 'misc' category tpm: put some tpm devices into the correct category nvdimm: put it into the 'storage' category vmmouse: put it into the 'input' category virtio-pmem: put it into the 'storage' category MAINTAINERS: add my github tree URL Fix SPDX-License-Identifier typos hw/block/fdc: Remove the check_media_rate property hw/i386/xen: Remove dead code Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
2021-02-20Fix SPDX-License-Identifier typosRyan Finnie
Several SPDX headers contain "SPDX-License-Identifer" (note the missing "i" before "er"); fix these typos. Signed-off-by: Ryan Finnie <ryan@finnie.org> Cc: qemu-trivial@nongnu.org Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210201200147.211914-1-ryan@finnie.org> Signed-off-by: Laurent Vivier <laurent@vivier.eu>
2021-02-20hw/sd: sdhci: Simplify updating s->prnsts in sdhci_sdma_transfer_multi_blocks()Bin Meng
s->prnsts is updated in both branches of the if () else () statement. Move the common bits outside so that it is cleaner. Signed-off-by: Bin Meng <bmeng.cn@gmail.com> Tested-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Alexander Bulekov <alxndr@bu.edu> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <1613447214-81951-5-git-send-email-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: sd: Bypass the RCA check for CMD13 in SPI modeBin Meng
Unlike SD mode, when SD card is working in SPI mode, the argument of CMD13 is stuff bits. Hence we should bypass the RCA check. See "Physical Layer Specification Version 8.00", chapter 7.3.1.3 Detailed Command Description (SPI mode): "The card shall ignore stuff bits and reserved bits in an argument" and Table 7-3 Commands and Arguments (SPI mode): "CMD13 Argument [31:0] stuff bits" Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210216150225.27996-9-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: sd: Skip write protect groups check in CMD24/25 for high capacity cardsBin Meng
High capacity cards don't support write protection hence we should not perform the write protect groups check in CMD24/25 for them. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210216150225.27996-8-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: sd: Skip write protect groups check in sd_erase() for high capacity cardsBin Meng
High capacity cards don't support write protection hence we should not perform the write protect groups check in sd_erase() for them. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210216150225.27996-6-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: sd: Move the sd_block_{read, write} and macros aheadBin Meng
These APIs and macros may be referenced by functions that are currently before them. Move them ahead a little bit. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210216150225.27996-5-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: sd: Fix CMD30 response typeBin Meng
Per the "Physical Layer Specification Version 8.00", table 4-26 (SD mode) and table 7-3 (SPI mode) command descriptions, CMD30 response type is R1, not R1b. Fixes: a1bb27b1e98a ("SD card emulation initial implementation") Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210216150225.27996-4-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: sd: Only SDSC cards support CMD28/29/30Bin Meng
Per the "Physical Layer Specification Version 8.00", table 4-26 (SD mode) and table 7-3 (SPI mode) command descriptions, the following commands: - CMD28 (SET_WRITE_PROT) - CMD29 (CLR_WRITE_PROT) - CMD30 (SEND_WRITE_PROT) are only supported by SDSC cards. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210216150225.27996-3-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: sd: Fix address check in sd_erase()Bin Meng
For high capacity memory cards, the erase start address and end address are multiplied by 512, but the address check is still based on the original block number in sd->erase_{start, end}. Fixes: 1bd6fd8ed593 ("hw/sd/sdcard: Do not attempt to erase out of range addresses") Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210216150225.27996-2-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: ssi-sd: Handle the rest commands with R1b response typeBin Meng
Besides CMD12, the following command's reponse type is R1b: - SET_WRITE_PROT (CMD28) - CLR_WRITE_PROT (CMD29) - ERASE (CMD38) Reuse the same s->stopping to indicate a R1b reponse is needed. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210128063035.15674-10-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: ssi-sd: Fix STOP_TRANSMISSION (CMD12) responseBin Meng
CMD12's response type is R1b, which is basically a R1 plus optional addition of the busy signal token that can be any number of bytes. A zero value indicates card is busy and a non-zero value indicates the card is ready for the next command. Current implementation sends the busy signal token without sending the R1 first. This does not break the U-Boot/Linux mmc_spi driver, but it does not make the VxWorks driver happy. Move the testing logic of s->stopping in the SSI_SD_RESPONSE state a bit later, after the first byte of the card reponse is sent out, to conform with the spec. After the busy signal token is sent, the state should be transferred to SSI_SD_CMD. Fixes: 775616c3ae8c ("Partial SD card SPI mode support") Signed-off-by: Bin Meng <bin.meng@windriver.com> Message-Id: <20210128063035.15674-9-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: ssi-sd: Fix SEND_IF_COND (CMD8) responseBin Meng
The SEND_IF_COND command (CMD8) response is of format R7, but current code returns R1 for CMD8. Fix it. Fixes: 775616c3ae8c ("Partial SD card SPI mode support") Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210128063035.15674-8-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: ssi-sd: Support multiple block writeBin Meng
For a multiple block write operation, each block begins with a multi write start token. Unlike the SD mode that the multiple block write ends when receiving a STOP_TRAN command (CMD12), a special stop tran token is used to signal the card. Emulating this by manually sending a CMD12 to the SD card core, to bring it out of the receiving data state. Signed-off-by: Bin Meng <bin.meng@windriver.com> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210128063035.15674-7-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: ssi-sd: Support single block writeBin Meng
Add 2 more states for the block write operation. The SPI host needs to send a data start token to start the transfer, and the data block written to the card will be acknowledged by a data response token. Signed-off-by: Bin Meng <bin.meng@windriver.com> [PMD: Change VMState version id 6 -> 7] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210128063035.15674-6-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: Introduce receive_ready() callbackBin Meng
At present there is a data_ready() callback for the SD data read path. Let's add a receive_ready() for the SD data write path. Signed-off-by: Bin Meng <bin.meng@windriver.com> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210128063035.15674-5-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: sd: Allow single/multiple block write for SPI modeBin Meng
At present the single/multiple block write in SPI mode is blocked by sd_normal_command(). Remove the limitation. Signed-off-by: Bin Meng <bin.meng@windriver.com> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210128063035.15674-4-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: sd: Remove duplicated codes in single/multiple block read/writeBin Meng
The single block read (CMD17) codes are the same as the multiple block read (CMD18). Merge them into one. The same applies to single block write (CMD24) and multiple block write (CMD25). Signed-off-by: Bin Meng <bin.meng@windriver.com> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210128063035.15674-3-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-02-20hw/sd: ssi-sd: Support multiple block readBin Meng
In the case of a multiple block read operation every transferred block has its suffix of CRC16. Update the state machine logic to handle multiple block read. Signed-off-by: Bin Meng <bin.meng@windriver.com> [PMD: Change VMState version id 5 -> 6] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Acked-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20210128063035.15674-2-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-27block: Separate blk_is_writable() and blk_supports_write_perm()Kevin Wolf
Currently, blk_is_read_only() tells whether a given BlockBackend can only be used in read-only mode because its root node is read-only. Some callers actually try to answer a slightly different question: Is the BlockBackend configured to be writable, by taking write permissions on the root node? This can differ, for example, for CD-ROM devices which don't take write permissions, but may be backed by a writable image file. scsi-cd allows write requests to the drive if blk_is_read_only() returns false. However, the write request will immediately run into an assertion failure because the write permission is missing. This patch introduces separate functions for both questions. blk_supports_write_perm() answers the question whether the block node/image file can support writable devices, whereas blk_is_writable() tells whether the BlockBackend is currently configured to be writable. All calls of blk_is_read_only() are converted to one of the two new functions. Fixes: https://bugs.launchpad.net/bugs/1906693 Cc: qemu-stable@nongnu.org Signed-off-by: Kevin Wolf <kwolf@redhat.com> Message-Id: <20210118123448.307825-2-kwolf@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Max Reitz <mreitz@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2021-01-24hw/sd: ssi-sd: Use macros for the dummy value and tokens in the transferBin Meng
At present the codes use hardcoded numbers (0xff/0xfe) for the dummy value and block start token. Replace them with macros. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210123104016.17485-12-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-24hw/sd: ssi-sd: Fix the wrong command index for STOP_TRANSMISSIONBin Meng
This fixes the wrong command index for STOP_TRANSMISSION, the required command to interrupt the multiple block read command, in the old codes. It should be CMD12 (0x4c), not CMD13 (0x4d). Fixes: 775616c3ae8c ("Partial SD card SPI mode support") Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210123104016.17485-10-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-24hw/sd: ssi-sd: Add a state representing NacBin Meng
Per the "Physical Layer Specification Version 8.00" chapter 7.5.2, "Data Read", there is a minimum 8 clock cycles (Nac) after the card response and before data block shows up on the data out line. This applies to both single and multiple block read operations. Current implementation of single block read already satisfies the timing requirement as in the RESPONSE state after all responses are transferred the state remains unchanged. In the next 8 clock cycles it jumps to DATA_START state if data is ready. However we need an explicit state when expanding our support to multiple block read in the future. Let's add a new state PREP_DATA explicitly in the ssi-sd state machine to represent Nac. Note we don't change the single block read state machine to let it jump from RESPONSE state to DATA_START state as that effectively generates a 16 clock cycles Nac, which might not be safe. As the spec says the maximum Nac shall be calculated from several fields encoded in the CSD register, we don't want to bother updating CSD to ensure our Nac is within range to complicate things. Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210123104016.17485-9-bmeng.cn@gmail.com> [PMD: Change VMState version id 4 -> 5] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-24hw/sd: ssi-sd: Suffix a data block with CRC16Bin Meng
Per the SD spec, a valid data block is suffixed with a 16-bit CRC generated by the standard CCITT polynomial x16+x12+x5+1. This part is currently missing in the ssi-sd state machine. Without it, all data block transfer fails in guest software because the expected CRC16 is missing on the data out line. Fixes: 775616c3ae8c ("Partial SD card SPI mode support") Signed-off-by: Bin Meng <bin.meng@windriver.com> Acked-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210123104016.17485-8-bmeng.cn@gmail.com> [PMD: Change VMState version id 3 -> 4, check s->mode validity in post_load()] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-24hw/sd: sd: Drop sd_crc16()Bin Meng
commit f6fb1f9b319f ("sdcard: Correct CRC16 offset in sd_function_switch()") changed the 16-bit CRC to be stored at offset 64. In fact, this CRC calculation is completely wrong. From the original codes, it wants to calculate the CRC16 of the first 64 bytes of sd->data[], however passing 64 as the `width` to sd_crc16() actually counts 256 bytes starting from the `message` for the CRC16 calculation, which is not what we want. Besides that, it seems existing sd_crc16() algorithm does not match the SD spec, which says CRC16 is the CCITT one but the calculation does not produce expected result. It turns out the CRC16 was never transferred outside the sd core, as in sd_read_byte() we see: if (sd->data_offset >= 64) sd->state = sd_transfer_state; Given above reasons, let's drop it. Signed-off-by: Bin Meng <bin.meng@windriver.com> Tested-by: Pragnesh Patel <pragnesh.patel@sifive.com> Reviewed-by: Pragnesh Patel <pragnesh.patel@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210123104016.17485-6-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-24hw/sd: sd: Support CMD59 for SPI modeBin Meng
After the card is put into SPI mode, CRC check for all commands including CMD0 will be done according to CMD59 setting. But this command is currently unimplemented. Simply allow the decoding of CMD59, but the CRC remains unchecked. Signed-off-by: Bin Meng <bin.meng@windriver.com> Tested-by: Pragnesh Patel <pragnesh.patel@sifive.com> Reviewed-by: Pragnesh Patel <pragnesh.patel@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210123104016.17485-5-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-24hw/sd: ssi-sd: Fix incorrect card response sequenceBin Meng
Per the "Physical Layer Specification Version 8.00" chapter 7.5.1, "Command/Response", there is a minimum 8 clock cycles (Ncr) before the card response shows up on the data out line. However current implementation jumps directly to the sending response state after all 6 bytes command is received, which is a spec violation. Add a new state PREP_RESP in the ssi-sd state machine to handle it. Fixes: 775616c3ae8c ("Partial SD card SPI mode support") Signed-off-by: Bin Meng <bin.meng@windriver.com> Tested-by: Pragnesh Patel <pragnesh.patel@sifive.com> Reviewed-by: Pragnesh Patel <pragnesh.patel@sifive.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20210123104016.17485-4-bmeng.cn@gmail.com> [PMD: Change VMState version id 2 -> 3] Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2021-01-08Remove superfluous timer_del() callsPeter Maydell
This commit is the result of running the timer-del-timer-free.cocci script on the whole source tree. Signed-off-by: Peter Maydell <peter.maydell@linaro.org> Acked-by: Corey Minyard <cminyard@mvista.com> Acked-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com> Reviewed-by: Richard Henderson <richard.henderson@linaro.org> Message-id: 20201215154107.3255-4-peter.maydell@linaro.org
2020-12-18qdev: Move softmmu properties to qdev-properties-system.hEduardo Habkost
Move the property types and property macros implemented in qdev-properties-system.c to a new qdev-properties-system.h header. Signed-off-by: Eduardo Habkost <ehabkost@redhat.com> Reviewed-by: Igor Mammedov <imammedo@redhat.com> Message-Id: <20201211220529.2290218-16-ehabkost@redhat.com> Signed-off-by: Eduardo Habkost <ehabkost@redhat.com>
2020-12-10hw/ssi: Rename SSI 'slave' as 'peripheral'Philippe Mathieu-Daudé
In order to use inclusive terminology, rename SSI 'slave' as 'peripheral', following the specification resolution: https://www.oshwa.org/a-resolution-to-redefine-spi-signal-names/ Patch created mechanically using: $ sed -i s/SSISlave/SSIPeripheral/ $(git grep -l SSISlave) $ sed -i s/SSI_SLAVE/SSI_PERIPHERAL/ $(git grep -l SSI_SLAVE) $ sed -i s/ssi-slave/ssi-peripheral/ $(git grep -l ssi-slave) $ sed -i s/ssi_slave/ssi_peripheral/ $(git grep -l ssi_slave) $ sed -i s/ssi_create_slave/ssi_create_peripheral/ \ $(git grep -l ssi_create_slave) Then in VMStateDescription vmstate_ssi_peripheral we restored the "SSISlave" migration stream name (to avoid breaking migration). Finally the following files have been manually tweaked: - hw/ssi/pl022.c - hw/ssi/xilinx_spips.c Suggested-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201012124955.3409127-4-f4bug@amsat.org> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
2020-11-17hw/sd: Fix 2 GiB card CSD register valuesBin Meng
Per the SD spec, to indicate a 2 GiB card, BLOCK_LEN shall be 1024 bytes, hence the READ_BL_LEN field in the CSD register shall be 10 instead of 9. This fixes the acceptance test error for the NetBSD 9.0 test of the Orange Pi PC that has an expanded SD card image of 2 GiB size. Fixes: 6d2d4069c47e ("hw/sd: Correct the maximum size of a Standard Capacity SD Memory Card") Reported-by: Niek Linnenbank <nieklinnenbank@gmail.com> Signed-off-by: Bin Meng <bin.meng@windriver.com> Tested-by: Niek Linnenbank <nieklinnenbank@gmail.com> Message-Id: <20201025152357.11865-1-bmeng.cn@gmail.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2020-11-15nomaintainer: Fix Lesser GPL version numberChetan Pant
There is no "version 2" of the "Lesser" General Public License. It is either "GPL version 2.0" or "Lesser GPL version 2.1". This patch replaces all occurrences of "Lesser GPL version 2" with "Lesser GPL version 2.1" in comment section. This patch contains all the files, whose maintainer I could not get from ‘get_maintainer.pl’ script. Signed-off-by: Chetan Pant <chetan4windows@gmail.com> Message-Id: <20201023124424.20177-1-chetan4windows@gmail.com> Reviewed-by: Thomas Huth <thuth@redhat.com> [thuth: Adapted exec.c and qdev-monitor.c to new location] Signed-off-by: Thomas Huth <thuth@redhat.com>
2020-10-26hw/sd/sdcard: Zero out function selection fields before being populatedBin Meng
The function selection fields (399:376) should be zeroed out to prevent leftover from being or'ed into the switch function status data structure. This fixes the boot failure as seen in the acceptance testing on the orangepi target. Fixes: b638627c723a ("hw/sd: Fix incorrect populated function switch status data structure") Reported-by: Michael Roth <mdroth@linux.vnet.ibm.com> Signed-off-by: Bin Meng <bin.meng@windriver.com> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20201024014954.21330-1-bmeng.cn@gmail.com> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
2020-10-26hw/sd/sdcard: Make iolen unsignedPhilippe Mathieu-Daudé
I/O request length can not be negative. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20200630133912.9428-15-f4bug@amsat.org>
2020-10-26hw/sd/sdcard: Constify sd_crc*()'s message argumentPhilippe Mathieu-Daudé
CRC functions don't modify the buffer argument, make it const. Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Message-Id: <20200630133912.9428-14-f4bug@amsat.org>
2020-10-26hw/sd/sdcard: Simplify cmd_valid_while_locked()Philippe Mathieu-Daudé
cmd_valid_while_locked() only needs to read SDRequest->cmd, pass it directly and make it const. Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20200630133912.9428-13-f4bug@amsat.org>
2020-10-26hw/sd/sdcard: Update the SDState documentationPhilippe Mathieu-Daudé
Add more descriptive comments to keep a clear separation between static property vs runtime changeable. Suggested-by: Peter Maydell <peter.maydell@linaro.org> Reviewed-by: Peter Maydell <peter.maydell@linaro.org> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Reviewed-by: Alistair Francis <alistair.francis@wdc.com> Message-Id: <20200630133912.9428-12-f4bug@amsat.org>
2020-10-21hw/sd/sdcard: Assert if accessing an illegal groupPhilippe Mathieu-Daudé
We can not have more group than 'wpgrps_size'. Assert if we are accessing a group above this limit. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201015063824.212980-7-f4bug@amsat.org>
2020-10-21hw/sd/sdcard: Do not attempt to erase out of range addressesPhilippe Mathieu-Daudé
While the Spec v3 is not very clear, v6 states: If the host provides an out of range address as an argument to CMD32 or CMD33, the card shall indicate OUT_OF_RANGE error in R1 (ERX) for CMD38. If an address is out of range, do not attempt to erase it: return R1 with the error bit set. Buglink: https://bugs.launchpad.net/qemu/+bug/1895310 Reported-by: Alexander Bulekov <alxndr@bu.edu> Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201015063824.212980-6-f4bug@amsat.org>
2020-10-21hw/sd/sdcard: Reset both start/end addresses on errorPhilippe Mathieu-Daudé
From the Spec "4.3.5 Erase": The host should adhere to the following command sequence: ERASE_WR_BLK_START, ERASE_WR_BLK_END and ERASE (CMD38). If an erase (CMD38) or address setting (CMD32, 33) command is received out of sequence, the card shall set the ERASE_SEQ_ERROR bit in the status register and reset the whole sequence. Reset both addresses if the ERASE command occured out of sequence (one of the start/end address is not set). Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201015063824.212980-5-f4bug@amsat.org>
2020-10-21hw/sd/sdcard: Do not use legal address '0' for INVALID_ADDRESSPhilippe Mathieu-Daudé
As it is legal to WRITE/ERASE the address/block 0, change the value of this definition to an illegal address: UINT32_MAX. Unfortunately this break the migration stream, so bump the VMState version number. This affects some ARM boards and the SDHCI_PCI device (which is only used for testing). Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> Tested-by: Alexander Bulekov <alxndr@bu.edu> Message-Id: <20201015063824.212980-4-f4bug@amsat.org>