boot-architecture

boot-architecture@lists.linaro.org

1 participants
646 discussions

[EBBR PATCH] Reference BBR instead of SBBR

by Grant Likely

SBBR has been superseded by Arm BBR. Update the about section to reference BBR instead. However, none of the specification language changes because EBBR has a relaxed set of UEFI requirements compared to BBR. Fixes: #62 Signed-off-by: Grant Likely <grant.likely(a)secretlab.ca> --- source/chapter1-about.rst | 19 ++++++++----------- source/references.rst | 6 +++--- 2 files changed, 11 insertions(+), 14 deletions(-) diff --git a/source/chapter1-about.rst b/source/chapter1-about.rst index 68a1abc..6f69f53 100644 --- a/source/chapter1-about.rst +++ b/source/chapter1-about.rst @@ -146,17 +146,14 @@ including services that are required for virtualization. It does not define a standardized abstract virtual machine view for a Guest 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. -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 +This specification is referenced by the Arm Base Boot Requirements +Specification [ArmBBR]_ § 4.3. +The UEFI requirements found in this document are similar but not identical to +the requirements found in BBR. +EBBR provides greater flexibility for support embedded designs which cannot +easily meet the stricter BBR requirements. + +By definition, all BBR compliant systems are also EBBR compliant, but the converse is not true. Conventions Used in this Document diff --git a/source/references.rst b/source/references.rst index d91dc08..fb7dc81 100644 --- a/source/references.rst +++ b/source/references.rst @@ -22,9 +22,9 @@ <https://static.docs.arm.com/den0022/c/DEN0022C_Power_State_Coordination_Int…>`_ 30 January 2015, `Arm Limited <http://arm.com>`_ -.. [SBBR] `Arm Server Base Boot Requirements specification Issue B (v1.0) - <https://static.docs.arm.com/den0044/b/DEN0044B_Server_Base_Boot_Requirement…>`_ - 8 March 2016, `Arm Limited <http://arm.com>`_ +.. [ArmBBR] `Arm Base Boot Requirements specification Issue F (v1.0) + <https://developer.arm.com/documentation/den0044/f>`_ + 6 Oct 2020, `Arm Limited <http://arm.com>`_ .. [UEFI] `Unified Extensable Firmware Interface Specification v2.8 Errata A <https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_A_Feb14.pdf>`_, -- 2.20.1

4 years, 3 months

DTE meeting notes 2021-03-08

by Bill Mills

All, Here are my notes from today. Please correct anything I got wrong. Attendees: Bruce Ashfield Frank Rowand Simon Glass Etienne Carriere Heinrich Schuchardt Ilias Apalodimas Joakim Bech Loic Pallardy Mark Brown Mathieu Poirier Rob Herring Ruchika Gupta Vincent Guittot Vincent Stehle CC: Stefano Stabellini Kumar Gala Discussion: Today we did a brainstorming session on goals/requirements for a new DTB format. Remember this is a laundry list of requirements / concerns. Not all will necessarily be included in the new format but all will be considered. It is not a discussion of the format changes to achieve these goals. Frank Rowand will be collecting past discussions related to this and expects this to be ready for the meeting on March 22. * FR: Reduce Size * FR: Overlay support in "symbol table" not looking like HW description * FR: Ability to express "delete node" and "delete property" ** many: do we really need delete node, every node should have status ** RH: not everyone today looks for status != ok ** general agreement that they should ** RH: perhaps we should make it more automatic somehow * SG: New format should be little endian ** most current active / popular CPU arch are LE these days * SG: Ability to refer to data blob by reference instead of inline ** blob would still be in DTB file/image but not inline as a property blob * RH: Include type info ** Know what is a u64 vs u32 vs phandle ** replicate what we have in schema with bit fields etc ** enums?? structs?? * SG: Provision for comments * RH: In general want more less conversion DTS -> DTB -> DTS ** WAM: Is it OK to rely on schema? ** SG: Ideally not, would prefer self describing format * HS: Want to be able to validate DTB (against schema) ** WAM: Isnt this the same as type info? ** RH: That is a lot of it but there is more * WAM: We want a new section for meta data ** WAM: signatures as discussed on this call ** FR: Source file info / version markers ** HS/WAM: taint flag if the DTC compile or validate is not clean * SG: IN yaml we can import a node, ** would be good to have this in DTS as well ** FR: It is valid to bring in DTS requirements as some of this will effect anyway * WAM: Segmeneted DTB or DTB set ** instead of applying overlays leave base and overlay intact ** deliver to OS as a set with assembly order. ** [We can call it IKEA mode :) ] ** allows signatures to reamin valid, can be passed on ** makes it clear what fixups were performed by the firmware * SG: a previous node "pointer" ** going backwards is very slow in FDT * WAM: Huawei is asking for B-Tree to speed up search in FDT ** FR/RH: probably too far but we will consider * RH: DTB format could be unflattened ** SG: could be too big ** SG: we may really need more than one format to balance speed vs size ** [WAM: learns that libfdt does not unflatten. U-boot copies Linux code for this.] ** RH: we could have a libdt that would be lib for live trees * SG: for speed it would be nice to have a directory for quick access ** WAM: improved alias? SG: Yes if they were phandles perhaps * WAM: Can we revist size, that is pretty broad ** Eliminate as many strings as possible ** FR: Compiler does "tail recursion" on strings already ** WAM: strings in properties are not in symbold table today ** SG: Yes I studied that and elimination of that did not help a lot. ** SG: Today everything is 32 bit *** I looked at reducing and could save 20% *** But it is not as regular *** WAM: is it aligned today? *** RH: Yes, 64 bit aligned but not very clear in spec ** HS: Just gzip the DTB if you just want to reduce storage size ** WAM: Published ATOM based DTB doc a few years ago. *** Try to move most strings to 32 bit ATOM constants (not offsets) *** Optionally include ATOM table to include the strings Devicetree Atom Table Format: https://docs.google.com/document/d/19XbxN-zX-GYwOXdF78lGnp0j7UNx1MT3wzyCjai… Frank reminds us that we want to collect all the stake holders: * Linux * DTC * U-Boot * BSDs ** One has its own DTC * RTOS ** Zephyr (mostly DTS) *** Have their own DTS parser, DOM lib, and code gen *** Want to make it more generic ** Vxworks (does use runtime DT of some sort) All agree: Old DTB format will need to be supported for a good while after new DTB format is defined. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 3 months

DT Evo call today March 8 at 4pm UK/UTC 11AM US East

by Bill Mills

Hello, We have our DTE call today. I don't have anything on the agenda unless we want to brainstorm on the DTB format changes. I know Frank is trying to collect/organize past work on this. Is it worth while talking today or should we wait for Frank? Open to any other agenda items. Join Zoom Meeting https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Meeting ID: 961 7042 8801 Passcode: 8250 ------ A note on timezones. This meeting is now anchored to the UK timezone to match the EBBR call. UK goes to Daylight savings on March 28 Most of the USA goes to Daylight savings on March 14. This means: UK: no visible change in time slot. USA (most): Meeting on 22nd will be one hour later. (and EBBR meeting on 15th) Non-daylight savings time zones: DTE and EBBR meetings are 1 hour earlier from March 28 to Oct 31. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 3 months

EFI_LOAD_FILE2 for initrd standardization

by Ilias Apalodimas

Hi, An arch agnostic way was recently added on the kernel, as an alternative method to load an initrd [1]. The kernel call to the firmware ends up calling the protocol with a Device Path End Structure, so the firmware must know which initrd to load on the buffer the kernel provides. The protocol is currently implemented by U-boot and EDK2, which both define a way of specifying the initrd to load. We could use this protocol, in order to provide vertical distros a way of loading (kernel, initrd) pairs without GRUB. In that case we need a common way for firmware implementations to define and manage the initrd. User space applications that control the boot flow (e.g efibootmgr), should also be able to change the variable accordingly. Looking at the EFI spec and specifically § 3.1.3 Load Options, we can use the FilePathList[] of the EFI_LOAD_OPTION, which is described as: "A packed array of UEFI device paths. The first element of the array is a device path that describes the device and location of the Image for this load option. The FilePathList[0] is specific to the device type. Other device paths may optionally exist in the FilePathList, but their usage is OSV specific. Each element in the array is variable length, and ends at the device path end structure. Because the size of Description is arbitrary, this data structure is not guaranteed to be aligned on a natural boundary. This data structure may have to be copied to an aligned natural boundary before it is used." So FilePatrhList[1-n] are available for OS usage. There are 3 ways we could implement that. All 3 ways would allow us to specify multiple initrds (and we could extend the same logic to DTBs, but that's a different discussion). They all re-use the same idea, prepend a VenMedia DP, which has a GUID. We can then use that GUID to identify the filetype and behavior of the device paths. 1. Prepend a VenMedia Device Path in every initrd Device Path. In that case FilePathList[] would look like this: Loaded Image device path - end node - VenMedia - Initrd DP - end node - VenMedia - Initrd DP - end node - repeat 2. Prepend a VenMedia Device Path once. In that case FilePathList[] would look like this: Loaded Image device path - end node - VenMedia - Initrd DP - end instance - (repeat) - Initrd DP - end node - other DPs In this case we could use the VenMedia Vendor Defined Data to indicate the number of device paths that follow, although it's redundant, since each instance would terminate on the Device Path End Structure. 3. Use Vendor Defined Data of the VenMedia device path and copy the initrd device path(s) in there. In that case the Vendor Defined Data will it self be in a device path format with all the initrds we want. Loaded Image device path - end node - VenMedia - end node - other DPs Any preference on these? Is one of them closer to the EFI spec, so we could go ahead and try to standardize some of the GUIDs of the VenMedia? [1] https://lkml.org/lkml/2020/2/16/105 Regards /Ilias

4 years, 4 months

*cancelled* EBBR Biweekly for 1 March 2021

by Grant Likely

Hi all, I'll be doing a presentation and round table about SystemReady IR at Embedded World on 1 March, but unfortunately it overlaps entirely our EBBR biweekly so I'm going to cancel that day. If you're interested in attending the round table, please email me privately. The session apparently limited to a small number of people (which seems odd for a virtual conference), so I'm sending out invites. The session is scheduled for 15:50-16:50 GMT on 1 March 2021. Cheers, g. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

4 years, 4 months

DTE Call today (Feb 22) at 11am US ET, 4PM UTC

by Bill Mills

All, We have the DTE call in ~ 1 hour (if my message is not delayed). Frank Rowand has agreed to talk about his TODO/backlog plans. We can probably entertain other agenda items after that. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

4 years, 4 months

[EBBR PATCH 0/3] Updates for v2.0

by Grant Likely

Hi all, Here are the updates I've prepared for v2.0 of EBBR which I'd like to tag for review sometime in the next few weeks. Please take a look and yell if you have any concerns. g. [EBBR PATCH 1/3] Override UEFI section 2.6 requirements [EBBR PATCH 2/3] Refine RTC requirements [EBBR PATCH 3/3] Require EFI_UPDATE_CAPSULE

4 years, 4 months

[PATCH 1/1] Fix build warnings:

by Heinrich Schuchardt

Building target html results in warnings: WARNING: html_static_path entry '_static' does not exist ebbr/source/index.rst:53: WARNING: toctree contains reference to document 'references' that doesn't have a title: no link will be generated * remove reference to path _static * add title to references Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- source/conf.py | 2 +- source/references.rst | 3 +++ 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/source/conf.py b/source/conf.py index 86f7b88..4a2566a 100644 --- a/source/conf.py +++ b/source/conf.py @@ -100,7 +100,7 @@ html_theme = 'alabaster' # Add any paths that contain custom static files (such as style sheets) here, # relative to this directory. They are copied after the builtin static files, # so a file named "default.css" will overwrite the builtin "default.css". -html_static_path = ['_static'] +# html_static_path = ['_static'] # -- Options for HTMLHelp output ------------------------------------------ diff --git a/source/references.rst b/source/references.rst index 1eb0509..c94d1d1 100644 --- a/source/references.rst +++ b/source/references.rst @@ -1,5 +1,8 @@ .. SPDX-License-Identifier: CC-BY-SA-4.0 +References +========== + .. [ACPI] `Advanced Configuration and Power Interface specification v6.2A <http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf>`_, September 2017, `UEFI Forum <http://www.uefi.org>`_ -- 2.30.0

4 years, 4 months

[PATCH 1/1] UEFI section 2.6 exceptions for boot services

by Heinrich Schuchardt

Describes deviations for ConnectController() and LoadImage(). Signed-off-by: Heinrich Schuchardt <xypron.glpk(a)gmx.de> --- source/chapter2-uefi.rst | 11 +++++++++++ 1 file changed, 11 insertions(+) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 49aec46..660eb27 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -112,6 +112,17 @@ interface specific UEFI protocols, and so they have been made optional. * - Element - Description of deviation + * - `LoadImage()` + - The LoadImage() boot service is not required to install an + EFI_HII_PACKAGE_LIST_PROTOCOL for an image containing a custom PE/COFF + resource with the type 'HII'. - HII resource images are not needed to run + the UEFI shell or the SCT. + * - `ConnectController()` + - The ConnectController()` boot service is not required to support the + EFI_PLATFORM_DRIVER_OVERRIDE_PROTOCOL, + EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL, and + EFI_BUS_SPECIFIC_DRIVER_OVERRIDE_PROTOCOL. - These override protocols are + only useful if drivers are loaded as EFI binaries by the firmware. * - `EFI_HII_CONFIG_ACCESS_PROTOCOL` - UEFI requires this for console devices, but it is rarely necessary in practice. Therefore this protocol is not required. -- 2.30.0

4 years, 4 months

[PATCH] Override UEFI section 2.6 requirements

by Grant Likely

EBBR only requires a subset of UEFI. Provide a replacement for the UEFI section that lists base requirements. Fixes: #60 Fixes: #61 Fixes: #64 --- This is my first complete draft itemizing the specific UEFI requirements for EBBR. Please review and comment. Cheers, g. source/chapter2-uefi.rst | 155 ++++++++++++++++++++++++++++++++++++++- 1 file changed, 152 insertions(+), 3 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index aab1c2c..5864a17 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -14,8 +14,157 @@ This document uses version 2.8 Errata A of the UEFI specification [UEFI]_. UEFI Compliance =============== -EBBR compliant platforms shall conform to the requirements in [UEFI]_ § 2.6, -except where explicit exemptions are provided by this document. +EBBR compliant platform shall conform to a subset of the [UEFI]_ spec as listed +in this section. +Normally, UEFI compliance would require full compliance with all items listed +in section 2.6 of the UEFI spec. +However, the EBBR target market has a reduced set of requirements, +and so some UEFI features are omitted as unnecessary. + +Required Elements +----------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.1. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Requirement + * - `EFI_SYSTEM_TABLE` + - The system table is required to provide required to access UEFI Boot Services, + UEFI Runtime Services, consoles, and other firmware, vendor and platform + information. + * - `EFI_BOOT_SERVICES` + - All functions defined as boot services must exist. + Methods for unsupported or unimplemented behavour must return an appropriate error code. + * - `EFI_RUNTIME_SERVICES` + - All functions defined as runtime services must exist. + Methods for unsupported or unimplemented behavour must return an appropriate error code. + * - `EFI_LOADED_IMAGE_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_LOADED_IMAGE_DEVICE_PATH_PROTOCOL` + - Must be installed for each loaded image + * - `EFI_DEVICE_PATH_PROTOCOL` + - Interface to provide location of a device + * - `EFI_DEVICE_PATH_UTILITIES_PROTOCOL` + - Interface for creating and manipulating UEFI device paths + +.. list-table:: Notible Omissions from UEFI section 2.6.1 + :header-rows: 1 + + * - Element + - Note + * - EFI_DECOMPRESS_PROTOCOL + - Native EFI Decompression is rarely used and therefore not required. + +Required Platform Specific Elements +----------------------------------- + +This section replaces the list of required elements in [UEFI]_ § 2.6.2. +All of the following UEFI elements are required for EBBR compliance. + +.. list-table:: UEFI Platform-Specific Required Elements + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description + * - Console devices + - The platform must have at least one console device + * - `EFI_SIMPLE_TEXT_INPUT_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_INPUT_EX_PROTOCOL` + - Needed for console input + * - `EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL` + - Needed for console output + * - `EFI_DEVICE_PATH_TO_TEXT_PROTOCOL` + - Needed for console output + * - `EFI_HII_STRING_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_HII_DATABASE_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_UNICODE_COLLATION2_PROTOCOL` + - Required by EFI shell and for compliance testing + * - `EFI_BLOCK_IO_PROTOCOL` + - Required for block device access + * - `EFI_SIMPLE_FILE_SYSTEM_PROTOCOL` + - Required if booting from block device is supported + * - `EFI_RNG_PROTOCOL` + - Required if platform has a hardware entropy source + * - Network booting + - If the platform supports network booting via TFTP, + then `EFI_SIMPLE_NETWORK_PROTOCOL` and + `EFI_PXE_BASE_CODE_PROTOCOL` must be implemented. + +The following table is a list of notable deviations from UEFI section 2.6.2. +Many of these deviations are because the EBBR use cases do not require +interface specific UEFI protocols, and so they have been made optional. + +.. list-table:: Notible Deviations from UEFI section 2.6.2 + :widths: 50 50 + :header-rows: 1 + + * - Element + - Description of deviation + * - `EFI_HII_CONFIG_ACCESS_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not requried. + * - `EFI_HII_CONFIG_ROUTING_PROTOCOL` + - UEFI requires this for console devices, but it is rarely necessary in practice. + Therefore this protocol is not requried. + * - Graphical console + - Platforms with a graphical device are not required to expose it as a graphical console. + * - EFI_DISK_IO_PROTOCOL + - Rarely used interface that isn't requried for EBBR use cases + * - Network protocols + - A full implementation of the UEFI general purpose networking ABIs is not required, + including `EFI_NETWORK_INTERFACE_IDENTIFIER_PROTOCOL`, `EFI_MANAGED_NETWORK_PROTOCOL`, + `EFI_*_SERVICE_BINDING_PROTOCOL`, or any of the IPv4 or IPv6 protocols. + * - Byte stream device support (UART) + - UEFI protocols not required + * - PCI bus support + - UEFI protocols not required + * - USB bus support + - UEFI protocols not required + * - NVMe pass through support + - UEFI protocols not required + * - SCSI pass through support + - UEFI protocols not required + * - SCSI pass through support + - UEFI protocols not required + * - `EFI_DRIVER_FAMILY_OVERRIDE_PROTOCOL` + - Not required + * - Option ROM support + - EBBR implementations are not required to support option ROM loading + +Required Global Variables +------------------------- + +EBBR compliant platforms are required to implement the following Global +Variables as found in [UEFI]_ § 3.3. + +.. list-table:: Required UEFI Variables + :widths: 25 75 + :header-rows: 1 + + * - Variable Name + - Description + * - `Boot####` + - A boot load option. #### is a numerical hex value + * - `BootCurrent` + - The boot option that was selected for the current boot + * - `BootNext` + - The boot option that will be used for the next boot only + * - `BootOrder` + - An ordered list of boot options. + Firmware will attempt each Boot#### entry in this order + * - `OsIndications` + - Method for OS to request features from firmware + * - `OsIndicationsSupported` + - Variable for firmware to indicate which features can be enabled Block device partitioning ------------------------- @@ -148,7 +297,7 @@ are required to be implemented during boot services and runtime services. .. table:: EFI_RUNTIME_SERVICES Implementation Requirements ============================== ============= ================ - EFI_RUNTIME_SERVICES function Boot Services Runtime Services + EFI_RUNTIME_SERVICES function Before EBS() After EBS() ============================== ============= ================ EFI_GET_TIME Optional Optional EFI_SET_TIME Optional Optional -- 2.20.1

4 years, 4 months

← Newer
1
...
19
20
21
22
23
24
25
...
65
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture