Need help how to compile for STM32F104 on Banana PI (gnu eabi nofp or softfp)

SCerovec · 08-25-2022, 03:26 PM

Hi,
I tried to make Klipper on the Banana Pi (up to date Slackware 15.0 32 bit; stock + sbotools) and failed so far:

I can almost produce a binary image for STM32F4xx as it has hardware floating point on chip. (the compile fails at a later stage but more on that later...)

However my target is a STM32F104 that lack a hardware FPU but has a hardware watchdog, the code seems to be producing hard FP instructions regardless and the compilation fails.

I wonder if anyone had tried making custom firmware for the like of 3d printers or laser cutters involving the STM32F family and what route did they go?

I so far tried to recompile the gcc compiler with softfp instead of hard option but that seems to require more than merely setting that single option in the SlackBuild.

Further i seem to be missing g_nano too but this concerns me only after i get the linking done (or does it?)... the missing g_nano is the road block for finishing the F4xx firmware it seems.

Please advise.

business_kid · 08-26-2022, 07:11 AM

A compile tailspin would be useful. When the compile fails, hit up-arrow & return and it will repeat the last error, and bale out. Post that section. If you can't post that, do something like

Code:

make > /home/you/Klipper_err.txt 2>&1

The FPU thing isn't a worry at this stage. At worst it will compile instructions your cpu can't run, but it isn't the cause of your compile failure. Post the error and state what you're compiling on. Give us a link to your source code, and mention your kernel & headers versions. Headers can be a real source of compiler pain. If you changed glibc or gcc, mention that also.

Dunc. · 08-26-2022, 09:34 AM

Hello. I have compiled for STM32 targets, mostly nucleo boards. I mostly use the mbed.com online platform because it is kept up to date and it allows me to collaborate with others. However I have also used the gnu arm toolchain 10.3-2022-02 which I compiled from source. I see that there are now aarch64 binaries available now which should make thing easier. I think I cheated in creating the makefile. I selected blinky LED program with my platform. I build it online. Then I export the project for the gcc toolchain. This gave me a makefile and directory structure. The rest I wrote and modified with kate. The makefile selected the right platform from ST's impenetrable HAL.

Dunc.

Dunc. · 08-26-2022, 09:51 AM

I have downloaded klipper. I selected the STMF103 target and built it OK.

Dunc.

SCerovec · 08-31-2022, 07:00 AM

Okay, buckle up, here goes

...

it all starts as per documentation:

Code:

$ mkdir src
$ cd src/

$ git clone https://github.com/Klipper3d/klipper
$ ./klipper/scripts/install-octopi_slackware.sh 

$ cd klipper/
$ less config/generic-bigtreetech-skr-e3-dip.cfg
$ # that's my board right there ^

$ # i apply everything that file recommends in the comments
$ make menuconfig
$ # finally I run make:

$ make

i then get:

Code:

  Creating symbolic link out/board
  Building out/autoconf.h
  Compiling out/src/sched.o
  Compiling out/src/command.o
  Compiling out/src/basecmd.o
  Compiling out/src/debugcmds.o
  Compiling out/src/initial_pins.o
  Compiling out/src/gpiocmds.o
  Compiling out/src/stepper.o
  Compiling out/src/endstop.o
  Compiling out/src/trsync.o
  Compiling out/src/adccmds.o
  Compiling out/src/spicmds.o
  Compiling out/src/thermocouple.o
  Compiling out/src/i2ccmds.o
  Compiling out/src/pwmcmds.o
  Compiling out/src/spi_software.o
  Compiling out/src/sensor_adxl345.o
  Compiling out/src/sensor_angle.o
  Compiling out/src/sensor_mpu9250.o
  Compiling out/src/lcd_st7920.o
  Compiling out/src/lcd_hd44780.o
  Compiling out/src/buttons.o
  Compiling out/src/tmcuart.o
  Compiling out/src/neopixel.o
  Compiling out/src/pulse_counter.o
  Compiling out/src/stm32/watchdog.o
In file included from lib/stm32f1/include/stm32f103xe.h:149,
                 from lib/stm32f1/include/stm32f1xx.h:133,
                 from src/stm32/internal.h:10,
                 from src/stm32/watchdog.c:8:
lib/cmsis-core/core_cm3.h:90:6: error: #error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
   90 |     #error "Compiler generates FPU instructions for a device without an FPU (check __FPU_PRESENT)"
      |      ^~~~~
make: *** [Makefile:64: out/src/stm32/watchdog.o] Error 1

i can edit that file (lib/cmsis-core/core_cm3.h) and get to continue with the compilation, but i eventually stumble into a final roadblock again:

it is the easiest to get there if i change the CPU to STM32F401 (or anithyng with hard FPU i guess) in the make menuconfig:

Code:

  Creating symbolic link out/board
  Building out/autoconf.h
  Compiling out/src/sched.o
  Compiling out/src/command.o
  Compiling out/src/basecmd.o
  Compiling out/src/debugcmds.o
  Compiling out/src/initial_pins.o
  Compiling out/src/gpiocmds.o
  Compiling out/src/stepper.o
  Compiling out/src/endstop.o
  Compiling out/src/trsync.o
  Compiling out/src/adccmds.o
  Compiling out/src/spicmds.o
  Compiling out/src/thermocouple.o
  Compiling out/src/i2ccmds.o
  Compiling out/src/pwmcmds.o
  Compiling out/src/spi_software.o
  Compiling out/src/sensor_adxl345.o
  Compiling out/src/sensor_angle.o
  Compiling out/src/sensor_mpu9250.o
  Compiling out/src/lcd_st7920.o
  Compiling out/src/lcd_hd44780.o
  Compiling out/src/buttons.o
  Compiling out/src/tmcuart.o
  Compiling out/src/neopixel.o
  Compiling out/src/pulse_counter.o
  Compiling out/src/stm32/watchdog.o
  Compiling out/src/stm32/gpio.o
  Compiling out/src/stm32/clockline.o
  Compiling out/src/generic/crc16_ccitt.o
  Compiling out/src/generic/armcm_boot.o
  Compiling out/src/generic/armcm_irq.o
  Compiling out/src/generic/armcm_reset.o
  Compiling out/src/../lib/stm32f4/system_stm32f4xx.o
  Compiling out/src/stm32/stm32f4.o
  Compiling out/src/generic/armcm_timer.o
  Compiling out/src/stm32/gpioperiph.o
  Compiling out/src/stm32/adc.o
  Compiling out/src/stm32/i2c.o
  Compiling out/src/stm32/spi.o
  Compiling out/src/stm32/usbotg.o
  Compiling out/src/stm32/chipid.o
  Compiling out/src/generic/usb_cdc.o
  Compiling out/src/stm32/hard_pwm.o
  Building out/compile_time_request.o
Version: v0.10.0-557-gf7e29b27
  Preprocessing out/src/generic/armcm_link.ld
  Linking out/klipper.elf
/usr/bin/arm-none-eabi-ld: cannot find -lg_nano
/usr/bin/arm-none-eabi-ld: cannot find -lc_nano
collect2: error: ld returned 1 exit status
make: *** [Makefile:72: out/klipper.elf] Error 1

hope this helps

business_kid · 08-31-2022, 09:48 AM

IMHO, that's a gcc problem.

If you set the gcc options correctly, gcc will insert code to emulate FP instructions when it comes accross them. So you can cobble up a set of $CFLAGS to build the kernel.

Also, Debian (aka Raspberry Pi OS) and Slackware Arm both have current distros handling the early Arm cpus with no FPU. You do have to dig or ask for urls, but you don't have to compile.

Slackware packages just untar from /, which is handy.

SCerovec · 09-01-2022, 03:34 AM

Quote:

Originally Posted by business_kid

IMHO, that's a gcc problem.

If you set the gcc options correctly, gcc will insert code to emulate FP instructions when it comes accross them. So you can cobble up a set of $CFLAGS to build the kernel.

Also, Debian (aka Raspberry Pi OS) and Slackware Arm both have current distros handling the early Arm cpus with no FPU. You do have to dig or ask for urls, but you don't have to compile.

Slackware packages just untar from /, which is handy.

1. I agree it's a gcc problem.

2. I doubt it's a parameter problem, as I see other distros picking a particular build of gcc, not a mere configure option (hard, soft, softfp) among several there might be.

3. there is that g_nano/c_nano issue down the road too

business_kid · 09-01-2022, 05:38 AM

I disagree on the parameter thing personally.

Back in the early 2000s I was into LFS and there were a lot of guys trying to make themselves Arm versions of LFS. I saw the difficulties then. But it could be done. I'm afraid you're in for a period of

'man gcc' in one terminal.
Slowly adding the required options to a command in another.

Enjoy your day.

If it matters any, the guys on lfs back then usually managed the big hurdles. It was the long list of programs requiring compilation without strace or gdb that wore them down. Back then, Professionals usually managed it and moved on, amateurs usually retired licking their wounds.

Programmers always are superstitious about gcc versions. There are so many configure options, and software guys become aware of 'a good one.' One that I came accross was tjhat back in the early 2000s, when gcc-3.0 came out, Linus still wanted all kernels built on gcc-2.95-3. There was a good 6 months of this and we were up to something like gcc-3.3 before he admitted kernels were building well on gcc-3.x. There were big changes then: Position Independent Code; Position Independent Executables; Stack Protection; Phasing out all the fixed addressed I/O, ISA, serial & parallel ports, etc.

There could be similar issues now for Arm - I am simply a user now so I don't try to keep up. Just checking the installed system, the Broadcom stuff on github arrears to be installed with the compiled kernel package. The kernel source has a number of .dts (ascii) files in the kernel source under ~arch/arm/boot/dts, and a big ~drivers/gpu/drm/vc4/vc4_firmware_kms.c. So I can acquit the slarm64 guys on the charge of including anything binary.

SCerovec · 09-01-2022, 06:07 AM

Quote:

Originally Posted by business_kid

Back in the early 2000s I was into LFS and there were a lot of guys trying to make themselves Arm versions of LFS. I saw the difficulties then. But it could be done. I'm afraid you're in for a period of

