trouble related to oe-core update

trouble related to oe-core update

[Andreas Müller]

Hi,

have seen that a while ago but had no time to take care.

Since oe-core commit

commit 3e760031f91fb87c3e2f62b77a117eb41164f259
Author: Martin Jansa <martin.jansa@gmail.com>
Date:   Wed Feb 18 15:40:35 2015 +0100

    feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix

I get

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 does not contain TUNE_PKGARCH
(cortexa9t2hf-vfp-neon).

I don't understand this fully but it seems that
fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
happens because sanity.bbclass is executed first and interrupts
parsing. What I don't understand: Am I the only one having this issue
and if yes - what makes my configuration special.

Help - please :)

Andreas

Re: [OE-core] trouble related to oe-core update

[Martin Jansa]

On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
> Hi,

Hi,

> have seen that a while ago but had no time to take care.
> 
> Since oe-core commit
> 
> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
> Author: Martin Jansa <martin.jansa@gmail.com>
> Date:   Wed Feb 18 15:40:35 2015 +0100
> 
>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
> 
> I get
> 
> 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 does not contain TUNE_PKGARCH
> (cortexa9t2hf-vfp-neon).
> 
> I don't understand this fully but it seems that
> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
> happens because sanity.bbclass is executed first and interrupts
> parsing. What I don't understand: Am I the only one having this issue
>o
I'm not using meta-fsl*, butdo you have this patch in your setup?
http://patches.openembedded.org/patch/90989/
it was discussed off-list a while ago and this change looks like result
of that discussion.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: trouble related to oe-core update

[Martin Jansa]

On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
> Hi,

Hi,

> have seen that a while ago but had no time to take care.
> 
> Since oe-core commit
> 
> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
> Author: Martin Jansa <martin.jansa@gmail.com>
> Date:   Wed Feb 18 15:40:35 2015 +0100
> 
>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
> 
> I get
> 
> 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 does not contain TUNE_PKGARCH
> (cortexa9t2hf-vfp-neon).
> 
> I don't understand this fully but it seems that
> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
> happens because sanity.bbclass is executed first and interrupts
> parsing. What I don't understand: Am I the only one having this issue
>o
I'm not using meta-fsl*, butdo you have this patch in your setup?
http://patches.openembedded.org/patch/90989/
it was discussed off-list a while ago and this change looks like result
of that discussion.

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

Re: [OE-core] trouble related to oe-core update

[Andreas Müller]

On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>> Hi,
>
> Hi,
>
>> have seen that a while ago but had no time to take care.
>>
>> Since oe-core commit
>>
>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>> Author: Martin Jansa <martin.jansa@gmail.com>
>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>
>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>
>> I get
>>
>> 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 does not contain TUNE_PKGARCH
>> (cortexa9t2hf-vfp-neon).
>>
>> I don't understand this fully but it seems that
>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>> happens because sanity.bbclass is executed first and interrupts
>> parsing. What I don't understand: Am I the only one having this issue
>>o
> I'm not using meta-fsl*, butdo you have this patch in your setup?
> http://patches.openembedded.org/patch/90989/
> it was discussed off-list a while ago and this change looks like result
> of that discussion.
>
Have meta-fsl-arm current master in my layers. This contains a similar patch:

commit bfe01a0ebde407086f4a7710ea165c6beff310d7
Author: Max Krummenacher <max.oss.09@gmail.com>
Date:   Mon Mar 30 23:49:32 2015 +0200

    fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds

Have rebased the mentionioned patch -> same result.

My problem seems to be that sanity.bbclass bails out before code in
fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
around with layer priorities / order of layers nothing changed
situation.

Andreas

Re: trouble related to oe-core update

[Andreas Müller]

On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>> Hi,
>
> Hi,
>
>> have seen that a while ago but had no time to take care.
>>
>> Since oe-core commit
>>
>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>> Author: Martin Jansa <martin.jansa@gmail.com>
>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>
>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>
>> I get
>>
>> 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 does not contain TUNE_PKGARCH
>> (cortexa9t2hf-vfp-neon).
>>
>> I don't understand this fully but it seems that
>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>> happens because sanity.bbclass is executed first and interrupts
>> parsing. What I don't understand: Am I the only one having this issue
>>o
> I'm not using meta-fsl*, butdo you have this patch in your setup?
> http://patches.openembedded.org/patch/90989/
> it was discussed off-list a while ago and this change looks like result
> of that discussion.
>
Have meta-fsl-arm current master in my layers. This contains a similar patch:

commit bfe01a0ebde407086f4a7710ea165c6beff310d7
Author: Max Krummenacher <max.oss.09@gmail.com>
Date:   Mon Mar 30 23:49:32 2015 +0200

    fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds

Have rebased the mentionioned patch -> same result.

My problem seems to be that sanity.bbclass bails out before code in
fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
around with layer priorities / order of layers nothing changed
situation.

Andreas

Re: [OE-core] trouble related to oe-core update

[Otavio Salvador]

On Mon, May 18, 2015 at 6:00 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>> Hi,
>>
>> Hi,
>>
>>> have seen that a while ago but had no time to take care.
>>>
>>> Since oe-core commit
>>>
>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>>
>>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>>
>>> I get
>>>
>>> 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 does not contain TUNE_PKGARCH
>>> (cortexa9t2hf-vfp-neon).
>>>
>>> I don't understand this fully but it seems that
>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>> happens because sanity.bbclass is executed first and interrupts
>>> parsing. What I don't understand: Am I the only one having this issue
>>>o
>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>> http://patches.openembedded.org/patch/90989/
>> it was discussed off-list a while ago and this change looks like result
>> of that discussion.
>>
> Have meta-fsl-arm current master in my layers. This contains a similar patch:
>
> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
> Author: Max Krummenacher <max.oss.09@gmail.com>
> Date:   Mon Mar 30 23:49:32 2015 +0200
>
>     fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
>
> Have rebased the mentionioned patch -> same result.
>
> My problem seems to be that sanity.bbclass bails out before code in
> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
> around with layer priorities / order of layers nothing changed
> situation.

What board are you using?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: trouble related to oe-core update

[Otavio Salvador]

