Can't build product that uses DEFAULTTUNE="arm926ejs"

Can't build product that uses DEFAULTTUNE="arm926ejs"

[Peter Kjellerstedt]

I'm trying to build with master of OE-core and one of our products now 
fails with:

ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
    Either fix the cause of this error or at your own risk disable the checker 
    (see sanity.conf). Following is the list of potential problems / advisories:

    Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t armv5 
    armv5t armv5e armv5te arm926ejste arm926ejse <BSP name withheld>) for 
    DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH (arm926ejst).

I believe this is due to commit ac83d22e (arm-tunes: Remove -march option if 
mcpu is already added). If I build with Thud, TUNE_PKGARCH is "arm926ejste".
The  lack of the "e" at the end when building with master seems to be due to 
the definition of ARMPKGSFX_DSP as 
"${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e', '', d)}" and 
the fact that after commit ac83d22e, TUNE_FEATURES no longer contains 'armv5'.

//Peter

Re: Can't build product that uses DEFAULTTUNE="arm926ejs"

[Khem Raj]

On Sun, Mar 10, 2019 at 9:20 PM Peter Kjellerstedt
<peter.kjellerstedt@axis.com> wrote:
>
> I'm trying to build with master of OE-core and one of our products now
> fails with:
>
> ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
>     Either fix the cause of this error or at your own risk disable the checker
>     (see sanity.conf). Following is the list of potential problems / advisories:
>
>     Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t armv5
>     armv5t armv5e armv5te arm926ejste arm926ejse <BSP name withheld>) for
>     DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH (arm926ejst).
>
> I believe this is due to commit ac83d22e (arm-tunes: Remove -march option if
> mcpu is already added). If I build with Thud, TUNE_PKGARCH is "arm926ejste".
> The  lack of the "e" at the end when building with master seems to be due to
> the definition of ARMPKGSFX_DSP as
> "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e', '', d)}" and
> the fact that after commit ac83d22e, TUNE_FEATURES no longer contains 'armv5'.
>
right this should now check for armv5t
armv5 has been removed from upstream gcc as well. So we only support
armv5t viariants.
> //Peter
>

Re: Can't build product that uses DEFAULTTUNE="arm926ejs"

[Peter Kjellerstedt]

> -----Original Message-----
> From: Khem Raj <raj.khem@gmail.com>
> Sent: den 11 mars 2019 05:24
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> Cc: OE Core (openembedded-core@lists.openembedded.org) <openembedded-
> core@lists.openembedded.org>
> Subject: Re: Can't build product that uses DEFAULTTUNE="arm926ejs"
> 
> On Sun, Mar 10, 2019 at 9:20 PM Peter Kjellerstedt
> <peter.kjellerstedt@axis.com> wrote:
> >
> > I'm trying to build with master of OE-core and one of our products
> > now fails with:
> >
> > ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
> >     Either fix the cause of this error or at your own risk disable the checker
> >     (see sanity.conf). Following is the list of potential problems / advisories:
> >
> >     Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t armv5
> >     armv5t armv5e armv5te arm926ejste arm926ejse <BSP name withheld>) for
> >     DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH (arm926ejst).
> >
> > I believe this is due to commit ac83d22e (arm-tunes: Remove -march
> > option if mcpu is already added). If I build with Thud, TUNE_PKGARCH 
> > is "arm926ejste". The  lack of the "e" at the end when building with 
> > master seems to be due to the definition of ARMPKGSFX_DSP as
> > "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e', '', d)}" 
> > and the fact that after commit ac83d22e, TUNE_FEATURES no longer 
> > contains 'armv5'.
> 
> right this should now check for armv5t

There is no armv5t to check for.

> armv5 has been removed from upstream gcc as well. So we only support
> armv5t variants.
> 
> > //Peter

