ESP32-C3 riscv32

[ccrause]

From your gitlab ccrause

around 5250 compiler/options.pas there is this, as it does not respond in RISCV32, the idf_version is still not being set.

Code: Pascal  [Select][+][-]

1. {$ifdef XTENSA}
2.   { set ESP32 or ESP8266 default SDK versions }
3.   option.MaybeSetIdfVersionMacro;
4. {$endif XTENSA}

Davo

Thanks Davo, I will fix this.  The default setting is not really useful, unless it happens to coincide with the provided esp-idf libraries version.  I strongly suggest specifying the esp-idf version via the -WP command line option (once the basics are sorted of course).

[dbannon]

....I strongly suggest specifying the esp-idf version via the -WP command line option (once the basics are sorted of course).

Great !  -WP ?  what is the syntax, my compiler does not mention it with a -h  ? Does not like it if I use -WP40400

[ccrause]

....I strongly suggest specifying the esp-idf version via the -WP command line option (once the basics are sorted of course).

Great !  -WP ?  what is the syntax, my compiler does not mention it with a -h  ? Does not like it if I use -WP40400

It is briefly mentioned on the xtensa wiki page:

  Note: Different versions of esp-idf require different libraries to link. Use the -WP command line option to specify the version number, e.g. -WP4.3.2.

It should also be documented as part of the compiler help output, but this help entry is missing for the riscv cross compiler.

[dbannon]

Ah, makes sense. One thing I am reasonable at is documenting, might have some fun later down this path.

Anyway, I forced a valid idf_version number and we proceeded to linking. And the linker rejects my *.a files (scrapped from the helloworld demo) because they contain, wait for it, Xtensa, obj files !

Code: [Select]

dbannon@dell:~/esp/riscv32-esp32-elf-libs$ file espnow.o
espnow.o: ELF 32-bit LSB relocatable, Tensilica Xtensa, version 1 (SYSV), not stripped
Going to have to roll back a long way and find what I did wrong there !  Last you will see of me tonight.

Davo

[ccrause]

Anyway, I forced a valid idf_version number and we proceeded to linking. And the linker rejects my *.a files (scrapped from the helloworld demo) because they contain, wait for it, Xtensa, obj files !

Code: [Select]

dbannon@dell:~/esp/riscv32-esp32-elf-libs$ file espnow.o
espnow.o: ELF 32-bit LSB relocatable, Tensilica Xtensa, version 1 (SYSV), not stripped
Going to have to roll back a long way and find what I did wrong there !  Last you will see of me tonight.

Davo

The default build target in esp-idf is esp32.  To change this do:

Code: Bash  [Select][+][-]

1. idf.py set-target esp32c3

in your esp-idf example folder.

[ccrause]

Code: Pascal  [Select][+][-]

1. {$ifdef RISCV32)}
2.     ct_esp32c3:
3.       begin
4.         set_system_compvar('IDF_VERSION','40400');
5.         idf_version:=40400;
6.       end;
7. {$endif RISCV32}

Need to get rid of the curved bracket, ")" from ifdef line.

But I am afraid even more trouble, once that block of code is exposed, it seems that current_settings.controllertype is not, in fact, set to ct_esp32c3 there !

The controller type should be specified by a command line option (-Wpesp32c3), or am I missing something else?

[MiR]

Hmm, Christo, now you got me confused..

Which version for esp-idf do you want to use for risc? I read about 5.0.6 earlier and now in your last comment it seems 4.4

I am currently doing a script to be able to have compilers/libs/bootloaders for 4.4, 5.0.6 and 5.2.1 for devices

esp32 esp32s2 esp32s3 esp32c3 esp32c6 (Not everything available everywhere)

Michael

[ccrause]

Hmm, Christo, now you got me confused..

Which version for esp-idf do you want to use for risc? I read about 5.0.6 earlier and now in your last comment it seems 4.4

I am currently doing a script to be able to have compilers/libs/bootloaders for 4.4, 5.0.6 and 5.2.1 for devices

esp32 esp32s2 esp32s3 esp32c3 esp32c6 (Not everything available everywhere)

Michael

I started with the v5.0 (latest fixes, so v5.0.6) branch because there already was an esp32c3idf_50000.pp unit in rtl/freertos/riscv32/. The riscv32 code in the t_freertos unit copied a lot of the esp32 code, hence the version checks do not always seem to match up yet. Once I get something working I will add support for different versions.

Edit: The v4.4 is also just copy/paste to get the functionality in place, not to reflect any specific preference.

[MiR]

I have now created a branch:

https://github.com/michael-ring/espsdk4fpc/tree/devel

which currently allows you to build sdk and binutils for 4.4.7 and 5.0.6 (and likely some other versions...)

Christo, can you please have a look if things are roughly in the right place and complete?

