Re: FreeBSD and Coreboot

On Mon, May 27, 2019, 10:44 PM Nathan Whitehorn <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>
> > 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>
> >> 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.

Warner

>