Repository files navigation

This project contains crosstool-ng .config files to build OpenMP-enabledbare-metal GCC cross-compilers:

• aarch64 -- ARMv8
• arm-cortexm7 -- ARMv7 Cortex-M7
• arm-uboot -- ARMv7 Cortex-A9 with NEON (i.MX6Q) with aapcs-linux
• arm-cortexm0p -- ARMv7 Cortex-m0+
• arm-cortexm33 -- ARMv7 Cortex-m33

Normally bare metal compilers do not have OpenMP support, since it isassumed that considerable operating system support is required to makeOpenMP work. However, it is actually not that difficult to get a subsetof OpenMP working on a multi-core bare metal system.

To build a bare-metal OpenMP-enabled toolchain you first need a couplemods to crosstool-ng which are contained in the project athttps://github.com/jrengdahl/crosstool-ng-openmp. After downloadingmy modified version of crosstool-ng, follow the instructions athttps://crosstool-ng.github.io/docs to build and install ct-ng. You canthen use the modified ct-ng and the .config files in this project tobuild the GCC toolchains.

Windows cross-compilers are built from a Cygwin64 bash shell.The Linux versions are built using Debian running under Windows Subsystemfor Linux (WSL). These should work equally well under any real Linux system.

I built the Windows toolchains on a Windows PC using Cygwin. Following the ct-ng instructions,You need to enabled case-sensitive filenames in the C:/cross subdirectory. Seehttps://learn.microsoft.com/en-us/windows/wsl/case-sensitivity. So I don't haveto remember the command I created setcase.bat which contains the command:"fsutil file setCaseSensitiveInfo %1 enable". Remember that this onlyworks if the directory is empty when the command is run.

I want the toolchains to be useable in both Cygwin and non-Cygwinenvironments. In order to do this, I need to copy two of the Cygwin DLLsinto the toolchain's bin directory, and move or copy two directories.See the file SetupOpenMP.txt for detailed instructions.

More recently (early 2024) this stunt does not seem to work any more. I had better luckwith creating a subdirectory arm-cortexm7-eabi/cygwin64/bin, copying ALL the CygwinDLLs there, then puttingf that directory on the Eclipse PATH.

If you run the toolchains in a Cygwin environment it is necessary thatthe versions of the DLLs in the toolchain bin directory match the installed Cygwinversion. I recommend that you update your Cygwin, then update the DLLsin the toolchain by copying them from C:/Cygwin64/bin. If you do not useCygwin you should not need to do this.

In my world I run the toolchain in a Cygwin environment whenever I compilesomething by typing commands in a shell window. When I compile using anEclipse project, the tools are run in a non-Cygwin environment automaticallycreated by Eclipse. This is why I need the toolchain to work in both Cygwinand non-Cygwin environments.

What I really wanted to do was build the toolchains using Cygwin's MSYScompilers. Applications built with MSYS and statically linked are independentof any DLLs and are more portable. However, MSYS does not seem to be completeenough to build GCC.

For now, you need to copy omp.h from another toolchain into the new toolchain.TODO -- create a crosstool-ng patch to make this step unnecessary.

You may also need to copy in a gdb executable -- I have not yet tried integratingthe toolchain into Eclipse under Linux.

Here are some of the more significant changes made to the .config file:

• CT_PREFIX_DIR="${PWD}/../../${CT_TARGET}"
  (Cygwin only) This causes the toolchain to be installed under C:\cross, which is where I keep my cross toolchains.There is a possibility that moving the toolchain to another location may not work in some cases(such as in a non-Cygwin environment) due to how Cygwin translates path names.I suspect it has something to do with cygwin1.dll becoming offended at finding itself in <toolchain>/binrather than in C:/cygwin64/bin.If moving the install location breaks for you, you may have to adjust this setting and re-build the toolchain for your environment,or just keep the toolchains in C:\cross.

• CT_TARGET_CFLAGS="-ffixed-x18" or CT_TARGET_CFLAGS="-ffixed-r9"
  This causes the compiler to build libraries that do not use the platform register as defined inthe ARM or Aarch64 Procedure Call Standards (AAPCS):

  "The role of register r9 is platform specific. A virtual platform may assign any role to thisregister and must document this usage. For example, it may designate it as the static base (SB)in a position-independent data model, or it may designate it as the thread register (TR) in anenvironment with thread-local storage. The usage of this register may require that the valueheld is persistent across all calls. A virtual platform that has no need for such a specialregister may designate r9 as an additional callee-saved variable register."

  This is only needed if your bare metal thread switching code uses the platform register.Doing so enables significant optimization of bare metal thread switching.

• CT_TARGET_VENDOR="<something useful>"
  Since bare metal toolchains typically put "none" or "unknown" as the second field of the triplet,which is uninformative, I decided to put helpful identifiers such as "openmp" or "uboot" here.

• CT_THREADS_NONE=y
  This is set, since the bare metal environment does not support Pthreads or any other known operatingsystem defined threading system. I am still learning OpenMP, but as far as I can tell at this point,OpenMP does not explicitly depend on Pthreads, therefore it doesn't make sense that the GCCbuild system enforces a dependency between OpenMP and Pthreads. Any Pthreads dependencies are hiddenwithin libgomp. To use OpenMP under bare metal, the threading mechanism must be provided by animplementation of libgomp.

• CT_CC_GCC_LIBGOMP=y
  This flag enables OpenMP in the compiler. By default, the GCC config system will override this settingif CT_THREADS_NONE=y is set. A couple modifications to crosstool-ng were required to overcome this.

• CT_GDB_CROSS is not set
  I was not able to get crosstool-ng to successfully build GDB. It has something to do with the version ofPython found by the configure script. Since I don't use GDB I simply turned this option off rather thanspending time debugging the problem. Since the Eclipse toolchain manger requires the presence of gdbin the toolchain bin directory (even if it is not used), I copied in a gdb from another similar toolchainand renamed it to match the triplet. I don't know if this gdb would work.

The ARMv8 toolchains are built for generic ARMv8 and multilib, but the ARMv7 versionsare built for specific processors. I did this to have better control of library generationand hopefully better optimization for ARMv7. I am not expert at building GCC, so itremains to be seen if I know what I am doing here.

• arm-uboot-eabi
  This toolchain is built for

  • Cortex-A9
  • NEON
  • aapcs-linux

  This toolchain is optimized for the NXP i.MX6Q. I was looking for a multi-coreARM platform which is supported by Segger J-link and Ozone, and has an on-chiptrace buffer. The i.MX6Q meets all these requirements, and I found a Sabre Liteboard and severalKaro Electronics TX6Q-1010 SoM modules on e-Bay for a good price. Most otherreadily available (and cheap) ARMv7-A implementations, such as Raspberry Pior the Rockchip RK3188, have only external trace ports, which requires developersto purchase very expensive trace probes.

  The aapcs-linux setting causes the use of fixed-length enums rather thanthe default variable length, which allows this toolchain to be used to buildu-boot and u-boot standalone apps. This is still experimental.

• arm-cortexm7
  Since the M7 is single-core it may not seem sensical to have an OpenMP-enabledcompiler for it, but I found it useful to debug OpenMP in a single-core,multi-threaded environment. I will also use this toolchain for non-OpenMPCortex-M7 projects.

##Releases:

• v0.0 First experimental release.
• v0.0.1 Fixed packaging issue for Windows binaries.
• v1.0 Oops, haven.t quite figured out tagging yet.
• v1.1 Add Cortex-M33, release GCC 12.2 for Cortex-m33.
• v1.2 Update Cortex-M33 and Cortex-M7 to GCC 13.2.