From owner-freebsd-current@freebsd.org Tue May 28 14:22:13 2019 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AED44159E260; Tue, 28 May 2019 14:22:13 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2154F83557; Tue, 28 May 2019 14:22:12 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id x4SEM2wH015969; Tue, 28 May 2019 07:22:02 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id x4SEM2fR015968; Tue, 28 May 2019 07:22:02 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201905281422.x4SEM2fR015968@gndrsh.dnsmgr.net> Subject: Re: FreeBSD and Coreboot In-Reply-To: To: Eric McCorkle Date: Tue, 28 May 2019 07:22:02 -0700 (PDT) CC: Warner Losh , Nathan Whitehorn , FreeBSD Hackers , FreeBSD Current , =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 2154F83557 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.92 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.92)[-0.923,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 14:22:13 -0000 > On 5/28/19 12:46 AM, Warner Losh wrote: > > > > > > On Mon, May 27, 2019, 10:44 PM Nathan Whitehorn > > wrote: > > > > > > > > On 2019-05-27 19:14, Warner Losh wrote: > > > On Mon, May 27, 2019, 7:18 PM Nathan Whitehorn > > > > > > 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 > > > > > >> 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