ARM binaries for command line compilers?

fanoush

New Member
Hello,

It would be great to have compiler binaries compiled for ARM architecture. The best would be statically linked binaries so it would run both on android devices and also on various arm based netbooks (chromebooks) and the Raspberry Pi!

Personally I would use it to compile picaxe basic projects with my son both on my Asus Transformer and his Pi.

Would it help if I prepare step by step guide for you how to compile something for ARM inside x86 Ubuntu or Debian (or even Windows)? For static linking I would suggest uclibc. It can produce static binaries that are small and self contained and run on almost any arm device with recent kernel.

BTW There is also growing arduino community around the Pi http://www.raspberrypi.org/archives/tag/arduino so picaxe should not be left out ;-)

This is minimal request, it would be of course great to have full axepad environment for the Pi but OTOH it would be limited to Pi only while compiler binaries are usable on more devices with more frontend applications.
 

hippy

Technical Support
Staff member
At present there are no plans to produce ARM ports of the compilers though we will continue to review the situation in the future.
 

fanoush

New Member
Thanks for reply and sorry for not being clear enough. I forgot to say that I mean binaries for ARM Linux i.e. this is not about porting but about taking the very same sources used to produce "Linux Compilers v2.4" downloadable here http://www.picaxe.com/Software/Drivers/PICAXE-Compilers/#tResources and just compiling it with compiler that produces arm linux instead of i386 linux binaries.

Unless there is x86 assembly in your code or the code neet some specific compiler other than gcc there should be no change in the source. Even the byte order is same for arm and x86 so there should be no issue regarding endianness.
 

fanoush

New Member
got it working!

Just to let you know that I got it working in armhf debian on Raspberry PI via i386 qemu user mode emulation.

QEMU has two modes - system emulation where it emulates whole hardware and linux user mode emulation where it just translates CPU instruction set and maps linux system calls from target to host. One can then just prefix any x86 linux executable with 'qemu-i386' and it runs just like native command.

There were only two issues with this.

PICAXE compilers are dynamically linked so I had to take /lib/ld-linux.so.2 and /lib/libc.so.6 from x86 linux. This worked fine and I could finally run compiler and see its output and even run syntax check and see terminal output like this
Code:
bash-4.2# qemu-i386  -L . picaxe14m2 -s -t test.bas

PICAXE-14M2 Enhanced Compiler. Version 2.4
Copyright (c) 1996-2012 Revolution Education Ltd
All rights reserved.
www.picaxe.com

Compiled successfully.
Memory used = 50 out of 2048 bytes.

Unsupported ioctl: cmd=0x5428

Terminal open (4800,n,8,1) - Press <Enter> to exit...

Hello, I am your PICAXE 14M2
Hello, I am your PICAXE 14M2

bash-4.2#
Unfortunately programming the chip or checking for firmware failed :-(
It failed because qemu (version 1.1.2) did not emulate relatively rare TIOCSBRK and TIOCCBRK ioctl calls. Looks like piceaxe compilers use those calls to send serial line break signal to trigger firmware loader.

The solution was to recompile qemu from source with those two calls added to emulated ioctl list in linux-user/ioctl.h header file. After building qemu with those two lines added everything works now.

We can finally program our PICAXE chips from Asus TF101 tablet and Raspberry PI :)

Next step is to integrate it with some text editor.
 

Technical

Technical Support
Staff member
Thanks for the feedback, this may be useful for others. Which USB cable are you using, is it the AXE027?
If there is enough demand in the future we will also consider an official arm build.
 

fanoush

New Member
I am using hand-made serial cable and generic pl2303 usb to serial converter. Both RaspberryPI and Asus Transformer TF101 have pl2303 driver in kernel and detect it automatically and creates /dev/ttyUSBx for me. Here is output from kernel log from Asus TF101
Code:
<6>[1773120.428758] usb 1-1.2: new full speed USB device using tegra-ehci and address 82
<6>[1773120.467325] usb 1-1.2: New USB device found, idVendor=067b, idProduct=2303
<6>[1773120.467365] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
<6>[1773120.467397] usb 1-1.2: Product: USB-Serial Controller
<6>[1773120.467422] usb 1-1.2: Manufacturer: Prolific Technology Inc.
<4>[1773120.467453] device: '1-1.2': device_add
<4>[1773120.468878] device: '1-1.2:1.0': device_add
<6>[1773120.470171] pl2303 1-1.2:1.0: pl2303 converter detected
<4>[1773120.472051] device: 'ttyUSB0': device_add
<4>[1773120.473573] device: 'ttyUSB0': device_add
<6>[1773120.475380] usb 1-1.2: pl2303 converter now attached to ttyUSB0
I am running armhf Debian in a chroot environment inside Android on the TF101 and compiled qemu there but I have built qemu-i386 as a static ARM binary so now it works also in pure Android in a terminal window, no need to run it from inside Debian.

Here is picture of the setup with compiler uploading test program to 08M2 board
picaxe-tf101.jpg

As for RaspberryPI - the board has GPIO/SPI/I2C/serial pins so it can be either used directly for some project or it can be used as host computer running desktop environment with PICAXE or Arduino connected. Also some people are using RaspberriPI as a real laptop thanks to relatively cheap (~US$70) Motorola Atrix Lapdock see this http://www.raspberrypi.org/phpBB3/viewtopic.php?f=63&t=6747 or this http://www.youtube.com/watch?v=zPGt2EmQEo8
In fact I have ordered this Lapdock for my son to replace his aging XO-1. It is great to have laptop with the possibility of detachable PI board so that it can run standalone if needed :)
 
Last edited:

photomankc

New Member
At present there are no plans to produce ARM ports of the compilers though we will continue to review the situation in the future.
This seems short-sighted. It's not much effort to support a community that is constantly looking for ways to integrate small real-time controllers into projects. I just hit the same wall. I wanted to compile and download to a PICAXE sub-controller on my BeagleBone Black robot project. Having the host ARM system able to reprogram it's sub-controller on the fly would be very useful, but the binaries don't run and of course I can't compile them for my platform. This means the robot would need to be torn down to reprogram an embedded PICAXE controller.
 

chopperwalker

New Member
I just wanted to say thank you fanoush. This works great. I have setup two different r-pi's each connected to 20x2s by I2C. It was a pain to go reprogram the 20x2s (remote location). Now I can update both the r-pi and picaxe program over wifi. Next I will update my programs to run over serial and not have both USB and I2C going. Amazing for debugging and updating.
 

SteveDee

Senior Member
...Unpack it somewhere, then get picaxe linux command compilers an put them to i386/compilers. Then you can run picaxe command wrappers from bin...
Many thanks to Fanoush for releasing this.

I'm having a problem using this method, so just wanted to check that my understanding of how to use this is correct(...its probably not!).

I've unzipped the files to my home directory and copied compilers to: /home/pi/picaxe/i386/compilers

Then I open a terminal session (from /home/pi/picaxe/bin)
and run:-
Code:
~/picaxe/bin $ sudo ./picaxe08m2 -h
...which returns:-
Code:
Error -13 while loading ./../i386/compilers/picaxe08m2
If error 13 is a Linux error it may be a permissions problem.

Any advice welcome.
 
Last edited:

hippy

Technical Support
Staff member
I recall there were some issues getting the compilers to run on a Pi after following the instructions because I don't think Fanoush's solution was specifically for Raspbian. You might need to manually set Execute permissions on all executable files and shell scripts.

Was there some 'name:' text before the error message ? That may give a clue as to what sub-component is reporting the error.

First thing is probably to dump a directory tree listing of everything in and below /home/pi/picaxe so it can be checked that the files are in the right place and have the right permissions and owners.
 

SteveDee

Senior Member
...Was there some 'name:' text before the error message ?...
Many thanks Hippy for taking the time to respond.

I think my main problem is that I don't understand Qemu. And I think this error...
error.png

...is probably because I need to install some qemu related packages.

I've started reading up on qemu, and know that it can be used in 2 ways: full emulation and user mode.
I just don't know how much support is needed for user mode (i.e. what Debian packages are required).

I'm running Raspian Jessie on a PiB+ (Arm6) although I started with a PiB2 (Arm7).

Here is the file/folder layout.

files.png

Just about all files are read/write/execute for current user "pi".

When I get time I will try running a command from the command line without the script.
 

hippy

Technical Support
Staff member
I think my main problem is that I don't understand Qemu. And I think this error... ...is probably because I need to install some qemu related packages.
It could be. I must admit that I am not that familiar with qemu nor Raspbian Jessie. Your files look okay to me, all in the right place.

Added: It looks like you have some of the ./bin files in ./i386/compilers directory, and I don't have a beta_compiler.pdf. It would be worth checking you have the latest PICAXE Linux compilers.

It could also be worth trying the B+ under Raspbian Wheezy just to assure yourself it does work. These are the commands I used to get things installed and tested, run from the default pi home directory ...

Code:
wget http://fanoush.wz.cz/picaxe/picaxe-raspberrypi.tar.gz
wget http://www.picaxe.com/downloads/picaxe.tgz
tar -zxvf picaxe-raspberrypi.tar.gz
tar -zxvf picaxe.tgz -C ./picaxe/i386/compilers
cd ./picaxe
cd ./bin
./picaxe08m2
That produces ...

Code:
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so' from /etc/ld.so.preload cannot be preloaded: ignored.

PICAXE-08M2 Compiler
Version 3.1
Copyright (c) 1996-2014
Revolution Education Ltd

Incorrect usage. Use -h for help.
Other than that ld.so error it works just fine as far as I can tell.
 
Last edited:

SteveDee

Senior Member
...These are the commands I used to get things installed and tested, run from the default pi home directory ....
Many thanks hippy. Having used your instructions successfully, I've discovered the problem. It was that loose nut attached to my keyboard (...again!).

When I did the original test on PiB2, there was just one file where I had not set the execute flag. This just happened to be the compiler I was using: picaxe08m2

When I did the second test on PiB+, all file permissions and execute flags were OK, but I screwed up copying files across via a memory stick.

My only defense is that I got the same error message, so assumed I had the same problem running both boards.

Anyway I can at least report that:
Code:
picaxe08m2 -h
...works with Raspian Jessie on both PiB+ (ARM6) and PiB2 (ARM7).

Now I just need to get it to compile & download to my Picaxe using something like:-
Code:
sudo ./picaxe08m2 -c/dev/ttyAMA0 test.bas
 

hippy

Technical Support
Staff member
Excellent news.

If /dev/ttyAMA0 is the on-board UART I believe the polarity will be inverted, idle high rather than the idle low the PICAXE expects, so will need hardware inversion. There is/was also a long standing bug which generates a false transmission whenever /dev/ttyAMA0 is opened; not sure if that still exists or would affect PICAXE download. Do let us know how you get on.
 

SteveDee

Senior Member
...There is/was also a long standing bug which generates a false transmission whenever /dev/ttyAMA0 is opened...
I think that bug was fixed a while ago, I haven't noticed it in any of my Picaxe serial test programs. And yes, I can confirm that its now compiling and downloading OK.

Many, many thanks once again!
 

hippy

Technical Support
Staff member
I can confirm that its now compiling and downloading OK.
Out of interest; did you have to invert the signals / what download cable are you using ?

Also, do you get the ld.so error, or is that just something I am getting on my set-up ? I think it was trying to get it to run, moving .so files around to get it to work which was the issue I originally encountered. I am not sure if it is a problem of my own making, I haven't tried a clean Raspbian re-install to check.
 

fanoush