I am by no means any expert on the tuning files (actually they mostly 
seem like black magic), but I devised an alternative solution for 
preferring -mcpu over -march that I think is less invasive and without 
unwanted side effects. I will publish it shortly.

//Peter

Re: Can't build product that uses DEFAULTTUNE="arm926ejs"

[Khem Raj]

On Mon, Mar 11, 2019 at 6:49 AM Peter Kjellerstedt
<peter.kjellerstedt@axis.com> wrote:
>
> > -----Original Message-----
> > From: Khem Raj <raj.khem@gmail.com>
> > Sent: den 11 mars 2019 05:24
> > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > Cc: OE Core (openembedded-core@lists.openembedded.org) <openembedded-
> > core@lists.openembedded.org>
> > Subject: Re: Can't build product that uses DEFAULTTUNE="arm926ejs"
> >
> > On Sun, Mar 10, 2019 at 9:20 PM Peter Kjellerstedt
> > <peter.kjellerstedt@axis.com> wrote:
> > >
> > > I'm trying to build with master of OE-core and one of our products
> > > now fails with:
> > >
> > > ERROR:  OE-core's config sanity checker detected a potential misconfiguration.
> > >     Either fix the cause of this error or at your own risk disable the checker
> > >     (see sanity.conf). Following is the list of potential problems / advisories:
> > >
> > >     Error, the PACKAGE_ARCHS variable (all any noarch arm armv4 armv4t armv5
> > >     armv5t armv5e armv5te arm926ejste arm926ejse <BSP name withheld>) for
> > >     DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH (arm926ejst).
> > >
> > > I believe this is due to commit ac83d22e (arm-tunes: Remove -march
> > > option if mcpu is already added). If I build with Thud, TUNE_PKGARCH
> > > is "arm926ejste". The  lack of the "e" at the end when building with
> > > master seems to be due to the definition of ARMPKGSFX_DSP as
> > > "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e', '', d)}"
> > > and the fact that after commit ac83d22e, TUNE_FEATURES no longer
> > > contains 'armv5'.
> >
> > right this should now check for armv5t
>
> There is no armv5t to check for.
>
> > armv5 has been removed from upstream gcc as well. So we only support
> > armv5t variants.
> >
> > > //Peter
>
> I am by no means any expert on the tuning files (actually they mostly
> seem like black magic), but I devised an alternative solution for
> preferring -mcpu over -march that I think is less invasive and without
> unwanted side effects. I will publish it shortly.

I saw you sent couple of patch to address this, however I think it can
be addressed a bit differently and patch could
be simple. I would be keen if you try it out and see if that fixes your problem

https://patchwork.openembedded.org/patch/159591/

>
> //Peter
>

Re: Can't build product that uses DEFAULTTUNE="arm926ejs"

[Peter Kjellerstedt]

