Add Xtensa (ESP32-S2/S3) target support - #168
Conversation
b837689 to
7c8886e
Compare
- map CONFIG_XTENSA SoC series to xtensa-*-none-elf rust targets (these exist upstream as tier 3 but need the esp-rs toolchain's LLVM backend) - allow RUST_SUPPORTED on XTENSA - kconfig codegen: emit hex values wider than 32 bits as u64 (ESP32-S3 GPIO masks overflow usize on 32-bit targets) Verified on heltec_wireless_tracker/esp32s3/procpu hardware: hello_world boots and logs, built with the esp 1.93 toolchain and CARGO_UNSTABLE_BUILD_STD=core,alloc. Signed-off-by: TruongSinh Tran-Nguyen <i@truongsinh.pro>
7c8886e to
67915e8
Compare
| writeln!(&mut f, "pub const {}: usize = {};", &caps[1], &caps[2]).unwrap(); | ||
| // Hex values wider than 32 bits (e.g. ESP32-S3 GPIO masks) don't | ||
| // fit usize on 32-bit targets; widen the type to match the value. | ||
| let value = u64::from_str_radix(&caps[2][2..], 16).unwrap_or(u64::MAX); |
There was a problem hiding this comment.
Will this also emit u64 instead of usize even on 64-bit targets? Just curious if this was considered and if it could cause any issues.
There was a problem hiding this comment.
Yes, but only for hex values above u32::MAX, and it keys on the value rather than the target, so a given constant is u64 everywhere or usize everywhere. That keeps the type portable instead of target-conditional. On 64-bit there's no truncation either way since usize is already 64-bit; on 32-bit the u64 is what avoids the silent truncation this fixes. The only cost is that a >u32 hex const is u64, so a usize consumer needs a cast, but those are rare (large masks like GPIO). If uniformity matters more than that, always emitting u64 for hex is the alternative, at the cost of small values losing the ergonomic usize.
There was a problem hiding this comment.
Hmm, it's a bit annoying that you'd get usize mixed with u64 on 64-bit systems where a uniform representation is available.
I think one of the following would be more sane,
- u32 with promotion to u64 when necessary - for all targets
- usize with promotion to u64 only when there is a target limitation
@d3zd3z What do you think?
3 participants
This adds Xtensa support for building and running Rust applications on ESP32-S3 (and, mapped but untested, ESP32-S2/ESP32) boards:
CONFIG_XTENSASoC series →xtensa-esp32s3-none-elf/-s2/-esp32. These target specs are upstream rustc tier 3 (Add no_std Xtensa targets support rust-lang/rust#125141, #126380), but official rustc ships without the Xtensa LLVM backend, so building requires the esp-rs Rust toolchain on PATH plusbuild-std(e.g.CARGO_UNSTABLE_BUILD_STD=core,alloc). The mapping comment says so.RUST_SUPPORTEDonXTENSA.u64instead ofusize— ESP32-S3'sCONFIG_SOC_GPIO_VALID_GPIO_MASK(49 bits) previously generatedpub const …: usize = 0x1FFFFFFFFFFFF;which is a hard error on 32-bit targets.Verified on real hardware:
samples/hello_worldbuilt forheltec_wireless_tracker/esp32s3/procpuwith the esp 1.93 toolchain boots and logsHello world from Rust on heltec_wireless_trackerover the USB-Serial-JTAG console. Also re-verified the existing ARM path (qemu_cortex_m3 boots, nrf52840dk builds) with the same tree.One adjacent observation while testing (not part of this PR): boards whose GPIO controllers use single-cell specifiers (e.g.
mps2/an385) make the generateddevicetree.rscallGpioPin::newwith one argument too few — can file an issue with details if useful.