Hello,
On 2/6/20 7:32 PM, Guenter Roeck wrote:
> When requesting JEDEC data using the JEDEC_READ command, the Linux kernel
> always requests 6 bytes. The current implementation only returns three
> bytes, and interprets the remaining three bytes as new commands.
> While this does not matter most of the time, it is at the very least
> confusing. To avoid the problem, always report up to 6 bytes of JEDEC
> data. Fill remaining data with 0.
>
> Signed-off-by: Guenter Roeck <[email protected]>
> ---
> v2: Split patch into two parts; improved decription
>
> hw/block/m25p80.c | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> index 5ff8d270c4..53bf63856f 100644
> --- a/hw/block/m25p80.c
> +++ b/hw/block/m25p80.c
> @@ -1040,8 +1040,11 @@ static void decode_new_cmd(Flash *s, uint32_t value)
> for (i = 0; i < s->pi->id_len; i++) {
> s->data[i] = s->pi->id[i];
> }
> + for (; i < SPI_NOR_MAX_ID_LEN; i++) {
> + s->data[i] = 0;
> + }
This is breaking an old firmware (Linux version 2.6.28.9) for a SuperMicro
board :
https://www.supermicro.com/en/products/motherboard/X11SSL-F
which expects the flash ID to repeat. Erik solved the problem with the patch
below and I think it makes sense to wrap around. Anyone knows what should be
the expected behavior ?
Thanks,
C.
diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
index 8227088441..5000930800 100644
--- a/hw/block/m25p80.c
+++ b/hw/block/m25p80.c
@@ -1041,7 +1041,7 @@ static void decode_new_cmd(Flash *s, uint32_t value)
s->data[i] = s->pi->id[i];
}
for (; i < SPI_NOR_MAX_ID_LEN; i++) {
- s->data[i] = 0;
+ s->data[i] = s->pi->id[i % s->pi->id_len];
}
s->len = SPI_NOR_MAX_ID_LEN;
