ARM7 program for Raspberry Pi 1 B

What happens if, on a Raspberry Pi 1B, I try to run a program with ARM7 code? Anything specific like it refuses to run it or segfaults or???

--
Thanks, 
David 
 Click to see the full signature
Reply to
David Taylor
Loading thread data ...

If by ARM7, you are referring to the ARM32 instruction set widely used in embedded chips, then it will probably run ... but.

Each variant of the ARM instruction set has restrictions on the 32 bit "classic" instruction set. The details are in the instruction set reference manuals. For the ARM1176JZF-S you need the ARM6 manual. I found one at

formatting link
or you could hunt on the ARM web site after registering.

Look for anything that includes UNPREDICTABLE.

Stephen

--
Stephen Pelc, stephen@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

???

Most compilers targetting ARMv7 produce Thumb2 code, which is a mix of

16bit Thumb and 32bit ARM instructions. ARMv6 only has 32 bit ARM and Thumb 1, so will probably segfault straight away.

---druck

Reply to
druck

Thanks. I keep getting "illegal instruction" even when I try different compiler options. Compiling on the RPi 1B for running on the RPI 1B. Sigh!

--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

Thanks, Stephen. I'm referring to the Raspberry Pi 1B's processor, but with the Buster OS installed. However, I shouldn't need to delve into the references you've kindly given to get a simple C program working when compiling and running on the 1B.

--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

If you are doing a straight compile (using gcc or g++) on your Pi to create an executable program for the Pi then I'd expect it to 'just work', no special compiler options or anything required.

An "illegal instruction" error doesn't necessarily mean the compiler has generated an illegal instruction, it may just mean you have a bug in your program so that you are trying to execute something that isn't code.

I'd certainly be looking for a bug in my proram before looking for esoteric compiler issues. :-)

--
Chris Green
Reply to
Chris Green

There's probably a command line switch to select the ARMv6 instruction set. Some guru here will know what it is.

Stephen

--
Stephen Pelc, stephen@mpeforth.com 
MicroProcessor Engineering Ltd - More Real, Less Time 
 Click to see the full signature
Reply to
Stephen Pelc

On 26/05/2020 09:20, Chris Green wrote: []

Thanks, Chris. It's not the program, but the link option. If I make a "Hello World" program it fails when using the same link option (-lgps) and not when that option is removed. I've checked the library and it appears to be OK - it's the one generated at the same time as I built gpsd from gitlab.

The support programs like cgps and ubxtool were built at the same time /presumably/ using the same library, but I'm now trying to find the link options used to build those programs.

--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

Thanks, Steven, and I found it, but it makes no difference. See my other reply.

--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

ults

erent

1B.

The code you are compiling will be ARMv6 unless you explicitly tell the compiler to do something else with -march or mcpu. What is probably happening is you are trying to link again a pre-built ARMv7 library.

You either build everything on that machine, and make sure you have not brought across any static or shared libraries from an ARMv7 machine.

I had the same problem when once when I copied some stuff from a Pi 2B (ARMv7) to a Pi Zero (ARMv6).

---druck

Reply to
druck

Yes, suggests that for some reason it's *linking* to a bad library. I'm surprised that "Hello World" fails though as it surely is using hardly any libraries.

Though, wait a minute, isn't it just telling you there's a bug in the library (same way as I was saying in my original message). The "illegal instruction" is just the bug in the library code trying to execute something it shouldn't.

--
Chris Green
Reply to
Chris Green

On Tue, 26 May 2020 05:40:55 +0100, David Taylor declaimed the following:

Out of curiosity, what FLOATING POINT option are you specifying?

formatting link
(applies to pure Debian, mostly) """ Raspberry Pi 1 (A, B, A+, B+, Zero, Zero W)

The systems now known as Raspberry Pi model 1 models A and B were announced in February 2012. This family was expanded by very similar models A+ and B+. In 2015, the Zero model was announced, using the same CPU as the 1 family but with a smaller form factor, followed by the Zero W, which adds wireless connectivity.

The first generation Raspberry systems work using Debian armel. The Zero uses the same SoC/CPU as the first version, so they should function identically. """

Though confusingly...

""" Debian and Raspbian

The most often used distribution across all raspberries is Raspbian. This is, first of all, for historical reasons (booting a mainline Debian kernel was not supported on Raspberries until late 2018), but also because of other non-free components that are shipped as part of Raspbian (such as Oracle Java and Wolfram Mathematica).

Raspbian builds a single image for all of the Raspberry families, so you will get an armhf 32-bit, hard floating-point system, but built for the ARMv6 ISA (with VFP2), unlike Debian's ARMv7 ISA (with VFP3) port. """

--
	Wulfraed                 Dennis Lee Bieber         AF6VN 
	wlfraed@ix.netcom.com    http://wlfraed.microdiversity.freeddns.org/
Reply to
Dennis Lee Bieber

On 26/05/2020 14:01, Chris Green wrote: []

Agreed, and it could be that I'm linking against an ARMv7 library but running on ARMv6. The programs in the suite I've tested (the gpsd service itself, cgps and ubxtool) all work as expected, so they must have been linked slightly differently than the simple -lgps that I'm testing with.

This is rather beyond the level of (Linux) knowledge I have or normally need. Sudo apt-get install normally does me nicely!

--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

On 26/05/2020 12:19, druck wrote: []

Agreed - it's resolving the library or linking issues. I guess we have the same problem on Windows when newer software relies on the greater range of functions on newer processors, and the 32/64 differences of course.

History: I need particular support for a u-blox MAX-M8Q which is in gpsd

3.20, but Buster only includes gpsd 3.17 (like its NTP support in way behind) and I was advised to compile from the source, which works correctly, except that my own software compiled against the same source fails. Do all this on a RasPi-4B and it all works including my own software. I had tried backports but I guess that doesn't [yet] support older processors. Or something.
--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

On 26/05/2020 14:54, Dennis Lee Bieber wrote: []

I'm not specifying any particular FP option, partially due to not having considered that, and more recently having been told that "Building on the target system" the options will be correct. Other programs in the gpsd suite have built and function correctly, so I'm thinking incompatible libraries rather than compiler options.

--
Cheers, 
David 
 Click to see the full signature
Reply to
David Taylor

It may very well be the bit of library that calls main():

There's a lot of crap happens before the processor even gets to execute your code.

I have no idea how to ensurer THAT library is invoked correctly because its pretty invisible

--
?But what a weak barrier is truth when it stands in the way of an  
hypothesis!? 
 Click to see the full signature
Reply to
The Natural Philosopher

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.