Hi everyone,
We Linux developers seem to have a bit of a love-hate relationship with ACPI. On the plus side it provides the "standard platform" that we rely on to support the huge amount of hardware in the x86 ecosystem It is also the source of much pain due to firmware and DSDT tables that are either buggy or perform poorly. In the embedded space we've avoided ACPI entirely by standardizing on the Flattened Device Tree for hardware discovery. However there are some market segments and use cases where FDT doesn't solve the problems faced by OEMs, particularly when the hardware needs to support existing, unmodified OS images. Some OEMs are looking to implement ACPI on ARM since it is a solution they are already familiar with. It's becoming clear to me that in the near future, independent of whether or not we as the Linux community like it, we are going to start seeing ARM systems that are based on UEFI and ACPI.
But, to quote h2g2, "Don't Panic." While there are many reasons as to why ACPI has been the source of pain, at least one of those factors is under our control. Historically, we as the Linux community have not been very good at participating or providing leadership as to what the future of the commodity hardware industry should look like, and the result is decisions that don't reflect our best interest, sheerly by omission. (There is an argument that standards setting hasn't been inclusive either, but I have reason to hope that is neither permanent nor insurmountable).
So, given that we know that ARM ACPI machines will exist, and given that we still want to support Linux on these machines, I think it is absolutely appropriate to start getting involved with both the ACPI and UEFI standardization processes. I (on behalf of Linaro) will soon be joining the UEFI ARM Binding Sub Team (ABST), and we already have representatives from Canonical and Red Hat involved there. I'm also investigating the possibility of getting involved when the post-ACPI 5 process begins, probably sometime early next year.
In the mean time, I want to start getting prepared by collecting feedback about the state of ACPI and UEFI now, and what changes we need to have for ACPI and UEFI to meet our needs in the Linux ecosystem. Reply to this email with your comments, and I'll start collating a list that I can discuss with the ACPI and UEFI folks.
For your reference, the current versions of the ACPI and UEFI specs can be found here[1][2]. The ACPI spec is freely downloadable, but the UEFI spec requires a click-through license to read.
[1] http://www.acpi.info/DOWNLOADS/ACPIspec40a.pdf [2] http://www.uefi.org/specs/
I'll kick things off with a few items from my personal list. This list will grow as I collect feedback and input from all of you.
1) Open Process - Currently the ACPI definition process is entirely confidential between the 5 APCI member companies (Microsoft, Intel, Toshiba, HP and Phoenix Technologies), and it remains so until the Final Draft is proposed to "Contributing Adopters" which is very late in the process. The current version of the spec is v4.0a[1]. ACPI 5 is currently under final review and will be released sometime late 2011, early 2012.
For us to participate in the ACPI definition, we need to have an open processes so that open source Linux engineers can participate.
2) Improvements to compliance testing - Several Linux developers have been doing good work on BIOS/UEFI/ACPI testing and are able to identify many common bugs in firmware. This is of course valueable to the Linux ecosystem, but since it is discovering firmware bugs, it is most likely of high value to all HW and OS vendors. I would like to see much of the test work that we're currently doing to start filtering back into the tools that are routinely used by HW vendors as part of QA testing. Maybe even pushing for an industry wide suite of compliance tests.
3) Better rules (and testing) on SMM interrupts (or the ARM equivalent). HW vendors are using SMM to work around hardware bugs or perform system management tasks independently and transparently from the operating system. However, poorly implemented firmware will take the processor away from the OS for unbounded periods of time which is a deal breaker for any kind of real-time response in the OS. For ARM systems I would like to see an alternative to compete interruption of the OS when firmware needs to perform system management tasks.
Cheers, g.
Hi Grant,
Thank you very much for starting this conversation on LKML.
On Sat, 2011-10-15 at 22:57 -0600, Grant Likely wrote:
<snip>
there are some market segments and use cases where FDT doesn't solve the problems faced by OEMs, particularly when the hardware needs to support existing, unmodified OS images. Some OEMs are looking to implement ACPI on ARM since it is a solution they are already familiar with. It's becoming clear to me that in the near future, independent of whether or not we as the Linux community like it, we are going to start seeing ARM systems that are based on UEFI and ACPI.
Right. To add to this, I don't think anyone is suggesting by UEFI that we'll see lots of runtime services implemented in UEFI on ARM, but we will be seeing systems that boot with UEFI. Personally, I like this for general purpose OS environments as opposed to using one of the many different U-Boots out there, none of which handle generically installing an OS and having a standard discoverable location for kernel and initramfs images, and upgrading all of these bits automatically. That's not to disparage U-Boot, just to say it targets a different use case.
<snip>
Historically, we as the Linux community have not been very good at participating or providing leadership as to what the future of the commodity hardware industry should look like, and the result is decisions that don't reflect our best interest, sheerly by omission.
Right. I think this is key. ACPI isn't "evil". It's an evolved standard that we've not been really engaged in steering or developing, and that is beginning to change. I am encouraged to believe that the future is bright as far as having more constructive input, especially post 5.
I (on behalf of Linaro) will soon be joining the UEFI ARM Binding Sub Team (ABST), and we already have representatives from Canonical and Red Hat involved there.
On our side, I am already a member of the UEFI ARM Binding Sub Team and have at least reviewed all of the existing standards documentation.
I'm also investigating the possibility of getting involved when the post-ACPI 5 process begins, probably sometime early next year.
Indeed. I have been able to review existing ACPI drafts but the current structure can certainly be improved in the future to be more inclusive during the actual definition of these standards if we are to use them. We have a unique opportunity to help steer here by acknowledging the interest in ACPI and responding by asking for things in return.
<snip>
I'll kick things off with a few items from my personal list.
I'll followup with a few of the things I've been thinking about.
<snip>
- Better rules (and testing) on SMM interrupts (or the ARM
equivalent). HW vendors are using SMM to work around hardware bugs or perform system management tasks independently and transparently from the operating system. However, poorly implemented firmware will take the processor away from the OS for unbounded periods of time which is a deal breaker for any kind of real-time response in the OS. For ARM systems I would like to see an alternative to compete interruption of the OS when firmware needs to perform system management tasks.
Right. At the moment, it's looking like TrustZone will be one way in which SMM-like things are done. It's more of a general platform issue than specific to ACPI or UEFI but it is one of the areas to look at.
Jon.
boot-architecture@lists.linaro.org
-
Grant Likely -
Jon Masters