- boot-architecture - lists.linaro.org

Re: [PATCH v2 0/2] DMI: Scan for DMI table from DTS info

by Ard Biesheuvel

(cc Ilias) On Thu, 23 Oct 2025 at 15:34, Adriana Nicolae <adriana(a)arista.com> wrote: > > On Thu, Oct 23, 2025 at 11:21 AM Ard Biesheuvel <ardb(a)kernel.org> wrote: > > > > On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae <adriana(a)arista.com> wrote: > > > > > > On Wed, Oct 22, 2025 at 11:19 PM Rob Herring <robh(a)kernel.org> wrote: > > > > > > > > On Wed, Oct 22, 2025 at 04:45:25AM -0700, adriana wrote: > > > > > Some bootloaders like U-boot, particularly for the ARM architecture, > > > > > provide SMBIOS/DMI tables at a specific memory address. However, these > > > > > systems often do not boot using a full UEFI environment, which means the > > > > > kernel's standard EFI DMI scanner cannot find these tables. > > > > > > > > I thought u-boot is a pretty complete UEFI implementation now. If > > > > there's standard way for UEFI to provide this, then that's what we > > > > should be using. I know supporting this has been discussed in context of > > > > EBBR spec, but no one involved in that has been CC'ed here. > > > > > > Regarding the use of UEFI, the non UEFI boot is used on Broadcom iProc which > > > boots initially into a Hardware Security Module which validates U-boot and then > > > loads it. This specific path does not utilize U-Boot's UEFI > > > implementation or the > > > standard UEFI boot services to pass tables like SMBIOS. > > > > > > > What prevents this HSM validated copy of u-boot from loading the kernel via EFI? > The vendor's U-Boot configuration for this specific secure boot path > (involving the > HSM) explicitly disables the CMD_BOOTEFI option due to security > mitigations, only > a subset of U-boot commands are whitelisted. We could patch the U-boot > to include > that but it is preferable to follow the vendor's recommandations and > just patch U-boot > to fill that memory location with SMBIOS address or directly with the > entry point. And what security mitigations are deemed needed for the EFI code? You are aware that avoiding EFI boot means that the booting kernel keeps all memory protections disabled for longer than it would otherwise. Is this allowlisting based on simply minimizing the code footprint? Introducing a non-standard mechanism means that others will now have to maintain it and coexist with it, rather than simply using the existing code which already fully supports what you are trying to accomplish (both on the bootloader and the kernel side) IOW, in my opinion, simply enabling CMD_BOOTEFI for your bootloader is a much better choice here. I'm not a u-boot expert but as I understand it, loading/authenticating the image and booting it in EFI mode are two separate things, and so the secure boot path would change very little. > > > Because there's no UEFI configuration table available in this boot mode, we need > > > an alternative mechanism to pass the SMBIOS table address to the kernel. The > > > /chosen node seemed like the most straightforward way for the bootloader to > > > communicate this non-discoverable information. > > > > > > I wasn't aware of the EBBR discussions covering this. I've added the > > > boot-architecture and arm.ebbr-discuss lists to the Cc. If there's a preferred > > > EBBR-compliant way to handle this for non-UEFI boots, I'm happy to adapt > > > the approach. > > > > > > > For the record, I don't see a huge problem with accepting SMBIOS > > tables in this manner, but it would be better if a description of this > > method was contributed to the DMTF spec, which currently states that > > the only way to discover SMBIOS tables on non-x86 systems is via the > > SMBIOS/SMBIOS3 EFI configuration tables. Doing so should prevent other > > folks from inventing their own methods for their own vertically > > integrated systems. (Other OSes exist, and from a boot arch PoV, we > > try to avoid these Linux-only shortcuts) > > > > However, the DT method should *only* be used when not booting via > > UEFI, to avoid future surprises, and to ensure that existing OSes > > (including older Linux) can always find the SMBIOS tables when booting > > via UEFI. > > > > Also, I would suggest to pull the entire entrypoint into DT, rather > > than the address in memory of either/both entrypoint(s). Both just > > carry some version fields, and the address of the actual SMBIOS data > > in memory, and the only difference between SMBIOS and SMBIOS3 is the > > size of the address field (32 vs 64 bits) > I understand the points raised about UEFI taking precedence and the > preference for standardization (DMTF). If this DT method is accepted > as a fallback only for non-UEFI boots like this one, the kernel implementation > will respect that precedence. > > Regarding the alternative to place the full SMBIOS entry point structure into > a DT property (as a byte array) instead of just its memory address. Both > approaches seem feasible from the U-Boot side. I opted initially for passing > the address to reuse the existing kernel functions (dmi_smbios3_present and > dmi_present) which already handle mapping and validation of the entry point > read from memory (as done for the EFI case). > Actually, it appears that dmidecode expects the entrypoint data in /sys/firmware/dmi/tables/smbios_entry_point, and so you will need to populate that file in any case, and so pulling it into the DT node is not as useful. But having both SMBIOS and SMBIOS3 is pointless, so please only bother with the latter.

5 months, 2 weeks

1
0
0 0

Re: [PATCH v2 0/2] DMI: Scan for DMI table from DTS info

by Ard Biesheuvel

On Thu, 23 Oct 2025 at 04:21, Adriana Nicolae <adriana(a)arista.com> wrote: > > On Wed, Oct 22, 2025 at 11:19 PM Rob Herring <robh(a)kernel.org> wrote: > > > > On Wed, Oct 22, 2025 at 04:45:25AM -0700, adriana wrote: > > > Some bootloaders like U-boot, particularly for the ARM architecture, > > > provide SMBIOS/DMI tables at a specific memory address. However, these > > > systems often do not boot using a full UEFI environment, which means the > > > kernel's standard EFI DMI scanner cannot find these tables. > > > > I thought u-boot is a pretty complete UEFI implementation now. If > > there's standard way for UEFI to provide this, then that's what we > > should be using. I know supporting this has been discussed in context of > > EBBR spec, but no one involved in that has been CC'ed here. > > Regarding the use of UEFI, the non UEFI boot is used on Broadcom iProc which > boots initially into a Hardware Security Module which validates U-boot and then > loads it. This specific path does not utilize U-Boot's UEFI > implementation or the > standard UEFI boot services to pass tables like SMBIOS. > What prevents this HSM validated copy of u-boot from loading the kernel via EFI? > Because there's no UEFI configuration table available in this boot mode, we need > an alternative mechanism to pass the SMBIOS table address to the kernel. The > /chosen node seemed like the most straightforward way for the bootloader to > communicate this non-discoverable information. > > I wasn't aware of the EBBR discussions covering this. I've added the > boot-architecture and arm.ebbr-discuss lists to the Cc. If there's a preferred > EBBR-compliant way to handle this for non-UEFI boots, I'm happy to adapt > the approach. > For the record, I don't see a huge problem with accepting SMBIOS tables in this manner, but it would be better if a description of this method was contributed to the DMTF spec, which currently states that the only way to discover SMBIOS tables on non-x86 systems is via the SMBIOS/SMBIOS3 EFI configuration tables. Doing so should prevent other folks from inventing their own methods for their own vertically integrated systems. (Other OSes exist, and from a boot arch PoV, we try to avoid these Linux-only shortcuts) However, the DT method should *only* be used when not booting via UEFI, to avoid future surprises, and to ensure that existing OSes (including older Linux) can always find the SMBIOS tables when booting via UEFI. Also, I would suggest to pull the entire entrypoint into DT, rather than the address in memory of either/both entrypoint(s). Both just carry some version fields, and the address of the actual SMBIOS data in memory, and the only difference between SMBIOS and SMBIOS3 is the size of the address field (32 vs 64 bits)

5 months, 3 weeks

1
0
0 0

EBBR call today Oct 22

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Oct 22 at 14:00 BST (13:00 UTC). [1] We have two pull requests on the agenda [2]: - Pull request #142: SCMI requirements - Pull request #148: Fix bibliography alignment for PDF and HTML We will use this pad [3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-22-ahgu?lang=en #142: https://github.com/ARM-software/ebbr/pull/142 #148: https://github.com/ARM-software/ebbr/pull/148

