On Thu, Nov 7, 2019 at 10:42 AM Steve Pavao <ste...@korgrd.com> wrote:
> > On Nov 4, 2019, at 4:26 PM, Steve Pavao <ste...@korgrd.com> wrote: > > > >> On Nov 4, 2019, at 11:32 AM, Steve Pavao <ste...@korgrd.com> wrote: > >>> > >>> On Nov 4, 2019, at 11:16 AM, Steve Pavao <ste...@korgrd.com> wrote: > >>>> > >>>> On Nov 4, 2019, at 11:11 AM, Adrian Bunk <b...@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 <b...@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.k...@gmail.com> > wrote: > >>>>>>>> On Sun, Nov 3, 2019 at 2:46 AM Andrei Gherzan <and...@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 > > > > >
-- _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto