Fedora Is Still Unsure About ARM Support

[phoronix]

Phoronix: Fedora Is Still Unsure About ARM Support

While Ubuntu support for ARM hardware is in great shape with Canonical investing significantly in the rapidly-growing ARM-based mobile market and the to-be-growing ARM server-space, plus other Linux distributions taking on ARM, official support for Fedora on ARM hasn't been quick to come by. In fact, Fedora developers still remain unconvinced about taking on ARM as a primary architecture...

http://www.phoronix.com/vr.php?view=MTA3ODA

[Delgarde]

Note that this discussion isn't about whether Fedora should support ARM - it should, and does. The discussion is purely about whether ARM should be elevated to the status of "primary architecture", which mostly means that it's held to the same standards as x86 and x86_64 - e.g bugs on ARM would be justification for blocking releases on *all* architectures, that sort of thing.

[AdamW]

Frankly I'd go a little further than delgarde: this is inaccurate, misleading and poorly researched.

Fedora has had ARM support for years, there is a dedicated and highly active SIG working on it, with both community members and Red Hat staff involved (RH has at least two people I know of working full time on Fedora ARM). there is nothing unofficial about the existing Fedora releases. Fedora is even the officially supported distro on the Raspberry Pi.

ARM is currently a secondary arch, which doesn't make it unofficial or unsupported. the practical effects are that ARM package builds happen separately from primary arch builds, and ARM releases are not tied to the main release schedule.

It isn't at all true to say that Fedora doesn't support ARM. FESCo was discussing whether to make it a primary arch. This article fundamentally misunderstood the situation.

[allquixotic]

The ARM SoC manufacturers, as a group, have a problem with closed hardware. ARM SoCs currently fall into one of two categories:

(1) Those for which some significant portion of the SoC is not officially documented by the manufacturer, and without any free drivers available, especially for the graphics core; this category encompasses a massive proportion of the chipsets being sold in smartphones, tablets and consoles to date (but even chips that fall into this category usually have open source, mainline Linux kernel support for the CPU, and perhaps even the audio code is in the ALSA SoC stuff).

(2) Those for which all of the critical components of the chipset are documented (CPU, MMU, networking, audio, video, I/O, and "wingdings" like vibrators/cameras/touchscreens) and/or have free drivers available. This category encompasses an extremely small subset of the chipsets available today; usually you only see chipsets built from the ground up with software freedom in mind belonging to this category.

Fedora, being a free distribution, should most likely focus their ARM efforts on the open minority of hardware out there; thus (2). The problem is that the market penetration of this hardware in devices that people actually use (development boards aside) is quite low. If you walk into a Verizon, AT&T, Sprint or Orange store (yes I went there to try and include non-US customers) you are not likely to find any "open hardware" phones on the shelves. If you walk into a Best Buy or Fry's, you are not likely to find any "open hardware" ARM tablets or netbooks or consoles. The devices being commercially advertised and sold as end-user products are not open hardware.

The consequence of trying to "liberate" hardware in (1) is that you end up fighting an uphill battle trying to support dozens of very different SoCs and graphics cores, with a reverse-engineering complexity greater than or equal to the Nouveau effort for each one. It's certainly possible to do this if you throw enough resources at it, but right now I don't think enough people are involved in these efforts to be notably successful. Worse, ARM SoCs are so quickly obsoleted by oncoming improvements that it's very likely that your reverse engineering efforts this year will be in vain, because the percentage of people still using that hardware in a year's time is going to be 50% of the original installed base, or less. This is due in part to the fact that smartphones and tablets are significantly less expensive than desktop and laptop computers, so they are more easily replaced when people are craving an upgrade. They also tend to experience more frequent accidental damage (drops, etc) which can motivate people to upgrade to a new phone if they don't have accidental damage insurance for their phone.

By contrast, the x86 platform looks very different: most or all of the x86 desktop and laptop chipsets are explicitly supported in the Linux kernel, either due to the direct involvement of the manufacturer, or an extremely vibrant reverse engineering community. The major CPUs by Intel and AMD are officially supported by said companies; ditto for motherboard chipsets. There are nice standards like Intel HDA codecs and USB Audio Class which make it fairly easy to add support for a new codec, even if it's a little different, with or without the manufacturer's support. And the major three x86 graphics vendors look good from an open hardware standpoint: Intel and AMD have official open source strategies; Nvidia has an extremely active RE community that has made significant progress on supporting popular desktop Nvidia chipsets.

Also, the physical issues of the mobile ARM devices don't exist: if you accidentally kick your desktop, chances are that you're going to hurt your foot more than you hurt your desktop So accidental damage is unlikely. This, coupled with the fact that people tend to upgrade desktops and laptops less frequently because (a) the hardware evolves slower, and (b) the hardware is far more expensive, results in old hardware "hanging around" for a very significant portion of the market in the 4 to 8 years range. Keeping a smartphone for 4 to 8 years is extremely rare, especially considering that most mobile contracts have a 2 year renewal period with a huge discount on a phone upgrade at the end of that two years.

So, if you take a random x86 desktop or laptop built in the last 8 years and see which of its hardware is supported by open source drivers in the latest Fedora release, your results are going to be surprisingly good. The CPU will, almost without exception, work flawlessly. The mainboard's core components will almost always work. Sound is very likely to work, unless you have a specialist add-on card or closed hardware (e.g. Creative). Video from Intel, AMD and Nvidia is almost guaranteed to work with software acceleration (no 3d); additionally, if your hardware is older than the very latest generation, it is almost guaranteed to have 3d support in some capacity. Input devices -- which are primary USB based for x86 systems -- are practically guaranteed to work.

This is all without a tainted kernel, which is what Fedora needs to give the green light on the hardware. Thus, Fedora is very happy to support x86(_64) as a primary microarchitecture, because so much effort is expended to officially support all aspects of modern x86 systems in the Linux kernel.

When you take the praise I've just said about x86 and compare it to ARM, it's obvious that ARM has a long, long, LONG way to go before it's even a shadow of x86 in terms of open hardware and open drivers. So, it comes as no surprise to me that some Fedora contributors would be against supporting ARM as a primary microarchitecture at this time.

[AdamW]

allquixotic: that's really less of an issue than you suggest; Fedora ARM does mostly focus on open devices, and there are more of these than you seem to think. It's just that few of them are consumer tablets or phones. Fedora ARM is mostly working on stuff like the Trimslice, Pi, BeagleBoard and so on. The two most significant ARM platforms for Fedora are likely to be the Pi and the OLPC XO 1.75 and 3, both of which are ARM-based and run Fedora.

There will be hundreds of thousands of ARM-based XOs running Fedora out in the wild within a pretty short space of time.

There is an open source driver for the Mali graphics adapter used in the ARM XOs. Several consumer devices are also coming to market in the near future which use the same adapter. So there will be interesting ARM consumer hardware with an open source graphics driver, Real Soon Now.

[schlobinux]

There is an open source driver for the Mali graphics adapter used in the ARM XOs.

The XO 1.75 will not use a Mali graphic adapter, but a Vivante one. Last I heard, there is no FOSS driver for Vivante, but it should appear later.