ACPI for ARM?

By Jonathan Corbet
November 22, 2013

The "Advanced Configuration and Power Interface" (ACPI) was not an obvious win when support for it was first merged into the mainline kernel. The standard was new, actual implementations were unreliable, and supporting it involved bringing a large virtual machine into the kernel. For years, booting with ACPI disabled was the first response to a wide range of problems; one can still find web sites advising readers to do that. But, for the most part, ACPI has settled in as a mandatory part of the PC platform standard. Now, however, it appears that a similar story may be about to play out in the ARM world.

Arguments for and against ACPI

There have been rumblings for a few years that ACPI would start to appear in ARM-based systems, and in server systems in particular. Recently, some code to support such systems has started to make the rounds; Olof Johansson, a co-maintainer of the arm-soc tree, looked at this code and didn't like what he saw:

The more I start to see early UEFI/ACPI code, the more I am certain that we want none of that crap in the kernel. It's making things considerably messier, while we're already very busy trying to convert everything over and enable DT -- we'll be preempting that effort just to add even more boilerplate everywhere and total progress will be hurt.

In this message and several followups Olof clarified what he was trying to get across. The ARM world already has a mechanism to describe the hardware — device trees — that is only now coming into focus. Adding device tree support has required making changes to a large amount of platform and driver code; supporting ACPI threatens to bring just as much work and add a second code path for system configuration that will need to be maintained forever. Even worse is the fact that there are no established standards for ACPI in the ARM setting; nobody really knows how things are supposed to work, and what is coming out in the early stages is not encouraging. Bringing in ARM ACPI support now would be committing the kernel community to supporting a moving target indefinitely.

Olof went on to suggest that it might be best to wait for others to figure out how ACPI on ARM is supposed to work:

Oh wait, there's people who have been doing this for years. Microsoft. They should be the ones driving this and taking the pain for it. Once the platform is enabled for their needs, we'll sort it out at our end. After all, that has worked reasonably well for x86 platforms.

He added that, until there are ACPI systems shipping with Windows and working well, the Linux community should stay far away from ACPI on ARM. If ACPI-based systems actually hit the market, he said, they can be supported with a pre-boot layer that translates the system's ACPI tables into the device tree format.

Disagreement with this position came in a couple of forms. Several people point out that standards developed by Microsoft may not suit the Linux community as well as we might like. As Mark Rutland (a device tree bindings maintainer) put it:

I'm not sure it's entirely reasonable to assume that Microsoft will swoop in and develop standards that are useful to us or even applicable to the vast majority of the systems that are likely to exist. If they do, then we will (by the expectation that Linux should be able to run wherever another OS can) have to support whatever standards they may create.

Russell King added another point echoed by many: refusing to support ACPI could cost the community its chance to influence (or even control) how the standard evolves. In his words:

We have a possibility here to define how we'd like ACPI to look: we have the chance to have ACPI properties using the same naming that we already have for DT.

Shutting the door on ACPI, Russell asserted, would be a move that the community would regret in the long term.

Jon Masters joined the conversation to make the claim that ARM-based servers were committed to the ACPI path, saying "all of the big boys are going to be using ACPI whether it's liked much or not". He said that the server space requires a mechanism that has been standardized and set in stone, and that, in his opinion, the device tree abstraction is far too unstable to be usable (a claim that Grant Likely strongly disagreed with). Red Hat, Jon said, is fully behind ACPI on ARM servers for all of the products that it has absolutely not said it will ever offer. Jon's wording, along with his suggestion that everything has already been decided in NDA-protected conference rooms, won him few friends in this discussion, but his point remains: there will be systems using ACPI on the market, and Linux has to deal with them somehow.

What to do

But that still doesn't answer the question of how to deal with them. Arnd Bergmann suggested that ACPI might not be a long-term issue for the ARM community:

I think we can still treat ACPI on ARM64 as a beginner's mistake and provide hand-written DT blobs for the few systems that start shipping with that. The main reason for doing it in the first place was the expected number of Windows RT servers, but WinRT isn't doing well at the moment, so it's not unreasonable to assume it's going the same way as WinRT tablets.

Most people, though, seemed to think that ACPI could be here to stay, so the community will have to figure out some way of dealing with it.

One possibility might be Olof's idea of translating the ACPI tables into a device tree, but that approach was somewhat unpopular. It looks to many like a partial answer to the problem that would run into no end of problems; there is also the matter of running the ACPI Machine Language (AML) code found in the ACPI firmware. AML can be necessary for hardware initialization and power management tasks, but it has no analog in the device tree world. Generally, there was a sentiment that, if ACPI is to be supported on ARM systems, it should be supported properly and not behind some sort of translation layer.

