[meta-raspberrypi] poky linux build fails if ARM erratum mfix linker switch is specified


Steve Pavao
 

poky linux build fails when ARM erratum mfix linker switch is specified in local.conf:

TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”

causes build failure.

Please advise how to use this switch successfully.  I am synced current in master branch in all layers as of today.  The switch causes libtool link to fail due to missing libbz2.so.  If I don’t specify the switch, the build completes without errors.

It is important to be able to build poky linux with this switch to avoid certain crash conditions as described in the ARM errata document.

Steve Pavao
Korg R&D


Andrei Gherzan
 

Hi Steve,

On 01/11/2019 05:32, Steve Pavao wrote:
poky linux build fails when ARM erratum mfix linker switch is specified in local.conf:
TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”
causes build failure.
Please advise how to use this switch successfully.  I am synced current in master branch in all layers as of today.  The switch causes libtool link to fail due to missing libbz2.so.  If I don’t specify the switch, the build completes without errors.
It is important to be able to build poky linux with this switch to avoid certain crash conditions as described in the ARM errata document.
I haven't tried this erratum fix. It is indeed implemented at the linker's lever. It's curious though to see the bz2 dependency. Can you share the specific error? I assume you are doing this on RPi3.

--
Andrei Gherzan


Khem Raj
 

On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan <andrei@...> wrote:

Hi Steve,

On 01/11/2019 05:32, Steve Pavao wrote:
poky linux build fails when ARM erratum mfix linker switch is specified
in local.conf:

TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”

causes build failure.

Please advise how to use this switch successfully. I am synced current
in master branch in all layers as of today. The switch causes libtool
link to fail due to missing libbz2.so. If I don’t specify the switch,
the build completes without errors.

It is important to be able to build poky linux with this switch to avoid
certain crash conditions as described in the ARM errata document.
I haven't tried this erratum fix. It is indeed implemented at the
linker's lever. It's curious though to see the bz2 dependency. Can you
share the specific error? I assume you are doing this on RPi3.
this will impact rpi3 in 64bit mode, don't think 32bit needs this. I
think its best to
add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS

--
Andrei Gherzan
--
_______________________________________________
yocto mailing list
yocto@...
https://lists.yoctoproject.org/listinfo/yocto


Andrei Gherzan
 

On 01/11/2019 17:18, Khem Raj wrote:
On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan <andrei@...> wrote:

Hi Steve,

On 01/11/2019 05:32, Steve Pavao wrote:
poky linux build fails when ARM erratum mfix linker switch is specified
in local.conf:

TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”

causes build failure.

Please advise how to use this switch successfully. I am synced current
in master branch in all layers as of today. The switch causes libtool
link to fail due to missing libbz2.so. If I don’t specify the switch,
the build completes without errors.

It is important to be able to build poky linux with this switch to avoid
certain crash conditions as described in the ARM errata document.
I haven't tried this erratum fix. It is indeed implemented at the
linker's lever. It's curious though to see the bz2 dependency. Can you
share the specific error? I assume you are doing this on RPi3.
this will impact rpi3 in 64bit mode, don't think 32bit needs this. I
think its best to
add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS
I was thinking about this. The erratum seems to show that this applies to all revisions of a53. So it sounds like we should add it in `tune-cortexa53.inc`.

--
Andrei Gherzan


Khem Raj
 



On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...> wrote:
On 01/11/2019 17:18, Khem Raj wrote:
> On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan <andrei@...> wrote:
>>
>> Hi Steve,
>>
>> On 01/11/2019 05:32, Steve Pavao wrote:
>>> poky linux build fails when ARM erratum mfix linker switch is specified
>>> in local.conf:
>>>
>>> TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”
>>>
>>> causes build failure.
>>>
>>> Please advise how to use this switch successfully.  I am synced current
>>> in master branch in all layers as of today.  The switch causes libtool
>>> link to fail due to missing libbz2.so.  If I don’t specify the switch,
>>> the build completes without errors.
>>>
>>> It is important to be able to build poky linux with this switch to avoid
>>> certain crash conditions as described in the ARM errata document.
>>
>> I haven't tried this erratum fix. It is indeed implemented at the
>> linker's lever. It's curious though to see the bz2 dependency. Can you
>> share the specific error? I assume you are doing this on RPi3.
>>
>
> this will impact rpi3 in 64bit mode, don't think 32bit needs this. I
> think its best to
> add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS

I was thinking about this. The erratum seems to show that this applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.

Up to r0b4 only so maybe not all a53 implementations are impacted 

--
Andrei Gherzan


Andrei Gherzan
 

On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:

On 01/11/2019 17:18, Khem Raj wrote:
On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan <andrei@...>
wrote:

Hi Steve,

On 01/11/2019 05:32, Steve Pavao wrote:
poky linux build fails when ARM erratum mfix linker switch is
specified
in local.conf:

TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”

causes build failure.

Please advise how to use this switch successfully. I am synced
current
in master branch in all layers as of today. The switch causes
libtool
link to fail due to missing libbz2.so. If I don’t specify the
switch,
the build completes without errors.

It is important to be able to build poky linux with this switch
to
avoid
certain crash conditions as described in the ARM errata document.
I haven't tried this erratum fix. It is indeed implemented at the
linker's lever. It's curious though to see the bz2 dependency. Can
you
share the specific error? I assume you are doing this on RPi3.
this will impact rpi3 in 64bit mode, don't think 32bit needs this.
I
think its best to
add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan


Khem Raj
 



On Sun, Nov 3, 2019 at 9:56 AM Andrei Gherzan <andrei@...> wrote:


On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
>On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
>wrote:
>
>> On 01/11/2019 17:18, Khem Raj wrote:
>> > On Fri, Nov 1, 2019 at 1:28 AM Andrei Gherzan <andrei@...>
>wrote:
>> >>
>> >> Hi Steve,
>> >>
>> >> On 01/11/2019 05:32, Steve Pavao wrote:
>> >>> poky linux build fails when ARM erratum mfix linker switch is
>specified
>> >>> in local.conf:
>> >>>
>> >>> TARGET_LD_ARCH_append += " -mfix-cortex-a53-843419”
>> >>>
>> >>> causes build failure.
>> >>>
>> >>> Please advise how to use this switch successfully.  I am synced
>current
>> >>> in master branch in all layers as of today.  The switch causes
>libtool
>> >>> link to fail due to missing libbz2.so.  If I don’t specify the
>switch,
>> >>> the build completes without errors.
>> >>>
>> >>> It is important to be able to build poky linux with this switch
>to
>> avoid
>> >>> certain crash conditions as described in the ARM errata document.
>> >>
>> >> I haven't tried this erratum fix. It is indeed implemented at the
>> >> linker's lever. It's curious though to see the bz2 dependency. Can
>you
>> >> share the specific error? I assume you are doing this on RPi3.
>> >>
>> >
>> > this will impact rpi3 in 64bit mode, don't think 32bit needs this.
>I
>> > think its best to
>> > add this option in raspberrypi3-64.conf perhaps via TUNE_CCARGS
>>
>> I was thinking about this. The erratum seems to show that this
>applies
>> to all revisions of a53. So it sounds like we should add it in
>> `tune-cortexa53.inc`.
>>
>
>Up to r0b4 only so maybe not all a53 implementations are impacted
>

As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?

Rpi3 is one of many cortex a53 implementations 

--
Andrei Gherzan
gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan


Adrian Bunk
 

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
It is fixed in some r0p4 implementations, indicated in REVIDR[8].

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed


Steve Pavao
 

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
It is fixed in some r0p4 implementations, indicated in REVIDR[8].
I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK. As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \


I will post again when I have localized the build problem further. Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.

- Steve Pavao
Korg R&D


Adrian Bunk
 

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
It is fixed in some r0p4 implementations, indicated in REVIDR[8].
I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK. As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \


I will post again when I have localized the build problem further. Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.
The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.

- Steve Pavao
Korg R&D
cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed


Steve Pavao
 


On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.


Up to r0b4 only so maybe not all a53 implementations are impacted


As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed? 

It is fixed in some r0p4 implementations, indicated in REVIDR[8].

I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK.  As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \


I will post again when I have localized the build problem further.  Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.

The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.

To conitnue to be able to use the 32-bit app support, perhaps I must do this:

DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”

I’ll give it a try.

- Steve Pavao
Korg R&D



Steve Pavao
 


On Nov 4, 2019, at 11:16 AM, Steve Pavao <stevep@...> wrote:


On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.


Up to r0b4 only so maybe not all a53 implementations are impacted


As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed? 

It is fixed in some r0p4 implementations, indicated in REVIDR[8].

I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK.  As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \


I will post again when I have localized the build problem further.  Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.

The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.

To conitnue to be able to use the 32-bit app support, perhaps I must do this:

DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”

This doesn’t work.

If I wish to keep the 32-bit app support in my build, I’ll need to devise a way to make sure those ARM errata flags are only applied to the aarch64 portion of the compile/link for the target, not to the multilib 32-bit app support portion.

