Skip to contentSkip to conversation

GCC 9 Drops Support For Older ARM Microarchitecture Versions

DISCUSSION Denys Dmytriyenko 6 participants 11 messages May 19, 2018 – May 24, 2018

lore
Share & tools
lore

Denys Dmytriyenko

author
#0 lore raw

https://www.phoronix.com/scan.php?page=news_item&px=GCC-9-Dropping-Older-ARM

Particularly, ARMv5 and ARMv5E are being dropped (but T and TE variants remain)

Are there any concerns from OE community perspective?

At least for binutils we needed this patch even for armv5te:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/binutils/binutils/0007-Add-the-armv5e-architecture-to-binutils.patch

Any other way this change will affect us? Thanks.

Signature · 1 line
Denys
#1 lore raw
Quoted 6 lines · Denys Dmytriyenko

https://www.phoronix.com/scan.php?page=news_item&px=GCC-9-Dropping-Older-ARM

Particularly, ARMv5 and ARMv5E are being dropped (but T and TE variants remain)

Are there any concerns from OE community perspective?

From yocto project perspctive qemuarm which is emulating arm926ejs with default tune armv5te is used.
so we are right at the trailing edge and wont be affected. However, I know there were OE users who had
devices using other armv5 or v4 variants

I have been suggesting to switch qemuarm to use armv7 based board emulator for few years now.
may be this is the time to make that call for next YP release.

Quoted 4 lines

At least for binutils we needed this patch even for armv5te:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/binutils/binutils/0007-Add-the-armv5e-architecture-to-binutils.patch

this patch technically required to support one of OEs available tune values. namely armv5e, we should be
able to drop it.

Quoted 9 lines

Any other way this change will affect us? Thanks.

--
Denys
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

author
#2 lore raw
Quoted 14 lines · Khem Raj
Quoted 6 lines · Denys Dmytriyenko

https://www.phoronix.com/scan.php?page=news_item&px=GCC-9-Dropping-Older-ARM

Particularly, ARMv5 and ARMv5E are being dropped (but T and TE variants remain)

Are there any concerns from OE community perspective?

From yocto project perspctive qemuarm which is emulating arm926ejs with default tune armv5te is used.
so we are right at the trailing edge and wont be affected. However, I know there were OE users who had
devices using other armv5 or v4 variants

Quoted 3 lines

I have been suggesting to switch qemuarm to use armv7 based board emulator for few years now.
may be this is the time to make that call for next YP release.

Valid point about qemuarm, but see below.

Quoted 6 lines
Quoted 3 lines

At least for binutils we needed this patch even for armv5te:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/binutils/binutils/0007-Add-the-armv5e-architecture-to-binutils.patch

this patch technically required to support one of OEs available tune values. namely armv5e, we should be able to drop it.

$ grep conf/machine meta/conf/machine/qemuarm.conf
require conf/machine/include/qemu.inc
require conf/machine/include/tune-arm926ejs.inc
#require conf/machine/include/tune-arm1136jf-s.inc
$ MACHINE=qemuarm bitbake virtual/kernel -e|grep -E '^DEFAULTTUNE=|^ARMPKGSFX_THUMB=|^TUNE_PKGARCH=|^TUNE_CCARGS='
ARMPKGSFX_THUMB=""
DEFAULTTUNE="armv5te"
TUNE_CCARGS=" -march=armv5e -marm"
TUNE_PKGARCH="armv5e"

I have already tried binutils w/o that patch for arm926ejs/armv5te machine and it fails, because as you can see above, -march=armv5e is being passed...

Signature · 1 line
Denys
#3 lore raw
Quoted 41 lines · Denys Dmytriyenko
Quoted 14 lines · Khem Raj
Quoted 6 lines · Denys Dmytriyenko

https://www.phoronix.com/scan.php?page=news_item&px=GCC-9-Dropping-Older-ARM

Particularly, ARMv5 and ARMv5E are being dropped (but T and TE variants remain)

Are there any concerns from OE community perspective?

From yocto project perspctive qemuarm which is emulating arm926ejs with default tune armv5te is used.
so we are right at the trailing edge and wont be affected. However, I know there were OE users who had
devices using other armv5 or v4 variants

Quoted 3 lines

I have been suggesting to switch qemuarm to use armv7 based board emulator for few years now.
may be this is the time to make that call for next YP release.

Valid point about qemuarm, but see below.

Quoted 6 lines
Quoted 3 lines

At least for binutils we needed this patch even for armv5te:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/binutils/binutils/0007-Add-the-armv5e-architecture-to-binutils.patch

this patch technically required to support one of OEs available tune values. namely armv5e, we should be able to drop it.

$ grep conf/machine meta/conf/machine/qemuarm.conf
require conf/machine/include/qemu.inc
require conf/machine/include/tune-arm926ejs.inc
#require conf/machine/include/tune-arm1136jf-s.inc
$ MACHINE=qemuarm bitbake virtual/kernel -e|grep -E '^DEFAULTTUNE=|^ARMPKGSFX_THUMB=|^TUNE_PKGARCH=|^TUNE_CCARGS='
ARMPKGSFX_THUMB=""
DEFAULTTUNE="armv5te"
TUNE_CCARGS=" -march=armv5e -marm"
TUNE_PKGARCH="armv5e"
Quoted 3 lines

