Question - efuse usage

[netmindz]

Should we be using eFuse as a way of hardware vendors identifying themselves or at least features like ethernet rather than releasing different firmware bins with certain build-time defaults set?

https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/system/efuse.html

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

• Create Plan

Examples

• Example 1
• Example 2

---

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[DedeHai]

isn't the whole point of the new OTA verification to identify hardware? Blowing hardware fuses would certainly be an elegant way but only viable for fixed hardware i.e. vendors. Since fuses are permanent, we would need to think it through for all current and future use cases.
A soft-approach would be a file in the file system that is persistant, i.e. gets loaded to ram on a factory reset, then re-stored in the FS, it can be updated any time so would be less "safe" than fuses in that regard but also more "safe" in case there is a bug.

[softhack007]

Blowing hardware fuses would certainly be an elegant way but only viable for fixed hardware i.e. vendors. Since fuses are permanent

I agree, if we "set" hardware fuses, this cannot be undone any more. It means if WLED blows hardware fuses, any other firmware is not able to restore them to the original value. If we accidentally (bug) blow the wrong ones, the board is bricked forever.

rather than releasing different firmware bins with certain build-time defaults set?

Not sure; different feature sets - like builds without ethernet - help us to keep the flash size under control. If a user doesn't need ethernet, doesn't need/want esp-now or IR remotes, this will free a lot of flash for additional features that might not fit into program space otherwise.
Or in case of DMX serial output, the code is so bug-prone and fragile that it don't want it even compiled-in for "normal" users.

One thing that you cannot avoid with fuses: different firmware files for esp32-S3 flash modes. Flash modes are incompatible on S3, so we'll always need special builds for dio, qio_qspi, qio_opi and opi_opi modes.

[netmindz]

Yeah. Just to be clear this is something that would only be done by hardware manufacturers, we would only coordinate their use and read. Blowing fuses would never be a feature of a vanilla build from us

[willmmiles]

If I'm understanding, the general idea is to read the efuses to allow a generic firmware to identify vendor hardware, and thus potentially load a "more correct" default configuration. The basic idea being to burn in a vendor/device ID so the firmware can recognize the hardware.

Potential risk factors:

• Maintaining database of hardware configurations is a chore
• Alternatively, storing settings directly in efuses limits us to a small number of user-available bits (128?)
• Some user tries to reuse an old device which had the efuses set in its previous life; firmware does something strange

To recap, the root problem is that vendors usually want a custom "factory default" configuration; and we don't want to have build-time defines for every configuration parameter. This factory default configuration needs to survive the "factory reset" process. Alternative solutions on the table:

1. Store a "default config" file on the filesystem at production time
   • Con: Special care is required for factory reset process - it's no longer just a filesystem flash erase
   • Con: May not survive USB flashing if partition sizes disagree
2. Store a "default config file" in a separate flash partition
   • Con: Supported by standard tools, though less-frequently-used portions
   • Con: May not survive USB flashing
3. Embed a "default config" file in the firmware
   • Con: Requires custom vendor build for each device
   • Con: Would get lost if switching to generic build

[DedeHai]

nice recap, this sums it up pretty well.
IIRC there are plenty of fuse bits, up to 3x256 bits on all ESP32 flavours, some may even have more. For ESP8266 I could not find an official documentation but it seems to have at least a few bits.
To progress this discussion I think specific scenarios would help.

[netmindz]

I was thinking about this in relation to the whole "factory reset" issue

[DedeHai]

I don't think using fuses for a factory reset is a viable solution. It would need to contain all possible current and future config values within 24 bytes or so.