I'm keen to test the xtensa-freertos target, but it seems there are a couple of patches missing from trunk.

It is possible to build an xtensa cross compiler, but the make files doesn't know the xtensa-freertos target. To get the make files in rtl updated, one needs to rebuild fpcmake, edit rtl/MakeFile.fpc and add "dirs_freertos=freertos" to the target list, then run fpcmake. At this point the the following make command proceeds up to sysutils: make rtl FPC=~/fpc/3.3.1/compiler/ppcrossxtensa CPU_TARGET=xtensa OS_TARGET=freertos BINUTILSPREFIX=xtensa-esp32-elf-

where the following errors crop up:
syssbh.inc(43,41) Error: Identifier not found "Double"
syssbh.inc(49,41) Error: Identifier not found "Single" etc.

I trust someone (Florian...) has a working build?

I sent Michael recently some instructions but I am not sure if they are still working. As Pierre got qemu-xtensa working I am pushing the linux port so we can test more easily the compiler.

- install esp-idf and execute
source ~/eps/esp-idf/export.sh
to get the pathes and environment set (namely tools path and $IDF_PATH are needed)
- use the lazarus project fpc/compiler/ppcxtens.lpt to build an xtensa compiler
- build the rtl (breaks currently at sysutils, doesn't matter): cd rtl/freertos
make FPC=../../compiler/xtensa/pp OS_TARGET=freertos "OPT=-Cplx6 -Cawindowed -XPxtensa-esp32-elf-" clean all
- build the example hello world program from the esp-idf, copy all generated .a into e.g. ~/xtensa-esp32-elf-libs
- create somewhere a hello world program, compile it with fpc/compiler/xtensa/pp -Fu../rtl/units/xtensa-freertos/ -Tfreertos -Cawindowed -XPxtensa-esp32-elf- -al -O3 -Wpesp32
-Fl~/xtensa-esp32-elf-libs
-Fl$HOME/.espressif/tools/xtensa-esp32-elf/esp-2019r2-8.2.0/xtensa-esp32-elf/xtensa-esp32-elf/lib/ hello
- get partition-table.bin and bootloader.bin from the hello_world example compiled above and copy them into the same dir as the compiled hello.bin
- flash with
esptool.py -p /dev/ttyUSB0 -b 460800 --before default_reset --after hard_reset --chip esp32 write_flash --flash_mode dio --flash_size detect --flash_freq 40m 0x1000 bootloader.bin 0x8000 partition-table.bin 0x10000 hello.bin
- monitor the output with:
idf_monitor.py --port /dev/ttyUSB0 hello.elf

Just to be sure, from your Path settings it looks like you are using esp-idf from the release/v4.0 Branch, correct?

Michael

I was able to compile my first hello world for esp32, however I had to patch a few files so that compiling works for 4.0 / 4.1 Branch of esp-idf

Florian, can you please have a look at the patches and apply them if they are OK?

diff --git a/compiler/systems/t_freertos.pas
b/compiler/systems/t_freertos.pas
index 3698f28dc1..a0788751ec 100644
--- a/compiler/systems/t_freertos.pas
+++ b/compiler/systems/t_freertos.pas
@@ -77,7 +77,7 @@ begin
      if target_info.system=system_xtensa_freertos then         ExeCmd[1]:='ld -g '+platform_select+' $OPT $DYNLINK $STATIC $GCSECTIONS $STRIP $MAP -L. -o $EXE -T $RES '+
          '-u call_user_start_cpu0 -u ld_include_panic_highint_hdl -u esp_app_desc -u vfs_include_syscalls_impl -u
pthread_include_pthread_impl -u pthread_include_pthread_cond_impl -u pthread_include_pthread_local_storage_impl -u newlib_include_locks_impl -u newlib_include_heap_impl -u newlib_include_syscalls_impl -u newlib_include_pthread_impl -u app_main -u uxTopUsedPriority '+ -         '-L $IDF_PATH/components/esp_rom/esp32/ld -T esp32.rom.newlib-funcs-time.ld '+
+         '-L $IDF_PATH/components/esp_rom/esp32/ld '+           '-T esp32.rom.ld -T esp32.rom.libgcc.ld -T esp32.rom.newlib-data.ld -T esp32.rom.syscalls.ld -T esp32.rom.newlib-funcs.ld '+
          '-L . -T esp32_out.ld -T esp32.project.ld '+           '-L $IDF_PATH/components/esp32/ld -T esp32.peripherals.ld' @@ -1523,10 +1523,10 @@ begin
       { generate linker maps for esp32 }
       binstr:='$IDF_PATH/tools/ldgen/ldgen.py';        cmdstr:='--config sdkconfig --fragments $IDF_PATH/components/xtensa/linker.lf $IDF_PATH/components/soc/linker.lf $IDF_PATH/components/esp_event/linker.lf '+
-        '$IDF_PATH/components/spi_flash/linker.lf $IDF_PATH/components/esp_wifi/linker.lf
$IDF_PATH/components/lwip/linker.lf $IDF_PATH/components/log/linker.lf '+ +        '$IDF_PATH/components/spi_flash/linker.lf $IDF_PATH/components/esp_wifi/linker.lf
$IDF_PATH/components/lwip/linker.lf '+
         '$IDF_PATH/components/heap/linker.lf $IDF_PATH/components/esp_ringbuf/linker.lf
$IDF_PATH/components/espcoredump/linker.lf
$IDF_PATH/components/esp32/linker.lf '+
'$IDF_PATH/components/esp32/ld/esp32_fragments.lf
$IDF_PATH/components/freertos/linker.lf
$IDF_PATH/components/newlib/newlib.lf '+
-        '$IDF_PATH/components/app_trace/linker.lf $IDF_PATH/components/esp_gdbstub/linker.lf '+
+        '$IDF_PATH/components/esp_gdbstub/linker.lf '+          '--input $IDF_PATH/components/esp32/ld/esp32.project.ld.in --output ./esp32.project.ld --kconfig $IDF_PATH/Kconfig --env-file config.env '+
         '--libraries-file ldgen_libraries --objdump xtensa-esp32-elf-objdump';
Replace(binstr,'$IDF_PATH',maybequoted(GetEnvironmentVariable('IDF_PATH')));

diff --git a/rtl/freertos/xtensa/esp32.pp b/rtl/freertos/xtensa/esp32.pp index 1bc9d3bcf9..e7070e082b 100644
--- a/rtl/freertos/xtensa/esp32.pp
+++ b/rtl/freertos/xtensa/esp32.pp
@@ -22,10 +22,10 @@ unit esp32;
 {$linklib spi_flash,static}
 {$linklib app_update,static}
 {$linklib xtensa,static}
-{$linklib esp_timer,static}
+//{$linklib esp_timer,static}
 {$linklib bootloader_support,static}
 {$linklib pthread,static}
-{$linklib soc_esp32,static}
+//{$linklib soc_esp32,static}
 {$linklib hal,static}
 {$linklib c,static}
 {$linklib esp_event,static}

To be honest, I have not the slightest clue if they are ok or not :) To be honest I simply did a lot of trial and error for the current port. Do you have any explanations for the needed changes?

BTW: I started a wiki page on it: https://wiki.freepascal.org/ESP32 (not end user ready, just for people interested on improving the port :))

I removed Modules/Libs that I could not find in v4.0/v4.1 Release of idf.

As official stable release of idf is currently 4.0 I think it makes sense to make sure that this release builds out of the box.

As esp32 is bleeding edge both for compiler and freertos I have done most patches that are necessary to make freertos compile with arm target.

There at least the compiler is pretty stable and overall the whole environment is a lot less complex, so perhaps making freertos work is a little easier.

Is anybody already working on freertos bindings?

Michael

By the way, I added a few missing points to the wiki

I have committed the patch with some extensions/adaptions. With current trunk, I can build a hello world following the wiki instructions with ESP-IDF 4.0.

Regarding the FreeRTOS binding for ARM: can you provide a patch somewhere?

I have uploaded  my patch to:

http://temp.michael-ring.org/fpc-arm-freertos.patch

I have left out the generated Makefiles to keep the patch (kind of) readable.

I am able to build the target like this:

make -j clean buildbase CROSSINSTALL=1 OS_TARGET=freertos CPU_TARGET=arm SUBARCH=armv7em CROSSOPT="-CfFPV4_SP_D16 -XParm-embedded-"

or

make -j clean buildbase CROSSINSTALL=1 OS_TARGET=freertos CPU_TARGET=arm SUBARCH=armv6m CROSSOPT="-CfSOFT -XParm-embedded-"

