Open Source & Linux Lab

It's better when it's simple

User Tools

Site Tools

You are here: О нас » /etc... » User pages » Осьмилис/jcmvbkbc/octofox sapiens » Linux port for Xtensa » Booting linux on ESP32s3
etc:users:jcmvbkbc:linux-xtensa:esp32s3

Differences

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

Link to this comparison view

Both sides previous revisionPrevious revision
Next revision		Previous revision
etc:users:jcmvbkbc:linux-xtensa:esp32s3 [2023/10/11 05:27] – jcmvbkbcetc:users:jcmvbkbc:linux-xtensa:esp32s3 [2024/06/09 05:06] (current) – update bootloader instructions to wifi-enabled version jcmvbkbc
Line 4: Line 4:
   * https://github.com/jcmvbkbc/xtensa-dynconfig/tree/original   * https://github.com/jcmvbkbc/xtensa-dynconfig/tree/original
   * https://github.com/jcmvbkbc/config-esp32s3   * https://github.com/jcmvbkbc/config-esp32s3
-  * https://github.com/jcmvbkbc/esp-idf/tree/linux-5.0.1 +  * https://github.com/jcmvbkbc/esp-hosted/tree/ipc-5.1.1 
-  * https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-6.4-esp32 +  * https://github.com/jcmvbkbc/linux-xtensa/tree/xtensa-6.10-rc2-esp32 
-  * https://github.com/jcmvbkbc/binutils-gdb-xtensa/tree/xtensa-2.40-fdpic +  * https://github.com/jcmvbkbc/binutils-gdb-xtensa/tree/xtensa-fdpic-abi-spec-1.4 
-  * https://github.com/jcmvbkbc/gcc-xtensa/tree/xtensa-14-fdpic +  * https://github.com/jcmvbkbc/gcc-xtensa/tree/xtensa-fdpic-abi-spec-1.4 
-  * https://github.com/jcmvbkbc/uclibc-ng-xtensa/tree/xtensa-fdpic +  * https://github.com/jcmvbkbc/uclibc-ng-xtensa/tree/xtensa-fdpic-abi-spec-1.4 
-  * https://github.com/jcmvbkbc/buildroot/tree/xtensa-2023.08-fdpic+  * https://github.com/jcmvbkbc/buildroot/tree/xtensa-2024.02-fdpic
   * https://github.com/jcmvbkbc/crosstool-NG/tree/xtensa-fdpic   * https://github.com/jcmvbkbc/crosstool-NG/tree/xtensa-fdpic
  
 Scripts with all steps below: https://github.com/jcmvbkbc/esp32-linux-build 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 ===== ===== 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. The firmware 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, ...   * 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.   * 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.   * 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).   * 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).   * 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 ===== ===== Things that don't work =====
  
-  * c++ exceptions. Not yet. +  * 193 failing tests in the gcc testsuite, 340 failing tests in the g++ testsuite. This is now mostly on par with the regular xtensa ELF toolchain. 
-  * 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.   * 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.   * 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.
Line 63: Line 75:
 $ CT_PREFIX=`pwd`/builds nice ./ct-ng build $ CT_PREFIX=`pwd`/builds nice ./ct-ng build
 $ popd $ popd
-</code> 
- 
-It doesn't complete successfully ATM, failing with the following message, but it builds and installs everything that's important. 
-<code> 
-... 
-[INFO ]  Installing final gcc compiler: done in 572.47s (at 29:47) 
-[INFO ]  ================================================================= 
-[INFO ]  Checking dynamic linker symlinks 
-[EXTRA]    Checking dynamic linker for multilib '' 
-[ERROR]    collect2: error: ld returned 1 exit status 
-[ERROR]    
-[ERROR]  >> 
-[ERROR]  >>  Build failed in step 'Checking dynamic linker symlinks' 
-[ERROR]  >>        called in step '(top-level)' 
-[ERROR]  >> 
-[ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@377] 
-[ERROR]  >>        called from: CT__FixupLDSO[scripts/functions@1695] 
-[ERROR]  >>        called from: CT_IterateMultilibs[scripts/functions@1608] 
-[ERROR]  >>        called from: CT_MultilibFixupLDSO[scripts/functions@1761] 
-[ERROR]  >>        called from: uClibc_ng_post_cc[scripts/build/libc/uClibc-ng.sh@335] 
-[ERROR]  >>        called from: do_libc_post_cc[scripts/build/libc.sh@38] 
-[ERROR]  >>        called from: main[scripts/crosstool-NG.sh@697] 
-[ERROR]  >> 
-... 
 </code> </code>
  
Line 92: Line 80:
  
 <code> <code>
-$ git clone https://github.com/jcmvbkbc/buildroot -b xtensa-2023.08-fdpic+$ git clone https://github.com/jcmvbkbc/buildroot -b xtensa-2024.02-fdpic
 $ nice make -C buildroot O=`pwd`/build-buildroot-esp32s3 esp32s3_defconfig $ nice make -C buildroot O=`pwd`/build-buildroot-esp32s3 esp32s3_defconfig
 $ buildroot/utils/config --file build-buildroot-esp32s3/.config --set-str TOOLCHAIN_EXTERNAL_PATH `pwd`/crosstool-NG/builds/xtensa-esp32s3-linux-uclibcfdpic $ buildroot/utils/config --file build-buildroot-esp32s3/.config --set-str TOOLCHAIN_EXTERNAL_PATH `pwd`/crosstool-NG/builds/xtensa-esp32s3-linux-uclibcfdpic
Line 103: Line 91:
  
 <code> <code>
-$ git clone https://github.com/jcmvbkbc/esp-idf -b linux-5.0.1 +$ git clone https://github.com/jcmvbkbc/esp-hosted -b ipc-5.1.1 
-$ pushd esp-idf+$ pushd esp-hosted/esp_hosted_ng/esp/esp_driver 
 +$ cmake . 
 +$ cd esp-idf
 $ . export.sh $ . export.sh
-$ cd examples/get-started/linux_boot+$ cd ../network_adapter
 $ idf.py set-target esp32s3 $ idf.py set-target esp32s3
 $ cp sdkconfig.defaults.esp32s3 sdkconfig $ cp sdkconfig.defaults.esp32s3 sdkconfig
etc/users/jcmvbkbc/linux-xtensa/esp32s3.1696991265.txt.gz · Last modified: 2023/10/11 05:27 by jcmvbkbc