ESP32-C3 riscv32

[dbannon]

This is a follow on from https://forum.lazarus.freepascal.org/index.php/topic,67252.msg517455

The wiki page, https://wiki.freepascal.org/Xtensa talks about the esp32 but the esp32-c3 is much more common now, substantially cheaper IMHO. (It too is marked as legacy, such is the market for such things).

The esp32-c3 is a different beast from the esp32, the -c3 gets you a riscv32 chip. The above mentioned wiki article suggests the use of espressif tool kit and model, and using their base C libraries to access the specialist functions these chips have. So, thought I'd give it a try. Sort of, works, with the disclaimer that my hardware has not arrived yet so not tested ! And my generated binaries are suspiciously small.

And some serious problems needing ugly workaround, better solutions would be very, very welcome !

Several stages -

• Install the espressif tool kit, it has some system dependencies, a git tree and then a hidden directory containg some generated stuff. Pretty easy. Walks you through building an example binary. https://docs.espressif.com/projects/esp-idf/en/stable/esp32c3/index.html
• Building a riscv32 FPC compiler and rtl. Based on https://wiki.freepascal.org/Xtensa
• Building a Hello World FPC app - and here there be dragons !

Jump to second stage, I easily built what I think might be a esp32c3 compiler, based on fpc-main, dedicated to esp32-c3, I built a x86_64 in the conventional way first and then, the source directory (where the Makefile lives) -

Code: [Select]

$> make FPC=~/bin/FPC-esp32/fpc-3.3.1/bin/fpc  CPU_TARGET=riscv32 OS_TARGET=freertos  SUBARCH=rv32imc    "CROSSOPT=-XPriscv32-esp-elf- -Cfsoft" all -j
$> cp compiler/ppcrossrv32 ../../fpc-3.3.1/bin/.
$> make crossinstall FPC="$FPC_DIR"/bin/ppcrossrv32  CPU_TARGET=riscv32 OS_TARGET=freertos  SUBARCH=rv32imc  INSTALL_PREFIX="$FPC_DIR"
That was easy, I ended up with a ppcrossrv32 binary and a whole lot of compiled units in ~/bin/FPC-esp32/fpc-3.3.1/units/riscv32-freertos/ that seemed to be what I expected -

Code: [Select]

$> file /home/dbannon/bin/FPC-esp32/fpc-3.3.1/units/riscv32-freertos/rtl/system.o
/home/dbannon/bin/FPC-esp32/fpc-3.3.1/units/riscv32-freertos/rtl/system.o: ELF 32-bit LSB relocatable, UCB RISC-V, RVC, soft-float ABI, version 1 (SYSV), not stripped
But after that, things get muddy.  I could compile but not link. And the reason seems to be that the espressif supplied linker has some funny ideas how to use the FPC linker script.  The compiler makes a nice linker script with absolute paths to all the necessary object files, but the the linker  insists on prepending a path of its own devising. See tail end of a compile run  (-va  and -k" --verbose") here -

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

1. $> /home/dbannon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/riscv32-esp-elf-ld -g   --verbose   --gc-sections   -L. -o hello.elf -T link289829.res
2. GNU ld (crosstool-NG esp-13.2.0_20230928) 2.41
3. ...
4. opened script file link289829.res
5. using external linker script:
6. ==================================================
7. SEARCH_DIR("/home/dbannon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/riscv32-esp-elf/lib/")
8. SEARCH_DIR("/home/dbannon/bin/FPC-esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/")
9. SEARCH_DIR("/home/dbannon/bin/FPC-esp32/fpc-3.3.1/bin/")
10. INPUT (
11. hello.o
12. /home/dbannon/bin/FPC-esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/system.o
13. /home/dbannon/bin/FPC-esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/esp32c3.o
14. /home/dbannon/bin/FPC-esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/consoleio.o
15. /home/dbannon/bin/FPC-esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/heapmgr.o
16. )
17. ....
18. ==================================================
19. /home/dbannon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/riscv32-esp-elf-ld: mode elf32lriscv
20. attempt to open hello.o succeeded
21. hello.o
22. attempt to open /home/dbannon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/../riscv32-esp-elf/home/dbannon/bin/FPC-esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/system.o failed
23. /home/dbannon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/riscv32-esp-elf-ld: cannot find /home/dbannon/bin/FPC-esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/system.o: No such file or directory
24. attempt to open /home/dbannon/.espressif/tools/riscv32-esp-elf/esp-13.2.0_20230928/riscv32-esp-elf/bin/../riscv32-esp-elf/home/dbannon/bin/FPC-esp32/fpc-3.3.1/lib/fpc/3.3.1/units/riscv32-freertos/rtl/system.o failed
25. ...

I could find no way to tell FPC to not supply the full path nor to tell tell the linker that the full path is there, use it ! So, in the end, I created a (crazy) directory structure below where the linker insists on looking with symlinks to the (few) needed files.

Thats was good, it build an elf file, but a very, very small one, 4688 bytes ??

Anyway, no .bin file because, after linking, FPC somehow calls

Code: [Select]

$> /home/dbannon/bin/esp/esp-idf//components/esptool_py/esptool/esptool.py --chip esp32c3 elf2image --flash_mode dio --flash_freq 80m --flash_size 4MB --elf-sha256-offset 0xb0 --min-rev 3 -o hello.bin hello.elf
But esptools is not executable, running it by hand (ie with python3) does make the hello.bin but its only 64bytes ??  That cannot be right but currently, no hardware! So, I wait ....

In summary, three issues

• Crazy Linker problem.
• FPC calls esptools (how does FPC know esptools even exits ?)
• Resulting binaries appear to be too small to be useful.

Any comments very welcome !

[MiR]

ccrause is definitely the expert here...

but have you already checked if the linker code in ./compiler/systems/t_freertos.pas is correctly configured? There are currently two possible defines that may be active, XTENSA and RISCV32 and in the end it may be that you need code from both to get proper linking.
likely XTENSA is not set at all but it should contain all the required linker settings that will likely have to go into the RISCV32 code sections.

This may explain why your result is so small, currently close to nothing is defined in the linker script for RISCV32

[ccrause]

I have started testing the build process for esp32c3.  There appears to be a few missing pieces in the compiler for handling the interaction with the esp-idf SDK for riscv32.  This is required for correct linking of the final binary image.  I will update this thread once I have a fix, or at least a better grasp of what is going on.

[ccrause]

So, thought I'd give it a try. Sort of, works, with the disclaimer that my hardware has not arrived yet so not tested ! And my generated binaries are suspiciously small.

Consider testing with Espressif's qemu fork for esp32c3.  This is especially useful for testing logic (as opposed to interacting with hardware).  It should output write(ln) statements, at least it does for esp32.

[Fibonacci]

Would love to code these bad boys in FPC

[dbannon]

One thing I noted, after Michael prompted, the code in ./compiler/systems/t_freertos.pas that writes out default linker scripts does not seem to be happening. I am not entirely sure where they appear, I suspect ~/bin/esp/riscv32--esp32-elf-libs in my case. Its where the espressif's *.a files are copied to make them afailable to FPC. But, truth is, they are not appearing.

That code is active if RISCV32 is defined but in my test compile, it does not seem to be (but CPURISCV32 is). I tried adding it as a -d define but no help.

Davo

[dbannon]

Just to clarify, there is some (considerable ?) code in compiler/systems/t_freertos.pas that is clearly intended to write some default linker scripts and other config files for the riscv32.

However, that code is not called. Its in TlinkerFreeRTOS.GenerateDefaultLinkerScripts of which there several, each wrapped in their own {$ifdef SOMECPU} tags.

Down in TlinkerFreeRTOS.MakeExecutable , there is an {$ifdef XTENSA} block for example that calls GenerateDefaultLinkerScripts, but if we have RISCV32 defined, no such call is made.

I have confirmed that RISCV32 is defined at that stage, I guess its "just" a case of implementing whats necessary guided by the way its done for XTENSA ?

Davo

Davo

[ccrause]

Just to clarify, there is some (considerable ?) code in compiler/systems/t_freertos.pas that is clearly intended to write some default linker scripts and other config files for the riscv32.

However, that code is not called. Its in TlinkerFreeRTOS.GenerateDefaultLinkerScripts of which there several, each wrapped in their own {$ifdef SOMECPU} tags.

Down in TlinkerFreeRTOS.MakeExecutable , there is an {$ifdef XTENSA} block for example that calls GenerateDefaultLinkerScripts, but if we have RISCV32 defined, no such call is made.

I have confirmed that RISCV32 is defined at that stage, I guess its "just" a case of implementing whats necessary guided by the way its done for XTENSA ?

Yes, the riscv32 recipe should closely follow the xtensa recipe.  I have started fixing some things, but it is slow going since there are small changes with esp-idf version changes that also needs to be accounted for (else one needs to pin FPC support to a specific version of esp-idf).  Will have more time over the weekend to work on this.  Also the list of scripts & libraries to load is similar but not identical between esp32 and esp32c3.

[dbannon]

Yes, been playing in the same space.

I note that idf_version is set to 0, options.pas does not want to know about RISCV32. Not clear to me how it is supposed to be set, seems dependent on the cpu type ?  Anyway, I forced a new version and a lot more worked. But the XTENSA one seems to have a number of ld scripts not present in RISCV32.

I got as far as being told "cannot find entry symbol call_start_cpu0", linked in cpu_start.c.obj from Hello-World and realized I was way, way out of my depth ....

Davo

[ccrause]

Here is my git branch that I'm working on: https://gitlab.com/ccrause/fpc-source/-/tree/esp32c3

It would be great if you can help with this.  Note that I am currently using esp-idf v5.0.6, since v5.0 is mentioned in FPC (although the list of libraries seem to fit better with a later version).  Since there are differences, it would avoid confusion if we are working off the same esp-idf base. Once we have a working base in FPC, I can update FPC to work with different versions of esp-idf.

Current status is that the linker reports multiple definitions for symbols, due to two versions of newlib being found (one from esp-idf and the other one from the gcc toolchain).

[MiR]

Cloned... Thanks for the new branch!

Christo, have you ever thought of integrating esp-idf as a submodule?

I googled a little and found this:

https://esp32.com/viewtopic.php?t=13860

which looks promising. If you like the idea then I can try if I can come up with something.....

also this looks interesting:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-component-manager.html

[dbannon]

I'll help in any way I can but ....

Cloning (yek, to gitlab, I should have pointed to my github...)

Davo

[ccrause]

Cloned... Thanks for the new branch!

Christo, have you ever thought of integrating esp-idf as a submodule?

I googled a little and found this:

https://esp32.com/viewtopic.php?t=13860

which looks promising. If you like the idea then I can try if I can come up with something.....

also this looks interesting:

https://docs.espressif.com/projects/esp-idf/en/latest/esp32/api-guides/tools/idf-component-manager.html

Michael I don't see the potential you are thinking of, maybe explain a bit more what workflow you are envisioning? I would appreciate anything that can automate building and collecting the esp-idf libraries for use with FPC.

AFAICS the eps-idf submodule is used within another project to pin the esp-idf version, also the build system of the project needs to work with cmake.  For FPC, we need (maybe not need, but it is a real time saver if one does not need to build the SDK on the fly) to provide precompiled libraries for the linking stage.  The approach you use in espsdk4fpc seems fine for this,  it checks out a specific git tag and build and collect the necessary files from there. I think espsdk4fpc should perhaps be generalized a bit so that one can select different controllers and different SDK versions.  This requires customization (or at least testing) for each version (and controller) since files and even components can move around even between minor versions.

[MiR]

Let me give this a little more thought.... But you are right, for building code with fpc there is no real need to have full esp-idf inside. That's maybe more something for the infrastructure arround fpc

Michael

[dbannon]

(work in progress when you post arrived)

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}

Then, about line 1500, we have -

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

1.   if not(target_info.system=system_xtensa_freertos) then
2.     exit;

Needs an or with system_riscv32_freertos ....

Then, down a bit further -

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 !

Davo