From: Manos Pitsidianakis <manos.pitsidianakis@linaro.org>
To: qemu-devel@nongnu.org, "Philippe Mathieu-Daudé " <philmd@linaro.org>
Cc: "Bin Meng" <bmeng.cn@gmail.com>,
"Cé dric Le Goater" <clg@kaod.org>,
"Yanan Wang" <wangyanan55@huawei.com>,
"Marcel Apfelbaum" <marcel.apfelbaum@gmail.com>,
"Eduardo Habkost" <eduardo@habkost.net>,
qemu-block@nongnu.org,
"Daniel P . Berrangé " <berrange@redhat.com>,
"Luc Michel" <luc.michel@amd.com>,
"Philippe Mathieu-Daudé " <philmd@linaro.org>
Subject: Re: [PATCH v45 3/3] hw/sd/sdcard: Do not store vendor data on block drive (CMD56)
Date: Wed, 03 Jul 2024 15:24:05 +0300 [thread overview]
Message-ID: <g1ry6.dru2gk6m73t@linaro.org> (raw)
In-Reply-To: <20240703085907.66775-4-philmd@linaro.org>
On Wed, 03 Jul 2024 11:59, Philippe Mathieu-Daudé <philmd@linaro.org> wrote:
>"General command" (GEN_CMD, CMD56) is described as:
>
> GEN_CMD is the same as the single block read or write
> commands (CMD24 or CMD17). The difference is that [...]
> the data block is not a memory payload data but has a
> vendor specific format and meaning.
>
>Thus this block must not be stored overwriting data block
>on underlying storage drive. Keep it in a dedicated
>'vendor_data[]' array.
>
I am reading the 4.3 spec, and it says:
The bus transaction of the GEN_CMD is the same as the single block
read or write commands (CMD24 or CMD17). The difference is that the
argument denotes the direction of the data transfer (rather than the
address) and the data block is not a memory payload data but has a
vendor specific format and meaning.
The vendor here (qemu) does not support any functionality with CMD56. I
think the correct approach would be to read zeros and discard writes,
without storing anything and without changing data_offset (which is for
`data` buffer)
What do you think?
>Signed-off-by: Philippe Mathieu-Daudé <philmd@linaro.org>
>---
>v43: Do not re-use VMSTATE_UNUSED_V (danpb)
>v44: Use subsection (Luc)
>v45: Remove APP_READ_BLOCK/APP_WRITE_BLOCK macros
>---
> hw/sd/sd.c | 29 +++++++++++++++++++----------
> 1 file changed, 19 insertions(+), 10 deletions(-)
>
>diff --git a/hw/sd/sd.c b/hw/sd/sd.c
>index a08a452d81..5d58937dd4 100644
>--- a/hw/sd/sd.c
>+++ b/hw/sd/sd.c
>@@ -153,6 +153,8 @@ struct SDState {
> uint32_t data_offset;
> size_t data_size;
> uint8_t data[512];
>+ uint8_t vendor_data[512];
>+
> qemu_irq readonly_cb;
> qemu_irq inserted_cb;
> QEMUTimer *ocr_power_timer;
>@@ -719,6 +721,7 @@ static void sd_reset(DeviceState *dev)
> sd->wp_switch = sd->blk ? !blk_is_writable(sd->blk) : false;
> sd->wp_group_bits = sect;
> sd->wp_group_bmap = bitmap_new(sd->wp_group_bits);
>+ memset(sd->vendor_data, 0xec, sizeof(sd->vendor_data));
> memset(sd->function_group, 0, sizeof(sd->function_group));
> sd->erase_start = INVALID_ADDRESS;
> sd->erase_end = INVALID_ADDRESS;
>@@ -793,6 +796,16 @@ static const VMStateDescription sd_ocr_vmstate = {
> },
> };
>
>+static const VMStateDescription sd_vendordata_vmstate = {
>+ .name = "sd-card/vendor_data-state",
>+ .version_id = 1,
>+ .minimum_version_id = 1,
>+ .fields = (const VMStateField[]) {
>+ VMSTATE_UINT8_ARRAY(vendor_data, SDState, 512),
>+ VMSTATE_END_OF_LIST()
>+ },
>+};
>+
> static int sd_vmstate_pre_load(void *opaque)
> {
> SDState *sd = opaque;
>@@ -840,6 +853,7 @@ static const VMStateDescription sd_vmstate = {
> },
> .subsections = (const VMStateDescription * const []) {
> &sd_ocr_vmstate,
>+ &sd_vendordata_vmstate,
> NULL
> },
> };
>@@ -902,9 +916,6 @@ static void sd_blk_write(SDState *sd, uint64_t addr, uint32_t len)
> }
> }
>
>-#define APP_READ_BLOCK(a, len) memset(sd->data, 0xec, len)
>-#define APP_WRITE_BLOCK(a, len)
>-
> static void sd_erase(SDState *sd)
> {
> uint64_t erase_start = sd->erase_start;
>@@ -2187,9 +2198,8 @@ void sd_write_byte(SDState *sd, uint8_t value)
> break;
>
> case 56: /* CMD56: GEN_CMD */
>- sd->data[sd->data_offset ++] = value;
>- if (sd->data_offset >= sd->blk_len) {
>- APP_WRITE_BLOCK(sd->data_start, sd->data_offset);
>+ sd->vendor_data[sd->data_offset++] = value;
>+ if (sd->data_offset >= sizeof(sd->vendor_data)) {
> sd->state = sd_transfer_state;
> }
> break;
>@@ -2261,12 +2271,11 @@ uint8_t sd_read_byte(SDState *sd)
> break;
>
> case 56: /* CMD56: GEN_CMD */
>- if (sd->data_offset == 0)
>- APP_READ_BLOCK(sd->data_start, sd->blk_len);
>- ret = sd->data[sd->data_offset ++];
>+ ret = sd->vendor_data[sd->data_offset++];
>
>- if (sd->data_offset >= sd->blk_len)
>+ if (sd->data_offset >= sizeof(sd->vendor_data)) {
> sd->state = sd_transfer_state;
>+ }
> break;
>
> default:
>--
>2.41.0
>
>
next prev parent reply other threads:[~2024-07-03 12:28 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-03 8:59 [PATCH v45 0/3] hw/sd/sdcard: Cleanups before adding eMMC support Philippe Mathieu-Daudé
2024-07-03 8:59 ` [PATCH v45 1/3] hw/sd/sdcard: Remove leftover comment about removed 'spi' Property Philippe Mathieu-Daudé
2024-07-03 12:03 ` Manos Pitsidianakis
2024-07-03 8:59 ` [PATCH v45 2/3] hw/sd/sdcard: Use spec v3.01 by default Philippe Mathieu-Daudé
2024-07-03 8:59 ` [PATCH v45 3/3] hw/sd/sdcard: Do not store vendor data on block drive (CMD56) Philippe Mathieu-Daudé
2024-07-03 12:24 ` Manos Pitsidianakis [this message]
2024-07-03 13:17 ` Philippe Mathieu-Daudé
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=g1ry6.dru2gk6m73t@linaro.org \
--to=manos.pitsidianakis@linaro.org \
--cc=berrange@redhat.com \
--cc=bmeng.cn@gmail.com \
--cc=clg@kaod.org \
--cc=eduardo@habkost.net \
--cc=luc.michel@amd.com \
--cc=marcel.apfelbaum@gmail.com \
--cc=philmd@linaro.org \
--cc=qemu-block@nongnu.org \
--cc=qemu-devel@nongnu.org \
--cc=wangyanan55@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).