fpcupdeluxe and the Pico

[dbannon]

Hi folks.

I note that Michael Ring's patches to FPC have been merges in FPC main ( https://gitlab.com/freepascal.org/fpc/source/-/merge_requests/531 ) and that's really great.

It would be even better if fpcupdelue updated to the newer compiler and Lazarus, the Lazarus in there now is quite buggy, especially wrt to some (important to me) code tools things. So, I thought I'd do so testing to ease DonAlfredo workload a touch. I have established Lazarus 3.2 works well with Michael's old compiler.

However, I have been unable to build a working Pico cross compiler direct from FPC Main, first because I used ARMHF (Michael tells me the armv6m does not do hard float) and then things like "invalid combination of opcode and operands" its clear I have the wrong combinations of options. Does anyone know the correct switches to use, below was my second attempt -

Code: [Select]

make clean all FPMAKEOPT="-T 4" CPU_TARGET=arm OPT="-dFPC_ARMel" CROSSOPT="-CpARMV6M -CaEABI" CROSSBINDIR=/usr/bin BINUTILSPREFIX=arm-none-eabi-
to be followed by, if the above can be made to work, with -

Code: [Select]

make crossinstall OS_TARGET=linux CPU_TARGET=arm OPT="-dFPC_ARMEL" CROSSBINDIR=/usr/bin  BINUTILSPREFIX=arm-none-eabi-  CROSSOPT="-CpARMV6M -CaEABI" INSTALL_PREFIX=/home/dbannon/bin/FPC/fpc-3.3.1

Any ideas please ?

Davo

[TRon]

The wiki seems to suggest to use subarch

Some hints on Subarchs:

    armv6m Subarch is good for Raspberry Pico, SAMD21 based board like the Arduino Zero or STM32F0/G0/L0 families

[MiR]

just out of interest, what does not work for you in latest Lazarus?

