boot-architecture

boot-architecture@lists.linaro.org

1 participants
646 discussions

Moving the EBBR call slot to Wednesdays, 14:00 UTC/BST

by Vincent Stehlé

Dear EBBR stakeholders, Thank you for completing the second poll [1]. We have looked at the results during our call of yesterday [2]. While there is no ideal slot allowing all people to attend, the Wednesday slots seem to allow more participants. We have thus decided to move the EBBR call to Wednesday, 14:00 UTC (following BST). Our next call will be on Oct. 23; see you there! Best regards, -- Vincent Stehlé System Architect - Arm [1] https://framadate.org/Wwf2GCiOsQywWfTg [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.10.07

9 months, 1 week

EBBR call today, Oct 7

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Oct 7 at 14h30 BST (13h30 UTC; BST is active). We have two topics on the agenda[2]: - Discussion around Boot Manager (see #132, "Boot Manager requirements"). - Poll results and choosing a new schedule for the EBBR call (see second poll) 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-oct-7-aafj?lang=en #132 https://github.com/ARM-software/ebbr/pull/132

9 months, 1 week

Second poll to find an even better schedule for the EBBR call

by Vincent Stehlé

Dear EBBR stakeholders, Thank you for having completed the poll, to try to find an even better schedule for our EBBR call. It appears that people have available slots on the afternoon of Monday, Wednesday and Friday. Here is a second (and hopefully last) poll, with 1/2 hour granularity: https://framadate.org/Wwf2GCiOsQywWfTg Could you please add your availabilities in there? Thank you! Best regards, Vincent Stehlé System Architect - Arm

9 months, 3 weeks

No EBBR call today, Sep 23?

by Vincent Stehlé

Hi, We have nothing on today's EBBR call's agenda [1]; we might as well cancel it. If you have an urgent topic to discuss today, please let us know before 1pm BST (12pm UTC), otherwise we will adjourn the call. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

9 months, 3 weeks

EBBR call today Sep 9

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Sep 9 at 15h30 BST (14h30 UTC; BST is active). We have only one pull requests on the agenda[2], therefore it might be a short call: - #132: Boot Manager requirements 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-9-a9wv?lang=en [132] https://github.com/ARM-software/ebbr/pull/132

10 months, 1 week

EBBR next call and poll

by Vincent Stehlé

Dear EBBR stakeholders, I hope you all had a nice summer break. Our next EBBR call is approaching as it will take place next Monday, Aug 26 at 14h30 BST (13h30 UTC; BST is active). In the mean time, I would like to remind you that we have a poll[1] on-going, to try to find an even better schedule for our EBBR call. Thank you to those who added their availabilities already; for those of you, who have not yet completed this first poll, could you please do so? At the time of writing, we have a couple of pull requests on the agenda[2]: - #131: Update UEFI version to 2.10 A - #132: Boot Manager requirements This an attempt at fixing issue #130: Explicitly require boot manager, from Heinrich Please have a look, and feel free to add to the agenda, directly on the wiki page or by e-mail. Best regards, Vincent Stehlé System Architect - Arm [1] https://framadate.org/6jm8P3jHqAzmv8Xo [2] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings [130] https://github.com/ARM-software/ebbr/issues/130 [131] https://github.com/ARM-software/ebbr/pull/131 [132] https://github.com/ARM-software/ebbr/pull/132

10 months, 3 weeks

Re: Re: Re: Firmware Partition Filesystem query

by Ghennadi Procopciuc

>> Could this section be updated in order to reduce the number of different >> interpretations? > > Yes, it can be clarified. As Daniel says, this section is only > intended for platforms where there is no other place to store > firmware. If the OS and the firmware need to share a logical block > device, and there is no way to protect the firmware bits, then this > section describes how they can co-exist. e.g., you don't want an OS > deployment to accidentally wipe out firmware. > > It is preferred and encouraged to have firmware contained entirely in > something separate from the main block storage. For example, in eMMC > boot areas (separate from the primary area), or on a separate device > entirely (SPI flash). I predict that a future version of EBBR will > require this and drop the shared storage option entirely because it is > necessary to protect against attacks against firmware (replacement or > deletion) > > g. > Thank you all contributing to this thread! While most of the points in this thread are self-explanatory and should not need a summary, I want to extract the main points to avoid misinterpretations: 1. Chapters '4.1 Partitioning of Shared Storage' and '4.2 Firmware Partition Filesystem' refer to cases when shared storage is used for OS and firmware images. In this case, the block device needs to be partitioned using GPT and the firmware binaries should be stored in a FAT partition. The folder organization for this partition is described in the '4.2.1 The firmware directory hierarchy' chapter. Ideally, the BootROM should be able to load images from a FAT partition. However, a feature release of the EBBR is likely to drop this option in the future. 2. For scenarios involving dedicated storage, the organization of the underlying storage for firmware falls outside the scope of the EBBR and can be arranged according to the SoC vendor's discretion. This can include options such as offset addressing, without GPT, with MRB, with or without a partition, based on the platform's requirements or limitations. Could you please confirm that this understanding is correct? > If I recall correctly, on the Arm platform, A-BL1 (BootROM) and A-BL2 > are responsible only for > loading the images. SCP_BL2 is loaded by BL2 into trusted SRAM and then > transferred to the SCP using the MHU protocol and I believe it is > followed this > way for other platforms also (?). > In summary, A-BL1(BootROM) and A-BL2 need to be aware of their next > stages to load those > images properly: > BootROM -> BL2 -> BL31 -> ... > | > v > SCP If the above summary points are valid, then in the case of a shared device, the BL2 should be able to load the next image(s) (either FIP or BL31) from a FAT partition, I suppose. Regards, Ghennadi

11 months, 3 weeks

Firmware Partition Filesystem query

by Ghennadi Procopciuc

Greetings everyone, I came across the following paragraph while reading the 'Firmware Partition Filesystem' chapter from EBBR v2.2.0 and I would like to clarify my understanding: Where possible, firmware images and data should be stored in a filesystem. Firmware can be stored either in a dedicated firmware partition, or in certain circumstances in the UEFI System Partition (ESP). Using a filesystem makes it simpler to manage multiple firmware files and makes it possible for a single disk image to contain firmware for multiple platforms. Dedicated firmware partitions should be formatted with a FAT filesystem as defined in UEFI § 13.3 File System Format. Dedicated firmware partitions should use the same /FIRMWARE directory hierarchy. OS tools shall ignore dedicated firmware partitions, and shall not attempt to use a dedicated firmware partition as an ESP Questions: 1. Does the above paragraph mean that, if the device allows, all firmware binaries (TF-A, U-Boot, and some others) must be stored in a dedicated firmware partition formatted with a FAT filesystem and GUID Partition Table (GPT) disk layout? 2. If so, would this also mean that, where possible, the BootROM or a (first stage) bootloader running before TF-A should have GPT and FAT support embedded support to load one of the TF-A stages (BL1/BL2)? Regards, Ghennadi

11 months, 3 weeks

No EBBR call today?

by Vincent Stehlé

Hi, We have nothing on today's EBBR call's agenda [1]; I would thus be inclined to cancel it. If you have an urgent topic to discuss today, please let us know before 1pm UTC, otherwise we will adjourn the call. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

12 months

Moving the EBBR call 1/2h earlier?

by Vincent Stehlé

Hi, The question of moving the EBBR call 1/2 hour earlier was raised during our last call [1]. Some people have colliding meetings now and it would make their lives easier. Also, this seemed practical for all the people present. Could all the EBBR attendees please tick their available hours on the following poll? https://framadate.org/FWI2Ff4Tmyz9yOfR Thank you in advance! If possible we will move the EBBR call to 14:30 UTC/BST starting with our next call on Jul 15. Best regards, Vincent Stehlé System Architect - Arm [1] https://github.com/ARM-software/ebbr/wiki/EBBR-Notes-2024.07.01

1 year

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture