eFuse write support

[kyrias]

This pull requests add support for writing eFuses to all currently supported chips. From reading both the relevant TRMs and the espefuse flashing process I believe that this should be correct for all of them, though I only have ESP32-S3 and ESP32-C3 devkits to test this out with. In particular I think it would be good if it could be explicitly tested on at least an ESP32 as well since its eFuse controller is structured completely differently from the rest, as well as ESP32-S2 just to be sure since it has rather different timing parameters from the rest.

---

Since I only have a couple of devkits on hand that limits the number of tests that can be done for this feature, so I would appreciate a review and at least a tentative approval before I perform my final tests.

[SergioGasquez]

Thanks for your work on this! A few fixs/comments, I wish we could test this features on HIL, but sadly I cant think of a way with efuse beings only writable once

[kyrias]

@SergioGasquez

I wish we could test this features on HIL, but sadly I cant think of a way with efuse beings only writable once

Yeah, I've been trying to think of any way to have automated tests for this, and it's unfortunate that we can't have HIL tests for this, since the eFuse controller itself doesn't have a concept of virtual eFuses, instead that's just an ESP-IDF concept.

One thing I've been wondering about though is whether it would be possible to get espflash talking to a VM running using the Espressif QEMU fork. From what I've been able to tell it doesn't seem like that's something they've implemented support for direct, but I wonder whether it would be possible to do it by making it boot the esptool stub loader at least?

If it is possible then I think it would be way too much work for this PR, but I think it's a promising future improvement idea.

[kyrias]

Actually, nevermind, I did something silly (or well, expected the doc examples to be correct 😅). It seems connecting to the QEMU VM with esptool/espefuse does work.

I'll try to rig something up to at least be able to test it manually this way. I think doing it in CI will still be too much work for this PR though, because it requires compiling the Espressif QEMU fork and figuring out how to run it properly in CI and stuff.

---

One annoyance is that we'd need to change how espflash handles serial ports. Currently espflash only allows using serial ports returned by serialport::available_ports(), but on Linux it uses libudev to detect serial ports which only cares about real, physical devices and will therefore not return the PTY allocated by QEMU.

On the other hand, both QEMU and esptool supports using the UART over TCP instead of as a PTY, using e.g. socket://localhost:5555. I wonder if it would make sense to support that as well? (Though it's a bit awkward that they use socket://, hmm.)

So I think we'd need to either allow specifying any device using --port and not just ones returned by serialport::available_ports(), or implement support for connecting over TCP. (Or both, I guess.)

[kyrias]

Hmm, the QEMU fork seems a bit wonky. If I leave it running for a bit it seems to stop responding to serial commands, but I haven't been able to tell if there's any pattern to its behavior.

Also, annoyingly it seems like the QEMU eFuse controller doesn't perform any error correction checks, so it's not possible to tell whether or not the calculated Reed-Solomon codes are correct. But at least it would be possible to check that we write the correct bytes to the correct register by writing some specially patterned data using espflash and then verifying against espefuse dump.

[SergioGasquez]

So I think we'd need to either allow specifying any device using --port and not just ones returned by serialport::available_ports(), or implement support for connecting over TCP. (Or both, I guess.)

Yes, this is something we could add support to, it shouldnt be too bad, but as you mentioned its out of the scope of this PR.

Hmm, the QEMU fork seems a bit wonky. If I leave it running for a bit it seems to stop responding to serial commands, but I haven't been able to tell if there's any pattern to its behavior.

I think using QEMU fork on CI could give us a few headaches, but if its the only option we could explore it!

[SergioGasquez]

LGTM! Thanks, lets merge this and we could add any test or improvements in future PRs!