At least for me Code completion works, also debugging with a pico probe (Although I had to first compile latest openocd patches from the Raspberry Repo.

To be honest I do not need much from Lazarus besides debugging so it would be nice to know where you struggle.

Michael

[TRon]

Any ideas please ?

At least a little better idea now 

The following seem to produce a (working) cross-compiler for me.

Code: [Select]

make \
  clean \  // always clean up before doing anything
  crosszipinstall \ // generate an archive that contains the cross compiler and units, feel free to use crossinstall instead but make sure you install (in)to the correct directory
  FPC=fpc \ // (full path to your) fpc executable or as alternative you can use PP=<(full path to)ppc executable>
  CPU_TARGET=arm \ // seems that pico has an arm (no legs though)
  OS_TARGET=embedded \ // pico is an embedded target
  SUBARCH=armv6m \ // pico requires specific subarch and indicates instructions(et) that can be used
  CROSSBINDIR="../binutils" \ // path to directory where your binutils are located (or leave empty when global installed)
  BINUTILSPREFIX="arm-embedded-" \ // the prefix used for binutils
  CROSSOPT="-CaEABI" // select appropriate ABI
Perhaps the above is able to provide some more details for trying your own build ?

[dbannon]

OK, so I have it working, I am about to start some tests to see how it works with real code.  Below is a script I used in my building and re-building tests, important to note its NOT intended as a general purpose script for this purpose, it has no error checking, in most cases it will just move on to the next step if something bad happens.

First, TRon, where did you get the info about SUBARCH and  crosszipinstall from ?  The latter was a red herring, does not appear on our wiki and breaks the build but SUBARCH was the key to getting it going even though its not mentioned anywhere in the Pico context. But it sure worked and I thanks you !

Back to the "script", or as I prefer, list of commands ....

You should, as a minium, look at the top few lines, make sure you have the current FPC source in ~/Downloads, fpc.zip. Make sure the directories indicated are not already existing and containing something (important or otherwise).

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

1. #!/bin/bash
2.  
3. # WARNING - do not think of this as an gp install script, it does
4. # absolutely NO ERROR CHECKING !!
5. # Demo of how to build a Raspberry Pico compiler from current 'main' FPC.
6. # Use it as you see fit. If it destroys your computer, cause you cat to become
7. # pregnant or any other problem, sorry, no responsibility accepted.
8. # David Bannon, 2024-03-05
9.  
10. export FPC_VER="fpc-3.3.1"
11. export SRC_DIR="$HOME/bin/FPC/SRC/$FPC_VER"
12. export FPC_DIR="$HOME/bin/FPC/$FPC_VER"
13. mkdir -p "$FPC_DIR"
14. mkdir -p "$SRC_DIR"
15.  
16. cd "$SRC_DIR"
17. unzip ~/Downloads/fpc.zip
18. cd fpc
19. make all
20.  
21. make install INSTALL_PREFIX="$FPC_DIR"
22.  
23. make crossinstall CPU_TARGET=arm OS_TARGET=embedded SUBARCH=armv6m  CROSSBINDIR=/usr/bin  BINUTILSPREFIX=arm-none-eabi-  CROSSOPT="-CpARMV6M -CaEABI" INSTALL_PREFIX="$FPC_DIR"
24.  
25. cp compiler/ppcx64 "$FPC_DIR"/bin/ppcx64         # cp rather ln -s because further processes seem to 'clean' it
26. cp compiler/ppcrossarm "$FPC_DIR"/bin/ppcrossarm
27. ## the make process does not copy the rtl/embedded/arm/* files across. Why not ?
28. cp rtl/embedded/arm/* "$FPC_DIR"/lib/fpc/3.3.1/units/arm-embedded/rtl/.
29.  
30. cd "$FPC_DIR"
31. mkdir -p etc
32. bin/fpcmkcfg -d basepath="$FPC_DIR" -o etc/fpc.cfg
33. ln -s "$FPC_DIR"/lib/fpc/3.3.1/units units
34.  
35.  
36. cd bin
37. echo "#!/bin/sh" > fpc.bash
38. echo "# A script that ensure when we start fpc here, it ignores all other fpc.cfg" >> fpc.bash
39. echo "$FPC_DIR""/bin/fpc -n @$FPC_DIR/etc/fpc.cfg \"\$@\"" >> fpc.bash
40. chmod u+x fpc.bash

A script to compile a job using this compiler may look like this -

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

1. #!/bin/bash
2. echo "------- Using the fpc from 3.3.1 ---------"
3. export MICHAELS_UNITS="$HOME"/Pico2/projects/pico-fpcexamples/units # these come from https://github.com/michael-ring/pico-fpcexamples
4. "$HOME"/bin/FPC/fpc-3.3.1/bin/fpc.bash -va -Xu -XParm-none-eabi- -Tembedded -Parm -CpARMV6M -Fu"$MICHAELS_UNITS" -Wpraspi_pico project1

If you use this compiler in Lazarus (I use Lazarus 3.2, works fine), make sure you call the compiler script, fpc.bash, not fpc itself. Otherwise, it may read you existing, 'other' fpc config and probably, that would be bad !

If this little package passes all my tests, I will write something up on the wiki so we have a record of how to do this stuff.

Much thanks to Michael Ring and DonAlfredo

Davo

[TRon]

First, TRon, where did you get the info about SUBARCH and  crosszipinstall from ?

In principle both from the makefile but I follow the commits on FPC and there the SUBARCH option passed my prying eyes (before the implementation/support of SUBARCH things were a bit complicated to build for embedded targets).

from the makefile (I just took a random embedded target for example purpose):

ifeq ($(CPU_OS_TARGET),arm-embedded)
ifeq ($(SUBARCH),)
$(error When compiling for arm-embedded, a sub-architecture (e.g. SUBARCH=armv4t or SUBARCH=armv7m) must be defined)
endif
override FPCOPT+=-Cp$(SUBARCH)
endif

Thus, no need to provide the -Cp argument manually

and for crosszipinstall:

.PHONY: crossall crossinstall crosszipinstall crosssinglezipinstall
crossall:
   $(MAKE) all CROSSINSTALL=1
crossinstall:
   $(MAKE) install CROSSINSTALL=1
crosszipinstall:
   $(MAKE) zipinstall CROSSINSTALL=1

It is a phony target. You could just as well provide zipinstall CROSSINSTALL=1 to your command.

  The latter was a red herring, does not appear on our wiki and breaks the build

In that case, please retry with clean directories. I have been using that since it was present and never got me into troubles. the auto-build of the archive comes in very handy because it allows to store the created archive somewhere safe for later use (very pleasant in case for release compilers, perhaps not so in case you build trunk on a regular base)

I thanks you !

You are more than welcome dbannon. Glad to hear/see that it was able to get you further in your endeavors.

A quick note about the rest of your script. You could opt for creating a bash alias (or script as you did) that invokes the correct compiler (and its options) when addressing the pico compiler, e.g. name it fpc-pico so that it doesn't pick up on the 'normal' FPC installation. (whatever normal is for your use case)

Personally i had more issues with figuring out the -Wpraspi_pico option. I did notice this (undocumented ?) -Wp option in on the embedded wiki pages, but not what to use for the pico (had to dive into the compiler source for that  )

btw should that option not read -Wprp2040 and/or -Wprppico ? (edit: strike that, apparently my sight was crooked when I looked  it is indeed raspi-pico )

Thank you for sharing 

[MiR]

Another hint:

The lpi files in my examples on github are your friend....

There you can set configurations for different targets in one place and use lazbuild to apply them.

Here's a partial example:

      <CustomOptions Value="
-Wpraspi_pico
-godwarfsets
-godwarfcpp
-Xu"/>

You can configure Targets from inside Lazarus in a GUI way and re-use what you have done with lazbuild:

lazbuild --build-all <lpifile> builds your code for all the default target

lazbuild --build-all --build-mode="Adafruit Feather RP2040" <lpifile> builds for the specific Adafruit Feather RP2040 board.

[dbannon]

TRon - My main focus here was confirming that the "official" "main" (you know what I mean) contains a usable pico compiler so that DonAlfredo can switch over to using it rather than Michael's out of date one. But it sounds like you have an "in use" version already ?  I could have saved some time ! There does not seem any great risk of a FPC release soon but it pays to be prepared !

....You could opt for creating a bash alias (or script as you did) that invokes the correct compiler (and its options) when addressing the pico compiler, e.g. name it fpc-pico so that it doesn't pick up on the 'normal' FPC installation. (whatever normal is for your use case)

Actually, I approach that differently, and beyond the scope of this thread. I keep an env var, OLD_PATH, that has my path before I added my default FPC, so I can, in the middle of a script (eg starting Lazarus), build a new clean path to suit whatever compiler I want. I glossed over that ...

Personally i had more issues with figuring out the -Wpraspi_pico option. I did notice this (undocumented ?)
btw should that option not read -Wprp2040 and/or -Wprppico ?

-Wpraspi_pico appears in Michaels Lazarus example projects, under Custom Options, so, I expect its the right one to use.

In cpuinfo.pas, both 'RP2040'  and 'RASPI_PICO'  are listed around line #1063.  But 'RP2040' is shown as having zero flashsize and that cannot be right, RASPI_PICO seems to have numbers more consistent with, eg https://petewarden.com/2024/01/16/understanding-the-raspberry-pi-picos-memory-layout that is -

flashbase:$10000000;
flashsize:$00200000;     
srambase:$20000000;
sramsize:$00042000),

I suspect RP2040 may be just a generic place holder ?

I was pretty sure I saw -WpXXXX documented somewhere but I cannot find it now. I remember seeing it with a list of values and the words "embedded only". I suggest its absence is a FPC documentation bug, "-h" should show it IMHO ??

Michael - yep, I normally use Lazarus projects but wanted to understand the process and a command line is clear and unambiguous. Do you agree that "fpc -h" should mention -WpXXXX ?  And should it be, in the case, RP2040 or RASPI_PICO ?

Davo

[TRon]

TRon - My main focus here was confirming that the "official" "main" (you know what I mean) contains a usable pico compiler so that DonAlfredo can switch over to using it rather than Michael's out of date one.

I am not quite sure what it is exactly you are trying to say there... trunk has been able to build for pico since the patches from MiR were accepted (well, plus-minus a few hiccups  ), FPCUpDeluxe is able to build trunk and I have seen from Don Alfredo's post that he has addressed issues wrt embedded targets so that means that FPCUpdeluxe should be able to build a cross-compiler for you (haven't tried yet though see edit). So unless Don A. is cheating and just copies over a pre-build when you select embedded raspi target instead of actually building it from trunk sources.....

But, imho it is always good to known and be able to manually build your binutils, compilers and cross-compilers.

edit: tried fpcupdeluxe and seems to work as expected (use the link to the wiki-page in my first reply that shows how to setup arm embedded using fpcupdeluxe). Though other than available instructions (1,2,3) make sure (at step 4) to select "none" for Arm target, "eabi" for ABI, and don't forget to select the right subarch. Do not let the (error) dialog that pops-up fool you, just press ok and it will try to download anything that is missing.

Code: [Select]

$ ./ppcrossarm -h
Free Pascal Compiler version 3.3.1-15371-g0fb4fca957-dirty [2024/03/05] for arm



But it sounds like you have an "in use" version already ?  I could have saved some time ! There does not seem any great risk of a FPC release soon but it pays to be prepared !

Well, I have a cross-compiler that is able to compile... if it actually works, I have no idea  (fwiw: that is not too odd, I cross compile for many targets for which I either do not have the hardware/software or not the time to test myself) And yes, everything you are able to learn about new targets/features from the (trunk) compiler before the official release has been published is good. Very good even, because if you run into issues then they can be reported before the actual release and as a result /can/ be fixed *hint hint*

Actually, I approach that differently, and beyond the scope of this thread. I keep an env var, OLD_PATH, that has my path before I added my default FPC, so I can, in the middle of a script (eg starting Lazarus), build a new clean path to suit whatever compiler I want. I glossed over that ...

Ok, yes that is also a solution (I used to use that as well but kept forgetting the name of the environment variable and back then was still using windows that all of a sudden required you to have elevated access rights when wanting to change envars so switched over to using the (undocumented) -V option, but with a small twist to suit my needs). I'll leave it at that if it is out of scope.

-Wpraspi_pico appears in Michaels Lazarus example projects, under Custom Options, so, I expect its the right one to use.

Yeah but things do tend to change (in trunk) once in a while...  (btw I looked at the wrong record-field when I wrote down rppico, I had it corrected in my (previous) post while you prepared your reply). So you were right all along 

In cpuinfo.pas, both 'RP2040'  and 'RASPI_PICO'  are listed ...

Ah ok, thank you for the information because tbh I haven't looked very close to the implementation details for the pico target. I trust your judgement on that.

I was pretty sure I saw -WpXXXX documented somewhere but I cannot find it now. I remember seeing it with a list of values and the words "embedded only". I suggest its absence is a FPC documentation bug, "-h" should show it IMHO ??

Oh, now I feel stupid (simply because I am  ). You are absolutely right,

./ppcrossarm -h
Free Pascal Compiler version 3.3.1 [2024/03/04] for arm
Copyright (c) 1993-2024 by Florian Klaempfl and others
...
     -WN        Do not generate relocation code, needed for debugging (Windows)
      -Wp<x>     Specify the controller type; see fpc -i or fpc -iu for possible values
      -WP<x>     Minimum iOS deployment version: 3.0, 5.0.1, ... (Darwin)

I spare you (and other readers) the ridiculous amount of output produced by ./ppccrossarm -i and -iu

[dbannon]

trunk has been able to build for pico since the patches from MiR were accepted ...

Only about 3 months ago.

[.....FPCUpDeluxe is able to build trunk and I have seen from Don Alfredo's post that he has addressed issues wrt embedded targets so that means that FPCUpdeluxe should be able to build a cross-compiler for you

While good to hear, my tests here indicate that fpcupdeluxe is still getting its Pico compiler from Michael's gitlab repo FPC source, static for a year or so.
See attached image of a week old fpcupdeluxe. I start fpupdeluxe, click the "Pico" button (Careful, it starts immediately, does not show a summary of what its going to do, just runs ! ).

The key here might be "click the Pico button" bit - maybe it behaves differently if you build it up from the left hand controls ?

Code: [Select]

$ ./ppcrossarm -h
Free Pascal Compiler version 3.3.1-15371-g0fb4fca957-dirty [2024/03/05] for arm

Yes !  That makes sense !  I was looking at -h from a fpc binary, not ppcrossarm !  I'm surprised they are different but I guess it makes sense.

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

1. ppcrossarm -iu

for example lists all the pico (etc) boards,

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

1. fpc -iu

lists nothing ! But a fpc binary that can find an appropriate ppcrossarm will accept -WpXXX.  So, should, IMHO, list it as an option.

A very useful discussion, lots of things becoming clearer.

Davo

[DonAlfredo]

While good to hear, my tests here indicate that fpcupdeluxe is still getting its Pico compiler from Michael's gitlab repo FPC source, static for a year or so.

The latest release of fpcupdeluxe should use normal FPC trunk !

[dbannon]

Yep, fresh download just now, fpc comes from https://gitlab.com/freepascal.org/fpc/source ! Great.

But Lazutils is not building -

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

1. fpcupdeluxe: Executing: /usr/bin/make --directory=/home/dbannon/fpcupdeluxe/lazarus USESVN2REVISIONINC=0 FPC=/home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.sh PP=/home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/ppcx64 PREFIX=/home/dbannon/fpcupdeluxe/lazarus INSTALL_PREFIX=/home/dbannon/fpcupdeluxe/lazarus INSTALL_BASEDIR=/home/dbannon/fpcupdeluxe/lazarus LAZARUS_INSTALL_DIR=/home/dbannon/fpcupdeluxe/lazarus/ FPCDIR=/home/dbannon/fpcupdeluxe/fpcsrc FPCMAKE=/home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/fpcmake PPUMOVE=/home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/ppumove OPT=-vw-n-h-l-d-u-t-p-c- -g -gl lazbuild (working dir: /home/dbannon/fpcupdeluxe/lazarus)
2.  
3. /usr/bin/make -C packager/registration
4.  
5. /home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.sh -MObjFPC -Scghi -O1 -g -gl -l -vewnhibq -Fu. -Fu/home/dbannon/fpcupdeluxe/fpcsrc/rtl -FE. -FU../units/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -vw-n-h-l-d-u-t-p-c- -g -gl -dx86_64 fcllaz.pas
6.  
7. (1002) Target OS: Linux for x86-64
8. (3104) Compiling fcllaz.pas
9. (3104) Compiling lazaruspackageintf.pas
10. (1008) 124 lines compiled, 0.1 sec
11.  
12. /usr/bin/make -C components/lazutils
13.  
14. /home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/fpc.sh -MObjFPC -Scghi -O1 -g -gl -l -vewnhibq -Fu../../packager/units/x86_64-linux -Fu. -Fu/home/dbannon/fpcupdeluxe/fpcsrc/rtl -FE. -FUlib/x86_64-linux -Cg -Fl/usr/lib/gcc/x86_64-linux-gnu/9 -vw-n-h-l-d-u-t-p-c- -g -gl -dx86_64 lazutils.pas
15. (1002) Target OS: Linux for x86-64
16. (3104) Compiling lazutils.pas
17.  
18. make: *** [Makefile:3762: lazutils] Error 2
19. (3104) Compiling utf8process.pp
20. (3104) Compiling fileutil.pas
21. (3104) Compiling lazfileutils.pas
22. (3104) Compiling lazutf8.pas
23. (3104) Compiling lazutilsstrconsts.pas
24. (3104) Compiling uitypes.pas
25. /home/dbannon/fpcupdeluxe/lazarus/components/lazutils/uitypes.pas(105,14) Error: (3285) Expected another 2 array elements
26.  
27. /home/dbannon/fpcupdeluxe/lazarus/components/lazutils/uitypes.pas(93,58) Fatal: (10026) There were 1 errors compiling module, stopping
28.  
29. Fatal: (1018) Compilation aborted
30.  
31. Error: /home/dbannon/fpcupdeluxe/fpc/bin/x86_64-linux/ppcx64 returned an error exitcode
32. fpcupdeluxe: ERROR: Lazarus Native Installer (BuildModuleCustom: Lazbuild): make returned exit status #512.
33.  
34.  
35. ERROR: Fpcupdeluxe fatal error !
36. Sequencer (UserIDE): Failure running fpcupdeluxe: error executing sequence UserIDE
37. Sequencer (Lazarus): Failure running fpcupdeluxe: error executing sequence Lazarus
38. Sequencer (Default): Failure running fpcupdeluxe: error executing sequence Default

This did, apparently, build OK with last weeks fpcupdeluxe. I'm using a relatively old Linux, U20.04, and, to be honest, I don't need it, so, maybe if its OK for everyone else, no heroic efforts for me please !

Sorry !

Davo

[MiR]

Building trunk for fpc and lazarus seems to be quite an adventure atm.

What worked for me was to use the december version of fpcupdeluxe which still uses older bootstrap compiler (I guess) and that worked fine 1-2 weeks ago.

Whith latest Bootstrap compiler errors change on a daily basis so it looks as if there is quite some work happening on trunk. But this all is target dependent, I had more issues on MacOSX for X86_64 than for MacOSX arm64, other platforms may be unaffected.

[dbannon]

Building trunk for fpc and lazarus seems to be quite an adventure atm.

We really don't need to track main in either case for the Pico. Just known stable snapshots from, eg, last six months or so.

For Lazarus, why not a stable release such as 3.0 or 3.2 ?

FPC is harder, we have not had a release of FPC since the Pico patches were merged so, without extensive testing, one snapshot of main is as good as another. I guess.

DonAlfredo, fpcupdeluxe is a magnificent product, a fantastic effort from yourself. You must have trouble finding the time, why not ask people here to run a barrage of tests on proposed candidates ? I was getting ready to do just that ....

Hmm, I see, Pico (and similar) are special cases. Most the other choices in fpcupdeluxe are specifically selected by the user.  Makes sense..... Just unlucky here I guess. Anyway, for the Pico I'd suggest a recent, stable, release of Lazarus and I'm happy to do some FPC testing of any snapshot of main you nominate. 

Davo

[TRon]

We really don't need to track main in either case for the Pico. Just known stable snapshots from, eg, last six months or so.

True. But you still would have to take an eye on things so that you know which snapshots do work (and which don't).

For Lazarus, why not a stable release such as 3.0 or 3.2 ?

It is guessing from my part (I usually do not use Lazarus) but most probably because new features of the compiler are not supported by stable Lazarus (it doe snot have notion of newly additions to the compiler). f.e. certain targets can't even be build by Lazarus stable (simply because the target was added in trunk compiler).

FPC is harder, we have not had a release of FPC since the Pico patches were merged so, without extensive testing, one snapshot of main is as good as another. I guess.

That is why I added the "hint hint" in one of my previous answers. You can only be sure by testing and in case of issues please report them so that they can be fixed.

The most simple form is just trying to build a certain target and give the developers a shout when a build fails (with accompanied error message). Some people have their own complete build-system in place to do just that for the targets they care about.

@MiR:
Yes indeed, lately a lot of activity going on in trunk so it can happen that things fail. As a generic remark to the reader just keep trying till it works (again) but sometimes it can take a couple of days. If persistent then try and see if the error is reported (in the bug-tracker) and in case not the please report yourself.