Re: [OE-core] fido -> jethro switching problem

2016-01-18 Thread Steffen Sledz 
On 15.01.2016 15:29, Koen Kooi wrote:
>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz  het 
>> volgende geschreven:
>> It seems that all machines based on armv5e are affected.
> 
> FWIW, I'm seeing the same problem. The last time it happened it was due to 
> the fixup angstrom does for broken arm BSPs

What commits do you talking about ("last time it happened")?

https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d
 ?
https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8
 ?

Or something else?

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] fido -> jethro switching problem

2016-01-18 Thread Koen Kooi 

> Op 18 jan. 2016, om 09:28 heeft Steffen Sledz  het 
> volgende geschreven:
> 
> On 15.01.2016 15:29, Koen Kooi wrote:
>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz  het 
>>> volgende geschreven:
>>> It seems that all machines based on armv5e are affected.
>> 
>> FWIW, I'm seeing the same problem. The last time it happened it was due to 
>> the fixup angstrom does for broken arm BSPs
> 
> What commits do you talking about ("last time it happened")?
> 
> https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d
>  ?
> https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8
>  ?
> 
> Or something else?

Yes, those ones. 

regards,

Koen

> 
> -- 
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] fido -> jethro switching problem

2016-01-18 Thread Steffen Sledz 
On 18.01.2016 09:41, Koen Kooi wrote:
>> Op 18 jan. 2016, om 09:28 heeft Steffen Sledz  het 
>> volgende geschreven:
>> On 15.01.2016 15:29, Koen Kooi wrote:
 Op 15 jan. 2016 om 15:26 heeft Steffen Sledz  het 
 volgende geschreven:
 It seems that all machines based on armv5e are affected.
>>>
>>> FWIW, I'm seeing the same problem. The last time it happened it was due to 
>>> the fixup angstrom does for broken arm BSPs
>>
>> What commits do you talking about ("last time it happened")?
>>
>> https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d
>>  ?
>> https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8
>>  ?
>>
>> Or something else?
> 
> Yes, those ones. 

If I understand right you only introduced an own DEFAULTUNE override for 
angstrom to work around the problem. Right?

Did you identify the parts of meta-fsl-arm which were responsible for these 
problems?

Steffen

PS: Hi Otavio, I've added you to this discussion as the official meta-fsl-arm 
maintainer.

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] fido -> jethro switching problem

2016-01-18 Thread Koen Kooi 


> Op 18 jan. 2016 om 11:10 heeft Steffen Sledz  het 
> volgende geschreven:
> 
> On 18.01.2016 09:41, Koen Kooi wrote:
>>> Op 18 jan. 2016, om 09:28 heeft Steffen Sledz  het 
>>> volgende geschreven:
>>> On 15.01.2016 15:29, Koen Kooi wrote:
> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz  het 
> volgende geschreven:
> It seems that all machines based on armv5e are affected.
 
 FWIW, I'm seeing the same problem. The last time it happened it was due to 
 the fixup angstrom does for broken arm BSPs
>>> 
>>> What commits do you talking about ("last time it happened")?
>>> 
>>> https://github.com/Angstrom-distribution/meta-angstrom/commit/7f3d898930077710dfa42150882bce60d437af7d
>>>  ?
>>> https://github.com/Angstrom-distribution/meta-angstrom/commit/4b2e8ecb9a82109022727f6d80b8db56ae493fe8
>>>  ?
>>> 
>>> Or something else?
>> 
>> Yes, those ones.
> 
> If I understand right you only introduced an own DEFAULTUNE override for 
> angstrom to work around the problem. Right?

right

> 
> Did you identify the parts of meta-fsl-arm which were responsible for these 
> problems?

The machine includes that tune to cortex-foo instead of armvX. I don't need 5 
different versions of bash for 5 'different' armv7 machines.

> 
> Steffen
> 
> PS: Hi Otavio, I've added you to this discussion as the official meta-fsl-arm 
> maintainer.
> 
> -- 
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] fido -> jethro switching problem

2016-01-18 Thread Koen Kooi 

> Op 18 jan. 2016, om 12:55 heeft Steffen Sledz  het 
> volgende geschreven:
> 
> On 15.01.2016 15:29, Koen Kooi wrote:
>>> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz  het 
>>> volgende geschreven:
 On 15.01.2016 14:24, Steffen Sledz wrote:
 And I made another interesting discovery: The exception appears on certain 
 machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 
 not.
>>> 
>>> It seems that all machines based on armv5e are affected.
>> 
>> FWIW, I'm seeing the same problem. The last time it happened it was due to 
>> the fixup angstrom does for broken arm BSPs
> 
> I've identified this line from 
> meta-angstrom/conf/distro/include/angstrom.inc[1] as "trigger" for the 
> exception in the way, that commenting out this line avoids the exception.
> 
> --> snip <
> # Add FEED_ARCH to machine overrides so we get access to e.g. 'armv7a' and 
> 'sh4'
> # Hopefully we'll never see a machine or arch with 'all' as substring
> MACHINEOVERRIDES .= ":${@bb.data.getVar('FEED_ARCH', 
> d,1).replace('all','noarch')}"
> --> snip <

So that bit doesn’t do what it says it does anymore, this diff after removing 
it:

-# $MACHINEOVERRIDES [10 operations]
+# $MACHINEOVERRIDES [9 operations]
 #   set? /build/v2015.12/sources/openembedded-core/meta/conf/bitbake.conf:688
 # "${MACHINE}"
 #   set /build/v2015.12/sources/openembedded-core/meta/conf/bitbake.conf:689
@@ -9106,15 +9106,13 @@
 # "${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" ,d)}"
 #   predot 
/build/v2015.12/sources/openembedded-core/meta/conf/machine/include/arm/arch-armv4.inc:13
 # "${@bb.utils.contains("TUNE_FEATURES", "armv4", "armv4:", "" ,d)}"
-#   postdot 
/build/v2015.12/sources/meta-angstrom/conf/distro/include/angstrom.inc:30
-# ":${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}"
 #   append 
/build/v2015.12/sources/meta-angstrom/conf/distro/include/angstrom-core-tweaks.inc:27
 # [vardepsexclude] "SOC_FAMILY"
 #   set 
/build/v2015.12/sources/openembedded-core/meta/conf/documentation.conf:282
 # [doc] "Lists overrides specific to the current machine. By default, this 
list includes the value of MACHINE."
 # pre-expansion value:
-#   "${@bb.utils.contains("TUNE_FEATURES", "armv4", "armv4:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv6", "armv6:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv7a", "armv7a:", "" ,d)}${@['', 
'${SOC_FAMILY}:']['${SOC_FAMILY}' != 
'']}${MACHINE}:${@bb.data.getVar('FEED_ARCH', d,1).replace('all','noarch')}"
-MACHINEOVERRIDES="armv7a:ti33x:beaglebone:armv7at2hf-vfp-neon"
+#   "${@bb.utils.contains("TUNE_FEATURES", "armv4", "armv4:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv5", "armv5:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv6", "armv6:", "" 
,d)}${@bb.utils.contains("TUNE_FEATURES", "armv7a", "armv7a:", "" ,d)}${@['', 
'${SOC_FAMILY}:']['${SOC_FAMILY}' != '']}${MACHINE}"
+MACHINEOVERRIDES=“armv7a:ti33x:beaglebone"

So ‘armv7a’ is already there, 'armv7at2hf-vfp-neon’ isn’t needed since that 
information is availble from MACHINE_FEATURES already. I’ll drop the bit in 
jethro and master.

Thanks for tracking this down!

regards,

Koen
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] fido -> jethro switching problem

2016-01-15 Thread Steffen Sledz 
On 15.01.2016 14:06, Richard Purdie wrote:
> On Fri, 2016-01-15 at 13:03 +0100, Steffen Sledz wrote:
>> Hi all,
>>
>> for our internal development we use the Angstrom distro with some
>> additional layers. Now we try to switch from fido to jethro branches
>> and hit a problem where we are overchallenged.
>>
>> Our local.conf contains
>>
>>   DISTRO_FEATURES_remove = "x11 wayland"
>>
>> what results in
> 
> The error you pasted means that your setup has some kind of circular
> override references in it.
> 
> Am I correct in understanding that you hit the same error regardless of
> the above line or not?