New Member
Also, do you get the ld.so error, or is that just something I am getting on my set-up ?
The "ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libcofi_rpi.so' from /etc/ld.so.preload cannot be preloaded: ignored." error is harmless. It is caused by raspbian setting to preload /usr/lib/arm-linux-gnueabihf/libcofi_rpi.so library for all (supposed to be ARM) binaries. I think it is caused by LD_LIBRARY_PATH or LD_PRELOAD variable being automatically passed by qemu to emulated environment so then the emulated x86 dynamic loader tries to load it into emulated environment too which fails because it is not x86 library.

When googling it now it looks like this could be fixed by using -U qemu parameter to unset the variable as documented e.g. here http://nairobi-embedded.org/qemu_usermode.html So something like -U LD_PRELOAD,LD_LIBRARY_PATH added to qemu-i386 command could get rid of the message. I will try it and update bin/wrapper script inside the archive if it works as expected.

And BTW I am happy this is useful for more people than just me :)
 

fanoush

New Member
Hi hippy, please take a look at my notes, which I think answer your questions: http://captainbodgit.blogspot.co.uk/2015/05/picaxe-programming-with-pi.html

If I've missed anything, please let me know. Thanks once again.
Great guide SteveDee :)

BTW it should be possible to run the compiler also from other folders so you don't need to keep you .bas files in same folder as the compiler. So instead of ./picaxe08m2 you can be in folder above and run it via ./bin/picaxe08m2 or even put the bin folder to your PATH (export PATH=$PATH:/home/pi/picaxe/bin) and run it from anywhere.

Also thanks for getting it working with builtin serial port! I found it easier to solve the signal inversion and freeing up the port issue by cheating and using usb to rs232 serial adapter but you solution is better :)
 
Last edited:

hippy

Technical Support
Staff member
I wonder why picaxe firmware creators decided to use inverse polarity.
The PICAXE was designed to connect directly to a standard RS232 interface which is an inverted serial signal, idle low, active high.
 

fanoush

New Member
Thank you, figured that out and removed that from my post already. Also removed the suggestion for using USB to serial TTL converter since that would not solve the polarity issue too. I forgot that for picaxe I am using usb to RS232 serial for this reason and not usb to TTL serial like with everything else. I just checked if the polarity can be changed in software for TTL adapters or PI builtin serial port (like PICAXE can do with serout command) and it looks like this is not supported. I only found one suggestion in this topic https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=22258 to use other two gpio pins inverted by interrupts but that looks more complex that using simple hardware inverter :)
 

hippy

Technical Support
Staff member
One thing to note is that the Pi Foundation warns that all GPIO on the Pi is only 3V3 tolerant and any voltage over that, even for a very short period, can permanently damage the GPIO and the entire SoC rendering the board useless. The GPIO is not as robust as found on the PICAXE and in-line current limiting resistors cannot be used to interface 5V or RS232 signal inputs directly.

The safest and easiest way to connect a Pi to a PICAXE is using a AXE027 or other USB-to-serial cable.
 

SteveDee

Senior Member
One thing to note is that the Pi Foundation warns that all GPIO on the Pi is only 3V3 tolerant and any voltage over that, even for a very short period, can permanently damage the GPIO...
Well, I dispute this. The gpio is powered from 3.3V but that does not mean that applying a voltage greater than 3.3V to a gpio pin configured as an input will damage the Pi. The Pi is very robust to ESD, which implies that the gpio has input protection, and my measurements seems to imply that the protection circuit kicks-in somewhere above 5Volts. For those that are not convinced, my Pi/Picaxe circuit allows R1 to be connected to 3.3V.

But if you want to take a look at my reasons for stating that the gpio (when used as an input) can be connected to a 5V interface, check my notes: http://captainbodgit.blogspot.co.uk/2015/01/raspberrypi-gpio-mixing-voltage-levels.html

I haven't found anyone on the Pi forum prepared to engage me in a sensible discussion about this. A forum moderator, calling himself an Engineer, even suggested that a voltage derived from a resistor was somehow different from the same voltage derived by other means (although a few hours later he edited his post and took that bit out!).

Either way, I think Picaxe + Pi is a great combination, and look forward to putting my PicaxePi Birdbox back into service for a second season come March 2016: http://captainbodgit.blogspot.co.uk/2015/01/birdbox2015-picaxe-controller-details.html
 

nekomatic

Member
Thank you, figured that out and removed that from my post already. Also removed the suggestion for using USB to serial TTL converter since that would not solve the polarity issue too. I forgot that for picaxe I am using usb to RS232 serial for this reason and not usb to TTL serial like with everything else. I just checked if the polarity can be changed in software for TTL adapters or PI builtin serial port (like PICAXE can do with serout command) and it looks like this is not supported. I only found one suggestion in this topic https://www.raspberrypi.org/forums/viewtopic.php?f=44&t=22258 to use other two gpio pins inverted by interrupts but that looks more complex that using simple hardware inverter :)
USB to TTL serial adapters that use the FTDI chipset can be configured to invert their data lines using the FT_Prog utility, which you can download from FTDI.
 

julianE

Senior Member
Thanks to SteveDee, fanoush and other good people of the forum I am programming a picaxe with a raspberry pi zero W. Everything works perfectly until I power down the pi.
I narrowed it down to the transistor inversion circuit. Goeytex circuit here,
http://www.picaxeforum.co.uk/attachment.php?attachmentid=17228&d=1412608050
I'm powering the transistor inverter from the same power supply powering the 08M2. The program I'm downloading to the picaxe from the pi flashes an LED and sends a sertxd message and all works perfect. Once I power down the pi the picaxe stops flashing, if I remove the positive lead to the inverter circuit the picaxe starts flashing again. Also, removing the wire running to the input of the picaxe restarts the flashing. I have tried using the usual 22K/10K combination instead of the Goeytex suggested resistors without a difference.

I really like the transistor inversion circuit but I do have a 74hc04 on hand and can try that if there is no solution to the issue.

Any ideas?
 

Technical

Technical Support
Staff member
That circuit depends on the CH340 being powered and holding Q2 on all the time (default state). Hence a poor solution if you want the circuit to work with the CH340 powered down (as R2 will then hold the serial pin permanently high, in the reset state).
 

SteveDee

Senior Member
I think you just need a weak pull-up resistor between Pi/R1 and supply. That way, if Pi is switched off, the transistor Q2 should stay on, but when Pi is running it should still switch high/low OK.

Take a look at my circuit here: https://captainbodgit.blogspot.co.uk/2016/01/robobuggy-and-me.html#more

You may need to experiment a bit with pull-up value depending upon Q2 gain. Also, I don't think R5 & R6 are necessary, and if they were removed you could increase the value of R2, as this is drawing over 2mA when Q2 is switched on. Basically, you want to be able to saturate Q2 with a weak pull-up (say 10-20k) but when Q2 is not conducting, the Q2 collector resistor needs to provide enough current to bring serin high.

I hope that makes sense, but come back if not.
 

julianE

Senior Member
Thank you gentlemen for the explanation, I did a quick try with a 22K pull pull up on Q2 and it did not work, will experiment more as time permits. I do like the circuit cause it uses so little space on the board compared to a 14 pin 74HC04. I was considering using an OP-AMP as an inverter but not many work at 3.3 volts.
BTW, SteveDee, phenomenal job documenting pi to picaxe programming. I did have to make some slight modifications for the pi zero wireless. Pi zero and picaxe is a very good combination.
 

SteveDee

Senior Member
Thank you gentlemen for the explanation, I did a quick try with a 22K pull pull up on Q2 and it did not work, will experiment more as time permits...
If you have a multi-meter, just monitor the Q2 collector voltage (w.r.t. 0V) and try lower values of pull-up resistor until Q2 saturates (voltage less than say 0.5V). Don't go too low, but 10k should be safe for the Pi (5V/10k = 500uA). Increasing the value of R2 will help to achieve Q2 saturation with sensibly high values of pull-up resistor.

...I do like the circuit cause it uses so little space....

