- boot-architecture - lists.linaro.org

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

5 years, 1 month

1
1
0 0

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

5 years, 2 months

2
1
0 0

[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

5 years, 2 months

5
13
0 0

[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

5 years, 2 months

1
0
0 0

[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

5 years, 2 months

2
1
0 0

[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

5 years, 2 months

7
17
0 0

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.

5 years, 2 months

1
2
0 0

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

5 years, 2 months

1
0
0 0

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

5 years, 2 months

3
3
0 0

Devicetree Evo Call Monday Jan 25 and every two weeks thereafter

by Bill Mills

All, I hope we have finally settled on a standing meeting time for the DT Evo call. We will have the call every other Monday alternating with EBBR in the same time slot. If I have done the TZ math correctly this is 16:00 UTC, and 11 AM US Eastern, 8AM US Pacific. I have sent a google calendar invite to all those listed on the previous call. If you would like to be added to that please email me directly at bill.mills(a)linaro.org Topic: Devicetree Evolution Time: Jan 25, 2021 11:00 AM Eastern Time (US and Canada) Every 2 weeks on Mon (Alternates with EBBR meeting in same time slot) Join Zoom Meeting https://linaro-org.zoom.us/j/96170428801?pwd=elBJNFdVMFJub0UzanFUcVQxTHBqdz… Meeting ID: 961 7042 8801 Passcode: 8250 One tap mobile +13017158592,,96170428801# US (Washington D.C) +16465588656,,96170428801# US (New York) Dial by your location +1 301 715 8592 US (Washington D.C) 888 788 0099 US Toll-free 877 853 5247 US Toll-free +44 203 481 5237 United Kingdom 0 800 031 5717 United Kingdom Toll-free Meeting ID: 961 7042 8801 Find your local number: https://linaro-org.zoom.us/u/acQEZ30MEP -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years, 2 months

2
2
0 0

[EBBR RFC] Refine RTC requirements

by Grant Likely

If the platform has an RTC, then EFI_GET_TIME and EFI_SET_TIME are required before ExitBootServices(). Clarify this in the spec. Also specify that EFI_{GET,SET}_WAKEUP_TIME are required before ExitBootService() if the RTC can wakeup the platform. Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- Reading through the RTC text it didn't seem clear to me. How's this for a clarification? g. source/chapter2-uefi.rst | 15 +++++++++------ 1 file changed, 9 insertions(+), 6 deletions(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 9906fd9..ab22932 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -159,16 +159,16 @@ are required to be implemented during boot services and runtime services. - Before ExitBootServices() - After ExitBootServices() * - `EFI_GET_TIME` - - Optional + - Required if RTC present - Optional * - `EFI_SET_TIME` - - Optional + - Required if RTC present - Optional * - `EFI_GET_WAKEUP_TIME` - - Optional + - Required if wakeup supported - Optional * - `EFI_SET_WAKEUP_TIME` - - Optional + - Required if wakeup supported - Optional * - `EFI_SET_VIRTUAL_ADDRESS_MAP` - N/A @@ -227,8 +227,11 @@ it may not be possible to access the RTC from runtime services. e.g., The RTC may be on a shared I2C bus which runtime services cannot access because it will conflict with the OS. -If firmware does not support access to the RTC, then GetTime() and -SetTime() shall return EFI_UNSUPPORTED, +If an RTC is present, then GetTime() and SetTime() must be supported +before ExitBootServices() is called. + +However, if firmware does not support access to the RTC after +ExitBootServices(), then GetTime() and SetTime() shall return EFI_UNSUPPORTED and the OS must use a device driver to control the RTC. UEFI Reset and Shutdown -- 2.20.1

5 years, 2 months

1
0
0 0

DT based PSA description of hardware partition

by François Ozog

Hi I assume this needs to be analyzed from System Device Tree perspective: https://trustedfirmware-a.readthedocs.io/en/latest/components/psa-ffa-manif… And this is to be included in the DT Technical Report. Cheers FF -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 3 months

4
6
0 0

EBBR Biweekly (Postponed to 14th Dec)

by Grant Likely

Hi everyone. I have to do this, but I have another unexpected conflict for the EBBR biweekly on the 14th. Rather than cancelling outright, does anyone else want to chair the meeting? The major planned orientatio item on the agenda was to talk about EBBR testing, with Heinrich sharing what he is currently doing. If I don't hear anything by about 1pm GMT tomorrow then I'll just cancel. Our next meeting will be in January as I believe most of us will already be on Christmas holiday on the 21st g. Get Outlook for Android<https://aka.ms/ghei36> 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.

5 years, 3 months

6
13
0 0

[EBBR PATCH] Require EFI_UPDATE_CAPSULE

by Grant Likely

EFI_UPDATE_CAPSULE is the industry standard method for applying firmware updates. Make it a requirement in EBBR so that fwupd, Windows Update, and any other generic firmware update service can support EBBR platforms. This is made required because the ability to update firmware is a critical part of building secure platforms. Fixes: #69 Signed-off-by: Grant Likely <grant.likely(a)arm.com> --- source/chapter2-uefi.rst | 32 +++++++++++++++++++++++++++++++- 1 file changed, 31 insertions(+), 1 deletion(-) diff --git a/source/chapter2-uefi.rst b/source/chapter2-uefi.rst index 7b5eb24..b1182a8 100644 --- a/source/chapter2-uefi.rst +++ b/source/chapter2-uefi.rst @@ -167,7 +167,10 @@ are required to be implemented during boot services and runtime services. EFI_SET_VARIABLE Required Optional EFI_GET_NEXT_HIGH_MONO_COUNT N/A Optional EFI_RESET_SYSTEM Required Optional - EFI_UPDATE_CAPSULE Optional Optional + EFI_UPDATE_CAPSULE Required Optional + for in-band + firmware + update EFI_QUERY_CAPSULE_CAPABILITIES Optional Optional EFI_QUERY_VARIABLE_INFO Optional Optional ============================== ============= ================ @@ -243,6 +246,25 @@ Even when SetVariable() is not supported during runtime services, firmware should cache variable names and values in EfiRuntimeServicesData memory so that GetVariable() and GetNextVeriableName() can behave as specified. +Firmware Update +--------------- + +Being able to update firmware to address security issues is a key feature of secure platforms. +EBBR platforms are required to implement either an in-band or an out-of-band firmware update mechanism. + +If firmware update is performed in-band (firmware on the application processor updates itself), +then the firmware shall implement EFI_UPDATE_CAPSULE and accept updates in the +"Firmware Management Protocol Data Capsule Structure" format as described in [UEFI]_ § 23.3, +"Delivering Capsules Containing Updates to Firmware Management Protocol. [#FMPNote]_ +Firmware is also required to provide an EFI System Resource Table (ESRT). [UEFI]_ § 23.4 +Every firmware image that is updated in-band must be described in the ESRT. + +If firmware update is performed out-of-band (e.g., by an independent Board Management Controller, +or firmware is provided by a hypervisor), then the platform is not required to implement EFI_UPDATE_CAPSULE. + +EFI_UPDATE_CAPSULE is only required before ExitBootServices() is called. + + .. [#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 @@ -253,3 +275,11 @@ that GetVariable() and GetNextVeriableName() can behave as specified. during runtime services. https://optee.readthedocs.io/en/latest/architecture/secure_storage.html + +.. [#FMPNote] The `EFI_UPDATE_CAPSULE` implementation is expected to be suitable + for use by generic firmware update services like fwupd and Windows Update. + Both fwupd and Windows Update read the ESRT table to determine what firmware + can be updated, and use an EFI helper application to call `EFI_UPDATE_CAPSULE` + before ExitBootServices() is called. + + https://fwupd.org/ -- 2.20.1 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.

5 years, 3 months

1
0
0 0

Specifying the boot flow

by Simon Glass

Hi, I thought perhaps it might be worth starting a thread on this, as despite Grant and Heinrich kinding spending a bit of time talking about this, I am still very much in the dark about how 'embedded' and distro/other boot flows are going to come together with EBBR. Of course this would be easier f2f. Case 1: Firmware loads the kernel to a particular address, selects DT and boots it. The kernel may require EFI boot services, or may not, but in the general case the firmware provides them. Case 2: Firmware loads EFI app and provides EFI boot services to it. How the system actually boots is under control of the app. I feel that a lot of the confusion about verified boot, DT selections, boot menus, etc. is coming from the introduction of an EFI app which has no specification (it can be grub, shim or something else, as I understand it). Certainly this is very flexible and future-proof, but it is also arbitrarily complex, unpredictable and hard to secure. I am wondering if we can come up with a way to deterministically specify how a system will boot and how to make it boot a different way (i.e. with a different kernel, initrd, DT). Heinrich mentioned EFI variables as a way of selecting kernel/initrd/DT. Then the problem becomes just a case of being able to change those variables from Linux userspace. Is that right? We are talking about having a 'secure' part of EBBR, which allows for secure boot. Should we have a 'defined boot' part of EBBR, that defines how the kernel/DT/initrd are selected, based on EFI variables? Unfortunately I just don't know enough about all the different boot flows used by the different distros. It seems like crazy town. Does anyone have some pointers so I can do some study? Regards, SImon

5 years, 3 months

7
20
0 0

Devicetree state of U-Boot vs kernel

by Bill Mills

All, On the Devicetree evolution call Wednesday I promised to finish my comparison of u-boot DT vs kernel DT. The script is not perfect but the results are still interesting. For each dts and dtsi file in the tip of the u-boot tree, it tries to correlate it to the kernel tip. It compares git SHA1 signatures or falls back to filenames. The results were surprising to me but perhaps they should not have been. I have checked in the script[1] and the full results here [2] The full file lists (with some diff stats) are in the root dir. Example [3] I also looked at the line count of the u-boot override files. Even though we don't expect these to correlate, we do expect reasonable usage to result in small files. Big files are an indication of possible abuse of the system. (I don't think the idea was to have wholesale new versions of the DTS as an override.) I plan to redo the script in python. It will be much easier to be more precise and to look deeper. (For example figure out how old the u-boot version is in number of change sets and number of days. Or if no content sync now were they ever synced?) Here is the scripts output: (from summary.txt) Devicetree sync status for u-boot v2021.01-rc5-7-gb8c725e736 Compared to kernel v5.11-rc2-156-g71c061d24438 14% (255) are completely synced 253 arm 2 riscv 0 mips 0 powerpc 0 x86 0 68k 0 microblaze 0 sh 0 arc 23% (416) content has appeared in the kernel but is not up to date 411 arm 0 riscv 1 mips 0 powerpc 1 x86 0 68k 0 microblaze 0 sh 1 arc 33% (584) filename appears in kernel but content never has 467 arm 1 riscv 12 mips 91 powerpc 0 x86 0 68k 0 microblaze 0 sh 8 arc 28% (510) neither filename nor content appears in kernel 305 arm 4 riscv 48 mips 35 powerpc 44 x86 0 68k 1 microblaze 1 sh 6 arc n/a (510) U-Boot specific, no correlation expected 7 sandbox 358 override 211 test histogram of override size (in raw lines) 10 61 20 53 30 38 40 33 50 23 60 14 70 12 80 7 90 5 100 4 110 4 120 5 130 6 140 4 150 0 160 2 170 0 180 0 190 4 200 0 210 2 220 2 230 1 240 2 250 1 260 1 270 1 280 0 290 0 300 0 310 0 320 1 [1] https://github.com/wmamills/devicetree-source/blob/master/scripts/correlate… [2] https://github.com/wmamills/devicetree-source [3] https://github.com/wmamills/devicetree-source/blob/master/dts-somewhere.txt -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years, 3 months

2
1
0 0

DeviceTree Evolution call tomorrow Jan 6

by Bill Mills

Hello, Thanks to all that have participated in the doodle poll. We don't yet have all key stakeholders so please add your info if you have not. As expected there is no perfect time but the current leader is Wednesdays at 4PM UK, 11 AM US Eastern. I have scheduled a meeting for tomorrow as this first one. Possible topics for tomorrow include: * More Conformance testing of DT source * Keeping multiple DT projects in sync (w/o moving the DT source) * DT overlay source in the kernel source tree (for bootloader applied overlays) If we stay with Wednesdays the meeting after this one would be Jan 27. (Wednesdays require working around Linaro TSC calls) Thanks, Bill *** Bill Mills is inviting you to a scheduled Zoom meeting. Topic: DT Evolution Time: Jan 6, 2021 04:00 PM London Join Zoom Meeting https://linaro-org.zoom.us/j/94413146152?pwd=NEs1Ym1xbnRBS0U4ZWNsaXFzbm1Ndz… Meeting ID: 944 1314 6152 Passcode: 8250 One tap mobile +13017158592,,94413146152# US (Washington D.C) +13126266799,,94413146152# US (Chicago) Dial by your location +1 301 715 8592 US (Washington D.C) +1 312 626 6799 US (Chicago) +1 646 558 8656 US (New York) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) 877 853 5247 US Toll-free 888 788 0099 US Toll-free Meeting ID: 944 1314 6152 Find your local number: https://linaro-org.zoom.us/u/aesZr3aPDG -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years, 3 months

1
0
0 0

DT conformance and "reg" tuples

by François Ozog

Hi, As I am thinking about conformance testing for SystemReady and Trusted Substrate, I'd like to get your feedback on the following. There are 7 values in the reg entry of interrupt-controller@210000 from the below DT. This corresponds to 3 valid {address,size} plus a single {address}. The spec does not state anything on incomplete {address,size} pairs... I understand that #size-cell can be zero, indicating that the reg will contain only {address} "tuples" and not {address,size} tuples. But that should be for all reg tuples, not just one. In this case, I assume the driver will get what it wants, but from a certification perspective: - I would reject this DT. - I would document proper tuple forming in the spec (no incomplete pairs) Last, I would also add some "notes" in the spec about where to get the "#*-cells" for the reg property of a device. If you think "hardware" it is obvious that the information must be retrieved from the immediate parent and "inheritance" does not make sense. But as I Googled the topic, I have seen a number of discussions and wrong patches around that. So I would add a non normative text (properly identified as such) to describe that in the spec. Thank you for your help Cheers FF config-space@f0000000 { #address-cells = <0x01>; #size-cells = <0x01>; compatible = "simple-bus"; ranges = <0x00 0x00 0xf0000000 0x1000000>; interrupt-controller@210000 { compatible = "arm,gic-400"; #interrupt-cells = <0x03>; #address-cells = <0x01>; #size-cells = <0x01>; ranges; interrupt-controller; interrupts = <0x01 0x09 0xf04>; reg = <0x210000 0x10000 0x220000 0x20000 0x240000 0 0x20000>; phandle = <0x01>; v2m@280000 { compatible = "arm,gic-v2m-frame"; msi-controller; reg = <0x280000 0x1000>; arm,msi-base-spi = <0xa0>; arm,msi-num-spis = <0x20>; phandle = <0x03>; }; -- François-Frédéric Ozog | *Director Linaro Edge & Fog Computing Group* T: +33.67221.6485 francois.ozog(a)linaro.org | Skype: ffozog

5 years, 3 months

2
1
0 0

Devicetree Evolution conference call time, al poll

by Bill Mills

All who participate or wish to participate in the DTE call, Please fill in this pool before you go out for the holidays: https://doodle.com/poll/fup2swsb9yi2u5u4?utm_source=poll&utm_medium=link The current meeting time does not work well for people on the west coast of North America as it is 6am Pacific time. I have selected the following times: 7 am PT, 15:00 UTC 8 am PT, 16:00 UTC 9 am PT, 17:00 UTC I have found options for Monday, Wednesday, Thursday, and Friday. Tuesday does not work at all for me at any reasonable time for the EU. All meeting times will repeat every two weeks except for the Wednesday 7am & 8am slots. These will normally be the 2nd and 4th Wednesdays of the month but in January will be the 6th and 27th. (This is to avoid the Linaro TSC calls that a good number us participate in.) If you want me to insert new times into the poll please respond to this message. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years, 4 months

1
0
0 0

DTE: UEFI protocol for device-tree fix-ups

by Heinrich Schuchardt

Dear all, we have discussed that a protocol is needed to fix-up device trees loaded by GRUB or other boot managers. In the U-Boot code we have actually the following actions for device-trees: * load the device-tree to memory * copy the device-tree to an allocated memory region which has 12 KiB free space for device-tree fix-ups * do the actual fix-ups, i.e. add new nodes or change properties * reserve memory according to the /reserved-memory node and the memory reservation block as EfiBootServicesData or as EfiReservedMemoryType for no-map regions * install the device-tree as configuration table So I think the usage of a DT fix-up protocol could take the following steps: * GRUB loads the device-tree allocating sufficient memory for fix-ups * GRUB calls the protocol a fist time to add extra nodes and properties * GRUB applies its own device-tree fix-ups * GRUB calls the protocol a second time which - reserves memory according to the /reserved-memory node - installs the device-tree as configuration table One could join both service calls if GRUB applies its own fix-ups first. But maybe GRUB wants to analyze U-Boot's fix-ups before committing its own ones. So lets define a bit-field to pass to the fix-up protocol: /* Add nodes and update properties */ #define EFI_DT_APPLY_FIXUPS 0x00000001 /* * Reserve memory according to the /reserved-memory node * and the memory reservation block */ #define EFI_DT_RESERVE_MEMORY 0x00000002 /* Install the device-tree as configuration table */ #define EFI_DT_INSTALL_TABLE 0x00000004 Here is the rest of the proposed protocol definition: #define EFI_DT_FIXUP_PROTOCOL_GUID \ { 0xe617d64c, 0xfe08, 0x46da, \ { 0xf4, 0xdc, 0xbb, 0xd5, 0x87, 0x0c, 0x73, 0x00 } } typedef struct _EFI_DT_FIXUP_PROTOCOL { EFI_DT_FIXUP fixup; } EFI_DT_FIXUP_PROTOCOL; typedef EFI_STATUS (EFIAPI *EFI_DT_FIXUP) ( IN EFI_DT_FIXUP_PROTOCOL *This, IN VOID *Fdt, IN OUT UINTN *BufferSize, IN UINT32 Flags, ); This: Pointer to the protocol Fdt: Buffer with the device-tree. This shall be memory of type EfiACPIReclaimMemory if Flags contains EFI_DT_INSTALL_TABLE. BufferSize: Pointer to the size of the buffer including trailing unused bytes for fix-ups. If the buffer size is too small, the required buffer size is returned. Flags: Bitmap containing at least one of the values EFI_DT_APPLY_FIXUPS, EFI_DT_RESERVE_MEMORY, EFI_DT_INSTALL_TABLE. Indicates the actions to be applied to the device-tree. The selected actions indicated in Flags are applied in the sequence: * Add nodes and update properties. * Reserve memory according to the /reserved-memory node and the memory reservation block * Install the device-tree as configuration table Memory is reserved as EfiBootServicesData if the reservation does not carry the no-map property and as EfiReservedMemoryType if it is marked as no-map. If *BufferSize exceeds the value of the totalsize field header of device-tree header upon entry to the service, the totalsize field is set to *BufferSize. Return values: EFI_INVALID_PARAMETER - This is NULL or does not point to a valid EFI_DT_FIXUP_PROTOCOL implementation. EFI_INVALID_PARAMETER - Fdt or BufferSize is NULL EFI_INVALID_PARAMETER - *Fdt is not a valid device-tree (e.g. incorrect value of magic) EFI_INVALID_PARAMETER - Invalid value of Flags (zero or unknown bit) EFI_BUFFER_TOO_SMALL - The buffer is too small to apply the fix-ups. EFI_SUCCESS - All steps succeeded If EFI_BUFFER_TOO_SMALL is returned, the device-tree is unmodified and *BufferSize is updated with the required buffer size for the provided device-tree. The required buffer size when called with EFI_DT_APPLY_FIXUPS should enforce at least 4 KiB unused space for additional fix-ups by the operating system or the caller. The available space in the device-tree shall be determined using the device-tree header fields: Available = header->totalsize - header->off_dt_strings - header->size_dt_strings; (The strings block is always last in the flattened device-tree. There might be more space between blocks but not all device-tree libraries can use it.) The required buffer size when called without EFI_DT_APPLY_FIXUPS shall be the value of the totalsize field of the flattened device tree header. If any other error code is returned, the state of the device-tree is undefined. The caller should discard the buffer content. The extent to which the validity of the device-tree is checked is implementation dependent. But a buffer without the correct value of the magic field of the flattened device tree header should always be rejected. The protocol implementation is not required to check if the device-tree is in memory of type EfiACPIReclaimMemory. Looking forward to your feedback. Best regards Heinrich

5 years, 4 months

1
1
0 0

DT Evolution call for Dev 9th

by Bill Mills

All, Sorry for the late notice. We will have our normal DTE call at 2PM GMT today. My suggested topic for today is the open items in the DTB ABI slides here: https://docs.google.com/presentation/d/1Hq7-42EfM4xC_1N1HMO20vXVKSpkA_S-Los… This will be the last call for 2020. My suggestion for the DTE calls after this is to start in January with either: Option 1: 2nd & 4th Wednesday @ 4 PM GMT / 11 AM US Eastern Option 2: Alternate weeks with the EBBR call, Mondays at 4 PM GMT Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years, 4 months

1
0
0 0

EBBR: RISC-V handoff to OS

by Heinrich Schuchardt

Hello Atish, the UEFI spec has this sentence: "When UEFI firmware handoff control to OS, the RISC-V is operated in machine-mode privilege." (M-mode is the equivalent to EL3 in ARM). This does not make any sense to me when using a secure execution environement (SEE) like OpenSBI. The hand-off should occur in S-Mode if the CPU supports it and only in M-Mode when the CPU only supports M-mode. We should prescribe this in the EBBR and somehow get the UEFI spec fixed afterwards. An other issue is the calling convention. Chapter "2.3.7.3 Detailed Calling Convention" does not describe which registers are saved by the UEFI payload's entry point and restored by the payload before calling the UEFI API or returning to the UEFI payload. This concerns especially registers gp (x3) and tp (x4). Into the EBBR or UEFI spec we should put a link to the "RISC-V ELF psABI specification" https://github.com/riscv/riscv-elf-psabi-doc/blob/master/riscv-elf.md which is referenced by "The RISC-V Instruction Set Manual". >From the "RISC-V ELF psABI specification" one might conclude that the UEFI payload should not be allowed to change gp and tp before calling ExitBootServices() or SetVirtualAddressMap() whichever occurs last. Due to this missing clarification U-Boot is currently saving gp before calling the entry point of the payload and restores it on reentry or on entry of an API call. Nothing is done for tp. Best regards Heinrich

5 years, 4 months

4
30
0 0

EBBR Biweekly (Postponed to 14th Dec)

by Grant Likely

I have a conflict this week and need to cancel. I propose pushing out to next week (Dec 14th), and cancelling the meeting on the 21st when many people will be on holiday anyway. Let me know if you want anything added to the meeting agenda before next week. Draft agenda: * Action item review * EBBR Testing Efforts (SCT, FWTS, etc) * UEFI Exception text changes * Next release schedule * Other business Time: This is a recurring meeting Meet anytime Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Password: 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 Password: 490324 Find your local number: https://armltd.zoom.us/u/adYiWaDyys 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.

5 years, 4 months

3
6
0 0

EBBR Biweekly today

by Grant Likely

Hi all, Here is the draft agenda for the EBBR biweekly today. As always, let me know if there is anything you want to add. Notes will be taken in Etherpad[1]. Draft agenda: - Issue & PR review - Draft EBBR text for tailoring UEFI section 2.6 base requirements[2] - Roundtable - Any other business [1] https://etherpad.opendev.org/p/EBBR [2] https://github.com/ARM-software/ebbr/wiki/Required-EFI-protocols --- Monday 23 November 16:00 GMT Join Zoom Meeting https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 Meeting ID: 920 8136 5511 Password: 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 Password: 490324 Find your local number: https://armltd.zoom.us/u/adYiWaDyys 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.

5 years, 5 months

1
1
0 0

DT Evolution calls for November 4 and 18

by Bill Mills

All, We had a DTE call last week that was poorly attended. We decided to try again this week. Nov 11 would be our next normal call but it is a holiday for many of us so Francois will cancel it. Here I am suggesting we also meet on Nov 18. so to recap: Nov 4: YES Nov 11: NO Nov 18: YES On one of these calls we will figure out what we want to do going forward for meeting time. (Go back to old schedule, Keep new schedule, alternate weeks with EBBR in the same slot) For anyone that wants a real calendar invite, you can import the link below. Topic: DT Evolution (special case for Nov) Time: Nov 4, 2020 02:00 PM London Every 2 weeks on Wed, 2 occurrence(s) Nov 4, 2020 02:00 PM Nov 18, 2020 02:00 PM Please download and import the following iCalendar (.ics) files to your calendar system. Weekly: https://linaro-org.zoom.us/meeting/tJwkc-2qrzgrHtVXvrcFXQ6fHonAqq_w1BZo/ics… Join Zoom Meeting https://linaro-org.zoom.us/j/98944213141?pwd=Ukg0T0hsTGp6OXFFMEpUZGZGVEUrdz… Meeting ID: 989 4421 3141 Passcode: 8250 One tap mobile +13017158592,,98944213141# US (Germantown) +16465588656,,98944213141# US (New York) Dial by your location +1 301 715 8592 US (Germantown) +1 646 558 8656 US (New York) +1 312 626 6799 US (Chicago) +1 669 900 9128 US (San Jose) +1 253 215 8782 US (Tacoma) +1 346 248 7799 US (Houston) 888 788 0099 US Toll-free 877 853 5247 US Toll-free Meeting ID: 989 4421 3141 Find your local number: https://linaro-org.zoom.us/u/abpCUvVWcd Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

5 years, 5 months

1
1
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture