[Buildroot] Building packages for Cortex M4

[Arnout Vandecappelle]

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.

  On the other hand, if overriding the toolchain file is really the only thing 
that needs to change, then perhaps using cmake-package is fine.

  Yann usually has some good opinions on philosophical stuff like this.

  Regards,
  Arnout


> 
> Except for a couple of small errors in the CMakeLists.txt which need yet to be
> fixed, it looks like this solution would work for me.
> 
> What do you think about it?
> 
> 
> Thank you very much,
> Andrey.
> _______________________________________________
> buildroot mailing list
> buildroot at buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
>