Why does the intel openvino R5 precompiled binaries give "not executable" on my raspberry pi OS? - raspberry-pi3

The precompiled OpenVINO R5 distribution supports "raspbian 9" and gives some precompiled libraries for interfacing with their "movidius" usb stick. I tried it, and for example their precompiled "myriad_compile" program runs on raspbian indeed. Now I am doing the same on a custom built OS made with OpenADK. It has the official raspberry pi kernel, and uses glibc 2.27 and I'm using gcc 7.3.0 too. If I run the exact same binary, then I get this message:
# ./myriad_compile
mksh: ./myriad_compile: not executable: 32-bit ELF file
As a test, I tried to run a random binary from raspbian on my OS, and it works ok. I also tried to run a random binary from my OS on raspbian and it also worked ok.
So now I'm a bit puzzled what else could be the cause of this.
I did a readelf of the intel binary:
pi#raspberrypi:~/armv7l $ readelf -A ./myriad_compile
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
And here is the random executable called "watchdogctl" compiled by my toolchain from my own OpenADK OS:
pi#raspberrypi:~/armv7l $ readelf -A ./watchdogctl
Attribute Section: aeabi
File Attributes
Tag_CPU_name: "Cortex-A53"
Tag_CPU_arch: v8
Tag_CPU_arch_profile: Application
Tag_ARM_ISA_use: Yes
Tag_THUMB_ISA_use: Thumb-2
Tag_FP_arch: FP for ARMv8
Tag_Advanced_SIMD_arch: NEON for ARMv8
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_MPextension_use: Allowed
Tag_Virtualization_use: TrustZone and Virtualization Extensions
And this executable, coming from raspbian 9 runs on my OS without problems, and it's compiled for an older cpu version even:
pi#raspberrypi:~/armv7l $ readelf -A /usr/bin/wpa_passphrase
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_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
So can I get some more info about what is missing in my OS that is present on raspbian 9? I see that they use glibc 2.24 but I have 2.27 so I should be OK I think, and also I have gcc 7 and they use gcc 6, but it's all with the new ABI so I also don't think there is a problem there.
Any suggestions are welcome!
Thank

Sooooo, after some more searching and hair-pulling, it seems I have to enable the "thumb" compile options in my glibc compilation. I found out by compiling a subset of my own os again with that option, and then uploaded such a binary to my old OS, then saw the exact same message appear... so I then booted my thumb OS and it works!

Related

How to use constants created with .equ in a second assembler file?

Context
I'm working through some examples in a book by Johnathan Bartlett titled "Learn to Program with Assembly" (2021). The author assumes a linux environment. I'm on OSX (Monterey). He's using gcc. I've got clang (v 13.1.6). In chapter 7 the author introduces laying out data records.
To facilitate this, he uses the .equ directive to define some constants in a file titled persondata.s which happens to only contain a data segment. For example:
# Describe the components of the struct
.globl WEIGHT_OFFSET, HAIR_OFFSET, HEIGHT_OFFSET, AGE_OFFSET .equ WEIGHT_OFFSET, 0
.equ HAIR_OFFSET, 8
.equ HEIGHT_OFFSET, 16
.equ AGE_OFFSET, 24
In another file, tallest.s, he makes use of the HEIGHT_OFFSET constant to access the height of a person record. This file has only a text segment.
movq HEIGHT_OFFSET(%rbx), %rax
The Problem
When I assemble tallest.s using the built-in tools on OSX, the assembler complains that I'm trying to use 32-bit absolute addressing in 64-bit mode.
The Question
How is this supposed to work on OSX? How am I supposed to make use of .equ defined constants?
Things I Tried
If I merge these two files into one file, then assembler doesn't complain. It treats HEIGHT_OFFSET as the constant that it is.
I presume the idea is to have constants defined along with the data, and then make use of those constants in code to avoid 'magic numbers'. Sounds like a good idea.
I tried assembling, linking, and running this code using the book's docker image (johnnyb61820/linux-assembly). It works. No complaints. Some details
# as -v
GNU assembler version 2.31.1 (x86_64-linux-gnu) using BFD version (GNU Binutils for Debian) 2.31.1
^C
# ld -v
GNU ld (GNU Binutils for Debian) 2.31.1
# uname -a
Linux eded2adb9c06 5.10.124-linuxkit #1 SMP Thu Jun 30 08:19:10 UTC 2022 x86_64 GNU/Linux
So it works as written under that set-up. Just not under my set-up which is clang (v 13.1.6).
Based on the fact that this works in the linuxkit docker image, I thought to install gcc via homebrew on my machine. This got me version 12.2.0 of gcc, which I used to try and compile/link my files. It also thinks HEIGHT_OFFSET is a problem due to 32-bit absolute addressing in 64-bit mode.
Based on the output of name -a in the docker image, I'm guessing it is 64 bit. Linux eded2adb9c06 5.10.124-linuxkit #1 SMP Thu Jun 30 08:19:10 UTC 2022 x86_64 GNU/Linux
Oddly enough, it doesn't complain about 32-bit absolute addressing not being supported. Under OSX, I had to make everything rip-relative to access any static-data (true for both gcc and clang). Makes me wonder what it is doing with these addresses.
As a possibly final note, under OSX yasm also doesn't like me using .equ defined constants from another file. It complains about wanting to make use of "32 bit absolute relocations" in 64 bit mode. GCC (12.2.0) and llvm-mc (13.0.1) also take issue with the HEIGHT_OFFSET constant.

