It’s a board we’re trying to bringup at my current company, we were trying to understand why the hardware was working fine but didn’t under QEMU.
Turns out the logic that was used to determine the timing value was slightly incorrect and was making the flash completely unresponsive under certain conditions early on the boot process. Thanks for adding Cédric! On Thu, Feb 19, 2026 at 21:01 Peter Maydell <[email protected]> wrote: > On Wed, 7 Jan 2026 at 11:30, Joel Bueno <[email protected]> > wrote: > > > > Is there any feedback on this patch series? > > Which board model(s) does this affect? You might have > some luck cc'ing their maintainers. > > I've cc'd Cédric who has done review in m25p80.c in the past. > > > On Sun, Dec 21, 2025 at 11:53 Joel Bueno <[email protected]> > wrote: > >> > >> The Fast Read (0Bh) instruction requires 8 dummy clock cycles > >> according to Winbond datasheets (e.g., W25Q256JV Section 8.2.12). > >> However, the current code adds 8 to needed_bytes, which represents > >> bytes, not clock cycles. Since 8 clock cycles equals 1 byte in SPI > >> communication (1 bit per clock edge), this results in 64 dummy > >> clock cycles instead of 8. > >> > >> Change the Winbond case to add 1 byte (8 clocks) instead of 8 bytes > >> (64 clocks), matching the existing implementation for SST flash and > >> the datasheet specifications. > >> > >> Signed-off-by: Joel Bueno <[email protected]> > >> --- > >> hw/block/m25p80.c | 2 +- > >> 1 file changed, 1 insertion(+), 1 deletion(-) > >> > >> diff --git a/hw/block/m25p80.c b/hw/block/m25p80.c > >> index a5336d92ff..21c2118b33 100644 > >> --- a/hw/block/m25p80.c > >> +++ b/hw/block/m25p80.c > >> @@ -1001,7 +1001,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; > >> break; > >> case MAN_NUMONYX: > >> s->needed_bytes += numonyx_extract_cfg_num_dummies(s); > >> -- > >> 2.51.0 > > -- PMM >
