ARM binaries for command line compilers?

bogbean

Well-known member
Thanks for having a dig around for me. I'm not able to see version info for qemu...
Code:
pi@raspberrypi:~/Documents/picaxe/picaxe/bin $ ./qemu-i386 -version
bash: ./qemu-i386: No such file or directory
I will go through the forum post you linked so I understand more about what could be the problem. I have run the 4 commands you suggested, I think it's shifted the issue onto something else...
Code:
pi@raspberrypi:~/Documents/picaxe/picaxe/bin $ ./picaxe08m2 -h
./qemu-i386: error while loading shared libraries: libgthread-2.0.so.0: cannot open shared object file: No such file or directory
I'm wondering if there is a bunch of 32-bit stuff I don't have on my machine. libgthread-2.0.so.0 is there but I get the original unhelpful error message...
Code:
pi@raspberrypi:~/Documents/picaxe/picaxe/bin $ file /usr/lib/aarch64-linux-gnu/libgthread*
/usr/lib/aarch64-linux-gnu/libgthread-2.0.a:           current ar archive
/usr/lib/aarch64-linux-gnu/libgthread-2.0.so:          symbolic link to libgthread-2.0.so.0
/usr/lib/aarch64-linux-gnu/libgthread-2.0.so.0:        symbolic link to libgthread-2.0.so.0.6600.8
/usr/lib/aarch64-linux-gnu/libgthread-2.0.so.0.6600.8: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, BuildID[sha1]=e56f4cbb202b0860e3e378d5dcfcca6a8880290d, stripped
This isn't terminal for my picaxe days as I do have an old laptop I can run PE6 on.
 

Flenser

Senior Member
pi@raspberrypi:~/Documents/picaxe/picaxe/bin $ ./qemu-i386 -version
bash: ./qemu-i386: No such file or directory
This means that the qemu-i386 file does not exist in the directory that you specified, which was ~/Documents/picaxe/picaxe

To find if the file qemu-i386 does exist on your linux installation, and where it is, use this command:
find / -name qemu-i386
 

hippy

Technical Support
Staff member
Code:
pi@raspberrypi:~/Documents/picaxe/picaxe/bin $ ./qemu-i386 -version
bash: ./qemu-i386: No such file or directory
This means that the qemu-i386 file does not exist in the directory that you specified, which was ~/Documents/picaxe/picaxe
On the contrary, I believe the file actually does exist and it's a less than useful error message which suggests it doesn't when it does.

These two will prove it does exist -

ls -l ./qemu-i386
file ./qemu-i386

so any 'no such file or directory' would not be correct when it comes to -

./qemu-i386

I suspect the program loader is finding './qemu-i386', but then cannot find the interpreter or other file it is linked against, is saying that doesn't exist rather than './qemu-i386' itself. But that's just my guess.

I'm wondering if there is a bunch of 32-bit stuff I don't have on my machine.
I suspect so. I have no idea how one gets what's missing or satisfies those dependencies, or even discovers what those would be.

I was going to suggest it may be possible to just get a './qemu-i386' which has been compiled for 64-bit which should just run, but fanoush indicates in Post #4 they had to recompile it from source to make it do all that is needed. It looks to me that someone would have to do the same to create a 64-bit './qemu-i386' for running the PICAXE compilers.

It might be worth trying a 64-bit './qemu-i386' to see if that at least runs the compilers even if it doesn't allow downloads.
 

bogbean

Well-known member
After looking at this site: https://wiki.debian.org/RaspberryPi/qemu-user-static
I installed qemu-user-static like this:
Code:
sudo apt-get install -y qemu qemu-user-static
one of the binaries this installed was qemu-i386-static. Several other qemu binaries were installed too and took up a fair amount of space. If I knew what I was doing a bit more I suspect I could have just installed the -i386 variant.

I've modified the last line of my /picaxe/bin/wrapper file to the following so it uses the newly-installed qemu-i386-static (I wasn't confident to move it to the current folder).
Code:
qemu-i386-static -L ${DIR}/../i386 ${DIR}/../i386/compilers/${CMD} $*
And the following command now displays the picaxe compiler help info. :)
Code:
./picaxe08m2 -h
So that was a very promising start. It successfully downloaded the test.bas programme too and returned serial text to the terminal. Good idea to find a proper 64-bit qemu-i386! I hope this post may be of help to any others programming a picaxe from a raspberry pi since the recommended OS may go to 64 bit soon.
 
Last edited:

steliosm

Senior Member
Of course, it would be great if RevEd would actually produce command line compiler binaries for Rpi. Not sure why they pretend that RPi doesn't exist.
 

hippy

Technical Support
Staff member
Not sure why they pretend that RPi doesn't exist.
It should be pretty clear that there is no pretending the Raspberry PI doesn't exist.

At the end of the proverbial day it doesn't really matter how compilation and downloading using a Raspberry Pi is achieved so much as it working.

