| Message ID | 20210908081630.3404221-1-kory.maincent@bootlin.com |
|---|---|
| State | Accepted |
| Headers | show |
| Series | package/arm-gnu-a-toolchain: bump to version 10.3-2021.07 | expand |
On 08/09/2021 10:16, Kory Maincent wrote: > Update to version 10.3-2021.07. > The old version contained a nasty nano.spec. The nano.spec file was adding > -lc_nano option but the c_nano.a library was not delivered in the > toolchain archive. > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > --- > package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash | 2 +- > package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) > > diff --git a/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash b/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash > index b18e56c151..26b9f1be1e 100644 > --- a/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash > +++ b/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash > @@ -1,2 +1,2 @@ > # Locally calculated > -sha256 ac952d89ae0fc3543e81099e7d34917efc621f5def112eee843fd1ce755eca8c gcc-arm-9.2-2019.12-x86_64-arm-none-eabi.tar.xz > +sha256 8c5b8de344e23cd035ca2b53bbf2075c58131ad61223cae48510641d3e556cea gcc-arm-none-eabi-10.3-2021.07-x86_64-linux.tar.bz2 > diff --git a/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk b/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk > index d7088892ca..1bbfa45d78 100644 > --- a/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk > +++ b/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk > @@ -4,9 +4,9 @@ > # > ################################################################################ > > -ARM_GNU_A_TOOLCHAIN_VERSION = 9.2-2019.12 > -ARM_GNU_A_TOOLCHAIN_SITE = https://developer.arm.com/-/media/Files/downloads/gnu-a/$(ARM_GNU_A_TOOLCHAIN_VERSION)/binrel > -ARM_GNU_A_TOOLCHAIN_SOURCE = gcc-arm-$(ARM_GNU_A_TOOLCHAIN_VERSION)-x86_64-arm-none-eabi.tar.xz > +ARM_GNU_A_TOOLCHAIN_VERSION = 10.3-2021.07 > +ARM_GNU_A_TOOLCHAIN_SITE = https://developer.arm.com/-/media/Files/downloads/gnu-rm/$(ARM_GNU_A_TOOLCHAIN_VERSION) > +ARM_GNU_A_TOOLCHAIN_SOURCE = gcc-arm-none-eabi-$(ARM_GNU_A_TOOLCHAIN_VERSION)-x86_64-linux.tar.bz2 Err, this can't be right... 'gnu-rm' stands for "GNU-based toolchain for Cortex-R and Cortex-M", and "arm-none-eabi" means it's a toolchain without libc... So either someone made a huge mistake at ARM, or you haven't actually tested this patch :-) Regards, Arnout > ARM_GNU_A_TOOLCHAIN_LICENSE = GPL-3.0+ > > HOST_ARM_GNU_A_TOOLCHAIN_INSTALL_DIR = $(HOST_DIR)/opt/gcc-arm-none-eabi >
Hello, On Sun, 19 Sep 2021 14:35:56 +0200 Arnout Vandecappelle <arnout@mind.be> wrote: > > -ARM_GNU_A_TOOLCHAIN_VERSION = 9.2-2019.12 > > -ARM_GNU_A_TOOLCHAIN_SITE = https://developer.arm.com/-/media/Files/downloads/gnu-a/$(ARM_GNU_A_TOOLCHAIN_VERSION)/binrel > > -ARM_GNU_A_TOOLCHAIN_SOURCE = gcc-arm-$(ARM_GNU_A_TOOLCHAIN_VERSION)-x86_64-arm-none-eabi.tar.xz > > +ARM_GNU_A_TOOLCHAIN_VERSION = 10.3-2021.07 > > +ARM_GNU_A_TOOLCHAIN_SITE = https://developer.arm.com/-/media/Files/downloads/gnu-rm/$(ARM_GNU_A_TOOLCHAIN_VERSION) > > +ARM_GNU_A_TOOLCHAIN_SOURCE = gcc-arm-none-eabi-$(ARM_GNU_A_TOOLCHAIN_VERSION)-x86_64-linux.tar.bz2 > > Err, this can't be right... 'gnu-rm' stands for "GNU-based toolchain for > Cortex-R and Cortex-M", and "arm-none-eabi" means it's a toolchain without libc... > > So either someone made a huge mistake at ARM, or you haven't actually tested > this patch :-) It was tested to build code for a Cortex-M4. This package was originally introduced to build ARM 32-bit code in the context of TF-A (boot/arm-trusted-firmware/). At the very beginning, was submitted by a Marvell person, who also had to build code for a Cortex-M3 co-processor IIRC, but then was taken over by a person from Amarula, who needed it to build ARM 32-bit code running on a Cortex-A. If it's truly a bare-metal toolchain with no libraries, it should not matter, right? You just pass to gcc -march=XYZ, and it will produce the right code. However, my understanding is that those bare-metal toolchains do have some libraries built for the target, which can potentially get linked with the code produced. So, long story short: do we need arm-gnu-a-toolchaind and arm-gnu-rm-toolchain packages ? Best regards, Thomas
On 19/09/2021 15:09, Thomas Petazzoni wrote: > Hello, > > On Sun, 19 Sep 2021 14:35:56 +0200 > Arnout Vandecappelle <arnout@mind.be> wrote: > >>> -ARM_GNU_A_TOOLCHAIN_VERSION = 9.2-2019.12 >>> -ARM_GNU_A_TOOLCHAIN_SITE = https://developer.arm.com/-/media/Files/downloads/gnu-a/$(ARM_GNU_A_TOOLCHAIN_VERSION)/binrel >>> -ARM_GNU_A_TOOLCHAIN_SOURCE = gcc-arm-$(ARM_GNU_A_TOOLCHAIN_VERSION)-x86_64-arm-none-eabi.tar.xz >>> +ARM_GNU_A_TOOLCHAIN_VERSION = 10.3-2021.07 >>> +ARM_GNU_A_TOOLCHAIN_SITE = https://developer.arm.com/-/media/Files/downloads/gnu-rm/$(ARM_GNU_A_TOOLCHAIN_VERSION) >>> +ARM_GNU_A_TOOLCHAIN_SOURCE = gcc-arm-none-eabi-$(ARM_GNU_A_TOOLCHAIN_VERSION)-x86_64-linux.tar.bz2 >> >> Err, this can't be right... 'gnu-rm' stands for "GNU-based toolchain for >> Cortex-R and Cortex-M", and "arm-none-eabi" means it's a toolchain without libc... >> >> So either someone made a huge mistake at ARM, or you haven't actually tested >> this patch :-) Or, of course, I can't read and I see toolchain/toolchain-external/toolchain-external-arm-arm instead of package/arm-gnu-a-toolchain... Worse still: I didn't see that the old one already *was* arm-none-eabi, it was just specified at the end of the tarball name instead of at the beginning. > It was tested to build code for a Cortex-M4. > > This package was originally introduced to build ARM 32-bit code in the > context of TF-A (boot/arm-trusted-firmware/). At the very beginning, > was submitted by a Marvell person, who also had to build code for a > Cortex-M3 co-processor IIRC, but then was taken over by a person from > Amarula, who needed it to build ARM 32-bit code running on a Cortex-A. > > If it's truly a bare-metal toolchain with no libraries, it should not > matter, right? You just pass to gcc -march=XYZ, and it will produce the > right code. However, my understanding is that those bare-metal > toolchains do have some libraries built for the target, which can > potentially get linked with the code produced. Yeah, you get libgcc and libstdc++ from the gcc source. libstdc++ is probably not used . libgcc may not be linked in either if -nostdlib is used (which it probably is). > So, long story short: do we need arm-gnu-a-toolchaind and > arm-gnu-rm-toolchain packages ? Easy to check: build a bunch of the defconfigs which set BR2_TARGET_ARM_TRUSTED_FIRMWARE_NEEDS_ARM32_TOOLCHAIN=y. And maybe double-check if indeed ATF doesn't link with libgcc. Regards, Arnout
On Mon, 20 Sep 2021 11:18:34 +0200 Arnout Vandecappelle <arnout@mind.be> wrote: > Yeah, you get libgcc and libstdc++ from the gcc source. libstdc++ is probably > not used . libgcc may not be linked in either if -nostdlib is used (which it > probably is). I think there's more than that, there is a c_nano library integrated in this toolchain. I'm not sure what it is, but the Cortex-M4 code we're building links against that library (I haven't investigated further for now). Best regards, Thomas
On 20/09/2021 14:01, Thomas Petazzoni wrote: > On Mon, 20 Sep 2021 11:18:34 +0200 > Arnout Vandecappelle <arnout@mind.be> wrote: > >> Yeah, you get libgcc and libstdc++ from the gcc source. libstdc++ is probably >> not used . libgcc may not be linked in either if -nostdlib is used (which it >> probably is). > > I think there's more than that, there is a c_nano library integrated in > this toolchain. I'm not sure what it is, but the Cortex-M4 code we're > building links against that library (I haven't investigated further for > now). Obviously, I can't comment on some mysterious out-of-tree package you have... If that package (which I guess will eventually be upstreamed) links with anything that is part of the toolchain, that's still fine as long as there's no other package (i.e. ATF) links with it (and expects a different target architecture). However, if the intention is to use the toolchain for a Cortex-M and you need any of its libraries, it's probably a lot cleaner to simply have a separate arm-gnu-a-toolchain and arm-gnu-rm-toolchain. It's definitely a bit weird to have a package "arm-gnu-a-toolchain" that actually uses the -rm one... Regards, Arnout
Hello Arnout, On Mon, 20 Sep 2021 20:52:29 +0200 Arnout Vandecappelle <arnout@mind.be> wrote: > > I think there's more than that, there is a c_nano library integrated in > > this toolchain. I'm not sure what it is, but the Cortex-M4 code we're > > building links against that library (I haven't investigated further for > > now). > > Obviously, I can't comment on some mysterious out-of-tree package you have... It's not that mysterious in fact, we are building the examples provided by ST for the Cortex-M4 included in their STM32MP157. I would ideally like this package to be submitted to upstream Buildroot, but it has some not so nice aspects: these examples are implemented using some fancy IDE, which saves some "project files", and you can only build the examples using the IDE. The Yocto packaging, which we have replicated in our Buildroot packaging, consists in a Makefile + some scripting that parses those "project files" to generate the final Makefiles to build those examples without the damn IDE. Yeah, not great :-/ > If that package (which I guess will eventually be upstreamed) links with > anything that is part of the toolchain, that's still fine as long as there's no > other package (i.e. ATF) links with it (and expects a different target > architecture). As you can see from above, it won't link with any other thing: it's bare-metal code for a Cortex-M4 micro-controller. > However, if the intention is to use the toolchain for a Cortex-M and you need > any of its libraries, it's probably a lot cleaner to simply have a separate > arm-gnu-a-toolchain and arm-gnu-rm-toolchain. It's definitely a bit weird to > have a package "arm-gnu-a-toolchain" that actually uses the -rm one... Yes, I agree that we should probably add a arm-gnu-rm-toolchain package side-by-side with the arm-gnu-a-toolchain. Köry: something for you to look at, perhaps? :-) Best regards, Thomas Petazzoni
On 23/09/2021 21:55, Thomas Petazzoni wrote: > Hello Arnout, > > On Mon, 20 Sep 2021 20:52:29 +0200 > Arnout Vandecappelle <arnout@mind.be> wrote: > [snip] >> If that package (which I guess will eventually be upstreamed) links with >> anything that is part of the toolchain, that's still fine as long as there's no >> other package (i.e. ATF) links with it (and expects a different target >> architecture). > > As you can see from above, it won't link with any other thing: it's > bare-metal code for a Cortex-M4 micro-controller. Well, bare-metal code often links with a libc that is included in the toolchain (newlib or apparently c-nano in this case), and usually with libgcc as well (for memcpy and friends). Regards, Arnout >> However, if the intention is to use the toolchain for a Cortex-M and you need >> any of its libraries, it's probably a lot cleaner to simply have a separate >> arm-gnu-a-toolchain and arm-gnu-rm-toolchain. It's definitely a bit weird to >> have a package "arm-gnu-a-toolchain" that actually uses the -rm one... > > Yes, I agree that we should probably add a arm-gnu-rm-toolchain package > side-by-side with the arm-gnu-a-toolchain. Köry: something for you to > look at, perhaps? :-) > > Best regards, > > Thomas Petazzoni >
Hello Arnout, Thomas, On Thu, 23 Sep 2021 23:20:40 +0200 Arnout Vandecappelle <arnout@mind.be> wrote: > > >> However, if the intention is to use the toolchain for a Cortex-M and > >> you need any of its libraries, it's probably a lot cleaner to simply have > >> a separate arm-gnu-a-toolchain and arm-gnu-rm-toolchain. It's definitely a > >> bit weird to have a package "arm-gnu-a-toolchain" that actually uses the > >> -rm one... > > > > Yes, I agree that we should probably add a arm-gnu-rm-toolchain package > > side-by-side with the arm-gnu-a-toolchain. Köry: something for you to > > look at, perhaps? :-) Hum, I don't know how to do it properly, without link and naming installation conflict between these two toolchains. Regards, Köry
Hello Köry, On Wed, 8 Sep 2021 10:16:30 +0200 Kory Maincent <kory.maincent@bootlin.com> wrote: > Update to version 10.3-2021.07. > The old version contained a nasty nano.spec. The nano.spec file was adding > -lc_nano option but the c_nano.a library was not delivered in the > toolchain archive. > > Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> > --- > package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash | 2 +- > package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) So, I have applied, but with a very important change: I really bump the gnu-a toolchain, I don't switch to the gnu-rm toolchain, which should be added as a separate package, because it's different. Best regards, Thomas
diff --git a/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash b/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash index b18e56c151..26b9f1be1e 100644 --- a/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash +++ b/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash @@ -1,2 +1,2 @@ # Locally calculated -sha256 ac952d89ae0fc3543e81099e7d34917efc621f5def112eee843fd1ce755eca8c gcc-arm-9.2-2019.12-x86_64-arm-none-eabi.tar.xz +sha256 8c5b8de344e23cd035ca2b53bbf2075c58131ad61223cae48510641d3e556cea gcc-arm-none-eabi-10.3-2021.07-x86_64-linux.tar.bz2 diff --git a/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk b/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk index d7088892ca..1bbfa45d78 100644 --- a/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk +++ b/package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk @@ -4,9 +4,9 @@ # ################################################################################ -ARM_GNU_A_TOOLCHAIN_VERSION = 9.2-2019.12 -ARM_GNU_A_TOOLCHAIN_SITE = https://developer.arm.com/-/media/Files/downloads/gnu-a/$(ARM_GNU_A_TOOLCHAIN_VERSION)/binrel -ARM_GNU_A_TOOLCHAIN_SOURCE = gcc-arm-$(ARM_GNU_A_TOOLCHAIN_VERSION)-x86_64-arm-none-eabi.tar.xz +ARM_GNU_A_TOOLCHAIN_VERSION = 10.3-2021.07 +ARM_GNU_A_TOOLCHAIN_SITE = https://developer.arm.com/-/media/Files/downloads/gnu-rm/$(ARM_GNU_A_TOOLCHAIN_VERSION) +ARM_GNU_A_TOOLCHAIN_SOURCE = gcc-arm-none-eabi-$(ARM_GNU_A_TOOLCHAIN_VERSION)-x86_64-linux.tar.bz2 ARM_GNU_A_TOOLCHAIN_LICENSE = GPL-3.0+ HOST_ARM_GNU_A_TOOLCHAIN_INSTALL_DIR = $(HOST_DIR)/opt/gcc-arm-none-eabi
Update to version 10.3-2021.07. The old version contained a nasty nano.spec. The nano.spec file was adding -lc_nano option but the c_nano.a library was not delivered in the toolchain archive. Signed-off-by: Kory Maincent <kory.maincent@bootlin.com> --- package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.hash | 2 +- package/arm-gnu-a-toolchain/arm-gnu-a-toolchain.mk | 6 +++--- 2 files changed, 4 insertions(+), 4 deletions(-)