Linux kernel on ARM Cortex-M: how to build proper executables

6
votes

I need to build a complete linux development framework for a Cortex-M MCU, specifically a STM32F7 Cortex-M7. First I've to explain some background info so please bear with me.

I've downloaded and built a gcc toolchain with croostool-ng 1.24 specifying an armv7e-m architecture with thumb-only instructions and linux 4.20 as the OS and that I want the output to be FLAT executables (I assumed it will mean bFLT).

Then I proceeded to compile the linux kernel (version 4.20) using configs/stm32_defconf, and then a statically compiled busybox rootfs, all using my new toolchain.

Kernel booted just fine but throw me an error and kernel painc with the following message:

Starting init: /sbin/init exists but couldn't execute it (error -8)

and

request_module: modprobe binfmt-464c cannot be processed, kmod busy with 50 threads

The interesting part is the last message. My busybox excutable turned out to be an .ELF! Cortex-M has no MMU, so it's imposible to build a linux kernel on a MMU-less architecture with .ELF support, that's why an (464c)"LF" binary loader can't be found, there is none.

So at last, my question is:

how could I build bFLT executables to run on MMU-less Linux architectures? My toolchain has elf2flt, but in crosstool-ng I've already specified a MMU-less architecture and FLAT binary and I was expecting direct bFLT output, not a "useless" executable. Is that even possible?

Or better: is there anywhere a documented standard procedure to build a complete, working Linux system based on Cortex-M?

Follow-up:

I gave up on building FLAT binaries and tried FDPIC executables. Another dead end. AFAIK:

  1. Linux has long been supporting ELF FDPIC, but the ABI for ARM is pretty new.
  2. It seems that still at this day and age, GCC has not a standard way to enable FDPIC. On some architectures you can use -mfdpic. Not on arm, don't know why. I even don't know if ARM FDPIC is supported at all by mainline GCC. Info is extremely scarce if inexistent.
  3. It seems crosstool-ng 1.24 is BROKEN at building ARM ELF FDPIC support. Resulting gcc has not -mfdpic, and -fPIC generates ARM executables, not ARM FDPIC.

Any insight will be very appreciated.

1
linuxgccembeddedcortex-mtoolchain
The 'standard procedure' would be to use yocto - specifically a yocto recipe that was designed for your SoC, SoM or atleast your specific controller. – markus-nm
I can't answer your question but I have always been told that STM32 MCUs don't have enough RAM to run Linux. Did you take this issue into account ? – Guillaume Petitjean
@markus-nm I'll look into yocto, thanks! – conejoroy
@GuillaumePetitjean that's not correct. It's common for mid/high pin versions of Cortex-M3/4/7 to have an external memory controller, then you can add SDRAM. 16 Mb should be more than enough to run Linux. My system has 16 Mb and it boots just fine until it reaches the point of executing something I cannot build properly. – conejoroy
Even if you don't want to use yocto examining what it does will lead you to your answer. It's fairly normal to use .elf as an intermediate format even for targets that cannot load one at runtime and then have to convert it to something else, for example the smaller Cortex-M parts you link to an elf then use objcopy to write that out as a flat binary image of what goes in flash and if I recall the process for bFLT is similar. I'm not sure there's an economic case for what you are doing however especially as there are cheap parts with MMU's. – Chris Stratton

1 Answers

0
votes

you can generate FDPIC ELF files just with a prebuilt arm-linux-gnueabi-gcc compiler.

Specifications of an FDPIC ELF file:

  • Position independent executable/code (i.e. -fPIE and fPIC)
  • Should be compiled as a shared executable (ET_DYN ELF) to be position independent

use these flags to compile your programs:

arm-linux-gnueabi-gcc -shared -fPIE -fPIC <YOUR PROGRAM.C> -o <OUTPUT FILE>

I've compiled busybox successfully for STM32H7 with this method.

As I know, unfortunately FDPIC ELFs should be compiled with - shared flag so, they use shared libraries and cannot be compiled as -static ELF.

For more information take a look at this file:

https://github.com/torvalds/linux/blob/master/fs/binfmt_elf_fdpic.c

Track the crosstool-ng BFLAT issue from here:

https://github.com/crosstool-ng/crosstool-ng/issues/1399