ESP flashing stub

[MabezDev]

Management of flashing Espressif chips using Rust

A discussion around rewritting/using Rust create a new esp flashing stub.

Prior art

• esptool the host implementation of the espflash protocol.
• The original flasher_stub - extends the rom flash stub (or drops in, in the case of the esp8266)
• esp-serial-flasher, for flashing espressif chips using
• openocd flashing algorithms for espressif chips

Rewrite goals

• More permissive license, the current stub is gpl
• Cleaner per chip implementation (avoid ifdef per device)
• Shared code to support:
  • esptool
  • openocd flash algo
  • probe-rs flash algo

Breaking down the problem

Per chip management

Requirements which may include:

• Reset & clock control.
• Peripheral init for supported communication peripherals (UART, USB...).
• Flash operations.
  • Should be easily managed by linking to the respective ROM functions.

Communication/ Host management

• Host/Target comms for esptool.
  • RX for receiving esptool protocol commands.
  • TX for logging.
  • We should aim to be generic over the physical interface.
• probe-rs flash algo - can be created via the CMSIS flash algo spec - simple implementation for the esp32c3 here
• openocd flash algo - seems very similiar to the probe rs structure
  • From my understanding, the flash write/erase implementations are shared between all espressif chips, but for each target, the ROM function symbols are linked against the targets ROM addresses.
  • Only init functions are configured per device (init cache, or logging uart etc)

MVP

I think the hardest part of all of this, will be implementing the chip specific initialisation steps. Not that it's particularly difficult, we already have reference implementations in C for all chip through esp-idf, but because we ideally need SVD files for all Espressif chips to reduce the amount of manual register management. SVD's will generate us a low level interface, much like the soc component for esp-idf. Fortunately SVD's are on the way, and @jessebraham has already created one for the esp32c3 under espressif/svd.

With this in mind I think our MVP should be to focus on the esp32c3, and implement support in Rust for esptool stub, probe-rs and openocd.

It is also worth noting that, we can fairly easily bind to the esp-idf implementations of the init functions where required, until we have Rust implementations.

cc: @igrr @radimkarnis @MaValki @erhankur @gerekon

[jessebraham]

I am able to produce SVDs for the S2 and S3 as well relatively quickly. The blocker on their PACs is the lack of LX7 support in the xtensa-lx and xtensa-lx-rt crates. If we're able to just use the LX6 features for the time being for both then I can get SVDs and PACs released, however I'm not sure if this will work or not.

With all that said, I do agree that the C3 is probably the path of least resistance presently.

[erhankur]

@MabezDev , unifying flasher stub with the minimum #ifdef was the backlog item for openocd. Thanks for taking this initiative.

Basically we have below functionality needs to be considered.

• Flash read_write through cache mmu. This is important to support encrypted flash read/write and breakpoints.
• Zlib compression. I know that esptool stub does not support uploading compressed binaries to the encrypted flash. Openocd does.
• Sha256 hash calculation
• Cpu clock change function
• Logging from uart. But there is a need to saving stub logs to the target RAM and retrieve them after openocd algo run.

For the new chips rom functions are almost same but for ESP32 they are different. And some functions are not in the rom for some chips. This is the one of the challenge we need to solve.

[gerekon]

Just several notes to what @erhan wrote...

Flash read_write through cache mmu. This is important to support encrypted flash read/write and breakpoints.

For flash writes we use ROM API, so this is actual for flash reads and breakpoints management.

Also there are several cases when user can access flash during runtime. So we need to be able save and restore state of any periheprals flasher stub uses/changes to make its execution seamless for SW on target. That includes:

• MMU
• CPU/flash clock config
• SPI
• Xtensa TRAX regs (used by flasher for host comms when accessing flash)

So in general stub execution should look like: 1) Save peripherals state 2) Init peripherals or bring them into the state needed for stub execution 3) Exec stub. 4) Restore peripherals state

To make it a bit nore smart and avoid saving/restoring states of all potentially used periheptrals we can use flags for them and make stub functions to mark what peripherals they actually used and need to be restored at the end.

[jessebraham]

We have an MVP at this point I believe, so closing this issue.