On Mon, 16 Jul 2018 at 18:11, Daniel Thompson daniel.thompson@linaro.org wrote:
Hi Folks
Sorry if you have already seen this but for those that didn't, last Friday Grant pushed out version 0.6 of EBBR. Details below but the summary is that it is time for feedback.
This v0.6 release of EBBR is a pre-release document. The contents are not final. The purpose of this release is to raise awareness of the EBBR
project, and to solicit feedback on the current draft. Please do read and provide comments on the boot-architecture@lists.linaro.org mailing
list.
We had a training session at HKG18 looking at best practices for automating devices and there are aspects of any boot architecture which will make or break automation. Has any one considered adding to the EBBR based on the objectives of supporting automation of compliant devices?
http://connect.linaro.org/resource/hkg18/hkg18-tr10/ That session was based on this white paper: https://collaborate.linaro.org/display/CTT/Automation+and+hardware+design - but that URL is still restricted to people with a login on collaborate, so I blogged the content here: https://linux.codehelp.co.uk/automation-and-risk.html (It is a long read)
There is a lot of interest in automating testing of all parts of the boot process on a range of boards. Linaro has a lot of experience of automating a range of devices and ARM is building a similar data set using the same tools.
Principle elements would be:
* Reliability - * all identifiers are persistent across updates of the software, reboots etc. * Reliable reporting of errors. * Outputting sensible, unique, strings when performing a CPU reset * Uniqueness - all identifiers are unique and exposed to other parts of the boot architecture, e.g. NIC needs to be visible to bootloaders like Grub. * Scalability - avoid need for customised hardware to automate the device * Deployment - consider how to deploy new software to the device under automation.
EBBR talks about UEFI Reset but doesn't require that a reset is identifiable when it happens in automation - a simple string like the U-Boot support for "Resetting CPU ..." is enough for the automation to detect that the system we tried to deploy has not booted and what is about to happen is that something else may get booted in it's place.
Runtime variable access plays into the need to ensure that the network PHY is exposed to UEFI applications (like grubaarch64.efi)
Partitioning is a frequent problem when AOSP requires multiple partitions and OE testing requires fewer. Devices need to support switching partition tables without needing a full recovery deployment or the deployment of new bits of firmware.
Daniel.
---------- Forwarded message --------- From: Grant Likely grant.likely@arm.com Date: Fri, 13 Jul 2018 at 23:34 Subject: [Arm.ebbr-discuss] EBBR v0.6 Release Announcement To: arm.ebbr-discuss arm.ebbr-discuss@arm.com, boot-architecture@lists.linaro.org boot-architecture@lists.linaro.org, Linux ARM linux-arm-kernel@lists.infradead.org, uboot < u-boot@lists.denx.de>, devicetree-spec@vger.kernel.org
I'm pleased to announce the release of version 0.6 of the Embedded Base Boot Requirements (EBBR) specification.
https://github.com/ARM-software/ebbr/releases/tag/v0.6EBBR is a new specification defining a standard boot environment suitable for full feature operating systems running on embedded platforms...
Well, it will when it's finished.
It is well know that firmware for embedded systems is a fragmented area with each platform behaving in subtly incompatible ways. It is also completely different from the firmware interface used on general purpose desktops and servers. For OSes, this makes supporting more than a handful of platforms a nearly impossible affair. EBBR aims to solve this problem by defining a standard boot interface that can easily be implemented using either U-Boot or Tianocore, and is based on the same UEFI specification used on general purpose computers.
By adopting EBBR, platform vendors can reduce the amount of engineering effort required to support their products and make them easier to use. As EBBR is being developed in conjunction with the U-Boot, Tianocore, and Trusted Firmware projects, most of the functionality required is already implemented and ready to be used if one uses an up to date release of U-Boot or Tianocore.
For OS vendors, this makes far easier to support embedded platforms because they don't need to tailor the boot process for each platform. The same boot infrastructure works on both desktop/servers and on EBBR compliant embedded platforms.
And finally, for end users, working with an EBBR compliant platform means they can boot the OS of their choice without needing to learn low level details of the platform firmware.
This v0.6 release of EBBR is a pre-release document. The contents are not final. The purpose of this release is to raise awareness of the EBBR project, and to solicit feedback on the current draft. Please do read and provide comments on the boot-architecture@lists.linaro.org mailing list.
The plan is to release v1.0 before the end of the 2018.
Thanks to the EBBR committee members who contributed to this release:
Andreas Färber (SUSE) Alex Graf (SUSE) Ryan Harkin (Linaro) Rob Herring (Linaro) Udit Kumar (NXP) Leif Lindholm (Linaro) Bill Mills (TI) Peter Robinson (Red Hat) Tom Rini (Konsulko) Daniel Thompson (Linaro) Dong Wei (Arm)
Sincerely, Grant Likely, EBBR committee co-chair
Note on U-Boot implementations
It is expected that EBBR compliant can be achieved by using a recent version of U-Boot with the appropriate configuration options. An implementers guide for U-Boot will be written before EBBR v1.0 is released.
There is also work ongoing to get the UEFI Self Certification Test running on U-Boot. Once working, this will be a tool for vendors to test their platforms for EBBR compliance.
FAQ
Does EBBR define a new interface?
No. EBBR builds on the existing UEFI spec by requiring a specific
subset that can be implemented today using U-Boot, and either Devicetree or ACPI.
Does EBBR require Devicetree? ACPI?
EBBR allows platforms to provide either ACPI or Devicetree. Linux
supports both system description languages equally well, and Devicetree is in common use on embedded platforms. As long as the platform supplies a system description that can boot a mainline operating system.
EBBR does not attempt to define a common base standard forDevicetree platforms because of the wide variety of platforms needed to be supported. The one assumption EBBR does make is that the target operating system already has support for the SoC on the platform.
Is EBBR only for U-Boot and Linux embedded systems?
No. While U-Boot+Linux platforms were certainly the primary audience
when EBBR was first conceived, the spec is very purposefully written to be OS-independent. EBBR requires specific interfaces, but those interface can be implemented by any firmware project.
We would absolutely like to have review, feedback and contributionsfrom non-Linux, non-U-Boot users.
Can I contribute to the EBBR specification?
Yes. The EBBR source document is on GitHub, and we use the
boot-architecture@lists.linaro.org mailing list.
https://github.com/ARM-Software/ebbr
On 16/07/2018 12:35, Neil Williams wrote:
On Mon, 16 Jul 2018 at 18:11, Daniel Thompson daniel.thompson@linaro.org wrote:
Hi Folks
Sorry if you have already seen this but for those that didn't, last Friday Grant pushed out version 0.6 of EBBR. Details below but the summary is that it is time for feedback.
This v0.6 release of EBBR is a pre-release document. The contents are not final. The purpose of this release is to raise awareness of the EBBR
project, and to solicit feedback on the current draft. Please do read and provide comments on the boot-architecture@lists.linaro.org mailing
list.
We had a training session at HKG18 looking at best practices for automating devices and there are aspects of any boot architecture which will make or break automation. Has any one considered adding to the EBBR based on the objectives of supporting automation of compliant devices?
http://connect.linaro.org/resource/hkg18/hkg18-tr10/ That session was based on this white paper: https://collaborate.linaro.org/display/CTT/Automation+and+hardware+design - but that URL is still restricted to people with a login on collaborate, so I blogged the content here: https://linux.codehelp.co.uk/automation-and-risk.html (It is a long read)
There is a lot of interest in automating testing of all parts of the boot process on a range of boards. Linaro has a lot of experience of automating a range of devices and ARM is building a similar data set using the same tools.
Useful. I'll read the blog post. Thanks.
Principle elements would be:
- Reliability -
- all identifiers are persistent across updates of the software, reboots
etc.
- Reliable reporting of errors.
- Outputting sensible, unique, strings when performing a CPU reset
- Uniqueness - all identifiers are unique and exposed to other parts of
the boot architecture, e.g. NIC needs to be visible to bootloaders like Grub.
- Scalability - avoid need for customised hardware to automate the device
- Deployment - consider how to deploy new software to the device under
automation.
EBBR talks about UEFI Reset but doesn't require that a reset is identifiable when it happens in automation - a simple string like the U-Boot support for "Resetting CPU ..." is enough for the automation to detect that the system we tried to deploy has not booted and what is about to happen is that something else may get booted in it's place.
It isn't something that has come up yet, but not I think for lack of interest. Much of the focus so far has been getting a baseline of functionality defined.
It would be easy to add requirements on boot messages. The process is completely open, so you can propose some language that you think would be suitable. When you do, keep in mind that there are implementation choices in terms of console output. Mostly likely the vast majority of EBBR platforms will use some form of serial port as the primary console, but that won't alwasy be the case. The proposed text should take into account platforms that use a graphical console instead of serial port, even it that just means you use language something like "if the primary console is a serial port, then the firmware shall..."
I would also take a look at the UEFI spec first to see if anything is prescribed there. EBBR is intended to inform reading of the UEFI spec. I don't want to take on content that should be in UEFI.
Runtime variable access plays into the need to ensure that the network PHY is exposed to UEFI applications (like grubaarch64.efi)
How EBBR talks about runtime variables still needs some work. There are three scenarios that need to be considered:
1) SetVariable() doesn't work at all -- rare 2) SetVariable() works at boot time, but not runtime -- many platforms 3) SetVariable() works as defined in UEFI.
UEFI doesn't say anything about #1 or #2. I think GetVariable() should work in all three cases, but SUSE currently assumes #2 if GetVariable() returns nothing at runtime. Text dealing with these scenarios needs to be written before v0.7 can be released.
Partitioning is a frequent problem when AOSP requires multiple partitions and OE testing requires fewer. Devices need to support switching partition tables without needing a full recovery deployment or the deployment of new bits of firmware.
Part of the goal of EBBR is to separate the firmware bits (partitions) from the OS bits. The intent is to be able to deploy firmware to a board regardless of the OS, and then be able to (re)install any OS without it disturbing the firmware partitions.
Thanks for the comments.
Cheers, g.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
On Mon, 16 Jul 2018 at 18:57, Grant Likely grant.likely@arm.com wrote:
On 16/07/2018 12:35, Neil Williams wrote:
On Mon, 16 Jul 2018 at 18:11, Daniel Thompson <
daniel.thompson@linaro.org>
wrote:
Hi Folks
Sorry if you have already seen this but for those that didn't, last
Friday
Grant pushed out version 0.6 of EBBR. Details below but the summary is that it is time for feedback.
This v0.6 release of EBBR is a pre-release document. The contents are not final. The purpose of this release is to raise awareness of the
EBBR
project, and to solicit feedback on the current draft. Please do read and provide comments on the boot-architecture@lists.linaro.org mailing
list.
We had a training session at HKG18 looking at best practices for automating devices and there are aspects of any boot architecture which will make or break automation. Has any one considered adding to the EBBR based on the objectives of supporting automation of compliant devices?
http://connect.linaro.org/resource/hkg18/hkg18-tr10/ That session was based on this white paper:
https://collaborate.linaro.org/display/CTT/Automation+and+hardware+design
but that URL is still restricted to people with a login on collaborate,
so
I blogged the content here: https://linux.codehelp.co.uk/automation-and-risk.html (It is a long
read)
There is a lot of interest in automating testing of all parts of the
boot
process on a range of boards. Linaro has a lot of experience of
automating
a range of devices and ARM is building a similar data set using the same tools.
Useful. I'll read the blog post. Thanks.
Principle elements would be:
- Reliability -
- all identifiers are persistent across updates of the software,
reboots
etc.
- Reliable reporting of errors.
- Outputting sensible, unique, strings when performing a CPU reset
- Uniqueness - all identifiers are unique and exposed to other parts of
the boot architecture, e.g. NIC needs to be visible to bootloaders like Grub.
- Scalability - avoid need for customised hardware to automate the device
- Deployment - consider how to deploy new software to the device under
automation.
EBBR talks about UEFI Reset but doesn't require that a reset is identifiable when it happens in automation - a simple string like the U-Boot support for "Resetting CPU ..." is enough for the automation to detect that the system we tried to deploy has not booted and what is
about
to happen is that something else may get booted in it's place.
It isn't something that has come up yet, but not I think for lack of interest. Much of the focus so far has been getting a baseline of functionality defined.
It would be easy to add requirements on boot messages. The process is completely open, so you can propose some language that you think would be suitable. When you do, keep in mind that there are implementation choices in terms of console output. Mostly likely the vast majority of EBBR platforms will use some form of serial port as the primary console, but that won't alwasy be the case. The proposed text should take into account platforms that use a graphical console instead of serial port, even it that just means you use language something like "if the primary console is a serial port, then the firmware shall..."
* output stable, reliable and unique messages for all supportable error conditions and failures, including resets * any changes to messages are to be highlighted in published changelogs * full changelogs must be available with every revision of firmware * firmware shall provide a means to write out the version string for the current build, alongside the files to be deployed to the device - (this allows testing to reliably identify each build)
... any firmware which does not provide a serial console will not be able to support automation.
GUI consoles are impossible to automate reliably. All sorts of complex ideas can be proposed but the evidence is that none of those are reilable or scalable. As covered in the training session and the post, Keep It Simple - complexity undermines automation because reliability decreases out of proportion to any increase in complexity.
If automation is to be an objective, then there needs to be some level of serial support. It doesn't have to be primary but it will need to be available, functional and reliable.
What kind of testing needs to be considered too - if all that's required is to watch UEFI go passed and then interact with something pre-configured and persistent within the firmware, like Grub, then everything is easy. If there is any requirement to interact with UEFI under automation (adding boot options, setting variables etc.), then a graphical console will completely block automation. I don't think that this is a useful sacrifice. I would push for graphical consoles to be ruled out of the specification as actively harmful to any kind of automation and only to be made available IF there is a serial alternative properly supported. (That serial alternative could, of course, be a BMC - anything so long as there is no need to interact with the graphical console under automation.)
I would also take a look at the UEFI spec first to see if anything is prescribed there. EBBR is intended to inform reading of the UEFI spec. I don't want to take on content that should be in UEFI.
Someone needs to act as an intermediary for that - I am not going to be putting changes into the UEFI spec. (One reason I CC'd Steve.)
This highlights a problem for this kind of effort - the people with the automation experience do not generally have low level knowledge of things like UEFI. We need those with that knowledge to engage with automation and work out what changes are actually feasible.
Runtime variable access plays into the need to ensure that the network
PHY
is exposed to UEFI applications (like grubaarch64.efi)
How EBBR talks about runtime variables still needs some work. There are three scenarios that need to be considered:
- SetVariable() doesn't work at all -- rare
- SetVariable() works at boot time, but not runtime -- many platforms
- SetVariable() works as defined in UEFI.
UEFI doesn't say anything about #1 or #2. I think GetVariable() should work in all three cases, but SUSE currently assumes #2 if GetVariable() returns nothing at runtime. Text dealing with these scenarios needs to be written before v0.7 can be released.
Partitioning is a frequent problem when AOSP requires multiple partitions and OE testing requires fewer. Devices need to support switching
partition
tables without needing a full recovery deployment or the deployment of
new
bits of firmware.
Part of the goal of EBBR is to separate the firmware bits (partitions) from the OS bits. The intent is to be able to deploy firmware to a board regardless of the OS, and then be able to (re)install any OS without it disturbing the firmware partitions.
Thanks for the comments.
Cheers, g.
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
boot-architecture@lists.linaro.org
-
Grant Likely -
Neil Williams