v4.4 on Raspberry Pi 4 ... "gcc is not able to compile a simple test program." (IDFGH-6180)

[csBlueChip]

Hi.

If I do this everything works exactly as expected:

# Install IDF
export IDF_TOOLS_PATH=/home/esp/tools/
mkdir /home/esp/idf
cd /home/esp/idf
git clone -b v4.3.1 --recursive https://github.com/espressif/esp-idf.git .
./install.sh

# Pull fix for broken CA file
cd /home/esp/idf/components/mbedtls/esp_crt_bundle
mv  cacrt_all.pem  cacrt_all.pem.orig
wget https://raw.githubusercontent.com/electrocucaracha/esp-idf/4e45f13e2df72a4cb4dc875942e95775198db85c/components/mbedtls/esp_crt_bundle/cacrt_all.pem

# Compile 'blink'
cp -pr  /home/esp/idf/examples/get-started/blink  /home/esp/blink/
cd /home/esp/blink
. /home/esp/idf/export.sh
idf.py  set-target  esp32s2
idf.py build

However, the author of TinyUSB (@hathach) has told me that TinyUSB does not (and will not in the forseeable future) do what I need, so I need to use v4.4 of the IDF.

If I erase everything (and clear the environment) ...and repeat all the above steps using -b release/v4.4, the set-target command fails with:

~/blink $ idf.py  set-target  esp32s2
Adding "set-target"'s dependency "fullclean" to list of commands with default set of options.
Executing action: fullclean
Build directory '/home/esp/blink/build' not found. Nothing to clean.
Executing action: set-target
Set Target to: esp32s2, new sdkconfig created. Existing sdkconfig renamed to sdkconfig.old.
Running cmake in directory /home/esp/blink/build
Executing "cmake -G Ninja -DPYTHON_DEPS_CHECKED=1 -DESP_PLATFORM=1 -DIDF_TARGET=esp32s2 -DCCACHE_ENABLE=0 /home/esp/blink"...
-- Found Git: /usr/bin/git (found version "2.20.1")
-- The C compiler identification is GNU 8.4.0
-- The CXX compiler identification is GNU 8.4.0
-- The ASM compiler identification is GNU
-- Found assembler: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-gcc
-- Check for working C compiler: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-gcc
-- Check for working C compiler: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-gcc -- broken
CMake Error at /usr/share/cmake-3.16/Modules/CMakeTestCCompiler.cmake:60 (message):
  The C compiler

    "/home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-gcc"
  is not able to compile a simple test program.
  It fails with the following output:
    Change Dir: /home/esp/blink/build/CMakeFiles/CMakeTmp

    Run Build Command(s):/usr/bin/ninja cmTC_a0212 && [1/2] Building C object CMakeFiles/cmTC_a0212.dir/testCCompiler.c.obj
    [2/2] Linking C executable cmTC_a0212
    FAILED: cmTC_a0212
    : && /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-gcc -mlongcalls   CMakeFiles/cmTC_a0212.dir/testCCompiler.c.obj  -o cmTC_a0212   && :
    /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../lib/gcc/xtensa-esp32s2-elf/8.4.0/../../../../xtensa-esp32s2-elf/bin/ld: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so: error loading plugin: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so: cannot open shared object file: No such file or directory
    collect2: error: ld returned 1 exit status
    ninja: build stopped: subcommand failed.

  CMake will not be able to correctly generate this project.
Call Stack (most recent call first):
  /home/esp/idf/tools/cmake/project.cmake:290 (__project)
  CMakeLists.txt:8 (project)

-- Configuring incomplete, errors occurred!
See also "/home/esp/blink/build/CMakeFiles/CMakeOutput.log".
See also "/home/esp/blink/build/CMakeFiles/CMakeError.log".
cmake failed with exit code 1

The directory /home/esp/blink/build/CMakeFiles/CMakeTmp DOES exist:

~/blink $ ls -ald /home/esp/blink/build/CMakeFiles/CMakeTmp
drwxr-xr-x 2 esp esp 4096 Nov  8 21:27 /home/esp/blink/build/CMakeFiles/CMakeTmp

And so does /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so:

~/blink $ ls -al /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so*
lrwxrwxrwx 1 esp esp    22 Nov  8 21:25 /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so -> liblto_plugin.so.0.0.0
lrwxrwxrwx 1 esp esp    22 Nov  8 21:25 /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so.0 -> liblto_plugin.so.0.0.0
-rwxr-xr-x 1 esp esp 71508 Oct 15 07:35 /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so.0.0.0

The log files don't give me any further clues:

~/blink $ cat build/CMakeFiles/CMakeError.log
Compiling the C compiler identification source file "CMakeCCompilerId.c" failed.
Compiler: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-gcc
Build flags: -mlongcalls
Id flags:

The output was:
1
/home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../lib/gcc/xtensa-esp32s2-elf/8.4.0/../../../../xtensa-esp32s2-elf/bin/ld: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so: error loading plugin: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so: cannot open shared object file: No such file or directory
collect2: error: ld returned 1 exit status

Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" failed.
Compiler: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-g++
Build flags: -mlongcalls
Id flags:

The output was:
1
/home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../lib/gcc/xtensa-esp32s2-elf/8.4.0/../../../../xtensa-esp32s2-elf/bin/ld: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so: error loading plugin: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so: cannot open shared object file: No such file or directory
collect2: error: ld returned 1 exit status

Determining if the C compiler works failed with the following output:
Change Dir: /home/esp/blink/build/CMakeFiles/CMakeTmp

Run Build Command(s):/usr/bin/ninja cmTC_a0212 && [1/2] Building C object CMakeFiles/cmTC_a0212.dir/testCCompiler.c.obj
[2/2] Linking C executable cmTC_a0212
FAILED: cmTC_a0212
: && /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-gcc -mlongcalls   CMakeFiles/cmTC_a0212.dir/testCCompiler.c.obj  -o cmTC_a0212   && :
/home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../lib/gcc/xtensa-esp32s2-elf/8.4.0/../../../../xtensa-esp32s2-elf/bin/ld: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so: error loading plugin: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/../libexec/gcc/xtensa-esp32s2-elf/8.4.0/liblto_plugin.so: cannot open shared object file: No such file or directory
collect2: error: ld returned 1 exit status
ninja: build stopped: subcommand failed.

~/blink $ cat build/CMakeFiles/CMakeOutput.log
The target system is: Generic -  -
The host system is: Linux - 5.10.63-v7l+ - armv7l
Compiling the C compiler identification source file "CMakeCCompilerId.c" succeeded.
Compiler: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-gcc
Build flags: -mlongcalls
Id flags: -c

The output was:
0

Compilation of the C compiler identification source "CMakeCCompilerId.c" produced "CMakeCCompilerId.o"

The C compiler identification is GNU, found in "/home/esp/blink/build/CMakeFiles/3.16.3/CompilerIdC/CMakeCCompilerId.o"

Compiling the CXX compiler identification source file "CMakeCXXCompilerId.cpp" succeeded.
Compiler: /home/esp/tools/tools/xtensa-esp32s2-elf/esp-2021r2-8.4.0/xtensa-esp32s2-elf/bin/xtensa-esp32s2-elf-g++
Build flags: -mlongcalls
Id flags: -c

The output was:
0

Compilation of the CXX compiler identification source "CMakeCXXCompilerId.cpp" produced "CMakeCXXCompilerId.o"

The CXX compiler identification is GNU, found in "/home/esp/blink/build/CMakeFiles/3.16.3/CompilerIdCXX/CMakeCXXCompilerId.o"

Checking whether the ASM compiler is GNU using "--version" matched "(GNU assembler)|(GCC)|(Free Software Foundation)":
xtensa-esp32s2-elf-gcc (crosstool-NG esp-2021r2) 8.4.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

