Re: FreeBSD and Coreboot

On 5/28/19 12:46 AM, Warner Losh wrote:
> 
> 
> On Mon, May 27, 2019, 10:44 PM Nathan Whitehorn <nwhitehorn_at_freebsd.org
> <mailto:nwhitehorn_at_freebsd.org>> wrote:
> 
> 
> 
>     On 2019-05-27 19:14, Warner Losh wrote:
>     > On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn
>     <nwhitehorn_at_freebsd.org <mailto:nwhitehorn_at_freebsd.org>>
>     > wrote:
>     >
>     >>
>     >> 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
>     <eric_at_metricspace.net <mailto:eric_at_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.
>     >>
>     > How do you use tunables and loadable modules?
>     >
>     > Warner
>     >
> 
>     The firmware on PowerNV has a way to write tunables to the device-tree,
>     which we rehydrate into something that looks like it came from loader.
> 
>     We don't usefully support loadable modules at the moment. The firmware
>     can optionally load exactly one file from the boot filesystem and pass
>     it to the kernel (for Linux, the initrd). There are a couple of ways to
>     imagine exploiting this for kernel modules, but all of them are kind of
>     crummy.
> 
> 
> Now that the loader supports a ram disk, we are almost to something
> useful... but yea, almost and crummy often go hand in hand.

This is looking out ahead of my current roadmap, but if you were to do a
kernel as the coreboot payload, there'd need to be some kind of trick to
support ZFS-only systems.

ZFS requires modules, which are typically pre-loaded (and linked) by
loader (or GRUB).  Coreboot has no disk or filesystem or even device
access facilities, however.  It's just "pull an image out of flash, do
the bare essential hardware initialization to get to a C runtime
environment, then jump into the image".

One way around it might be to concatenate the modules and a kernel
together with a kind of mezzanine level that does all the module
linking, then jumps into the kernel.  I suppose you could also build
that functionality into the kernel itself, or perhaps even coreboot.

I suspect there might be some license issues that kept us from being
able to build these modules into the kernel in the first place, though,
and that might affect the choice as well.