> > No EFI_CAPSULE_LOADER needed, not Linux specific. EFI-aware OS' > are also aware of the EFI system partition, FWIW. And with the > Boot Loader Specification[3], we already try to make use of it > beyond UEFI. > > Modeling things with files is a good choice by the Linux kernel > developers. But the overall design seems to miss that the boot- > loaders are file-aware too! We already have a ubiquitous mecha- > nism to pass files (usually the kernel) to the firmware. Often > also to validate their authenticity (secure boot).
So basically instead of a runtime service, getting a file from a disk at boottime to update the flash? I think this is indeed dramatically simpler on both the firmware side as the OS side. I suppose this only works when there is a boot disk, but then again servers tend to have a BMC which takes care of firmware updates anyway. So this seems like a good trade-off. Not sure about exact considerations which went into the decision other than > on-disk capsules already working in EDK2, but use of in-RAM capsules looks > like a cleaner design to me: > - no file-system writes by an OS > - no file-system writes by firmware to remove a processed capsule (not > sure I want to trust EDK2 drivers doing that) > - the capsule can be verified at the moment it's offered to the > firmware, not in the middle of a boot - File system writes are way simpler than supporting an UEFI runtime service. - Does the firmware need to remove the capsule? Can't fwupd do that once it detects a successful update? What does the spec say about this? - Doing things at runtime is against the coreboot philosophy. If doing something at boottime is a reasonable option to avoid needing a runtime I think this is the way to go. I generally like Nico's proposal. No new coreboot-payload interaction (depends on the design). Less runtime. Reusing existing spec and tooling. This is the way to go in my opinion. Arthur
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