Some kind of.

If you look at my original post, with this line the exception is somewhat 
related to DISTRO_FEATURES. Without the line it is related to TUNE_FEATURES.

And I made another interesting discovery: The exception appears on certain 
machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 not.

And last but not least with fido we did not had any problems.

Regards,
Steffen

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] fido -> jethro switching problem

2016-01-15 Thread Richard Purdie 
On Fri, 2016-01-15 at 13:03 +0100, Steffen Sledz wrote:
> Hi all,
> 
> for our internal development we use the Angstrom distro with some
> additional layers. Now we try to switch from fido to jethro branches
> and hit a problem where we are overchallenged.
> 
> Our local.conf contains
> 
>   DISTRO_FEATURES_remove = "x11 wayland"
> 
> what results in

The error you pasted means that your setup has some kind of circular
override references in it.

Am I correct in understanding that you hit the same error regardless of
the above line or not? If so, that means the problem is probably
elsewhere in your configuration.

As an example of what would cause this kind of issue:

OVERRIDES = "${VAR1}:${VAR2}"

VAR1 = "VAL1"VAR2 = "VAL2"
VAR2_VAL2 = "VAL1"

So bitbake would try and expand OVERRIDES and get "VAL1:VAL2", that
would change the value of VAR2 to VAL1, making overrides "VAL1:VAL1",
hence VAR2 now becomes VAL2, so OVERRIDES changes and so on.

Rather than infinitely loop, the code exits. There isn't code in there
which tries to figure out the circular dependency path since that is
rather complicated and there can be multiple levels of indirection
rather than just the single level above.

You probably need to track down which OVERRIDES value is causing the
problem, then work through the usages of it to find the problem, or
instrument the code to see which values are changing and causing the
instability.

Cheers,

Richard









-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

[OE-core] fido -> jethro switching problem

2016-01-15 Thread Steffen Sledz 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi all,

for our internal development we use the Angstrom distro with some additional 
layers. Now we try to switch from fido to jethro branches and hit a problem 
where we are overchallenged.

Our local.conf contains

  DISTRO_FEATURES_remove = "x11 wayland"

what results in

- --> snip <-
ERROR: Overrides could not be expanded into a stable state after 5 iterations, 
overrides must be being referenced by other overridden variables in some 
recursive fashion. Please provide your configuration to bitbake-devel so we can 
laugh, er, I mean try and understand how to make it work.
ERROR: Error parsing configuration files
Traceback (most recent call last):
  File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/parse/ast.py", line 88, in 
DataNode.getFunc(key='DISTRO_FEATURES', data=):
 else:
>return data.getVar(key, False, noweakdefault=True, 
parsing=True)

  File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 565, 
in DataSmart.getVar(var='DISTRO_FEATURES', expand=False, noweakdefault=True, 
parsing=True):
 def getVar(self, var, expand=False, noweakdefault=False, 
parsing=False):
>return self.getVarFlag(var, "_content", expand, noweakdefault, 
parsing)

  File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 737, 
in DataSmart.getVarFlag(var='DISTRO_FEATURES', flag='_content', expand=False, 
noweakdefault=True, parsing=True):
 removes = []
>self.need_overrides()
 for (r, o) in local_var["_remove"]:
  File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 435, 
in DataSmart.need_overrides():
 else:
>bb.fatal("Overrides could not be expanded into a stable state 
after 5 iterations, overrides must be being referenced by other overridden 
variables in some recursive fashion. Please provide your configuration to 
bitbake-devel so we can laugh, er, I mean try and understand how to make it 
work.")

  File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/__init__.py", line 102, in 
fatal:
 logger.critical(''.join(args), extra=kwargs)
>raise BBHandledException()

BBHandledException
- --> snap <-

And also if we remove this line we end in a similar exception

- --> snip <-
ERROR: Overrides could not be expanded into a stable state after 5 iterations, 
overrides must be being referenced by other overridden variables in some 
recursive fashion. Please provide your configuration to bitbake-devel so we can 
laugh, er, I mean try and understand how to make it work.
ERROR: Unable to parse DEFAULTTUNE_angstrom[:=]
Traceback (most recent call last):
  File "arm-defaults.inc", line 2, in 
arm_tune_handler(d=)
  File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 565, 
in DataSmart.getVar(var='TUNE_FEATURES', expand=True, noweakdefault=False, 
parsing=False):
 def getVar(self, var, expand=False, noweakdefault=False, 
parsing=False):
>return self.getVarFlag(var, "_content", expand, noweakdefault, 
parsing)

  File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 667, 
in DataSmart.getVarFlag(var='TUNE_FEATURES', flag='_content', expand=True, 
noweakdefault=False, parsing=False):
 active = {}
>self.need_overrides()
 for (r, o) in self.overridedata[var]:
  File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/data_smart.py", line 435, 
in DataSmart.need_overrides():
 else:
>bb.fatal("Overrides could not be expanded into a stable state 
after 5 iterations, overrides must be being referenced by other overridden 
variables in some recursive fashion. Please provide your configuration to 
bitbake-devel so we can laugh, er, I mean try and understand how to make it 
work.")

  File "/home/sledz/work/HIPOS.jethro/bitbake/lib/bb/__init__.py", line 102, in 
fatal:
 logger.critical(''.join(args), extra=kwargs)
>raise BBHandledException()

ExpansionError: Failure expanding variable DEFAULTTUNE_angstrom[:=], expression 
was ${@arm_tune_handler(d)} which triggered exception BBHandledException:
- --> snap <-

Can someone give some hints what's going wrong here?

Additional info:
BitBake Build Tool Core version 1.28.0
angstrom-v2015.12-yocto2.0 67032251d761f0107322a85595062029b95d788d

Thx,
Steffen

- -- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
-BEGIN PGP SIGNATURE-
Version: GnuPG v2

iQIcBAEBAgAGBQJWmOACAAoJEIz5slJ1krPhgBoP+gJvuy3bu3s+jC8OvXholWTF

Re: [OE-core] fido -> jethro switching problem

2016-01-15 Thread Koen Kooi 


> Op 15 jan. 2016 om 15:26 heeft Steffen Sledz  het 
> volgende geschreven:
> 
>> On 15.01.2016 14:24, Steffen Sledz wrote:
>> And I made another interesting discovery: The exception appears on certain 
>> machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 
>> not.
> 
> It seems that all machines based on armv5e are affected.

FWIW, I'm seeing the same problem. The last time it happened it was due to the 
fixup angstrom does for broken arm BSPs


> 
> -- 
> DResearch Fahrzeugelektronik GmbH
> Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
> Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
> Fax: +49 30 515932-299
> Geschäftsführer: Dr. Michael Weber, Werner Mögle;
> Amtsgericht Berlin Charlottenburg; HRB 130120 B;
> Ust.-IDNr. DE273952058
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] fido -> jethro switching problem

2016-01-15 Thread Steffen Sledz 
On 15.01.2016 14:24, Steffen Sledz wrote:
> And I made another interesting discovery: The exception appears on certain 
> machine types only, e.g with qemuarm it appears, with qemuarm64 or qemux86 
> not.

It seems that all machines based on armv5e are affected.

-- 
DResearch Fahrzeugelektronik GmbH
Otto-Schmirgal-Str. 3, 10319 Berlin, Germany
Tel: +49 30 515932-237 mailto:sl...@dresearch-fe.de
Fax: +49 30 515932-299
Geschäftsführer: Dr. Michael Weber, Werner Mögle;
Amtsgericht Berlin Charlottenburg; HRB 130120 B;
Ust.-IDNr. DE273952058
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] fido -> jethro switching problem

2016-01-15 Thread Richard Purdie 
On Fri, 2016-01-15 at 15:26 +0100, Steffen Sledz wrote:
> On 15.01.2016 14:24, Steffen Sledz wrote:
> > And I made another interesting discovery: The exception appears on
> > certain machine types only, e.g with qemuarm it appears, with
> > qemuarm64 or qemux86 not.
> 
> It seems that all machines based on armv5e are affected.

Which is a good data point to have and should help narrow it down.

I know that jethro OE-Core doesn't do this. Its unlikely to be machine
specific if all armv5e including qemuarm are affected. It therefore
sounds like there is something in your distro config related to armv5
is likely the cause...

Cheers,

Richard

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core