What should Linaro do with UEFI
- First and foremost I'm a Linux engineer. Walking the line between representing the requirements of Linaro members and representing the needs of the Linux community.
Feedback from vendors
After one on one conversations with vendors, the following issues and concerns were raised:
- Vendors would like to line up with the rest of the industry
- 'advanced' boot features are important; particularly to vendors looking at 'general purpose' arm platforms
- PXE, SATA, USB methods
- Particularly important for machines in a datacenter (server)
- Secure boot
- PXE, SATA, USB methods
- Having a test suite is also important.
- Excited about the possibility of debugging the OS with UEFI
- Seems like few vendors are actually working on UEFI; while they see it as something they want to support and provide to their customers, there isn't a lot of engineering effort behind it at the moment.
- Licensing seems to be a hot topic; vendor's customers are asking for non-GPLed (ie. BSD) firmware so they don't need to
- Boot time is important
Concerns about UEFI
Size and Complexity
From what I've been able to tell, UEFI is big, in the order of 1-2 MB for a UEFI firmware image. Cannot tell how easy it is to tailor and how small the image can be.
A major reason not to use UEFI, particularly in embedded systems, is the size and complexity. UEFI is an operating system in its own right which requires additional device drivers and has a greater surface area where things can go wrong resulting in a bricked system. For embedded or CE systems, it can be argued that stripped down simple firmware is more appropriate. ie. CoreBoot or LittleKernel. Note: U-Boot also fails the test for being too big and complex in a lot of situations.
In other words; it's just firmware. The goal is to get out of firmware as soon as possible and into the real environment.
Size and complexity have already been mentioned, so that won't be repeated, but there are some other concerns from a Linux engineering perspective
- OS entry point. The last thing we want is a different entry mode for each firmware interface. We're standardizing on device tree, and want to ensure that all implementations use the same thing.
I'm very surprised to hear that there isn't any Linux representation on the ARM bindings sub team. What level of Linux representation is there in the rest of UEFI?
Open Source Community
Is UEFI good for Open Source and Linux? So far, all indications are that UEFI is more work to support without any significant benefit. There is also significant distaste for any firmware that expects to remain resident after the kernel. Some other concerns:
- An open source implementation is critical
- Is it going to be possible to work around situations when firmware is imperfect (firmware is always imperfect)
Linaro needs to take some sort of position about UEFI on ARM. The possible options are:
- UEFI is our saviour; everyone should migrate to it
- UEFI is the devil; it should never be used for Linux systems
- UEFI is an option, but vendors must decide if it makes sense for their systems.
While I'm sure there are some people who argue for option 1 or 2, the third option is by far the most likely and the most reasonable, but within that option there is still a couple of questions which need to be answered.
- Should Linaro expend any engineering effort on UEFI images for target platforms?
- What recommendations should Linaro be providing to their members on how to design their firmware?
Vendor conversation notes
Some notes from conference call about Calxeda's thoughts on UEFI
- Version 2.3 of the UEFI Specification has been released which includes the ARM Bindings, specifies the state of the processor, system posted UEFI initialization and defines the Runtime and Pre-Boot Services (ABI). Reference code is publicly available but the Compliance Test Suites are not yet available for ARM. It is extremely important that these suites are provided for ARM based systems in order to test and validate UEFI compliance.
- What does Calxeda need out of UEFI? Requirements
- Server market focus
- Server OEMs and end customers will require UEFI for ARM based products in order to remain consistent with x86 based products
- Although Uboot likely acceptable for initial product releases the expectation is that UEFI will be a core requirement over time.
- PXE boot is really important, especially in datacenters
- Secure boot somewhat important too
- Significant value in having industry reference release supported with Linaro environment and kernel
- Consistent model with existing Uboot implementation - interfaces, Device Tree support, etc. This will ease likely requirement of having to support both Uboot and UEFI over time.
- Initial target support should be for 11.11 release cycle in order to hit key industry milestones
- Specific benefits related to UEFI:
- Expects BSD rather than GPL licensed
- There are things that BSD license allows them to add to firmware.
- Consistency for customers/partners across broad array of architectures
Random notes on how UEFI fits into the ARM boot architecture...
Use Cases (who needs UEFI?)
- Need details about the features needed
- Windows 8
Possible technical requirements
- Secure boot
- Pass device tree to client OS
- don't want to be forced to define multiple Linux boot interfaces.
- Does UEFI require being runtime resident?
- Is UEFI too big/complex
- Will it be too much effort for vendors to "get it right"? In other words, will adopting UEFI result in a large number of broken UEFI shipments which will never get be fixed?
- UEFI has been problematic for Linux on x86 (hearsay, don't have cross references)
- "It's just firmware"
- A lot of effort for no benefit?
"Tianocore" BSD licensed UEFI implementation:
Is this driven by Intel engineering effort?
Cycles/1105/TechnicalTopicsAD-UEFI (last modified 2011-03-25 18:15:37)