Differences

This shows you the differences between two versions of the page.

--- etc:users:jcmvbkbc:linux-xtensa:esp32s3 [2023/10/11 05:27] – jcmvbkbc
+++ etc:users:jcmvbkbc:linux-xtensa:esp32s3 [2024/03/15 21:07] (current) – jcmvbkbc
@@ Line 5: / Line 5: @@
   * https://github.com/jcmvbkbc/config-esp32s3
   * https://github.com/jcmvbkbc/esp-idf/tree/linux-5.0.1
-  * https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-6.4-esp32
+  * https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-6.7-esp32
-  * https://github.com/jcmvbkbc/binutils-gdb-xtensa/tree/xtensa-2.40-fdpic
+  * https://github.com/jcmvbkbc/binutils-gdb-xtensa/tree/xtensa-2.41-fdpic
-  * https://github.com/jcmvbkbc/gcc-xtensa/tree/xtensa-14-fdpic
+  * https://github.com/jcmvbkbc/gcc-xtensa/tree/xtensa-14-4992-fdpic
-  * https://github.com/jcmvbkbc/uclibc-ng-xtensa/tree/xtensa-fdpic
+  * https://github.com/jcmvbkbc/uclibc-ng-xtensa/tree/xtensa-1.0.44-fdpic
-  * https://github.com/jcmvbkbc/buildroot/tree/xtensa-2023.08-fdpic
+  * https://github.com/jcmvbkbc/buildroot/tree/xtensa-2023.11-fdpic
   * https://github.com/jcmvbkbc/crosstool-NG/tree/xtensa-fdpic
 Scripts with all steps below: https://github.com/jcmvbkbc/esp32-linux-build
+===== Details =====
+  * [[.:esp32s3:flash]]
+  * [[.:esp32s3:gpio]]
+  * [[.:esp32s3:linux-ipc]]
+  * [[.:esp32s3:mmu]]
+  * [[.:esp32s3:wifi]]
 ===== Things that work =====
-  * WiFi. Use the script that builds firmware based on esp-hosted. It runs on core 0, linux runs on core 1, special linux IPC is used for communication. WiFi transport that uses linux IPC is added both to the firmware and to the linux kernel wifi driver.
+  * WiFi. Use the script that builds firmware based on esp-hosted. It runs on core 0, linux runs on core 1, special linux IPC is used for communication. WiFi transport that uses linux IPC is added both to the firmware and to the linux kernel wifi driver. Not all wifi security options may be working, e.g. open and wpa2-psk are working and 802.11w is not.
   * Writing to FLASH and using ESP FLASH partition table. Driver based on linux IPC sends FLASH-related requests to the firmware. Default configuration has an etc partition that is flashed with /etc file system and mounted at boot time. The file system is writable and it can be used to store things like wpa_supplicant.conf, /etc/passwd, /etc/shadow, ...
+  * USB serial. It is visible as the /dev/ttyACM1 (in kernels based on v6.5) or the /dev/ttyGS3 (in kernels based on v6.6-rc and newer) device inside the linux environment. (The change of name was requested by the linux TTY subsystem maintainer, the change of number is to keep UART ports numbering coherent with esp32s3 TRM).
+  * GPIO, including interrupts. Software I2C over GPIO and software SPI over GPIO.
+  * hardware SPI. Tested clock speed up to 20MHz with SD card.
+  * clock frequency detection. CPU, XTAL and APB clocks may be preset by the bootloader, the kernel will understand and use preset frequencies without additional configuration.
   * ssh server and ssh client. There's an issue using scp from openssh version 9 because that version switched from the original scp protocol to sftp. The option -O makes it use the now legacy scp.
   * mounting NFS shares.
-  * running executable code from outside the rootfs, e.g. from /etc or from NFS mounts. Code in the linux bootloader maps PSRAM to the IRAM address range and a special hack in the kernel code does address remapping, so that when a file is mapped for execution the mapping address points to the PSRAM alias in the IRAM address range.
+  * running executable code from outside the rootfs, e.g. from /etc or from NFS mounts. A special hack in the kernel code does address remapping, so that when an executable memory mapping is created, the mapping address points to the PSRAM alias in the IRAM address range. This does not work for ESP32 as it doesn't have executable mappings of PSRAM.
-  * USB serial. It is visible as the <del>/dev/ttyACM1</del> /dev/ttyGS3 device inside the linux environment. (The change of name was requested by the linux TTY subsystem maintainer, the change of number is to keep UART ports numbering coherent with esp32s3 TRM).
+  * passing command line from bootloader to the kernel. Bootloader reads the file /etc/cmdline if it exists and passes its contents to the kernel as the command line. The bootloader does JFFS2 file system parsing for that. E.g. the following line can be used to move console to the USB serial: <code>earlycon=esp32s3acm,mmio32,0x60038000 console=ttyGS3 debug rw root=mtd:rootfs no_hash_pointers</code>
-  * passing command line from bootloader to the kernel. Bootloader reads the file /etc/cmdline if it exists and passes its contents to the kernel as the command line. The bootloader does JFFS2 file system parsing for that.
   * strace (a one-line fix is needed for the mainline strace to correctly handle the initial exec).
   * perf stat (heavy patching is needed to build it for nommu). -D1 is needed to properly enable events (perf relies on ability to run code after the fork but before the exec in the child process to manage events on systems with mmu, -D1 looks like a good workaround for nommu case).
+  * c++ exceptions, c cleanup routines, forced stack unwinding, unwinding over signal frames.
+  * TLS and NPTL. Some corner cases still need attention though.
 ===== Things that don't work =====
-  * c++ exceptions. Not yet.
+  * about 290 failing tests in the gcc testsuite, most related to TLS and linuxthreads limitations. About 300 failing tests in the g++ testsuite.
-  * NPTL. Not yet.
+  * mmap with MAP_FIXED flag. By design of the nommu linux, but it seems to me that it doesn't have to be like that. It's usually not a big deal, but that's the reason there's no module information in the /proc/*/maps other than for the ld.so and the executable.
-  * mmap with MAP_FIXED flag. By design of the nommu linux, but it seems to me that it doesn't have to be like that.
   * tcpdump and libpcap in general. It tries to mmap the packet socket and it's missing a few things (mm/nommu.c doesn't know what capabilities to assign to S_IFSOCK files, the socket file needs to have get_unmapped_area callback defined), but most importantly the packet_mmap code heavily relies on the presence of mmu. Although it seems that it could be worked around.
   * bluetooth. It requires heavy userspace support that includes dbus which wants fork. Looks like it can be worked around, but the amount of bloat is discouraging.