qemu-riscv
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 05/22] hw/sd: sd: Drop sd_crc16()


From: Philippe Mathieu-Daudé
Subject: Re: [PATCH 05/22] hw/sd: sd: Drop sd_crc16()
Date: Thu, 14 Jan 2021 12:51:54 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

On 12/31/20 12:29 PM, Bin Meng wrote:
> From: Bin Meng <bin.meng@windriver.com>
> 
> 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.

Yeah:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg531790.html

> 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 exisitng 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
> transfered outside the sd core,

Typos "existing", "transferred".

Well, I tried by adding tests, see:
https://www.mail-archive.com/qemu-devel@nongnu.org/msg531777.html
(Series:)
https://www.mail-archive.com/qemu-devel@nongnu.org/msg531768.html

> as in sd_read_byte() we see:
> 
>     if (sd->data_offset >= 64)
>         sd->state = sd_transfer_state;
> 
> Given above reaons, let's drop it.
> 
> Signed-off-by: Bin Meng <bin.meng@windriver.com>
> ---
> 
>  hw/sd/sd.c | 18 ------------------
>  1 file changed, 18 deletions(-)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]