- boot-architecture - lists.linaro.org

EBBR Weekly - Agenda 12 July 2018

by Grant Likely

Next EBBR meeting is in a few minutes. Here are the agenda items I've got for today: - Issue review - Set/GetVariable() behaviour when non-volatile doesn't work at runtime - v0.6 release - Review distribution list - Any other business As always, this Google doc will be used to capture notes. Please help filling it in. You may need to request edit access if I haven't already added you. https://docs.google.com/document/d/1RdlFp5SIrvjcVOGoGEFVYDsqTqFBJHugbBMV5Mu… --- Every Thursday at 16:30 UTC/BST, 8:30 PST/PDT, 00:30 CST (following UTC/BST daylight savings time shifts) Online meeting: https://meet.lync.com/armh/grant.likely/YBY93TIK Skype Web App: https://meet.lync.com/armh/grant.likely/YBY93TIK?sl=1 Phone +44 2033215213,, 4664465# Find a local number: https://dialin.lync.com/7bdb65cd-97d0-44fe-bc03-bf8072eadc33 Conference ID: 4664465 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.

8 years, 2 months

2
2
0 0

ARM V8 Boot

by Mohamed ABDELRASOUL

Hello all, i wanna know how much time will ATF take to initialize board and jump to U-Boot or Bootloader ? and is there any document to help me customize and optimize ATF stages to boot in less time ? Thanks, -- *This e-mail message is intended for the internal use of the intended recipient(s) only. The information contained herein is confidential/privileged. Its disclosure or reproduction is strictly prohibited. If you are not the intended recipient, please inform the sender immediately, do not disclose it internally or to third parties and destroy it.*

8 years, 2 months

1
0
0 0

Re: [Arm.ebbr-discuss] EBBR v0.6 Release Announcement

by Neil Williams

On Mon, 16 Jul 2018 at 18:11, Daniel Thompson <daniel.thompson(a)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(a)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(a)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(a)arm.com>, > boot-architecture(a)lists.linaro.org <boot-architecture(a)lists.linaro.org>, > Linux ARM <linux-arm-kernel(a)lists.infradead.org>, uboot < > u-boot(a)lists.denx.de>, <devicetree-spec(a)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.6 > > EBBR 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(a)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 > --- > 1. 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. > > 2. 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 for > Devicetree 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. > > 3. 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 contributions > from non-Linux, non-U-Boot users. > > 4. Can I contribute to the EBBR specification? > > Yes. The EBBR source document is on GitHub, and we use the > boot-architecture(a)lists.linaro.org mailing list. > > https://github.com/ARM-Software/ebbr > > -- Neil Williams ============= neil.williams(a)linaro.org http://www.linux.codehelp.co.uk/

8 years, 2 months

2
2
0 0

EBBR v0.6 Release Announcement

by Grant Likely

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.6 EBBR 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(a)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 --- 1. 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. 2. 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 for Devicetree 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. 3. 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 contributions from non-Linux, non-U-Boot users. 4. Can I contribute to the EBBR specification? Yes. The EBBR source document is on GitHub, and we use the boot-architecture(a)lists.linaro.org mailing list. https://github.com/ARM-Software/ebbr 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.

8 years, 2 months

2
2
0 0

[PATCH 0/5] Editorial and trivial changes for v0.6

by Grant Likely

I've already pushed these out to GitHub, but posting to the mailing list for completeness. Grant Likely (5): trivial: fix broken internal reference trivial: Put SPDX tag into all source files trivial: Fix reference to required runtime services section editorial: tighten up uefi runtime services language editorial: Drop value statement between ACPI & DT source/appendix-a-uefi-features.rst | 3 +++ source/chapter1-about.rst | 4 ++-- source/chapter2-uefi.rst | 12 ++++++++---- source/chapter3-secureworld.rst | 2 ++ source/chapter4-firmware-media.rst | 2 ++ source/references.rst | 2 ++ 6 files changed, 19 insertions(+), 6 deletions(-) -- 2.13.0

8 years, 2 months

1
5
0 0

[PATCH] uefi: Add todo item on how to handle SetVariable()

by Grant Likely

We don't have agreement yet on what the behaviour should be if non-volatile variables cannot be updated or created at runtime. Add a paragraph discussing the factors involved and asking for feedback. Cc: Dong Wei <dong.wei(a)arm.com> Cc: Alexander Graf <agraf(a)suse.de> Cc: Peter Robinson <pbrobinson(a)redhat.com> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter2-uefi.rst | 72 ++++++++++++++++++++++++++++++++++++++++++------ 1 file changed, 64 insertions(+), 8 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7b6843e..10448fd 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -197,13 +197,69 @@ command: Operating Systems calls to reset the system will go via Runtime Services and not directly to PSCI. -Set Variable ------------- +Runtime Variable Access +----------------------- + +.. todo: + + There are many platforms where it is difficult to support SetVariable() for + non-volatile variables because the firmware cannot access storage after + ExitBootServices() is called. + e.g., If firmware accesses an eMMC device directly at runtime, it will + collide with transactions initiated by the OS. + Neither U-Boot nor Tianocore have a solution for accessing shared media for + variable updates. [#OPTEESupplicant]_ + + In these platforms SetVariable() calls with the EFI_VARIABLE_NON_VOLATILE + attribute set will work in boot services, but will fail in runtime services. + The [UEFI]_ specification doesn't address what to do in this situation. + We need feedback on options before writing this section of EBBR, or making a + proposal to modify UEFI. + + We need a solution that communicates to the OS that non-volatile variable + updates are not supported at runtime, and that defines the behaviour when + SetVariable() is called with the EFI_VARIABLE_NON_VOLATILE attribute. + + Presumably, the solution will require SetVariable() to return + EFI_INVALID_PARAMETER if called with the EFI_VARIABLE_NON_VOLATILE + attribute, but beyond that there are a number of options: + + #. Clear EFI_VARIABLE_NON_VOLATILE from all variables at ExitBootServices() + + If the platform is incapable of updating non-volatile variables from Runtime + Services then it must clear the EFI_VARIABLE_NON_VOLATILE attribute from all + non-volatile variables when ExitBootServices() is called. + + An OS can discover that non-volatile variables cannot be updated at + runtime by noticing that the NON_VOLATILE attribute is not set. + + #. Clear all variables at ExitBootServices() + + If the platform is incapable of updating non-volatile variables from Runtime + Services then it will clear all variables and return EFI_INVALID_PARAMETER + on all calls to SetVariable(). + + SUSE in particular currently uses this behaviour to decide whether or not + to treat the ESP as removable media. + + #. Advertise that SetVariable() doesn't work at runtime with another variable + + Platforms can check another variable to determine if they have this quirk, + perhaps by adding a new BootOptionSupport flag. + + This is not a complete list, and other options can still be proposed. We're + looking for feedback on what would be most faithful to the UEFI spec, and + would work for the OS distributions before filling out this section of the + specification. + + Comments can be sent to the boot-architecture(a)lists.linaro.org mailing list. -Non-volatile UEFI variables must persist across reset, and emulated variables -in RAM are not permitted. -The UEFI Runtime Services must be able to update the variables directly without -the aid of the Operating System. +.. [#OPTEESupplicant] It is worth noting that OP-TEE has a similar problem + regarding secure storage. + OP-TEE's chosen solution is to rely on an OS supplicant agent to perform + storage operations on behalf of OP-TEE. + The same solution may be applicable to solving the UEFI non-volatile + variable problem, but that approach is also not entirely UEFI compliant + because it requires additional OS support to work. -.. note:: This normally requires dedicated storage for UEFI variables that is - not directly accessible from the Operating System. + https://github.com/OP-TEE/optee_os/blob/master/documentation/secure_storage… -- 2.13.0

