简体   繁体   中英

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

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.

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 (ie -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

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM