Date: Tue, 28 May 2019 07:22:02 -0700 (PDT) From: "Rodney W. Grimes" <freebsd-rwg@gndrsh.dnsmgr.net> To: Eric McCorkle <eric@metricspace.net> Cc: Warner Losh <imp@bsdimp.com>, Nathan Whitehorn <nwhitehorn@freebsd.org>, FreeBSD Hackers <freebsd-hackers@freebsd.org>, FreeBSD Current <freebsd-current@freebsd.org>, =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= <trasz@freebsd.org> Subject: Re: FreeBSD and Coreboot Message-ID: <201905281422.x4SEM2fR015968@gndrsh.dnsmgr.net> In-Reply-To: <f65401e3-40ea-fd43-07f2-13b9663c8cd9@metricspace.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 5/28/19 12:46 AM, Warner Losh wrote: > > > > > > On Mon, May 27, 2019, 10:44 PM Nathan Whitehorn <nwhitehorn@freebsd.org > > <mailto:nwhitehorn@freebsd.org>> wrote: > > > > > > > > On 2019-05-27 19:14, Warner Losh wrote: > > > On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn > > <nwhitehorn@freebsd.org <mailto:nwhitehorn@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@metricspace.net <mailto:eric@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@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201905281422.x4SEM2fR015968>