8 years, 2 months

1
0
0 0

RE: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

by Udit Kumar

Hi Mark > -----Original Message----- > From: Mark Brown [mailto:broonie@kernel.org] > Sent: Thursday, July 12, 2018 8:20 PM > To: Udit Kumar <udit.kumar(a)nxp.com> > Cc: Ard Biesheuvel <ard.biesheuvel(a)linaro.org>; Architecture Mailman List > <boot-architecture(a)lists.linaro.org>; nd <nd(a)arm.com>; arm.ebbr-discuss > <arm.ebbr-discuss(a)arm.com> > Subject: Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working > at runtime > > On Thu, Jul 12, 2018 at 02:19:49PM +0000, Udit Kumar wrote: > > > > > Do any existing implementations change variables from non-volatile > > > > to volatile? > > > > The UEFI spec is explicit about which variables are volatile and which are not. > > > Simply relaxing non-volatile to volatile in the general case doesn't > > > seem like a useful approach to me. > > > I believe at boot-time, UEFI specs will be followed for volatile and non-volatile > variables. > > Having this in statement EBBR, will help those platform, which cannot expose > non-volatile variables at runtime. > > If nothing currently does it the chances that anything will actually cope well > seem minimal. Like Daniel said it seems more likely to break things - if the > variables are defined as being non-volatile then the OS is unlikely to be checking > at runtime if that's the case or not unless it's explicitly written to work with > EBBR. If an error is generated because a non-volatile variable can't be set then > that should at least fall into whatever error handling code is there to cover > normal rutime failures which has some chance of doing something sensible. Right, There will be some breaks or say diversion from UEFI specs. If we need to follow UEFI specs 'Table 10. Global Variables' on such platform where we cannot write to NV storage at runtime, then in either case 1/ passing OS as no-efi-runtime or 2/ Returning errors/not saving to NV storage is violation of UEFI spec. Which divergence is acceptable ? Regards Udit

8 years, 2 months

5
5
0 0

Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

by Grant Likely

On 12/07/2018 15:50, Mark Brown wrote: > On Thu, Jul 12, 2018 at 02:19:49PM +0000, Udit Kumar wrote: > >>>> Do any existing implementations change variables from non-volatile to >>>> volatile? > >>> The UEFI spec is explicit about which variables are volatile and which are not. >>> Simply relaxing non-volatile to volatile in the general case doesn't seem like a >>> useful approach to me. > >> I believe at boot-time, UEFI specs will be followed for volatile and non-volatile variables. >> Having this in statement EBBR, will help those platform, which cannot expose non-volatile variables at runtime. > > If nothing currently does it the chances that anything will actually > cope well seem minimal. Like Daniel said it seems more likely to break > things - if the variables are defined as being non-volatile then the OS > is unlikely to be checking at runtime if that's the case or not unless > it's explicitly written to work with EBBR. If an error is generated > because a non-volatile variable can't be set then that should at least > fall into whatever error handling code is there to cover normal rutime > failures which has some chance of doing something sensible. There is a hard break at least between when variables are used in boot services, and when they are used at runtime. For Linux, only the UEFI stub will read the variables at boot time (if at all) before calling exitBootServices(). By the time the kernel starts, runtime services are the only way to access variables. There is no caching of variables from the stub to the kernel as far as I can tell. As far as the kernel and userspace are concerned, all the variables will have only ever been volatile. g. > > > > _______________________________________________ > Arm.ebbr-discuss mailing list > Arm.ebbr-discuss(a)arm.com >

8 years, 2 months

1
0
0 0

[RFC] uefi: Account for SetVariable() not working at runtime

by Grant Likely

Add details on what to do if the platform is unable to set persistent variables in runtime services. The idea here is that the GetVariable() and SetVariable() APIs should continue to work, and the OS can obtain all the variable settings, but if it cannot be written then the NON_VOLATILE attribute is cleared so the OS knows that persistence is not available. Cc: Dong Wei <dong.wei(a)arm.com> Cc: Alexander Graf <agraf(a)suse.de> Cc: Peter Robinson <pbrobinson(a)redhat.com> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- Alex/Peter: Does this approach work for you? I tried to come up with something that is faithful to the spec, gives the OS information that non-volatile variables aren't available, but still have the ability to query the boot environment. Dong: Is this an appropriate way to use {Get,Set}Variable()? Cheers, g. --- source/chapter2-uefi.rst | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7b6843e..57594bc 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -197,13 +197,13 @@ command: Operating Systems calls to reset the system will go via Runtime Services and not directly to PSCI. -Set Variable ------------- - -Non-volatile UEFI variables must persist across reset, and emulated variables -in RAM are not permitted. -The UEFI Runtime Services must be able to update the variables directly without -the aid of the Operating System. +Runtime Variable Access +----------------------- -.. note:: This normally requires dedicated storage for UEFI variables that is - not directly accessible from the Operating System. +Non-volatile UEFI variables must persist across reset. +If the platform is incapable of updating non-volatile variables from Runtime +Services then it must clear the EFI_VARIABLE_NON_VOLATILE attribute from all +non-volatile variables when ExitBootServices() is called. +Similarly, if non-volatile variables cannot be set from Runtime Services, then +SetVariable() must return EFI_INVALID_PARAMETER if the +EFI_VARIABLE_NON_VOLATILE attribute is set. -- 2.13.0

8 years, 2 months

4
4
0 0

Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

by Grant Likely

