diff mbox series

package/arm-gnu-a-toolchain: bump to version 10.3-2021.07

Message ID 20210908081630.3404221-1-kory.maincent@bootlin.com
State New
Headers show
Series package/arm-gnu-a-toolchain: bump to version 10.3-2021.07 | expand

Commit Message

Kory Maincent Sept. 8, 2021, 8:16 a.m. UTC
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(-)

Comments

Arnout Vandecappelle Sept. 19, 2021, 12:35 p.m. UTC | #1
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
>
Thomas Petazzoni Sept. 19, 2021, 1:09 p.m. UTC | #2
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
Arnout Vandecappelle Sept. 20, 2021, 9:18 a.m. UTC | #3
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
Thomas Petazzoni Sept. 20, 2021, 12:01 p.m. UTC | #4
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
Arnout Vandecappelle Sept. 20, 2021, 6:52 p.m. UTC | #5
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
Thomas Petazzoni Sept. 23, 2021, 7:55 p.m. UTC | #6
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
Arnout Vandecappelle Sept. 23, 2021, 9:20 p.m. UTC | #7
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
>
diff mbox series

Patch

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