Support for ARMV6 Architecture

[ergouser]

Using the develop-SNAPSHOT from Maven:

The Linux-ARM binary is ARMV7 on the Pi Zero this give you:

siginfo: si_signo: 4 (SIGILL), si_code: 1 (ILL_ILLOPC), si_addr: 0xa75b61f0

(oddly in one of the JNA stackframes) as the library loads.

Pi Zero (and the old Pi 1's) are ARMV6, not ARMV7 (all the later Pi's).

Pi ZERO:
$ cat /proc/cpuinfo
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 697.95
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7

Hardware : BCM2835
Revision : 9000c1
Serial : 0000000003492989
Model : Raspberry Pi Zero W Rev 1.1

The maven build for JNA is V6

$ arm-linux-gnueabihf-readelf -A com/sun/jna/linux-arm/libjnidispatch.so
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
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_enum_size: int
Tag_ABI_HardFP_use: Deprecated
Tag_ABI_VFP_args: VFP registers
Tag_CPU_unaligned_access: v6

I would suggest that the HID build could be the same, it's currently V7
$ arm-linux-gnueabihf-readelf -A libhidapi.so
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_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

[ergouser]

I would add that rebuilding the .so's for ARMv6 solved the ILL_ILOPC issue. I built them native on the Pi Zero from the libusb/hidapi repository so don't have suggestions for cross-compiling.

[tresf]

Gary uses dockcross for his builds.

What's a bit confusing to me is that the linux-armel profile claims to builds for V6 where as the linux-arm builds for V7, both seem to use hardware-floating-point tools to do so despite the armel being described as a "software-floating-point architecture"? Anyway, I'm not very familiar with the differences, but wanted to provide some insight into the build system Gary uses. Below are the relevant lines. I'm working through this build process for a snapshot I need for a project. I'm sure your fix is just a matter of tweaking one of the lines below, then you can send a pull request with the required change. :)

linux-armel

hid4java/build-hidapi.sh

Lines 224 to 227 in b1c3a6d

	if [[ "$1" == "all" ]] || [[ "$1" == "linux" ]] || [[ "$1" == "linux-armel" ]]
	then
	echo -e "\033[32mBuilding ARMv6 EABI\033[0m"
	dockcross-linux-armv6 bash -c 'sudo dpkg --add-architecture armhf && sudo apt-get update && sudo apt-get --yes install gcc-arm-linux-gnueabihf libudev-dev:armhf libusb-1.0-0-dev:armhf && sudo make clean && sudo ./bootstrap && sudo ./configure --host=arm-linux-gnueabihf && sudo make'

linux-arm

hid4java/build-hidapi.sh

Lines 244 to 247 in b1c3a6d

	if [[ "$1" == "all" ]] || [[ "$1" == "linux" ]] || [[ "$1" == "linux-arm" ]]
	then
	echo -e "\033[32mBuilding ARMv7 hard float\033[0m"
	dockcross-linux-armv7 bash -c 'sudo dpkg --add-architecture armhf && sudo rm -Rf /var/lib/apt/lists && sudo apt-get update && sudo apt-get --yes install libudev-dev:armhf libusb-1.0-0-dev:armhf gcc-arm-linux-gnueabihf && sudo make clean && sudo ./bootstrap && sudo ./configure --host=arm-linux-gnueabihf CC=arm-linux-gnueabihf-gcc && sudo make'

[tresf]

So it turns out dockcross uses the hardware-floating-point utility for compiling V6 targets... quoting:

# The CROSS_TRIPLE is a configured alias of the "armv6-unknown-linux-gnueabihf" target.
ENV CROSS_TRIPLE armv6-unknown-linux-gnueabihf
ENV CROSS_ROOT ${XCC_PREFIX}/${CROSS_TRIPLE}
ENV AS=${CROSS_ROOT}/bin/${CROSS_TRIPLE}-as \
    AR=${CROSS_ROOT}/bin/${CROSS_TRIPLE}-ar \
    CC=${CROSS_ROOT}/bin/${CROSS_TRIPLE}-gcc \
    CPP=${CROSS_ROOT}/bin/${CROSS_TRIPLE}-cpp \
    CXX=${CROSS_ROOT}/bin/${CROSS_TRIPLE}-g++ \
    LD=${CROSS_ROOT}/bin/${CROSS_TRIPLE}-ld \
    FC=${CROSS_ROOT}/bin/${CROSS_TRIPLE}-gfortran

There's a chance this compiler allows forcing back to software-floating-point, but from what I can tell, the builds are simply broken in the scripts current form and needs to be fixed. I'll see if I can patch it to work on my local.

[ergouser]

I don't claim to be an expert on the different Pi's (I was blind-sided by Pi3/4 and Pi Zero difference yesterday).
However, it is my understanding the that ArmV6 in the Pi Zero does have hardware floating point support.

[ergouser]

I'll see if I can get the cross compiling to work, last time I tried Manjaro complained about something that seemed as though it was going to be a lengthy problem to resolve.

In the Pi Zero, "out of the box" applications use the linux-arm library, I don't know what platforms might choose the armel by default. (Is there a runtime switch to choose the architecture?).

The solution to getting a v6 build would seems to be just to change line 247

dockcross-linux-armv7 ----> dockcross-linux-armv6

Whether, philosophically, that's the right approach I don't feel qualified to judge, but it does seem to be a common approach for Pi binaries - JNA provides V6. Eclipse UPM compiled on the Pi4 also generates V6 .so's.

I assume that there's a performance (and other?) penalty but, for the HID code I would also not expect it to be significant. Software floating point might be a bottleneck, except that the amount of floating point in the HID code is likely pretty limited.

[tresf]

it is my understanding the that ArmV6 in the Pi Zero does have hardware floating point support.

Ok, so I'm focusing on the wrong binary. :). Well, the armel is definitely broken, it can't find <libudev.h> for some reason.

To your issue, the hard-float library (a.k.a. linux-arm, that seems to just be a number away from being the armv6.

- echo -e "${green}Building ARMv7 hard float${plain}"
+ echo -e "${green}Building ARMv6 hard float${plain}"
-    dockcross-linux-armv7 bash -c 'sudo dpkg --add-architecture armhf && sudo rm -Rf /var/lib/apt/lists && sudo apt-get update && sudo apt-get --yes install libudev-dev:armhf libusb-1.0-0-dev:armhf gcc-arm-linux-gnueabihf && sudo make clean && sudo ./bootstrap && sudo ./configure --host=arm-linux-gnueabihf CC=arm-linux-gnueabihf-gcc && sudo make'
+    dockcross-linux-armv6 bash -c 'sudo dpkg --add-architecture armhf && sudo rm -Rf /var/lib/apt/lists && sudo apt-get update && sudo apt-get --yes install libudev-dev:armhf libusb-1.0-0-dev:armhf gcc-arm-linux-gnueabihf && sudo make clean && sudo ./bootstrap && sudo ./configure --host=arm-linux-gnueabihf CC=arm-linux-gnueabihf-gcc && sudo make'

[ergouser]

That's what I would expect and I would then expect that binary to work on all Pi's (0-4). I don't see any downside to this change although, admittedly my view may be a little biased...

[tresf]

Note, I tested the line above. The build says this:

linux-arm
ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=ff49c8f1c9270a9393e7b7cca94ba2d769ef8528, with debug_info, not stripped
ELF 32-bit LSB shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, BuildID[sha1]=a7a785c285f9bfc911b25566497ffccc385a980f, with debug_info, not stripped

Is EABI5 the same as armv6?

[ergouser]

Yes. The only command I know is :

arm-linux-gnueabihf-readelf -A libhidapi.so

which will identify the architecture.

[tresf]

my view may be a little biased...

If it's what JNA targets, it's what this library should target since it depends on JNA, it should have identical levels of compatibility.

Yes. The only command I know is :
arm-linux-gnueabihf-readelf -A libhidapi.so

It took me a while to get it working, but it gives me this, which I don't think is what we want:

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

[ergouser]

I would say not...

$ arm-linux-gnueabihf-readelf -A libhidapi.so
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "6"
Tag_CPU_arch: v6
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-1
Tag_FP_arch: VFPv2
Tag_ABI_PCS_wchar_t: 4
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

[tresf]

Yeah, I don't know why it's building for the wrong architecture, the dockcross container clearly states it should build for ARMv6 with the one we're using... https://github.com/dockcross/dockcross/blob/aa4bcf4a34692fb4d0dc61d6dad8f6737c0b6f83/linux-armv6/Dockerfile.in#L10.

I'll see if I can figure out what I'm doing wrong. It should be pretty straight forward.

[ergouser]

There's an issue that I don't really understand related to linking, gcc and ARMv7

https://stackoverflow.com/questions/55465118/gcc-8-cross-compiler-outputs-armv7-executable-instead-of-armv6

[tresf]

There's an issue that I don't really understand related to linking, gcc and ARMv7

https://stackoverflow.com/questions/55465118/gcc-8-cross-compiler-outputs-armv7-executable-instead-of-armv6

Good catch. Check this out: https://stackoverflow.com/a/65186762/3196753

Quoting:

By default, newer GCC versions do not create correct binaries for ARMv6. Even though you pass the correct -mcpu= flag to gcc, it will create startup code for the newer ARMv7 architecture. Running them on your RasPI Zero will cause an "Illegal Instruction" exception.

this info is mentioned here https://github.com/Pro/raspi-toolchain

Ouch!

[tresf]

Also (essentially the same observation):
https://stackoverflow.com/questions/55465118/gcc-8-cross-compiler-outputs-armv7-executable-instead-of-armv6

Yeah, I tried the linux-armv6-lts Docker file as well as the linux-armv6-musl. The first still produced v7 binaries, the latter gets hung up on libudev.h: No such file or directory, just like the soft-float compilation I was working on earlier.

Most of the forums state to avoid Ubuntu's linker so I'm not sure if its possible, but I was hoping that perhaps the musl version lacked such a linker defect. :/