Dear all,
I have looked through the forum looking for a similar thread but I have not found it. Please excuse me if the question is repeated. Also excuse me if my English has some mistakes as it is not my first language.
I am quite newbie to ARM programing but I would like to know if migration among similar architectures is possible. I would like to know if a program developed in other system (for example Pandaboard) running in a linux distribution could be migrated to RaspberryPi using the very same distribution. Is that possible? What changes should be done?
Bst
Diego.
Re: ARM Architectures migration
well i know that as long as they are the same architecture (like i think CPU on the Rpi is an armv7 architecture) then it will run on all cpu's of that architecture
i believe there is also a way to compile for generic arm?
i believe there is also a way to compile for generic arm?
Re: ARM Architectures migration
The Pandaboard and the ES model are built around the OMAP processor which is based upon the Cortex A9 processor. There will be some apps that will run on both and then some that only run on the Pandaboard. There are two reasons for this.. One is feature set, being that the Cortex series is a newer ARM design it will have all of what the older processors have plus some new stuff, and Two, The performance aspect, the OMAP SOC used on the Pandaboard has two processor cores whereas the R-Pi has one, in addition to this both cores also run at 1Ghz (1.2Ghz for the ES model.) The arm core in the Pandaboard's SOC will also outperform the R-Pi's SOC by a factor of at least 1.5 on a clock per clock basis (IPC.)
So the answer is not quite straight forward. There will be some cross compatable software out there. There will be some that will just need a simple re-compile with the proper toolchain. Then there will be some that needs the newer feature set or performance of the Cortex A9 cores.
So the answer is not quite straight forward. There will be some cross compatable software out there. There will be some that will just need a simple re-compile with the proper toolchain. Then there will be some that needs the newer feature set or performance of the Cortex A9 cores.
-
johnbeetem
- Posts: 945
- Joined: Mon Oct 17, 2011 11:18 pm
- Location: The Mountains
- Contact: Website
Re: ARM Architectures migration
Wikipedia has a good introduction to ARM architecture, i.e., instruction set: http://en.wikipedia.org/wiki/ARM
ARM architecture varies a lot from version to version. Generally, binaries are upward compatible from an earlier version -- e.g., ARMv5 -- to later versions such as ARMv6 and ARMv7. RasPi is ARMv6. BeagleBoard and most tablets are ARMv7.
However, it gets pretty complicated when you bring in hardware versus software floating point and which ABI (application binary interface) is used. [The ABI specifies register usage and function calling conventions.] These must be compatible with the shared libraries on the operating system you are using. Relying on binaries that were compiled for anything other than RasPi is likely to be a problem. Recompiling from source is generally a lot safer.
Until recently, ARM has not been used much for general-purpose computers. ARM has mostly been used in cell phones and other portable devices which run a single program provided by the manufacturer plus interpreted apps. The manufacturer only had to compile the program for one version of ARM at a time so cross-architecture considerations weren't a problem.
ARM architecture varies a lot from version to version. Generally, binaries are upward compatible from an earlier version -- e.g., ARMv5 -- to later versions such as ARMv6 and ARMv7. RasPi is ARMv6. BeagleBoard and most tablets are ARMv7.
However, it gets pretty complicated when you bring in hardware versus software floating point and which ABI (application binary interface) is used. [The ABI specifies register usage and function calling conventions.] These must be compatible with the shared libraries on the operating system you are using. Relying on binaries that were compiled for anything other than RasPi is likely to be a problem. Recompiling from source is generally a lot safer.
Until recently, ARM has not been used much for general-purpose computers. ARM has mostly been used in cell phones and other portable devices which run a single program provided by the manufacturer plus interpreted apps. The manufacturer only had to compile the program for one version of ARM at a time so cross-architecture considerations weren't a problem.
Re: ARM Architectures migration
First of all, let me thank all you your answers.
Then, it seems "possible", but not straight forward
Thanks a lot for everything!
Best,
Diego
Then, it seems "possible", but not straight forward
Thanks a lot for everything!
Best,
Diego
Re: ARM Architectures migration
For a binary to run correctly it must be compatible with your processor and your libraries. Further your libraries must be compatible with your kernel. It doesn't really make much sense to talk of a "raspberry pi binary".
For a binary to be compatible with the processor it must only use instructions the processor has. To be compatible with your libaries it must use the right calling conventions and binary formats (the "C abi"). For a library (or application that performs syscalls directly) to be compatible with your kernel it must perform syscalls in the correct way. Normally a C abi and a syscall ABI go together though there may be more than one C abi using the same syscall ABI (for example there is regular EABI and EABI hardfloat C abis but they both use the same syscall ABI). Kernels may support more than one syscall abi (for example most eabi kernels also support oldabi so you can have an oldabi chroot on an eabi system just like the way in the PC world you can have an i386 chroot on an amd64 system)
The default compile options of the compilers shipped with a port of a distro are usually set to produce binaries that will run on. So if you are running debian armel on both your pandaboard and your pi and you don't pass compile options that influence the instruction set used you should be able to move binaries between them with no problems.
One distro may have multiple arm ports, Since i'm a debian guy i'll explain how things are done in debian, Debian has had (at least) four arm ports done with incompatible ABIs. Of these three have been in the official archive and two have been included in official releases.
arm: this was the original arm port using the old "GNU abi", unfortunately it had terrible floating point performance because it was relying on kernel emulation of a FPU that hardly any real hardware actually had and because it used a calling convention that used FPU registers they couldn't migrate away without creating a new port. It was included as an official release architecture from 2.2 (potato) to 5.0 (lenny) inclusive. I'm not sure exactly what CPUs were supported.
armeb: this was a big endian port based on openslug's binary specifications and targeted at the NSLU2 and similar devices but afaict it was largely abandoned after people worked out how to get a little endian kernel running on the slug. It was never in the official archive.
armel: this is the "eabi softfloat" port and is currently the main arm port of debian, It has been included in the 5.0 (lenny) and 6.0 (squeeze) stable releases and should continue to be included for the foreseeable future. It supports armv4t and up.
armhf: this is the "eabi vfp" port. It should provide better performance on modern hardware than armel due to both being compiled for a newer processor core and making use of the floating point hardware. It requires a processor that supports the armv7 core instruction set and the vfp3 floating point instruction set. It is a new port and it is hoped it will be included in the next stable release.
armel will certainly run on the pi, Unfortunately I think the CPU on the pi is only armv6 so debian armhf probably won't be compatible (though it should possible to build an eabi hardfloat distro that is compatible).
P.S. Note that ubuntu use the names armel for ports that use the same ABI as the debian ports mentioned above but have different processor requirements (just as the debian i386 port and ubuntu i386 port use the same ABI but have different processor requirements).
P.P.S. arm confusingly has two seperate numbering systems, arm<n> reffers to processor core designs while armv<n> reffers to instruction sets. So for example te arm11 processor core implements the armv6 instruction set.
Edit: sorry arm11 is armv6 not armv7.
For a binary to be compatible with the processor it must only use instructions the processor has. To be compatible with your libaries it must use the right calling conventions and binary formats (the "C abi"). For a library (or application that performs syscalls directly) to be compatible with your kernel it must perform syscalls in the correct way. Normally a C abi and a syscall ABI go together though there may be more than one C abi using the same syscall ABI (for example there is regular EABI and EABI hardfloat C abis but they both use the same syscall ABI). Kernels may support more than one syscall abi (for example most eabi kernels also support oldabi so you can have an oldabi chroot on an eabi system just like the way in the PC world you can have an i386 chroot on an amd64 system)
The default compile options of the compilers shipped with a port of a distro are usually set to produce binaries that will run on. So if you are running debian armel on both your pandaboard and your pi and you don't pass compile options that influence the instruction set used you should be able to move binaries between them with no problems.
One distro may have multiple arm ports, Since i'm a debian guy i'll explain how things are done in debian, Debian has had (at least) four arm ports done with incompatible ABIs. Of these three have been in the official archive and two have been included in official releases.
arm: this was the original arm port using the old "GNU abi", unfortunately it had terrible floating point performance because it was relying on kernel emulation of a FPU that hardly any real hardware actually had and because it used a calling convention that used FPU registers they couldn't migrate away without creating a new port. It was included as an official release architecture from 2.2 (potato) to 5.0 (lenny) inclusive. I'm not sure exactly what CPUs were supported.
armeb: this was a big endian port based on openslug's binary specifications and targeted at the NSLU2 and similar devices but afaict it was largely abandoned after people worked out how to get a little endian kernel running on the slug. It was never in the official archive.
armel: this is the "eabi softfloat" port and is currently the main arm port of debian, It has been included in the 5.0 (lenny) and 6.0 (squeeze) stable releases and should continue to be included for the foreseeable future. It supports armv4t and up.
armhf: this is the "eabi vfp" port. It should provide better performance on modern hardware than armel due to both being compiled for a newer processor core and making use of the floating point hardware. It requires a processor that supports the armv7 core instruction set and the vfp3 floating point instruction set. It is a new port and it is hoped it will be included in the next stable release.
armel will certainly run on the pi, Unfortunately I think the CPU on the pi is only armv6 so debian armhf probably won't be compatible (though it should possible to build an eabi hardfloat distro that is compatible).
P.S. Note that ubuntu use the names armel for ports that use the same ABI as the debian ports mentioned above but have different processor requirements (just as the debian i386 port and ubuntu i386 port use the same ABI but have different processor requirements).
P.P.S. arm confusingly has two seperate numbering systems, arm<n> reffers to processor core designs while armv<n> reffers to instruction sets. So for example te arm11 processor core implements the armv6 instruction set.
Edit: sorry arm11 is armv6 not armv7.