Slackware ARM - FAQ - soft float and hard float
Q. Why is Slackware a soft float port?
A. Slackware ARM (or 'ARMedslack' as it was previously known) was developed in 2002 when the only ARM devices on the market were soft float. It's only in recent years - 2009, 2010 that hard float machines became main stream. For Slackware ARM to have a hard float port is an entirely new port. alienBOB of the Slackware Core Team began a hard float port. The progress he made has been made public. However, porting Slackware is no trivial task - it's a *lot* of work. A few people have started and have not continued. Q. Do I need hard float? Not necessarily. If you are using your ARM device for multi media (video, audio) then it you really do need it otherwise the performance will not be optimal, or be unviewable or have stuttering audio. However, if you are not using your ARM device for multi media then you don't need hard float - it won't make much difference to use a soft float distribution. Q. Can I recompile some of the packages in Slackware ARM to be hard float and leave the rest as Soft Float? Yes! Have a look through this article that explains about rebuilding some of the core components to use hard float: http://mindplusplus.wordpress.com/20...-raspberry-pi/ Q. Do I need to recompile my kernel to be hard float? No. The kernels are compiled to support the architectures selected (e.g. ARMv7 Tegra, armv6 Broadcom). When selecting the support you will either choose which features to support, or they will be baked into the CPU type anyway. So yes, if the CPU contains hardware floating point support, your kernel will be hard float. See this discussion for more information: http://www.linuxquestions.org/questi...at-4175495652/ |
Quote:
If you're going to compile your own kernel there are still a few selections that you are left to choose and that influence how your kernel is going to deal with floating point calculations: Code:
System Type Now the help messages in the "Floating Point Emulation" section can cause further confusion but to my understanding NWFPE and FastFPE make the kernel do software floating point while VFP-format is the means by which floating point calculations are passed to FPU. As Stuart has said in other posts ... If the usernald has divorced from hardfloat the kernel will never be asked to perform hardfloat calculations. |
To conclude this thread:
* Slackware ARM 14.2 is "soft float" and is the last and final version of the soft float port that is maintained. * Following on from the 14.2 release, all future releases will be hardware floating point. * Slackware ARM "current" is hardware floating point. |
Sorry drMozes:
so this effectively means: besides kernel's FP emulation being disabled, nothing prevents the OS to boot on an FP-less host? And other than that, only select packages make use of FP anyway? This reminds to the MMX era and MPlayer from scratch? So an wary owner of an sub-v7 CPU could theoretically still get an post 14.2 to run, but at the cost of rolling their own? Not exactly Linux From Scratch, but a rather far cry from out of the box? |
Quote:
The user land is now using the hard float ABI. It cannot run binaries from the 14.2 soft float. Code:
# Hard float bash: Quote:
As you can see, this is impossible. Quote:
Not that I have any prescience about the demise of the software floating support in ARM, but I've written about why I dropped the soft float port: summary - ARM community is small (for all distributions) and incredibly fragmented. Unless the masses are still using soft float OS or hardware that does not have FPU, the soft float port dies out of lack of use and maintenance. It happened with the 'old ABI' (Slackware/armedslack <=12.2), happened with the Mozilla suite. You either keep up with the pack, try and support yourself or die off. It's just economics and numbers of contributors. |
Member response
Hi,
drmozes, will you be doing a 64Bit for SlackwareARM? I posted; First 64-Bit and Enterprise OS Comes to Raspberry Pi 3 Just wondering if you know of anyone working on a SlackwareARM64? Thanks for all the Slackware ARM work. :hattip: |
Have a look at this thread.
|
Member response
Hi,
Quote:
|
Quote:
I've spent several hours just hacking around getting two Orange Pi boards supported, and trawling through mailing lists looking for hints as to whether anyone else'd come across the same issues. I'd probably look at 64bit properly once and only once hard float is coming towards end of life upstream, as soft float did. |
^_^ looking forward to either (and to help if I can)
Kudos to longtime (longer than me) fellow slackers :hattip: |
Quote:
Quote:
The SARPi Project was initially conceived from much the same vision of 'what could be'. A friend and I first discussed Slackware ARM on a Raspberry Pi in 2011 - quite a few months before the device became publicly available. We started out with not much more than a dream and a head full of ideas, and took on the seemingly monumental task of turning those fanciful speculations into a reality. What you see now from the SARPi Project is the result of a lot of invested time, hard work, and the help/assistance of many, many people over the past +4 years. When you have a clear vision of your goal(s), as we did, it does not matter how long or difficult the road might be in order to accomplish them. If you want to achieve and be successful then you need to have faith in your hopes, aspirations, and especially your dreams. I haven't yet given up on my dreams. |
@drmozes & all
It's an old topic but my actual problems are very on-topic, no need to start a new thread I guess. I'm trying to get a lately unused (just attracting dust on my desk) Raspberry Pi0 1.3 as a multimedia device running Kodi and got entangled into the arm philosophy (sorry, can't call it science, not yet). In short, I'm about to recompile the Slackware ARM 14.2 (or maybe better the ARM current) system libs (some of them that Kodi depends on) with the compiler flags: -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard, in order to get them optimized for the Pi0. I'm still not sure if my Raspberry official kernel 4.4.50+ natively supports hard float calls, if my newly compiled libs will still be able to work for some other programs that depend on them and if the hard float emulation -mfloat-abi=softfp is not worse than just the actual -mfloat-abi=soft from performance perspective. Furthermore, the compiler that comes with Slackware arm 14.2 doesn't seem to have the necessary libraries to compile with the -mfloat-abi=hard flag. Just by testing, trying to compile openvpn with hard-float support I got into this compiler error: libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-lz4.lo -MD -MP -MF .deps/compat-lz4.Tpo -c compat-lz4.c -fPIC -DPIC -o .libs/compat-lz4.o In file included from /usr/include/features.h:392:0, from /usr/include/stdlib.h:24, from compat-lz4.c:112: /usr/include/gnu/stubs.h:10:29: fatal error: gnu/stubs-hard.h: No such file or directory compilation terminated. Adding to my confusion were these old answers: Your statement: _______ Q. Can I recompile some of the packages in Slackware ARM to be hard float and leave the rest as Soft Float? Yes! Have a look through this article that explains about rebuilding some of the core components to use hard float: https://mindplusplus.wordpress.com/2...-raspberry-pi/ _________ - the Debian arm wiki (the most complete info I could get ATM) explains that softfp, while implemented for compatibility, is worse than soft from performance perspective: https://wiki.debian.org/ArmHardFloatPort/VfpComparison And: Your statement: ________ No, it's different. The Kernel has no link to the user space in this regard. For example, the armv7 kernel in 14.2 has no floating point emulation in it and the 14.2 Kernel was used to boot strap the hard float port. _______ - according to this, the kernel should also have support for vfp calls: https://raspberrypi.stackexchange.co...es-on-a-soft-f Now, I got Kodi and all the dependencies compiled and packed (slack packages) on a Pi2B with: -march=armv6zk -mtune=arm1176jzf-s -mfloat-abi=soft moved them to my Pi0 running the official soft float Slack arm 14.2 & Raspberry's official kernel 4.4.50+ and got everything running almost perfect. Almost, because of some performance issues, frame drops, high IRQ count (8000 on pi0 Soft Float compared to 1500 on Pi2 Hard Float), and stalls with 100% CPU usage, issues that the Pi2 (having the same GPU, I reckon, armv7 is a little faster than armv6) handles without any issues under Hard Float binaries/libs/kernel on one core. Interestingly, when I booted the official Raspbian Image on my Pi0, in order to nick the kernel headers, I got the 4.4.50-v7+ loaded and I'm not sure why under Slackware ARM 14.2 I get the 4.4.50+ I know that there are some routines in the booting sequence of the Pi (the code that gets loaded by the GPU) that check the system architecture and are loading an appropriate kernel, but are these routines also mounting the root partition and checking how init was compiled ? weird... https://raspberrypi.stackexchange.co...kernel-to-load I would be more than thankful if you could be so kind and with your actual knowledge&experience shed some light over the dark maze I'm lost in and maybe also help me consider arm a science and not a philosophy ;) |
Quote:
This is not what's colloquially called "hard float" - where the entire OS is built using the hardware floating point ABI, which is incompatible with the software floating point ABI. This URL is now dead, but it was using softfp. Quote:
Quote:
I knew what the h/w floating point emulation did in the original ARMedslack back in 2005, where a Kernel module emulated a hardware floating point unit, and trapped the kernel exceptions, but I don't know what CONFIG_VFP does without reading more about it. However, I am talking about the difference between the distinction between the user land ABI and the Kernel -- where as, as far as I know (without further reading), there's no link. The "hardware floating point" (currently only in Slackware ARM current) refers to the OS/user land being compiled to use the hardware floating point ABI, and nothing more. The single Kernel supplied supports the SoC's that use armv7 and the FPU instructions. Even though the Kernel config for the armv7 Kernel within 14.2 supports it: Code:
root@wizbit:~/armedslack/slackwarearm-14.2/source/k/configs# egrep '^CON.*NEON|^CON.*VFP' config-armv7 For a multimedia machine on one of these Raspberry Pi's that has a CPU <armv7, I'd use Raspbian since the OS is built to use the hardware floating point unit. |
@drmozes
Many thanks for your quick reply! I just got the latest openvpn compiled under Slackware ARM current on one of my Pi2B with: -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard Created a slack package, moved the package over to the Pi0 running Slackware 14.2 SoftFloat, installed it and launched openvpn just to see it not being recognized by the system: readelf -A /usr/local/sbin/openvpn Attribute Section: aeabi File Attributes Tag_CPU_name: "7-A" Tag_CPU_arch: v7 Tag_CPU_arch_profile: Application Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-2 Tag_FP_arch: VFPv3-D16 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_rounding: Needed Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: int Tag_ABI_VFP_args: VFP registers Tag_CPU_unaligned_access: v6 Tag_Virtualization_use: TrustZone While the compiler from the official Slackware ARM 14.2 soft float is broken, it cannot create HardFloat code, I was using the compiler from Slack ARM current under a Pi2B box and as I see now I got the arm v7 code generated instead of armv6 when using -mfpu=vfp -mfloat-abi=hard The VFP code Tag_FP_arch: VFPv3-D16 looks good though for the arm v6 architecture... The link is not dead but it was me pasting a truncated one (corrected now in my post) and indeed it was using softfp emulation: https://mindplusplus.wordpress.com/2...-raspberry-pi/ On your Raspbian recommendation for < armv7, thank you, but no thank you. I already got banned from the Raspbian Forum by not accepting their Debian offer (forced down my throat) and loving Slack so much :) Not to mention I need to get used with systemd! I was looking at Gentoo for my Pi0, as they have HardFloat support for armv6, but learned that I have to compile the whole stuff and then thought - why not doing it with Slackware then? I'm not sure what to make of this Pi0 (apart from throwing it away) and it's not only multimedia I'm looking after, but also a small VPN box as an alternative. On armv7 HardFloat with AES256 I get a throughput around 30Mbps on one core and with armv6 SoftFloat it's 5Mbit, useless. |
It looks like the compiler from Slackware ARM current (with the latest updates) is also unable to generate armv6 code when -mfpu=vfp -mfloat-abi=hard flags are used. Native armv7 code is created instead.
In my first attempt to get openvpn compiled for armv6 I manually modified the CFLAGS section of the Makefiles. I'm doing this usually with configure scripts that don't have an option for compiler flags and also don't like environmental compiler variables. Now, in my second attempt I just used CFLAGS env variables and although the compilation itself used them, like it did before with the modified Makefiles, the generated bin is still native armv7: export CFLAGS="$CFLAGS -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard" echo $CFLAGS -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard ./configure --disable-server --disable-plugins --disable-management --disable-multihome --disable-port-share --enable-small --enable-iproute2 --disable-plugin-auth-pam --disable-plugin-down-root --disable-pf - the Makefiles contain: CFLAGS = -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard make -j 4 V=1 .... /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-dirname.lo -MD -MP -MF .deps/compat-dirname.Tpo -c -o compat-dirname.lo compat-dirname.c /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-basename.lo -MD -MP -MF .deps/compat-basename.Tpo -c -o compat-basename.lo compat-basename.c /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-gettimeofday.lo -MD -MP -MF .deps/compat-gettimeofday.Tpo -c -o compat-gettimeofday.lo compat-gettimeofday.c /bin/sh ../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../.. -I../../include -g -O2 -std=c99 -march=armv6zk -mtune=arm1176jzf-s -mfpu=vfp -mfloat-abi=hard -MT compat-daemon.lo -MD -MP -MF .deps/compat-daemon.Tpo -c -o compat-daemon.lo compat-daemon.c .... make install DESTDIR=/tmp/build readelf -A /tmp/build/usr/local/sbin/openvpn Attribute Section: aeabi File Attributes Tag_CPU_name: "7-A" Tag_CPU_arch: v7 Tag_CPU_arch_profile: Application Tag_ARM_ISA_use: Yes Tag_THUMB_ISA_use: Thumb-2 Tag_FP_arch: VFPv3-D16 Tag_ABI_PCS_wchar_t: 4 Tag_ABI_FP_rounding: Needed Tag_ABI_FP_denormal: Needed Tag_ABI_FP_exceptions: Needed Tag_ABI_FP_number_model: IEEE 754 Tag_ABI_align_needed: 8-byte Tag_ABI_align_preserved: 8-byte, except leaf SP Tag_ABI_enum_size: int Tag_ABI_VFP_args: VFP registers Tag_CPU_unaligned_access: v6 Tag_Virtualization_use: TrustZone Are there any other compiler options I need to tune or what compiler should I use to be able to both generate armv6 & armv7 HardFloat code ? Thanks in advance! |
All times are GMT -5. The time now is 05:12 PM. |