loader: Change this BIOS tradeoff: Add back zip and use text only

After talking with a number of people about the removal of some things
to make the loader fit, readjust things a little.

Add back G

loader: Change this BIOS tradeoff: Add back zip and use text only

After talking with a number of people about the removal of some things
to make the loader fit, readjust things a little.

Add back GZIP and BZIP2 compression support. Many of the downstream MFC
packaging systems depend on this. This adds back 20k to the size of the
loader.

Make the boot loader text-only by default. This saves 40k in size. Net,
we're 20k smaller. The graphics loader for BIOS is less useful than the
zip functionality: You can still boot w/a text only one it and you can
build a custom one if you really want it. It's also the default we use
for dual console.

This should be merged back into stable/14 and stable/13 so it's in the
next release for each of these. That way we have only one release (13.4)
with the other defaults.

MFC After: 3 days
Sponsored by: Netflix
Reviewed by: olce, rgrimes, emaste
Differential Revision: https://reviews.freebsd.org/D47203

show more ...

loader: Minor comentary tweak

Reword slightly to cleanup awkward constructs.

Sponsored by: Netflix

stand: Reduce limit to 500k for x86 loader

The largest loader that works for PXE boot is about 500k. PXE needs low
memory for packets and other driver state, so the largest safe size for
the loader

stand: Reduce limit to 500k for x86 loader

The largest loader that works for PXE boot is about 500k. PXE needs low
memory for packets and other driver state, so the largest safe size for
the loader is about 500k. Reduce the size from 560k to 500k so we don't
accidentally break PXE in the future.

Add a comment for people with special needs. If you control the
hardware, it can be safe to have boot loaders as large as 580k or 600k
in some cases. Since the BIOS loader is becoming more and more of a
legacy item, the build variable LOADERSIZE isn't documented. This change
doesn't change that: there's been little demand for this documentation
and in general, users shouldn't change it lightly.

PR: 257018
Sponsored by: Netflix

show more ...

stand: Stop building in fat, ext2fs, gzip and bzip to BIOS /boot/loader

This saves space to allow pxeboot to work again. Users desiring these
features can turn them on for their custom build. While

stand: Stop building in fat, ext2fs, gzip and bzip to BIOS /boot/loader

This saves space to allow pxeboot to work again. Users desiring these
features can turn them on for their custom build. While these are useful
for some specialized applications, they aren't needed to boot the
typical system, and we're low on space.

text data bss dec hex filename
Before: 465866 20740 31612 518218 0x7e84a loader_lua.bin
After: 441535 17484 31092 490111 0x77a7f loader_lua.bin

Savings: 28,107 bytes

Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D42416

show more ...

loader: Make MK_LOADER_BIOS_TEXTONLY work

Select between text-only and graphical frame buffer consoles for the
BIOS boot loader. Pull one or the other in with #ifdef in conf.c. Add
gfx_bios.c for th

loader: Make MK_LOADER_BIOS_TEXTONLY work

Select between text-only and graphical frame buffer consoles for the
BIOS boot loader. Pull one or the other in with #ifdef in conf.c. Add
gfx_bios.c for the few routines that are needed for the BIOS support of
gfx. These are stubbed out for text-only mode. Move bi_load_vbe_data
here since it's only used for the graphical frame buffer.

Note: This setup also allows us to build multiple BIOS loaders if we
have to, some with text-only and some graphical. We don't do this today.
We may be forced to turn this on in the future if ZFS keeps growing.

The size savings is 41k, which helps a lot with some of our users that
want to enable more options in the BIOS boot loader than are normally
safe to do, and they don't need graphics.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D43917

show more ...

loader: Bump the limit to 560,000 bytes for BIOS loader

Further experience suggests we do not need as much margin. This was
mistakenly bumped to 570,000 in a prior commit, so this undoes that.

Spon

loader: Bump the limit to 560,000 bytes for BIOS loader

Further experience suggests we do not need as much margin. This was
mistakenly bumped to 570,000 in a prior commit, so this undoes that.

Sponsored by: Netflix

show more ...

kboot: Add our own lua bindings

Create a small wrapper around the new flua hash module so we can use it
here too. There's no 4th bindings, nor will they be created.

Sponsored by: Netflix
Different

kboot: Add our own lua bindings

Create a small wrapper around the new flua hash module so we can use it
here too. There's no 4th bindings, nor will they be created.

Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D43874

show more ...

Remove $FreeBSD$: one-line sh pattern

Remove /^\s*#[#!]?\s*\$FreeBSD\$.*$\n/

loader: always install help files

Address two issues with current help file logic:

The existing condition prevents the common help file from being
installed when there are no additional help files

loader: always install help files

Address two issues with current help file logic:

The existing condition prevents the common help file from being
installed when there are no additional help files defined. This results
in no loader.help on EFI platforms, for example.

Second, due to the fact that we build and install multiple loader types,
each successive install will clobber the previous loader.help. The
result is that we could lose type-specific commands, or possibly list
them in loaders that do not have such commands.

Instead, give each loader type a uniquely named help file. The EFI
loader will look for /boot/loader.help.efi, userboot will look for
/boot/loader.help.userboot, etc. The interpreter variant has no effect
on which help file is loaded.

This leaves the old /boot/loader.help unused.

Some credit for the final approach goes to Mathieu <sigsys@gmail.com>
for their version of the fix in https://reviews.freebsd.org/D22951.

PR: 267134
Reported by: Daniel O'Connor <darius@dons.net.au>
Reviewed by: imp
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D28591

show more ...

stand: Remove i386-only support fire firewire

Remove support for booting off of firewire, and for having dcons via
firewire in the loader. Kernel support for these things is unchanged.
Discussed on

stand: Remove i386-only support fire firewire

Remove support for booting off of firewire, and for having dcons via
firewire in the loader. Kernel support for these things is unchanged.
Discussed on arch@ and the current state is not working (and the build
was wrong to boot).

Sponsored by: Netflix
Discussed: https://lists.freebsd.org/archives/freebsd-arch/2022-November/000267.html
Reviewed by: kevans, melifaro, emaste
Differential Revision: https://reviews.freebsd.org/D37334

show more ...

stand: Fix a couple of comment typos in f8a199f28f9d

The commit message documented it as /etc/src.conf but the comment in the
source mentioned the non-existent /etc/loader.conf.

Fixes: f8a199f28f9d

stand: Fix a couple of comment typos in f8a199f28f9d

The commit message documented it as /etc/src.conf but the comment in the
source mentioned the non-existent /etc/loader.conf.

Fixes: f8a199f28f9d ("stand: Raise limit to 550,000 bytes for loader")

show more ...

stand: Raise limit to 550,000 bytes for loader

Raise the limit for /boot/loader to be 550k. The IBM PC imposes a limit
of 640k of RAM below 1MB, which is needed for real mode calls. BTX takes
40k of

stand: Raise limit to 550,000 bytes for loader

Raise the limit for /boot/loader to be 550k. The IBM PC imposes a limit
of 640k of RAM below 1MB, which is needed for real mode calls. BTX takes
40k of that. The BIOS takes some amount (25k seems a good "99% take less
than or equal to this" estimate for that, though some systems consume
more). Most typical setups need 25k of stack. This leaves 550k for
code. We set the limit to 550,000 which gives about an extra 13,000
bytes of buffer for machines that whose setups use a little more stack
or whose BIOS reserves a bit more...

Add this derivation in the Makefile. Also recommend setting LOADERSIZE
lower in /etc/src.conf when the loader has to run on a system whose BIOS
takes up more space, or for a complex setup. Add a recipe for how to
find how much RAM your BIOS uses as well (thanks to jhb@ for the
trick). Network cards that boot via PXE and HBAs with their BIOS enabled
are known to be large consumers of lomem space.

Sponsored by: Netflix
Reviewed by: jhb
Differential Revision: https://reviews.freebsd.org/D36152

show more ...

stand: Go back to a.out format for /boot/loader

Turns out there's two hidden a.out dependencies. pxeldr.S assumes it has
access to the a.out header from /boot/loader and cdboot.S assumes that
/boot/

stand: Go back to a.out format for /boot/loader

Turns out there's two hidden a.out dependencies. pxeldr.S assumes it has
access to the a.out header from /boot/loader and cdboot.S assumes that
/boot/loader is also a.out and doesn't use boot2.

So, go back to making a.out files for these and adjust the size checks
to use ls, but we only need to check loader.bin. Trim the size we check
against by 2,000. The difference in size between loader and loader.bin
is about 3000 bytes, but clang15 produces binaries that are a smidge
bigger so we need to relax the check just a little and accept some
additional risk for the moment.

Add some comments to loader's Makefile about this.

Sponsored by: Netflix
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D36142

show more ...

stand: Make BIOS loader size limits settable

It's sometimes desirable to override the size limit: It's a soft limit
and there are times we exceed the limit by just a little bit and don't
want the bu

stand: Make BIOS loader size limits settable

It's sometimes desirable to override the size limit: It's a soft limit
and there are times we exceed the limit by just a little bit and don't
want the build to fail (or we are hitting runtime failures below the
510,000 byte limit).

Sponsored by: Netflix

show more ...

stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr

The BIOS method of booting imposes an absolute limit of 640k for the
size of the program being run due to btx. In practice, this me

stand: impose 510,000 byte limit for /boot/loader and /boot/pxeldr

The BIOS method of booting imposes an absolute limit of 640k for the
size of the program being run due to btx. In practice, this means that
programs larger than about 500kiB will fail in odd ways as the stack /
heap will overflow.

Pick 510,000 as the cutoff line semi-arbitrarily. loader_lua is now
almost too big and we want to break the build when it crosses this
threshold. In my experience, below 500,000 always works, above 520,000
always seems to fail with things getting bad somewhere between 512,000
to 515,000. 510,000 is as close to the line as I think we can go, though
experience may dictate we need to lower this in the future.

This is at-best a stop-breakage until we have a better way to subset the
boot loader for BIOS booting to allow better, more fined-tuned
/boot/loaders for the many different environments they have to run
in. This likely means we'll have a graphical loader than understands a
few filesystmes for installation, and a non-graphical loader that
understands the most filesystems possible for everything else in the
future. Our build infrastructure needs some work before we can do that,
however.

At this late date, it likely isn't worth the efforts to move parts of
the loader into high memory. There's a number of assumptions about where
the stack is, where buffers reside, etc that are fulfilled when it lives
in the first 640k that would need bounce buffers and/or other counter
measures if we were to split it up. All BIOS calls are done in 16-bit
mode with SEG:OFF addresses, requiring them to be in the first 640k of
RAM. And nearly all machines in the last decade can boot with UEFI
(though there's some exceptions, so it isn't worth killing outright
yet).

Sponsored by: Netflix
Reviewed by: kevans
Differential Revision: https://reviews.freebsd.org/D36129

show more ...

stand: i386/amd64: Always use elf format for /boot/loader and pxeldr

The first level boot blocks have understood how to load ELF code since
1999. Switch /boot/loader and /boot/pxeldr over to being E

stand: i386/amd64: Always use elf format for /boot/loader and pxeldr

The first level boot blocks have understood how to load ELF code since
1999. Switch /boot/loader and /boot/pxeldr over to being ELF format so
that in-tree tools can examine them more closely. In addition, one
could, in theory, now have a 'lo-mem' and a 'hi-mem' segment (though a
lot of work would need to be done with bounce buffers, btx, code segment
marking, etc for an arrangement like that to work).

As far as I can tell, this is the last a.out binary in the tree. There
are several raw binaries left, but everything else is ELF.

Reviewed by: emaste, kevans
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D36130

show more ...

i386 loaders: avoid lld 13 garbage collecting linker sets

Because lld 13 and higher default to garbage collecting start/stop
symbols when using --gc-sections, the linker sets used in the i386 boot
l

i386 loaders: avoid lld 13 garbage collecting linker sets

Because lld 13 and higher default to garbage collecting start/stop
symbols when using --gc-sections, the linker sets used in the i386 boot
loaders will disappear. This leads to the loaders not recognizing any
commands, and failure to boot.

Until we have a good set of linker scripts for the loaders, work around
it by disabling the start-stop-gc feature.

MFC after: 1 week

show more ...

type: becauce -> because

Noticed by: Piotr P. Stefaniak
Sponsored by: Netflix

boot: fix OBJS to not include BTX's crt0.o

According to comments in the Makefile, to make pxeboot work we need to
have crt0.o first. This is needed because the simplified loader in
pxeboot assumes t

boot: fix OBJS to not include BTX's crt0.o

According to comments in the Makefile, to make pxeboot work we need to
have crt0.o first. This is needed because the simplified loader in
pxeboot assumes that the startup code is at offset 0 in this binary. In
normal booting, the start address can be obtained from headers of the
binary, but since pxeboot encodes this as a pure binary, it has no way
of knowing where that is and assumes 0. Added comments to that effect
in the Makefile.

We've done this by adding it to OBJS before all the other .o's are
added. However, there's a problem. This also adds it to the CLEANFILES
variable, which causes it to be removed from multiple places. The
dependencies may also cause it to be re-built at a time that's after
boot2 is built. This causes installs to fail because at install time
boot2 is considered to be out of date and the programs to rebuild it are
no longer in the path.

Cope with this problem by just adding it to LDFLAGS instead.

Glanced at by: kevans ("I thought that went in ages ago")
Sponsored by: Netflix
Differential Revision: https://reviews.freebsd.org/D28876

show more ...

loader: create built in font from bold font face

We did replace full version of default font 8x16v with bold, also
use bold version for built in font.

loader: implement framebuffer console

Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size

loader: implement framebuffer console

Draw console on efi.
Add vbe framebuffer for BIOS loader (vbe off, vbe on, vbe list,
vbe set xxx).
autoload font (/boot/fonts) based on resolution and font size.
Add command loadfont (set font by file) and
variable screen.font (set font by size). Pass loaded font to kernel.

Export variables:
screen.height
screen.width
screen.depth

Add gfx primitives to draw the screen and put png image on the screen.
Rework menu draw to iterate list of consoles to enamble device specific
output.

Probably something else I forgot...

Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D27420

show more ...

loader: zfs should support bootonce an nextboot

bootonce feature is temporary, one time boot, activated by
"bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag.

By default, t

loader: zfs should support bootonce an nextboot

bootonce feature is temporary, one time boot, activated by
"bectl activate -t BE", "bectl activate -T BE" will reset the bootonce flag.

By default, the bootonce setting is reset on attempt to boot and the next
boot will use previously active BE.

By setting zfs_bootonce_activate="YES" in rc.conf, the bootonce BE will
be set permanently active.

bootonce dataset name is recorded in boot pool labels, bootenv area.

in case of nextboot, the nextboot_enable boolean variable is recorded in
freebsd:nvstore nvlist, also stored in boot pool label bootenv area.
On boot, the loader will process /boot/nextboot.conf if nextboot_enable
is "YES", and will set nextboot_enable to "NO", preventing /boot/nextboot.conf
processing on next boot.

bootonce and nextboot features are usable in both UEFI and BIOS boot.

To use bootonce/nextboot features, the boot loader needs to be updated on disk;
if loader.efi is stored on ESP, then ESP needs to be updated and
for BIOS boot, stage2 (zfsboot or gptzfsboot) needs to be updated
(gpart or other tools).

At this time, only lua loader is updated.

Sponsored by: Netflix, Klara Inc.
Differential Revision: https://reviews.freebsd.org/D25512

show more ...

Merge ^/head r364082 through r364250.

MFH

Sponsored by: Rubicon Communications, LLC (netgate.com)

Allow overriding the tool used for stripping binaries

Since the make variable STRIP is already used for other purposes, this
uses STRIPBIN (which is also used for the same purpose by install(1).
Thi

Allow overriding the tool used for stripping binaries

Since the make variable STRIP is already used for other purposes, this
uses STRIPBIN (which is also used for the same purpose by install(1).
This allows using LLVM objcopy to strip binaries instead of the in-tree
elftoolchain objcopy. We make use of this in CheriBSD since passing
binaries generated by our toolchain to elftoolchain strip sometimes results
in assertion failures.

This allows working around https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=248516
by specifying STRIPBIN=/path/to/llvm-strip

Obtained from: CheriBSD
Reviewed By: emaste, brooks
Differential Revision: https://reviews.freebsd.org/D25988

show more ...