The same error happens if I use master or 4.4-dev branches, or if I use git to switch branches from 4.3.1 (as per the official docs) ...IE. 4.3.1 is the only version I can get to work - and I need v4.4 for the native USB support!

I'm out of ideas! Can anybody help please?

Thanks, BC

[felmue]

Hello @csBlueChip

I don't get the error you are reporting with either master or release/v4.4. Here are the steps I use on Ubuntu 20.04 after deleting .espressif and esp directories (e.g. fresh install):

mkdir esp
cd esp
git clone -b release/v4.4 --recursive https://github.com/espressif/esp-idf.git
cd esp-idf
./install.sh
. ./export.sh
cd ..
cp -r esp-idf/examples/get-started/blink .
cd blink
idf.py set-target esp32s2
idf.py build

Hopefully this can shed some light on the issue you are seeing.

Thanks Felix

P.S. Have you verified there is enough free space on your drive?

[csBlueChip]

@felmue

Felix. Thank You. Your success has led me to the source of my problem!

I pasted your exact commands to a "clean" user, and got the same problem (again) ...Then I repeated the exercise on an x86 Debian VM! ...Success!

It seems the source of the problem is that I have been using a Raspberry Pi 4 as my μC dev box ...release/v4.4 DOES work on x86/Debian; and does NOT work Pi4/Raspbian.

$ uname -a
Linux devserver 5.10.63-v7l+ #1459 SMP Wed Oct 6 16:41:57 BST 2021 armv7l GNU/Linux

$ cat /etc/os-release
PRETTY_NAME="Raspbian GNU/Linux 10 (buster)"
NAME="Raspbian GNU/Linux"
VERSION_ID="10"
VERSION="10 (buster)"
VERSION_CODENAME=buster
ID=raspbian
ID_LIKE=debian
HOME_URL="http://www.raspbian.org/"
SUPPORT_URL="http://www.raspbian.org/RaspbianForums"
BUG_REPORT_URL="http://www.raspbian.org/RaspbianBugs"

I'm not sure if you are the right person to ask this question, but: Is IDF v4.4 expected to work on a Pi4? ...Should I change the title of this Issue? Or start another? Or <other please specify>? ...Either way I offer my help to test any potential fixes.

On the bright side, Thank You for prompting me to realise the issue and find a functional workaround.

BC

PS. Yes. There is sufficient free space:

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
/dev/root        31G   13G   17G  43% /
...
...

[felmue]

Hello @csBlueChip

Thank you for your feedback. Unfortunately I don't know it IDF v4.4 is supposed to work on a Pi4 at this point in time and I don't posses a Pi4 so I cannot test myself. So yes, I'd suggest you change the title to indicate the issue is in conjunction with the Pi4. Hopefully somebody with better knowledge than me can help you figuring out what's causing the issue on the Pi4.

Thanks Felix

[0xjakob]

@csBlueChip Our tools team is looking into this issue currently.

[csBlueChip]

Hey @0xjakob, Do you have any update on this issue? Cheers, BC

[wuxx]

same problem on my raspberry pi 4 after update the esp-idf to latest code on master branch

[wuxx]

it seems that the toolchain has some problems. the command line: ~/oss/esp-idf/examples/get-started/blink/build/CMakeFiles $ /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc 3.16.3/CompilerIdC/CMakeCCompilerId.c /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: error loading plugin: /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: cannot open shared object file: No such file or directory

if use host gcc, compile is ok. pi@raspberrypi:~/oss/esp-idf/examples/get-started/blink/build/CMakeFiles $ gcc 3.16.3/CompilerIdC/CMakeCCompilerId.c pi@raspberrypi:~/oss/esp-idf/examples/get-started/blink/build/CMakeFiles $ ls 3.16.3 a.out cmake.check_cache CMakeError.log CMakeOutput.log CMakeTmp git-data

[wuxx]

ok.... after add these params, compile is ok now.. -fno-lto -fno-use-linker-plugin

pi@raspberrypi:~/oss/esp-idf/examples/get-started/blink/build/CMakeFiles $ /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -fno-lto -fno-use-linker-plugin 3.16.3/CompilerIdC/CMakeCCompilerId.c pi@raspberrypi:~/oss/esp-idf/examples/get-started/blink/build/CMakeFiles $ ls 3.16.3 a.out cmake.check_cache CMakeError.log CMakeOutput.log CMakeTmp git-data

[wuxx]

@zikalino zikalino

[jmbr]

Hi,

I'm experiencing the same issue. I thought I'd mention that if instead of using . export.sh I directly execute ~/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/xtensa-esp32-elf-gcc -c foo.c -o foo then the compiler has no problem producing a binary executable. However, every attempt at compiling anything via idf.py fails with the same error reported by @csBlueChip above.

If there's something I can do to narrow this issue down and help you debug it, please let me know.

[igrr]

Thanks for reporting and sorry for the late response! Could you please run ldd ~/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so and paste the output here?

[rrobinet]

pi@raspberrypi:~/esp/hello_world $ ldd ~/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so
    not a dynamic executable

[rrobinet]

always the same type of error /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: error loading plugin: /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: cannot open shared object file: No such file or directory

and

pi@raspberrypi:~/esp/hello_world $ ls -l /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld
-rwxr-xr-x 4 pi pi 1285276 Oct 15 08:33 /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld
pi@raspberrypi:~/esp/hello_world $ ls -l /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so
lrwxrwxrwx 1 pi pi 22 Jan  5 17:36 /home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so -> liblto_plugin.so.0.0.0

[jmbr]

Thank you for following up, @igrr.

I get the same "not a dynamic executable" message from ldd that @rrobinet reports. I'm pasting below the result of running objdump -p ~/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so.0.0.0 in the hopes that it helps.

/home/pi/.espressif/tools/xtensa-esp32-elf/esp-2021r2-8.4.0/xtensa-esp32-elf/libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so.0.0.0:     file format elf32-littlearm

Program Header:
    LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16
         filesz 0x0001099c memsz 0x0001099c flags r-x
    LOAD off    0x00010da0 vaddr 0x00020da0 paddr 0x00020da0 align 2**16
         filesz 0x00000470 memsz 0x00000524 flags rw-
 DYNAMIC off    0x00010f08 vaddr 0x00020f08 paddr 0x00020f08 align 2**2
         filesz 0x000000f8 memsz 0x000000f8 flags rw-
    NOTE off    0x000000f4 vaddr 0x000000f4 paddr 0x000000f4 align 2**2
         filesz 0x00000024 memsz 0x00000024 flags r--
   STACK off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**4
         filesz 0x00000000 memsz 0x00000000 flags rw-
   RELRO off    0x00010da0 vaddr 0x00020da0 paddr 0x00020da0 align 2**0
         filesz 0x00000260 memsz 0x00000260 flags r--

Dynamic Section:
  NEEDED               libstdc++.so.6
  NEEDED               libm.so.6
  NEEDED               libc.so.6
  SONAME               liblto_plugin.so.0
  INIT                 0x00001ee0
  FINI                 0x0000f5d0
  INIT_ARRAY           0x00020da0
  INIT_ARRAYSZ         0x00000004
  FINI_ARRAY           0x00020da4
  FINI_ARRAYSZ         0x00000004
  GNU_HASH             0x00000118
  STRTAB               0x00000e6c
  SYMTAB               0x000003ec
  STRSZ                0x00000841
  SYMENT               0x00000010
  PLTGOT               0x00021000
  PLTRELSZ             0x00000368
  PLTREL               0x00000011
  JMPREL               0x00001b78
  REL                  0x00001830
  RELSZ                0x00000348
  RELENT               0x00000008
  VERNEED              0x00001800
  VERNEEDNUM           0x00000001
  VERSYM               0x000016ae
  RELCOUNT             0x00000056

Version References:
  required from libc.so.6:
    0x06969191 0x00 03 GLIBC_2.11
    0x0d696914 0x00 02 GLIBC_2.4
private flags = 5000200: [Version5 EABI] [soft-float ABI]

[rrobinet]

Just for info I did install version 4.3 which is working fine

[will-emmerson]

I have the same problem and had to go back to v4.3.1 (esp-2021r1-8.4.0) to fix it as v.4.3.2 (stable) uses the newer compiler.

[phucng]

I confirm that v4.3.1 (esp-2021r1-8.4.0) works on a Raspberry Pi 3 running Debian 11 (bullseye), while v4.3.2 (stable, uses esp-2021r2-8.4.0) doesn't work and yields the same issue as above.

Edit: there is no file named liblto_plugin.so in ~/.espressif/tools/xtensa-esp32-elf/esp-2021r1-8.4.0. This file seems to be a new dependency in esp-2021r2-8.4.0 (which has liblto_plugin.so but still doesn't work.)

[RSC-Games]

I also confirm that v4.3.1 (esp-2021r1-8.4.0) works on Raspberry Pi 4 (2 GB model) with Raspberry Pi OS 32 bit (based on Debian 11). However, IDF v4.4 and v4.3.1 do NOT work, for the same issue as described as OP. I also investigated whether said file was present and it was.

[fivdi]

My heart goes out to all those waiting for this issue to be fixed. I have shed many a tear and wept daily since discovering this unfortunate problem. This issue is the source of persistent pain and great suffering and it will be a day of great joy and celebration when the issue is resolved.

[fivdi]

All the weeping due to this unfortunate issue resulted me having a chronic dehydration condition. However, what I have discovered is that ESP-IDF v4.4 and gcc do appear to work as expected for the ESP32 on a Raspberry Pi 4 if the 64-bit version of Raspberry Pi OS is used. Up until now I had been using the 32-bit version of Raspberry Pi OS as the 64-bit version was still in beta. This is no longer the case and the first non-beta 64-bit version of Raspberry Pi OS was released recently so I gave it a try.

Raspberry Pi OS 64-bit is being used:

pi@raspberrypi:~/src/hello_world $ uname -a
Linux raspberrypi 5.10.92-v8+ #1514 SMP PREEMPT Mon Jan 17 17:39:38 GMT 2022 aarch64 GNU/Linux

ESP-IDF v4.4 is being used:

pi@raspberrypi:~/src/hello_world $ idf.py --version
ESP-IDF v4.4

idf.py build functions as expected indicating that gcc can compile successfully:

pi@raspberrypi:~/src/hello_world $ idf.py build
Executing action: all (aliases: build)
Running ninja in directory /home/pi/src/hello_world/build
Executing "ninja all"...
[1/4] cd /home/pi/src/hello_world/buil.../src/hello_world/build/hello_world.bin
hello_world.bin binary size 0x29730 bytes. Smallest app partition is 0x100000 bytes. 0xd68d0 bytes (84%) free.
[2/4] Performing build step for 'bootloader'
[1/1] cd /home/pi/src/hello_world/build/bootloader/esp-idf/esptool_py && /home/pi/.espressif/python_env/idf4.4_py3.9_env/bin/python /home/pi/esp/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x1000 /home/pi/src/hello_world/build/bootloader/bootloader.bin
Bootloader binary size 0x62b0 bytes. 0xd50 bytes (12%) free.

Project build complete. To flash, run this command:
/home/pi/.espressif/python_env/idf4.4_py3.9_env/bin/python ../../esp/esp-idf/components/esptool_py/esptool/esptool.py -p (PORT) -b 460800 --before default_reset --after hard_reset --chip esp32  write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x1000 build/bootloader/bootloader.bin 0x8000 build/partition_table/partition-table.bin 0x10000 build/hello_world.bin
or run 'idf.py -p (PORT) flash'
pi@raspberrypi:~/src/hello_world $

idf.py -p /dev/ttyUSB0 flash functions as expected:

pi@raspberrypi:~/src/hello_world $ idf.py -p /dev/ttyUSB0 flash
Executing action: flash
Running ninja in directory /home/pi/src/hello_world/build
Executing "ninja flash"...
[1/5] cd /home/pi/src/hello_world/buil.../src/hello_world/build/hello_world.bin
hello_world.bin binary size 0x29730 bytes. Smallest app partition is 0x100000 bytes. 0xd68d0 bytes (84%) free.
[2/5] Performing build step for 'bootloader'
[1/1] cd /home/pi/src/hello_world/build/bootloader/esp-idf/esptool_py && /home/pi/.espressif/python_env/idf4.4_py3.9_env/bin/python /home/pi/esp/esp-idf/components/partition_table/check_sizes.py --offset 0x8000 bootloader 0x1000 /home/pi/src/hello_world/build/bootloader/bootloader.bin
Bootloader binary size 0x62b0 bytes. 0xd50 bytes (12%) free.
[2/3] cd /home/pi/esp/esp-idf/componen...nents/esptool_py/run_serial_tool.cmake
esptool.py esp32 -p /dev/ttyUSB0 -b 460800 --before=default_reset --after=hard_reset write_flash --flash_mode dio --flash_freq 40m --flash_size 4MB 0x1000 bootloader/bootloader.bin 0x10000 hello_world.bin 0x8000 partition_table/partition-table.bin
esptool.py v3.2-dev
Serial port /dev/ttyUSB0
Connecting....
Chip is ESP32-PICO-D4 (revision 1)
Features: WiFi, BT, Dual Core, Embedded Flash, Coding Scheme None
Crystal is 40MHz
MAC: d8:a0:1d:40:78:d8
Uploading stub...
Running stub...
Stub running...
Changing baud rate to 460800
Changed.
Configuring flash size...
Flash will be erased from 0x00001000 to 0x00007fff...
Flash will be erased from 0x00010000 to 0x00039fff...
Flash will be erased from 0x00008000 to 0x00008fff...
Compressed 25264 bytes to 15785...
Writing at 0x00001000... (100 %)
Wrote 25264 bytes (15785 compressed) at 0x00001000 in 0.7 seconds (effective 277.0 kbit/s)...
Hash of data verified.
Compressed 169776 bytes to 89622...
Writing at 0x00010000... (16 %)
Writing at 0x0001afdf... (33 %)
Writing at 0x00020758... (50 %)
Writing at 0x00025fa1... (66 %)
Writing at 0x0002e5b5... (83 %)
Writing at 0x00036945... (100 %)
Wrote 169776 bytes (89622 compressed) at 0x00010000 in 2.5 seconds (effective 538.7 kbit/s)...
Hash of data verified.
Compressed 3072 bytes to 103...
Writing at 0x00008000... (100 %)
Wrote 3072 bytes (103 compressed) at 0x00008000 in 0.0 seconds (effective 524.3 kbit/s)...
Hash of data verified.

Leaving...
Hard resetting via RTS pin...
Done
pi@raspberrypi:~/src/hello_world $ 

idf.py -p /dev/ttyUSB0 monitor functions as expected:

pi@raspberrypi:~/src/hello_world $ idf.py -p /dev/ttyUSB0 monitor
Executing action: monitor
Running idf_monitor in directory /home/pi/src/hello_world
Executing "/home/pi/.espressif/python_env/idf4.4_py3.9_env/bin/python /home/pi/esp/esp-idf/tools/idf_monitor.py -p /dev/ttyUSB0 -b 115200 --toolchain-prefix xtensa-esp32-elf- --target esp32 --revision 0 /home/pi/src/hello_world/build/hello_world.elf -m '/home/pi/.espressif/python_env/idf4.4_py3.9_env/bin/python' '/home/pi/esp/esp-idf/tools/idf.py' '-p' '/dev/ttyUSB0'"...
--- idf_monitor on /dev/ttyUSB0 115200 ---
--- Quit: Ctrl+] | Menu: Ctrl+T | Help: Ctrl+T followed by Ctrl+H ---
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:6604
ho 0 tail 12 room 4
load:0x40078000,len:14780
load:0x40080400,len:3792
0x40080400: _init at ??:?

entry 0x40080694
I (29) boot: ESP-IDF v4.4 2nd stage bootloader
I (29) boot: compile time 23:33:05
I (29) boot: chip revision: 1
I (32) boot_comm: chip revision: 1, min. bootloader chip revision: 0
I (39) boot.esp32: SPI Speed      : 40MHz
I (44) boot.esp32: SPI Mode       : DIO
I (48) boot.esp32: SPI Flash Size : 4MB
I (53) boot: Enabling RNG early entropy source...
I (58) boot: Partition Table:
I (62) boot: ## Label            Usage          Type ST Offset   Length
I (69) boot:  0 nvs              WiFi data        01 02 00009000 00006000
I (77) boot:  1 phy_init         RF data          01 01 0000f000 00001000
I (84) boot:  2 factory          factory app      00 00 00010000 00100000
I (92) boot: End of partition table
I (96) boot_comm: chip revision: 1, min. application chip revision: 0
I (103) esp_image: segment 0: paddr=00010020 vaddr=3f400020 size=07784h ( 30596) map
I (122) esp_image: segment 1: paddr=000177ac vaddr=3ffb0000 size=02340h (  9024) load
I (126) esp_image: segment 2: paddr=00019af4 vaddr=40080000 size=06524h ( 25892) load
I (141) esp_image: segment 3: paddr=00020020 vaddr=400d0020 size=14a40h ( 84544) map
I (172) esp_image: segment 4: paddr=00034a68 vaddr=40086524 size=04c84h ( 19588) load
I (180) esp_image: segment 5: paddr=000396f4 vaddr=50000000 size=00010h (    16) load
I (186) boot: Loaded app from partition at offset 0x10000
I (186) boot: Disabling RNG early entropy source...
I (201) cpu_start: Pro cpu up.
I (201) cpu_start: Starting app cpu, entry point is 0x40080fe8
0x40080fe8: call_start_cpu1 at /home/pi/esp/esp-idf/components/esp_system/port/cpu_start.c:156

