Andreas Bolsch

There are provisions (e.g. in SFDP data) for up to 4 differerent (erase) sector sizes. And most (all?) higher capacity devices have differerent sector sizes to choose from. There are even devices where the large erase sector size can be switched by some non-volatile register. Infineon came up with such a "fancy" device ... So, somewhat chaotic, I'd say. Of course, it's possible to add an additional erase block size for only one device. But this is rather non-systematic and additionally it doesn't...

Most SPI flash do support various "sector" sizes, 4kB is sometimes called subsector. OpenOCD uses for bigger flash always the largest available size: Erasing a substancial part by subsector erase is usually much slower than by the larger sectors. E.g. for MT25QL512ABB: subsector 4kByte typ. 50ms, 64kByte typ. 150ms, so roughly factor 5. If you can't live with the larger sector size, these alternatives came to my mind: 1) Add corresponding subsector size/erase command to spi.c for all devices where...

jtagspi cmd 0 1 0x05 ;# read status register jtagspi cmd 0 0 0x06 ;# write enable jtagspi cmd 0 1 0x05 ;# read status register again to check WEL jtagspi cmd 0 0 0x01 0x40 ;# set QE bit (assuming BP to remain cleared) Note that QE is a non-volatile bit, so it has to be set only once. From the datasheet it is NOT quite clear to me how QE bit and QIOEN/QIODI commands do interact. It is possible that setting QE instantly turns on QPI mode, so be prepared that after the seqence above the flash will only...

See 12.5.1 "Flash Driver: jtagspi Command: jtagspi cmd bank_id resp_num cmd_byte ..." Present in all not too old builds, see https://review.openocd.org/c/openocd/+/4876

So, why do you think this is related to OpenOCD? If you fiddle around with settings in a more or less arbitrary way, it's not that surprising that something stops working. Maybe you should simply revert these settings to their original values?!

jtagspi and stmqspi drivers do have a command to specify the properties of a flash device at run time. That's not exactly what you described, but reasonable close to it. So, it's more or less a copy-and-paste of the "jtgaspi set" or "stmqspi set" (see docs) command implementation to another flash driver. As I don't use rp2040 I can't do this, unfortunately.

I'm afraid that - apart from your rather impolite wording - you're not getting the point: 1) Your idea of a generic write method is technically infeasible. E.g. address length or sector length (ATXP128 require 4-byte addresses, S25HL256 ... don't have 4kB sectors) or non-volatile configuration options simply prevent programming without some information about the flash chip. And even chips from the same manufacturer, same product line, same capacity do exist in different versions with different instruction...

As long as continuous 'read' starting in bottom 16MByte via single line is concerned, this might work in most cases. But: - SPI flash might be configured (non-volatile!) to quad line mode. - 'read' with start address above 16MByte requires banking register or 4-byte addresses. For 'program' there are additional obstacles: - sector protection might be active - writing beyond actual memory size will most likely cause wrap-around, hence overwriting the previously written data - some fancy devices require...