| Message ID | 20180607180641.874-8-f4bug@amsat.org |
|---|---|
| State | New |
| Headers | show |
| Series | sdcard: cleanup the SD_SPEC version | expand |
On 7 June 2018 at 19:06, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > Due to physical restriction in SPI mode the maximum transfer > speed is limited. All the extensions added after Spec v3 are > simply not supported in SPI mode: You say here that SPI mode doesn't support extensions added "after spec v3"... > 7.1 Introduction > > The SPI mode consists of a secondary communication protocol > that is offered by Flash-based SD Memory Cards. This mode is > a subset of the SD Memory Card protocol, designed to communicate > with a SPI channel, commonly found in Motorola's (and lately a > few other vendors') microcontrollers. The interface is selected > during the first reset command after power up (CMD0) and cannot > be changed once the part is powered on. > The SPI standard defines the physical link only, and not the > complete data transfer protocol. The SD Memory Card SPI > implementation uses a subset of the SD Memory Card protocol and > command set. The advantage of the SPI mode is the capability of > using an off-the-shelf host, hence reducing the design-in effort > to minimum. The disadvantage is the loss of performance of the > SPI mode versus SD mode (e.g. Single data line and hardware CS > signal per card). > The commands and functions in SD mode defined after the Version > 2.00 are not supported in SPI mode. ...but here quote the spec which says that commands defined after version 2.00 are not supported in SPI mode... and then the patch itself enforces spec 1.10, rather than 2. So I'm confused. > The card may respond to the > commands and functions even if the card is in SPI mode but host > should not use them in SPI mode. > > Some firmwares use the CMD8 in SPI mode to poll which Spec version > the SD card supports. > > 7.2.1 Mode Selection and Initialization (SPI mode) > > The SD Card is powered up in the SD mode. It will enter SPI mode > if the CS signal is asserted (negative) during the reception of > the reset command (CMD0). If the card recognizes that the SD mode > is required it will not respond to the command and remain in the > SD mode. If SPI mode is required, the card will switch to SPI and > respond with the SPI mode R1 response. > The only way to return to the SD mode is by entering the power > cycle. In SPI mode, the SD Card protocol state machine in SD mode > is not observed. All the SD Card commands supported in SPI mode > are always available. [...] > If the card indicates an illegal command, the card is legacy and > does not support CMD8. If the card supports CMD8 and can operate > on the supplied voltage, the response echoes back the supply > voltage and the check pattern that were set in the command > argument. > > The NuttX RTOS use it too: > > /* Check for SDHC Version 2.x. CMD 8 is reserved on SD version 1.0 and > * MMC. > */ > finfo("Send CMD8\n"); > result = mmcsd_sendcmd(slot, &g_cmd8, 0x1aa); > if (result == MMCSD_SPIR1_IDLESTATE) > ... > /* Check for SDC version 1.x or MMC */ > else > ... > > See https://bitbucket.org/nuttx/nuttx/src/nuttx-7.25/drivers/mmcsd/mmcsd_spi.c?mmcsd_spi.c-1645#mmcsd_spi.c-1645 This seems reasonable guest behaviour, and it's what the spec says to do. Why do we need to enforce 1.10 to get things to work? thanks -- PMM
diff --git a/hw/sd/ssi-sd.c b/hw/sd/ssi-sd.c index 96542ecd62..82470a12e2 100644 --- a/hw/sd/ssi-sd.c +++ b/hw/sd/ssi-sd.c @@ -252,6 +252,8 @@ static void ssi_sd_realize(SSISlave *d, Error **errp) /* FIXME use a qdev drive property instead of drive_get_next() */ dinfo = drive_get_next(IF_SD); carddev = qdev_create(&s->sdbus.qbus, TYPE_SD_CARD); + object_property_set_uint(OBJECT(carddev), + SD_PHY_SPECv1_10_VERS, "spec_version", &err); if (dinfo) { qdev_prop_set_drive(carddev, "drive", blk_by_legacy_dinfo(dinfo), &err); }
Due to physical restriction in SPI mode the maximum transfer speed is limited. All the extensions added after Spec v3 are simply not supported in SPI mode: 7.1 Introduction The SPI mode consists of a secondary communication protocol that is offered by Flash-based SD Memory Cards. This mode is a subset of the SD Memory Card protocol, designed to communicate with a SPI channel, commonly found in Motorola's (and lately a few other vendors') microcontrollers. The interface is selected during the first reset command after power up (CMD0) and cannot be changed once the part is powered on. The SPI standard defines the physical link only, and not the complete data transfer protocol. The SD Memory Card SPI implementation uses a subset of the SD Memory Card protocol and command set. The advantage of the SPI mode is the capability of using an off-the-shelf host, hence reducing the design-in effort to minimum. The disadvantage is the loss of performance of the SPI mode versus SD mode (e.g. Single data line and hardware CS signal per card). The commands and functions in SD mode defined after the Version 2.00 are not supported in SPI mode. The card may respond to the commands and functions even if the card is in SPI mode but host should not use them in SPI mode. Some firmwares use the CMD8 in SPI mode to poll which Spec version the SD card supports. 7.2.1 Mode Selection and Initialization (SPI mode) The SD Card is powered up in the SD mode. It will enter SPI mode if the CS signal is asserted (negative) during the reception of the reset command (CMD0). If the card recognizes that the SD mode is required it will not respond to the command and remain in the SD mode. If SPI mode is required, the card will switch to SPI and respond with the SPI mode R1 response. The only way to return to the SD mode is by entering the power cycle. In SPI mode, the SD Card protocol state machine in SD mode is not observed. All the SD Card commands supported in SPI mode are always available. [...] If the card indicates an illegal command, the card is legacy and does not support CMD8. If the card supports CMD8 and can operate on the supplied voltage, the response echoes back the supply voltage and the check pattern that were set in the command argument. The NuttX RTOS use it too: /* Check for SDHC Version 2.x. CMD 8 is reserved on SD version 1.0 and * MMC. */ finfo("Send CMD8\n"); result = mmcsd_sendcmd(slot, &g_cmd8, 0x1aa); if (result == MMCSD_SPIR1_IDLESTATE) ... /* Check for SDC version 1.x or MMC */ else ... See https://bitbucket.org/nuttx/nuttx/src/nuttx-7.25/drivers/mmcsd/mmcsd_spi.c?mmcsd_spi.c-1645#mmcsd_spi.c-1645 The Stellaris LM3S6965EVB board is the only model using SD cards in SPI mode. The firmware found to work with the board expect the card to be following Spec v1 to work, and is the only one stressing the v1 code path of the SD card model. Thus it seems clever to restrict SPI connected cards to use Spec v1. Signed-off-by: Philippe Mathieu-Daudé <f4bug@amsat.org> --- This change would be better in the lm3s6965evb_init() rathar than here in ssi-sd. As suggested by Peter and Thomas here: http://lists.nongnu.org/archive/html/qemu-devel/2018-05/msg06616.html We can use -device sd-card,spec_version=1 to avoid this change. $ arm-softmmu/qemu-system-arm \ -M lm3s6965evb -nodefaults \ -serial stdio \ -kernel sd_card.bin \ -drive file=sdcard.img,id=mycard,if=none \ -device sd-card,spi=true,spec_version=1,drive=mycard qemu-system-arm: warning: nic stellaris_enet.0 has no peer SD Card Example Program Type 'help' for help. /> ls Open listing ----A 2012/04/25 17:44 12 README.TXT 1 File(s), 12 bytes total 0 Dir(s), 61182K bytes free /> cat README.TXT Hello World /> Even if there are still 2 cards... (qemu) info qtree bus: main-system-bus type System dev: pl022, id "" gpio-out "sysbus-irq" 1 mmio 0000000040008000/0000000000001000 bus: ssi type SSI dev: ssd0323, id "" gpio-in "" 1 gpio-in "ssi-gpio-cs" 1 dev: ssi-sd, id "" gpio-in "ssi-gpio-cs" 1 bus: sd-bus type sd-bus dev: sd-card, id "" spec_version = 1 (0x1) drive = "mycard" spi = true dev: sd-card, id "" spec_version = 2 (0x2) drive = "" spi = true hw/sd/ssi-sd.c | 2 ++ 1 file changed, 2 insertions(+)