I (0) cpu_start: App cpu up.
I (215) cpu_start: Pro cpu start user code
I (215) cpu_start: cpu freq: 160000000
I (215) cpu_start: Application information:
I (219) cpu_start: Project name:     hello_world
I (225) cpu_start: App version:      1
I (229) cpu_start: Compile time:     Feb 10 2022 23:32:46
I (235) cpu_start: ELF file SHA256:  5e34838f30b80de0...
I (241) cpu_start: ESP-IDF:          v4.4
I (246) heap_init: Initializing. RAM available for dynamic allocation:
I (253) heap_init: At 3FFAE6E0 len 00001920 (6 KiB): DRAM
I (259) heap_init: At 3FFB2C28 len 0002D3D8 (180 KiB): DRAM
I (266) heap_init: At 3FFE0440 len 00003AE0 (14 KiB): D/IRAM
I (272) heap_init: At 3FFE4350 len 0001BCB0 (111 KiB): D/IRAM
I (278) heap_init: At 4008B1A8 len 00014E58 (83 KiB): IRAM
I (286) spi_flash: detected chip: gd
I (289) spi_flash: flash io: dio
I (294) cpu_start: Starting scheduler on PRO CPU.
I (0) cpu_start: Starting scheduler on APP CPU.
Hello world!
This is esp32 chip with 2 CPU core(s), WiFi/BT/BLE, silicon revision 1, 4MB embedded flash
Minimum free heap size: 293268 bytes
Restarting in 10 seconds...
Restarting in 9 seconds...
Restarting in 8 seconds...
Restarting in 7 seconds...
Restarting in 6 seconds...
Restarting in 5 seconds...
Restarting in 4 seconds...
Restarting in 3 seconds...
Restarting in 2 seconds...
Restarting in 1 seconds...
Restarting in 0 seconds...
Restarting now.
ets Jun  8 2016 00:22:57

