The changes here could do with a few more comments 😄

Code size report:

   bare-arm:    +0 +0.000% 
minimal x86:    +0 +0.000% 
   unix x64:    +0 +0.000% standard
      stm32:    +0 +0.000% PYBV10
     mimxrt:    +0 +0.000% TEENSY40
        rp2:    +0 +0.000% RPI_PICO_W
       samd:    +0 +0.000% ADAFRUIT_ITSYBITSY_M4_EXPRESS
  qemu rv32:    +0 +0.000% VIRT_RV32

I don't know if you've considered this in alternatives, but one more option is SFDP. I considered it before the OSPI settings tables, but it looked like it will take some effort to implement. If it is ever implemented though, as some generic layer in drivers/memory, it could possibly replace all hard-coded settings and allow supporting any complaint part.

The SAMD port uses SFDP to some extend. Unfortunately, the capacity of the flash is not available in the SFDP mandatory section. The size is taken from the JEDEC ID, where there seems to be a frequently used encoding for the size.

the capacity of the flash is not available in the SFDP mandatory section.

I guess this is not a valid alternative then.

@iabdalkader Reading the SFDP spec again it seems I was not right. The size of the flash is coded there, and quite a few more important parameters, like how for write the status bits. Things that would have to be defined otherwise. So using that information looks promising for a more generic approach to flash. It should be possible to drop quite a few board variants/boards which just differ by flash parameters.

@iabdalkader Reading the SFDP spec again it seems I was not right. The size of the flash is coded there, and quite a few more important parameters, like how for write the status bits. Things that would have to be defined otherwise. So using that information looks promising for a more generic approach to flash. It should be possible to drop quite a few board variants/boards which just differ by flash parameters.

Yes, if I remember correctly, it also includes many useful things for OSPI chips (opcodes to switch to octal mode, commands for erase/read/write, dummy cycles? etc..). This would be a very good alternative to many things, but it's quite an undertaking to implement generically, so I also resorted to tables in another port.

This would be a very good alternative to many things, but it's quiet an undertaking to implement generically, so I also resorted to tables in another port.

FWIW I fully agree that it's useful but also a big undertaking. It'd be interesting to see if we could find a way to do it generically across ports.

My other recollection of SFDP, from Espressif, is that eventually there are chips which need manually inserted "quirks" because the SFDP parameters are wrong or don't apply in a particular host config, or something like that. That's not a reason to discount it, though.

FWIW I fully agree that it's useful but also a big undertaking. It'd be interesting to see if we could find a way to do it generically across ports.

I see a few challenges:

• Verify, that all information a port needs is in the mandatory section of SFDP. That's the one which should always be there IF the flash device supports SFDP.
• Get a sufficient test coverage and test confidence over the various chip types that exist.
• How to deal with flash chips that do not support SFDP. I have seen a few, and those were chips with smaller capacity, like <= 1MByte. At least, all flash chips I have seen larger than 1Mbyte had SFDP support.
• Generalize it across ports, where possible, as you said.

Looking again into the various versions of the SFDP spec and into the SFDP data of various chips the situation is not overly promising. Besides the flash size and the size of the addresses a required information that varies between chips is the method of enabling the quad write mode == setting the QE flag. This piece of information is not covered by the initial SFDP spec. Newer version of SFDP have it in DWORD15 of the data. The problem: None of flash chips which I looked at have this data. They all comply only to the first version of SFDP. That means, that either this QE flag method has to be configured manually, or Quad Write cannot be supported. That sounds worse than it may be. Writing is relatively slow, and at high clock frequencies the data transfer time is way smaller than the page program time, like ~50µs transfer time @ 40Mhz vs 500 µs. page program time.

Besides the flash size and the size of the addresses a required information that varies between chips is the method of enabling the quad write mode == setting the QE flag. This piece of information is not covered by the initial SFDP spec

You could still maintain some simple logic to work out how to set the QE flag. There are probably only a handful of ways that need to be supported for that.

Regardless, I'm not sure it's worth the effort to do this right now. There are many other things to work on!

here are probably only a handful of ways that need to be supported for that.

The flag has 6 possible settings, but three of them can be handled the same way, and I have never seen one of them. So it's 3 or 4 variants.