> -----Original Message-----
> From: Khem Raj <raj.khem@gmail.com>
> Sent: den 15 mars 2019 06:09
> To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> Cc: OE Core (openembedded-core@lists.openembedded.org) <openembedded-
> core@lists.openembedded.org>
> Subject: Re: Can't build product that uses DEFAULTTUNE="arm926ejs"
> 
> On Mon, Mar 11, 2019 at 6:49 AM Peter Kjellerstedt
> <peter.kjellerstedt@axis.com> wrote:
> >
> > > -----Original Message-----
> > > From: Khem Raj <raj.khem@gmail.com>
> > > Sent: den 11 mars 2019 05:24
> > > To: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
> > > Cc: OE Core (openembedded-core@lists.openembedded.org)
> <openembedded-
> > > core@lists.openembedded.org>
> > > Subject: Re: Can't build product that uses DEFAULTTUNE="arm926ejs"
> > >
> > > On Sun, Mar 10, 2019 at 9:20 PM Peter Kjellerstedt
> > > <peter.kjellerstedt@axis.com> wrote:
> > > >
> > > > I'm trying to build with master of OE-core and one of our
> products
> > > > now fails with:
> > > >
> > > > ERROR:  OE-core's config sanity checker detected a potential
> misconfiguration.
> > > >     Either fix the cause of this error or at your own risk
> disable the checker
> > > >     (see sanity.conf). Following is the list of potential
> problems / advisories:
> > > >
> > > >     Error, the PACKAGE_ARCHS variable (all any noarch arm armv4
> armv4t armv5
> > > >     armv5t armv5e armv5te arm926ejste arm926ejse <BSP name
> withheld>) for
> > > >     DEFAULTTUNE (arm926ejs) does not contain TUNE_PKGARCH
> (arm926ejst).
> > > >
> > > > I believe this is due to commit ac83d22e (arm-tunes: Remove -
> march
> > > > option if mcpu is already added). If I build with Thud,
> TUNE_PKGARCH
> > > > is "arm926ejste". The  lack of the "e" at the end when building
> with
> > > > master seems to be due to the definition of ARMPKGSFX_DSP as
> > > > "${@bb.utils.contains('TUNE_FEATURES', [ 'armv5', 'dsp' ], 'e',
> '', d)}"
> > > > and the fact that after commit ac83d22e, TUNE_FEATURES no longer
> > > > contains 'armv5'.
> > >
> > > right this should now check for armv5t
> >
> > There is no armv5t to check for.
> >
> > > armv5 has been removed from upstream gcc as well. So we only
> support
> > > armv5t variants.
> > >
> > > > //Peter
> >
> > I am by no means any expert on the tuning files (actually they mostly
> > seem like black magic), but I devised an alternative solution for
> > preferring -mcpu over -march that I think is less invasive and without
> > unwanted side effects. I will publish it shortly.
> 
> I saw you sent couple of patch to address this, however I think it can
> be addressed a bit differently and patch could be simple. I would be 
> keen if you try it out and see if that fixes your problem
> 
> https://patchwork.openembedded.org/patch/159591/
> 
> > //Peter

While I agree that your patch will solve the problem with arm926ejs, I 
believe there are advantages in applying my patches instead. In addition 
to fixing the problem with arm926ejs, my patches (patch set 4, not patch 
set 2 that is currently on master-next) also:

* make it so that there is no change to TUNE_FEATURES,
* make it explicit whether -mcpu or -march is used, and
* make the extra arguments added to -mcpu or -march for armv8 explicit.

That last point was something that confused me when I read the original 
tune files. I did not realize that those extra features were added to 
whatever -mcpu or -march happened to be added to TUNE_CCARGS before the 
arch-armv8a.inc file was included (especially as it was written to make 
it look as they were only added to the -march option).

//Peter

Re: Can't build product that uses DEFAULTTUNE="arm926ejs"

[Adrian Bunk]

On Sat, Mar 16, 2019 at 09:21:57AM +0000, Peter Kjellerstedt wrote:
> 
> While I agree that your patch will solve the problem with arm926ejs, I 
> believe there are advantages in applying my patches instead. In addition 
> to fixing the problem with arm926ejs, my patches (patch set 4, not patch 
> set 2 that is currently on master-next) also:
> 
> * make it so that there is no change to TUNE_FEATURES,
> * make it explicit whether -mcpu or -march is used, and
> * make the extra arguments added to -mcpu or -march for armv8 explicit.
> 
> That last point was something that confused me when I read the original 
> tune files. I did not realize that those extra features were added to 
> whatever -mcpu or -march happened to be added to TUNE_CCARGS before the 
> arch-armv8a.inc file was included (especially as it was written to make 
> it look as they were only added to the -march option).

For armv8 a larger redesign is actually required - it doesn't scale
to have variables like TUNE_FEATURES_tune-armv8a-crc-crypto with
160k possible combinations[1] in gcc 8.

> //Peter

cu
Adrian

[1] target architectures 8.0-8.4 and 15 feature modifiers

-- 

       "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