# LinuxBoot Meeting Notes

In bi-weekly meetings, we discuss the development of the [LinuxBoot project](https://linuxboot.org).
The calendar on the website has a link to the video conference.

Our main reference is the [LinuxBoot book](https://book.linuxboot.org) :book:.

## 2026-05-25

## 2026-05-11

will be skipped

## 2026-04-27

- Thierry Laurion (Heads)
- Daniel Maslowski (LinuxBoot TSC)
- Philip Molloy (LinuxBoot TSC)
- Ron Minnich
- Piotr Król (3mdeb)

### Topics

- Philip went to SUSECon in Prague, exchanged with others
- Madness about RPi reinventing everything
- State of LinuxBoot: not dead, just resting
- We did some work on the book last year
- Piotr is considering LinuxBoot for Dasharo, hasn't looked into it much yet
- Philip: We intend to clarify what LinuxBoot means in terms of what you need
- We provide the idea, you do the implementation
- We point you to everything you need in order to get there
- Piotr: For the future of the project, commercial support will be necessary
- Where is the project going? Which integrations?
- On top of EFI PEI/DXE, coreboot, ???
- Build systems: Yocto, Buildroot?
- Philip: Proposed Buildroot as a build system
- Using systemd-boot in Linux userspace instead of UEFI
- Leverage the existing parser for boot entries etc
- Talked to Lennart Poettering about it, questions arose
- How does the whole kexec thing work?
- Authentication?
- Interfaces between components, contracts?
- Piotr: Case study sounds like a sensible contribution for 3mdeb
- Piotr: Are there public recipes for LinuxBoot on top of EFI?
- Daniel: We have some in the old repositories, it's complicated
- Existing recipes are mainly for older OCP machines
- Piotr: hard to obtain
- Daniel did a PoC on a ThinkPad X270, ran into issues
- Problem with distros being made for UEFI, requiring EFI framebuffer
- Intention was to publish more; it's been 2 years since
- Can export list of DXEs to remove from Fiedka
- Want to have `utk` consume that for replaying the changes
- Ron: LinuxBoot with u-root on top of EFI runs on many machines
- Millions, but in datacenters of hyperscalers
- Project suffered during pandemic, when people left Google
- Need people from the community to keep it going
- Full circle coming back to the idea of LinuxBIOS >25 years ago
- Google dropped coreboot again for servers in 2021
- Linux devs double down on EFI, even on RISC-V now
- Piotr: 3mdeb already had an interest in u-root, e.g. for DRTM
- Transition from earlier stages is important
- Many things are not publicly documented
- Ron: Google employees having a hard time maintaining projects
- Not encouraged ... even less for documentation
- Piotr: Are there companies selling LinuxBoot hardware?
- Ron: We had one, lost it to Iron Mountains
- Daniel: It was Horizon Computing; see bottom of linuxboot.org for ref
- Thierry: Where is Google going?
- Philip: We were asked for a "roadmap", but we're doing volunteer work
- David Hu envisioned LinuxBoot "2.0"
- Ron: Question: What company would buy a LinuxBoot machine?
- UEFI was pushed everywhere, so everyone expects it now
- Maintaining two software stacks complicated for hardware vendor
- UEFI and coreboot+LinuxBoot would mean obligations
- Philip: The market is already narrow
- Ron: Success on Chromebooks because coreboot was invisible
- Philip: What other vendor than ADI documents their mask ROM publicly?
- Ron: Big meeting of Arm vendors, all talking about UEFI
- Question: What's the issue with the established U-Boot?
- Chromebooks went with Depthcharge
- Ron: Can we come from a Right to Repair angle?
- Daniel: you need 3 things
- Ability to claim ownership; locked platforms are an issue
- You can exploit things like Intel ME, though not great
- Education; very few people even know about / dare to look at firmware
- Hardware to work with; flash programmers, probes, desoldering unpleasant
- Ron: Back to topic; where are we now?
- HPE have an entire supply chain around firmware, same as DELL
- You as the end user cannot change or own the signing key
- OCP discarded standard requiring to pass ownership to user
- Ron: <https://github.com/opencomputeproject/ocp-fwupdater-PoC>
- Matrix channel revival: https://matrix.to/#/#osfw-linuxboot:matrix.org

## 2026-04-13

skipped

## 2026-04-13

- Thierry Laurion (Heads)
- Daniel Maslowski (LinuxBoot TSC)
- Ron Minnich

### Topics

- Thierry's proposal got approved
- https://nlnet.nl/project/LinuxBoot4all/
- Daniel did some u-root / mkuimage maintenance
- https://github.com/u-root/mkuimage/pull/46
- https://github.com/u-root/mkuimage/pull/47
- https://github.com/u-root/mkuimage/pull/48
- Project: LinuxBoot to k8s
- Goal: press power button, cluster ready after 5 seconds
- I know it's not realistic, but if you don't aim high, you won't fall deep
- For consideration:
- [k3s](https://github.com/k3s-io/k3s)
- [KubeSolo](https://github.com/portainer/kubesolo)
- [boot2container](https://archive.fosdem.org/2022/schedule/event/container_boot2container/)
- Ron will have time again for this meeting
- Suggested to publicize NlNet funding. Question is which channel and when
- Suggested we create branched/versioned LinuxBoot book to be able to direct stakeholders to previous version and WiP one
- Proposed to provide older ARM hardware, can ship.
- kexec purgatory might be something unneeded today (Plan 9 real life exeperience, contrib to be followed)
- Used a Plan 9 kernel in place of the purgatory binary

## 2026-03-30

- Daniel Maslowski (LinuxBoot TSC)
- Philip Molloy (LinuxBoot TSC)

### Topics

- Daniel: Continued work on dtvis
- [phandles/references in particular](https://github.com/platform-system-interface/dtvis/issues/19)
- talked to friends at CLT regarding recent [FIT-related vuln](https://github.com/barebox/barebox/security/advisories/GHSA-3fvj-q26p-j6h4)

## 2026-03-16

- Thierry Laurion (Heads)
- Daniel Maslowski (LinuxBoot TSC)
- Philip Molloy (LinuxBoot TSC)

meeting through google meet

### Topics

- Thierry : Was unexpectedly re-contacted by NlNet to push for *Linuxboot for all* past grant application in current round. They proposed something they would agree with which I only had to say "yes". Wondering who wants to do what; scoped to go bottom up (linuxboot on current x86 second hand, Risc-V and ARM targets), Linuxboot chapters on cleaning DXE, recipes, SBOM etc.
- https://github.com/geerlingguy/sbc-reviews
- Framwork RISC-V MB swap board: https://github.com/geerlingguy/sbc-reviews/issues/82 (DC-ROMA AI PC - RISC-V Mainboard II)
- Philip:
- mostly working on first stage / DDR init now
- was at Embedded World representing ADI
- Daniel:
- hint on <https://sbcwiki.com/news/>
- drafting a serial vector graphics protocol <https://github.com/platform-system-interface/jiji>

#### NlNet "Linuxboot for all" Project's Description (redacted)

LinuxBoot carries years of hyperscaler knowledge that has never been made accessible to the broader hardware community. Three contributors from different areas of the ecosystem are ready to commit sustained effort to relaunching the project, anchored by restarted bi-monthly meetings and a shared 12-month roadmap.

The immediate focus is to rewrite the LinuxBoot book and give the project a concrete, actionable identity: documenting the use of Fiano to remove the large number of unneeded DXE modules present in UEFI firmwares, and pushing LinuxBoot into the desktop and laptop space by working from both ends of the spectrum — single-board systems and servers capable of secure self-hosting today.

Several threads of contribution are already aligned. Former NERF engineers, no longer under NDA, are ready to bring their hyperscaler experience back into the public domain. Lessons learned from maintaining the Heads project will feed directly into LinuxBoot's documentation and tooling. A u-boot + LinuxBoot proof-of-concept on a Rockchip single-board system is planned as a concrete reference to lower the barrier for Rockchip and similar vendors to adopt LinuxBoot.

The longer-horizon ambition is to work with Framework to adopt LinuxBoot without Boot Guard, with all firmware-related components housed in a removable module — carrying forward the mission where the Flashkeeper project concludes.

While much of the effort will be community, coordination, and political work, this grant covers the R&D part of the mission.

12-month goal: Bring hyperscaler knowledge back as public recipes for real hardware (servers, laptops, SBCs) and engage prototyping companies to use and contribute to LinuxBoot.

#### Concrete outcomes:

- Updated LinuxBoot book with DXE removal methodology
- DXE removal campaigns with documented safe DXE profiles for x86, ARM, and RISC-V targets
- LinuxBoot deployment recipes for servers, laptops, workstations, and SBCs
- u-boot + LinuxBoot PoC on Rockchip SBC, published as a vendor-facing reference
- Documentation of servers that can use LinuxBoot for secure self-hosting today
- Reproducible build scripts and CycloneDX/SPDX SBOMs for each tested board
- Restarted bi-monthly meetings with public agenda and decision record

#### Work Packages

1. DXE automation on real hardware

Improve tooling around dxecleaner and Fiano; build and test a flash/power/reboot/log harness around two to three UEFI x86 devices under test, as well as representative ARM and RISC-V targets; run full DXE-removal campaigns and document safe DXE profiles per board.

Milestones:

- Improved dxecleaner/Fiano tooling published upstream
- Flash/power/reboot/log harness operational and documented for x86 devices under test
- DXE removal campaign completed for x86 targets; safe DXE profiles published per board
- DXE removal baseline established for at least one ARM target (Rockchip SBC)
- DXE removal baseline established for at least one RISC-V target

2. Reproducible builds and SBOM pipeline

Develop deterministic build scripts for LinuxBoot/u-root on the chosen devices; integrate SBOM generation (CycloneDX/SPDX) into the build pipeline and establish a basic verification story so anyone can audit what they flash.

Milestones:

- Deterministic build scripts for LinuxBoot/u-root published for each device under test
- CycloneDX/SPDX SBOM generation integrated and documented
- Verification workflow published so users can independently audit a flashed image

3. Documentation and recipes (LinuxBoot book + HOWTOs)

Produce updated chapters for the LinuxBoot book and a set of concrete board-level recipes, making the outcomes of work packages 1 and 2 accessible to anyone starting from vendor firmware.

Milestones:

- Chapter on DXE removal methodology on real hardware published
- Chapter on reproducible builds and SBOM published
- Two to three "from vendor firmware to LinuxBoot" recipes published for the chosen boards
- Documented list of servers that can run LinuxBoot for secure self-hosting today published

4. u-boot + LinuxBoot PoC on Rockchip SBC

Demonstrate a working u-boot + LinuxBoot stack on a Rockchip single-board system as a reference implementation to lower the barrier for Rockchip and similar vendors to adopt LinuxBoot.

Milestones:

- u-boot + LinuxBoot PoC running and reproducibly buildable on Rockchip SBC
- PoC documented as a vendor-facing reference and published
- Bi-monthly meeting process restarted with public agenda and decision record

5. Hardware and lab

Procure two to three second-hand x86 UEFI systems as devices under test and any missing lab controller pieces for flash, power, and serial access, preferring reuse and donations where possible.

Milestones:

- Devices under test acquired and lab harness assembled
- Hardware inventory and sourcing notes published for reproducibility

## 2026-02-02

- Daniel Maslowski (LinuxBoot TSC)
- Philip Molloy (LinuxBoot TSC)
- Thierry Laurion (Heads)

### Topics

We're busy with our work.

Some thoughts from Daniel's mind:
- We are getting [new CYBER CYBER legal things in the EU](https://docbox.etsi.org/CYBER/EUSR/Open), also [addressing bootloaders](EN-304-623_V0.0.12_2025-12-19_Boot_Managers_Mature-draft.pdf).
- We should [provide feedback](https://docbox.etsi.org/CYBER/EUSR/Open/ETSI_Commenting_Guidelines_for_Open_Consultation_2026-01-14.pdf), specifically on the issue of ownership and transfer thereof.
- LinuxBoot and other custom solutions should be a possible choice to a device owner, so that they can opt out of the vendor-provided software, for security, self-sovereignty, etc.. Some vendors argue that vendor-gated lockdowns are "for security". They fail to prove said security though, are neither dependable nor trustworthy, as the news keep showing. Often enough is source code not provided, so that the device owner cannot verify any claims without reverse engineering, or in some cases not at all. The vendors are surely not talking about the _owner_'s security, but that of the vendor, the media industry, etc..
- Can we have a global keyring in the system along the lines of Plan 9's factotum?
- `systemd-keyring`?
- e.g. NetworkManager stores its credentials in a root-only-accessible directory
- desktop environments have their own keyrings, e.g. GNOME and KDE
- web browsers have credentials management
- some people use KeePassXC, VaultWarden etc
- distros have their keyrings for package signing
- Arch folks are proposing [a distro-agnostic approach via UAPI Group](https://uapi-group.org/specifications/specs/file_hierarchy_for_the_verification_of_os_artifacts/)
- see also https://devblog.archlinux.page/2026/verify-arch-linux-artifacts-using-voa-openpgp/
- Philip talked to Lennart Poettering at FOSDEM and presented to Buildroot folks
- Lennart said leveraging systemd for LinuxBoot sounds good, another maintainer would be interested
- Someone from the Buildroot crowd brought up Petitboot, and Philip explained how it was mainly for POWER and Google et al created u-root etc for their purposes.
- Planning on a preso at All Systems Go! to connect embedded and other folks
- suggestion: have a "Why you need LinuxBoot" slide deck, just like e.g. Zephyr has one for marketing presos
- Thierry needs points to convince NLnet that LinuxBoot is useful.
- I wrote back to NLnet.
- arguably, big names like Google, Red Hat (nmbl), ByteDance etc are behind it, so demand is there (we can reference our book)
- we really need to add Netflix / Warner Losh's work https://github.com/linuxboot/book/issues/134 to the book, HIGH PRIORITY :rotating_light:

## 2025-11-24

- Philip Molloy (LinuxBoot TSC)
- Daniel Maslowski (LinuxBoot TSC)

### Topics

- LinuxBoot beyond just hyperscalers (everyone else)
- A small discussion in the OSFW Slack channel
- People would like to see features such as reacting to newly attached devices
- We would like to grow a community that is not just 3 big companies
- We want a good experience for laptop/desktop use
- Philip will have time by the end of the year to work on the book
- TODOs to be discussed in the next meeting
- Daniel is making progress with [`intel_fw`](https://github.com/platform-system-interface/intel_fw/)
- Got a lot of [documentation](https://platform-system-interface.github.io/intel_fw/) out
- Attending meetups and giving presentations to get people interested
- Will see what to do at 39C3; we'll have an OSFW assembly again

## 2025-11-10

- Daniel Maslowski (LinuxBoot TSC)
- Thierry Laurion (Heads)

### Topics

- [`intel_fw`](https://github.com/platform-system-interface/intel_fw/) is making lots of progress
- close to feature parity with `me_cleaner`
- already has additional features and improvements
- brief sync on NLnet proposals
- Daniel's "LinuxBoot for the Community" (targeting U-Boot) got rejected
- Thierry's proposal "LinuxBoot for all" (general advancement) got back questions to answer in time

## 2025-10-13

- Daniel Maslowski (LinuxBoot TSC)

### Topics

- Daniel is working on a [new Intel firmware tool](https://github.com/platform-system-interface/intel_fw/) under an OSFF grant
- Starting with `me_cleaner` feature parity

## 2025-09-29

### Participants

- Daniel Maslowski (LinuxBoot TSC)

### Topics

- got [a bunch of PRs](https://github.com/linuxboot/book/pulls?q=is%3Apr+is%3Aclosed+merged%3A2025-09-15..2025-09-29+base%3Amain+sort%3Aupdated-desc) into the book

## 2025-09-15

### Participants

- Philip Molloy (LinuxBoot TSC)
- Daniel Maslowski (LinuxBoot TSC)
- Thierry Laurion (Heads)
- Dennis Marttinen (CSC)

### Topics

- brief sync between us

## 2025-09-01

### Participants

- Philip Molloy (LinuxBoot TSC)
- Daniel Maslowski (LinuxBoot TSC)

### Topics

- Daniel successfully did a `kexec` on MDM9625
- And even so [via a menu](https://www.youtube.com/watch?v=gpOJrqOjBHI)
- New chapter request: [role of the initramfs](https://github.com/linuxboot/book/issues/177)

## 2025-08-18

### Participants

- Daniel Maslowski (LinuxBoot TSC)

### Topics

- Found more traces of people doing/wanting LinuxBoot
- [`kexec` on a Qualcomm Arm v7 (32-bit) based phone](https://gist.github.com/alvinhochun/7945270)
- [Ported from Mike Kasick's work](https://xdaforums.com/t/patches-kexec-syscall-support-boots-kernels-from-sd-or-usb-11-6-11-gb-support.1266827/) and [used in kernel forks](https://github.com/alvinhochun/sony-xperia-m-kernel/commits/android-4.1.2_r2.1/)
- [commit 2e818d8 "Implement kexec-hardboot"](https://github.com/alvinhochun/sony-xperia-m-kernel/commit/2e818d81f21f6a627bc629e477052045426b0663)
- See there for more references and how this was ported multiple times
- TODO: Heavy patches (~300 lines, incl. asm), can they be mainlined?
- People in the postmarketOS and Qualcomm mainline development communities are also interested
- Daniel started a writeup on `earlycon`/`earlyprintk`, from a generic perspective
- Sometimes the only debug option
- Kernel docs have notes scattered around
- [cmdline (admin guide)](https://docs.kernel.org/admin-guide/kernel-parameters.html)
- [serial API (for developers)](https://docs.kernel.org/driver-api/serial/driver.html)
- `earlyprintk` is arch specific, e.g. [x86](https://docs.kernel.org/arch/x86/earlyprintk.html), see [platform devices and drivers](https://docs.kernel.org/driver-api/driver-model/platform.html)
- TODO: early output on (SPI, I2C) screen when no UART/serial is available

## 2025-08-04

### Participants

- Dennis Marttinen (Racklet)
- Daniel Maslowski (LinuxBoot TSC)

Philip has another colliding meeting, unfortunately.

### Topics

- Platform setup
- Trinity of
- hardware features (controllers, fixed parts...)
- kernel features (enabled drivers via Kconfig, possibly hard baking in)
- boot time features (enabled via device tree, possibly ACPI)
- Question: how to you enable / reconfigure at runtime, i.e., from userspace?
- Daniel applied for OSFF grant to pick up and extend the work on Intel ME tooling
- Can we gain traction through UEFI Secure Boot key expiry?
- https://lwn.net/Articles/1029767/
- https://nondeterministic.computer/@mjg59/114949832337898099
- What motivates people to switch systems? What can we offer for firmware?
- features and anti-features (MS pushing for AI, ads...)
- performance
- not really overclocking, that's just marketing/part of the products
- some faetures are hard disabled in firmware, but hardware would be capable
- memory tuning? get more bandwidth with open firmware
- undervolting, battery life enhancement, thermal improvement
- MSRs documented by community
- [Intel XTU](https://www.intel.com/content/www/us/en/download/17881/intel-extreme-tuning-utility-intel-xtu.html) (eXtreme Tuning Utility) is for Windows only
- So is [ThrottleStop](https://www.techpowerup.com/download/techpowerup-throttlestop/) - this is basically required to fix bad OEM power configuration on a lot of laptops
- TDP adjustment
- 3rd party apps necessary to e.g. tweak GPU fan control on Windows
- firmware not capable enough
- Windows doesn't have it built in
- platform features
- MSRs, chicken bits?
- scan through firmware images to find all MSR interactions
- gain ideas from logic around, DXE GUIDs and possible names, etc
- transplant them to other platforms
- Create LinuxBoot as an intermediate stage on ESP (between firmware and OS loader)
- Enables more participation from community
- Easier to port to, say, Arm SBCs and add on top of U-Boot (proper)
- E.g. move [raspi-config](https://www.raspberrypi.com/documentation/computers/configuration.html) to earlier environment than final OS
- Essentially a "better GRUB", which is hard to work with in terms of UI
- Universal tool to get a menu with _all_ the UEFI options for CPU etc config
- OEMs typically hide many options that are still available nonetheless
- Extract options via [IFRExtractor](https://github.com/LongSoft/IFRExtractor-RS)
- AMD vs Intel specifics?
- AMD: [Smokeless UMAF](https://github.com/DavidS95/Smokeless_UMAF) accesses the full AGESA menu
- Daniel drafted a [writeup on multicall binaries](https://github.com/orangecms/multicall), should end up in the LinuxBoot book

## 2025-07-07

### Participants

- Dennis Marttinen (Racklet)
- Philip Molloy (LinuxBoot TSC)
- Daniel Maslowski (LinuxBoot TSC)

### Topics

- Merged into :book:: [boot config](https://github.com/linuxboot/book/pull/145)
- What next?
- Philip: [intro cleanup](https://github.com/linuxboot/book/pull/176)
- Daniel: [expand on use-cases](https://github.com/linuxboot/book/pull/140)

## 2025-06-23

### Participants

- Dennis Marttinen (Racklet)
- Thierry Laurion (Heads)
- Philip Molloy (LinuxBoot TSC)
- Daniel Maslowski (LinuxBoot TSC)

### Topics

- Restructuring the [book :book:](https://book.linuxboot.org)
- Intro has too many UEFI, u-root specifics
- Move specifics into other sections
- Keep only "What is LinuxBoot?" and "Why LinuxBoot?"
- Diagram like on the main LinuxBoot website
- Recreate with Mermaid?
- Add oreboot as another possible pre-stage
- Have graphics for EDK2, U-Boot etc for recognition
- "What LinuxBoot does" -> intro to UEFI
- Golang selling points -> under u-root
- Make high-level sections short intros, a single paragraph roughly
- Glossary using [mdbook-hints](https://lib.rs/crates/mdbook-hints)?
- Daniel drafted an application for NLnet / NGI fund
- Goal: Integrate LinuxBoot with U-Boot SPL
- ~5 platforms for reference
- Asked for EUR 50k (max)
- Will also apply for OSFF fund
- Goal: Tooling for AMD platform images based on [earlier work](https://github.com/fiedka/romulan)
- Max is EUR 5k

## 2025-06-09

### Participants

- Dennis Marttinen (Racklet)
- Thierry Laurion (Heads)
- Philip Molloy (LinuxBoot TSC)
- Daniel Maslowski (LinuxBoot TSC)

### Topics

- Philip:
- Something for the book in the next 14 days
- Make it succinct and exciting?
- Community vs corporate development
- Dennis:
- LinuxBoot is competing with "you can just download Ubuntu.iso and run it"
- Thierry: Why even Linux?
- Daniel:
- could be anything else, even Zephyr
- https://antmicro.com/blog/2023/06/zephyr-as-bootloader-for-linux-on-riscv/
- Thierry
- Why replacing UEFI DXEs by something else?
- UEFI bloated by IBV/ODM choices (most of DXEs are there for unknown reasons by IBV/ODM (ref needed)
- [Trammell Hudson, 33C3: Bringing Linux back to server boot ROMs with NERF and Heads ("Let Linux do it")](https://media.ccc.de/v/34c3-9056-bringing_linux_back_to_server_boot_roms_with_nerf_and_heads)
- Firmware devs = linux devs (community + expertise)
- How to replace UEFI DXEs by something else?
- Fiano can remove hundred of DXEs (but requires hundred of hours of DXE removal + reboot to see if causes regressions: [OCP 2018, Ron Minnich - Firmware, the last frontier: Open System Firmware (OSF))](https://www.youtube.com/watch?v=4a1QHQ76it8)
- UEFI: 3 possible entry points for Linuxboot : easy -> hard
- UEFI Shell [Ron mistook it for DxeShell] (easy) : direct replacement with Linux
- BdsDxe (medium): replace with linux FFS, depends on how well BdsDxe follows UEFI rules)
- DXECore replacement (hard) : linux needs to run DXEs
- Daniel: other binaries can be replaced; I've done that for the X270
- `utk x270.rom replace_pe32 Setup bzImage save x270_mod.rom`
- x86 : Why wanting to replace UEFI altogether?
- SMMSTORE: A SMM backed configuration store that persist across reboot
- Why replacing UEFI by coreboot
- No need of fiano to remove DXE
- SMM on a diet
- UEFI has SMMSTORE, which runs and can be modified through SMI (SMM)
- This is why LinuxbootSMM is under development
- Dennis:
- Average person doesn't care about how a system boots.
- LinuxBoot is for people that *do* care and have specific needs.
- E.g. things UEFI does not fulfill.

## 2025-05-12

### Participants

- Richard Hughes (fwupd/LVFS)
- Dennis Marttinen (Racklet)
- Thierry Laurion (Heads)
- Philip Molloy (LinuxBoot TSC)
- Daniel Maslowski (LinuxBoot TSC)

### Topics

- Richard: SBoM
- Daniel: where should the line be drawn?
- Richard: focus on core things that provide attack surface, e.g. image parsers
- Daniel: single reference can suffice for open source distros
- Richard: multiple SBoMs possible, e.g. per boot chain component vs one global SBoM
- as part of build process, upload to LVFS
- Daniel: or attach to GitHub?
- there needs to be a way to obtain the SBoM data (from the OS?)
- Richard: Partitioning, A/B updates
- Daniel: even first stage?
- Philip: some mask ROMs have multi-slot support for first code, need
vendor/SoC specific headers
- hardware ID
- Dennis: for same hardware but different firmware, how to identify?
- Richard's recommendation: change DMI data
- device trees
- Philip: DTs in Linux upstreamed maintained at high quality, with more rigor
- funding matters
- Philip: gotta do PoC first, gain traction, then approach e.g. Rockchip
- Thierry: next NLNet funding round application deadline is June 1, 2025
- target platforms
- Philip and Daniel want to focus on SBCs, same for Dennis for Racklet
- Thierry sees interest in servers, such as older OCP hardware

## 2025-04-28

### Participants

- Chiao Yang ()
- Dennis Marttinen (Racklet)
- Philip Molloy (LinuxBoot TSC)
- Daniel Maslowski (LinuxBoot TSC)

### Topics

- another introduction round, since we have some new faces
- "awesome" list for LinuxBoot
- Philip: Khadas and Radxa have their own firmware projects
- https://docs.khadas.com/software/oowow/getting-started
- https://docs.radxa.com/en/roobi
- Daniel: want `fastboot` in LinuxBoot
- Dennis: role of LinuxBoot group? Unification?
- Daniel: clarify need for built-in modules / static kernel vs modules
- What can be modules? LinuxBoot kernel would need to load them.
- Daniel: prebuilt rootfs CPIOs for people to try out
- retire https://github.com/linuxboot/u-root-builder ?
- https://github.com/u-root/u-root-distro is a successor, needs fixups
- Dennis: meaning of "LinuxBoot compliance"?
- kexec loosely defined
- verification steps?
- Philip: non-defined interface is also a benefit; flexibility?
- make kexec debugging easier
- Dennis: provide clarity regarding boot protocols, features, subsets thereof
etc
- leave the choice to the distro whether they want ACPI/UEFI or not (!)
- e.g. Windows needs WMI

## 2025-04-14

This is our first common meeting to reestablish a LinuxBoot community.

### Participants

- Ziang Wang (ByteDance)
- Thierry Laurion (Heads)
- Jeremy Kerr (Petitboot)
- Jean-Marie Verdun (HPE)
- Philip Molloy (LinuxBoot TSC)
- Daniel Maslowski (LinuxBoot TSC)

### Topics

- getting to know everyone and our backgrounds
- how everyone implements LinuxBoot, respectively