On 12/07/2018 14:12, Mark Brown wrote: > On Thu, Jul 12, 2018 at 01:50:45PM +0100, Daniel Thompson wrote: >> On Thu, Jul 12, 2018 at 11:41:08AM +0100, Grant Likely wrote: >>> Add details on what to do if the platform is unable to set persistent >>> variables in runtime services. The idea here is that the GetVariable() >>> and SetVariable() APIs should continue to work, and the OS can obtain >>> all the variable settings, but if it cannot be written then the >>> NON_VOLATILE attribute is cleared so the OS knows that persistence is >>> not available. >> >> I'm really struggling to wrap my head around this one. >> >> How does incorrectly describing a non-volatile but non-modifiable >> variable as volatile help the OS do the right thing? I took a read through section 8.2 of the UEFI spec (Variable services) before drafting the proposal. UEFI doesn't define a "read-only" attribute for variables. It has a non-volatile attribute that says a variable change will be persistant. My thought here was that clearing the non-volatile flag will indicate that making a change to that variable will not be saved, and so won't change the boot order. If an OS tries to modify a variable without using the exact same attributes, then SetVariable() will fail. e.g., If the OS tries to set EFI_VARIABLE_NON_VOLATILE on a veriable without that attribute, then it will fail with EFI_INVALID_PARAMETER (See description of SetVariable()). With my proposed text, if the OS tries to set a new variable with the EFI_VARIABLE_NON_VOLATILE attribute set, then SetVariable() will also fail. (At runtime only; boot time SetVariable() should work as defined). An OS can determine in two ways if variable writes are allowed. 1) If the BOOT* varilables don't have the NON_VOLATILE attribute. 2) A EFI_INVALID_PARAMETER return code when attempting to create an non-volatile variable, or set the NON_VOLATILE attribute. >> The OS will discover the variable is non-modifiable when it tried to >> set it. Won't the current proposal mislead standards compliant use of >> GetVariable()? For example does it it makes standards compliant code >> *more* likely to call SetVariable() in order to fix up a variable that >> it thinks was incorrectly set with the NON_VOLATILE attribute. If it tried to, the call to SetVariable() will fail. > > Do any existing implementations change variables from non-volatile to > volatile? I don't know. That's part of why this is an RFC. I'm looking for the most spec-compatible way to deal with platforms that cannot set non-volatile variables at runtime. The UEFI spec is written with the assumption that non-volatile variables can be written at runtime. EBBR encompases platforms that cannot (yet?) do that, so we're in new territory. There are other approaches that could be taken too. - Alex said a while back that if UEFI doesn't provide any variables at runtime, then it assumes non-volatile variables aren't available and will treat the ESP as if it were removable media. - The problem with this approach is it is a very blunt hammer. It eliminates all possible users of variables at runtime. - We could add an EBBR_FLAGS variable or something similar to indicate EBBR style quirks, like non-volatile variables cannot be written at runtime. Let's talk about this in the weekly meeting later today. g.

8 years, 2 months

1
0
0 0

RE: [Arm.ebbr-discuss] [PATCH] Update manifesto from comments on mailing list

by Dong Wei

I like this better😊 - DW - -----Original Message----- From: arm.ebbr-discuss-bounces(a)arm.com <arm.ebbr-discuss-bounces(a)arm.com> On Behalf Of Mark Brown Sent: Thursday, July 12, 2018 3:18 AM To: Grant Likely <Grant.Likely(a)arm.com> Cc: boot-architecture(a)lists.linaro.org; arm.ebbr-discuss <arm.ebbr-discuss(a)arm.com>; nd <nd(a)arm.com> Subject: Re: [Arm.ebbr-discuss] [PATCH] Update manifesto from comments on mailing list On Wed, Jul 11, 2018 at 09:11:53PM +0100, Grant Likely wrote: > On 09/07/2018 13:39, Mark Brown wrote: > > On Mon, Jul 09, 2018 at 01:17:56PM +0100, Grant Likely wrote: > > > - While ACPI provides more standardization, Devicetree is > > > preferred in may embedded > > > - platforms for its flexibility. > > > + While ACPI provides more standardization, Devicetree is > > > + preferred in many embedded platforms for its flexibility. > > Bit of a pet peeve of mine since ASoC means I'm frequently having to > > think about systems that fall off the edge of what ACPI can express > > and it's just a miserable experience. > Understood, but I'm going to leave it as is for now. I don't want to > get into a discussion of the reasons Devicetree is preferred. I just > want to acknowledge that both DT and ACPI are supported options. OK... part of what I was reacting to there was that the text read to me like it was making value judgements about the merits of the two (or at least it's a lot like what people say). How about either striking this entirely or something like: Either ACPI or Devicetree may be used depending on which meets the needs of the system better, they have different platform models. 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.

8 years, 2 months

1
0
0 0

Re: [Arm.ebbr-discuss] [RFC] uefi: Account for SetVariable() not working at runtime

by Ard Biesheuvel

On 12 July 2018 at 15:12, Mark Brown <broonie(a)kernel.org> wrote: > On Thu, Jul 12, 2018 at 01:50:45PM +0100, Daniel Thompson wrote: > >> The OS will discover the variable is non-modifiable when it tried to >> set it. Won't the current proposal mislead standards compliant use of >> GetVariable()? For example does it it makes standards compliant code >> *more* likely to call SetVariable() in order to fix up a variable that >> it thinks was incorrectly set with the NON_VOLATILE attribute. > > Do any existing implementations change variables from non-volatile to > volatile? > The UEFI spec is explicit about which variables are volatile and which are not. Simply relaxing non-volatile to volatile in the general case doesn't seem like a useful approach to me.

8 years, 2 months

2
1
0 0

Re: [PATCH] Update manifesto from comments on mailing list

by Grant Likely

On 12/07/2018 11:18, Mark Brown wrote: > On Wed, Jul 11, 2018 at 09:11:53PM +0100, Grant Likely wrote: >> On 09/07/2018 13:39, Mark Brown wrote: >>> On Mon, Jul 09, 2018 at 01:17:56PM +0100, Grant Likely wrote: > >>>> - While ACPI provides more standardization, Devicetree is preferred in may embedded >>>> - platforms for its flexibility. >>>> + While ACPI provides more standardization, Devicetree is preferred in many >>>> + embedded platforms for its flexibility. > >>> Bit of a pet peeve of mine since ASoC means I'm frequently having to >>> think about systems that fall off the edge of what ACPI can express and >>> it's just a miserable experience. > >> Understood, but I'm going to leave it as is for now. I don't want to get >> into a discussion of the reasons Devicetree is preferred. I just want to >> acknowledge that both DT and ACPI are supported options. > > OK... part of what I was reacting to there was that the text read to me > like it was making value judgements about the merits of the two (or at > least it's a lot like what people say). How about either striking this > entirely or something like: I've dropped it entirely. g.

8 years, 2 months

1
0
0 0

[PATCH] v0.6-pre1 draft comments responses

by Grant Likely

Edits responding to comments from Udit Kumar Suggested-by: Udit Kumar <udit.kumar(a)nxp.com> Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter1-about.rst | 16 +++++++++------- source/chapter4-firmware-media.rst | 3 ++- 2 files changed, 11 insertions(+), 8 deletions(-) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index a2561d6..1dafd39 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -10,7 +10,7 @@ between platform firmware and an operating system that is suitable for embedded platforms. EBBR compliant platforms present a consistent interface that will boot an EBBR compliant operating system without any custom tailoring required. -For example, an Arm A-class embedded networking platform will benefit +For example, an Arm A-class embedded platform will benefit from a standard interface that supports features such as secure boot and firmware update. @@ -149,12 +149,14 @@ Operating System. This specification is similar to the Arm Server Base Boot Requirements specification [SBBR]_ in that it defines the firmware interface presented to an -operating system, with SBBR having stricter requirements on hardware and -firmware than EBBR. -EBBR allows for design decisions that are common in the embedded space, but not -supported by the server ecosystem. -For example, an embedded system may use a single eMMC storage device to hold -both firmware and operating system images. +operating system. +SBBR is targeted at the server ecosystem and places strict requirements on the +platform to ensure cross vendor interoperability. +EBBR on the other hand allows more flexibility to support embedded designs +which do not fit within the SBBR model. +For example, a platform that isn't SBBR compliant because the SoC is only +supported using Devicetree could be EBBR compliant, but not SBBR compliant. + By definition, all SBBR compliant systems are also EBBR compliant, but the converse is not true. diff --git a/source/chapter4-firmware-media.rst b/source/chapter4-firmware-media.rst index 604df18..39a1c03 100644 --- a/source/chapter4-firmware-media.rst +++ b/source/chapter4-firmware-media.rst @@ -4,7 +4,8 @@ Firmware Storage In general, EBBR compliant platforms should use dedicated storage for boot firmware images and data, -independent of the storage used for OS partitions and the ESP. +independent of the storage used for OS partitions and the EFI System Partition +(ESP). This could be a physically separate device (e.g. SPI flash), or a dedicated logical unit (LU) within a device (e.g. eMMC boot partition, [#eMMCBootPartition]_ -- 2.13.0 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.

8 years, 2 months

2
1
0 0

EBBR v0.6-pre1 Released

by Grant Likely

I've tagged the prerelease in preparation for a wider v0.6 RFC release next week. Please review and comment: https://github.com/glikely/ebbr/releases/tag/v0.6-pre1 (I've linked to the copy on my personal ebbr fork because I'm having trouble getting Travis-ci to deploy to the official repo. It will take a bit of effort to work out what is wrong) 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.

8 years, 2 months

3
7
0 0

[PATCH] Update manifesto from comments on mailing list

by Grant Likely

Editing in response to comments from Bill Mills, Daniel Thompson, and Alex Graf. Mostly trivial editorial, but did flush out the discussion of how future updates to the specification would be handled, and added a note about DT platform compatibility rules. Signed-off-by: Grant Likely <grant.likely(a)arm.com> Cc: Bill Mills <wmills(a)ti.com> Cc: Alexander Graf <agraf(a)suse.de> Cc: Daniel Thompson <daniel.thompson(a)linaro.org> --- source/chapter1-about.rst | 49 ++++++++++++++++++++++++++++++++--------------- 1 file changed, 34 insertions(+), 15 deletions(-) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index cb675d9..a2561d6 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -23,7 +23,7 @@ It leverages the prevalent industry standard firmware specification of [UEFI]_. Comments or change requests can be sent to arm.ebbr-discuss(a)arm.com. -Guiding Principals +Guiding Principles ================== EBBR as a specification defines requirements on platforms and operating systems, @@ -51,7 +51,7 @@ amount of custom engineering required, make it possible for OS distributions to support embedded platforms, while still preserving the firmware stack product vendors are comfortable with. Or in simpler terms, EBBR is designed to solve the embedded boot mess by -migrating existing firmware projects (U-Boot) to a defined standard (UEFI). +adding a defined standard (UEFI) to the existing firmware projects (U-Boot). However, EBBR is a specification, not an implementation. The goal of EBBR is not to mandate U-Boot and Linux. @@ -61,24 +61,33 @@ ensure that the EBBR requirements are implemented by both projects. [#EDK2Note]_ .. [#EDK2Note] Tianocore/EDK2 and U-Boot are highlighted here because at the - time of writing these are the two most important firmware projects. + time of writing these are the two most important firmware projects that + implement UEFI. Tianocore/EDK2 is a full featured UEFI implementation and so should - automatically be EBBR compliant. U-Boot is the incumbant firmware project - for embedded platforms and has added basic UEFI compliance. + automatically be EBBR compliant. + U-Boot is the incumbant firmware project for embedded platforms and has + steadily been adding UEFI compliance since 2016. -The following guiding principals of the EBBR specification and its -process: +The following guiding principles are used while developing the EBBR specification. - Be agnostic about ACPI and Devicetree. EBBR explicitly does not require a specific system description language. Both Devicetree and ACPI are supported. - While ACPI provides more standardization, Devicetree is preferred in may embedded - platforms for its flexibility. + While ACPI provides more standardization, Devicetree is preferred in many + embedded platforms for its flexibility. The Linux kernel supports both equally well, and so EBBR doesn't require one over the other. - However, it does require the system description to be provided by the - platform, and that it conform to the relevant ACPI or DT specifications. + However, EBBR does require the system description to be supplied by the + platform, not the OS. + The platform must also conform to the relevant ACPI or DT specifications and + adhere to platform compatibility rules. [#CompatRules]_ + +.. [#CompatRules] It must be acknowledged that at the time of writing this + document, platform compatibility rules for DT platforms are not well defined + or documented. + We the authors recognize that this is a problem and are working to solve it + in parallel with this specification. - Focus on the UEFI interface, not a specific codebase @@ -112,10 +121,20 @@ process: - Plan to evolve over time - The first release of EBBR is firmly targeting current embedded hardware. - Future versions will add capabilities which may tighten the hardware requirements. - - However, existing compliant boards will remain compliant. + The v1.0 release of EBBR is firmly targeted at existing platforms so that + gaining EBBR compliance may require a firmware update, but will not require + hardware changes for the majority of platforms. + + Future EBBR releases will tighten requirements to add features and improve + compatibility, which may affect hardware design choices. + However, EBBR will not retroactively revoke support from previously compliant + platforms. + Instead, new requirements will be clearly documented as being over and above + what was required by a previous release. + Existing platforms will be able to retain compliance with a previous + requirement level. + In turn, OS projects and end users can choose what level of EBBR compliance + is required for their use case. Scope ===== -- 2.13.0

8 years, 2 months

5
5
0 0

Re: [PATCH] Update manifesto from comments on mailing list

by Grant Likely

On 09/07/2018 13:39, Mark Brown wrote: > On Mon, Jul 09, 2018 at 01:17:56PM +0100, Grant Likely wrote: > >> - While ACPI provides more standardization, Devicetree is preferred in may embedded >> - platforms for its flexibility. >> + While ACPI provides more standardization, Devicetree is preferred in many >> + embedded platforms for its flexibility. > > How about something more like > > While ACPI provides strong standardization for platforms that fit > within its model many embedded platforms do not work well within > that model so the standards offered by Devicetree are preferred. > > Bit of a pet peeve of mine since ASoC means I'm frequently having to > think about systems that fall off the edge of what ACPI can express and > it's just a miserable experience. Understood, but I'm going to leave it as is for now. I don't want to get into a discussion of the reasons Devicetree is preferred. I just want to acknowledge that both DT and ACPI are supported options. g.

8 years, 2 months

1
0
0 0

[PATCH v4 0/6] Make deferring probe forever optional

by Rob Herring

This series came out of a discussion on the ARM boot-architecture list[1] about DT forwards and backwards compatibility issues. There are issues with newer DTs breaking on older, stable kernels. Some of these are difficult to solve, but cases of optional devices not having kernel support should be solvable. I tested this on a RPi3 B with the pinctrl driver forced off. With this change, the MMC/SD and UART drivers can function without the pinctrl driver. I left the dts change out this time. v2 and v3 of this series can be found here[2][3]. Rob [1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html [2] https://lore.kernel.org/patchwork/project/lkml/list/?series=347413 [3] https://lore.kernel.org/patchwork/project/lkml/list/?series=357344 Rob Herring (6): driver core: allow stopping deferred probe after init dt-bindings: pinctrl: add a 'pinctrl-use-default' property pinctrl: Support stopping deferred probe after initcalls iommu: Stop deferring probe at end of initcalls iommu: Remove IOMMU_OF_DECLARE PM / Domains: Stop deferring probe at the end of initcall .../admin-guide/kernel-parameters.txt | 9 +++ .../bindings/pinctrl/pinctrl-bindings.txt | 6 ++ drivers/base/dd.c | 59 +++++++++++++++++++ drivers/base/power/domain.c | 2 +- drivers/iommu/arm-smmu-v3.c | 2 - drivers/iommu/arm-smmu.c | 7 --- drivers/iommu/exynos-iommu.c | 2 - drivers/iommu/ipmmu-vmsa.c | 3 - drivers/iommu/msm_iommu.c | 2 - drivers/iommu/of_iommu.c | 21 +------ drivers/iommu/qcom_iommu.c | 2 - drivers/iommu/rockchip-iommu.c | 2 - drivers/pinctrl/devicetree.c | 15 +++-- include/asm-generic/vmlinux.lds.h | 2 - include/linux/device.h | 2 + include/linux/of_iommu.h | 4 -- 16 files changed, 90 insertions(+), 50 deletions(-) -- 2.17.1

8 years, 2 months

3
11
0 0

[PATCH] Be clear that UEFI is required

by Grant Likely

Some of the language was ambiguous and it seemed like UEFI was optional. Tighten it up to be clear the EBBR requires UEFI and add some details about how EBBR informs how UEFI is used for embedded systems. The block device partitioning section is also moved within the chapter so it doesn't appear as a subsection of the system environment section (which mainly talks about the CPU execution mode). Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/appendix-a-uefi-features.rst | 2 ++ source/chapter1-about.rst | 17 ++++++++++------- source/chapter2-uefi.rst | 29 ++++++++++++++--------------- 3 files changed, 26 insertions(+), 22 deletions(-) diff --git a/source/appendix-a-uefi-features.rst b/source/appendix-a-uefi-features.rst index 0bdc712..709b929 100644 --- a/source/appendix-a-uefi-features.rst +++ b/source/appendix-a-uefi-features.rst @@ -1,3 +1,5 @@ +.. _appendix-uefi-requirements: + ############################################# APPENDIX A - UEFI Implementation Requirements ############################################# diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index d713cf3..b667f1b 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -5,18 +5,21 @@ About This Document Introduction ============ -This Embedded Base Boot Requirements (EBBR) specification is intended for Arm -embedded devices that want to take advantage of the UEFI technology to separate -the firmware and OS development. -For example, class-A embedded devices like networking platforms can benefit +This Embedded Base Boot Requirements (EBBR) specification defines an interface +between platform firmware and an operating system that is suitable for embedded +platforms. +EBBR compliant platforms present a consistent interface that will boot an EBBR +compliant operating system without any custom tailoring required. +For example, an Arm A-class embedded networking platform will benefit from a standard interface that supports features such as secure boot and firmware update. -This specification defines the base firmware requirements if UEFI is chosen. +This specification defines the base firmware requirements for EBBR compliant platforms. The requirements in this specification are expected to be minimal yet complete, while leaving plenty of room for innovations and design details. This specification is intended to be OS-neutral. -It leverages the prevalent industry standard firmware specifications of UEFI. + +It leverages the prevalent industry standard firmware specification of [UEFI]_. Comments or change requests can be sent to arm.ebbr-discuss(a)arm.com. @@ -24,7 +27,7 @@ Scope ===== This document defines the boot and runtime services that are expected by an Operating System or hypervisor, for an Arm embedded device, which follows the -UEFI specification. +UEFI specification [UEFI]_. This specification defines the boot and runtime services for a physical system, including services that are required for virtualization. diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index d13c19e..a8bd71e 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -2,21 +2,26 @@ UEFI **** +This chapter discusses specific UEFI implementation details for EBBR compliant +platforms. + UEFI Version ============ - -Boot and system firmware for Arm embedded devices can be based on the UEFI -specification [UEFI]_, version 2.7 or later, incorporating the AArch64 bindings. +This document uses version 2.7 of the UEFI specification [UEFI]_. UEFI Compliance =============== -Any UEFI-compliant system must follow the requirements that are laid out in -section 2.6 of the UEFI specification [UEFI]_. -However, to ensure a common boot architecture for embedded-class, systems -compliant with this specification must always provide the UEFI services and -protocols that are listed in Appendix A, Appendix B, and Appendix C of this -document. +EBBR compliant platforms shall conform to the requirements in [UEFI]_ § 2.6, +except where explicit exemptions are provided by this document. + +EBBR compliant platforms shall also implement the UEFI services and +protocols that are listed in :ref:appendix-uefi-requirements of this document. + +Block device partitioning +------------------------- + +The system firmware must implement support for MBR, GPT and El Torito partitioning. UEFI System Environment and Configuration ========================================= @@ -50,12 +55,6 @@ UEFI-compliant Operating System. In this instance, the UEFI boot-time environment can be provided, as a virtualized service, by the hypervisor and not as part of the host firmware. -System Volume Format --------------------- - -The system firmware must support all partitioning standards required -by the UEFI specification. - UEFI Boot Services ================== -- 2.13.0

8 years, 2 months

2
3
0 0

[PATCH] Introduction: add a manifesto

by Grant Likely

Give some rationale behind EBBR so the reader understands what problem the specification is intended to solve. Signed-off-by: Bill Mills <wmills(a)ti.com> [glikely: made it more verbose to make the intent clear] Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter1-about.rst | 94 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 94 insertions(+) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index b667f1b..cb675d9 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -23,6 +23,100 @@ It leverages the prevalent industry standard firmware specification of [UEFI]_. Comments or change requests can be sent to arm.ebbr-discuss(a)arm.com. +Guiding Principals +================== + +EBBR as a specification defines requirements on platforms and operating systems, +but requirements alone don't provide insight into why the specification is +written the way it is, or what problems it is intended to solve. +Using the assumption that better understanding of the thought process behind +EBBR will result in better implementations, this section is a discussion of the +goals and guiding principle that shaped EBBR. + +This section should be considered commentary, and not a formal part of the specification. + +EBBR was written as a response to the lack of boot sequence standardization in the embedded system ecosystem. +As embedded systems are becoming more sophisticated and connected, +it is becoming increasingly important for embedded systems to run standard OS +distributions and software stacks, or to have consistent behaviour across a +large deployment of heterogeneous platforms. +However, the lack of consistency between platforms often requires per-platform +customization to get an OS image to boot on multiple platforms. + +A large part of this ecosystem is based on U-Boot and Linux. +Vendors have heavy investments in both projects and are not interested in large +scale changes to their firmware architecture. +The challenge for EBBR is to define a set of boot standards that reduce the +amount of custom engineering required, make it possible for OS distributions to +support embedded platforms, while still preserving the firmware stack product +vendors are comfortable with. +Or in simpler terms, EBBR is designed to solve the embedded boot mess by +migrating existing firmware projects (U-Boot) to a defined standard (UEFI). + +However, EBBR is a specification, not an implementation. +The goal of EBBR is not to mandate U-Boot and Linux. +Rather, it is to mandate interfaces that can be implemented by any firmware or +OS project, while at the same time work with both Tianocore/EDK2 and U-Boot to +ensure that the EBBR requirements are implemented by both projects. +[#EDK2Note]_ + +.. [#EDK2Note] Tianocore/EDK2 and U-Boot are highlighted here because at the + time of writing these are the two most important firmware projects. + Tianocore/EDK2 is a full featured UEFI implementation and so should + automatically be EBBR compliant. U-Boot is the incumbant firmware project + for embedded platforms and has added basic UEFI compliance. + +The following guiding principals of the EBBR specification and its +process: + +- Be agnostic about ACPI and Devicetree. + + EBBR explicitly does not require a specific system description language. + Both Devicetree and ACPI are supported. + While ACPI provides more standardization, Devicetree is preferred in may embedded + platforms for its flexibility. + The Linux kernel supports both equally well, and so EBBR doesn't require one + over the other. + However, it does require the system description to be provided by the + platform, and that it conform to the relevant ACPI or DT specifications. + +- Focus on the UEFI interface, not a specific codebase + + EBBR does not require a specific firmware implementation. + Any firmware project can implement these interfaces. + Neither U-Boot nor Tianocore/EDK2 are required. + +- Design to be implementable and useful today + + The drafting process for EBBR worked closely with U-Boot and Tianocore + developers to ensure that current upstream code will meet the requirements. + +- Design to be OS independent + + This document uses Linux as an example but other OS's are expected. + +- Support multiple architectures + + Any architecture can implement the EBBR requirements. + + .. note:: + At the time of writing this document only addresses AArch64, but AArch32 and others architectures are expected. + +- Design for common embedded hardware + + EBBR support will be implemented on existing developer hardware. + Generally anything that has a near-upstream U-Boot implementation should be + able to implement the EBBR requirements. + EBBR was drafted with readily available hardware in mind, like the + Raspberry Pi and BeagleBone families of boards, and it is applicable for low cost boards (<$10). + +- Plan to evolve over time + + The first release of EBBR is firmly targeting current embedded hardware. + Future versions will add capabilities which may tighten the hardware requirements. + + However, existing compliant boards will remain compliant. + Scope ===== This document defines the boot and runtime services that are expected by an -- 2.13.0

8 years, 2 months

6
9
0 0

Questions about GPT

by William Mills

All, I rely on your greater knowledge to help me understand these questions. Thanks in advance. 1) GPT and block size GPT uses LBA for its data stuctures The size of a block is historically 512B but is moving to larger sizes (4KB). The code needs to handle this on a per device mount basis. How does the driver know the block size used in the LBA? 1A) By querying the device 1B) Some MBR magic? If 1A then that means to me that dd if=/dev/sdb of=/dev/sdc won't produce a usable image on sdc if its block size is different than sdb's. (Of course I also assume that the total space ion sdc is also == or > than that of sdb. Which brings me to ...) 2) Can GPT be grown? In the above example if sdc is much bigger than sdb, I presume this is OK, at least as long as the GPT header in LBA1 passes its CRC. Mounters won't query the drive size and refuse to mount the GPT just because it does not cover the whole disk right? Now what happens if LBA1 becomes corrupted? Now does the driver query the drive size and block size and look at drive_size-block_size for the backup GOT header? Again does it use the block size from the device or does try something else? (I suppose to could try several block sizes until it found a good CRC. However it does seem that it must assume that the redundant copy is at the end of the physical disk.) So even if the GPT is "mounted" OK, the extra space on the drive is not usable, even for new partitions. Are there utilities that will "grow" the GPT? Such growing would find the new end of disk and move the redundant GPT table & header there. 3) Is it actually required that the partition array start at LBA2? If not, then it would be possible to create a GPT assuming 512B blocks but allow it to be "re-block sized" later by leaving 7 512B blocks free before the table. Of course the partitions themselves should be aligned and sized to multiples of the max block size expected. This is probibly already done as you would want them to align to the prefered read/write and those will almost certianly be larger than 512B. Why? The main case I am thinking about is: wget http://downloads.new-wizbang-os.org/images/latest/aarch64-disk.img dd if=aarch64-disk.img of=/dev/my-usb-sd-adapter Then boot the image and the OS will resize the GPT and last filesystem to cover the 16GB of my SD card even though they only require a minimum size of 2GB. Thanks, Bill ---------------- William A. Mills Chief Technologist, Open Solutions, SDO Texas Instruments, Inc. 20450 Century Blvd Germantown MD 20878 240-643-0836

8 years, 2 months

8
20
0 0

[PATCH v3 0/6] Make deferring probe forever optional

by Rob Herring

This series came out of a discussion on the ARM boot-architecture list[1] about DT forwards and backwards compatibility issues. There are issues with newer DTs breaking on older, stable kernels. Some of these are difficult to solve, but cases of optional devices not having kernel support should be solvable. I tested this on a RPi3 B with the pinctrl driver forced off. With this change, the MMC/SD and UART drivers can function without the pinctrl driver. I left the dts change out this time. v2 of this series can be found here[2]. Rob [1] https://lists.linaro.org/pipermail/boot-architecture/2018-April/000466.html [2] https://lore.kernel.org/patchwork/project/lkml/list/?series=347413 Rob Herring (6): driver core: allow stopping deferred probe after init dt-bindings: pinctrl: add a 'pinctrl-use-default' property pinctrl: Support stopping deferred probe after initcalls iommu: Stop deferring probe at end of initcalls iommu: Remove IOMMU_OF_DECLARE PM / Domains: Stop deferring probe at the end of initcall .../admin-guide/kernel-parameters.txt | 9 +++ .../bindings/pinctrl/pinctrl-bindings.txt | 6 ++ drivers/base/dd.c | 57 +++++++++++++++++++ drivers/base/power/domain.c | 2 +- drivers/iommu/arm-smmu-v3.c | 2 - drivers/iommu/arm-smmu.c | 7 --- drivers/iommu/exynos-iommu.c | 2 - drivers/iommu/ipmmu-vmsa.c | 3 - drivers/iommu/msm_iommu.c | 2 - drivers/iommu/of_iommu.c | 21 +------ drivers/iommu/qcom_iommu.c | 2 - drivers/iommu/rockchip-iommu.c | 2 - drivers/pinctrl/devicetree.c | 15 +++-- include/asm-generic/vmlinux.lds.h | 2 - include/linux/device.h | 2 + include/linux/of_iommu.h | 4 -- 16 files changed, 88 insertions(+), 50 deletions(-) -- 2.17.1

8 years, 2 months

5
11
0 0

EBBR presentations at LInaro Connect and ELC-E

by Mills, William

All, We really should be doing presentations at Linaro Connect and ELC-E. I can volunteer to help present at ELC-E but I think it would looks better if a small group was represented. For Connect, I won't volunteer to present. I tried that last time and with my required schedule at connect it just does not work out. The ELC-E CFP closed Monday. Perhaps we can sweet talk an extension? Grant, you might have the best chance. Thanks, Bill --------------------------------------------------- William A. Mills Chief Technologist, Open Source Texas Instruments, Processors 20450 Century Blvd Germantown MD, 20874 (work/mobile) +1-240-643-0836

8 years, 2 months

4
6
0 0

UEFI requirements section

by Grant Likely

Dong, Looking at the current state of EBBR, Appendix A contains a big list of boot/runtime services and protocols that are required to be implemented. However, I don't think this list has been audited, and I'm not sure how much of it is actually needed. Some of these things (like the list of boot/runtime services) seem to be required by the UEFI spec, so it is redundant to list them here. I'm also unsure on the list of protocols. Some I'm sure are already required by the UEFI spec. e.g., UEFI section 2.6.1 requires EFI_LOADED_IMAGE_PROTOCOL, EFI_LOADED_IMAGE_DEVICE_PATH, EFI_DEVICE_PATH_PROTOCOL, EFI_DECOMPRESS_PROTOCOL, and EFI_DEVICE_PATH_UTILITIES_PROTOCOL, so is it necessary to list them in EBBR? Looking at the current U-Boot implementation, only the following protocols are implemented: include/efi_api.h|277| #define LOADED_IMAGE_PROTOCOL_GUID \ include/efi_api.h|519| #define EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL_GUID \ include/efi_api.h|590| #define EFI_SIMPLE_TEXT_INPUT_PROTOCOL_GUID \ include/efi_api.h|603| #define EFI_DEVICE_PATH_TO_TEXT_PROTOCOL_GUID \ include/efi_api.h|619| #define EFI_DEVICE_PATH_UTILITIES_PROTOCOL_GUID \ include/efi_api.h|853| #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \ include/efi_api.h|882| #define EFI_SIMPLE_FILE_SYSTEM_PROTOCOL_GUID \ include/efi_api.h|933| #define EFI_DRIVER_BINDING_PROTOCOL_GUID \ Presumably Grub and the kernel only use the above protocols, and they are sufficient to handle perform the distro installer use case. Yet it is not compliant with UEFI 2.7. Notably missing are: UEFI § 2.6.1 - EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL - EFI_DEVICE_PATH_PROTOCOL - EFI_DECOMPRESS_PROTOCOL UEFI § 2.6.2 - EFI_SIMPLE_TEXT_EX_PROTOCOL - EFI_BLOCK_IO_PROTOCOL - EFI_DISK_IO_PROTOCOL - EFI_UNICODE_COLLATION_PROTOCOL - EFI_SERIAL_IO_PROTOCOL - EFI_USB2_HC_PROTOCOL - EFI_USB_IO_PROTOCOL In fact, perhaps what EBBR needs is a list of exceptions to the UEFI § 2.6 requirements (expected to reduce over time as the U-Boot implementation matures). Thoughts? For discussion, I've pasted the text of the current UEFI appendix below to make it easy to comment on the mailing list. g. --- .. _appendix-uefi-requirements: ############################################# APPENDIX A - UEFI Implementation Requirements ############################################# Required Boot Services ********************** ========================================== ====== Service UEFI § ========================================== ====== EFI_RAISE_TPL 7.1 EFI_RESTORE_TPL 7.1 EFI_ALLOCATE_PAGES 7.2 EFI_FREE_PAGES 7.2 EFI_GET_MEMORY_MAP 7.2 EFI_ALLOCATE_POOL 7.2 EFI_FREE_POOL 7.2 EFI_CREATE_EVENT 7.1 EFI_SET_TIMER 7.1 EFI_WAIT_FOR_EVENT 7.1 EFI_SIGNAL_EVENT 7.1 EFI_CLOSE_EVENT 7.1 EFI_INSTALL_PROTOCOL_INTERFACE 7.3 EFI_REINSTALL_PROTOCOL_INTERFACE 7.3 EFI_UNINSTALL_PROTOCOL_INTERFACE 7.3 EFI_HANDLE_PROTOCOL 7.3 EFI_REGISTER_PROTOCOL_NOTIFY 7.3 EFI_LOCATE_HANDLE 7.3 EFI_LOCATE_PROTOCOL 7.3 EFI_LOCATE_DEVICE_PATH 7.3 EFI_INSTALL_CONFIGURATION_TABLE 7.3 EFI_IMAGE_LOAD 7.4 EFI_IMAGE_START 7.4 EFI_EXIT 7.4 EFI_IMAGE_UNLOAD 7.4 EFI_EXIT_BOOT_SERVICES 7.4 EFI_GET_NEXT_MONOTONIC_COUNT 7.5 EFI_STALL 7.5 EFI_SET_WATCHDOG_TIMER 7.5 EFI_CONNECT_CONTROLLER 7.3 EFI_DISCONNECT_CONTROLLER 7.3 EFI_OPEN_PROTOCOL 7.3 EFI_CLOSE_PROTOCOL 7.3 EFI_OPEN_PROTOCOL_INFORMATION 7.3 EFI_PROTOCOLS_PER_HANDLE 7.3 EFI_LOCATE_HANDLE_BUFFER 7.3 EFI_LOCATE_PROTOCOL 7.3 EFI_INSTALL_MULTIPLE_PROTOCOL_INTERFACES 7.3 EFI_UNINSTALL_MULTIPLE_PROTOCOL_INTERFACES 7.3 EFI_CALCULATE_CRC32 7.5 EFI_COPY_MEM 7.5 EFI_SET_MEM 7.5 EFI_CREATE_EVENT_EX 7.5 ========================================== ====== Required Runtime Services ************************* ========================================== ====== Service UEFI § ========================================== ====== EFI_GET_TIME 8.3 EFI_SET_TIME 8.3 EFI_GET_WAKEUP_TIME 8.3 EFI_SET_WAKEUP_TIME 8.3 EFI_SET_VIRTUAL_ADDRESS_MAP 8.4 EFI_CONVERT_POINTER 8.4 EFI_GET_VARIABLE 8.2 EFI_GET_NEXT_VARIABLE_NAME 8.2 EFI_SET_VARIABLE 8.2 EFI_GET_NEXT_HIGH_MONO_COUNT 8.5 EFI_RESET_SYSTEM 8.5 EFI_UPDATE_CAPSULE 8.5 EFI_QUERY_CAPSULE_CAPABILITIES 8.5 EFI_QUERY_VARIABLE_INFO 8.5 ========================================== ====== .. note:: EFI_GET_WAKEUP_TIME and EFI_SET_WAKEUP_TIME must be implemented, but might simply return EFI_UNSUPPORTED. Required UEFI Protocols *********************** Core UEFI Protocols =================== ========================================== ====== Service UEFI § ========================================== ====== EFI_LOADED_IMAGE_PROTOCOL 9.1 EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL 9.2 EFI_DECOMPRESS_PROTOCOL 19.5 EFI_DEVICE_PATH_PROTOCOL 10.2 EFI_DEVICE_PATH_UTILITIES_PROTOCOL 10.3 ========================================== ====== Media I/O Protocols =================== ========================================== ====== Service UEFI § ========================================== ====== EFI_LOAD_FILE2_PROTOCOL 13.2 EFI_SIMPLE_FILE_SYSTEM_PROTOCOL 13.4 EFI_FILE_PROTOCOL 13.5 ========================================== ====== Console Protocols ================= ========================================== ====== Service UEFI § ========================================== ====== EFI_SIMPLE_TEXT_INPUT_PROTOCOL 12.2 EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL 12.3 EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL 12.4 ========================================== ====== Driver Configuration Protocols ============================== ========================================== ====== Service UEFI § ========================================== ====== EFI_HII_DATABASE_PROTOCOL 33.4 EFI_HII_STRING_PROTOCOL 33.4 EFI_HII_CONFIG_ROUTING_PROTOCOL 33.4 EFI_HII_CONFIG_ACCESS_PROTOCOL 33.4 ========================================== ====== Optional UEFI Protocols *********************** Basic Networking Support ======================== ============================================ ====== Service UEFI § ============================================ ====== EFI_SIMPLE_NETWORK_PROTOCOL 24.1 EFI_MANAGED_NETWORK_PROTOCOL 25.1 EFI_MANAGED_NETWORK_SERVICE_BINDING_PROTOCOL 25.1 ============================================ ====== .. note:: Networking services are optional on platforms that do not support networking. Network Boot Protocols ====================== ========================================== ====== Service UEFI § ========================================== ====== EFI_PXE_BASE_CODE_PROTOCOL 24.3 EFI_PXE_BASE_CODE_CALLBACK_PROTOCOL 24.4 EFI_BIS_PROTOCOL 24.5 EFI_MTFTP4_PROTOCOL 30.3 EFI_MTFTP6_PROTOCOL 30.4 ========================================== ====== .. note:: EFI_BIS_PROTOCOL is optional on machines that do not support Secure Boot. IPV4 Network Support ==================== ========================================== ====== Service UEFI § ========================================== ====== EFI_ARP_PROTOCOL 29.1 EFI_ARP_SERVICE_BINDING_PROTOCOL 29.1 EFI_DHCP4_SERVICE_BINDING_PROTOCOL 29.2 EFI_DHCP4_PROTOCOL 29.2 EFI_TCP4_PROTOCOL 28.1.2 EFI_TCP4_SERVICE_BINDING_PROTOCOL 28.1.1 EFI_IP4_SERVICE_BINDING_PROTOCOL 28.3.1 EFI_IP4_CONFIG2_PROTOCOL 28.5 EFI_UDP4_PROTOCOL 30.1.2 EFI_UDP4_SERVICE_BINDING_PROTOCOL 30.1.1 ========================================== ====== .. note:: Networking services are optional on platforms that do not support networking. IPV6 Network Support ==================== ========================================== ====== Service UEFI § ========================================== ====== EFI_DHCP6_PROTOCOL 29.3.2 EFI_DHCP6_SERVICE_BINDING_PROTOCOL 29.3.1 EFI_TCP6_PROTOCOL 28.2.2 EFI_TCP6_SERVICE_BINDING_PROTOCOL 28.2.1 EFI_IP6_SERVICE_BINDING_PROTOCOL 28.6.1 EFI_IP6_CONFIG_PROTOCOL 28.7 EFI_UDP6_PROTOCOL 30.2.2 EFI_UDP6_SERVICE_BINDING_PROTOCOL 30.2.1 ========================================== ====== .. note:: Networking services are optional on platforms that do not support networking. VLAN Protocols ============== ========================================== ====== Service UEFI § ========================================== ====== EFI_VLAN_CONFIG_PROTOCOL 27.1 ========================================== ====== iSCSI Protocols =============== ========================================== ====== Service UEFI § ========================================== ====== EFI_ISCSI_INITIATOR_NAME_PROTOCOL 16.2 ========================================== ====== .. note:: Support for iSCSI is only required on machines that lack persistent storage, such as a, HDD. This configuration is intended for thin clients and compute-only nodes 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.

8 years, 2 months

3
4
0 0

[PATCH] Introduction: Add a manifesto

by Bill Mills

Tell people what to expect from EBBR in easy bullet form. Signed-off-by: Bill Mills <wmills(a)ti.com> --- source/chapter1-about.rst | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 125e400..83c682f 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -18,6 +18,46 @@ while leaving plenty of room for innovations and design details. This specification is intended to be OS-neutral. It leverages the prevalent industry standard firmware specifications of UEFI. +Guiding Principals +================== + +The following are the guiding principals of the EBBR specification and its +process: + +- DeviceTree or ACPI + + Describes the hardware and firmware to the OS + +- UEFI interface, not a specific codebase + + Can be implemented by U-Boot or Tianocore/EDK2 or others + +- Implementable and useful today + + EBBR is always defined so that current U-Boot can implement the requirements + +- OS independant + + This document may use Linux as an example but other OS's are expected + +- Multiple Architectures + + This document addresses AArch64 today but AArch32 and others are expected + +- Is designed with Embedded Hardware in mind + + Works on today's boards + + Simple low cost hardware recommendations for tomorrow's boards + + Is appropriate for boards < $10 + +- Will evolve + + Future versions will add capabilities and may tighten hardware requirements + + However, existing compliant boards will remain compliant + Comments or change requests can be sent to arm.ebbr-discuss(a)arm.com. Scope -- 2.7.4

8 years, 2 months

4
4
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture