HI Philippe,
On Mon, Jul 6, 2026 at 3:50 PM Philippe Mathieu-Daudé
<[email protected]> wrote:
>
> Hi Bin,
>
> On 30/6/26 15:57, Bin Meng wrote:
> > The m25p80 model uses s->needed_bytes to track how many bytes a
> > controller must send after an opcode before the flash model can enter
> > the data phase. For address-bearing commands this includes the address
> > bytes. For fast-read commands it also includes the dummy phase.
> >
> > The tricky part is that flash datasheets describe the dummy phase in
> > clock cycles, while the QEMU SSI interface advances the flash model one
> > transferred byte at a time. The dummy clock count therefore has to be
> > converted to the number of SSI bytes that the controller will actually
> > emit.
> >
> > Some controllers have drivers that push these dummy bytes into a FIFO.
> > Other controllers are programmed with a dummy-cycle count and generate
> > the clocks themselves. The flash model still has to use the same byte
> > count that a FIFO-style controller or the Linux spi-mem layer would use,
> > otherwise the model waits too long and drops the first data bytes.
> >
> > Let's fix the inconsistency from the flash side first. We start from an
> > easy one, the Winbond flashes.
> >
> > Per the Windbond W25Q256JV datasheet [1] instrunction set table
>
> "instruction"
>
> > (chapter 8.1.2, 8.1.3, 8.1.4, 8.1.5), fix the wrong number of
> > dummy bytes needed for fast read commands.
> >
> > [1]
> > https://www.winbond.com/resource-files/w25q256jv%20spi%20revb%2009202016.pdf
> >
> > Fixes: fe8477052831 ("m25p80: Fix QIOR/DIOR handling for Winbond")
> > Fixes: 3830c7a460b8 ("m25p80: Fix WINBOND fast read command handling")
> > Fixes: cf6f1efe0b57 ("m25p80: Fast read commands family changes")
> > Signed-off-by: Bin Meng <[email protected]>
> > ---
> >
> > hw/block/m25p80.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c
> > index 4a4cda6602..59ecb32c0a 100644
> > --- a/hw/block/m25p80.c
> > +++ b/hw/block/m25p80.c
> > @@ -1004,7 +1004,7 @@ static void decode_fast_read_cmd(Flash *s)
> > s->needed_bytes += 1;
> > break;
> > case MAN_WINBOND:
> > - s->needed_bytes += 8;
> > + s->needed_bytes += 1;
>
> hw/block/m25p80.c-1224- case FAST_READ:
> hw/block/m25p80.c-1225- case FAST_READ4:
> hw/block/m25p80.c:1226: decode_fast_read_cmd(s);
>
> This method is handling 2 distinct commands. Should we pass the
> address count by argument? (IIUC that alters the dummy clock count)
>
Per the datasheet, the only difference is 3-byte address vs. 4-byte
address. The number of dummy cycles are the same.
> > break;
> > case MAN_NUMONYX:
> > s->needed_bytes += numonyx_extract_cfg_num_dummies(s);
> > @@ -1099,7 +1099,7 @@ static void decode_qio_read_cmd(Flash *s)
> > switch (get_man(s)) {
> > case MAN_WINBOND:
> > s->needed_bytes += WINBOND_CONTINUOUS_READ_MODE_CMD_LEN;
> > - s->needed_bytes += 4;
> > + s->needed_bytes += 2;
>
> Ditto:
>
> hw/block/m25p80.c-1257- case QIOR:
> hw/block/m25p80.c-1258- case QIOR4:
>
> > break;
> > case MAN_SPANSION:
> > s->needed_bytes += SPANSION_CONTINUOUS_READ_MODE_CMD_LEN;
>
Regards,
Bin
