boot-architecture February 2021

boot-architecture@lists.linaro.org

17 participants
12 discussions

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

3 years, 9 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.

3 years, 10 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

3 years, 10 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

3 years, 10 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

3 years, 10 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

3 years, 10 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

3 years, 10 months

EBBR Biweekly for Monday 01 Feb 2021

by Grant Likely

Hi all, Next EBBR biweekly is on Monday at 16:00 GMT. Dial-in details are below. Below is the agenda I have so far. I've carried over the items that we did not have time to discuss last week. Agenda: - Initrd passing - Revised UEFI requirements (patch on mailing list) - UpdateCapsule() - other business Please email if you want to add anything to the agenda Cheers, g. ---- Topic: EBBR Biweekly Time: 1 Feb 2021, 16:00-17:00 GMT Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Passcode: 490324 One tap mobile +14086380968,,92081365511#,,,,*490324# US (San Jose) +16465189805,,92081365511#,,,,*490324# US (New York) Dial by your location +1 408 638 0968 US (San Jose) +1 646 518 9805 US (New York) +1 346 248 7799 US (Houston) Meeting ID: 920 8136 5511 Passcode: 490324 Find your local number: https://armltd.zoom.us/u/aelJgr9ZAW 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.

3 years, 10 months

Re: Ideas for DT improvements

by Zhangpeng (Parker, Kirin)

