Hard vs soft floating point architecture
Closed this issue · 4 comments
Hi,
the kernel being baked into the image is for an ARMv6, which means there are no floating point instruction sets for the RevPi Core 1. Still the image being shipped is armhf... this causes problems with the architecture of self created debian packages and the corresponding ABI of the compiled binaries. The latter has to be gnueabi, the former to apease the debian package manager gnueabihf, since we are talkinkg about a armhf image.
Running a application compiled for armhf (gnueabihf), making use of the floating point instruction set results in segfaults. Currently we're working around the issue by emulating fp operations in the program itself and shipping a arm (gnueabi) version as a binary in a armhf debian package... its a little messy.
Are we the only ones having this issue?
Any chance of fixing this, considering Core3 is the currently sold product (we happen to have only one Core1, everything else is Core3)
Best regards,
lwk
The BCM2835 CPU on the RevPi Core 1 implements ARMv6 with VFP2 floating point support.
The BCM2837 CPU on the RevPi Core 3 implements ARMv7.
Debian's armhf port is compiled for ARMv7 with VFP3. It can be run on the Core 3, but not the Core 1.
Debian's armel port is compiled for ARMv4 with software-emulated floating point support. It runs on the Core 1 but is unnecessarily slow. (See Debian Wiki.)
Raspbian is a recompiled version of all the Debian packages for the BCM2835's ARMv6+VFP2 flavor. It makes optimal use of the BCM2835's capabilities, but doesn't use the BCM2837 in the Core 3 to its full potential. Our image is based on Raspbian. Unfortunately the Foundation does not provide separate Raspbian images for the BCM2835 and BCM2837.
It is not correct that "the kernel being baked into the image is for an ARMv6": The image contains two kernels, one for the Core 1 and another for the Core 3. The former is compiled for ARMv6, the latter for ARMv7. However all of the user land is compiled for ARMv6 only. And even though the kernel is compiled for ARMv7, it does not use the BCM2837's 64-bit support.
If you need to install custom deb-packages, be sure to build them on Raspbian (either on a RevPi or with qemu) so that they are compiled and linked against Raspbian's ARMv6+VFP2 flavor. This will avoid the segfaults you were seeing. If you're missing certain packages in Raspbian which are otherwise available in Debian, clone their source repositories and use dpkg-buildpackage to compile against ARMv6+VFP2.
If you need maximum performance on the Core 3, you could in principle use an Armbian 64-bit image. The problem is that even though you'll be able to use all the nice 64-bit and Neon features, driver support for the peripherals may be worse than with the 32-bit Raspbian kernel. (E.g. some of the optimizations for the USB host controller are only available on 32-bit if I recall correctly.)
Thank your very much for the valuable insight. Now I understand the conundrum.
I'll try to fix our problem by fiddling with the gcc linker's flags in an attempt to cross-compile against the VFP extensions. We are currently cross compiling from x86_64 desktops, which is a must if we want to get any work done. If we find a solution that does not involve compiling directly on a raspian, we'll post it here. In the meantime I think your shedding of light into the issue will have to satisfy the scope of this issue.
Again thanks! and thank you guys for the wonderful work you are doing!
Best regards,
lwk
We are currently cross compiling from x86_64 desktops, which is a must if we want to get any work done.
Understandable. One solution is to mount a Raspbian image on an x86_64 machine (as a loop device) and copy /usr/bin/qemu-arm-static to the /usr/bin directory of the image. Then you can start a shell with chroot <mountpoint> /bin/bash and compile your sources. On Debian, the qemu-arm-static binary is part of the qemu-user-static package (binfmt-support is also required). imagebakery is doing exactly that since commit 1d4ccb4.
Good idea! Thank you for the suggestion. Much appreciated.