ACPI for ARM?

Posted Nov 22, 2013 16:17 UTC (Fri) by pwsan (subscriber, #56604)
Parent article: ACPI for ARM?

The article states:

> In the end, it will certainly work out; it is hard to imagine any significant class of ARM-based hardware being successful without solid Linux support.

This is just wrong.

From a open-source software hobbyist or hardware hobbyist point-of-view, there are strong and vibrant free-software development communities around the various ARM development boards in existence (e.g. BeagleBoards, etc.) The ARM folks are lucky to have a few commercial distributions that are pushing hard for more openness, rather than less. And from a commercial point of view, ARM-based, Linux-based hardware has clearly been quite successful given the number of Android devices in use.

The notion that "now the professionals from some industry associations from the PC world are coming in to make it all work" is patronizing, ignorant, and counter to the spirit of open source and free software. What it will mean, if such an endeavor is successful, is that large amounts of the platform code used to run these devices will become hidden, closed-source blobs, managed through magic firmware interfaces.

Readers may not realize it, but this is the current state of the x86 world today. Most x86 Linux users probably don't realize how little control they have over their hardware.

ACPI for ARM?

Posted Nov 22, 2013 16:27 UTC (Fri) by corbet (editor, #1) [Link] (4 responses)

Sorry but I'm wondering...what, exactly, do you think is wrong in the quoted text? I don't see any contradiction between that text and what you wrote...

ACPI for ARM?

Posted Nov 22, 2013 17:31 UTC (Fri) by pwsan (subscriber, #56604) [Link] (2 responses)

My concern, which was perhaps hastily expressed, is this: if the ARM server vendors are interested in solid Linux support for their Linux ARM servers that can work today, they can build DT files for their platforms, and get their drivers upstream. No ACPI needed. This process is working now for most of the existing ARM hardware. (Not that the whole ARM Linux DT effort is particularly great, but at least it's a partially community-driven process, conducted mostly in the open.)

So it's difficult to conclude that the desire for solid Linux support is what's motivating the effort to mandate ACPI/UEFI. This isn't just a matter of concern for hobbyists; it's also problematic for vendors or distributions that aren't part of the club, who have no influence over the "big boys" and must play by their rules.

ACPI for ARM?

Posted Nov 22, 2013 18:09 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (1 responses)

UEFI is meaningful, because it provides a standardised pre-boot environment. How do I configure an ARM device to perform a one-shot PXE boot? How do I run an OS-independent provisioning script? How do I ship an ARM device that supports booting off aftermarket third-party storage devices? ACPI, on the other hand, is an implementation detail. A system running with ACPI should appear identical to one running with some other firmware implementation, assuming appropriate kernel support. Lumping the two together isn't terribly helpful in terms of figuring out what the benefits are.

ACPI for ARM?

Posted Nov 22, 2013 18:21 UTC (Fri) by olof (subscriber, #11729) [Link]

People (myself included) have gotten used to referring to them as UEFI/ACPI because that's how it's sort of been presented (as "server requirements", in particular). It's clear from the patches posted that enabling UEFI is something we should do -- it's noninvasive and as you say it does bring real value. That was also covered in the thread the article refers to.

What I'm less sure about is the use of UEFI on embedded platforms, but that's a tangent to all this discussion.

So, there's mostly terminology misuse from the ARM side, mentally it's easy for us to group the two together when they're really completely different things.

ACPI for ARM?

Posted Nov 22, 2013 19:10 UTC (Fri) by pwsan (subscriber, #56604) [Link]

And by the way, my original comment was harsher than it should have been, and I regret that. For what it's worth, it wasn't focused at any individual, and certainly not Jon Corbet, but rather focused on a misperception about Linux and ARM that's rapidly becoming pervasive in some quarters.

That misperception is being used to justify a completely unrelated agenda that has nothing to do with Linux - it relates to platform control.