A couple new changes in the esp32-linux-build scripts:.- update to linux-6.11 and buildroot-2024.08.- new configuration for the Espressif Box-3 supporting SPI display and USB host controller.

Xtensa FDPIC ABI draft RFC:

xtensa FDPIC toolchain gets initial TLS and NPTL support with uClibc-ng. New linux builds for esp32s3 and esp32 will have it enabled by default. xtensa FDPIC support in musl libc is next.

xtensa gcc switches from reload to LRA thanks to Takayuki 'January June' Suwa.

And as long as bits DPORT_{PRO,APP}_CACHE_MASK_IROM0 are set, reads from the region 0x4080_0000. 0x40BF_FFFF (VAddr3) return 0xbad00bad. Clearing these bits makes the VAddr3 mappings work.

On esp32 as long as DPORT_{PRO,APP}_CACHE_CTRL1_REG bits DPORT_{PRO,APP}_CACHE_MASK_IRAM1 are set, reads from the region 0x4040_0000. 0x407F_FFFF (VAddr2 in esp32 TRM terminology) return 0xbad00bad. Clearing these bits makes the VAddr2 mappings work.

Got linux-6.7-rc8 + userspace running on esp32 with 4M FLASH and 4M PSRAM. It took some time to find a workaround for the unfortunate default FLASH mapping. Build script:

c++ exceptions and c cleanup routines are now working in the xtensa FDPIC toolchain. TLS and NPTL are next.

Got GPIO kernel driver working in esp32s3 xtensa linux, and with that bitbanged SPI and I2C. Can scan i2c bus with i2cdetect. Got an example i2c accelerometer working in the kernel iio framework.

xtensa windowed ABI is somewhat vague about it and says that the frame pointer "may (but is not required to) be allocated in register a7". If I squint hard enough I can read it as "for functions that use call4 the frame pointer may be allocated in a3".

Turns out xtensa windowed ABI assignment of hard frame pointer to a7 messes up gcc idea of call-clobbered registers with WINDOW_SIZE of 4, even when the frame pointer is not in use.

xtensa gcc compiler port is nicely parameterized by the WINDOW_SIZE macro, that specifies the size of a register window used for function calls. It's fixed as 8 right now, so I thought that changing it to 4 might be a quick way to get gcc to use call4 instead. Ha-ha, what a fool.

Build script is in the usual place:

Got writing to FLASH working in the esp32s3 linux. Made persistent writable /etc partition.

and now an interesting thing: on a different module I see 5Mbits/s on wireless and 30Mbits/s on local interface.

on the loopback interface it shows ~14Mbits/s, so 2Mbits/s on wireless doesn't look that bad.

iperf3 on xtensa linux on esp32s3 shows ~2Mbits/s for TCP in both client and server modes.

Here's the script to build and flash it:

It was due to a couple missing entries in the kernel config, with these entries in place xtensa linux on esp32s3 successfully joins wpa2 network.

I also tried wpa_supplicant to join protected setup, but no luck so far.