Add support for Xtensa LX7

[jessebraham]

The ESP32-S2 and ESP32-S3 are based on Xtensa LX7 processors. In order to build up the bare-metal ecosystem for these devices we will obviously need runtime support.

There appears to be a large amount of overlap between the LX6 and LX7 processors in this regard, so we may need to refactor things a bit and change how we're gating features.

[MabezDev]

In esp-idf, they use pre processor definitions from the xtensa-overlays repo, maybe we could do something similiar.

Short term, if the current lx6 feature just works, lets reuse that until we have a better plan going forward.

[jessebraham]

When attempting to enable the lx6 feature and use this crate with an LX7 processor (in my case the ESP32-S2), a number of compilation errors occur. I have saved the output of this in a gist:

https://gist.github.com/jessebraham/085edc8e45e681a0b84e6ade10ebfe3b

[igrr]

I think the issue here is that the CPU configuration of ESP32-S2 doesn't have a few features enabled, compared to ESP32 or ESP32-S3. So this is less of an LX6 vs LX7 thing and rather a specific CPU configuration thing.

In particular, ESP32-S2 doesn't have Zero Overhead Loop option, doesn't have Misc, Boolean, or FPU registers. Neither ESP32-S2 or S3 have the Double Precision FPU Accelerator option. (TBH it's unused on ESP32, so we can completely remove it.)

[MabezDev]

FYI this is something I started trying to tackle in https://github.com/esp-rs/xtensa-lx-rt/pull/27/files. Using CPU features to decide what's enabled, but this has its limitations (see the PR).

[jessebraham]

Upon further investigation, it seems these issues only apply to the ESP32-S2.

Using the unify-xtensa-asm branch I was able to build for the ESP32 and ESP32-S3, but when building for the ESP-S2 I see the aforementioned error output. Note that in order to do this I had to first add the #![allow(named_asm_labels)] attribute to lib.rs in xtensa-lx-rt.

(This is mostly just confirming what Ivan has already said)

[MabezDev]

Looking a bit further into my approach in #27, there are details we just can't find out from the Rust compiler (technically LLVM) currently. There is also the general xtensa problem that everything can be custom, so there is no standard layout for the vector table etc.

I think a new approach, consuming core-isa.h header files from espressif/xtensa-overlays is a more viable option so I'll look into that.