Closed MabezDev closed 1 year ago
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.
@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.
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.
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:
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.
We have an MVP at this point I believe, so closing this issue.
Management of flashing Espressif chips using Rust
A discussion around rewritting/using Rust create a new esp flashing stub.
Prior art
Rewrite goals
Breaking down the problem
Per chip management
Requirements which may include:
Communication/ Host management
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