In the short term, some sort of translation to device trees — either at boot-time or done by hand — seems likely to be the outcome, though. Putting code into the kernel to support any ACPI-based systems that might appear in the near future just seems to many like a way to take on a long-term support burden for short-lived systems. What might start to tip the balance could be systems which, as Arnd described them, are "PCs with their x86 CPU removed and an ARM chip put in there"; adding ACPI support for those would be "harmless enough", he said. But Arnd seems to be strongly against adding ACPI support for complicated ARM-style systems.

Longer-term, the community is likely to watch and wait. Efforts will be made to direct the evolution of ACPI for ARM systems; Linaro, in particular, has developers engaged with that process now. And even Olof is open to bringing in ACPI support at some point in the future, once its supporters "seem to have their act together, have worked out their kinks and reached a usable stable platform". But that, he says, could be a couple of years from now.

Microsoft, through its dominance of the market for software on PC-class systems, was able to push hardware standards in directions it liked. In the ARM world, Linux dominates just as strongly, so it seems a bit surprising to be playing catch-up with shifts in the ARM platform in this way. Part of the problem, of course, is that there is no single Linux voice at the standards table; companies like Linaro and Red Hat are working on the problem, but they do not represent, or seemingly even talk to, the rest of the community on this topic. The fact that much of this work is done under non-disclosure agreements does not help; NDAs do not fit well with how community development is done.

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. It's mostly a matter of how much short- and long-term pain will have to be endured to make that support happen. For all the early complaining, ACPI has mostly worked out in the x86 world; it may well find a useful role in the ARM market as well.

Index entries for this article
Kernel	ACPI
Kernel	Architectures/Arm

Complaints

Posted Nov 22, 2013 0:56 UTC (Fri) by ncm (guest, #165) [Link] (16 responses)

Without disagreeing with Jon's final point, I would like to point out that the objections at the time were largely correct, and the predicted consequences really did transpire. Linux adapted and survived at a cost that was felt by everybody. ACPI on ARM really will happen, most likely, but it will inevitably be an echo of that experience.

Complaints

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

The only *really* painful bit of ACPI was the move from firmware-mediated suspend/resume to OS-level management. Linux just didn't have a topological model for devices at the time, which made it pretty much impossible to implement suspend/resume until 2.6.

The problems facing ACPI on ARM are a pretty separate issue. ACPI assumes a well-defined underlying platform, and there simply isn't one for ARM. That's not a problem that's being imposed externally, it's a problem that the Linux community needs to figure out.

Complaints

Posted Nov 22, 2013 3:09 UTC (Fri) by iabervon (subscriber, #722) [Link] (4 responses)

It seems to me that "servers" (regardless of architecture) are a better-defined platform than ARM (regardless of purpose). Your ARM servers aren't likely to be dealing with a bunch of buttons attached to GPIOs that should be treated as keyboard keys, or direct connections between audio codecs and the cell baseband, or multiple seat-back displays, or memory the processor can't access, but only use for DMA with the flash or SATA target peripheral. There's no particular reason that the same ISA can't be available in both a "tell us what you soldered onto the board" form and a "general computing resource, with firmware-based discoverable peripherals" form, where the former is intentionally not a well-defined platform, and the latter looks like x86 except without the legacy junk.

Complaints

Posted Nov 25, 2013 0:25 UTC (Mon) by plugwash (subscriber, #29694) [Link] (3 responses)

It is certainly true that servers have less "weird stuff" than smartphones etc.

However even if storage and networking are on enumeratable busses (which they often isn't in the arm world) a platform still has to define stuff like where to find the enumeration registers to enumerate the enumeratable buses, where to find the timers needed to schedule non-hardware triggered events and so-on.

Complaints

Posted Dec 2, 2013 11:32 UTC (Mon) by cesarb (subscriber, #6266) [Link] (2 responses)

Won't storage and network on servers be behind a PCI bus? Then you only need to find the PCI registers and windows, and these could be described by simple tables. Timers should be similarly simple.

Complaints

Posted Dec 2, 2013 13:21 UTC (Mon) by broonie (subscriber, #7078) [Link]

There's no reason to assume that this would be the case - it's not how existing designs for these integrated SoCs are implemented and there's no pressing reason to do so from an electrical engineering point of view. PCI will be in use and probably will be used for the highest performance devices but for the bog standard integrated option it's less clear.

Complaints

Posted Dec 2, 2013 23:26 UTC (Mon) by plugwash (subscriber, #29694) [Link]

"Won't storage and network on servers be behind a PCI bus?"
The arm server stuff I have seen mostly seems to integrate storage and/or network into the SoC itself with no need for PCI. The arm server market is very much focussed on "lots of small servers" not "one big server".

PCs create "fake" PCI busses for storage and network controllers that are really integrated into the chipset. I guess in theory there is no reason an arm based platform couldn't do the same but i'm not aware of any that do.

Pain

Posted Nov 22, 2013 4:36 UTC (Fri) by ncm (guest, #165) [Link] (7 responses)

Without disagreeing with Matt, I would like to point out that what he finds painful would, for most of us, be progressively and ultimately fatally disfiguring, unto the seventh generation.

Pain

Posted Nov 22, 2013 4:42 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (6 responses)

And I find the entire area of memory management and process scheduling to be unbearably painful, but I don't complain about NUMA being awful. Nobody in Linux-land was really paying attention to ACPI until hardware started shipping with it, and even after that we spent several years deciding to obsess over implementing the spec rather than reality. The increased involvement of Linux vendors in working groups makes it unlikely that anything similar will happen again, though we do need to come up with a compelling story for supporting Connected Standby.

The ARM case is somewhat different. Some vendors apparently want to use ACPI, but they won't tell us why (I heard nothing even when I was maintaining most of the RHEL ACPI code at Red Hat). There's an apparent disconnect between what vendors expect Linux to offer and what people are actually working on implementing. You're right that the end result might well be painful, but it's going to be painful for entirely different reasons.

Pain

Posted Nov 22, 2013 9:13 UTC (Fri) by cesarb (subscriber, #6266) [Link]

I'd guess that what the vendors want is "PCs with their x86 CPU removed and an ARM chip put in there". That is, common code (and probably common hardware) for both their x86 and their arm64 servers.

I'd thus also guess that the vendors pushing ACPI would be the same ones which already have x86 servers. The vendors with only ARM products would instead prefer DT.

Pain

Posted Nov 22, 2013 14:04 UTC (Fri) by jdulaney (subscriber, #83672) [Link] (4 responses)

For Linux to wait on Microsoft to set the standards is so amazingly short sighted as to be table-flipping stupid. It is quite obvious that arm64 servers are going to be using ACPI whether we like it or not, and to not implement support for them is basically telling Microsoft that they can just have the market; we'll get out of your way and roll out the read carpet, on, and here is the Scotch you ordered.

Pain

Posted Nov 22, 2013 15:57 UTC (Fri) by olof (subscriber, #11729) [Link] (2 responses)

If you read the thread instead of what Jon chose to pick out of it, you'll see that nobody is actually proposing that. I'm pushing the subject to get discussion going, which seems to have been successful. Too many people have been grumbling about this for quite a while now but nobody actually put a foot down -- it was time to do so to at least shake out technical motivations for ACPI (so far there have been zero, even after bringing it up).

We can't drop everything and spend significant efforts trying to figure out ACPI instead of making the first rounds of systems work well with the means we have at hand -- that's not going to help anybody besides the people betting against Linux on ARM servers.

If some people want to keep ACPI a possible alternative while we continue working on the platforms, that's perfectly fine, but we shouldn't let it become a distraction for everybody.

Pain

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

(Clarification: s/proposing/serious about/)

Pain

Posted Nov 25, 2013 2:00 UTC (Mon) by marcH (subscriber, #57642) [Link]

> If you read the thread instead of what Jon chose to pick out of it,...

Unfortunately life is too short, which is why there is LWN.

Pain

Posted Nov 22, 2013 17:21 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

That's… not what I said? If we don't know what the vendors want from ACPI then adding random support is utterly meaningless. If what they want from ACPI turns out to be incompatible with reality then that's going to be painful for everybody. It's important to know what the problems we're supposed to be solving actually are.

Complaints

Posted Nov 29, 2013 9:44 UTC (Fri) by mirabilos (subscriber, #84359) [Link] (1 responses)

Have you *read* the ACPI spec for x86? Or even looked at its sheer size? Do you really believe everyone will implement it correctly?

I like the DT idea and preboot layer. This, if the Linaro guys could be convinced to agree (as opposed to hacking ACPI into their own trees locally), could be enough force to stop this nonsense before it starts. (Not to even start about EFI. It’s an Itanic thing best be kept dead. OpenBOOT (from sparc) is much nicer, anyway.)

Complaints

Posted Nov 29, 2013 16:21 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

"Have you *read* the ACPI spec for x86?"

Yes. Have you?

"Do you really believe everyone will implement it correctly?"

No, of course not. Nor do I believe everyone will implement DT correctly. The ARM world has hardly been a shining sea of well-implemented firmware in the past, and I don't think ACPI is going to miraculously fix that.

ACPI for ARM?

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

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.

ACPI for ARM?

Posted Nov 25, 2013 5:18 UTC (Mon) by jcm (subscriber, #18262) [Link] (5 responses)

I'd like to state for the record that my comment around "big boys" was meant to refer to the large server vendors in this space. It wasn't supposed to be deprecating to anyone else. It's possible that there may have been closed door discussions in this space, but I won't comment on that too much out of fairness to the kinds of agreements one undertakes in the ARM space. I did however, join that list thread because I wanted to make sure there was someone at least who stood up and said that "ACPI is coming" so that there is more attention paid to that fact. This isn't me making a fiat. This is simply me stating that certain things are coming and trying to deliver that message. I failed in my approach, but I wasn't trying to make demands myself. I do stand by my assertion that any general purpose Operating System in this space should absolutely confirm to any platform specifications.

I have been calling for platform standardization in this space (so that a general purpose OS can be made to run on whatever hardware platforms ship from multiple vendors), and for it to happen in as open a fashion as can possibly happen in the general sense. I would add, however, that no Operating System owns the base hardware platform. The hardware platform is owned by the vendors who ship those systems. They *absolutely* should consult with and involve the Linux community early and often, along with other OS communities as well. Nothing should happen in a vacuum, and if it does happen behind closed doors, there is a point (long since passed) at which there really needs to be more out in the open, at least as far as any specification documents that may or may not exist.

I think I'll leave it there. Please understand I don't actually want to do the smoke and daggers thing, but I will save any more comment for a happy day (soon) when there is more out in the open. Neither I, nor my employer, have any involvement over keeping anything behind closed doors - quite the opposite. But I won't followup on this thread and instead will let things happen how they need to.

ACPI for ARM?

Posted Nov 25, 2013 15:54 UTC (Mon) by mjg59 (subscriber, #23239) [Link] (4 responses)

Saying "ACPI is coming" without giving any indication as to what kind of support will be needed is not merely unhelpful, it's actively harmful. Should we assume that all ARM devices will implement the reduced hardware profile, or do we need to ensure that support for the entire spec is implemented on ARM? Are ARM servers going to need support for embedding DT properties? If I have a limited amount of time to spend on preparing the kernel for these machines, what should I be spending it on?

If I'm confused about what's going on I have no incentive to do anything to support it. There's a real risk that I'll end up working on something that provides no benefit to any platforms that people are actually working on, duplicating work that's being done elsewhere or making changes that make it harder to merge pending support code.

> Please understand I don't actually want to do the smoke and daggers thing

So don't. Spend your time working on something that allows you to engage with the community instead of treating them as a resource.

ACPI for ARM?

Posted Nov 26, 2013 9:22 UTC (Tue) by kleptog (subscriber, #1183) [Link] (3 responses)

Reading his post ISTM he's not saying that you must implement ACPI now. Instead I read his post as saying that we are currently in the design phase and that the decisions haven't all been made yet.

So I read it more like a call to people: if you care about how ACPI is going to be implemented, now is the time to get involved to steer the specification the way you want it.

If however, you don't care at all and are happy to implement whatever the ARM vendors come up with then the correct action is to do nothing.

ACPI for ARM?

Posted Nov 26, 2013 17:09 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (2 responses)

Up until last week there was no way to be involved in ACPI design discussions. It's still impossible for individual developers to be.

ACPI for ARM?

Posted Nov 29, 2013 23:16 UTC (Fri) by marcH (subscriber, #57642) [Link] (1 responses)

> It's still impossible for individual developers to be.

Use your company to join and try to change that from the inside? Even if that does not work you'll at least know what's wrong.

ACPI for ARM?

Posted Nov 29, 2013 23:32 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

There's some IP language in the agreements that might make some companies unhappy, and you'll need to figure out an argument to justify the $2000 annual membership fee. And that assumes that you don't work for a non-profit. Things get significantly more complicated then.

ACPI for ARM?

Posted Dec 5, 2013 5:08 UTC (Thu) by heijo (guest, #88363) [Link] (1 responses)

The kernel obviously needs to support ACPI on x86, so I fail to see why it should be hard or burdensome to support it on ARM too.

Assuming of course that ACPI for ARM is made as similar to the x86 version as possible.

ACPI for ARM?

Posted Dec 5, 2013 5:16 UTC (Thu) by mjg59 (subscriber, #23239) [Link]

That's the problem. ACPI on x86 is very much built on the model of having a fairly standard base platform and then abstracting away the differences in the ACPI methods. ARM, traditionally, isn't. It'd be possible to fit ACPI onto the traditional ARM model, but it'd involve a fair amount of modification to the ACPI spec. It'd be possible to fit ARM into the traditional ACPI model, but it'd involve a fair amount of kernel work that (so far) doesn't have any clear benefit. Figuring out what the best approach is is likely to take time and negotiation, and it's inevitably going to make some people upset.

ACPI for ARM?

Posted Dec 6, 2013 10:08 UTC (Fri) by glaesera (guest, #91429) [Link]

It seems there is not much success yet for ARM-based WindowsRT tablets.
So Microsoft will probably not invest large sums of money for bringing ACPI-support to the ARM-architecture.