Supported chips are currently esp32 esp32s2 esp32s3 and esp32c3

with 5.2.1 Espressif releases common binutils for all xpressif chips, same as for risc5, so for the future this would be a nice target (and it has support for esp32c6). I did not feel like already doing the necessary changes, when you want to work in this direction I can make the code also work with 5.2.1 sdk

esp32s2 and esp32s3 are lx7 but I kept the lx6 directory, let me know if you would like to change this.

I also splitted into debug / release directories, although currently I have no proper sdkconfig files for debug so actually the debug files are identical to the release files, feel free to create a PR to change this...

Michael

[ccrause]

I have now created a branch:

https://github.com/michael-ring/espsdk4fpc/tree/devel

which currently allows you to build sdk and binutils for 4.4.7 and 5.0.6 (and likely some other versions...)

Christo, can you please have a look if things are roughly in the right place and complete?

Thank you Michael!  I finally got to the point where FPC can link against esp32c3 libraries without conflicts.  I want to test the generated executable to check if it is actually working, then I will dive into espsdk4fpc.

[dbannon]

And the linker rejects my *.a files (scrapped from the helloworld demo) because they contain, wait for it, Xtensa, obj files !

The default build target in esp-idf is esp32.  To change this do:

Code: Bash  [Select][+][-]

1. idf.py set-target esp32c3

in your esp-idf example folder.

No, the github repo itself contains a whole lot of prebuilt *.a archives. See (libcore.a for example) -

Code: [Select]

bannon@dell:~/esp/hello_world$ find ~/esp/esp-idf/components -name "*.a" | grep libcore
/home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32s3/libcore.a
/home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32c3/libcore.a
/home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32s2/libcore.a
/home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32c2/libcore.a
/home/dbannon/esp/esp-idf/components/esp_wifi/lib/esp32/libcore.a
As the find/copy command finds them, it will over write the previous one so its quite unpredictable as to which one you end up with in riscv32-esp32-elf-libs. Selecting only archives that have esp32c3 in their pathname solved that problem.

But (with your latest commits) -

Code: [Select]

/home/dbannon/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libc.a
/home/dbannon/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libm.a
/home/dbannon/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libgcc.a
[0.055] hello.pas(4,18) Error: Error while linking
[0.055] hello.pas(4,18) Fatal: There were 1 errors compiling module, stopping
Davo

[ccrause]

Code: [Select]

/home/dbannon/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libc.a
/home/dbannon/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libm.a
/home/dbannon/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find libgcc.a
[0.055] hello.pas(4,18) Error: Error while linking
[0.055] hello.pas(4,18) Fatal: There were 1 errors compiling module, stopping

These libraries are part of the Gnu toolchain distribution and can be found here (obviously computer specific):

Code: Text  [Select][+][-]

1. ~/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/lib/gcc/riscv32-esp-elf/11.2.0/rv32imc/ilp32/no-rtti
2. ~/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/riscv32-esp-elf/lib/rv32imc/ilp32/no-rtti

For all the settings I'm using, see the below summary for riscv32-freertos in my fpc.cfg:

Code: Text  [Select][+][-]

