On 2019-05-27 15:50, Eric McCorkle wrote: > On 5/27/19 5:53 PM, Edward Napierala wrote: >> On Mon, 27 May 2019 at 16:14, Eric McCorkle <e...@metricspace.net> wrote: >> >> [..] >> >>> My plan is roughly this: >>> >>> * Refurbish the GRUB port, get it working again in QEMU (possibly on one >>> of my machines), also possibly push a patch to GRUB to use the keybufs >>> mechanism to pass in GELI keys. >>> >>> * Get coreboot with GRUB/Seabios booting FreeBSD in QEMU >>> >>> * Possibly create a coreboot port (uncertain how this would work, since >>> Coreboot has its own extensive config menu) >>> >>> * Hold my breath and test it out on real hardware (I have a Librem 13 r1 >>> for this purpose) >>> >>> * Possibly try getting the FreeBSD kernel to work as a coreboot payload. >> Out of curiosity - why the kernel and not loader(8)? >> > If I understand coreboot correctly, loader would have to directly > manipulate devices _without a BIOS_. That is, it would have to have an > entire device detection/interface layer, which I don't believe is the > case today. > > At least in the EFI case, loader is talking through the system's EFI > implementation, which takes care of all that for you. BIOS works in a > similar way. My sense is getting loader to the point where it could be > a coreboot (without Seabios/GRUB/Tianocore) would be quite an undertaking. >
On IBM PowerNV systems, which also don't provide interfaces to a second-stage loader, we just abandoned loader(8). It's way too much work. -Nathan
signature.asc
Description: OpenPGP digital signature