rst:0xc (SW_CPU_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 188777542, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:6604
ho 0 tail 12 room 4
load:0x40078000,len:14780
load:0x40080400,len:3792
0x40080400: _init at ??:?

entry 0x40080694
I (29) boot: ESP-IDF v4.4 2nd stage bootloader
...

So I am now happy 😄

I guess it's only the 32-bit Xtensa compilers that are broken the 64-bit compilers appear to work.

[phucng]

Thank @fivdi, for cheering and guiding us through these dark times. The latest version also works on my Pi after moving to the 64-bit Raspberry PI OS.

However, many of us cannot ditch the 32-bit OS and reinstall everything, at least until their next holiday. Some even have to stay 32-bit for compatibility. I hope that this issue will not be closed until addressed.

[zikalino]

all, the fix for this issue should be available in master soon, i will keep an eye on updates, and post more information soon

[csBlueChip]

Is there any more information available yet?

[antmak]

@csBlueChip We are on our way to get a new release of the toolchain. It is a big release with updating GCC and newlib versions. There is a chance to get a fix for the issue too

[csBlueChip]

Thank you. After 3 years of waiting, it is good to know that Espressif are "on their way" to releasing a devkit which will unlock the USB features of the chip, and there is "a chance" that it will work :)

[RSC-Games]

Any new updates on this? I installed 64 bit RPi OS recently, but I have yet to migrate my whole toolchain (which is based on a modified MicroPython codebase). I would like to update to IDF 4.4 (for ESP32 S3 support), but I am unable. I have a working executable generated from IDF 4.2.0, but I would prefer to use IDF 4.4.

[antmak]

Hi @RSC-Games ! The new toolchain with ARM*@linux fixes will come to master branch already on these days. Also the fixes will be ported to v4.4, but I'm not sure about ETA

[MMucka]

Hi, I have got also this problem on v4.4 with Raspberry Pi 4. As I read, the v4.4. should be supported on Raspberry Pi 4, but it is still not. Can you please keep this issue open until the fix will be available?

[antmak]

@MMucka right, for v4.4 we can open this

[MMucka]

What I have done:

cd ~/esp/esp-idf
git fetch
git checkout remotes/origin/release/v4.4
git submodule update --init --recursive
~/esp/esp-idf/install.sh esp32c3
. ~/esp/esp-idf/export.sh

but in tools, there is still old gcc

ls ~/.espressif/tools/riscv32-esp-elf
esp-2021r2-patch3-8.4.0

So I tried to apply changes from https://github.com/espressif/esp-idf/commit/bf43076c044a58429ebd90ac508e32dd82321af1 for tools/tools.json and tools/toolchain_version.mk, but I have still problem to build simple test program.

[RSC-Games]

I have not verified that the latest commit works, because I migrated my toolchain to rpi 4 64 bit on Monday. I'll have to dig out my 32 bit sd card.

However, when I cloned IDF 5.0 it reported using GCC 11.2 and the compiler was esp-2022r1. I'm running IDF 4.4 and it reports using GCC 8.4 and esp-2021r2. This works for me, but then again I'm using 64 bit. If you can, then I would suggest using IDF 5.0, but for me, Micropython does not support IDF 5, so I'm stuck with 4.4.

[Alvin1Zhang]

Thanks for reporting, fix is available at https://github.com/espressif/esp-idf/commit/00077545bf23134379133cfd979aaad35d5f3552, feel free to reopen.

[lanwin]

Is this fix not available in the latest 5.1.2?

I still get:

&& /config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/xtensa-esp32-elf-gcc -mlongcalls -Wno-frame-address   CMakeFiles/cmTC_d0ead.dir/testCCompiler.c.obj  -o cmTC_d0ead   && :
/config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/../lib/gcc/xtensa-esp32-elf/8.4.0/../../../../xtensa-esp32-elf/bin/ld: /config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: error loading plugin: /config/.esphome/platformio/packages/toolchain-xtensa-esp32/bin/../libexec/gcc/xtensa-esp32-elf/8.4.0/liblto_plugin.so: cannot open shared object file: No such file or directory