On Mon, May 18, 2015 at 6:00 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>> Hi,
>>
>> Hi,
>>
>>> have seen that a while ago but had no time to take care.
>>>
>>> Since oe-core commit
>>>
>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>>
>>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>>
>>> I get
>>>
>>> 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 does not contain TUNE_PKGARCH
>>> (cortexa9t2hf-vfp-neon).
>>>
>>> I don't understand this fully but it seems that
>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>> happens because sanity.bbclass is executed first and interrupts
>>> parsing. What I don't understand: Am I the only one having this issue
>>>o
>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>> http://patches.openembedded.org/patch/90989/
>> it was discussed off-list a while ago and this change looks like result
>> of that discussion.
>>
> Have meta-fsl-arm current master in my layers. This contains a similar patch:
>
> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
> Author: Max Krummenacher <max.oss.09@gmail.com>
> Date:   Mon Mar 30 23:49:32 2015 +0200
>
>     fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
>
> Have rebased the mentionioned patch -> same result.
>
> My problem seems to be that sanity.bbclass bails out before code in
> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
> around with layer priorities / order of layers nothing changed
> situation.

What board are you using?

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [OE-core] trouble related to oe-core update

[Andreas Müller]

On Mon, May 18, 2015 at 1:55 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Mon, May 18, 2015 at 6:00 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>>> Hi,
>>>
>>> Hi,
>>>
>>>> have seen that a while ago but had no time to take care.
>>>>
>>>> Since oe-core commit
>>>>
>>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>>>
>>>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>>>
>>>> I get
>>>>
>>>> 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 does not contain TUNE_PKGARCH
>>>> (cortexa9t2hf-vfp-neon).
>>>>
>>>> I don't understand this fully but it seems that
>>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>>> happens because sanity.bbclass is executed first and interrupts
>>>> parsing. What I don't understand: Am I the only one having this issue
>>>>o
>>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>>> http://patches.openembedded.org/patch/90989/
>>> it was discussed off-list a while ago and this change looks like result
>>> of that discussion.
>>>
>> Have meta-fsl-arm current master in my layers. This contains a similar patch:
>>
>> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
>> Author: Max Krummenacher <max.oss.09@gmail.com>
>> Date:   Mon Mar 30 23:49:32 2015 +0200
>>
>>     fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
>>
>> Have rebased the mentionioned patch -> same result.
>>
>> My problem seems to be that sanity.bbclass bails out before code in
>> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
>> around with layer priorities / order of layers nothing changed
>> situation.
>
> What board are you using?
>
For this I used imx6qsabresd (want to build for another machine but to
be sure that my layer does not cause trouble I removed it from
bblayers.conf and select imx6qsabresd).

Updates:

1) when replacing DISTRO = "angstrom" by DISTRO = "nodistro" in
local.conf and using imx6qsabresd as machine -> parsing of recipes
starts.
2) selecting custom machine [1] and DISTRO = "nodistro" -> sanity causes break

I get the feeling that there is some kind of race:
check_sanity_eventhandler in sanity.bbclass might get called before
python code in fsl-dynamic-packagearch.bbclass was executed.

[1] https://github.com/schnitzeltony/meta-variscite-community/blob/master/conf/machine/varsomimx6q.conf

Andreas

Re: trouble related to oe-core update

[Andreas Müller]

On Mon, May 18, 2015 at 1:55 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Mon, May 18, 2015 at 6:00 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>>> Hi,
>>>
>>> Hi,
>>>
>>>> have seen that a while ago but had no time to take care.
>>>>
>>>> Since oe-core commit
>>>>
>>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>>>
>>>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>>>
>>>> I get
>>>>
>>>> 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 does not contain TUNE_PKGARCH
>>>> (cortexa9t2hf-vfp-neon).
>>>>
>>>> I don't understand this fully but it seems that
>>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>>> happens because sanity.bbclass is executed first and interrupts
>>>> parsing. What I don't understand: Am I the only one having this issue
>>>>o
>>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>>> http://patches.openembedded.org/patch/90989/
>>> it was discussed off-list a while ago and this change looks like result
>>> of that discussion.
>>>
>> Have meta-fsl-arm current master in my layers. This contains a similar patch:
>>
>> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
>> Author: Max Krummenacher <max.oss.09@gmail.com>
>> Date:   Mon Mar 30 23:49:32 2015 +0200
>>
>>     fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
>>
>> Have rebased the mentionioned patch -> same result.
>>
>> My problem seems to be that sanity.bbclass bails out before code in
>> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
>> around with layer priorities / order of layers nothing changed
>> situation.
>
> What board are you using?
>
For this I used imx6qsabresd (want to build for another machine but to
be sure that my layer does not cause trouble I removed it from
bblayers.conf and select imx6qsabresd).

Updates:

1) when replacing DISTRO = "angstrom" by DISTRO = "nodistro" in
local.conf and using imx6qsabresd as machine -> parsing of recipes
starts.
2) selecting custom machine [1] and DISTRO = "nodistro" -> sanity causes break

I get the feeling that there is some kind of race:
check_sanity_eventhandler in sanity.bbclass might get called before
python code in fsl-dynamic-packagearch.bbclass was executed.

[1] https://github.com/schnitzeltony/meta-variscite-community/blob/master/conf/machine/varsomimx6q.conf

Andreas

Re: [OE-core] trouble related to oe-core update

[Otavio Salvador]

On Mon, May 18, 2015 at 9:43 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Mon, May 18, 2015 at 1:55 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Mon, May 18, 2015 at 6:00 AM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>>> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>>>> Hi,
>>>>
>>>> Hi,
>>>>
>>>>> have seen that a while ago but had no time to take care.
>>>>>
>>>>> Since oe-core commit
>>>>>
>>>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>>>>
>>>>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>>>>
>>>>> I get
>>>>>
>>>>> 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 does not contain TUNE_PKGARCH
>>>>> (cortexa9t2hf-vfp-neon).
>>>>>
>>>>> I don't understand this fully but it seems that
>>>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>>>> happens because sanity.bbclass is executed first and interrupts
>>>>> parsing. What I don't understand: Am I the only one having this issue
>>>>>o
>>>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>>>> http://patches.openembedded.org/patch/90989/
>>>> it was discussed off-list a while ago and this change looks like result
>>>> of that discussion.
>>>>
>>> Have meta-fsl-arm current master in my layers. This contains a similar patch:
>>>
>>> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
>>> Author: Max Krummenacher <max.oss.09@gmail.com>
>>> Date:   Mon Mar 30 23:49:32 2015 +0200
>>>
>>>     fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
>>>
>>> Have rebased the mentionioned patch -> same result.
>>>
>>> My problem seems to be that sanity.bbclass bails out before code in
>>> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
>>> around with layer priorities / order of layers nothing changed
>>> situation.
>>
>> What board are you using?
>>
> For this I used imx6qsabresd (want to build for another machine but to
> be sure that my layer does not cause trouble I removed it from
> bblayers.conf and select imx6qsabresd).
>
> Updates:
>
> 1) when replacing DISTRO = "angstrom" by DISTRO = "nodistro" in
> local.conf and using imx6qsabresd as machine -> parsing of recipes
> starts.
> 2) selecting custom machine [1] and DISTRO = "nodistro" -> sanity causes break
>
> I get the feeling that there is some kind of race:
> check_sanity_eventhandler in sanity.bbclass might get called before
> python code in fsl-dynamic-packagearch.bbclass was executed.
>
> [1] https://github.com/schnitzeltony/meta-variscite-community/blob/master/conf/machine/varsomimx6q.conf

So it is clearly related to the Variscite board.

This layer has too much duplication. Stop using the duplicated bits
and rely on the ones provided by the BSP (imx-base.inc for example).
To be honest, it would be good to push Variscite to proper integrate
the board as it is a very popular SoM for custom projects. The
imx-base.inc reuse should fix your issue I think.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: trouble related to oe-core update

[Otavio Salvador]

On Mon, May 18, 2015 at 9:43 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Mon, May 18, 2015 at 1:55 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
>> On Mon, May 18, 2015 at 6:00 AM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>>> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>>>> Hi,
>>>>
>>>> Hi,
>>>>
>>>>> have seen that a while ago but had no time to take care.
>>>>>
>>>>> Since oe-core commit
>>>>>
>>>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>>>>
>>>>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>>>>
>>>>> I get
>>>>>
>>>>> 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 does not contain TUNE_PKGARCH
>>>>> (cortexa9t2hf-vfp-neon).
>>>>>
>>>>> I don't understand this fully but it seems that
>>>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>>>> happens because sanity.bbclass is executed first and interrupts
>>>>> parsing. What I don't understand: Am I the only one having this issue
>>>>>o
>>>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>>>> http://patches.openembedded.org/patch/90989/
>>>> it was discussed off-list a while ago and this change looks like result
>>>> of that discussion.
>>>>
>>> Have meta-fsl-arm current master in my layers. This contains a similar patch:
>>>
>>> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
>>> Author: Max Krummenacher <max.oss.09@gmail.com>
>>> Date:   Mon Mar 30 23:49:32 2015 +0200
>>>
>>>     fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
>>>
>>> Have rebased the mentionioned patch -> same result.
>>>
>>> My problem seems to be that sanity.bbclass bails out before code in
>>> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
>>> around with layer priorities / order of layers nothing changed
>>> situation.
>>
>> What board are you using?
>>
> For this I used imx6qsabresd (want to build for another machine but to
> be sure that my layer does not cause trouble I removed it from
> bblayers.conf and select imx6qsabresd).
>
> Updates:
>
> 1) when replacing DISTRO = "angstrom" by DISTRO = "nodistro" in
> local.conf and using imx6qsabresd as machine -> parsing of recipes
> starts.
> 2) selecting custom machine [1] and DISTRO = "nodistro" -> sanity causes break
>
> I get the feeling that there is some kind of race:
> check_sanity_eventhandler in sanity.bbclass might get called before
> python code in fsl-dynamic-packagearch.bbclass was executed.
>
> [1] https://github.com/schnitzeltony/meta-variscite-community/blob/master/conf/machine/varsomimx6q.conf

So it is clearly related to the Variscite board.

This layer has too much duplication. Stop using the duplicated bits
and rely on the ones provided by the BSP (imx-base.inc for example).
To be honest, it would be good to push Variscite to proper integrate
the board as it is a very popular SoM for custom projects. The
imx-base.inc reuse should fix your issue I think.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [OE-core] trouble related to oe-core update

[Andreas Müller]

On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Mon, May 18, 2015 at 9:43 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Mon, May 18, 2015 at 1:55 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Mon, May 18, 2015 at 6:00 AM, Andreas Müller
>>> <schnitzeltony@googlemail.com> wrote:
>>>> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>>>>> Hi,
>>>>>
>>>>> Hi,
>>>>>
>>>>>> have seen that a while ago but had no time to take care.
>>>>>>
>>>>>> Since oe-core commit
>>>>>>
>>>>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>>>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>>>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>>>>>
>>>>>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>>>>>
>>>>>> I get
>>>>>>
>>>>>> 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 does not contain TUNE_PKGARCH
>>>>>> (cortexa9t2hf-vfp-neon).
>>>>>>
>>>>>> I don't understand this fully but it seems that
>>>>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>>>>> happens because sanity.bbclass is executed first and interrupts
>>>>>> parsing. What I don't understand: Am I the only one having this issue
>>>>>>o
>>>>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>>>>> http://patches.openembedded.org/patch/90989/
>>>>> it was discussed off-list a while ago and this change looks like result
>>>>> of that discussion.
>>>>>
>>>> Have meta-fsl-arm current master in my layers. This contains a similar patch:
>>>>
>>>> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
>>>> Author: Max Krummenacher <max.oss.09@gmail.com>
>>>> Date:   Mon Mar 30 23:49:32 2015 +0200
>>>>
>>>>     fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
>>>>
>>>> Have rebased the mentionioned patch -> same result.
>>>>
>>>> My problem seems to be that sanity.bbclass bails out before code in
>>>> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
>>>> around with layer priorities / order of layers nothing changed
>>>> situation.
>>>
>>> What board are you using?
>>>
>> For this I used imx6qsabresd (want to build for another machine but to
>> be sure that my layer does not cause trouble I removed it from
>> bblayers.conf and select imx6qsabresd).
>>
>> Updates:
>>
>> 1) when replacing DISTRO = "angstrom" by DISTRO = "nodistro" in
>> local.conf and using imx6qsabresd as machine -> parsing of recipes
>> starts.
>> 2) selecting custom machine [1] and DISTRO = "nodistro" -> sanity causes break
>>
>> I get the feeling that there is some kind of race:
>> check_sanity_eventhandler in sanity.bbclass might get called before
>> python code in fsl-dynamic-packagearch.bbclass was executed.
>>
>> [1] https://github.com/schnitzeltony/meta-variscite-community/blob/master/conf/machine/varsomimx6q.conf
>
> So it is clearly related to the Variscite board.
>
> This layer has too much duplication. Stop using the duplicated bits
> and rely on the ones provided by the BSP (imx-base.inc for example).
> To be honest, it would be good to push Variscite to proper integrate
> the board as it is a very popular SoM for custom projects. The
> imx-base.inc reuse should fix your issue I think.
>
This layer is WIP (would be happy to see something usable in
meta-fsl-arm-extra -but this is a different story) so don't
overestimate please. Still what about angstrom + imx6qsabresd?

Andreas

Re: trouble related to oe-core update

[Andreas Müller]

On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
<otavio@ossystems.com.br> wrote:
> On Mon, May 18, 2015 at 9:43 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Mon, May 18, 2015 at 1:55 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
>>> On Mon, May 18, 2015 at 6:00 AM, Andreas Müller
>>> <schnitzeltony@googlemail.com> wrote:
>>>> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>>>>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>>>>> Hi,
>>>>>
>>>>> Hi,
>>>>>
>>>>>> have seen that a while ago but had no time to take care.
>>>>>>
>>>>>> Since oe-core commit
>>>>>>
>>>>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>>>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>>>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>>>>>
>>>>>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>>>>>
>>>>>> I get
>>>>>>
>>>>>> 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 does not contain TUNE_PKGARCH
>>>>>> (cortexa9t2hf-vfp-neon).
>>>>>>
>>>>>> I don't understand this fully but it seems that
>>>>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>>>>> happens because sanity.bbclass is executed first and interrupts
>>>>>> parsing. What I don't understand: Am I the only one having this issue
>>>>>>o
>>>>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>>>>> http://patches.openembedded.org/patch/90989/
>>>>> it was discussed off-list a while ago and this change looks like result
>>>>> of that discussion.
>>>>>
>>>> Have meta-fsl-arm current master in my layers. This contains a similar patch:
>>>>
>>>> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
>>>> Author: Max Krummenacher <max.oss.09@gmail.com>
>>>> Date:   Mon Mar 30 23:49:32 2015 +0200
>>>>
>>>>     fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
>>>>
>>>> Have rebased the mentionioned patch -> same result.
>>>>
>>>> My problem seems to be that sanity.bbclass bails out before code in
>>>> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
>>>> around with layer priorities / order of layers nothing changed
>>>> situation.
>>>
>>> What board are you using?
>>>
>> For this I used imx6qsabresd (want to build for another machine but to
>> be sure that my layer does not cause trouble I removed it from
>> bblayers.conf and select imx6qsabresd).
>>
>> Updates:
>>
>> 1) when replacing DISTRO = "angstrom" by DISTRO = "nodistro" in
>> local.conf and using imx6qsabresd as machine -> parsing of recipes
>> starts.
>> 2) selecting custom machine [1] and DISTRO = "nodistro" -> sanity causes break
>>
>> I get the feeling that there is some kind of race:
>> check_sanity_eventhandler in sanity.bbclass might get called before
>> python code in fsl-dynamic-packagearch.bbclass was executed.
>>
>> [1] https://github.com/schnitzeltony/meta-variscite-community/blob/master/conf/machine/varsomimx6q.conf
>
> So it is clearly related to the Variscite board.
>
> This layer has too much duplication. Stop using the duplicated bits
> and rely on the ones provided by the BSP (imx-base.inc for example).
> To be honest, it would be good to push Variscite to proper integrate
> the board as it is a very popular SoM for custom projects. The
> imx-base.inc reuse should fix your issue I think.
>
This layer is WIP (would be happy to see something usable in
meta-fsl-arm-extra -but this is a different story) so don't
overestimate please. Still what about angstrom + imx6qsabresd?

Andreas

Re: [OE-core] trouble related to oe-core update

[Otavio Salvador]

On Mon, May 18, 2015 at 10:08 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
...
> overestimate please. Still what about angstrom + imx6qsabresd?

No clue. I personally don't use Angstrom and I don't know what the
distro does. You can instrument the class code to see if you find
something useful and I can assist in how to address the issue. I just
don't have enough time to debug this myself.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: trouble related to oe-core update

[Otavio Salvador]

On Mon, May 18, 2015 at 10:08 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
> <otavio@ossystems.com.br> wrote:
...
> overestimate please. Still what about angstrom + imx6qsabresd?

No clue. I personally don't use Angstrom and I don't know what the
distro does. You can instrument the class code to see if you find
something useful and I can assist in how to address the issue. I just
don't have enough time to debug this myself.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [OE-core] trouble related to oe-core update

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]


> On May 18, 2015, at 2:00 AM, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> 
> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>> Hi,
>> 
>> Hi,
>> 
>>> have seen that a while ago but had no time to take care.
>>> 
>>> Since oe-core commit
>>> 
>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>> 
>>>    feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>> 
>>> I get
>>> 
>>> 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 does not contain TUNE_PKGARCH
>>> (cortexa9t2hf-vfp-neon).
>>> 
>>> I don't understand this fully but it seems that
>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>> happens because sanity.bbclass is executed first and interrupts
>>> parsing. What I don't understand: Am I the only one having this issue
>>> o
>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>> http://patches.openembedded.org/patch/90989/
>> it was discussed off-list a while ago and this change looks like result
>> of that discussion.
>> 
> Have meta-fsl-arm current master in my layers. This contains a similar patch:
> 
> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
> Author: Max Krummenacher <max.oss.09@gmail.com>
> Date:   Mon Mar 30 23:49:32 2015 +0200
> 
>    fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
> 
> Have rebased the mentionioned patch -> same result.
> 
> My problem seems to be that sanity.bbclass bails out before code in
> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
> around with layer priorities / order of layers nothing changed
> situation.