Code:
sudo apt-get install -y qemu qemu-user-static
I've modified the last line of my /picaxe/bin/wrapper file to the following so it uses the newly-installed qemu-i386-static (I wasn't confident to move it to the current folder).
Code:
qemu-i386-static -L ${DIR}/../i386 ${DIR}/../i386/compilers/${CMD} $*
And the following command now displays the picaxe compiler help info. :) So that was a very promising start. It successfully downloaded the test.bas programme too and returned serial text to the terminal. Good idea to find a proper 64-bit qemu-i386!
That is great news and it seems you have found the solution. Well done and thanks for persevering, getting things to work..

There is no need to move the 'qemu-i386-static ' to the PICAXE directory and arguably better to not do that. I believe the main reason the './qemu-i386' was a local copy is that's it's a specially compiled version rather than a system provided version.

I would consider the 'qemu-i386-static' to be "a proper 64-bit qemu-i386" so wouldn't worry what else could be used. There may be some more optimal or smaller install but for most people that's probably not a necessity.
 

bogbean

Well-known member
I find that when I download a program to a picaxe using the command line compilers with my Raspberry Pi I am then unable to download a program again unless I disconnect and reconnect my AXE027 cable from the RPi's USB port. This in an inconvenience but something I could live with. The error I receive is Error: Hardware not found on /dev/ttyUSB0!
I confirm my AXE027 cable is seen to be present as /dev/ttyUSB0

I also can't initiate a download when applying the hard reset sequence, even if the AXE027 has been freshly unplugged/reconnected. This could occasionally be a problem if I'm unable to do hard resets.

Using the following sequence I'm able to achieve reliable downloads:
1) unplug & reconnect AXE027 from USB port
2) ensure picaxe is powered
3) enter command to begin downloading

I have an ancient laptop with PE6 using Windows 7 and with that I am able to perform hard resets and multiple program downloading without having to unplug & reconnect the AXE027 cable, so I don't think it's a cable issue.

I wondered if either of these were known issues. I didn't find it reported on the forum but I'm not sure many are using a RPi.
 

bogbean

Well-known member
Yes, I'm running the wrappers provided by fanoush to run the Rev-ed compilers using qemu. The compiler is running fine but returns Error: Hardware not found on /dev/ttyUSB0!

I'm now wondering if something is wrong on the RPi end because the 3 step sequence I described in post 47 has become less reliable now to the point I can barely download anything (strangely, after downloading a program using PE6 on a windows machine I am then able to successfully download a program once from the RPi but then no more).

I'll go back to the ancient windows laptop, at least it gives me PE6.
 

hippy

Technical Support
Staff member
I also can't initiate a download when applying the hard reset sequence, even if the AXE027 has been freshly unplugged/reconnected. This could occasionally be a problem if I'm unable to do hard resets.
That sounds to me more likely an issue with getting the timing of Hard Reset right than an issue with the command line compilers. I would try with a simple program which should allow subsequent downloads and see if repeated downloads do work -
Code:
Do
  Pause 1000
Loop
You could add a "TOGGLE X.Y" command in the loop if you have a LED on your hardware.

If that accepts repeated downloads then it probably is a Hard Reset timing issue. If that doesn't work then details of Pi model, operating system used, version, Stretch, Buster or Bullseye, 32-bit or 64-bit, whether you have 'qemu-i386-static' installed or not will help investigation or figuring out what may not be working.
 

bogbean

Well-known member
I'm using a Raspberry Pi 4 Model B Rev 1.4 with 8GB of RAM
The OS is Debian GNU/Linux 11 (bullseye) 64 bit
I have qemu-i386-static installed (using the steps described in post #44)

My question can be retired because I had over-voltaged the AXE027 and 08M2! Both then worked sporadically from my RPi but now not at all, the compiler returns Error: Hardware not found on /dev/ttyUSB0!

The AXE027 and 08M2 both work fine from PE6 on a windows machine just not from my RPi.
Lesson learned: don't leave 9V batteries within reach on my desk. Thanks for the support, apologies for wasting peoples time!
 

hippy

Technical Support
Staff member
Thanks for the support, apologies for wasting peoples time!
Please don't worry about it. Knowing why something didn't work is always useful to have on the list of potential causes should others encounter similar problems. So thanks for letting us know.

It is intriguing it all still works on Windows. Does that mean it's the Pi which has been 'damaged' in some way ?
 

bogbean

Well-known member
It is intriguing it all still works on Windows. Does that mean it's the Pi which has been 'damaged' in some way ?
The Pi seems ok: mouse and keyboard work on all 4 USB ports and I can draw 500mA from all of them too using a USB load tester.
I just performed a successful single (one only, I tried several) download of a helloWorld program from the Pi to the 08M2 that was overvoltaged using the AXE027 that was overvoltaged
Code:
main:
high c.2
pause 1000
low c.2
pause 1000
goto main
So the 08M2 seems to have survived although perhaps there is damage not shown by this limited test. I have marked this 08M2 with a blob of paint for future reference.

Also of interest is that when I wrote post #47 I had been successfully downloading programs when powered at 9V! Although it did only work when I followed that exact sequence.
 
Top