There are dual inverters available (maybe something like this: http://www.ti.com/lit/ds/sces617a/sces617a.pdf) but I have no idea about price and availability.

...I did have to make some slight modifications for the pi zero wireless....
Please publish your modifications for the Pi Zero, as this may be helpful to others.

Are you just using the Pi to program, or is it an integral part of your Picaxe project?
 

julianE

Senior Member
Please publish your modifications for the Pi Zero, as this may be helpful to others.

Are you just using the Pi to program, or is it an integral part of your Picaxe project?
I certainly will. Need to buy a new pi zero w and do a clean setup. I changed a lot of things while troubleshooting and I'm sure most were unnecessary. I'm not sure but I think I'm using a software serial instead of hardware. Just like your tutorial I'm using pins 8 and 10 on the pi but the device is /dev/ttyS0.
I used a half a dozen sites to figure out how to get serial communication going on pi zero w. pi with bluetooth and built in WiFi are a little different then the original pi. Here is the web site that was of most help,
https://spellfoundry.com/2016/05/29/configuring-gpio-serial-port-raspbian-jessie-including-pi-3/

I will try to pick up a fresh pi zero today and see if i can set it up to work and take notes along the way.

I have some ambitious plans for pi/picaxe combo. I'd like to have multiple picaxes controlled by a single pi, have some sort of a switching system to select which picaxe would be attached to the pi, one at the time. perhaps use a 4066 chip for switching between picaxes. i'd like to have it all battery powered and to be able to power off the pi and turn it back on remotely. turn off i can do through WiFi and use the 315Mhz modules with a picaxe to turn it back on. i've been reading the forum about solar cell battery charging because i'd like to have it all battery powered.

of course, life always gets in the way of fun i hope to have some free time soon.
 

julianE

Senior Member
I picked up a new pi zero w and i have no idea how i got the first one working i patched it together from a number of sites. I did find one site that explained it succinctly,
https://community.particle.io/t/tutorial-enable-gpio-serial-on-rpi-3/30194

here are the steps if the link disappears,

$ sudo -s
$ echo "enable_uart=1" >> /boot/config.txt
$ systemctl stop serial-getty@ttyS0.service
$ systemctl disable serial-getty@ttyS0.service
$ nano /boot/cmdline.txt #Remove console=serial0,115200

After a reboot you should be able to use /dev/ttyS0

to check type in

ls -l /dev/serial*

that will list all your serial ports.

Follow SteveDee instructions just make a couple substitutions,

http://captainbodgit.blogspot.com/2015/05/picaxe-programming-with-pi.html

I start the minicom program with,

sudo minicom -D /dev/ttyS0 -b 4800

and for the compiling,

./picaxe08m2 -c/dev/ttyS0 yourprogram.bas

it worked for me. i did sertxd every few seconds just sending something like ("count= ",#b0,CR,LF) and had no dropped characters. I'm not sure if ttyS0 is a software serial or hardware UART, I'm using it at 4800 and it's pretty solid.

Hope this helps someone using a pi zero w and it should also work on a pi3 which i will be testing soon.
 

hippy

Technical Support
Staff member
Rather late in the day I think I have discovered how to avoid the slightly annoying but harmless "ld.so" error when the compilers are run -
Code:
pi@raspberrypi:~/picaxe/bin $ ./picaxe08m2
ERROR: ld.so: object '/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so' from /etc/ld.so.preload cannot be preloaded: ignored.

PICAXE-08M2 Compiler
Version 3.1
Copyright (c) 1996-2014
Revolution Education Ltd

Incorrect usage. Use -h for help.
The trick is to edit the '/etc/ld.so.preload' file
Code:
sudo nano /etc/ld.so.preload
Which should have one line in it, similar to -
Code:
/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so
Insert a '#' at the start of the line to comment it out -
Code:
#/usr/lib/arm-linux-gnueabihf/libarmmem-${PLATFORM}.so
Press Ctrl-X, press 'Y', then press return to save the change.

When the compilers are then run the 'ld.so' errors should be gone.
 

steliosm

Senior Member
Hello.

Given the release of a new RPi product (RPi 400) and it's popularity are you willing to consider porting the command line compilers to RPi platform this time?
Relying on a 'hack' that also requires a modded qemu binary doesn't substitute the need for a proper compiler for this platform.
 

bogbean

Well-known member
I've previously been successfully able to download code to an 08M2 from my RPi 4B running the 32 bit RPi OS. I followed the (very handy) instructions here to set things up...

A few days ago I switched to the bullseye 64 bit (beta) OS on the pi and have tried setting up the picaxe compilers again using the same above instructions but have run into a problem. When I try the ./picaxe08m2 -h command from the bin folder I get the following error:
./picaxe08m2: line 3: ./qemu-i386: No such file or directory

Could this problem be linked to the change of my OS from 32 bit to 64 bit?
 

hippy

Technical Support
Staff member
./picaxe08m2: line 3: ./qemu-i386: No such file or directory

Could this problem be linked to the change of my OS from 32 bit to 64 bit?
Possibly but it sounds more likely that the 'quemu-i386' executable isn't in the same directory as the 'picaxe08m2', doesn't have the executable permissions set.
 

bogbean

Well-known member
Yes, good things to check, I ought to have thought of those.
I can confirm qemu-i386 is in the same directory as picaxe08m2, i.e. the directory from which I was running ./picaxe08m2 -h

The permissions for qemu-i386 return the following, so I believe them to be ok: -rwxr-xr-x 1 pi pi 1043272 Oct 5 2013 qemu-i386

A stackoverflow post suggested using 'file qemu-i386', this returns the following:
qemu-i386: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=6eb8212c719d65e515220256d3475bda038a0a13, for GNU/Linux 2.6.26, stripped

snooping around some other forums I think I may need to install a different interpreter for my linux release to run qemu-i386. I'll have a look into that, perhaps I'll start by reading up on what an interpreter is.
 

hippy

Technical Support
Staff member
snooping around some other forums I think I may need to install a different interpreter for my linux release to run qemu-i386. I'll have a look into that, perhaps I'll start by reading up on what an interpreter is
I have never been entirely clear on what "interpreter /lib/ld-linux-armhf.so.3" means when it comes to compiled Linux applications but am not convinced finding some other would make it work.

The issue could be that it is compiled as "ELF 32-bit LSB executable", and a 64-bit Linux won't run 32-bit Linux apps. But I am not sure why the error was "No such file or directory" rather than some 'cannot run it' error.

You can try "./qemu-i386 -version". It will be interesting to see what it reports -
Code:
pi@Pi3B:~/picaxe/bin $ ./qemu-i386 -version
qemu-i386 version 1.1.2, Copyright (c) 2003-2008 Fabrice Bellard
What I have installed seems to be what you have -
Code:
pi@Pi3B:~/picaxe/bin $ ls -l qemu-i386
-rwxr-xr-x 1 pi pi 1043272 Oct  5  2013 qemu-i386
pi@Pi3B:~/picaxe/bin $ file qemu-i386
qemu-i386: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, BuildID[sha1]=6eb8212c719d65e515220256d3475bda038a0a13, for GNU/Linux 2.6.26, stripped
 

hippy

Technical Support
Staff member
I am not sure why the error was "No such file or directory" rather than some 'cannot run it' error.
Seems this falls into the category of 'not very helpful error messages', and appears quite common when the program cannot run. It suggests what's being run is missing when it is in fact there.

Considering how often it must be asked, it seems impossible to get a simple, clear and straight answer to "how do I run the 32-bit app I have on 64-bit Pi OS?". Most threads go wildly off-topic, answer the wrong question, answer for X86. This is the best I could find ...

Code:
sudo dpkg --add-architecture armhf
sudo apt-get update
sudo apt-get install libc6:armhf
sudo ln -s /lib/ld-linux-armhf.so.3 /lib/ld-linux.so.3
So I guess that's the 'replace interpreter' option I wasn't convinced by.

It's probably worth a try, shouldn't cause a problem if it isn't, but, given I really don't know, be prepared to have to reinstall the OS if things do go badly wrong.
 
Top