[Buildroot] Building packages for Cortex M4

[Andrey Nechypurenko]

Hi Arnout,

On Sat, 11 Dec 2021 at 09:35, Arnout Vandecappelle <arnout at mind.be> wrote:
>
>
>
> On 09/12/2021 18:02, Andrey Nechypurenko wrote:
> > Hello Thomas,
> >
> >>> I am currently playing with Avenger96 Board which is powered by
> >>> ST32MP157 with A7 and M4 cores. Part of my system is the firmware for
> >>> the M4 microcontroller which should be compiled with a corresponding
> >>> variant of gcc (not the one used to compile the rest of the system)
> >>> and placed in /lib/firmware in the rootfs/image.
> >>>
> >>> I am wondering if this kind of scenario (two different
> >>> cross-compilers) is supported by Buildroot and if yes, is there any
> >>> documentation on how to do it? If there is no "standard" way to
> >>> achieve this, I would appreciate any recommendations.
> >>
> >> Yes, it is possible by installing a separate bare-metal compiler using
> >> an additional host package in Buildroot.
> >>
> >> You can see https://github.com/bootlin/buildroot-external-st is able to
> >> build the M4 examples from ST. Note that this BR2_EXTERNAL works with a
> >> few patches on Buildroot itself, available at
> >> https://github.com/bootlin/buildroot/commits/st/2021.02. One of the
> >> change is precisely on the bare metal toolchain package.
> >
> > Thank you for the links. Will definitely take a look at it.
> >
> > In the meantime, I came up with the following solution and wondered what
> > would you say about it. First, I made host package which downloads and
> > installs M4 toolchain from ARM site (inspired by
> > https://gist.github.com/titouanc/ea0685d9cd8592deb1c49d48e33b3eee )
> >
> > Config.in.host:
> >
> > ################################################################################
> > #
> > # gcc-arm-none-eabi
> > #
> > ################################################################################
> >
> > config BR2_PACKAGE_HOST_GCC_ARM_NONE_EABI_SUPPORTS
> >      bool
> >      default y
> >
> >
> > config BR2_PACKAGE_HOST_GCC_ARM_NONE_EABI
> >      bool "host gcc-arm-none-eabi"
> >      depends on BR2_PACKAGE_HOST_GCC_ARM_NONE_EABI_SUPPORTS
> >      help
> >        The GNU Embedded Toolchain for Arm is a ready-to-use, open source
> >        suite of tools for C, C++ and Assembly programming targeting Arm
> >        Cortex-M and Cortex-R family of processors. It includes the GNU
> >        Compiler (GCC) and is available free of charge directly from Arm
> >        for embedded software development on Windows, Linux and Mac OS X
> >        operating systems.
> >
> >        https://developer.arm.com/open-source/gnu-toolchain/gnu-rm/downloads
> >
> >
> > gcc-arm-none-eabi.mk:
> >
> > ################################################################################
> > #
> > # GNU Arm Embedded Toolchain
> > #
> > ################################################################################
> >
> > GCC_ARM_NONE_EABI_VERSION = 10.3-2021.10
> >
> > GCC_ARM_NONE_EABI_SOURCE =
> > gcc-arm-none-eabi-$(GCC_ARM_NONE_EABI_VERSION)-$(HOSTARCH)-linux.tar.bz2
> > GCC_ARM_NONE_EABI_SITE =
> > https://developer.arm.com/-/media/Files/downloads/gnu-rm/$(GCC_ARM_NONE_EABI_VERSION)
> >
> > GCC_ARM_NONE_EABI_LICENSE = GPL-2.0+, LGPL-2.1+
> > GCC_ARM_NONE_EABI_LICENSE_FILES = share/doc/gcc-arm-none-eabi/license.txt
> >
> > # This is a prebuilt toolchain, we only extract it to the host
> > GCC_ARM_NONE_EABI_INSTALLDIR = $(HOST_DIR)/share/gcc-arm-none-eabi
> >
> > define HOST_GCC_ARM_NONE_EABI_INSTALL_CMDS
> >      mkdir -p $(GCC_ARM_NONE_EABI_INSTALLDIR)
> >      cp -dpfr $(@D)/* $(GCC_ARM_NONE_EABI_INSTALLDIR)
> > endef
> >
> > $(eval $(host-generic-package))
> >
> > Then I define toolchain file for CMake and made the following .mk file for
> > my M4 application (defined as a separate Buildroot package):
> >
> > comcu.mk:
> >
> > ################################################################################
> > #
> > ## comcu
> > #
> > #################################################################################
> >
> > COMCU_SITE = $(TOPDIR)/../src/comcu
> > COMCU_SITE_METHOD = local
> >
> > COMCU_CONF_OPTS = \
> >      -DTOOLCHAIN_DIR=$(HOST_DIR)/share/gcc-arm-none-eabi \
> >      -DCMAKE_TOOLCHAIN_FILE=cmake/TOOLCHAIN_arm_none_eabi_cortex_m4.cmake \
> >      -DUSE_HAL_DRIVER=ON \
> >      -DUSE_LL_DRIVER=OFF \
> >      -DUSE_OPENAMP=ON \
> >      -DUSE_STM32_USB_FS_LIB=OFF \
> >      -DUSE_FREERTOS=OFF \
> >      -DUSE_SEMIHOSTING=OFF \
> >      -DUSE_STTERM=OFF \
> >      -DUSE_DBGUART=OFF \
> >      -DUSE_GDB=OFF \
> >      -DUSE_OVERCLOCKING=OFF \
> >      -DUSE_TINY_PRINTF=OFF \
> >      -DSRC=Src \
> >      -DGITHUB_DRIVERS=OFF
> >
> > $(eval $(cmake-package))
>
>   I wonder if we really want to use cmake-package here... The cmake-package
> infrastructure is geared towards building for the target, not for some other
> CPU. The fact that you need to override the toolchain file is indicative of this
> problem.

Could you please elaborate on it a little bit? My understanding is that
independent of what build-system (cmake or whatever else) is used, somehow
you need to say that other toolchain should be used to compile particular
package. CMake's way of doing it is to use the toolchain file. Somehow I can
not see any big disadvantages with it. Similarly I can not see any big
advantages of using other build-systems. They will need to do the same but
with different syntax.

The only reason why I used cmake here is because this is what provided by ST
as an example. The CMake file is not trivial with all these
CMSIS/HAL/BSP/Cube/... things. Since I do not see any big advantages from
using other build system, I can not find enough motivation to spend time on
converting cmake staff to something different. That is why I would
appreciate if you can provide more details on why cmake could be a bad idea
in this case.


Thank you,
Andrey.