5 months, 3 weeks

2
2
0 0

EBBR call today Oct 8

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Oct 8 at 14:00 BST (13:00 UTC). [1] We have mostly one pull request on the agenda [2]: - Pull request #142: SCMI requirements This is less important but if time permits, we can also discuss this second pull request: - Pull request #148: Fix bibliography alignment for PDF and HTML We will use this pad [3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-8-ah7i?lang=en #142: https://github.com/ARM-software/ebbr/pull/142 #148: https://github.com/ARM-software/ebbr/pull/148

6 months

1
0
0 0

DT relevance

by ff

Dear fellow firmware aficionados, Static ACPI has been adopted by Mercedes and other silicon vendors to: - meet the safety requirements - stay away from DT lifecycle issues - leverage chiplet and CXL bindings - truly multi-host/hypervisor (or even secure/no-secure should people want it) as bindings are defined in an ad-hoc forum (not by an OS community) DT community leaders and enthusiasts, I believe discussion on the bigger picture related to DT relevance in the long run may be needed as I believe many embedded solutions will follow Mercedes example. Constructively yours, François-Frédéric PS: static ACPI can be handled by a simple parser, do not execute any ACPI byte code, is findable by EFI tables, code base is even smaller than libfdt.

6 months, 1 week

5
11
0 0

EBBR call today Sep 24

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Sep 24 at 14:00 BST (13:00 UTC). [1] We have a single topic on the agenda [2]: - Pull request #142: SCMI requirements (was: "Conditionally require SCMI 2.x, x >= 1 recommended") Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. We will 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-24-agy7?lang=en #142: https://github.com/ARM-software/ebbr/pull/142

6 months, 2 weeks

1
0
0 0

EBBR call today Sep 10

by Vincent Stehlé

Dear EBBR contributors, We will have our EBBR call today, Sep 10 at 14:00 BST (13:00 UTC). [1] We have a single topic on the agenda for now [2]: - Pull request #144: PFDI requirements Heinrich, do you want to add your pull request as well? - Pull request #147: chapter3: raise RISC-V SBI requirement In all cases, feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. We will 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-10-agou?lang=en #144: https://github.com/ARM-software/ebbr/pull/144 #147: https://github.com/ARM-software/ebbr/pull/147

7 months

2
1
0 0

