-
Notifications
You must be signed in to change notification settings - Fork 7.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
REQ: ESP32-S3: Assign efuse bits for PSRAM bus type (IDFGH-7538) #9101
Comments
+1 |
Hi @henrygab , Thanks for your proposal. We will consider this (runtime detection of OPI flash/psram). But since it's a major change (all changes to efuses are not simple), we need a lot more time to discuss about it. |
@ginkgm -- This issue is NOT asking for runtime detection of OPI. After all, as you have said, that would be a major change. Rather, this issue is limited to asking that some e-fuse bits be allocated officially by Espressif (and meaning defined). This will NOT require automatic detection, is 100% backwards-compatible / safe, and enables a smooth(*) transition time. Please do consider this, in view of understanding the much more limited scope of this request! (*) Smooth is defined as, "no worse than exists today". P.S. -- Moved a section in original issue to clarify scope. |
Any news? |
@ginkgm ... Any update? I ask because it seems there was some confusion about my request. You wrote that I was requesting, "runtime detection of OPI flash/psram" ... although my request was only for the EFUSE bits be allocated from the reserved block of Espressif-controlled bits. Until the bits are allocated, all attempts to fix the issues are essentially blocked (or require hacks that will cause other problems). Again ... this is NOT requesting runtime detection to exist(*) ... it's only requesting that three bits be allocated to this purpose (one bit to indicate this information exists / is valid, two bits to indicate the values). (*) Runtime detection is NOT part if this request ... it's understood that automatic detection may be technically impossible in some scenarios; Rather, this just allows STORING a (manually-supplied) value. |
Hi @henrygab , @Jason2866 , But you still need to use them at runtime, don't you? From the point of view of maintaining the SDK (ESP-IDF), we almost can't add any logic that rely on this efuse bit, because not all products can correctly get this efuse field burnt. There are:
But if the user have to do it, why it has to be in the efuse rather than the flash, which is possible to overwrite? And the simplest way to record some information in the flash is a simple Kconfig option. |
Still a reservation of a efuse would be nice. I do understand that you can not burn the fuses by default. So board manufacturers can do for there boards. At the moment it is a mess, since boards with the same name are sold with all kind of flash/Psram types and sizes. Many users do not manage to get the boards going. If this is not possible a detection utility (esptool.py?) is needed which prints out the size and type of flash and psram. I opened a feature request. |
Jason2866 responded, and I agree with his statements. If I understood you, because not all products will have the efuse burnt at factory, you are wondering why it's worthwhile to have in efuses vs. flash. I will try to simplify to two reasons:
This is a solution that enables progress towards fewer error conditions. Defining the bits and their meaning is the first step. After this is done, all the following are possible without any synchronization (fully backwards compatible ... unset bits == no information on PSRAM):
These are not in scope for this issue ... but they are gated by / blocked by this issue. |
Another reason why it would be really useful to check at runtime how the flash/PSRAM is wired is to allow for some pins to be used or not. And the other way around, if the bootloader can also act on these fuse bits, perhaps issues like I had today with the Lilygo T-dongle S3 (16M) could have been prevented. |
PLEASE consider just officially MARKING three efuse bits from the reserved pool (reserved == future use by espressif) for this purpose, and defining them as noted above. The sheer number of bootloader variants that must be supported otherwise is geometrically increasing, and is a constant source of friction to the use of these modules.
What this does do is provide an OPTION for those who desire to move forward with a solution ... it provides a BACKWARDS COMPATIBLE way forward, without impact on any existing items. Please? |
+1 |
👍 +1 |
Community Ask: Please set aside some bits in efuse for explicit use of indicating different flash and PSRAM configurations. Espressif response: Store settings in flash. But ... flash isn't accessible if the board is fully erased, so it leaves the community confused. Community Ask: Just reserve three efuse bits ... nothing else! Espressif response: Any change we make to efuse tooling requires lots of work. Community Ask: No tooling... Just reserve three efuse bits ... nothing else! Espressif response: We cannot use this ourselves in manufacturing on all product lines. Therefore, this is not useful. Community is left confused, since simple zero-overhead solution was rejected. |
It seems there is activity. espressif/esptool@b70ead2 |
I'm not so sure... From the commit:
On the positive side, it's possible to go from any However, unless either:
Then I think those changes may be tangential.... |
Is your feature request related to a problem? Please describe.
Currently, ESP32-S3 does not have appear to support storing manually selected PSRAM settings. This prevents having a single binary for the ESP32-S3 chip variant (which was possible for ESP32 and ESP32-S2). Currently, there is no programmatic way to detect the PSRAM, and having a mismatch between bootloader and binary will cause boot loop. These are causing confusion and frustration. See, for example, bootloop and bootloader issues.
Describe the solution you'd like
I request that Espressif allocate at least three efuse bits on ESP32-S3 for the purpose of storing manually selected type of PSRAM attached to the processor.
As an example, one solution, similar to the flash's voltage(*) requirement, would be:
11b
01b
10b
00b
This provides a backwards-compatible method of using the efuses to detect the stored setting, and allows existing modules to have their efuses be updated in-the-field, or at any point in supply chain, as needed.
Out-of-scope for this issue, but enables...
For clarity, I've pushed this section into a collapsible node. These are NOT part of this issue, but rather show how this will enable transitioning to a better experience in a smooth manner....
As soon as it's official which bits are allocated, the following can then occur in parallel, without any bottlenecks or cross-dependencies:
Describe alternatives you've considered
Verbose, so moved to collapsible node...
Not assigning efuse bits. Without an official location to store this critical information, it becomes necessary to keep (and continually update) a list of modules, and what connection type is used. The updating adds perpetual costs to the maintenance of multiple projects, where the preferred goal (for many reasons) is a single binary per platform.
Using customer-defined EFUSE bits. However, this would not resolve issues in hobbyist community, and would not allow tools to be updated to interpret this setting.
Using only two bits. The use of only two bits was considered. However, three bits were used to more closely align with existing similar efuse bits defined by espressif (e.g., flash voltage).
Not defining bit pattern
11b
as invalid. However,11b
reflects un-set efuses. Defining this as "not set" reduces the number of user errors. This also makes an explicit choice for the board mandatory.Not defining a bit patter as
No PSRAM
. However, an explicit setting forNo PSRAM
is preferred, so bootloaders could then avoid fallback / autodetection techniques when explicitly indicates no PSRAM is available.Alternate bit patterns. Specifically, the bit pattern of
00b
to indicateNo PSRAM
was selected to allow a safety fall-back, in case the EFUSE is accidentally programmed with the wrong PSRAM type. That is, it is possible to transition from either QSPI or OPI PSRAM settings (01b
or10b
) to disabling PSRAM (00b
), because EFUSE may transition only from1
to0
.Additional context
See also: espressif/arduino-esp32#6426 (reply in thread)
See also: espressif/arduino-esp32#6646
Example of how a bootloader could use the information
Pseudo-code
P.S. -- THANK YOU for shipping ESP32-S3 modules with efuses indicating flash voltage settings! This solved large pain points from hobbyists attaching IO12 to various electronics, and having difficult-to-track boot failures.
The text was updated successfully, but these errors were encountered: