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".

ZFS does not "require" modules, you can statically compile both
opensolaris and zfs into your kernel.

> 
> 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.

It is called a statically linked kernel, no modules at all.

> 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.

I do not know of a license issue for US, linux has one due to
incompatibility of a GPL kernel with a CDDL ZFS module, thankfully
we do not have that issue.


-- 
Rod Grimes                                                 rgrimes_at_freebsd.org