2011/4/11 Arjan van de Ven <ar...@linux.intel.com>: > On 4/11/2011 5:28 AM, Juha Kallioinen wrote: >> >> Hello, >> >> the hardfp floating point ABI for ARM will be made default and mandatory >> for MeeGo 1.2 and later. This decision was made and approved back in >> December 2010 in the MeeGo TSG and the impact has been described in MeeGo >> wiki [1]. >> >> The hardfp scheduler is called armv8el and is up and running in MeeGo >> Trunk. >> >> This change introduces an ABI break with MeeGo 1.1. The hardfp ABI is not >> compatible with the softfp ABI and because of this the packages produced by >> the armv8el scheduler have the architecture name .armv7hl. They cannot be >> installed in an armv7l system and vice versa. >> >> If you or your company run into problems with this changeover, feel free >> to seek help from #meego-arm @ freenode IRC channel or from the >> meego-porting mailing list [2]. > > can you, for completeness, list a set of ARM SOC's that this hardfp will run > on... > > omap3 > tegra? > qualcom ?
The baseline is armv7hl: -mfloat-abi=hard -mfpu=vfpv3-d16 -march=armv7-a -mno-thumb This matches SoCs such as - we've tested both with the help of ARM vendors themselves and people with boards: * OMAP3, OMAP4 (tested) * nVidia Tegra2 (tested) * Qualcomm ARMv7 chips should work with it (think it was tested) * ST-Ericsson U8500 (tested) * iMX.51 (tested) * Marvell Dove and others (tested) * etc. The baseline is practically similar to that of Debian armhf, http://wiki.debian.org/ArmHardFloatPort , except that we don't mandate thumb2/permit it for the baseline for compatibility reasons - subarchitectures give proper flexibility for NEON, Thumb2. This covers the largest set of ARMv7 chipsets available, including future Cortex-A5 (VFPv3 FPU option required though of this variant and ability to use NEON exists if provided by SoC). We've actually moved from VFPv3-D32 to VFPv3-D16 which means we support nVidia tegra2 and Marvell's chips now, which armv7l didn't before. > asking because if it's only omap3 then I think this is a step in the wrong > direction and we should revisit the TSG decision. That would indeed be a wrong direction and we do not optimize towards a specific chipset/SoC, as seen above - the hardfp port has been happily working on many different devices and enabling even more. We don't even tune for cortex-a8 as this makes gcc exhibit NEON instructions in some situations. As it's an ABI break, it does require a rebuild on top of the MeeGo toolchain of typical closed source binaries from the hardware vendor, which they would have to anyway, given Linaro and Debian's armhf directions. BR Carsten Munk > > _______________________________________________ > MeeGo-dev mailing list > MeeGo-dev@meego.com > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines > _______________________________________________ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
