I am trying to download a Debian image for an ARM Cortex-A7 processor but I can't figure out which image to download. I have looked on the Debian website, and see three different downloads for ARM processor. What is the difference between them and which one should I download?
The ARM EABI (armel) port targets a range of older 32-bit ARM devices, particularly those used in NAS hardware and a variety of *plug computers.
The newer ARM hard-float (armhf) port supports newer, more powerful 32-bit devices using version 7 of the ARM architecture specification.
The 64-bit ARM (arm64) port supports the latest 64-bit ARM-powered devices.
Although this question is from late '15 it may still be useful to know.
So.. explaining the Debian offer requires a bit of background.
What you are talking about are the names of its official ARM ports. As you can see, they correspond to a specific triplet of ISA, OS and ABI options. These in turn are the least common multiple that can assure software compatibility of the compiled packages.
Putting aside the self-evident Arm64 build (exploiting the 64-bit mode of some ARMv8 cpu), I guess like most confusion arises from the other ones, all starting with arm-linux-.
Once upon a time, there actually just was a single "arm" target, but for a number of reasons ranging from endianness to floating point support and performance it has become obsoleted. EmbeddedABI (pretty empty moniker if you ask me technically speaking, but so ARM calls it) specification having since supplanted it flawlessly.
Armel is nothing else than a new name, to distinguish between both the old version, and the arm big-endian (then unofficial, now abandoned altogether) one. It should be considered the most basic, and it should run on just about any hardware under the sun.
On the other hand though, if your processor has a FPU that's not going to be used. Given before ARMv8 there was no guarantee for that to be supported (the majority of v7-A cores did, but the situation is direr the far behind you go with time), "maximum compatibility" entails any related instruction is getting referred to glibc soft-fp library (not to be confused with the softfp float-abi flag), not VFP.
And this is why, ultimately, Armhf was created. Userspace is yet again not link compatible, but you are getting as much speediness as possible. Albeit nothing was stopping them from using the aforementioned softfp instead (like Android does for example), allowing for both compatibility and an almost uncompromised access to floating point hardware.