As part of the work to prepare for ARM servers, the Linaro Enterprise Group has spent the last year getting ACPI and UEFI working on ARM. We’ve been working closely with ARM and ARM’s partners on this to make sure the firmware architecture meets the needs of the server market.
Yet this work has raised questions about what it means for the rest of the ARM Linux world. Why are we doing UEFI & ACPI? Who should be using UEFI/ACPI? Will U-Boot and FDT continue to be supported? Can hardware provide both ACPI & FDT? Can ACPI and FDT coexist? And so on. I want to quickly address those questions in this blog post, and then I want to discuss a development plan to get UEFI and ACPI onto shipping servers.
This is an important week for ARM’s push into server platforms. On Tuesday AMD announced their Opteron A1100 “Seattle” ARM processor will begin sampling in March, and yesterday ARM announced availability of Server Base System Architecture (SBSA) document for ARM servers. Of the two, the SBSA announcement is the most significant because begins laying out the platform for ARM server machines that both hardware and software vendors can built to and ensure compatibility.
The SBSA document is specifically about hardware design and includes requirements on CPU features, cache architecture, MMU organization and standard peripheral interfaces like SATA and USB. Despite media reports, the SBSA does not cover firmware architecture. You can expect ARM to release a separate document specifying firmware requirements (spoiler: UEFI and ACPI will be required).
Full disclosure: I was part of the group consulted by ARM for the drafting of the SBSA
There is a big a difference between knowing something, and really understanding it. That thought occurred to me a few days ago when I made a bad decision on a project I’ve been tinkering with. To explain what I mean, let me describe a bit about my experience as an engineer.
Follow