Thanks to all of you for your thoughts so far.

Steve Pavao
Korg R&D


Steve Pavao
 



On Nov 4, 2019, at 11:32 AM, Steve Pavao <stevep@...> wrote:


On Nov 4, 2019, at 11:16 AM, Steve Pavao <stevep@...> wrote:


On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.


Up to r0b4 only so maybe not all a53 implementations are impacted


As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed? 

It is fixed in some r0p4 implementations, indicated in REVIDR[8].

I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK.  As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \


I will post again when I have localized the build problem further.  Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.

The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.

To conitnue to be able to use the 32-bit app support, perhaps I must do this:

DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”

This doesn’t work.

If I wish to keep the 32-bit app support in my build, I’ll need to devise a way to make sure those ARM errata flags are only applied to the aarch64 portion of the compile/link for the target, not to the multilib 32-bit app support portion.

Andrei and/or Khem,

Could you advise an approach that allows to use the ARM errata switches for the aarch64 portion of the build for the target, but which will NOT specify the ARM errata switches for our supplementary 32-bit portion of the build for the target?  (This supplementary 32-bit portion of the build is to support the 32-bit vcgencmd app, and contains multilib and some additional 32-bit libraires.  Please see earlier post for the syntax we use in our local.conf.)

Steve Pavao
Korg R&D



Steve Pavao
 

On Nov 4, 2019, at 4:26 PM, Steve Pavao <stevep@...> wrote:

On Nov 4, 2019, at 11:32 AM, Steve Pavao <stevep@...> wrote:

On Nov 4, 2019, at 11:16 AM, Steve Pavao <stevep@...> wrote:

On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
It is fixed in some r0p4 implementations, indicated in REVIDR[8].
I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK. As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \


I will post again when I have localized the build problem further. Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.
The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.
To conitnue to be able to use the 32-bit app support, perhaps I must do this:

DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”
This doesn’t work.

If I wish to keep the 32-bit app support in my build, I’ll need to devise a way to make sure those ARM errata flags are only applied to the aarch64 portion of the compile/link for the target, not to the multilib 32-bit app support portion.
Andrei and/or Khem,

Could you advise an approach that allows to use the ARM errata switches for the aarch64 portion of the build for the target, but which will NOT specify the ARM errata switches for our supplementary 32-bit portion of the build for the target? (This supplementary 32-bit portion of the build is to support the 32-bit vcgencmd app, and contains multilib and some additional 32-bit libraires. Please see earlier post for the syntax we use in our local.conf.)

I've been able to rebuild 64-bit Linux code with the ARM errata switches, by adding the following line to the end of /meta/conf/machine/include/arm/arch-arm64.inc,

TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "aarch64", " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769", "" ,d)}”

Please let me know if you have any thoughts about this approach.

Steve Pavao
Korg R&D


Khem Raj
 



On Thu, Nov 7, 2019 at 10:42 AM Steve Pavao <stevep@...> wrote:
> On Nov 4, 2019, at 4:26 PM, Steve Pavao <stevep@...> wrote:
>
>> On Nov 4, 2019, at 11:32 AM, Steve Pavao <stevep@...> wrote:
>>>
>>> On Nov 4, 2019, at 11:16 AM, Steve Pavao <stevep@...> wrote:
>>>>
>>>> On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:
>>>>
>>>> On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:
>>>>>
>>>>>> On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:
>>>>>>
>>>>>> On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
>>>>>>> On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
>>>>>>>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
>>>>>>>> wrote:
>>>>>>>>> I was thinking about this. The erratum seems to show that this
>>>>>>>> applies
>>>>>>>>> to all revisions of a53. So it sounds like we should add it in
>>>>>>>>> `tune-cortexa53.inc`.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Up to r0b4 only so maybe not all a53 implementations are impacted
>>>>>>>>
>>>>>>>
>>>>>>> As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
>>>>>>
>>>>>> It is fixed in some r0p4 implementations, indicated in REVIDR[8].
>>>>>
>>>>> I am closer to understanding why I experience an error when building with the ARM errata switches.
>>>>>
>>>>> I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)
>>>>>
>>>>> When I remove the 32-bit support, the build completes OK.  As of now, adding the following seems to work fine to acheive this:
>>>>>
>>>>> TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”
>>>>>
>>>>> Something in the following block seems to be the culprit.:
>>>>>
>>>>> # for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
>>>>> require conf/multilib.conf
>>>>> MULTILIBS = "multilib:lib32"
>>>>> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
>>>>> IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \
>>>>> “
>>>>>
>>>>> I will post again when I have localized the build problem further.  Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.
>>>>
>>>> The errata switches are only valid for aarch64, not for armv7a.
>>>> There is likely some kind of "invalid option" earlier in your build.
>>>
>>> To conitnue to be able to use the 32-bit app support, perhaps I must do this:
>>>
>>> DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”
>>
>> This doesn’t work.
>>
>> If I wish to keep the 32-bit app support in my build, I’ll need to devise a way to make sure those ARM errata flags are only applied to the aarch64 portion of the compile/link for the target, not to the multilib 32-bit app support portion.
>
> Andrei and/or Khem,
>
> Could you advise an approach that allows to use the ARM errata switches for the aarch64 portion of the build for the target, but which will NOT specify the ARM errata switches for our supplementary 32-bit portion of the build for the target?  (This supplementary 32-bit portion of the build is to support the 32-bit vcgencmd app, and contains multilib and some additional 32-bit libraires.  Please see earlier post for the syntax we use in our local.conf.)


I've been able to rebuild 64-bit Linux code with the ARM errata switches, by adding the following line to the end of /meta/conf/machine/include/arm/arch-arm64.inc,

TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "aarch64", " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769", "" ,d)}”

This should be in tune-cortexa53.inc 


Please let me know if you have any thoughts about this approach.

Steve Pavao
Korg R&D





Steve Pavao
 



On Thu, Nov 7, 2019 at 2:03 PM Khem Raj <raj.khem@...> wrote:


On Thu, Nov 7, 2019 at 10:42 AM Steve Pavao <stevep@...> wrote:
> On Nov 4, 2019, at 4:26 PM, Steve Pavao <stevep@...> wrote:
>
>> On Nov 4, 2019, at 11:32 AM, Steve Pavao <stevep@...> wrote:
>>>
>>> On Nov 4, 2019, at 11:16 AM, Steve Pavao <stevep@...> wrote:
>>>>
>>>> On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:
>>>>
>>>> On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:
>>>>>
>>>>>> On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:
>>>>>>
>>>>>> On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
>>>>>>> On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
>>>>>>>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
>>>>>>>> wrote:
>>>>>>>>> I was thinking about this. The erratum seems to show that this
>>>>>>>> applies
>>>>>>>>> to all revisions of a53. So it sounds like we should add it in
>>>>>>>>> `tune-cortexa53.inc`.
>>>>>>>>>
>>>>>>>>
>>>>>>>> Up to r0b4 only so maybe not all a53 implementations are impacted
>>>>>>>>
>>>>>>>
>>>>>>> As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
>>>>>>
>>>>>> It is fixed in some r0p4 implementations, indicated in REVIDR[8].
>>>>>
>>>>> I am closer to understanding why I experience an error when building with the ARM errata switches.
>>>>>
>>>>> I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)
>>>>>
>>>>> When I remove the 32-bit support, the build completes OK.  As of now, adding the following seems to work fine to acheive this:
>>>>>
>>>>> TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”
>>>>>
>>>>> Something in the following block seems to be the culprit.:
>>>>>
>>>>> # for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
>>>>> require conf/multilib.conf
>>>>> MULTILIBS = "multilib:lib32"
>>>>> DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
>>>>> IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \
>>>>> “
>>>>>
>>>>> I will post again when I have localized the build problem further.  Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.
>>>>
>>>> The errata switches are only valid for aarch64, not for armv7a.
>>>> There is likely some kind of "invalid option" earlier in your build.
>>>
>>> To conitnue to be able to use the 32-bit app support, perhaps I must do this:
>>>
>>> DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”
>>
>> This doesn’t work.
>>
>> If I wish to keep the 32-bit app support in my build, I’ll need to devise a way to make sure those ARM errata flags are only applied to the aarch64 portion of the compile/link for the target, not to the multilib 32-bit app support portion.
>
> Andrei and/or Khem,
>
> Could you advise an approach that allows to use the ARM errata switches for the aarch64 portion of the build for the target, but which will NOT specify the ARM errata switches for our supplementary 32-bit portion of the build for the target?  (This supplementary 32-bit portion of the build is to support the 32-bit vcgencmd app, and contains multilib and some additional 32-bit libraires.  Please see earlier post for the syntax we use in our local.conf.)


I've been able to rebuild 64-bit Linux code with the ARM errata switches, by adding the following line to the end of /meta/conf/machine/include/arm/arch-arm64.inc,

TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "aarch64", " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769", "" ,d)}”

This should be in tune-cortexa53.inc 

I took care of this locally on my system in that file for now.

That said, in your opinion, what is the best way to have this change be applied permanently to that file in the meta layer?  Should I be the one to try to make the change and generate a pull request, or is it best if someone who is already regularly involved in meta layer maintenance and testing gives it a closer look and does it the way they think is best?

Steve Pavao
Korg R&D


Khem Raj
 

On Tue, Dec 3, 2019 at 3:54 PM Steve Pavao <stevep@...> wrote:



On Thu, Nov 7, 2019 at 2:03 PM Khem Raj <raj.khem@...> wrote:



On Thu, Nov 7, 2019 at 10:42 AM Steve Pavao <stevep@...> wrote:

On Nov 4, 2019, at 4:26 PM, Steve Pavao <stevep@...> wrote:

On Nov 4, 2019, at 11:32 AM, Steve Pavao <stevep@...> wrote:

On Nov 4, 2019, at 11:16 AM, Steve Pavao <stevep@...> wrote:

On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk@...> wrote:

On Mon, Nov 04, 2019 at 10:48:57AM -0500, Steve Pavao wrote:

On Nov 3, 2019, at 1:25 PM, Adrian Bunk <bunk@...> wrote:

On Sun, Nov 03, 2019 at 05:56:45PM +0000, Andrei Gherzan wrote:
On 3 November 2019 13:18:53 GMT, Khem Raj <raj.khem@...> wrote:
On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei@...>
wrote:
I was thinking about this. The erratum seems to show that this
applies
to all revisions of a53. So it sounds like we should add it in
`tune-cortexa53.inc`.
Up to r0b4 only so maybe not all a53 implementations are impacted
As far as I know that is the latest revision. Do you mean that newer revision might come up with this fixed?
It is fixed in some r0p4 implementations, indicated in REVIDR[8].
I am closer to understanding why I experience an error when building with the ARM errata switches.

I believe it is related to 32-bit app support in my poky Linux 64-bit build (I add this to support vcgencmd and vcdbg 32-bit apps.)

When I remove the 32-bit support, the build completes OK. As of now, adding the following seems to work fine to acheive this:

TARGET_CC_ARCH_append += " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769”

Something in the following block seems to be the culprit.:

# for vcgencmd and vcdbg 32-bit executable support in the OS image (comment out for -c populate_sdk)
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a"
IMAGE_INSTALL_append += " vcgencmd lib32-glibc lib32-libgcc lib32-libstdc++ vcdbg rpi-setup \


I will post again when I have localized the build problem further. Maybe there’s some 64-bit vs. 32-bit build confusion going on, and the armv7a default tune switch for 32-bits is colliding with the errata switches.
The errata switches are only valid for aarch64, not for armv7a.
There is likely some kind of "invalid option" earlier in your build.
To conitnue to be able to use the 32-bit app support, perhaps I must do this:

DEFAULTTUNE_virtclass-multilib-lib32 = “armv7a -mno-fix-cortex-a53-843419 -mno-fix-cortex-a53-835769”
This doesn’t work.

If I wish to keep the 32-bit app support in my build, I’ll need to devise a way to make sure those ARM errata flags are only applied to the aarch64 portion of the compile/link for the target, not to the multilib 32-bit app support portion.
Andrei and/or Khem,

Could you advise an approach that allows to use the ARM errata switches for the aarch64 portion of the build for the target, but which will NOT specify the ARM errata switches for our supplementary 32-bit portion of the build for the target? (This supplementary 32-bit portion of the build is to support the 32-bit vcgencmd app, and contains multilib and some additional 32-bit libraires. Please see earlier post for the syntax we use in our local.conf.)

I've been able to rebuild 64-bit Linux code with the ARM errata switches, by adding the following line to the end of /meta/conf/machine/include/arm/arch-arm64.inc,

TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "aarch64", " -mfix-cortex-a53-843419 -mfix-cortex-a53-835769", "" ,d)}”

This should be in tune-cortexa53.inc

I took care of this locally on my system in that file for now.

That said, in your opinion, what is the best way to have this change be applied permanently to that file in the meta layer? Should I be the one to try to make the change and generate a pull request, or is it best if someone who is already regularly involved in meta layer maintenance and testing gives it a closer look and does it the way they think is best?
I would expect a patch from you since you are in thick of it and have
tested the solution, So please go ahead and create a pull request on
github. We can review and iterate of patch then


Steve Pavao
Korg R&D