Hi Bill, Improve search algorithm performance: We will need data to show the problem. I suppose this would best be done when unflatening the data at runtime? What is the expected gain in boot time? Are there any measurements of how much time is spent in the search routines today? Actually, It is nessary to search and modify device tree in boot loader, and the device tree has not be unflatened. We need to search device tree node int dtb by libfdt, however libfdt algorithm is pretty horrible, eg:fdt_node_offset_by_compatible. It takes about 10ms on average to search for a node. I suppose the dtb structure and libfdt algorithm can be optimized to reduce boot time? The time for searching for a node should be less than 1 ms. Reduce DTB space: What is the goal of the use case? 1) Fit in limited storage ( ex: 256MB ) 2) Conserve more space of modest storage for container data ( 1GB eMMC) 3) Improve boot time For 3, the load time will be reduced but the decompression time will be added. These need to be balanced based on the CPU. One pet peeve I have in most of our boot loaders today is that they do loading and decompression serially. During loading the IO is 100% loaded and the CPU is very lightly loaded. During decomoression the CPU is 100% loaded and the IO is 0%. It makes sense to pipleline / overlap these things which means that it needs to go into the loader. To optimize boot time the decompression algorithm needs to be chosen correctly. On smaller CPUs the time taken to decompress newer algorithms can greatly outweigh the time taken to load the decompressed data. Ideally the time to decompress 1 block == time to load one block. The dynamics shift with CPU and IO performance. Today, a lot of people focused on boot speed just use decompressed data but I think we could do better if we pipeline Since one dtbo image contains of hundreds of dtbs, the iamge is too large. The goal of reducing dtb space is to fit in limited storage without increasing boot time. Pipleline / overlap loading and decompression is a good idea. We can try to overlap them in boot loader, and discuss it further if there's a problem. Define specific rule for properties: This is harder.In 2019 I had proposed an ATOM based DTB enhancement [2]. I was told Frank Rowand had other proposals for format changes. OK.I am very interested in the ATOM based DTB enhancement. I will learn about it and other format changes, then make some detailed discussions with you. Thanks very much, Bill. Happy Chinese New Year Regards, Zhangpeng 发件人: Jammy Zhou [mailto:jammy.zhou@linaro.org] 发送时间: 2021年2月9日 16:45 收件人: Xiamingliang (XML, Hisilicon) <xiamingliang(a)huawei.com> 抄送: Bill Mills <bill.mills(a)linaro.org>; boot-architecture(a)lists.linaro.org; Frank Rowand <frowand.list(a)gmail.com>; Zhangpeng (Parker, Kirin) <zhangpeng55(a)huawei.com>; Wangjun (U) <wangjundrv.wang(a)huawei.com> 主题: Re: Ideas for DT improvements Hi Bill, Thanks very much for your comments. Since we're close to the Chinese New Year holiday, I would assume there will be some delay for the response by Zhangpeng. Regards, Jammy On Sun, 7 Feb 2021 at 09:35, Xiamingliang (XML, Hisilicon) <xiamingliang(a)huawei.com<mailto:xiamingliang@huawei.com>> wrote: + zhangpeng, owner of DT in Hisilicon -----Original Message----- From: Bill Mills [mailto:bill.mills@linaro.org<mailto:bill.mills@linaro.org>] Sent: 2021年2月7日 1:39 To: Jammy Zhou <jammy.zhou(a)linaro.org<mailto:jammy.zhou@linaro.org>>; boot-architecture(a)lists.linaro.org<mailto:boot-architecture@lists.linaro.org>; Frank Rowand <frowand.list(a)gmail.com<mailto:frowand.list@gmail.com>> Cc: Xiamingliang (XML, Hisilicon) <xiamingliang(a)huawei.com<mailto:xiamingliang@huawei.com>> Subject: Re: Ideas for DT improvements Hi Jammy & Mingliang, On 2/5/21 2:59 AM, Jammy Zhou wrote: > Hi, > > There are several ideas for DT improvements. Please check if they are > reasonable, and any comments are welcome. I would let Mingliang (CCed) > share more details if needed. > > 1) Improve search algorithm performance: Is the binary search tree or > other algorithm better than current algorithm? > We will need data to show the problem. I suppose this would best be done when unflatening the data at runtime? What is the expected gain in boot time? Are there any measurements of how much time is spent in the search routines today? > 2) Reduce DTB space: when use one DTB to support multiple boards, the > image is quite big (e.g, ~39MB space for 100 configurations), and some > compression algorithm can reduce the space a lot (e.g, from 39MB to 7MB). > Shall we have such compression support for DTB? And it can be helpful > if we can have more efficient compression algorithm. > This could be done as an enhancement to the DTB loader instead of the DTB format itself. Compressing each DTB (boardx.dtb.xz) will get you gains but compressing a set of boards (vmlinux-5.4.0-65-generic-dbt-set-20.tar.xz) might give you more. To be significant, the number of boards would need to be large and the size of the rootfs would need to be modest. A 200 to 300 MB minimal image would make an interesting comparison point. (A rootfs of 10s of MB would probably only target a few boards.) What is the goal of the use case? 1) Fit in limited storage ( ex: 256MB ) 2) Conserve more space of modest storage for container data ( 1GB eMMC) 3) Improve boot time For 3, the load time will be reduced but the decompression time will be added. These need to be balanced based on the CPU. One pet peeve I have in most of our boot loaders today is that they do loading and decompression serially. During loading the IO is 100% loaded and the CPU is very lightly loaded. During decomoression the CPU is 100% loaded and the IO is 0%. It makes sense to pipleline / overlap these things which means that it needs to go into the loader. To optimize boot time the decompression algorithm needs to be chosen correctly. On smaller CPUs the time taken to decompress newer algorithms can greatly outweigh the time taken to load the decompressed data. Ideally the time to decompress 1 block == time to load one block. The dynamics shift with CPU and IO performance. Today, a lot of people focused on boot speed just use decompressed data but I think we could do better if we pipeline > 3) Define specific rule for properties: The property value > (FDT_PROP_DATA) itself occupies only ~50% of the total DTB space. And > the property of each node is different and the private property name > length is too long, for > example: “freq-autodown-baseaddress-num” in dt_strings. It seems more > reasonable that the property value should occupies more than 70% of > the total DTB space. It can probably be achieved to define some rules > to restrict the length of property name, etc. > This is harder. In 2019 I had proposed an ATOM based DTB enhancement [2]. I was told Frank Rowand had other proposals for format changes. Thanks, Bill [2] https://docs.google.com/document/d/19XbxN-zX-GYwOXdF78lGnp0j7UNx1MT3wzyCjai… > Thanks, > Jammy > _______________________________________________ > boot-architecture mailing list > boot-architecture(a)lists.linaro.org<mailto:boot-architecture@lists.linaro.org> > https://lists.linaro.org/mailman/listinfo/boot-architecture > -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 10 months

Ideas for DT improvements

by Jammy Zhou

Hi, There are several ideas for DT improvements. Please check if they are reasonable, and any comments are welcome. I would let Mingliang (CCed) share more details if needed. 1) Improve search algorithm performance: Is the binary search tree or other algorithm better than current algorithm? 2) Reduce DTB space: when use one DTB to support multiple boards, the image is quite big (e.g, ~39MB space for 100 configurations), and some compression algorithm can reduce the space a lot (e.g, from 39MB to 7MB). Shall we have such compression support for DTB? And it can be helpful if we can have more efficient compression algorithm. 3) Define specific rule for properties: The property value (FDT_PROP_DATA) itself occupies only ~50% of the total DTB space. And the property of each node is different and the private property name length is too long, for example: “freq-autodown-baseaddress-num” in dt_strings. It seems more reasonable that the property value should occupies more than 70% of the total DTB space. It can probably be achieved to define some rules to restrict the length of property name, etc. Thanks, Jammy

3 years, 10 months

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture February 2021