From owner-freebsd-hackers@freebsd.org Tue May 28 11:17:29 2019 Return-Path: Delivered-To: freebsd-hackers@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 948DC15BE997; Tue, 28 May 2019 11:17:29 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from mail.metricspace.net (mail.metricspace.net [IPv6:2001:470:1f11:617::107]) by mx1.freebsd.org (Postfix) with ESMTP id B3B897480B; Tue, 28 May 2019 11:17:28 +0000 (UTC) (envelope-from eric@metricspace.net) Received: from [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f] (unknown [IPv6:2001:470:1f11:617:3210:b3ff:fe77:ca3f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: eric) by mail.metricspace.net (Postfix) with ESMTPSA id 4B4F313AC; Tue, 28 May 2019 11:17:28 +0000 (UTC) To: Warner Losh , Nathan Whitehorn Cc: FreeBSD Hackers , FreeBSD Current , =?UTF-8?Q?Edward_Tomasz_Napiera=c5=82a?= References: <4a6b0f1e-64ec-6b83-b43b-f9791ec8428f@metricspace.net> <1452db0c-1210-3230-c044-bc682e7e1745@metricspace.net> <3aa00c6b-2502-ffad-c915-a833292882bd@freebsd.org> <79c249c0-e6b0-a584-ad23-c9a4f57ff3c1@freebsd.org> From: Eric McCorkle Openpgp: preference=signencrypt Autocrypt: addr=eric@metricspace.net; prefer-encrypt=mutual; keydata= mDMEXMXabRYJKwYBBAHaRw8BAQdAJ2yzSUUR7u7H/bLAFOzhPII7vvJ45zQeB60TxyCoio20 JEVyaWMgTWNDb3JrbGUgPGVyaWNAbWV0cmljc3BhY2UubmV0PoiWBBMWCAA+FiEEG/v8wt9b D9+AxsV/6Y4m2LfgVbIFAlzF2m0CGwMFCQHhM4AFCwkIBwIGFQoJCAsCBBYCAwECHgECF4AA CgkQ6Y4m2LfgVbJ9mwD/YpSeQ5F9gpvKFS5Bs5w1Bw7zTOfO7zJQrh9NzDbWtd0BAOSGr/i5 zJer2pAjwambsyU0bhgHNy9IDQ7AGnidIyMHuDgEXMXabRIKKwYBBAGXVQEFAQEHQEBwYuBK iJPJEDtS6hbLgcDSUSbfUNA2rGp3TJ1G+7EqAwEIB4h+BBgWCAAmFiEEG/v8wt9bD9+AxsV/ 6Y4m2LfgVbIFAlzF2m0CGwwFCQHhM4AACgkQ6Y4m2LfgVbJ2kwEAlJj1z3zRJm3mmi6N81by nuwAxk3qcKa67WX2/F3C4soA/iwVuPMnx5RWaoX3i2eKXVNzNwzvTFfeGKxfQBOzMocM Subject: Re: FreeBSD and Coreboot Message-ID: Date: Tue, 28 May 2019 07:17:28 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 May 2019 11:17:29 -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". 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. 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.