memory-25q: erase-all does not work on 25PX80VG

[fxsheep]

Version

Glasgow 0.1.dev2846+gcaa6dc9 (CPython 3.13.12 on Linux-6.8.0-106-generic-x86_64-with-glibc2.35 Ubuntu 22.04.5 LTS)

Description

erase-all does not work on a ST/Micron 25PX80VG.

This chip apparently does not support SFDP:

I: g.cli: running handler for applet 'memory-25q'
W: g.applet.memory.25q: device does not have valid SFDP tables: SFDP signature not present
W: g.applet.memory.25q: assuming --address-bytes 3 by default
I: g.applet.memory.25q: JEDEC identification:       STMicroelectronics (0x20) device 0x7114
I: g.applet.memory.25q: inexact memory size guess:  1024.0 KiB
I: g.applet.memory.25q: current block protect bits: 0000 (all blocks writable)

An erase-all command fails with:

I: g.cli: running handler for applet 'memory-25q'
W: g.applet.memory.25q: device does not have valid SFDP tables: SFDP signature not present
W: g.applet.memory.25q: assuming --address-bytes 3 by default
W: g.applet.memory.25q: this command may take a long time
E: g.applet.memory.25q: operation failed

If I understand it correct, Glasgow uses 0x60 for erase-all when SFDP is not present:

glasgow/software/glasgow/arch/qspi/nor.py

Line 75 in caa6dc9

EraseChip = 0x60 # W M X I (C7h is an universal alternative)

    # Erase
    EraseChip               = 0x60 # W M X I   (C7h is an universal alternative)

Datasheet of M25PX80 states BULK ERASE uses 0xC7, with no mention to 0x60.
https://docs.rs-online.com/8b73/0900766b8121bd2b.pdf

Changing EraseChip to 0xC7 in the sources, worked.

My idea is

• Implement a blacklist for "C7 only" chips(as they seem to be rare). Uses 0xC7 when JEDEC ID matched blacklist
• add a --opcode-erase-all so that the user can override it when their chip is not yet covered by blacklist, without changing source

Log file

No response

(I'm aware that with memory-25q, erase-all is unnecessary for most use cases, but for completeness, nevertheless)

[whitequark]

I do not like the proposed solution. Since there are no known (to me at least) chips that don't support C7h I think we should just switch to using C7h. If it turns out that there are both C7h-only and 60h-only devices we can start thinking about more complex solutions.

The reason for this is that I would like to maintain as few things as possible and "blacklist indexed by Flash JEDEC ID" is distinctly in the set of things I do not wish to maintain under any circumstances. This is a big part of why I invested so much effort into improving SFDP support.

[whitequark]

It looks like they bought the flash unit from STMicroelectronics?

edit: oh, it's in the log and the text you wrote, I must be blind