This is a bitter pill, indeed. Two questions:

1. Is there a technical reason that prevents a single binary from supporting either QSPI and OPI PSRAM, if the type is known (e.g., via efuse settings)?

2. Is it an option for Espressif to allocate 3 bits in the efuses to this purpose?

From Espressif's side, the allocation of efuse bits is all that is needed to enable projects to provide a single binary per family (e.g., one binary for each of ESP8266, ESP32, ESP32-C2, ESP32-S2, ESP32-S3). This would be much more helpful than a solution that forever will need to update a list of modules with their PSRAM settings....

As an example, I could imagine a solution similar to the flash's voltage(*) requirement:

• A first bit (anywhere) that indicates the PSRAM bus type setting is valid.
• Then two bits for storing the configured PSRAM bus type:

  2-Bit	Meaning
  11b	Undefined
  01b	QSPI
  10b	OPI
  00b	No PSRAM

Then, flashing tools and even firmware / bootloader would not need to try to probe the type... they could just read the eFuse bits. For example, a bootloader could implement the following logic:

1. detect if PSRAM settings are to be used, based on efuse values
2. if they are to be used, and they conflict with image in app partition, perform board-specific error handling (blinking lights, debug output, etc.)
3. else, use current behavior (allowing error / mismatch between chip and firmware)

On the positive note, once the bits are defined by Espressif, all customers can immediately start using them, and updating the efuses for any current devices.