angstrom uses thumb2 by default. So you have exposed a bug in OE-Core or meta-fsl-arm
the default configurations that meta-fsl-arm has been tested is probably not using thumb2

Just set ARM_INSTRUCTION_SET = “arm"

in local.conf and you should make progress.

> 
> Andreas
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: trouble related to oe-core update

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2577 bytes --]


> On May 18, 2015, at 2:00 AM, Andreas Müller <schnitzeltony@googlemail.com> wrote:
> 
> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa@gmail.com> wrote:
>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:
>>> Hi,
>> 
>> Hi,
>> 
>>> have seen that a while ago but had no time to take care.
>>> 
>>> Since oe-core commit
>>> 
>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
>>> Author: Martin Jansa <martin.jansa@gmail.com>
>>> Date:   Wed Feb 18 15:40:35 2015 +0100
>>> 
>>>    feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding thumb suffix
>>> 
>>> I get
>>> 
>>> 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 does not contain TUNE_PKGARCH
>>> (cortexa9t2hf-vfp-neon).
>>> 
>>> I don't understand this fully but it seems that
>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
>>> happens because sanity.bbclass is executed first and interrupts
>>> parsing. What I don't understand: Am I the only one having this issue
>>> o
>> I'm not using meta-fsl*, butdo you have this patch in your setup?
>> http://patches.openembedded.org/patch/90989/
>> it was discussed off-list a while ago and this change looks like result
>> of that discussion.
>> 
> Have meta-fsl-arm current master in my layers. This contains a similar patch:
> 
> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
> Author: Max Krummenacher <max.oss.09@gmail.com>
> Date:   Mon Mar 30 23:49:32 2015 +0200
> 
>    fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
> 
> Have rebased the mentionioned patch -> same result.
> 
> My problem seems to be that sanity.bbclass bails out before code in
> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
> around with layer priorities / order of layers nothing changed
> situation.

angstrom uses thumb2 by default. So you have exposed a bug in OE-Core or meta-fsl-arm
the default configurations that meta-fsl-arm has been tested is probably not using thumb2

Just set ARM_INSTRUCTION_SET = “arm"

in local.conf and you should make progress.

> 
> Andreas
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [OE-core] trouble related to oe-core update

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]


> On May 18, 2015, at 6:12 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> 
> On Mon, May 18, 2015 at 10:08 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
> ...
>> overestimate please. Still what about angstrom + imx6qsabresd?
> 
> No clue. I personally don't use Angstrom and I don't know what the
> distro does. You can instrument the class code to see if you find
> something useful and I can assist in how to address the issue. I just
> don't have enough time to debug this myself.

It has nothing to do with Angstrom, I checked meta-fsl-arm and here it goes

conf/machine/imx6qsabresd.conf
….
SOC_FAMILY = "mx6:mx6q”
…

Then

conf/machine/include/imx-base.inc

….
# Float-Point setting
# handled by software
# DEFAULTTUNE_mx6 ?= "cortexa9-neon"
# handled by hardware
DEFAULTTUNE_mx6 ?= "cortexa9hf-neon”
….

Here you are saying all mx6 machines which don’t choose their DEFAULTTUNE are not thumb capable
and hence ‘thumb’ does not get into TUNE_FEATURES

IMO changing defaults for mx6 to use cortexa9t2hf-vfp-neon would be most close to h/w capabilities.

and when we say my default instruction set is thumb then it errors out. Ofcours one could argue
that message could have been better but atleast it did not do the wrong thing



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: trouble related to oe-core update

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]


> On May 18, 2015, at 6:12 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> 
> On Mon, May 18, 2015 at 10:08 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
>> On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
>> <otavio@ossystems.com.br> wrote:
> ...
>> overestimate please. Still what about angstrom + imx6qsabresd?
> 
> No clue. I personally don't use Angstrom and I don't know what the
> distro does. You can instrument the class code to see if you find
> something useful and I can assist in how to address the issue. I just
> don't have enough time to debug this myself.

It has nothing to do with Angstrom, I checked meta-fsl-arm and here it goes

conf/machine/imx6qsabresd.conf
….
SOC_FAMILY = "mx6:mx6q”
…

Then

conf/machine/include/imx-base.inc

….
# Float-Point setting
# handled by software
# DEFAULTTUNE_mx6 ?= "cortexa9-neon"
# handled by hardware
DEFAULTTUNE_mx6 ?= "cortexa9hf-neon”
….

Here you are saying all mx6 machines which don’t choose their DEFAULTTUNE are not thumb capable
and hence ‘thumb’ does not get into TUNE_FEATURES

IMO changing defaults for mx6 to use cortexa9t2hf-vfp-neon would be most close to h/w capabilities.

and when we say my default instruction set is thumb then it errors out. Ofcours one could argue
that message could have been better but atleast it did not do the wrong thing



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [OE-core] trouble related to oe-core update

[Andreas Müller]

On Tue, May 19, 2015 at 5:54 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>> On May 18, 2015, at 6:12 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>
>> On Mon, May 18, 2015 at 10:08 AM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>>> On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>> ...
>>> overestimate please. Still what about angstrom + imx6qsabresd?
>>
>> No clue. I personally don't use Angstrom and I don't know what the
>> distro does. You can instrument the class code to see if you find
>> something useful and I can assist in how to address the issue. I just
>> don't have enough time to debug this myself.
>
> It has nothing to do with Angstrom, I checked meta-fsl-arm and here it goes
>
> conf/machine/imx6qsabresd.conf
> ….
> SOC_FAMILY = "mx6:mx6q”
> …
>
> Then
>
> conf/machine/include/imx-base.inc
>
> ….
> # Float-Point setting
> # handled by software
> # DEFAULTTUNE_mx6 ?= "cortexa9-neon"
> # handled by hardware
> DEFAULTTUNE_mx6 ?= "cortexa9hf-neon”
> ….
>
> Here you are saying all mx6 machines which don’t choose their DEFAULTTUNE are not thumb capable
> and hence ‘thumb’ does not get into TUNE_FEATURES
>
> IMO changing defaults for mx6 to use cortexa9t2hf-vfp-neon would be most close to h/w capabilities.
>
> and when we say my default instruction set is thumb then it errors out. Ofcours one could argue
> that message could have been better but atleast it did not do the wrong thing
>
Hi,

