- boot-architecture - lists.linaro.org

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, 6 months

1
0
0 0

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, 7 months

3
2
0 0

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, 7 months

1
0
0 0

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, 10 months

1
0
0 0

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

2 years, 10 months

1
0
0 0

[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.…>

2 years, 11 months

7
23
0 0

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

2 years, 11 months

1
0
0 0

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

by Heinrich Schuchardt

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. Best regards Heinrich

2 years, 11 months

3
3
0 0

Re: [RISC-V][tech-os-a-see] Recommendation for identifying partition with firmware to be loaded from SD-card

by Heinrich Schuchardt

On 5/1/23 16:31, Aaron Durbin wrote: > Hi, > > On Mon, May 1, 2023 at 8:26 AM Heinrich Schuchardt > <heinrich.schuchardt(a)canonical.com > <mailto:heinrich.schuchardt@canonical.com>> 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. > > > Who is loading the firmware that is identified by a GUID? And how does > that tie into Linux distros? I don't see anything wrong w/ the > recommendation, but I didn't completely follow which piece of software > is loading firmware and how the GUID reduces the problems. Also, is this > "SoC specific partition type GUID" unique per SoC? Or is it expected to > be a global GUID? Booting firmware starts at boot ROM which may either directly load a piece of software from SD-card or may load a piece of software from flash which in turn will load the next step boot loader from the SD-card. From the view of a distro it is best if each board uses a separate GUID. This allows to add multiple U-Boot versions (or other boot software) on the same SD-card. Best regards Heinrich

2 years, 11 months

1
0
0 0

EBBR call today Apr 24

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Apr 24, at 15h UTC/BST. On the agenda[2] we have one pull request review continuation: - Pull request #[105]: Recommend the firmware update protocol We could also go through the opened issues[3] if willing. 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-apr-24-a0kw?lang=en [105]: https://github.com/ARM-software/ebbr/pull/105

2 years, 11 months

1
0
0 0

No EBBR call next Monday, Apr 10

by Vincent Stehlé

Hi, Next Monday, Apr 10, is Easter Monday and is a bank holiday in some countries. Let us therefore cancel the corresponding EBBR call, please. The next EBBR call will be held on Apr 24. Feel free to add to the agenda, directly on the wiki page[1] or by e-mail. Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

3 years

1
0
0 0

EBBR call today Mar 27

by Vincent Stehlé

Hi, We will have an EBBR call[1] today, Mar 27, at 15h UTC/BST. On the agenda[2] we have pull requests[3] reviews continuations: - Pull request #102: File Format For Storing EFI Variables (Heinrich) - Pull request #104: Make monotonic counter optional (was: Relax monotonic counter nonvolatility) - Pull request #105: Recommend the firmware update protocol 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/pulls [4]: https://mensuel.framapad.org/p/ebbr-call-of-mar-27-a027

3 years

1
0
0 0

EBBR call today Mar 13

by Vincent Stehlé

Hi, We will have an EBBR call[1] today at 15h UTC/BST. On the agenda for today[2] we have pull requests[3] reviews: - Pull request #102: File Format For Storing EFI Variables (Heinrich) - Pull request #104: Relax monotonic counter nonvolatility - Pull request #105: Recommend the firmware update protocol 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/pulls [4]: https://mensuel.framapad.org/p/ebbr-call-of-mar-13-9zsw

3 years, 1 month

1
0
0 0

No DT call today or going forward

by Bill Mills

All, There will be no DT call today. In fact, I am going to cancel the series. Since Feb 1, Mondays don't work for me anymore. I have discussed this inside of Linaro and we don't feel a periodic DT call is needed at this time. I am keeping a copy of the invite list in case we want to schedule special meetings on specific topics. If you feel we need this call and wish to host it, please contact me on this list or directly. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 1 month

1
0
0 0

EBBR call today Feb 27

by Vincent Stehlé

Hi, We will have an EBBR call[1] today at 15h UTC/BST. On the agenda[2]: - Review the pull requests[3]: + Pull request #102: File Format For Storing EFI Variables (Heinrich) + Pull request #103: Require capsule update "on disk" and corresponding variables 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/pulls [4]: https://mensuel.framapad.org/p/ebbr-call-of-feb-27-9zjk

3 years, 1 month

1
0
0 0

No DT call on Feb 20

by Bill Mills

All, Monday Feb 20 is a US holiday. We won't have a meeting. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 1 month

1
0
0 0

EBBR call today Feb 13

by Vincent Stehlé

Hi, We will have an EBBR call[1] today at 15h UTC/BST. On the agenda[2] today: - SetVariable() at runtime for boards that store EFI variables on an RPMB 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-feb-13-9za9?lang=en

3 years, 2 months

1
0
0 0

Re: [PATCH] schemas: Add schema for firmware logs

by Rob Herring

+boot-architecture On Mon, Feb 6, 2023 at 3:25 PM Simon Glass <sjg(a)chromium.org> wrote: > > Hi Rob, > > On Mon, 6 Feb 2023 at 10:15, Rob Herring <robh(a)kernel.org> wrote: > > > > On Sat, Feb 4, 2023 at 6:04 AM Simon Glass <sjg(a)chromium.org> wrote: > > > > > > Hi Peter, > > > > > > On Sat, 4 Feb 2023 at 02:36, Peter Robinson <pbrobinson(a)gmail.com> wrote: > > > > > > > > Hi Simon, > > > > > > > > Does it make sense to devise something that is compatible with the > > > > kernel's pstore [1] mechanism? > > > > > > Possibly...can you please be a little more specific? > > > > Peter is talking about the same thing I suggested on IRC. > > > > pstore == ramoops > > Oh, I only looked at the DT binding as I thought that was what you > were talking about on irc. The binding is called ramoops as it's for the RAM backend for pstore. My suggestion was either using/extending ramoops or following its design as a reserved memory region. All you would need to extend the ramoops binding is a new property to define the size of your data. > For pstore, isn't the point that Linux wants to save stuff to allow > debugging or collection on reboot? What does that have to do with > console logs from firmware? That seems like a different thing. Or are > you suggesting that we add a pstore driver into U-Boot? It is quite a > lot of code, including compression, etc. It might be easier for Linux > to write the data into pstore when it starts up? Originally ramoops was just what you described. It has grown to multiple backends and types of records (hence the rename to pstore). If you just add a new subsection within the pstore region, then I think the existing kernel infrastructure will support reading it from userspace. Maybe new types have to be explicitly supported, IDK. U-boot being able to read pstore wouldn't be a terrible feature to have anyways if your boot crashes before anything else is up to get the output. Note I'd guess the ram backend doesn't do compression as supporting slightly corrupted ram is a feature which wouldn't work. I think any new DT binding is premature and pstore/ramoops was just a suggestion to consider. This needs wider consideration of how to handle all the various (boot) firmware logs. I've added the boot-architecture list for a bit more visibility. Rob

3 years, 2 months

4
8
0 0

Firmware handoff status

by ff

Hi Anyone knows what is the status of standardizing firmware handoff (when starting BL33) ? Here is a reference to the topic: https://github.com/FirmwareHandoff/firmware_handoff I would be interested in both standard text and standard implementation in TFA. The context is portability of type-1 hypervisors that need to be fully in control of security and thus execute BL33 in an ad hoc "VM". The rationale is to isolate everything that deals with devices or IO (at its core, a hypervisor deals only with CPU, RAM, MMU, SMMU, GIC). Cheers FF PS: To explore how easy it is to boot a hypervisor with either booti, bootefi or BL33 I published a Rust tool (barekit) that can do precisely that (and much more as it can be used to create BL32 or even a Rust based FF-A implementation): https://www.linkedin.com/posts/fozog_github-fozogbarekit-rust-base-code-to-… https://github.com/fozog/barekit

3 years, 2 months

3
4
0 0

No DT call today

by Bill Mills

All, I have not received any ideas for agenda for today. I will cancel this meeting. A heads up: Meetings on Monday no longer fit for me. We will need to make some change going forward. I will talk thing over with others and get back to the list. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 2 months

1
0
0 0

No EBBR call today Jan 30

by Vincent Stehlé

Hi, We do not have an agenda[2] for the EBBR call today Jan 30 therefore let us cancel this call. Next EBBR call will be on Feb 13; feel free to propose topics on the wiki or by e-mail. Best regards, Vincent Stehlé System Architect - Arm [2]: https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

3 years, 2 months

2
1
0 0

No DT call today

by Bill Mills

All, We do not have a topic for today so I will cancel today's meeting. If you have a suggestion for the Feb 6 meeting please reply to this email. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 2 months

1
0
0 0

EBBR call today Jan 16

by Vincent Stehlé

Hi, Happy new year! We will have an EBBR call[1] today at 15h UTC/BST (sorry for the short notice). On the agenda[2] today: - Issues[3] scrub - Continue the discussion on Minimum Viable Product (MVP) 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-jan-16-9yro?lang=en

3 years, 2 months

1
0
0 0

No DT meeting Monday Dec 12

by Bill Mills

All, Sorry but I have a conflict for Monday's meeting so I am going to cancel. Thanks, Bill -- Bill Mills Principal Technical Consultant, Linaro +1-240-643-0836 TZ: US Eastern Work Schedule: Tues/Wed/Thur

3 years, 4 months

1
0
0 0

EBBR call today

by Vincent Stehlé

Hi, I hope everybody is doing well. We will have an EBBR call[1] today at 15h UTC/BST. Also, there will be no call on Dec 19. If practicable for everyone, the meeting after the one today shall be next year on Jan 2 2023 (let's confirm during the call today). On the agenda[2] today: - Preparing for version 2.1.0 - Issues[3] scrub - Continue the discussion on Minimum Viable Product (MVP) - Confirm Jan 2 meeting 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-notes-20221205-9xzm?lang=en

3 years, 4 months

6
8
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture