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

[Khem Raj]

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

> > On Nov 4, 2019, at 4:26 PM, Steve Pavao <stevep at korgrd.com> wrote:
> >
> >> On Nov 4, 2019, at 11:32 AM, Steve Pavao <stevep at korgrd.com> wrote:
> >>>
> >>> On Nov 4, 2019, at 11:16 AM, Steve Pavao <stevep at korgrd.com> wrote:
> >>>>
> >>>> On Nov 4, 2019, at 11:11 AM, Adrian Bunk <bunk at stusta.de> 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 at stusta.de> 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 at gmail.com>
> wrote:
> >>>>>>>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <andrei at gherzan.ro>
> >>>>>>>> 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20191107/78ded493/attachment.html>