Re: [PATCH v2 1/3] mtd: spi-nor: macronix: Drop the redundant flash info fields

[Cédric Le Goater]

Hi,

On 6/22/25 21:09, Pratyush Yadav wrote:
> Hi Guenter,
>
> On Tue, Jun 10 2025, Guenter Roeck wrote:
>
> > On 6/9/25 23:46, Tudor Ambarus wrote:
> > > On 6/10/25 1:14 AM, Guenter Roeck wrote:
> > > > On 6/8/25 18:13, Guenter Roeck wrote:
> > > > > On 6/8/25 05:53, Pratyush Yadav wrote:
> > > > > > On Sat, Jun 07 2025, Guenter Roeck wrote:
> [...]
> > > > > > > With this patch in place, some of my qemu tests no longer recognize the
> > > > > > > flash chips (MX25L25635E/F). Do you have a suggestion on how to handle
> > > > > > > this other than avoiding Macronix flash chips when working with qemu ?
> > > > > >
> > > > > > Could you share some logs? Does the flash fail to detect, or does the
> > > > > > SFDP-based probing fail? Since this is qemu, it would be even better if
> > > > > > you can share a setup/reproduction guide. I have been meaning to set up
> > > > > > qemu for SPI NOR testing for some time now, but never got around to
> > > > > > figuring it out.
> > > > >
> > > > > I suspect that the SFDP data for the affected flashes is incorrect in
> > > > > qemu.
> > > > > Since this is very likely a qemu problem, I'll just configure
> > > > > different flash
> > > > > chips when running affected tests.
> [...]
> > Some debugging shows two problems with qemu: The returned SFPD data for one
> > of the flashes is wrong and does not reflect the data qemu is supposed
> > to provide, and qemu does not provide SFPD data for all flashes.
> >
> > I don't know if the bad data is due to a bad Linux driver (unlikely), a bug
> > in qemu's SPI emulation code, or a bug in qemu's flash emulation code.
> > Unfortunately I don't really have time to track this down further.
>
> I used the command you posted in [0] and tried to reproduce the bug, but
> for me the flash probes just fine:
>
>      root@romulus:/sys/bus/spi/devices/spi0.0/spi-nor# cat manufacturer
>      macronix
>      root@romulus:/sys/bus/spi/devices/spi0.0/spi-nor# cat jedec_id
>      c22019
>      root@romulus:/sys/bus/spi/devices/spi0.0/spi-nor# uname -a
>      Linux romulus 6.16.0-rc2-00308-gf7301f856d35-dirty #5 SMP Sat Jun 21 19:29:15 CEST 2025 armv6l GNU/Linux
>
> The rootfs is also mounted on a mtdblock device backed by this flash,
> and everything appears to work fine.
>
> Which version of qemu are you using? I can see that SFDP data for
> mx25l25635e was added to qemu in commit dc907a667c ("m25p80: Add the
> mx25l25635e SFPD table"), which was released in v7.2.0. Older versions
> of qemu might run into trouble with this flash if SFDP data is not
> available.
>
> FWIW, my qemu version:
>
>      $ qemu-system-arm --version
>      QEMU emulator version 10.0.0
>      Copyright (c) 2003-2025 Fabrice Bellard and the QEMU Project developers
>
> [0] https://lore.kernel.org/linux-mtd/da58fc81-3c99-4951-85bc-e3c139283b5a@xxxxxxxxxxxx/

Some comments on why the mx25l25635e and mx25l25635f flash devices
were introduced in QEMU.

These do represent real HW flash devices with the same JEDEC ID and
different SFDP tables. We discovered that the hard way when doing
bringup of the OpenPOWER servers, some flash devices had 4B opcodes
support, some didn't and it confused pretty badly firmware. IIRC,
we bricked a few BMCs long the way. Hence, the work we did in QEMU to
improve support.


This is not particularly old by Linux standards, less than a decade,
and there may is still be hardware in the field using these devices.
How well they are maintain is difficult to say but I wouldn't risk
bricking them though.

I hope this gives some background.


If you need more info on how to run QEMU for these machines, please
look at the aspeed functional tests :

  https://gitlab.com/qemu-project/qemu/-/tree/master/tests/functional/arm?ref_type=heads

and/or contact us on the QEMU devel mailing list.

Thanks,

C.