thanks very very much for support.

As you might guess TUNES are still a matter I do not yet understand -
please no comments :).

So to get build working again - also for variscite machine - I
commented out DEFAULTTUNE_mx6 in conf/machine/include/imx-base.inc.

Maybe somebody could jump in to get the combination of meta-fsl-arm /
meta-angstrom working with a proper fix?

Thanks again

Andreas

Re: trouble related to oe-core update

[Andreas Müller]

On Tue, May 19, 2015 at 5:54 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>> On May 18, 2015, at 6:12 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>
>> On Mon, May 18, 2015 at 10:08 AM, Andreas Müller
>> <schnitzeltony@googlemail.com> wrote:
>>> On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
>>> <otavio@ossystems.com.br> wrote:
>> ...
>>> overestimate please. Still what about angstrom + imx6qsabresd?
>>
>> No clue. I personally don't use Angstrom and I don't know what the
>> distro does. You can instrument the class code to see if you find
>> something useful and I can assist in how to address the issue. I just
>> don't have enough time to debug this myself.
>
> It has nothing to do with Angstrom, I checked meta-fsl-arm and here it goes
>
> conf/machine/imx6qsabresd.conf
> ….
> SOC_FAMILY = "mx6:mx6q”
> …
>
> Then
>
> conf/machine/include/imx-base.inc
>
> ….
> # Float-Point setting
> # handled by software
> # DEFAULTTUNE_mx6 ?= "cortexa9-neon"
> # handled by hardware
> DEFAULTTUNE_mx6 ?= "cortexa9hf-neon”
> ….
>
> Here you are saying all mx6 machines which don’t choose their DEFAULTTUNE are not thumb capable
> and hence ‘thumb’ does not get into TUNE_FEATURES
>
> IMO changing defaults for mx6 to use cortexa9t2hf-vfp-neon would be most close to h/w capabilities.
>
> and when we say my default instruction set is thumb then it errors out. Ofcours one could argue
> that message could have been better but atleast it did not do the wrong thing
>
Hi,

thanks very very much for support.

As you might guess TUNES are still a matter I do not yet understand -
please no comments :).

So to get build working again - also for variscite machine - I
commented out DEFAULTTUNE_mx6 in conf/machine/include/imx-base.inc.

Maybe somebody could jump in to get the combination of meta-fsl-arm /
meta-angstrom working with a proper fix?

Thanks again

Andreas

Re: [OE-core] trouble related to oe-core update

[Andreas Müller]

On Tue, May 19, 2015 at 10:54 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Tue, May 19, 2015 at 5:54 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>> On May 18, 2015, at 6:12 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>>
>>> On Mon, May 18, 2015 at 10:08 AM, Andreas Müller
>>> <schnitzeltony@googlemail.com> wrote:
>>>> On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
>>>> <otavio@ossystems.com.br> wrote:
>>> ...
>>>> overestimate please. Still what about angstrom + imx6qsabresd?
>>>
>>> No clue. I personally don't use Angstrom and I don't know what the
>>> distro does. You can instrument the class code to see if you find
>>> something useful and I can assist in how to address the issue. I just
>>> don't have enough time to debug this myself.
>>
>> It has nothing to do with Angstrom, I checked meta-fsl-arm and here it goes
>>
>> conf/machine/imx6qsabresd.conf
>> ….
>> SOC_FAMILY = "mx6:mx6q”
>> …
>>
>> Then
>>
>> conf/machine/include/imx-base.inc
>>
>> ….
>> # Float-Point setting
>> # handled by software
>> # DEFAULTTUNE_mx6 ?= "cortexa9-neon"
>> # handled by hardware
>> DEFAULTTUNE_mx6 ?= "cortexa9hf-neon”
>> ….
>>
>> Here you are saying all mx6 machines which don’t choose their DEFAULTTUNE are not thumb capable
>> and hence ‘thumb’ does not get into TUNE_FEATURES
>>
>> IMO changing defaults for mx6 to use cortexa9t2hf-vfp-neon would be most close to h/w capabilities.
>>
>> and when we say my default instruction set is thumb then it errors out. Ofcours one could argue
>> that message could have been better but atleast it did not do the wrong thing
>>
> Hi,
>
> thanks very very much for support.
>
> As you might guess TUNES are still a matter I do not yet understand -
> please no comments :).
>
> So to get build working again - also for variscite machine - I
> commented out DEFAULTTUNE_mx6 in conf/machine/include/imx-base.inc.
>
> Maybe somebody could jump in to get the combination of meta-fsl-arm /
> meta-angstrom working with a proper fix?
>
> Thanks again
>
Would like to get a solution for this and see 2 ways to go in imx-base.inc:

1. allow thumb:
<snip>
# Float-Point setting
# handled by software
# DEFAULTTUNE_mx6 ?= "cortexa9t-neon"
# handled by hardware
DEFAULTTUNE_mx6 ?= "cortexa9thf-neon"
</snip>

2. if thumb2 is not allowed (why?):
<snip>
# Float-Point setting
# handled by software
# DEFAULTTUNE_mx6 ?= "cortexa9-neon"
# handled by hardware
DEFAULTTUNE_mx6 ?= "cortexa9hf-neon"
ARM_INSTRUCTION_SET = "arm"
</snip>

Opinions?

Andreas

Re: trouble related to oe-core update

[Andreas Müller]

On Tue, May 19, 2015 at 10:54 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Tue, May 19, 2015 at 5:54 AM, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>> On May 18, 2015, at 6:12 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>>
>>> On Mon, May 18, 2015 at 10:08 AM, Andreas Müller
>>> <schnitzeltony@googlemail.com> wrote:
>>>> On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
>>>> <otavio@ossystems.com.br> wrote:
>>> ...
>>>> overestimate please. Still what about angstrom + imx6qsabresd?
>>>
>>> No clue. I personally don't use Angstrom and I don't know what the
>>> distro does. You can instrument the class code to see if you find
>>> something useful and I can assist in how to address the issue. I just
>>> don't have enough time to debug this myself.
>>
>> It has nothing to do with Angstrom, I checked meta-fsl-arm and here it goes
>>
>> conf/machine/imx6qsabresd.conf
>> ….
>> SOC_FAMILY = "mx6:mx6q”
>> …
>>
>> Then
>>
>> conf/machine/include/imx-base.inc
>>
>> ….
>> # Float-Point setting
>> # handled by software
>> # DEFAULTTUNE_mx6 ?= "cortexa9-neon"
>> # handled by hardware
>> DEFAULTTUNE_mx6 ?= "cortexa9hf-neon”
>> ….
>>
>> Here you are saying all mx6 machines which don’t choose their DEFAULTTUNE are not thumb capable
>> and hence ‘thumb’ does not get into TUNE_FEATURES
>>
>> IMO changing defaults for mx6 to use cortexa9t2hf-vfp-neon would be most close to h/w capabilities.
>>
>> and when we say my default instruction set is thumb then it errors out. Ofcours one could argue
>> that message could have been better but atleast it did not do the wrong thing
>>
> Hi,
>
> thanks very very much for support.
>
> As you might guess TUNES are still a matter I do not yet understand -
> please no comments :).
>
> So to get build working again - also for variscite machine - I
> commented out DEFAULTTUNE_mx6 in conf/machine/include/imx-base.inc.
>
> Maybe somebody could jump in to get the combination of meta-fsl-arm /
> meta-angstrom working with a proper fix?
>
> Thanks again
>
Would like to get a solution for this and see 2 ways to go in imx-base.inc:

1. allow thumb:
<snip>
# Float-Point setting
# handled by software
# DEFAULTTUNE_mx6 ?= "cortexa9t-neon"
# handled by hardware
DEFAULTTUNE_mx6 ?= "cortexa9thf-neon"
</snip>

2. if thumb2 is not allowed (why?):
<snip>
# Float-Point setting
# handled by software
# DEFAULTTUNE_mx6 ?= "cortexa9-neon"
# handled by hardware
DEFAULTTUNE_mx6 ?= "cortexa9hf-neon"
ARM_INSTRUCTION_SET = "arm"
</snip>

Opinions?

Andreas

Re: [OE-core] trouble related to oe-core update

[Otavio Salvador]

On Wed, May 20, 2015 at 5:34 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Tue, May 19, 2015 at 10:54 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
> Would like to get a solution for this and see 2 ways to go in imx-base.inc:
>
> 1. allow thumb:
> <snip>
> # Float-Point setting
> # handled by software
> # DEFAULTTUNE_mx6 ?= "cortexa9t-neon"
> # handled by hardware
> DEFAULTTUNE_mx6 ?= "cortexa9thf-neon"
> </snip>
>
> 2. if thumb2 is not allowed (why?):
> <snip>
> # Float-Point setting
> # handled by software
> # DEFAULTTUNE_mx6 ?= "cortexa9-neon"
> # handled by hardware
> DEFAULTTUNE_mx6 ?= "cortexa9hf-neon"
> ARM_INSTRUCTION_SET = "arm"
> </snip>
>
> Opinions?

OE-Core does not seem to enable thumb2 by default so I don't think we
ought to change the default here. However I do agree in extend the
comment and provide an example so it is easier for people to do this
when needed.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: trouble related to oe-core update

[Otavio Salvador]

On Wed, May 20, 2015 at 5:34 AM, Andreas Müller
<schnitzeltony@googlemail.com> wrote:
> On Tue, May 19, 2015 at 10:54 AM, Andreas Müller
> <schnitzeltony@googlemail.com> wrote:
> Would like to get a solution for this and see 2 ways to go in imx-base.inc:
>
> 1. allow thumb:
> <snip>
> # Float-Point setting
> # handled by software
> # DEFAULTTUNE_mx6 ?= "cortexa9t-neon"
> # handled by hardware
> DEFAULTTUNE_mx6 ?= "cortexa9thf-neon"
> </snip>
>
> 2. if thumb2 is not allowed (why?):
> <snip>
> # Float-Point setting
> # handled by software
> # DEFAULTTUNE_mx6 ?= "cortexa9-neon"
> # handled by hardware
> DEFAULTTUNE_mx6 ?= "cortexa9hf-neon"
> ARM_INSTRUCTION_SET = "arm"
> </snip>
>
> Opinions?

OE-Core does not seem to enable thumb2 by default so I don't think we
ought to change the default here. However I do agree in extend the
comment and provide an example so it is easier for people to do this
when needed.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [OE-core] trouble related to oe-core update

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]


> On May 20, 2015, at 6:46 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> 
> OE-Core does not seem to enable thumb2 by default so I don't think we
> ought to change the default here. However I do agree in extend the
> comment and provide an example so it is easier for people to do this
> when needed.

No. That setting is effectively telling
this chip does not have thumb capabilities which is wrong for that class of processors, that assumption
is wrong and should be fixed.

even if you have thumb tunes expressed, it won’t change default ISA which is what you are
implying with your first sentence there. Default ISA for a component or globally can be changed
via different knobs and distros can choose that policy.



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: trouble related to oe-core update

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 750 bytes --]


> On May 20, 2015, at 6:46 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
> 
> OE-Core does not seem to enable thumb2 by default so I don't think we
> ought to change the default here. However I do agree in extend the
> comment and provide an example so it is easier for people to do this
> when needed.

No. That setting is effectively telling
this chip does not have thumb capabilities which is wrong for that class of processors, that assumption
is wrong and should be fixed.

even if you have thumb tunes expressed, it won’t change default ISA which is what you are
implying with your first sentence there. Default ISA for a component or globally can be changed
via different knobs and distros can choose that policy.



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [OE-core] trouble related to oe-core update

[Otavio Salvador]

On Wed, May 20, 2015 at 10:58 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>> On May 20, 2015, at 6:46 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>
>> OE-Core does not seem to enable thumb2 by default so I don't think we
>> ought to change the default here. However I do agree in extend the
>> comment and provide an example so it is easier for people to do this
>> when needed.
>
> No. That setting is effectively telling
> this chip does not have thumb capabilities which is wrong for that class of processors, that assumption
> is wrong and should be fixed.
>
> even if you have thumb tunes expressed, it won’t change default ISA which is what you are
> implying with your first sentence there. Default ISA for a component or globally can be changed
> via different knobs and distros can choose that policy.

Is it possible for you to cook a formal patch with a descriptive
commit log for review than? I am not against this change but this
needs to be well documented.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: trouble related to oe-core update

[Otavio Salvador]

On Wed, May 20, 2015 at 10:58 AM, Khem Raj <raj.khem@gmail.com> wrote:
>
>> On May 20, 2015, at 6:46 AM, Otavio Salvador <otavio@ossystems.com.br> wrote:
>>
>> OE-Core does not seem to enable thumb2 by default so I don't think we
>> ought to change the default here. However I do agree in extend the
>> comment and provide an example so it is easier for people to do this
>> when needed.
>
> No. That setting is effectively telling
> this chip does not have thumb capabilities which is wrong for that class of processors, that assumption
> is wrong and should be fixed.
>
> even if you have thumb tunes expressed, it won’t change default ISA which is what you are
> implying with your first sentence there. Default ISA for a component or globally can be changed
> via different knobs and distros can choose that policy.

Is it possible for you to cook a formal patch with a descriptive
commit log for review than? I am not against this change but this
needs to be well documented.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: [OE-core] trouble related to oe-core update

[Max Krummenacher]

Hi All

Andreas Müller <schnitzeltony@...> writes:

>
> On Mon, May 18, 2015 at 2:50 PM, Otavio Salvador
> <otavio <at> ossystems.com.br> wrote:
> > On Mon, May 18, 2015 at 9:43 AM, Andreas Müller
> > <schnitzeltony <at> googlemail.com> wrote:
> >> On Mon, May 18, 2015 at 1:55 PM, Otavio Salvador
> >> <otavio <at> ossystems.com.br> wrote:
> >>> On Mon, May 18, 2015 at 6:00 AM, Andreas Müller
> >>> <schnitzeltony <at> googlemail.com> wrote:
> >>>> On Mon, May 18, 2015 at 10:01 AM, Martin Jansa <martin.jansa <at>
gmail.com> wrote:
> >>>>> On Mon, May 18, 2015 at 09:46:03AM +0200, Andreas Müller wrote:

> >>>>>> have seen that a while ago but had no time to take care.
> >>>>>>
> >>>>>> Since oe-core commit
> >>>>>>
> >>>>>> commit 3e760031f91fb87c3e2f62b77a117eb41164f259
> >>>>>> Author: Martin Jansa <martin.jansa <at> gmail.com>
> >>>>>> Date:   Wed Feb 18 15:40:35 2015 +0100
> >>>>>>
> >>>>>>     feature-arm-thumb.inc: respect ARM_INSTRUCTION_SET when adding
thumb suffix
> >>>>>>
> >>>>>> I get
> >>>>>>
> >>>>>> 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 does not contain TUNE_PKGARCH
> >>>>>> (cortexa9t2hf-vfp-neon).
> >>>>>>
> >>>>>> I don't understand this fully but it seems that
> >>>>>> fsl-dynamic-packagearch.bbclass would add this pkg arch but this never
> >>>>>> happens because sanity.bbclass is executed first and interrupts
> >>>>>> parsing. What I don't understand: Am I the only one having this issue

That is wrong, see below.

> >>>>> I'm not using meta-fsl*, butdo you have this patch in your setup?
> >>>>> http://patches.openembedded.org/patch/90989/
> >>>>> it was discussed off-list a while ago and this change looks like result
> >>>>> of that discussion.
> >>>>>
> >>>> Have meta-fsl-arm current master in my layers. This contains a
similar patch:
> >>>>
> >>>> commit bfe01a0ebde407086f4a7710ea165c6beff310d7
> >>>> Author: Max Krummenacher <max.oss.09 <at> gmail.com>
> >>>> Date:   Mon Mar 30 23:49:32 2015 +0200
> >>>>
> >>>>     fsl-dynamic-packagearch: add all MACHINE_SOCARCH feeds
> >>>>

meta-fsl-arm adds an additional package feed for the SOC ARCH packages
to the ones already available.
e.g. for i.MX6 cortexa9hf-vfp-neon-mx6qdl.

If the configuration sets the default instruction set to thumb
(as angstrom does) then all packages which are built with thumb
are placed in a thumb specific feed.
So meta-fsl-arm must add yet another package feed,
e.g. cortexa9t2hf-vfp-neon-mx6qdl.
The mentioned patch (and its changes due to regressions or
side effects) does this so that during do_rootfs these thumb packages
are actually found.

> >>>> My problem seems to be that sanity.bbclass bails out before code in
> >>>> fsl-dynamic-packagearch.bbclass is executed (and would fix). Playing
> >>>> around with layer priorities / order of layers nothing changed
> >>>> situation.
> >>>

I believe that the way Angstrom configures thumb together with how
meta-fsl-arm sets the DEFAULTTUNE the resulting build does
a) build thumb packages
and
b) does not have thumb in TUNE_FEATURES
which makes the sanity checker kick in.

Standard assignment from Angstrom after some python magic:
DEFAULTTUNE := "${@arm_tune_handler(d)}"
https://github.com/Angstrom-distribution/meta-angstrom/blob/master/conf/distro/include/arm-defaults.inc#L22
Plus setting the default instruction set to thumb here:
https://github.com/Angstrom-distribution/meta-angstrom/blob/master/conf/distro/include/angstrom.inc#L56

Override in meta-fsl-arm which takes precedence
https://github.com/Freescale/meta-fsl-arm/blob/master/conf/machine/include/imx-base.inc#L37
DEFAULTTUNE_mx6 ?= "cortexa9hf-neon"


My luck was the following define in the machine configuration
DEFAULTTUNE_mx6 = "armv7athf-neon"
because I build for cortex-a5 and cortex-a9 machines and don't want to
rebuild all packages due to specific machine archs.
http://git.toradex.com/cgit/meta-toradex.git/tree/conf/machine/apalis-imx6.conf?h=V2.4#n6

So you probably get a working configuration when adding one of the
following:
DEFAULTTUNE_mx6 = "armv7athf-neon"
DEFAULTTUNE_mx6 = "cortexa9thf-neon"


Regards
Max