Compile and run a 32bit binary on Armv8 (aarch64) running 64bit linux

I'am trying to compile and run a 32 bit binary on a Cortex-A72 Armv8 using gcc compiler but i am not able to do it. I followed this prior thread Having trouble compiling 32-bit binary on 64-bit linux armv8 machine and i am realized too that the -m32 flag is not supported on ARMv8 linux machines.
Looking at https://gcc.gnu.org/onlinedocs/gcc/AArch64-Options.html i didn’t find anything interesting.
In according to https://linux.die.net/man/1/arm-linux-gnu-gcc the AArch64 gcc options are:
-mbig-endian -mlittle-endian -mgeneral-regs-only -mcmodel=tiny -mcmodel=small -mcmodel=large -mstrict-align -momit-leaf-frame-pointer -mno-omit-leaf-frame-pointer -mtls-dialect=desc -mtls-dialect=traditional -march=name -mcpu=name -mtune=name
So my question is: is it possible to compile and run a 32-bit binary on a 64-bit linux Armv8 machine ? and is so, how ?
Thank you.
EDIT: this https://jensd.be/1126/linux/cross-compiling-for-arm-or-aarch64-on-debian-or-ubuntu worked for me
You can download the AArch32 target with hard float (arm-none-linux-gnueabihf) toolchain from the Cortex-A toolchain Arm site.
The archive file name is gcc-arm-10.2-2020.11-aarch64-arm-none-linux-gnueabihf.tar.xz, in the AArch64 Linux hosted cross compilers section.
You may need to install additional packages on your Aarch64 system - search for How to run 32-bit (armhf) binaries on 64-bit (arm64) and your Linux distribution name.

ELF file generated in armv7, .o files in armv6, while using -march=armv6, why?

I'm trying to compile my program to armv6, but the ELF file is built for armv7, even when I use -march=armv6 option. All .o files has been compiled to armv6, only the ELF file is wrong.
Basically I'm compiling like this:
arm-linux-gnueabihf-g++ -static -march=armv6 -mfpu=vfp -mfloat-abi=hard -marm -Wa,-march=armv6 -o "Bridge"
Checking all .o files I get this:
$ readelf -a -W Bridge.o | grep Tag
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_ABI_optimization_goals: Aggressive Speed
Tag_CPU_unaligned_access: v6
But checking the ELF file:
$ readelf -a -W Bridge | grep Tag
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
Tag_Advanced_SIMD_arch: NEONv1
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
I'm using Linaro GCC 7.2.1, and I've also tried with old versions, and different compilation flags combinations. Can someone tell me how to compile an armv6 ELF file?
Problem identified.
The Linaro toolchain binary was able to compile the object files for the armv6 platform, however, the linker actually did not interpret this flag.
Reason: the toolchain was compiled with the armv7 configuration.
Solution: I downloaded the source code for the Linaro toolchain, configured it to support armv6 and compiled it using the cross-ng-tool.

How can I build zaptel for ARM?

I'm trying to cross-compile zaptel driver for Arm
I'm following this project http://svn.astfin.org/software/baps/trunk to build zaptel driver for blackfin arch. After building uClinux, oslec and patching zaptel.patch to build extra modules wcfxs, sport_interface, bfsi instead of original one, this command does the magic
make -C /home/working/BAPS/uClinux-dist/linux-2.6.x/ SUBDIRS=/home/working/BAPS/zaptel-1.4.3/ modules V=1 ARCH=blackfin CROSS_COMPILE=bfin-uclinux- EXTRA_CFLAGS="-DCONFIG_4FX_SPI_INTERFACE"
Build process run successfully, bfsi.ko, sport_interface.ko, wcfxs.ko, zaptel.ko generated and useful for my astfin board (well, also the oslec.ko in the previous process).
bfsi.ko: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYSV), not stripped
sport_interface.ko: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYSV), not stripped
wcfxs.ko: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYSV), not stripped
zaptel.ko: ELF 32-bit LSB relocatable, Analog Devices Blackfin, version 1 (SYSV), not stripped
So then I want to do the same thing with my arm board (particularly my Beaglebone Black).
Firstly, I completely built BBB Kernel, and then the oslec. I know oslec is also a kernel module but I easily built it.
make -C [my bbb kernel] ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- EXTRA_CFLAGS="-I/home/working/AAPS/oslec/kernel -I/home/working/AAPS/oslec/spandsp-0.0.3/src/spandsp" SUBDIRS=/home/working/AAPS/oslec/kernel modules
I have the oslec.ko and it looks ok.
kernel/oslec.ko: ELF 32-bit LSB relocatable, ARM, version 1 (SYSV), not stripped
But I got stuck in the final step - building zaptel
Here's my make command
make -C /home/working/AAPS/dl/buildroot-bbb/output/build/linux-3.8.13/\
SUBDIRS=/home/working/AAPS/zaptel-1.4.3/ modules V=1 ARCH=arm\
CROSS_COMPILE=arm-linux-gnueabihf- KBUILD_NOPEDANTIC=1\
EXTRA_CFLAGS="-DCONFIG_4FX_SPORT_INTERFACE -I/home/working/AAPS/zaptel-1.4.3/staging/usr/include "
come with error:
include/linux/wait.h:159:47: error: ‘TASK_INTERRUPTIBLE’ undeclared (first use in this function)
#define wake_up_interruptible(x) __wake_up(x, TASK_INTERRUPTIBLE, 1, NULL)
I figured out that the constant TASK_INTERRUPTIBLE was defined in $(my_bbb_kernel)/include/linux/sched.h and $(blackfin_uclinux_kernel)/linux-2.6.x/include/linux/sched.h, but one works (uclinux for blackfin) and one does not (my bbb kernel). I dont know how can they included cause i'm not so familiar with linux kernel module development.
So if anyone have any idea in this case, please give me some instructions or explains.
Best Regards
Loi Dang

libiconv solaris-sparc/opteron 64 bits

I have 64 bit solaris - sparc and opteron systems. Under /usr/local/lib , I can see libiconv.so for both systems. The file command on libiconv.so gives following output:-
ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available
How do I build 64 bit libiconv w/o disturbing existing 32 bit on both sparc and opteron systems? Reason being, I am not aware of existing version of libiconv.
This libiconv.so is not part of the OS being in the non standard /usr/local/lib. Should you want to build yourself or install from elsewhere a 64 bit version of this library, you would install it in /usr/local/lib/amd64 or /usr/local/lib/64.
However, this is probably useless in the first place as Solaris already includes the iconv library function in its standard C library so Gnu libiconv is basically redundant and unnecessary here.

Resources