'man gcc' in one terminal.
Slowly adding the required options to a command in another.

Enjoy your day.

If it matters any, they usually managed the big hurdles. It was the long list of programs requiring compilation without strace or gdb that wore them down. Back then, Professionals usually managed it and moved on, amateurs usually retired licking their wounds.

I was afraid you'd say (well,, write) that

My half ass educated guess is in that line too.So far I've gleaned at the docs (before even posting here) hints me at needing a specifically compiled GCC for just that, but i might be wrong and it might be possible to maneuver around this with mere makefile tweaks back and forth...

business_kid · 09-01-2022, 07:48 AM

Quote:

Originally Posted by SCerovec

My half ass educated guess is in that line too.So far I've gleaned at the docs (before even posting here) hints me at needing a specifically compiled GCC for just that, but i might be wrong and it might be possible to maneuver around this with mere makefile tweaks back and forth...

having compiled gcc many times (as one does in lfs) I never noticed an option to remove or include floating point instructions. It could be done with command line options then. It could be configure options now. I don't know.
Have you tried the two sources I gave you - the slackware arm lot or maybe debian/raspbian/whatever?
Slackware Arm (a subforum of slackware) will answer you definitely.

SCerovec · 09-02-2022, 03:46 AM

Quote:

Originally Posted by business_kid

having compiled gcc many times (as one does in lfs) I never noticed an option to remove or include floating point instructions. It could be done with command line options then. It could be configure options now. I don't know.
Have you tried the two sources I gave you - the slackware arm lot or maybe debian/raspbian/whatever?
Slackware Arm (a subforum of slackware) will answer you definitely.

What do You know, i did a third thing

...

I installed (meanwhile) a BeagleBone black with an debian image and tried to install klipper there (gcc 10.x.x)...

Short story long, it didn't went thru smooth either, but after repeating few failed commands (!) i managed to see thru the compilation of the stm32F103 firmware (klipper.bin).

This leads me to the conclusion that:

1. The options i gleaned from the Slackbuild sem to be aimed at the gcc binary alone and are used to unlock the best performance on the host using it.
2. The building process with klipper might be somewhat obsolete and i will have to bear some to see it thru on Slackware.
3. The target build scripts aren't perfect either, and i better glean some more in klipper docs alongside gcc docs too.
4. Linux while a far cry from the red hat being leader distro days, is still a mess at times and at certain spots.

P.S.
That BeagleBone black seems somewhat slower than the Banana pi so i hope i see thru with this with Slackware as i always managed before.

business_kid · 09-02-2022, 05:24 AM

I don't have the specs to hand but yes, they are sad and sadder little boxes aimed at trivial tasks.

If you have the facilities, it might be no harm to install the system on a vm locally. The Pi 4 runs qemu, I believe. Then you have a backup (for the next sd card) and and an environment to compile anything else you need. Mark this solved if you have a result

SCerovec · 09-02-2022, 06:36 AM

Code:

~/src/klipper$ gcc -v
Reading specs from /usr/lib/gcc/arm-slackware-linux-gnueabihf/11.2.0/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/arm-slackware-linux-gnueabihf/11.2.0/lto-wrapper
Target: arm-slackware-linux-gnueabihf
Configured with: ../configure --with-arch=armv7-a --with-float=hard --with-fpu=vfpv3-d16 --with-tune=generic-armv7-a --disable-sjlj-exceptions --verbose --prefix=/usr --mandir=/usr/man --infodir=/usr/info --libdir=/usr/lib --enable-bootstrap --enable-checking=release --enable-libstdcxx-dual-abi --enable-shared --enable-languages=ada,c,c++,d,fortran,go,lto,objc,obj-c++ --enable-objc-gc --enable-threads=posix --enable-__cxa_atexit --enable-gnu-unique-object --enable-clocale=gnu --enable-plugin --enable-lto --with-arch-directory= --with-system-zlib --with-gnu-ld --with-isl --with-default-libstdcxx-abi=new --disable-libunwind-exceptions --disable-libstdcxx-pch --disable-libssp --disable-werror --disable-gtktest --disable-install-libiberty --host=arm-slackware-linux-gnueabihf --build=arm-slackware-linux-gnueabihf --target=arm-slackware-linux-gnueabihf
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.0 (GCC)

question:
does the red emphasized option apply to generated code as a default or just at the gcc alone as a binary leaning on hardware FPU?

SCerovec · 09-02-2022, 07:11 AM

I've just found out: it applies to the gcc binary only.

The hunt goes on...

business_kid · 09-02-2022, 07:53 AM

Quote:

arm-slackware-linux-gnueabihf

This bit applies to the libc, afaict, = everything really. hf = hard float.
It looks to me like you have the standard 32bit slackware arm for ≥Arm A7 = Pi 2 or later. They do, or did a distro that accomodated the Pi zero - Arm A5 or something.

Just doing a quick hunt, slackware-14.1 seems to support? It's on ftp.slackware.uk. I see you trying to compile klipper? klipper from kde? Surely running kde on a little box like that is like entering an electric bicycle in the Isle on Man TT?