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
>
>
> _______________________________________________
> 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