Fwd: [devicetree-org/dt-schema] schemas: chosen: document devicetree-path property (PR #167)

by Rob Herring

Posting to boot-architecture list for more visibility. ---------- Forwarded message --------- From: Casey Connolly <notifications(a)github.com> Date: Mon, Jun 30, 2025 at 12:33 PM Subject: [devicetree-org/dt-schema] schemas: chosen: document devicetree-path property (PR #167) To: devicetree-org/dt-schema <dt-schema(a)noreply.github.com> Cc: Subscribed <subscribed(a)noreply.github.com> Background With more and more laptops, dev boards, and other products shipping with both an EFI capable bootloader and relying on devicetree, there is an increasing problem with trying to ensure that a devicetree is loaded and that it will work with the kernel/OS version being booted. This is less of an issue on vertically integrated embedded platforms, but with ARM SystemReady gaining prevalence and the abundance of cheap dev boards there is a growing desire to boot generic OS installer/disk images on these devices. In some cases the platform doesn't see many devicetree changes and works well with a range of kernel versions, the board can just provide it's own devicetree in firmware and it will work just fine. However there are many platforms where this is not the case, unintentional breaking changes can be made to drivers or DT, or new features being enabled can break compatibility with older kernels. In these cases, the best way to maximise the chance that the generic OS image will boot is if it can load the devicetree blob which was installed alongside the kernel (something most mainstream distros do). To enable this there has to be a consistent way to determine which dtb (and overlays) were embedded into the firmware provided devicetree. This new property enables exactly this usecase by making it possible to embed the information into the dtb itself at build time. A proposed implementation of this for U-Boot is available here 1. The devicetree paths are all appended to some versioned prefix (typically the kernel version) which would be known by the OS loader when you choose a version to boot. Prior effort Previous attempts have been made to work around the issue of DTB loading, U-Boot attempts to search some well-known (unversioned) paths on the ESP using it's internal fdtfile variable (which has to be constructed in a platform specific way, see below). This has mixed results and doesn't work on distros like Fedora and Debian which install dtbs to version-specific subdirectories. On the EFI laptop side (where they don't provide any DTB) the dtbloader EFI driver effectively implements the same logic as U-Boot, guessing generic paths and using an internal unreliable map of SMBIOS hardware IDs to file paths, this has been the go-to for many folks for a while now but it's clear that it doesn't scale and that distros won't be keep to ship it. It gets more complicated when you consider secureboot as well which would require signing the driver. File path as API This proposed solution does have a potential stumbling block, as it effectively cements the idea that the dtb path is API. I believe this is a bridge that was already crossed long ago when extlinux and later GRUB and systemd-boot gained a way to specify a devicetree blob to load, since all distros use the upstream file naming, any renames already potentially cause devices to become unbootable after a kernel upgrade... That being said, it's clear that the current way files are named is often arbitrary and definitely inconsistent. I would propose a solution like enforcing a way to convert between the root compatible property and the file path, this provides consistency and removes the need to store this arbitrary additional data needed to locate the dtb on the ESP during boot. An ugly attempt to best-effort this conversion for Qualcomm boards today can be found at 2. Why not store this data elsewhere? There are quite a few benefits to putting this in the DTB itself. It makes it possible to have a generic bootloader binary which gets the DTB in an implementation-specific way, it avoids having to hard-code the data. On devices that have an EFI which doesn't provide a DTB, a driver can be installed once on the ESP which installs a stub DT just containing these properties, so that the OS loader can use them. It isn't EFI specific, extlinux or other boot methods can make use of this. This is metadata which belongs with the DTB, it can be inserted at build time or at runtime, or even augmented to add additional overlays at runtime should the implementation require that. All in all, a generic mechanism for bootloaders and OS loaders to load a dtb and overlays from the ESP (or other arbitrary storage mechanism) is needed, and there doesn't seem to be another place to put it. Why not FIT? The FIT format has it's uses in embedded applications, but the only way it could be applied here would be to use it as the way to index /all/ of the available DTBs, in a generic ARM64 Fedora or Debian image there are thousands of these. In addition, while matching by compatible property may work for the base DTB, it doesn't work for overlays. And of course, using FIT for this would require changing how DTBs are installed and packaged, this would be hugely disruptive and introduce a myriad of additional problems. cc @poettering @apalos ________________________________ You can view, comment on, or merge this pull request online at: https://github.com/devicetree-org/dt-schema/pull/167 Commit Summary bb9677f schemas: chosen: document devicetree-path property File Changes (1 file) M dtschema/schemas/chosen.yaml (22) Patch Links: https://github.com/devicetree-org/dt-schema/pull/167.patch https://github.com/devicetree-org/dt-schema/pull/167.diff — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: <devicetree-org/dt-schema/pull/167(a)github.com>

7 months

7
17
0 0

Call for Participation: Embedded & IoT micro-conference at Linux Plumbers 2025

by Jan Lübbe

We are happy to announce that the Embedded & IoT micro-conference was again accepted for Linux Plumbers this year. Hosted in beautiful Tokyo, Japan December 11-13. https://lpc.events/event/19/contributions/2005/ Topics cover all things embedded and IoT. Boot time to kernel size, low power communication, telemetry and also RTOS. Devicetree and build system have their own MC and we can move sessions between them as needed. As with all MC's at Plumbers we are not looking for talks, but rather discussing current problems and working towards their solution. If your proposal has a specific stakeholder (maintainer, developer, company) that would be needed for a fruitful discussion, please mention it in your submission. The CfP is open now and will run until October 3rd. Please do not wait until the end with your submissions as we are going to accept good proposals even before the end, so the MC might be filled up before October 3rd. Jan & Stefan

7 months, 1 week

1
0
0 0

EBBR call today Aug 27

by Vincent Stehlé

Dear EBBR contributors, I hope you had a nice summer break. We will have our EBBR call today, Aug 27 at 14:00 BST (13:00 UTC). [1] We have a few topics on the agenda [2]: - First look at pull request #144: PFDI requirements - Pull request #145: Harmonize sections references titles - Pull request #146: Bump references We will not "vote" on the PFDI requirements on this call, as I suspect not everybody might be back yet, but for the next two minor pull requests we might. We can use this pad [3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-aug-27-agfi?lang=en #144: https://github.com/ARM-software/ebbr/pull/144 #145: https://github.com/ARM-software/ebbr/pull/145 #146: https://github.com/ARM-software/ebbr/pull/146

7 months, 2 weeks

2
2
0 0

u-boot question regarding the rockchip rk 3399...

by Mario Marietto

Hello. I've installed FreeBSD 14.2-RELEASE on both my boards (RockPro64 and Khadas Edge V),both based on the Rockchip RK3399 and I've used a display that has a resolution of 720 x 720 resolution and I saw that the screen remains almost black (almost because I see a dim illumination coming from the display) . I don't even see the u-boot logo. Instead,it is able to turn on my large HDMI monitor,which has a resolution of 1920x1080 pixels. Since I'm building a FreeBSD modular phone, I want to use a small HDMI display with a low resolution. My question is : why is u-boot able to turn on a monitor that has a resolution of 1920x1080 and it's not able to turn on the other HDMI display that has a resolution of 720x720 ? Or even better : what's the lowest resolution that will work ? If I want to buy a display that has a resolution of 800x600,will u-boot be able to turn it on ? 1024x768 ? more ? Thanks. -- Mario.

7 months, 3 weeks

2
5
0 0

Next EBBR call Aug 27

by Vincent Stehlé

Hi, This is a quick reminder that we will not have an EBBR call today and the next one will be on Aug 27. [1] Best regards, Vincent Stehlé System Architect - Arm [1] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

9 months, 1 week

1
0
0 0

EBBR call today Jun 18

by Vincent Stehlé

Dear EBBR contributors, We will have an EBBR call today, Jun 18 at 14:00 BST (13:00 UTC). [1] We have mostly only one topic on the agenda [2], therefore this could be a short call: - Summary of the investigations for pull request #141 ("All runtime services optional after ExitBootServices()") - Let's decide if we drop it completely. Otherwise if people are motivated enough we could always cleanup old issues and pull requests. We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-jun-18-af4v?lang=en #141 https://github.com/ARM-software/ebbr/pull/141

9 months, 4 weeks

1
0
0 0

No EBBR call today Jun 4?

by Vincent Stehlé

Hi, We have no agenda for today's EBBR call [1], therefore I suspect we might end up canceling it. If you have an urgent topic to discuss today, please let us know before 11am UTC, otherwise we will adjourn the call. Best regards, Vincent Stehlé System Architect - Arm [1] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

10 months, 1 week

1
1
0 0

No EBBR call today May 21?

by Vincent Stehlé

Hi, We have no agenda for today's EBBR call [1], therefore I wonder if we might as well cancel it. If you have an urgent topic to discuss today, please let us know before 11am UTC, otherwise we will adjourn the call. Best regards, Vincent Stehlé System Architect - Arm [1] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

10 months, 3 weeks

1
2
0 0

EBBR call today May 7

by Vincent Stehlé

Dear EBBR contributors, We will have an EBBR call today, May 7 at 14:00 BST (13:00 UTC). [1] We have only one topic on the agenda [2], therefore this could be a short call: - Pull request #142: Conditionally require SCMI 2.x, x >= 1 recommended We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-may-7-aecv?lang=en #142 https://github.com/ARM-software/ebbr/pull/142

11 months, 1 week

1
0
0 0

EBBR call today Apr 23

by Vincent Stehlé

Dear EBBR contributors, We will have an EBBR call today, Apr 23 at 14:00 BST (13:00 UTC). [1] On the agenda: [2] - Pull request #141: All runtime services optional after ExitBootServices(). - Pull request #142: Conditionally require SCMI 2.x, x >= 1 recommended We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-23-apr-ae3j?lang=en #141 https://github.com/ARM-software/ebbr/pull/141 #142 https://github.com/ARM-software/ebbr/pull/142

11 months, 3 weeks

1
0
0 0

EBBR "birds of a feather" session at the Linaro Connect in Lisbon

by Vincent Stehlé

Dear EBBR contributors and stakeholders, We will have an EBBR "birds of a feather" session at the Linaro Connect in Lisbon. [1] If you are attending the Linaro Connect, we would be pleased to see you there! Best regards, Vincent Stehlé System Architect - Arm [1] https://www.kitefor.events/events/linaro-connect-2025/submissions/331

1 year

1
0
0 0

No EBBR call today Apr 9?

by Vincent Stehlé

Hi, We have no agenda for today's EBBR call [1]; shall we cancel it? If you have an urgent topic to discuss today, please let us know before 11am UTC, otherwise we will adjourn the call. Best regards, Vincent Stehlé System Architect - Arm [1] https://github.com/ARM-software/ebbr/wiki/EBBR-Meetings

1 year

1
1
0 0

EBBR call today Mar 12

by Vincent Stehlé

Dear EBBR contributors, We will have an EBBR call today, Mar 12 at 14:00 UTC. [1] On the agenda: [2] - Pull request #138: Require FF-A compatibility with v1.2 - Pull request #139: Recommend GOP We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-mar-12-adbk?lang=en #138 https://github.com/ARM-software/ebbr/pull/138 #139 https://github.com/ARM-software/ebbr/pull/139

1 year, 1 month

1
0
0 0

EBBR call today Feb 26

by Vincent Stehlé

Dear EBBR contributors, We will have an EBBR call today, Feb 26 at 14:00 UTC. [1] On the agenda: [2] - Pull request #138: Require FF-A compatibility with v1.2 We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-26-ad28?lang=en #138 https://github.com/ARM-software/ebbr/pull/138

1 year, 1 month

1
0
0 0

No EBBR call today Jan 29 ?

by Vincent Stehlé

Hi, We have nothing on today's EBBR call's agenda [1]; I would therefore be tempted 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

1 year, 2 months

1
1
0 0

EBBR call today Jan 15

by Vincent Stehlé

Dear EBBR contributors, Happy new year! We will have an EBBR call today, Jan 17 at 14:00 UTC. [1] We have just one pull request on the agenda: [2] - Pull request #137: Require FMP and "on disk" OsIndicationsSupported bits when supported We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-jan-15-aca9?lang=en #137 https://github.com/ARM-software/ebbr/pull/137

1 year, 2 months

1
0
0 0

EBBR v2.3.0 has been released

by Vincent Stehlé

Hi, I am happy to announce that v2.3.0 of the EBBR specification has now been released. [1] Compared to v2.2.0, this release formalizes the Boot Manager requirements, adds requirements on authenticated FMP capsules for firmware update and deprecates spin tables for AArch64. The following people (listed in alphabetical order) have participated to this EBBR release directly or indirectly, with patches, github issues, pull requests, reviews, comments, suggestions, or by participating to the regular calls: Andrea Della Porta Ard Biesheuvel Étienne Carrière Heinrich Schuchardt Ilias Apalodimas Joakim Bech Jon Humphreys Michal Simek Peter Robinson Ricardo Salveti Rob Herring Vincent Stehlé A big thank you and a merry Christmas to all the EBBR contributors! Best regards, Vincent Stehlé System Architect - Arm [1]: https://github.com/ARM-software/ebbr/releases/tag/v2.3.0

1 year, 3 months

1
0
0 0

EBBR call today Dec 18

by Vincent Stehlé

Dear EBBR contributors, We will have an EBBR call today, Dec 18 at 14:00 UTC. [1] On the agenda: [2] - Feedbacks on v2.3.0-pre1 and releasing v2.3.0. - Pull request #136: Update UEFI version to 2.11 Should we take it for v2.3.0? We can use this pad[3] for the meeting notes. Feel free to add to the agenda, directly on the wiki page, by e-mail or on the pad. 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-dec-18-abrk?lang=en #136 https://github.com/ARM-software/ebbr/pull/135

1 year, 3 months

1
0
0 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

boot-architecture