[spi-nor] Macronix MX25L requires CR read opcode 0x15 (not 0x35)

[Maarten Zanders]

Hi,

On Tue, Sep 9, 2025 at 5:29 PM Pratyush Yadav <me at yadavpratyush.com> wrote:
> How do any of the flashes even work on mainline then? Won't they all
> have the same problem? Does it only end up touching the OTP bits, and
> those don't get noticed?

For the part I mentioned, the other fields in the CR concern:
- output driver strength, this can go easily unnoted (default 1)
- dummy clock cycles, only for fast read mode, not sure if this is used
Flipping the OTP top/bottom bit only gets noted when you use (and
test..) locking for the last portion of the device as that's the only
thing which is supported by the driver - the BP mechanism at top of
flash.
Also when combined with (default) U-Boot for instance, all locking is
disabled in SR at boot which hides the issue again...
So for the most part, the driver and devices are working and you need
quite some bad luck to hit this bug.

> > > SNOR_F_NO_READ_CR
> > That flag will have similar results as reading garbage today. It will
> > ignore the actual contents of CR when we're actually trying to do a
> > read-don't-modify-write. In the case of this part, it will clear some
> > bits which were 1 by default, changing output driver strength.
>
> Hmm, makes sense. I was hoping the bits would also default to 0 so there
> won't be a problem.

Also tested with a different (& larger) flash device, MX25L25645G,
where all the CR bits do default to 0. Coincidentally, the flag
SNOR_F_NO_READ_CR is then also set so we're always writing 0's to CR
when updating SR.
This is because in SFPD  BFPT_DWORD15_QER_SR2_BIT1_NO_RD is set, as
opposed to BFPT_DWORD15_QER_SR1_BIT6 on the failing part.
So for this kind of devices (which don't read CR) we're good. But it's
hard to get an overview for all devices as that requires the SFDP data
which is only available on request.

This SFDP parsing of QER is unclear/messy to me. I'd love to have a
look in the JEDEC specification but don't have access. Clearly,
somewhere something went wrong with the implementation of these
parameters. Some variable renames in the past obfuscate history a bit
too. I feel that SNOR_F_NO_READ_CR was introduced as a fix while the
actual issue was a wrong opcode...
I was told that Macronix engineers are also looking into this so I
hope they can chip in here in due time.

> > A cleaner/modern approach would be to add a parameter in struct
> > spi_nor_flash_parameter which gets defaulted to SPINOR_OP_RDCR (0x35)
> > and fixed up using manufacturer late_init() for Macronix?
>
> Yeah, or maybe a callback like for ready?
>

I have a working patch for 6.1 which my project uses today, will see
to get this to the current state & have it tested.

I also noted on the Zephyr Project that the opcode for RDCR is using
0x15 for all mfg's...

Best regards,
Maarten