I have already tried binutils w/o that patch for arm926ejs/armv5te machine and it fails, because as you can see above, -march=armv5e is being passed...

What happens if you drop setting TUNE_CCARGS and TUNE_PKGARCH ?

Quoted 2 lines

--
Denys

author
#4 lore raw
Quoted 42 lines · Khem Raj
Quoted 41 lines · Denys Dmytriyenko
Quoted 14 lines · Khem Raj
Quoted 6 lines · Denys Dmytriyenko

https://www.phoronix.com/scan.php?page=news_item&px=GCC-9-Dropping-Older-ARM

Particularly, ARMv5 and ARMv5E are being dropped (but T and TE variants remain)

Are there any concerns from OE community perspective?

From yocto project perspctive qemuarm which is emulating arm926ejs with default tune armv5te is used.
so we are right at the trailing edge and wont be affected. However, I know there were OE users who had
devices using other armv5 or v4 variants

Quoted 3 lines

I have been suggesting to switch qemuarm to use armv7 based board emulator for few years now.
may be this is the time to make that call for next YP release.

Valid point about qemuarm, but see below.

Quoted 6 lines
Quoted 3 lines

At least for binutils we needed this patch even for armv5te:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/binutils/binutils/0007-Add-the-armv5e-architecture-to-binutils.patch

this patch technically required to support one of OEs available tune values. namely armv5e, we should be able to drop it.

$ grep conf/machine meta/conf/machine/qemuarm.conf
require conf/machine/include/qemu.inc
require conf/machine/include/tune-arm926ejs.inc
#require conf/machine/include/tune-arm1136jf-s.inc
$ MACHINE=qemuarm bitbake virtual/kernel -e|grep -E '^DEFAULTTUNE=|^ARMPKGSFX_THUMB=|^TUNE_PKGARCH=|^TUNE_CCARGS='
ARMPKGSFX_THUMB=""
DEFAULTTUNE="armv5te"
TUNE_CCARGS=" -march=armv5e -marm"
TUNE_PKGARCH="armv5e"
Quoted 4 lines
Quoted 2 lines

I have already tried binutils w/o that patch for arm926ejs/armv5te machine and it fails, because as you can see above, -march=armv5e is being passed...

What happens if you drop setting TUNE_CCARGS and TUNE_PKGARCH ?

From OE-Core?

http://cgit.openembedded.org/openembedded-core/tree/meta/conf/machine/include/arm/arch-armv5.inc#n5
http://cgit.openembedded.org/openembedded-core/tree/meta/conf/machine/include/arm/arch-arm.inc#n11

From the README:
A small set of ARM specific variables have been defined to allow TUNE_PKGARCH to be automatically defined. Optimized tunings must NOT change the definiton of TUNE_PKGARCH. TUNE_PKGACH_tune-<tune> will be ignored. The format of the package arch is enforced by the TUNE_PKGARCH default. The format must be of the form:
<armversion>[t][e][hf][b][-vfp][-neon]

#5 lore raw
Quoted 47 lines · Denys Dmytriyenko
Quoted 38 lines · Khem Raj
Quoted 37 lines · Denys Dmytriyenko
Quoted 13 lines · Khem Raj
Quoted 6 lines · Denys Dmytriyenko

https://www.phoronix.com/scan.php?page=news_item&px=GCC-9-Dropping-Older-ARM

Particularly, ARMv5 and ARMv5E are being dropped (but T and TE variants remain)

Are there any concerns from OE community perspective?

From yocto project perspctive qemuarm which is emulating arm926ejs with default tune armv5te is used.
so we are right at the trailing edge and wont be affected. However, I know there were OE users who had
devices using other armv5 or v4 variants

Quoted 3 lines

I have been suggesting to switch qemuarm to use armv7 based board emulator for few years now.
may be this is the time to make that call for next YP release.

Valid point about qemuarm, but see below.

Quoted 5 lines
Quoted 3 lines

At least for binutils we needed this patch even for armv5te:
http://cgit.openembedded.org/openembedded-core/tree/meta/recipes-devtools/binutils/binutils/0007-Add-the-armv5e-architecture-to-binutils.patch

this patch technically required to support one of OEs available tune values. namely armv5e, we should be able to drop it.

$ grep conf/machine meta/conf/machine/qemuarm.conf
require conf/machine/include/qemu.inc
require conf/machine/include/tune-arm926ejs.inc
#require conf/machine/include/tune-arm1136jf-s.inc
$ MACHINE=qemuarm bitbake virtual/kernel -e|grep -E '^DEFAULTTUNE=|^ARMPKGSFX_THUMB=|^TUNE_PKGARCH=|^TUNE_CCARGS='
ARMPKGSFX_THUMB=""
DEFAULTTUNE="armv5te"
TUNE_CCARGS=" -march=armv5e -marm"
TUNE_PKGARCH="armv5e"
Quoted 3 lines
Quoted 2 lines

I have already tried binutils w/o that patch for arm926ejs/armv5te machine and it fails, because as you can see above, -march=armv5e is being passed...

What happens if you drop setting TUNE_CCARGS and TUNE_PKGARCH ?

From OE-Core?

http://cgit.openembedded.org/openembedded-core/tree/meta/conf/machine/include/arm/arch-armv5.inc#n5
http://cgit.openembedded.org/openembedded-core/tree/meta/conf/machine/include/arm/arch-arm.inc#n11

Quoted 7 lines

From the README:
A small set of ARM specific variables have been defined to allow TUNE_PKGARCH to be automatically defined. Optimized tunings must NOT change the definiton of TUNE_PKGARCH. TUNE_PKGACH_tune-<tune> will be ignored. The format of the package arch is enforced by the TUNE_PKGARCH default. The format must be of the form:
<armversion>[t][e][hf][b][-vfp][-neon]

Maybe a bug is in order and then we might be able to add it to the 2.6 planning?

Maybe a QEMU strategy for OE going forward may also be a topic.

- armin

#6 lore raw
Quoted 2 lines · On 05/20/2018 10:59 AM, akuster808 wrote:

Maybe a bug is in order and then we might be able to add it to the 2.6 planning?

Not my bug to file... anyone?

Quoted 2 lines

Maybe a QEMU strategy for OE going forward may also be a topic.

There is meta-qemuarma9:
https://github.com/OverC/meta-qemuarma9.git
I'm not an arm man but would it make sense for oe-core to drop qemuarm and use qemuarma9?

Signature · 2 lines
# Randy MacLeod
# Wind River Linux
#7 lore raw
Quoted 9 lines · Randy MacLeod
Quoted 3 lines · On 05/20/2018 10:59 AM, akuster808 wrote:

Maybe a bug is in order and then we might be able to add it to the 2.6 planning?

There is meta-qemuarma9:
https://github.com/OverC/meta-qemuarma9.git
I'm not an arm man but would it make sense for oe-core to drop qemuarm and use qemuarma9?

Presumably that name was chosen just to avoid a clash with the qemuarm machine name used in oe-core?

If/when we update the CPU used in the oe-core qemu ARM machine, I vote we continue to just call it "qemuarm".

#8 lore raw

Add Bruce.

Quoted 2 lines · Andre McCurdy

Presumably that name was chosen just to avoid a clash with the qemuarm machine name used in oe-core?

That seems likely.

Here's an early commit lo from the repo made by Bruce that shows the output of /proc/cpuinfo:

commit 3f23b7954861bc55f8c10ebbe9934fbd052d2a6d

Author: Bruce Ashfield <[email protected]>
Date:   Thu May 17 14:24:28 2012 -0400

wr-bsps: add qemuarma9

This is the out-of-tree port of the CoreTile Express A9x4 platform, running under qemu.

root@qemuarma9:~# cat /proc/cpuinfo
Processor : ARMv7 Processor rev 0 (v7l)
processor : 0
BogoMIPS : 498.89

Features : swp half thumb fastmult vfp edsp neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xc09
CPU revision : 0

Hardware : ARM-Versatile Express
Revision : 0000
Serial : 0000000000000000

Signed-off-by Bruce Ashfield <[email protected]>

Again, I'm not an arm man so maybe this is old hat to toolchain and BSP people. I'm just trying to suggest a tested short-cut.

Quoted 3 lines

If/when we update the CPU used in the oe-core qemu ARM machine, I vote we continue to just call it "qemuarm".

That would surprise me as a user of qemuarm so my vote is to change the name unless there's precedent to support your vote.

Signature · 2 lines
# Randy MacLeod
# Wind River Linux
#9 lore raw
Quoted 7 lines · Randy MacLeod
Quoted 3 lines · Andre McCurdy

If/when we update the CPU used in the oe-core qemu ARM machine, I vote we continue to just call it "qemuarm".

That would surprise me as a user of qemuarm so my vote is to change the name unless there's precedent to support your vote.

I think we've updated the CPU used by qemux86 a few times (and with kvm doesn't it even change depending on the host?).

#10 lore raw
Quoted 4 lines · Andre McCurdy
Quoted 2 lines · Randy MacLeod
Quoted 1 line · Andre McCurdy
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

If/when we update the CPU used in the oe-core qemu ARM machine, I vote we continue to just call it "qemuarm".

That would surprise me as a user of qemuarm so my vote is to change the name unless there's precedent to support your vote.

I think we've updated the CPU used by qemux86 a few times (and with kvm doesn't it even change depending on the host?).

Correct. There's no requirement to update the board emulation just to tweak the cpu ISA.

The qemuarma9 board has some gaps with respect to the old versatile926ejs. So unless the cpu update doesn't work, I'm all for leaving the board the same but just changing the cpu.

Bruce

Quoted 1 line