Any desktop applications written for ARM?

[Mxster]

I was googling this and found nothing. I also Googled Linux for ARM. It seems at least a couple distros (Debian and Arch) have ARM ports. But I was wondering if there are any Linux distros built from thr ground up for ARM?

If you guys know something more about this than me, please share, thank you.

 

[Cerb]

No, and you won't find one any time soon. ARM is not like x86. You have commercial distros (Android) built for specific SoCs, and you have ports of multiplatform distros (like Debian and Fedora), which support a wide variety of ARM hardware, but take good advantage of very little.

With x86, generations always add. Old features may be slow, but they work. With ARM, old features may be gone. Multiple SoCs of the same generation could have wildly varying instruction support, will not all boot up the same way, may require the OS or application to have detailed knowledge of the hardware to safely function (such as software clock control for all parts of the chip...yuck), and so on.

Only in the last couple years has ARM started to coalesce their ISA features, that still only applies for ARMv7a SoCs (and future ARMv8), and they still haven't taken care of issues like booting, memory handling, interconnects, clock control, and so on. Some SoC makers have started doing good jobs at it with their newer chips (Qualcomm and NVidia), but it's still a giant mess, overall.

With x86, you can support a 386 as minimum ISA, allow optional newer extensions, optimize binaries for newer CPUs, and go on your merry way. No x86 mainstream CPU+chipset will fail to act like a 386. With x86_64, you still only have complications of supporting two chips correctly at a maximum, to get things working well enough (P4's x86_64, K8's x86_64).

http://www.nordichardware.com/news/69-cpu-chipset/43937-linus-torvalds-says-arm-is-disorganized.html
http://www.theinquirer.net/inquirer...ds-talks-discusses-arm-issues-linuxcon-europe

 

[Mxster]

No, and you won't find one any time soon. ARM is not like x86. You have commercial distros (Android) built for specific SoCs, and you have ports of multiplatform distros (like Debian and Fedora), which support a wide variety of ARM hardware, but take good advantage of very little.

With x86, generations always add. Old features may be slow, but they work. With ARM, old features may be gone. Multiple SoCs of the same generation could have wildly varying instruction support, will not all boot up the same way, may require the OS or application to have detailed knowledge of the hardware to safely function (such as software clock control for all parts of the chip...yuck), and so on.

Only in the last couple years has ARM started to coalesce their ISA features, that still only applies for ARMv7a SoCs (and future ARMv8), and they still haven't taken care of issues like booting, memory handling, interconnects, clock control, and so on. Some SoC makers have started doing good jobs at it with their newer chips (Qualcomm and NVidia), but it's still a giant mess, overall.

With x86, you can support a 386 as minimum ISA, allow optional newer extensions, optimize binaries for newer CPUs, and go on your merry way. No x86 mainstream CPU+chipset will fail to act like a 386. With x86_64, you still only have complications of supporting two chips correctly at a maximum, to get things working well enough (P4's x86_64, K8's x86_64).

http://www.nordichardware.com/news/69-cpu-chipset/43937-linus-torvalds-says-arm-is-disorganized.html

That makes sense.
http://www.theinquirer.net/inquirer...ds-talks-discusses-arm-issues-linuxcon-europe

That makes sense. So I'm guessing that because ARM has so much tied into SoC hardware, they aren't going to spend a whole lot of resources on coalescing the ISA across all their microprocessor families.

Thanks. Makes good sense.

 

[lamedude]

Most Linux programs probably compile for ARM, most WinRT programs likely will support ARM. If WOA allowed Win32 you could probably recompile most Windows programs for ARM too like MS did with Office.

 

[Cerb]

That makes sense. So I'm guessing that because ARM has so much tied into SoC hardware, they aren't going to spend a whole lot of resources on coalescing the ISA across all their microprocessor families.

They are, but they just started, maybe 2-3 years ago, and ARM themselves only have a small part of that SoC using their own tech (in Qualcomm's case, almost none of it).

Qualcomm, Samsung, TI, etc., license from various design companies, and do the final HW implementation themselves, often with some important in-house bits included. Then, they would typically do the work to get custom support for commercial OSes, and any useful documentation, which may expose internals they don't want to share, would at best only be available via NDA, which might prevent FOSS development.

Regular end users being able to use ARM boards like PCs, and 3rd-party developers being able to get documentation on the hardware to write software, rather than paying for the privilege, and being stuck with serious disclosure and development restrictions even if it works out (if you're not planning to sell products, chances are you wouldn't get anywhere), is a whole new thing to the likes of ARM and its licensees.

 

[chessdeviant]

What about the Distro's for the Raspberry Pi
http://elinux.org/RPi_Distributions

 

[Cogman]

They are, but they just started, maybe 2-3 years ago, and ARM themselves only have a small part of that SoC using their own tech (in Qualcomm's case, almost none of it).

Qualcomm, Samsung, TI, etc., license from various design companies, and do the final HW implementation themselves, often with some important in-house bits included. Then, they would typically do the work to get custom support for commercial OSes, and any useful documentation, which may expose internals they don't want to share, would at best only be available via NDA, which might prevent FOSS development.

Regular end users being able to use ARM boards like PCs, and 3rd-party developers being able to get documentation on the hardware to write software, rather than paying for the privilege, and being stuck with serious disclosure and development restrictions even if it works out (if you're not planning to sell products, chances are you wouldn't get anywhere), is a whole new thing to the likes of ARM and its licensees.

Ummmmmmmmm... What?

I would suggest you look up the beaglebone, beagleboard, pandaboard, rasberry pi, and several other platforms that are easily purchasable by a consumer (though, admittedly they aren't really marketed for that).

On all of these platforms, Ubuntu, android, windows CE and several other OSes are available.

I've personally used Ubuntu on the beaglebone and pandaboard. All the same packages that are available for the x86 version are available for the ARM version (there are a few exceptions, but I never ran into them).

 

[Cerb]

Ummmmmmmmm... What?

Where is the ARM made-for-these-good-SoCs equivalent to SimlyMEPIS, or PCLOS? Or, for that matter, Slack? Debian, Ubuntu, Fedora, etc., aren't made for ARM. I not once said there weren't ARM distros. Outside of video, they even work fairly well.

WinCE is not like Linux, and sucks (the latter part will hopefully go away w/ Win8).

Android is probably the closest to what I read the OP as asking about.

http://www.raspberrypi.org/faqs

But I demand the documentation for the chip. Give it to me!

To get the full SoC documentation you would need to sign an NDA with Broadcom, who make the chip and sell it to us. But you would also need to provide a business model and estimate of how many chips you are going to sell.

That is the common behavior. It is changing, luckily, but that's not the way it is for x86. For x86, you must, at worst, give Intel or AMD real contact information. Very little is left truly hidden, and practically nothing that anyone but big media companies care about.

http://www.raspberrypi.org/archives/615#comment-1107
Good things are occurring, though. That's only two months ago.

There are reasons for this kind of behavior, too. They design it not expecting non-commercial closed use, so since everyone with access to the HW signs an NDA anyway, they can expose internals that might give away secret sauce, or expose details they licensed under certain terms from some other company. That is a large part of what has been changing in a last couple years.

With ARMv8, and likely SoCs that share enough in terms of interface to need very little unique kernel code (read: manhours put into it), I wouldn't be surprised if we do start seeing ARM-specific optimized distros.

 

[Mxster]

Most Linux programs probably compile for ARM, most WinRT programs likely will support ARM. If WOA allowed Win32 you could probably recompile most Windows programs for ARM too like MS did with Office.

How does that even make sense? Linux app code is written for x86 ISA right? ARM processors are RISC architecture. You can't just compile those two interchangeably.

 

[Mxster]

What about the Distro's for the Raspberry Pi
http://elinux.org/RPi_Distributions

Cool link.

 

[Jodell88]

With Linux 99% percent of the time all you need to do is compile for the specific architecture.

 

[Cogman]

Where is the ARM made-for-these-good-SoCs equivalent to SimlyMEPIS, or PCLOS? Or, for that matter, Slack? Debian, Ubuntu, Fedora, etc., aren't made for ARM. I not once said there weren't ARM distros. Outside of video, they even work fairly well.

Only the first two OSes you listed don't have ARM ports...

Slackware http://www.armedslack.org/
Debian http://www.debian.org/ports/arm/
Ubuntu https://wiki.ubuntu.com/ARM
Fedora http://fedoraproject.org/wiki/Architectures/ARM (Not really complete yet.. It is in the alpha stage).

I've personally dealt with the Ubuntu ARM port. And as I said earlier, I never saw a package that was available only on x86 and not ARM. (though they do exist, they are generally the very obscure packages).

 

[Cerb]

Only the first two OSes you listed don't have ARM ports...

Exactly. The existence of multiplatform distros with ARM ports has been assumed to be known knowledge from the beginning of the thread.

It seems at least a couple distros (Debian and Arch) have ARM ports. But I was wondering if there are any Linux distros built from thr (sic) ground up for ARM? (em. added)

 

[Cogman]

Exactly.

... NM I see your point.

I guess I would just say that "built from the ground up" is really not that important.

 

[Cerb]

I guess I would just say that "built from the ground up" is really not that important.

That I would agree with. Most x86-specific distros, even, are x86 mainly because people use x86, so they want to optimize for certain CPU families, and other hardware, found mostly on x86 PCs, which is what they're going to own and use. The wider the range of compatibility, the more little optimizations either can't get attention, or can't get spare time put towards them, though, which are often a focus of these distros.

 

[lamedude]

Unless performance is important programs aren't written for any ISA. Its just C/C++ or some other portable language. Even when performance critical parts are writen using assembly, SSE or some ISA dependant feature there may be a C version of it that can be used for other platforms.
Every Mac program wasn't rewritten for the Intel, MS didn't rewrite Office for ARM tablets, and Doom gets ported to about everything.

 

[OBLAMA2009]

I was googling this and found nothing. I also Googled Linux for ARM. It seems at least a couple distros (Debian and Arch) have ARM ports. But I was wondering if there are any Linux distros built from thr ground up for ARM?

If you guys know something more about this than me, please share, thank you.

this wont happen for a long time because arm is so underpowered relative to x86 that no one would use such distributions when theyre used to running them on x86. just try out the motorola lapdock using the current dual core arm chips. its so awful it cant even run a browser decently, let alone multitask. windows 8 on arm will be a joke.

 

[Cogman]

this wont happen for a long time because arm is so underpowered relative to x86 that no one would use such distributions when theyre used to running them on x86. just try out the motorola lapdock using the current dual core arm chips. its so awful it cant even run a browser decently, let alone multitask. windows 8 on arm will be a joke.

Well, more the real reason it "won't happen" is because there is no point. The GCC has is a pretty good compiler that has support ARM since about forever. 99% of applications are straight C/C++ and don't do a single optimization that can be done only for the x86 architecture.

If your distro of choice supports ARM. Congratulations, it was built from the ground up to support ARM. That is one of the beauties of linux.

 

[Blades]

Well, more the real reason it "won't happen" is because there is no point. The GCC has is a pretty good compiler that has support ARM since about forever. 99% of applications are straight C/C++ and don't do a single optimization that can be done only for the x86 architecture.

If your distro of choice supports ARM. Congratulations, it was built from the ground up to support ARM. That is one of the beauties of linux.

I have a pandaboard oc'd to 1.5ghz running ubuntu (on usb rootfs).. the sd card io is probably a step above morse code.. its painful.. Eliminating the io speed issue (or trying to), running a raid0 usb disk array and it stll is slow.

If you want something optimized for arm (and don't mind unity - awfulness), www.linaro.org

You're not going to do much with it tho.. none of these soc dev boards support adding on ram. Hell, the pandaboard's 4460 (I have an ES) is ON the elpida memory chip. I suppose the most use mine got (or rather gets) is a native kernel compile for a couple android devices.

 

[Cerb]

99% of applications are straight C/C++ and don't do a single optimization that can be done only for the x86 architecture.

With x86_64, that's become true on our end. On anything from a Pentium Pro or Athlon or newer, you can feel the difference on a desktop between 386 and P3 binaries. With x86_64, deeply pipelined CPUs, with P6 and newer optimizations, including reasonable performance running Opteron-, Prescott-, and Conroe-optimized code, are baseline. Outside of trying to get the most from number crunching applications, there isn't nearly enough different between what our CPUs optimally run to worry about it, and that's not a bad thing.

 

[BrightCandle]

Even if an application does put in a specific x86 optimisation its quite likely its surrounded by a macro that will fall back to a general c algorithm to do the same thing. Apps don't start with assembler embedded in them, that gets added later to improve the performance in known hotspots.

The optimiser on modern GCC is actually pretty impressive. A study released literally a week ago showed on x86 we had been benefiting from about 3% increases year on year for the last decade, just from compiler improvements.