1. #ifdef cpuriscv32
2.   -Fu~/fpc/installs/lib/fpc/$fpcversion/units/$fpctarget/*/$fpcsubarch
3.   #ifdef CPUrv32imc
4.     -XPriscv32-esp-elf-
5.     #ifdef freertos
6.      # esp-idf libraries
7.      -Fl/home/christo/fpc/xtensa/esp-idf-5.0.6/libs-esp32c3
8.      -Ff/home/christo/fpc/xtensa/esp-idf-5.0.6
9.      -WP5.0.6
10.      -FD/home/christo/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/bin
11.      -Fl/home/christo/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/lib/gcc/riscv32-esp-elf/11.2.0/rv32imc/ilp32/no-rtti
12.      -Fl/home/christo/.espressif/tools/riscv32-esp-elf/esp-2022r1-11.2.0/riscv32-esp-elf/riscv32-esp-elf/lib/rv32imc/ilp32/no-rtti
13.     #endif freertos
14.     -Wpesp32c3
15.   #endif CPUrv32imc
16. #endif cpuriscv32

Note: Later, when all is working and updated in fpcupdeluxe, the folder structure will obviously be different, this is just how I happen to arrange things for now.

To see where all the used libraries in the example project are located, go the the esp-idf example build sub folder, open the $example.map file and search for the library name. The map file is also useful to see which library is supplying which symbol, if you end up in a situation where the linker cannot locate a symbol in a FPC project.

EDIT: Fixed paths to toolchain library folders

[ccrause]

Current status of a simple blink Pascal project:

Code: [Select]

I (8609) cpu_start: cpu freq: 160000000 Hz
I (8632) cpu_start: Application information:
I (8647) cpu_start: Project name:     blink
I (8665) cpu_start: App version:      1
I (8677) cpu_start: Compile time:     May 18 2024 17:46:58
I (8698) cpu_start: ELF file SHA256:  6c88b520a176f320...
I (8720) cpu_start: ESP-IDF:          v5.0.6
I (8738) cpu_start: Min chip rev:     v0.3
I (8764) cpu_start: Max chip rev:     v1.99
I (8791) cpu_start: Chip rev:         v0.3
I (8839) heap_init: Initializing. RAM available for dynamic allocation:
I (8904) heap_init: At 3FC8D600 len 0004F110 (316 KiB): DRAM
I (8946) heap_init: At 3FCDC710 len 00002950 (10 KiB): STACK/DRAM
I (8992) heap_init: At 50000010 len 00001FD8 (7 KiB): RTCRAM
Guru Meditation Error: Core  0 panic'ed (Instruction access fault). Exception was unhandled.
The problem is located in the startup code function __smakebuf_r which is called during the initialization of the heap memory on the SDK side (before the Pascal code is loaded). The problem is that the FPC linked binary contains a version of __smakebuf_r that is slightly different from the esp-idf linked example, even though both examples are linked to the same libc library.

Working version:

Code: Text  [Select][+][-]

1. 4200ae8a <__smakebuf_r>:
2. ...
3. 4200af04:   cf91                   beqz   a5,4200af20 <__smakebuf_r+0x96>
4. 4200af06:   00e41583          lh   a1,14(s0)
5. 4200af0a:   8526                  mv   a0,s1
6. 4200af0c:   f7bf80ef             jal   ra,42003e86 <_getpid_r>
7. 4200af10:   c901                  beqz   a0,4200af20 <__smakebuf_r+0x96>
8. 4200af12:   00c45783          lhu   a5,12(s0)

Non-working version:

Code: Text  [Select][+][-]

1. 4200abe6 <__smakebuf_r>:
2. ...
3. 4200ac60:   c385                   beqz   a5,4200ac80 <__smakebuf_r+0x9a>
4. 4200ac62:   00e41583             lh   a1,14(s0)
5. 4200ac66:   8526                   mv   a0,s1
6. 4200ac68:   fdff5097             auipc   ra,0xfdff5
7. 4200ac6c:   718080e7             jalr   1816(ra) # 40000380 <_isatty_r>
8. 4200ac70:   c901                   beqz   a0,4200ac80 <__smakebuf_r+0x9a>
9. 4200ac72:   00c45783             lhu   a5,12(s0)

Looking at the object code for __smakebuf_r in libc shows the following instructions for the relevant jal call:

Code: [Select]

0000010c <.LVL17>:
 10c: 00000097          auipc ra,0x0
10c: R_RISCV_CALL _isatty_r
10c: R_RISCV_RELAX *ABS*
 110: 000080e7          jalr ra # 10c <.LVL17>
This obviously should call _isatty_r.  Unfortunately there are two versions, one defined in newlib and one that is included in the on chip ROM , defined in esp32c3.rom.newlib-time.ld. The non-working version links to the ROM version of _isatty_r, so this appears to not work correctly. Now to find a way to convince the linker to pick the newlib version...

[dbannon]

....
These libraries are part of the Gnu toolchain distribution and can be found here (obviously computer specific):

Oh, I don't know why I did not look there !  Sorry.

For all the settings I'm using, see the below summary for riscv32-freertos in my fpc.cfg:

Yep, makes sense, I prefer not to edit the fpc.cfg file, I have been building with a script that offers all that content on a fpc command line, easier IMHO to manage.

But I still find myself missing symbols esp_app_get_elf_sha256, esp_partition_main_flash_region_safe, esp_app_get_description

Easy to look them up in the map file you mention and find the .a file they live in. And easy to manually add then to the link file and it all builds. But thats no solution. How can I tell FPC about needing them ? It finds all the other object archives it needs ?

What are your plans with "packaging" this ?  Its a labourous process installing IDF and its associated tool, it appears to me it would be legal to just cherry pick all the needed libraries and put them 'somewhere' suitable but how about the assembler and linker ?  Oh, and that esptool.py thing ....

And should that process be based on the 5.2.1 stable release ?

Davo

[MiR]

Packaging is done in my repo:

https://github.com/michael-ring/espsdk4fpc/tree/devel

when you have a linux box or a mac you can run buildsdk.sh and you will end up with a directory structure (4.4.7 and 5.0.6) that includes the (hopefully complete) dependencies for compiling and linking an esp project. We use an older version of this with fpcupdeluxe, hopefully when things advance the same mechanism can be used for the esp32c3 chip.

Michael