[Bug 217512] boot2 is unable to load kernel directly

[Bruce Evans]

On Fri, 3 Mar 2017 "a bug that doesn't want replies"@freebsd.org wrote:

> --- Comment #2 from Mark Willson <mark at uncommon.com> ---
> As I understand the theory of  boot0/boot1/boot2/loader operations, boot2
> should have all the registers, bios calls, and setup correct for direct
> execution of the kernel. Assuming, of course, that the kernel has everything
> that it needs compiled into the kernel [with the exception of kernel modules]
> and does not need any of the modifications or the boot time services, e.g.
> device.hints, loader.conf, etc., that the loader would supply.
>
> Assuming there is no support for AMD64s in boot2 then--

boot2 has the correct amount of special support (none), but the amd64 kernel
always depended on the special support provided by loader.

> 1) there is no support for any 64 bit based CPUs (intel or amd), effectively
> limiting its use for booting directly into the kernel to ancient 32-bit i386
> machines

And modern 32-bit i386 machines.  FreeBSD in i386 mode on modern 64-bit CPUs
runs many small applications about 10% faster than FreeBSD in amd64 mode on
the same CPU.

> 2) boot.config, for the same purposes, will not work

It works to configure boot2, but for booting amd64 kernels that only gets
you as far as pre-selecting a few things including the loader.

I normally use my version of biosboot for boot2.  This also supports
loading kernel.config into memory for use by the kernel.  kernel.config
is used by FreeBSD-4 and earlier i386 kernels to hold configuration
info.  loader does this wrong in a different way by providing
unstructured configuration info in environment variables.  The structured
info in kernel.config at least allows error detection for typos.  This
feature is broken (not supported) in boot2.

> 3) boot2 cannot be used to bypass loader problems on 64 bit machines

It can be used to boot a better 32-bit kernel.  This is not a bad method
to use generally.  Instead of booting through loader, boot through a 32-
bit kernel to configure for a 64-bit kernel if you must use a 64-bit
kernel for some reason.  In the 32-bit kernel, you can use normal tools
with usable UIs, and never see loader or its unusable UI (loader still
doesn't even have history for its line editor).  The loader step is
still unfortunately necessary to get from the 32-bit kernel to the 64-bit
one, and 32-bit kernel takes a bit longer to boot than loader.

> 4) boot2 can only be used to look at or changing certain temporary variables,
> select a different loader (very unlikely), or to fiddle with video/serial
> console options

It takes editing the source code to change console options.  I often use
boot2 to select a loader at all when booting an i386 kernel, to change my
default of not using loader.  Usually there is one in /boot on the default
drive/partition.  I often override the default for the drive/partition,
but rarely to select a different loader.

> 5) the documentation is in error in a number of places (e.g. handbook, man,
> internals) and needs to note this major limitation so that others don't go down
> rabbit hole as well.
> 
> I did do some additional checking and it appears that you are correct at least
> as far back as FreeBSD 8.x. A similar error/outcome came up on a different
> server/bios/config.

Back to FreeBSD-5 for the first version of amd64.

> I also noted that boot2 does say 'FreeBSD/i386 BOOT' at its prompt (although,
> since i386/amd64 are the core lines for freebsd I've always thought of i386 as
> a subset of AMD64--anything i386 could do amd64 could do better--guess I was
> >wrong).

Could do better, but usually does worse.

> Is it possible that AMD64s *could* work if the appropriate device.hints were
> statically linked in the kernel itself as well as any other "external" required
> setup done by the loader at boot time is compiled in or is there something
> fundamental about the architecture/BIOS support that makes this unlikely?

Nothing fundamental, but it needs to set up page tables as on i386 and
do something to replace configuration via vm86.  amd64 already has an
x86 emulator which is used instead of vm86 for at least syscons video
BIOS calls.  It seems to work perfectly.  i386 also uses non-vm86 BIOS
calls which are more fragile.  Perhaps these could use the emulator and
work on amd64 too, and the early vm86 calls on i386 could be changed to
use the emulator, then used on amd64 too.

Support for booting with boot2 often gets broken on i386.  I fixed it
in -current last year, and it still works in FreeBSD-[7-9] (probably
also in [5-6], but it is still broken in [9-10] by making early vm86
calls before vm86 is initialized.  vm86 BIOS calls, non-vm86 BIOS calls
and the emulator take large complicated code but are still better than
than using loader to make the calls.  amd64 needed the emulator because
BIOS calls are needed for acpi suspend/resume, and using the loader at
suspend/resume time is just impossible.  So amd64 no longer has the
excuse that vm86 doesn't work for requiring loader.

Suspend/resume doesn't actually work on most of my systems because the
video BIOS calls which are the main ones done are also the ones that
don't work with modern Intel graphics.  Specifically, the one to restore
a saved SVGA state doesn't work to turn video back on for resume.

Bruce