make -j clean buildbase CROSSINSTALL=1 OS_TARGET=freertos CPU_TARGET=arm SUBARCH=armv7m CROSSOPT="-CfSOFT -XParm-embedded-"

Fun Fact: I have to include -CfSOFT in CROSSOPT for armv6m/7m or I will get this error:

/Library/Developer/CommandLineTools/usr/bin/make -C rtl all /Library/Developer/CommandLineTools/usr/bin/make -C freertos all /bin/mkdir -p /Users/ring/devel/fpc-freertos/rtl/units/arm-freertos /Users/ring/devel/fpc-freertos/compiler/ppcrossarm -Cparmv6m -Ur -Tfreertos -Parm -XParm-freertos- -Xr -Ur -Xs -O2 -n -Fi../inc -Fi../arm -FE. -FU/Users/ring/devel/fpc-freertos/rtl/units/arm-freertos -darm -dRELEASE -XParm-embedded-  -Us -Sg system.pp @system.cfg system.inc(416,5) Fatal: Internal error 200312126

Do you have an idea why? I compared to the embedded target but could not find something obvious....

The freertos bindings are not included yet as I am still testing & learning and I need your guidance on how to provide the lib/*.o files for freertos:

I currently build freertos rtl as three different versions with a hopefully sane base-set of configuration options, the question is where to put the matching *.o or *.a files, check them in in fpc or provide build instructions on the Wiki similar to the buildinstructions for xtensa target??

I have uploaded a zipfile with everything needed to build a freertos environment:

http://temp.michael-ring.org/FreeRTOS-Bootstrap.zip

The Build also includes prebuilt .o files.

To build yourself you will first have to manually adjust the buildFreeRTOS.sh script so that it points to a correct arm-none-eabi-gcc.

Michael

Michael Ring wrote

I have uploaded  my patch to: http://temp.michael-ring.org/fpc-arm-freertos.patch

Thanks, I'll look into it.

I'll see if I can fix it when adding the patch.

I have no idea either yet. Most likely we will need some fpcdeluxe like approach.

Michael Ring wrote

I have uploaded  my patch to: http://temp.michael-ring.org/fpc-arm-freertos.patch

I have committed it with a few changes, let's see how it works :)

Thanks!

Your commit is close, but not yet there...

to make it work it was necessary for me to re-create the Makefiles, arm-freertos was missing in the root makefile and some others, did you rebuild fpcmake before using it?

You also did not include the rtl/freertos/arm directory (I guess on purpose, it is currently an evil clone of rtl/embedded/arm):

without that directory and it's content the build breaks. I checked if you did some magic to re-use the rtl/embedded/arm directory but this does not seem to be the case.

Currently it is also perhaps a good idea to have a new directory for freertos compatible units, from what I know today I will have to change the interrupt-names defined in the unitfiles to be CMSIS (and for that FreeRTOS) compatible.

This means that we will likely have to rename interrupt names like:

PendSV_Interrupt

to

PendSV_Handler

so that FreeRTOS can properly provide it's own routines for handling SysTick, PendSV and SVCall Interrupt Handlers.

There may be other solutions to this problem, read somewhere that one can replace symbols in the linker step, but for the first version it would be good to have the changed units in trunk.

Here's a zip with the missing files:

http://temp.michael-ring.org/freertos-arm-missing.zip

Michael

Pierre recreated the makefiles already, so it should be fine, right?

You also did not include the rtl/freertos/arm directory (I guess on purpose, it is currently an evil clone of rtl/embedded/arm):

Ok. I added them.

without that directory and it's content the build breaks. I checked if you did some magic to re-use the rtl/embedded/arm directory but this does not seem to be the case.

No, I applied the patch and forgot to add them.

Yes.

Another thing: some of the files miss a header, so the correct license. If some of them are made by you, can you please provide a header?

Yes, I could start the build from trunk

No worries....

Sorry, I will provide new versions with proper headers

_______________________________________________ fpc-devel maillist  -  https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Trunk now builds without issues for armv6m, armv7m and armv7em, here's the patch to add the license and the renames to make the interrupts cmsis compatible.

http://temp.michael-ring.org/cmsis_plus_license.patch

Michael