Does ESP32-S2 work with the existing toolchain?

Does ESP32-S2 work with the existing toolchain?

Nope, that requires a separate toolchain that I could provide.

Please do, I actually have one of those boards 😄

I'm still surprised, aren't they all using the same Xtensa core? Why are separate toolchains needed for different members of the family?

Does ESP32-S2 work with the existing toolchain?

Nope, that requires a separate toolchain that I could provide.

I could provide it immediately. The question is whether it makes sense before we have ESP32-C3 and ESP32-S3 support in the master. Each toolchain blows up the Docker image by about 300 MBytes.

As it can take very long for the workers to get updates, I say we better have toolchain support earlier than later.

Please do, I actually have one of those boards smile

Hm, but the ESP32-S2 support bases on some changes introduced for ESP32-S3 which in turn bases on some changes that can't be merged independent on the PR for ESP32-C3 support. That is, we have to merge the support for each variant step by step 😟

I'm still surprised, aren't they all using the same Xtensa core? Why are separate toolchains needed for different members of the family?

I don't know. At least ESP32 uses a different Xtensa core than ESP32-S2 and ESP32-S3. While ESP32 is using LX6 cores, new ESP32x variants like ESP32-S2 and ESP32-S3 use LX7 core.

I don't know. At least ESP32 uses a different Xtensa core than ESP32-S2 and ESP32-S3. While ESP32 is using LX6 cores, new ESP32x variants like ESP32-S2 and ESP32-S3 use LX7 core.

As I know, the cores differ in the instruction sets they implement. Xtensa cores are highly configurable by the SoC designer. There are a lot of hardware options from which a designer can select what he wants. As a result, supported instructions can differ a lot. I guess, the compiler has to know what instructions are supported so that it has to be built for each Xtensa core.

the ESP32-S2 support bases on some changes introduced for ESP32-S3 which in turn bases on some changes that can't be merged independent on the PR for ESP32-C3 support. That is, we have to merge the support for each variant step by step

Don't worry about that, only more motivation for me to review the C3 and S3 PRs 😉
I'll try to find some time for it on the weekend.

Hm, the build test seems to fail due to an unrelated error in Rust build test. It seems that a git checkout command is used and the examples/rust-hello-world/Cargo.lock file is modified during the compilation of examples/rust-hello-world/.

error: Your local changes to the following files would be overwritten by checkout:
	examples/rust-hello-world/Cargo.lock
Please commit your changes or stash them before you switch branches.
Aborting
Error: Process completed with exit code 1.

Bors try

try

Build succeeded:

• Build and Test

Bors merge

Build succeeded:

• Build and Test

@benpicco Thanks for reviewing and merging.