[Buildroot] Building packages for Cortex M4

[Buildroot] Building packages for Cortex M4

[Andrey Nechypurenko]

Hi Buildrooters,

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.

Thank you,
Andrey.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Building packages for Cortex M4

[Thomas Petazzoni]

Hello Andrey,

On Wed, 8 Dec 2021 17:46:58 +0100
Andrey Nechypurenko <andreynech@gmail.com> wrote:

> 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.

Best regards,

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Building packages for Cortex M4

[Andrey Nechypurenko]

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))

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@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Building packages for Cortex M4

[Thomas Petazzoni]

Hello Andrey,

On Thu, 9 Dec 2021 18:02:27 +0100
Andrey Nechypurenko <andreynech@gmail.com> wrote:

> 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
> #
> ################################################################################

We already have a package for an ARM toolchain, in
package/arm-gnu-a-toolchain/. However, we have found that this
toolchain is targeted at Cortex-A, and while in theory it should work
for Cortex-M as well, the Cortex-M examples from ST (at least) expect
some libraries that are not in the Cortex-A toolchain provided by ARM,
but only the Cortex-M.

This is why in
https://github.com/bootlin/buildroot/commit/8635d412292eec7bb90bfabcba25a8c238aa2f93
we switch to the Cortex-M/Cortex-R toolchain for this package. But this
isn't directly suitable for upstream. More work is needed here.

> 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?

Yes, that looks, except for the toolchain package, where we probably
want to re-use what already exists :)

Thomas
-- 
Thomas Petazzoni, co-owner and CEO, Bootlin
Embedded Linux and Kernel engineering and training
https://bootlin.com
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Building packages for Cortex M4

[Andrey Nechypurenko]

Hello Thomas,

>> 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
>> #
>> ################################################################################
>
> We already have a package for an ARM toolchain, in
> package/arm-gnu-a-toolchain/. However, we have found that this
> toolchain is targeted at Cortex-A, and while in theory it should work
> for Cortex-M as well, the Cortex-M examples from ST (at least) expect
> some libraries that are not in the Cortex-A toolchain provided by ARM,
> but only the Cortex-M.
>
> This is why in
> https://github.com/bootlin/buildroot/commit/8635d412292eec7bb90bfabcba25a8c238aa2f93
> we switch to the Cortex-M/Cortex-R toolchain for this package. But this
> isn't directly suitable for upstream. More work is needed here.

Do you think that having two different toolchain packages for Cortex-A and
M/R would make sense? Sooner or later someone will probably ask for Cortex-A
also. If yes, I would be glad if you will find my package for Cortex-M/R
good enough to integrate in Buildroot :-) .


Thank you,
Andrey.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [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@buildroot.org
> https://lists.buildroot.org/mailman/listinfo/buildroot
> 
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Building packages for Cortex M4

[Andrey Nechypurenko]

Hi Arnout,

On Sat, 11 Dec 2021 at 09:35, Arnout Vandecappelle <arnout@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.
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot

Re: [Buildroot] Building packages for Cortex M4

[Yann E. MORIN]

Andrey, All,

On 2021-12-13 18:36 +0100, Andrey Nechypurenko spake thusly:
> On Sat, 11 Dec 2021 at 09:35, Arnout Vandecappelle <arnout@mind.be> wrote:
> > On 09/12/2021 18:02, Andrey Nechypurenko wrote:
[--SNIP--]
> > > 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.

What Arnout was wondering about, is not about using cmake or not; it was
about using the cmake-package infrastructure in Buildroot or not.

I.e., what he was basically suggesting between the lines, was to make
that a generic package, something along the lines of:

    COMCU_DEPENDENCIES = host-cmake

    define COMCU_CONFIGURE_CMDS
        $(BR2_CMAKE) $(@D) \
            -DTOOLCHAIN_DIR=$(HOST_DIR)/share/gcc-arm-none-eabi \
            -DCMAKE_TOOLCHAIN_FILE=cmake/TOOLCHAIN_arm_none_eabi_cortex_m4.cmake \
            [etc...]
    endef

    define COMCU_BUILD_CMDS
        $(MAKE) -C $(@D)
    endef

    define COMCU_INSTALL_TARGET_CMDS
        $(MAKE) -C $(@D) DESTDIR=$(TARGET_DIR) install/fast
    endef

    $(eval $(generic-package))

And I do agree with him, in that our cmake infra is made only for
building stuff that runs on the architecture that is defined in
Buildroot's configuration, not to build firmwares that run in add-on
CPUs...

However, I can also see that the way you did it also makes the package
drastically simpler that repeating a good part of the cmake-package
infra, so I am a bit torn...

 would still think that it would be better to do a generic-package,
because the cmake-pakcage infra can very well get additional "features"
that would render it unusable for using with another toolchain file.
And I would like to avoid introducing a precedent...

So I'm back with Arnout: make that a generic-package.

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 561 099 427 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot