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 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
Best Regards Ulf Samuelsson u...@emagii.com +46 (722) 427 437 23 okt 2013 kl. 18:30 skrev Björn Krombholz : > 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
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
On Sun, Oct 20, 2013 at 2:49 PM, Ulf Samuelsson wrote: > > > 20 okt 2013 kl. 21:04 skrev Koen Kooi : > >> 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
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
Op 21 okt. 2013, om 10:00 heeft Ulf Samuelsson het volgende geschreven: > On 2013-10-21 07:52, Koen Kooi wrote: >> Op 20 okt. 2013, om 23:49 heeft Ulf Samuelsson het >> volgende geschreven: >> >>> >>> 20 okt 2013 kl. 21:04 skrev Koen Kooi : >>> 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://l
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 het volgende geschreven: 20 okt 2013 kl. 21:04 skrev Koen Kooi : 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 03:20 heeft Philip Balister het volgende geschreven: > On 10/20/2013 05:49 PM, Ulf Samuelsson wrote: >> >> >> 20 okt 2013 kl. 21:04 skrev Koen Kooi : >> >>> 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
Op 20 okt. 2013, om 23:49 heeft Ulf Samuelsson het volgende geschreven: > > > 20 okt 2013 kl. 21:04 skrev Koen Kooi : > >> 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
On 10/20/2013 05:49 PM, Ulf Samuelsson wrote: > > > 20 okt 2013 kl. 21:04 skrev Koen Kooi : > >> 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
Re: [Angstrom-devel] v2013.06 and v2013.12 architecture change for ARMv7A machines
20 okt 2013 kl. 21:04 skrev Koen Kooi : > 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
[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