boot-architecture

boot-architecture@lists.linaro.org

1 participants
684 discussions

by Jon Humphreys

Hi all. I've organized some of my requests for clarification below. I appreciate you helping me understand the spec. Where the spec needs clarification itself, I'll create a ticket to track. Basic (dumb) questions: ----------------------- - why is EBBR dictating the location of firmwares? The firmware locations are a contract with the boot ROM and subsequent stages, leading up to the OSloader. The OSloader hand-off interface is the real EBBR contract with an OS provider, I would think. My answer to this question had been that in order for the OS to update firmware, the firmware locations need to be standardized. But I've since learned that the firmware update mechanism should be abstracted via update capsules. So I am back to not understanding why the firmware locations aren't just a convention local to the board vendor. Firmware locations: ------------------- - the EBBR states that a dedicated partition is preferred for storing firmware. This seems to imply that all firmwares will be in a single location. This isn't true in many cases (eg, some partitions aren't large enough and subsequent stages are loaded from a different partition). Is there guidance (or should be guidance) in EBBR on how to handle these scenarios? - does the EBBR discourage placing firmware in the ESP, and if so, under what circumstances is it recommended (eg, trying to boot a stock OS image). See https://github.com/ARM-software/ebbr/issues/113 Device Tree: ------------ - The EBBR requires a device tree file (or ACPI table). It makes complete theoretical sense that the board firmware should supply the DTB, since it is (in theory) a description of the hardware, which obviously doesn't change. But the unfortunate reality is that the device tree is always changing to stay in sync with the kernel. My experience is that OS images ship with a corresponding device tree. But the device tree location is one example where the EBBR does not specify a convention. How can the EBBR handle this reality so that we can standardize where an OS vendor can place its version of the DTB? ESP --- - who is responsible for providing the ESP, the board firmware or the OS provider? The goal of SystemReady is to separate the software packaging between board firmware and OS images, so that we eliminate the need for OS vendors to produce board specific images. The current practice in embedded is to deliver a monolithic, self-contained image, and in this scenario, standards don't matter as much as it is all self-contained. As I try to image what embedded looks like where boards ship with firmware installed and OS providers only provide the OS image, I'm running into these questions like who provides the ESP, where is the DTB located, etc. thanks Jon

2 years, 6 months

[DT] Chosen node documentation

by ff

Hi, As I am working on Automotive Virtual Platform Speficition in the context of SOAFEE and there is a reference to « chosen » standardization in the document, I am verifying all external links. The file https://elixir.bootlin.com/linux/v5.19.17/source/Documentation/devicetree/b… has disappeared from the Doc tree since 6.0 There are no references to kaslr-seed, stdout-path or linux,usable-memory-range in the whole DT, including in the current 6.6 tree. There is a brief mention (probably not normative) of « chosen » is usage_model.rst but that’s all. Does anyone knows if that is intentional? Cheers FF

2 years, 6 months

Clarification on firmware location on removable storage

by Jon Humphreys

Hi all. I need clarification on where firmware should be located when booting from removable shared storage. Statements in the intro of 4.2 seem to contradict later statements in 4.2.2 of the EBBR [1]. Section 4.2.2 states that to make it easier to use stock OS images on removable storage, firmware should be located on the ESP partition (so you don't have to create a dedicated firmware partition). > On removable media, firmware should be stored in the ESP under the > /FIRMWARE directory structure as described in Firmware Partition > Filesystem. However, prior in the 4.2 section, it states: > The sections below discuss the requirements when using both fixed and > removable storage. However, it should be noted that the recommended > behaviour of firmware should be identical regardless of storage type. > In both cases, the recommended boot sequence is to first search for > firmware in a dedicated firmware partition, and second search for > firmware in the ESP. Why would the boot sequence for shared storage look in two places if it is always in the ESP? Or does the statement in 4.2.2 only apply in the case of using a stock OS image? As a side question, I'm not sure of the practicality of recommending a boot sequence that looks in two places, at least for the very first firmware stages, as ROM usually is very simple and only looks in a single location. thanks Jon [1] https://arm-software.github.io/ebbr/

2 years, 7 months

EBBR call today Sep 25

by Vincent Stehle

Hi, We will have an EBBR call[1] today, Sep 25, at 15h BST (14h UTC). On the agenda[2] we have a number of pull requests to review: - #[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich) - #[107]: Arm sections changes (was support Armv8-R AArch64) - #[108]: Add smbios tables details (should we even require SMBIOS?) - #[109]: Add an extension for UEFI (and now DTSPEC) references - #[110]: Bump ACPI and PSCI versions Also, a discussion topic: - Secure boot with systemd-boot requires EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[3] for the meeting notes. Best regards, Vincent Stehlé System Architect - Arm [1]: https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3]: https://mensuel.framapad.org/p/ebbr-call-of-sep-25-a3fj [106]: https://github.com/ARM-software/ebbr/pull/106 [107]: https://github.com/ARM-software/ebbr/pull/107 [108]: https://github.com/ARM-software/ebbr/pull/108 [109]: https://github.com/ARM-software/ebbr/pull/109 [110]: https://github.com/ARM-software/ebbr/pull/110

2 years, 8 months

EBBR call today Sep 11

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Sep 11, at 15h BST (14h UTC). On the agenda[2] we have a number of pull requests to review: - #[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich) - #[107]: Support Armv8-R AArch64 - #[108]: Add smbios tables details - #[109]: Add an extension for UEFI references Also some discussions topics have been proposed: - Secure boot with systemd-boot requires EFI_SECURITY_ARCH_PROTOCOL and EFI_SECURITY2_ARCH_PROTOCOL (Heinrich) - Info: upcoming BBR ECR #634 forbidding some SMCs after ExitBootServices - "Platform firmware must not implement any SMC calls from the SMCCC Vendor Specific EL3 Monitor range (FIDs 0x8700_0000—0x8700_FFFF and 0xC700_0000—0xC700_FFFF) after ExitBootServices." (info from Jose) - Should we specify which Devicetree nodes are allowed? (suggested by Sughosh) Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[3] for the meeting notes. Best regards, Vincent Stehlé System Architect - Arm [1]: https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3]: https://mensuel.framapad.org/p/ebbr-call-of-sep-11-a368 [106]: https://github.com/ARM-software/ebbr/pull/106 [107]: https://github.com/ARM-software/ebbr/pull/107 [108]: https://github.com/ARM-software/ebbr/pull/108 [109]: https://github.com/ARM-software/ebbr/pull/109

2 years, 8 months

Reminder: next EBBR call Sep 11

by Vincent Stehlé

Hi, This is a kind reminder that we will have our next EBBR call on Sep 11. Feel free to add to the agenda, directly on the wiki page[1] or by e-mail. I hope everybody had a nice summer break. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

2 years, 9 months

EBBR call today Jun 5

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Jun 5, at 15h UTC/BST. On the agenda[2] we have a pull request to review: - Pull request #[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich) We could also go through the opened issues[3] if time permits. Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[4] for the meeting notes. Best regards, Vincent Stehlé System Architect - Arm [1]: https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3]: https://github.com/ARM-software/ebbr/issues [4]: https://mensuel.framapad.org/p/ebbr-call-of-jun-5-a1cv [106]: https://github.com/ARM-software/ebbr/pull/106

2 years, 11 months

EBBR call today May 22

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, May 22, at 15h UTC/BST. On the agenda[2] we have two pull requests to review: - Pull request #[105]: Recommend the firmware update protocol - Pull request #[106]: Recommend usage of partition type GUIDs to find firmware (Heinrich) We could also go through the opened issues[3] if time permits. Feel free to add to the agenda, directly on the wiki page or by e-mail. We can use this pad[4] for the meeting notes. Best regards, Vincent Stehlé System Architect - Arm [1]: https://armltd.zoom.us/j/92081365511?pwd=SFZpRitXUEp3Zy9GM0h3UUZ1b1pnUT09 [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [3]: https://github.com/ARM-software/ebbr/issues [4]: https://mensuel.framapad.org/p/ebbr-call-of-22-may-a13j [105]: https://github.com/ARM-software/ebbr/pull/105 [106]: https://github.com/ARM-software/ebbr/pull/106

3 years

[RFC] Proposed location to host the firmware handoff specification.

by Jose Marinho

Hi, Arm worked to draft a firmware handoff [1] specification, evolving it based on community feedback. This activity followed the request of some members of the Arm ecosystem [2]. The spec (still at ALP – feedback/comments welcome!) standardizes how information is propagated between different firmware components during boot. The spec hopes to remove the reliance on bespoke/platform-specific information handoff mechanisms, thus reducing the code maintenance burden. The concept of entry types is present in the spec – these are data structure layouts that carry a specific type of data. New types are meant to be added, following the needs and use-cases of the different communities. Thus, these communities should be empowered to request new types! To enable community contributions, the specification must be hosted in a location that is friendly to change requests. We propose to host the spec in trustedfirmware.org (tf.org). Tf.org hosts several open-source projects and already has an open governance model. TF-A, and the associated community, rely on tf.org, and thus are already well equipped to maintain this specification and keep it up to date. Tf.org is agnostic of any downstream projects that would adopt this specification (e.g. U-boot, EDK2, etc.). We welcome the views of the communities and want to understand if there are any strong objections to what’s being proposed! If anyone has objections, we are happy to consider alternatives and associated trade-offs. Regards [1] https://developer.arm.com/documentation/den0135/latest [2] Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages - TF-A - lists.trustedfirmware.org<https://lists.trustedfirmware.org/archives/list/tf-a@lists.trustedfirmware.…>

3 years

Re: Recommendation for identifying partition with firmware to be loaded from SD-card

by Heinrich Schuchardt

On 5/4/23 13:39, Michal Simek wrote: > > > On 5/1/23 16:26, Heinrich Schuchardt wrote: >> Linux distributions are interested in providing a single image which >> enables a high number of boards to boot. This is simple if the boot >> firmware (EDK II or U-Boot) is installed on flash. >> >> For boards that expect to load a boot loader like U-Boot from an SD-card >> it is necessary that the firmware locations for different boards >> on the SD-card don't collide. >> >> When loading from SD-card or eMMC the sector at which the binary >> starts has to be identified. The following has been implemented: >> >> - start from hard coded sector number >> - load file from FAT file system >> - load from given partition number >> - load from partition with boot flag set (MBR partioning only) >> - load from partition with specific type GUID >> >> Loading by partition type GUID seems the most appropriate to avoid >> collisions between the firmware for different boards. >> >> Often firmware is separated into multiple parts due to firmware >> restrictions, e.g. U-Boot SPL and main U-Boot (e.g. as .itb file). >> >> Here the same considerations apply. Using a partition type GUID to >> identify further firmware parts to be loaded is best suited to >> avoid collisions. >> >> I would suggest to add a recommendation to the EBBR specification >> to use SoC specific partition type GUIDs to identify firmware to >> be loaded from SD-card. >> >> Please, provide your feedback. > > Isn't this very similar to effort which Andre presented at Fosdem 2019? > > https://archive.fosdem.org/2019/schedule/event/one_image_to_rule_them_all/a… > > Thanks, > Michal Thanks Michal for the pointer. We are talking about the same topic. The question that was not resolved up to now is how we can avoid conflicts between the U-Boot binaries of different SoCs stored on the same medium. This is where I propose to use GUID partition types. Best regards Heinrich

3 years

← Newer
1
...
8
9
10
11
12
13
14
...
69
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture