boot-architecture

boot-architecture@lists.linaro.org

624 discussions

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.

6 years, 2 months

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.

6 years, 2 months

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.

6 years, 2 months

[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.

6 years, 2 months

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.

6 years, 2 months

[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

6 years, 2 months

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.

6 years, 2 months

[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

6 years, 2 months

[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

6 years, 2 months

[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

6 years, 2 months

← Newer
1
...
35
36
37
38
39
40
41
...
63
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture