FreeBSD and Coreboot
Rodney W. Grimes
freebsd-rwg at gndrsh.dnsmgr.net
Tue May 28 14:22:13 UTC 2019
> 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
More information about the freebsd-current
mailing list