Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
On Wed, 2013-10-23 at 18:30 +0200, Björn Krombholz wrote:
On 10/20/2013 09:04 PM, Koen Kooi wrote:
Then I noticed that the 'genericarmv7a' machine in meta-linaro set
the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set
that variable, but that's a different bug. It turns out that using
that tune we can have a single feed again for all armv7a machines.
Hi,
just for clarification, I'm not sure where to set it if not in the
MACHINE config without modifying meta-angstrom.
I've seen you added MACHINE specific DEFAULTTUNEs based on the currently
supported boards.
Basically the result should be (IMHO):
if MACHINE is a armv7a based and DISTRO is angstrom, then
DEFAULTTUNE = armv7athf-neon
Would it be possible to add those definitions based on SOC_FAMILY:
DEFAULTTUNE_ti33x and DEFAULTTUNE_omap3?
I hope so, see below.
As of now, when I add a new MACHINE=machfoo based on ti33x.inc from
meta-ti, I end up with a DEFAULTTUNE=armv7a-neon instead of the new one,
as the board is not known in meta-angstrom.
I added
DEFAULTTUNE_machfoo = ${DEFAULTTUNE_genericarmv7a}
to the machfoo.conf which is discouraged, if I understand you correctly.
Maybe I'm just missing the obvious safe way?
There is no obvious safe way :( You are running into the same problems
Khem and I ran into with the oe-core way of doing tune files.
This is a big problem and needs to get fixed somehow.
regards,
Koen
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
On 10/27/2013 12:53 PM, Koen Kooi wrote:
On Wed, 2013-10-23 at 18:30 +0200, Björn Krombholz wrote:
On 10/20/2013 09:04 PM, Koen Kooi wrote:
Then I noticed that the 'genericarmv7a' machine in meta-linaro set
the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set
that variable, but that's a different bug. It turns out that using
that tune we can have a single feed again for all armv7a machines.
Hi,
just for clarification, I'm not sure where to set it if not in the
MACHINE config without modifying meta-angstrom.
I've seen you added MACHINE specific DEFAULTTUNEs based on the currently
supported boards.
Basically the result should be (IMHO):
if MACHINE is a armv7a based and DISTRO is angstrom, then
DEFAULTTUNE = armv7athf-neon
Would it be possible to add those definitions based on SOC_FAMILY:
DEFAULTTUNE_ti33x and DEFAULTTUNE_omap3?
I hope so, see below.
As of now, when I add a new MACHINE=machfoo based on ti33x.inc from
meta-ti, I end up with a DEFAULTTUNE=armv7a-neon instead of the new one,
as the board is not known in meta-angstrom.
I added
DEFAULTTUNE_machfoo = ${DEFAULTTUNE_genericarmv7a}
to the machfoo.conf which is discouraged, if I understand you correctly.
Maybe I'm just missing the obvious safe way?
There is no obvious safe way :( You are running into the same problems
Khem and I ran into with the oe-core way of doing tune files.
This is a big problem and needs to get fixed somehow.
Can we get a good description of the problem in the Yocto Project Bugzilla?
Philip
regards,
Koen
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
On 10/20/2013 09:04 PM, Koen Kooi wrote:
Then I noticed that the 'genericarmv7a' machine in meta-linaro set
the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set
that variable, but that's a different bug. It turns out that using
that tune we can have a single feed again for all armv7a machines.
Hi,
just for clarification, I'm not sure where to set it if not in the
MACHINE config without modifying meta-angstrom.
I've seen you added MACHINE specific DEFAULTTUNEs based on the currently
supported boards.
Basically the result should be (IMHO):
if MACHINE is a armv7a based and DISTRO is angstrom, then
DEFAULTTUNE = armv7athf-neon
Would it be possible to add those definitions based on SOC_FAMILY:
DEFAULTTUNE_ti33x and DEFAULTTUNE_omap3?
As of now, when I add a new MACHINE=machfoo based on ti33x.inc from
meta-ti, I end up with a DEFAULTTUNE=armv7a-neon instead of the new one,
as the board is not known in meta-angstrom.
I added
DEFAULTTUNE_machfoo = ${DEFAULTTUNE_genericarmv7a}
to the machfoo.conf which is discouraged, if I understand you correctly.
Maybe I'm just missing the obvious safe way?
Thx
Björn
--
Björn Krombholz
pironex GmbH -- http://www.pironex.de
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
Best Regards
Ulf Samuelsson
u...@emagii.com
+46 (722) 427 437
23 okt 2013 kl. 18:30 skrev Björn Krombholz pir...@gmail.com:
On 10/20/2013 09:04 PM, Koen Kooi wrote:
Then I noticed that the 'genericarmv7a' machine in meta-linaro set
the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set
that variable, but that's a different bug. It turns out that using
that tune we can have a single feed again for all armv7a machines.
Hi,
just for clarification, I'm not sure where to set it if not in the MACHINE
config without modifying meta-angstrom.
I've seen you added MACHINE specific DEFAULTTUNEs based on the currently
supported boards.
Basically the result should be (IMHO):
if MACHINE is a armv7a based and DISTRO is angstrom, then
DEFAULTTUNE = armv7athf-neon
Since not all arm7va have neon. it is optional on Cortex-A5
and there are already arm7a chips without neon round,
so this is not a good idea.
Would it be possible to add those definitions based on SOC_FAMILY:
DEFAULTTUNE_ti33x and DEFAULTTUNE_omap3?
Better.
As of now, when I add a new MACHINE=machfoo based on ti33x.inc from meta-ti,
I end up with a DEFAULTTUNE=armv7a-neon instead of the new one, as the board
is not known in meta-angstrom.
I added
DEFAULTTUNE_machfoo = ${DEFAULTTUNE_genericarmv7a}
to the machfoo.conf which is discouraged, if I understand you correctly.
Maybe I'm just missing the obvious safe way?
Thx
Björn
--
Björn Krombholz
pironex GmbH -- http://www.pironex.de
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
Op 20 okt. 2013, om 23:49 heeft Ulf Samuelsson angstrom-...@emagii.com het volgende geschreven: 20 okt 2013 kl. 21:04 skrev Koen Kooi k...@dominion.thruhere.net: Hi, A while ago we decided to switch armv7a machines for hardfloat because we were worn it with explaining that there's no real world difference between softfp (which does use hw fp despite its name) and hardfp and silicon vendors started moving their evil binary only stuff to that as well. So we looked into it and set the DEFAULTTUNE to cortexa8hf-neon. That gave us a hardfp build and it had no regressions so far, so good. So how are Cortex-A5 chips without neon going to be handled? They are also armv7a! I'd say DEFAULTTUNE = armv7athf and a seperate feed. We did something similar in the 2011.03 release for the armv6-without-vfp chips. Been struggling with this, during the weekend, since some recipes assume hat if It is an arm7a, then Neon should be turned on. Those have to be converted to check TUNE_FEATURES for 'neon'. regards, Koen Best Regards Ulf Samuelsson u...@emagii.com Two weeks ago I switched jobs and had to dust off my pandaboards for the new job and that's were things starting going south. 'cortexa8hf-neon' didn't work since the buildsystem knew it was an cortex-A9 CPU, so 'cortexa9hf-neon' needed to be used. Again that built and worked. But it required two seperate feeds that were a single feed in v2012.12 and earlier. Then I started looking at cortex-A15 boards and realized this setup is wasting disk space and cpu time. Then I noticed that the 'genericarmv7a' machine in meta-linaro set the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set that variable, but that's a different bug. It turns out that using that tune we can have a single feed again for all armv7a machines. Yay! If you have been using v2013.06 and your architecture for the feeds is cortexa*hf*, try doing the following: opkg update ; opkg install angstrom-feed-configs opkg update ; opkg install opkg-config-base That will update the feed configs to point to the new unified feed and drag in the /etc/opkg/arch.conf that lists the new armv7ahf-vfp-neon architecture as supported. It will throw a ton of warnings for the currently installed packages, but that's mostly harmless. Installing things from the feeds will work again, but it will try to reinstall a lot of things due to the architecture change. The v2013.12 feed will be cleaned up later, all the conferences will interfere with that. It looks like the complete angstrom cabal will be present at ELC-E in Edinburgh next week and at least 3 of us will also be attending Linaro Connect USA the week after that. If you're in the neighbourhood come say hello and please tell us about your pet peeve with angstrom or OE and we'll try to address it. thanks, Koen ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
Op 21 okt. 2013, om 03:20 heeft Philip Balister phi...@balister.org het volgende geschreven: On 10/20/2013 05:49 PM, Ulf Samuelsson wrote: 20 okt 2013 kl. 21:04 skrev Koen Kooi k...@dominion.thruhere.net: Hi, A while ago we decided to switch armv7a machines for hardfloat because we were worn it with explaining that there's no real world difference between softfp (which does use hw fp despite its name) and hardfp and silicon vendors started moving their evil binary only stuff to that as well. So we looked into it and set the DEFAULTTUNE to cortexa8hf-neon. That gave us a hardfp build and it had no regressions so far, so good. So how are Cortex-A5 chips without neon going to be handled? They are also armv7a! A5 or A15? We need an arm decoder ring! A5, a budget version like the A7. To keep power consumption and die size down NEON is 'optional' on that core. regards, Koen Philip Been struggling with this, during the weekend, since some recipes assume hat if It is an arm7a, then Neon should be turned on. Best Regards Ulf Samuelsson u...@emagii.com Two weeks ago I switched jobs and had to dust off my pandaboards for the new job and that's were things starting going south. 'cortexa8hf-neon' didn't work since the buildsystem knew it was an cortex-A9 CPU, so 'cortexa9hf-neon' needed to be used. Again that built and worked. But it required two seperate feeds that were a single feed in v2012.12 and earlier. Then I started looking at cortex-A15 boards and realized this setup is wasting disk space and cpu time. Then I noticed that the 'genericarmv7a' machine in meta-linaro set the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set that variable, but that's a different bug. It turns out that using that tune we can have a single feed again for all armv7a machines. Yay! If you have been using v2013.06 and your architecture for the feeds is cortexa*hf*, try doing the following: opkg update ; opkg install angstrom-feed-configs opkg update ; opkg install opkg-config-base That will update the feed configs to point to the new unified feed and drag in the /etc/opkg/arch.conf that lists the new armv7ahf-vfp-neon architecture as supported. It will throw a ton of warnings for the currently installed packages, but that's mostly harmless. Installing things from the feeds will work again, but it will try to reinstall a lot of things due to the architecture change. The v2013.12 feed will be cleaned up later, all the conferences will interfere with that. It looks like the complete angstrom cabal will be present at ELC-E in Edinburgh next week and at least 3 of us will also be attending Linaro Connect USA the week after that. If you're in the neighbourhood come say hello and please tell us about your pet peeve with angstrom or OE and we'll try to address it. thanks, Koen ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
On 2013-10-21 07:52, Koen Kooi wrote:
Op 20 okt. 2013, om 23:49 heeft Ulf Samuelsson angstrom-...@emagii.com het
volgende geschreven:
20 okt 2013 kl. 21:04 skrev Koen Kooi k...@dominion.thruhere.net:
Hi,
A while ago we decided to switch armv7a machines for hardfloat because we were
worn it with explaining that there's no real world difference between softfp
(which does use hw fp despite its name) and hardfp and silicon vendors started
moving their evil binary only stuff to that as well. So we looked into it and
set the DEFAULTTUNE to cortexa8hf-neon. That gave us a hardfp build and it had
no regressions so far, so good.
So how are Cortex-A5 chips without neon going to be handled?
They are also armv7a!
I'd say DEFAULTTUNE = armv7athf and a seperate feed. We did something similar
in the 2011.03 release for the armv6-without-vfp chips.
Here is my tune-cortexa5.inc.
Can build systemd-gnome-image with this.
DEFAULTTUNE ?= cortexa5thf
# TUNE_FEATURES = armv7a vfp callconvention-hard
# TARGET_FPU= vfp
require conf/machine/include/arm/arch-armv7a.inc
TUNEVALID[cortexa5] = Enable Cortex-A5 specific processor optimizations
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, cortexa5,
-mtune=cortex-a5, , d)}
# Little Endian base configs
AVAILTUNES += cortexa5 cortexa5t
TUNE_FEATURES_tune-cortexa5 = ${TUNE_FEATURES_tune-armv7a} cortexa5
TUNE_FEATURES_tune-cortexa5t = ${TUNE_FEATURES_tune-armv7at} cortexa5
PACKAGE_EXTRA_ARCHS_tune-cortexa5 = ${PACKAGE_EXTRA_ARCHS_tune-armv7a}
PACKAGE_EXTRA_ARCHS_tune-cortexa5t = ${PACKAGE_EXTRA_ARCHS_tune-armv7at}
# VFP Tunes
AVAILTUNES += cortexa5hf cortexa5thf
TUNE_FEATURES_tune-cortexa5hf ?= ${TUNE_FEATURES_tune-armv7ahf} cortexa5
TUNE_FEATURES_tune-cortexa5thf ?= ${TUNE_FEATURES_tune-armv7athf} cortexa5
PACKAGE_EXTRA_ARCHS_tune-cortexa5hf = ${PACKAGE_EXTRA_ARCHS_tune-armv7ahf}
PACKAGE_EXTRA_ARCHS_tune-cortexa5thf =
${PACKAGE_EXTRA_ARCHS_tune-armv7athf}
Been struggling with this, during the weekend, since some recipes assume hat if
It is an arm7a, then Neon should be turned on.
Those have to be converted to check TUNE_FEATURES for 'neon'.
regards,
Koen
Best Regards
Ulf Samuelsson
u...@emagii.com
Two weeks ago I switched jobs and had to dust off my pandaboards for the new
job and that's were things starting going south. 'cortexa8hf-neon' didn't work
since the buildsystem knew it was an cortex-A9 CPU, so 'cortexa9hf-neon' needed
to be used. Again that built and worked. But it required two seperate feeds
that were a single feed in v2012.12 and earlier. Then I started looking at
cortex-A15 boards and realized this setup is wasting disk space and cpu time.
Then I noticed that the 'genericarmv7a' machine in meta-linaro set the
DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set that variable,
but that's a different bug. It turns out that using that tune we can have a
single feed again for all armv7a machines. Yay!
If you have been using v2013.06 and your architecture for the feeds is
cortexa*hf*, try doing the following:
opkg update ; opkg install angstrom-feed-configs
opkg update ; opkg install opkg-config-base
That will update the feed configs to point to the new unified feed and drag in
the /etc/opkg/arch.conf that lists the new armv7ahf-vfp-neon architecture as
supported. It will throw a ton of warnings for the currently installed
packages, but that's mostly harmless. Installing things from the feeds will
work again, but it will try to reinstall a lot of things due to the
architecture change.
The v2013.12 feed will be cleaned up later, all the conferences will interfere
with that.
It looks like the complete angstrom cabal will be present at ELC-E in Edinburgh
next week and at least 3 of us will also be attending Linaro Connect USA the
week after that. If you're in the neighbourhood come say hello and please tell
us about your pet peeve with angstrom or OE and we'll try to address it.
thanks,
Koen
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
Op 21 okt. 2013, om 10:00 heeft Ulf Samuelsson angstrom-...@emagii.com het
volgende geschreven:
On 2013-10-21 07:52, Koen Kooi wrote:
Op 20 okt. 2013, om 23:49 heeft Ulf Samuelsson angstrom-...@emagii.com het
volgende geschreven:
20 okt 2013 kl. 21:04 skrev Koen Kooi k...@dominion.thruhere.net:
Hi,
A while ago we decided to switch armv7a machines for hardfloat because we
were worn it with explaining that there's no real world difference between
softfp (which does use hw fp despite its name) and hardfp and silicon
vendors started moving their evil binary only stuff to that as well. So we
looked into it and set the DEFAULTTUNE to cortexa8hf-neon. That gave us a
hardfp build and it had no regressions so far, so good.
So how are Cortex-A5 chips without neon going to be handled?
They are also armv7a!
I'd say DEFAULTTUNE = armv7athf and a seperate feed. We did something
similar in the 2011.03 release for the armv6-without-vfp chips.
Here is my tune-cortexa5.inc.
Can build systemd-gnome-image with this.
DEFAULTTUNE ?= cortexa5thf
That's a DISTRO choice, the OE default is softfp, MACHINE.confs *really*
shouldn't be poking at that since it presents nasty suprises to people building
for multiple machines.
regards,
Koen
# TUNE_FEATURES = armv7a vfp callconvention-hard
# TARGET_FPU= vfp
require conf/machine/include/arm/arch-armv7a.inc
TUNEVALID[cortexa5] = Enable Cortex-A5 specific processor optimizations
TUNE_CCARGS += ${@bb.utils.contains(TUNE_FEATURES, cortexa5,
-mtune=cortex-a5, , d)}
# Little Endian base configs
AVAILTUNES += cortexa5 cortexa5t
TUNE_FEATURES_tune-cortexa5 = ${TUNE_FEATURES_tune-armv7a} cortexa5
TUNE_FEATURES_tune-cortexa5t = ${TUNE_FEATURES_tune-armv7at} cortexa5
PACKAGE_EXTRA_ARCHS_tune-cortexa5 = ${PACKAGE_EXTRA_ARCHS_tune-armv7a}
PACKAGE_EXTRA_ARCHS_tune-cortexa5t = ${PACKAGE_EXTRA_ARCHS_tune-armv7at}
# VFP Tunes
AVAILTUNES += cortexa5hf cortexa5thf
TUNE_FEATURES_tune-cortexa5hf ?= ${TUNE_FEATURES_tune-armv7ahf} cortexa5
TUNE_FEATURES_tune-cortexa5thf ?= ${TUNE_FEATURES_tune-armv7athf} cortexa5
PACKAGE_EXTRA_ARCHS_tune-cortexa5hf = ${PACKAGE_EXTRA_ARCHS_tune-armv7ahf}
PACKAGE_EXTRA_ARCHS_tune-cortexa5thf = ${PACKAGE_EXTRA_ARCHS_tune-armv7athf}
Been struggling with this, during the weekend, since some recipes assume
hat if
It is an arm7a, then Neon should be turned on.
Those have to be converted to check TUNE_FEATURES for 'neon'.
regards,
Koen
Best Regards
Ulf Samuelsson
u...@emagii.com
Two weeks ago I switched jobs and had to dust off my pandaboards for the
new job and that's were things starting going south. 'cortexa8hf-neon'
didn't work since the buildsystem knew it was an cortex-A9 CPU, so
'cortexa9hf-neon' needed to be used. Again that built and worked. But it
required two seperate feeds that were a single feed in v2012.12 and
earlier. Then I started looking at cortex-A15 boards and realized this
setup is wasting disk space and cpu time.
Then I noticed that the 'genericarmv7a' machine in meta-linaro set the
DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set that
variable, but that's a different bug. It turns out that using that tune we
can have a single feed again for all armv7a machines. Yay!
If you have been using v2013.06 and your architecture for the feeds is
cortexa*hf*, try doing the following:
opkg update ; opkg install angstrom-feed-configs
opkg update ; opkg install opkg-config-base
That will update the feed configs to point to the new unified feed and
drag in the /etc/opkg/arch.conf that lists the new armv7ahf-vfp-neon
architecture as supported. It will throw a ton of warnings for the
currently installed packages, but that's mostly harmless. Installing
things from the feeds will work again, but it will try to reinstall a lot
of things due to the architecture change.
The v2013.12 feed will be cleaned up later, all the conferences will
interfere with that.
It looks like the complete angstrom cabal will be present at ELC-E in
Edinburgh next week and at least 3 of us will also be attending Linaro
Connect USA the week after that. If you're in the neighbourhood come say
hello and please tell us about your pet peeve with angstrom or OE and
we'll try to address it.
thanks,
Koen
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
___
Angstrom-distro-devel mailing list
Angstrom-distro-devel@linuxtogo.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
On Sun, Oct 20, 2013 at 2:49 PM, Ulf Samuelsson angstrom-...@emagii.com wrote: 20 okt 2013 kl. 21:04 skrev Koen Kooi k...@dominion.thruhere.net: Hi, A while ago we decided to switch armv7a machines for hardfloat because we were worn it with explaining that there's no real world difference between softfp (which does use hw fp despite its name) and hardfp and silicon vendors started moving their evil binary only stuff to that as well. So we looked into it and set the DEFAULTTUNE to cortexa8hf-neon. That gave us a hardfp build and it had no regressions so far, so good. So how are Cortex-A5 chips without neon going to be handled? They are also armv7a! Been struggling with this, during the weekend, since some recipes assume hat if It is an arm7a, then Neon should be turned on. well then there is also Tegras and marvell stuff... we can not find a wholesome common denominator but we can find largest common denominator and thats the idea here. Best Regards Ulf Samuelsson u...@emagii.com Two weeks ago I switched jobs and had to dust off my pandaboards for the new job and that's were things starting going south. 'cortexa8hf-neon' didn't work since the buildsystem knew it was an cortex-A9 CPU, so 'cortexa9hf-neon' needed to be used. Again that built and worked. But it required two seperate feeds that were a single feed in v2012.12 and earlier. Then I started looking at cortex-A15 boards and realized this setup is wasting disk space and cpu time. Then I noticed that the 'genericarmv7a' machine in meta-linaro set the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set that variable, but that's a different bug. It turns out that using that tune we can have a single feed again for all armv7a machines. Yay! If you have been using v2013.06 and your architecture for the feeds is cortexa*hf*, try doing the following: opkg update ; opkg install angstrom-feed-configs opkg update ; opkg install opkg-config-base That will update the feed configs to point to the new unified feed and drag in the /etc/opkg/arch.conf that lists the new armv7ahf-vfp-neon architecture as supported. It will throw a ton of warnings for the currently installed packages, but that's mostly harmless. Installing things from the feeds will work again, but it will try to reinstall a lot of things due to the architecture change. The v2013.12 feed will be cleaned up later, all the conferences will interfere with that. It looks like the complete angstrom cabal will be present at ELC-E in Edinburgh next week and at least 3 of us will also be attending Linaro Connect USA the week after that. If you're in the neighbourhood come say hello and please tell us about your pet peeve with angstrom or OE and we'll try to address it. thanks, Koen ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
[Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
Hi, A while ago we decided to switch armv7a machines for hardfloat because we were worn it with explaining that there's no real world difference between softfp (which does use hw fp despite its name) and hardfp and silicon vendors started moving their evil binary only stuff to that as well. So we looked into it and set the DEFAULTTUNE to cortexa8hf-neon. That gave us a hardfp build and it had no regressions so far, so good. Two weeks ago I switched jobs and had to dust off my pandaboards for the new job and that's were things starting going south. 'cortexa8hf-neon' didn't work since the buildsystem knew it was an cortex-A9 CPU, so 'cortexa9hf-neon' needed to be used. Again that built and worked. But it required two seperate feeds that were a single feed in v2012.12 and earlier. Then I started looking at cortex-A15 boards and realized this setup is wasting disk space and cpu time. Then I noticed that the 'genericarmv7a' machine in meta-linaro set the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set that variable, but that's a different bug. It turns out that using that tune we can have a single feed again for all armv7a machines. Yay! If you have been using v2013.06 and your architecture for the feeds is cortexa*hf*, try doing the following: opkg update ; opkg install angstrom-feed-configs opkg update ; opkg install opkg-config-base That will update the feed configs to point to the new unified feed and drag in the /etc/opkg/arch.conf that lists the new armv7ahf-vfp-neon architecture as supported. It will throw a ton of warnings for the currently installed packages, but that's mostly harmless. Installing things from the feeds will work again, but it will try to reinstall a lot of things due to the architecture change. The v2013.12 feed will be cleaned up later, all the conferences will interfere with that. It looks like the complete angstrom cabal will be present at ELC-E in Edinburgh next week and at least 3 of us will also be attending Linaro Connect USA the week after that. If you're in the neighbourhood come say hello and please tell us about your pet peeve with angstrom or OE and we'll try to address it. thanks, Koen ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
20 okt 2013 kl. 21:04 skrev Koen Kooi k...@dominion.thruhere.net: Hi, A while ago we decided to switch armv7a machines for hardfloat because we were worn it with explaining that there's no real world difference between softfp (which does use hw fp despite its name) and hardfp and silicon vendors started moving their evil binary only stuff to that as well. So we looked into it and set the DEFAULTTUNE to cortexa8hf-neon. That gave us a hardfp build and it had no regressions so far, so good. So how are Cortex-A5 chips without neon going to be handled? They are also armv7a! Been struggling with this, during the weekend, since some recipes assume hat if It is an arm7a, then Neon should be turned on. Best Regards Ulf Samuelsson u...@emagii.com Two weeks ago I switched jobs and had to dust off my pandaboards for the new job and that's were things starting going south. 'cortexa8hf-neon' didn't work since the buildsystem knew it was an cortex-A9 CPU, so 'cortexa9hf-neon' needed to be used. Again that built and worked. But it required two seperate feeds that were a single feed in v2012.12 and earlier. Then I started looking at cortex-A15 boards and realized this setup is wasting disk space and cpu time. Then I noticed that the 'genericarmv7a' machine in meta-linaro set the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set that variable, but that's a different bug. It turns out that using that tune we can have a single feed again for all armv7a machines. Yay! If you have been using v2013.06 and your architecture for the feeds is cortexa*hf*, try doing the following: opkg update ; opkg install angstrom-feed-configs opkg update ; opkg install opkg-config-base That will update the feed configs to point to the new unified feed and drag in the /etc/opkg/arch.conf that lists the new armv7ahf-vfp-neon architecture as supported. It will throw a ton of warnings for the currently installed packages, but that's mostly harmless. Installing things from the feeds will work again, but it will try to reinstall a lot of things due to the architecture change. The v2013.12 feed will be cleaned up later, all the conferences will interfere with that. It looks like the complete angstrom cabal will be present at ELC-E in Edinburgh next week and at least 3 of us will also be attending Linaro Connect USA the week after that. If you're in the neighbourhood come say hello and please tell us about your pet peeve with angstrom or OE and we'll try to address it. thanks, Koen ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
On 10/20/2013 05:49 PM, Ulf Samuelsson wrote: 20 okt 2013 kl. 21:04 skrev Koen Kooi k...@dominion.thruhere.net: Hi, A while ago we decided to switch armv7a machines for hardfloat because we were worn it with explaining that there's no real world difference between softfp (which does use hw fp despite its name) and hardfp and silicon vendors started moving their evil binary only stuff to that as well. So we looked into it and set the DEFAULTTUNE to cortexa8hf-neon. That gave us a hardfp build and it had no regressions so far, so good. So how are Cortex-A5 chips without neon going to be handled? They are also armv7a! A5 or A15? We need an arm decoder ring! Philip Been struggling with this, during the weekend, since some recipes assume hat if It is an arm7a, then Neon should be turned on. Best Regards Ulf Samuelsson u...@emagii.com Two weeks ago I switched jobs and had to dust off my pandaboards for the new job and that's were things starting going south. 'cortexa8hf-neon' didn't work since the buildsystem knew it was an cortex-A9 CPU, so 'cortexa9hf-neon' needed to be used. Again that built and worked. But it required two seperate feeds that were a single feed in v2012.12 and earlier. Then I started looking at cortex-A15 boards and realized this setup is wasting disk space and cpu time. Then I noticed that the 'genericarmv7a' machine in meta-linaro set the DEFAULTTUNE to armv7athf-neon. A MACHINE config shouldn't set that variable, but that's a different bug. It turns out that using that tune we can have a single feed again for all armv7a machines. Yay! If you have been using v2013.06 and your architecture for the feeds is cortexa*hf*, try doing the following: opkg update ; opkg install angstrom-feed-configs opkg update ; opkg install opkg-config-base That will update the feed configs to point to the new unified feed and drag in the /etc/opkg/arch.conf that lists the new armv7ahf-vfp-neon architecture as supported. It will throw a ton of warnings for the currently installed packages, but that's mostly harmless. Installing things from the feeds will work again, but it will try to reinstall a lot of things due to the architecture change. The v2013.12 feed will be cleaned up later, all the conferences will interfere with that. It looks like the complete angstrom cabal will be present at ELC-E in Edinburgh next week and at least 3 of us will also be attending Linaro Connect USA the week after that. If you're in the neighbourhood come say hello and please tell us about your pet peeve with angstrom or OE and we'll try to address it. thanks, Koen ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel ___ Angstrom-distro-devel mailing list Angstrom-distro-devel@linuxtogo.org http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/angstrom-distro-devel
