For some reason, 32-bit U-Boot only works when executed from
GRUB, but not SeaBIOS; 64-bit U-Boot only works from SeaBIOS!
This will have to be investigated. Standalone U-Boot, where
U-Boot is the primary payload, has not yet been tested in
Libreboot, and will not be provided for some time due to
stability concerns. More testing is needed!
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's important that we maintain realistic expectations.
x86 u-boot is not yet fully stable, so mark it as such.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Currently seems to stall when booted from the GRUB
payload, but works when booted from the SeaBIOS menu.
I also tested it as a standalone payload and it seems
to boot. Will test on hardware next, and start adding
it to more mainboards.
Signed-off-by: Leah Rowe <leah@libreboot.org>
NOTE: Support added for xarch target x86_64-elf,
but U-Boot failed to build with this error:
OBJCOPY lib/efi_loader/helloworld.efi
x86_64-elf-objcopy: lib/efi_loader/helloworld_efi.so: invalid bfd target
make[2]: *** [scripts/Makefile.lib:476: lib/efi_loader/helloworld.efi] Error 1
Since I'm building U-Boot for x86_64 *on* an x86-64
host, and since that is currently the recommended type
of machine to use for lbmk development, and since the
other x86 payloads currently don't cross compile anyway,
this is an acceptable compromise for now. This is because
at present, I'm not making U-Boot the primary payload on x86,
instead preferring to chain it from GRUB and SeaBIOS.
The target.cfg file for x86 u-boot shows xarch/xtree commented.
Uncomment these to compile on crossgcc instead of hostcc.
I mention 64-bit because I initially did this first, but decided
to do 32-bit first. I'll work on the 64-bit one next (SPL).
It's only enabled in QEMU for now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Of note: upstream has made several improvements to memory
management, and several fixes to file systems.
User-friendly change to LUKS: if the passphrase input failed,
the user is prompted again for the correct passphrase, instead
of GRUB just failing. Similar to cryptsetup luksOpen behaviour
under Linux.
This pulls in the following changes from upstream (gnu.org):
* b53ec06a1 util/grub-mkrescue: Check existence of option arguments
* ab9fe8030 loader/efi/fdt: Add fdtdump command to access device tree
* 0cfec355d osdep/devmapper/getroot: Unmark 2 strings for translation
* f171122f0 loader/emu/linux: Fix determination of program name
* 828717833 disk/cryptodisk: Fix translatable message
* 9a2134a70 tests: Add test for ZFS zstd
* f96df6fe9 fs/zfs/zfs: Add support for zstd compression
* 55d35d628 kern/efi/mm: Detect calls to grub_efi_drop_alloc() with wrong page counts
* 61f1d0a61 kern/efi/mm: Change grub_efi_allocate_pages_real() to call semantically correct free function
* dc0a3a27d kern/efi/mm: Change grub_efi_mm_add_regions() to keep track of map allocation size
* b990df0be tests/util/grub-fs-tester: Fix EROFS label tests in grub-fs-tester
* d41c64811 tests: Switch to requiring exfatprogs from exfat-utils
* c1ee4da6a tests/util/grub-shell-luks-tester: Fix detached header test getting wrong header path
* c22e052fe tests/util/grub-shell: Add flexibility in QEMU firmware handling
* d2fc9dfcd tests/util/grub-shell: Use pflash instead of -bios to load UEFI firmware
* 88a7e64c2 tests/util/grub-shell: Print gdbinfo if on EFI platform
* b8d29f114 configure: Add Debian/Ubuntu DejaVu font path
* 13b315c0a term/ns8250-spcr: Add one more 16550 debug type
* 8abec8e15 loader/i386/multiboot_mbi: Fix handling of errors in broken aout-kludge
* d35ff2251 net/drivers/ieee1275/ofnet: Remove 200 ms timeout in get_card_packet() to reduce input latency
* 86df79275 commands/efi/tpm: Re-enable measurements on confidential computing platforms
* 0b4d01794 util/grub-mkpasswd-pbkdf2: Simplify the main function implementation
* fa36f6376 kern/ieee1275/init: Add IEEE 1275 Radix support for KVM on Power
* c464f1ec3 fs/zfs/zfs: Mark vdev_zaps_v2 and head_errlog as supported
* 2ffc14ba9 types: Add missing casts in compile-time byteswaps
* c6ac49120 font: Add Fedora-specific font paths
* 5e8989e4e fs/bfs: Fix improper grub_free() on non-existing files
* c806e4dc8 io/gzio: Properly init a table
* 243682baa io/gzio: Abort early when get_byte() reads nothing
* bb65d81fe cli_lock: Add build option to block command line interface
* 56e58828c fs/erofs: Add tests for EROFS in grub-fs-tester
* 9d603061a fs/erofs: Add support for the EROFS
* 1ba39de62 safemath: Add ALIGN_UP_OVF() which checks for an overflow
* d291449ba docs: Fix spelling mistakes
* 6cc2e4481 util/grub.d/00_header.in: Quote background image pathname in output
* f456add5f disk/lvm: GRUB fails to detect LVM volumes due to an incorrect computation of mda_end
* 386b59ddb disk/cryptodisk: Allow user to retry failed passphrase
* 99b4c0c38 disk/mdraid1x_linux: Prevent infinite recursion
* b272ed230 efi: Fix stack protector issues
* 6744840b1 build: Track explicit module dependencies in Makefile.core.def
Signed-off-by: Leah Rowe <leah@libreboot.org>
instead, make it a helper function, defined in target.cfg
this means that we can also do the same with other projects
in the future, and it is expected that we will have to.
these helper functions are used in cases where we want
additional actions to be performed.
actually, the helper could be anything. for example, you
could write:
mkhelper="./build foo bar"
and it would do that (at the point of execution, PWD
is the root directory of the build system)
Signed-off-by: Leah Rowe <leah@libreboot.org>
don't hardcode the check based on whether the current
project is grub. instead, define "btype" in target.cfg
if unset, we assume kconfig and permit kconfig commands
e.g. make menuconfig, make silentoldconfig, etc
this is to avoid the deadliest of sins:
project-specific hacks
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is bloat, because it's something the user can already
do at runtime configuration anyway.
set it to a reasonable default of 8 seconds instead of 5,
and don't honour the timeout variable in target.cfg.
this will be documented in the next release.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the background is only a few kb. the whole rationale
before was to limit the space used in memdisk, but this
decision was made when the background was much bigger;
it has since been optimised greatly, and the grub modules
were heavily reduce, so it should be safe.
grub's memdisk breaks when you add too much data to it.
as part of simplifying the rest of lbmk, this change removes
some more bloat from the rest of lbmk. handling this in the
memdisk is much simpler than handling it with cbfstool.
Signed-off-by: Leah Rowe <leah@libreboot.org>
remove nvme support from the "default" grub tree
now there are three trees:
* default: no xhci or nvme patches
* nvme: contains nvme support
* xhci: contains xhci and nvme support
this is in case a bug like lbmk issue #216 ever occurs
again, as referenced before during lbmk audit 5
there is no indication that the nvme patch causes any
issues, but after previous experience i want to be sure
Signed-off-by: Leah Rowe <leah@libreboot.org>
certain code checks for build.list, to skip it, for
example in items()
we already use config/data/grub to store grub config data
that applied to all trees
create these directories too:
config/data/coreboot
config/data/u-boot
config/data/seabios
move the respective build.list files in here, and also
to config/data/grub
now multi-tree projects contain, per directory, just the
target.cfg file and the patches directory. this is much
cleaner, because some of the logic can be simplified more
Signed-off-by: Leah Rowe <leah@libreboot.org>
Re-add xHCI only on haswell and broadwell machines, where
they are needed. Otherwise, keep the same GRUB code.
The xHCI patches were removed because they caused issues
on Sandybridge-based Dell Latitude laptops. See:
https://codeberg.org/libreboot/lbmk/issues/216
The issue was not reported elsewhere, including on the
Haswell/Broadwell hardware where they are needed, but the
build system could only build one version of GRUB.
The older machines do not need xHCI patches, because they
either do not have xHCI patches, or work (in GRUB) because
they're in EHCI mode when running the payload.
So, the problem is that we need the xHCI patches for GRUB
on Haswell/Broadwell hardware, but the patches break
Sandybridge hardware, and we only had the one build of GRUB.
To mitigate this problem, the build system now supports
building multiple revisions of GRUB, with different patches,
and each given coreboot target can say which GRUB tree to use
by setting this in target.cfg:
grubtree="xhci"
In the above example, the "xhci" tree would be used. Some
generic GRUB config has been moved to config/data/grub/
and config/grub/ now looks like config/coreboot/ - also,
the grub.cfg file (named "payload" in each tree) is copied
to the GRUB source tree as ".config", then added to GRUB's
memdisk in the same way, as grub.cfg.
Several other design changes had to be made because of this:
* grub.cfg in memdisk no longer automatically jumps to one
in CBFS, but now shows a menuentry for it if available
* Certain commands in script/trees are disabled for GRUB,
such as *config make commands.
* gnulib is now defined in config/submodule/grub/, instead
of config/git/grub - and this mitigates an existing bug
where downloading gnulib first would make grub no longer
possible to download in lbmk.
The coreboot option CONFIG_FINALIZE_USB_ROUTE_XHCI has been
re-enabled on: Dell OptiPlex 9020 MT, Dell OptiPlex 9020 SFF,
Lenovo ThinkPad T440p and Lenovo ThinkPad W541 - now USB should
work again in GRUB.
The GRUB payload has been re-enabled on HP EliteBook 820 G2.
This change will enable per-board GRUB optimisation in the
future. For example, we hardcode what partitions and LVMs
GRUB scans because * is slow on ICH7-based machines, due
to GRUB's design. On other machines, * is reasonably fast,
for automatically enumerating the list of devices for boot.
Use of * (and other wildcards) could enable our GRUB payload
to automatically boot more distros, with minimal fuss. This
can be done at a later date, in subsequent revisions.
Signed-off-by: Leah Rowe <leah@libreboot.org>
it's very unlikely that someone would use this
directory name nowadays, and i had half a mind
to remove it altogether
Signed-off-by: Leah Rowe <leah@libreboot.org>
in practise, the machines we support don't have
the option of including so many disks; 8 seems like
the most reasonable default. additionally, it's
unreasonable to expect *20 partitions*
this hardcoding is done to avoid using *, which is
slow in grub on some machines (the grub kernel always
re-enumerates the devices during every operation,
without caching any of it)
yet, the hardcoding is also slow; balance it a bit
better by searching fewer permutations, but not so few
that it would likely break a lot of setups
Signed-off-by: Leah Rowe <leah@libreboot.org>
we already supported syslinux but not grub
support grub by scanning for the most common paths,
based on the most popular distros
we don't hardcode this with * because it slows down
the boot, and in practise many distros still use the
same grub.cfg location as in BIOS systems (the EFI
one is often just a link to the BIOS one)
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is a relic from the old days when we didn't
automated the grub.cfg logic as much. these days,
the grub.cfg logic is able to boot almost all distros
without any manual intervention or override.
removing these entries will speed up the boot in general
Signed-off-by: Leah Rowe <leah@libreboot.org>
the path "/boot/EFI" is unnecessary because the ESP
is always a FAT32 partition, so we don't need to
scan it as a subdirectory within a subdirectory.
the ESP is always mounted as its own partition,
FAT32, and EFI/ is always at the root of it
Signed-off-by: Leah Rowe <leah@libreboot.org>
the esp is always a fat32 partition so this makes no sensgrub.cfg: don't scan EFI on btrfs subvols
the esp is always a fat32 partition so this makes no sense
Signed-off-by: Leah Rowe <leah@libreboot.org>
replace variables ahcidev/atadev/nvmedev with a single
one named bootdev
the for loop goes through grub_scan_disk, so now it is
effectively a bootorder configuration
Signed-off-by: Leah Rowe <leah@libreboot.org>
it has always been gpl 3 or later, but it helps to have
the license declaration within the file
there's a copying file anyway. put spdx in the config
Signed-off-by: Leah Rowe <leah@libreboot.org>
Previously, grub_scan_disk could set ata, ahci or "both",
which would make both be tried (ahci first). This worked
when we only dealt with ata and ahci devices, but now we
support nvme devices so the logic is inherently flawed.
Instead, use grub_scan_disk to store the boot order, e.g.:
grub_scan_disk="ahci nvme ata"
grub_scan_disk="nvme ata"
In the first example, it would make GRUB scan ahci first,
then nvme and then ata.
In the secontd example, it would make GRUB scan nvme first,
and then ata.
If "both" is set, or anything other than ahci/ata/nvme,
grub_scan_disk is now changed to "nvme ahci ata".
Actual grub_scan_disk entries in target.cfg files will now
be modified, to match each machine.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Fixes this bug:
https://codeberg.org/libreboot/lbmk/issues/216
Well, fix is the wrong word. We want xHCI ideally.
Mate is working on it as I write this. I've also:
* Disabled CONFIG_FINALIZE_USB_ROUTE_XHCI on Haswell
boards (coreboot)
* Disabled the GRUB payload on HP 820 G2 for now
We will need to re-add the xHCI patches once fixed.
If Mate/we can't fix it, I'll contact Patrick
Rudolph who originally wrote the xHCI patches.
Signed-off-by: Leah Rowe <leah@libreboot.org>
see:
https://github.com/9elements/grub/commits/xhci-module-upstreaming-squash_v4/
grub only supports xhci on bios/uefi targets, but not coreboot.
some newer machines don't have ps/2 controllers, and boot in a
way where ehci isn't available at startup; the controller can't
be used by ehci code, there must be xhci support.
the code is from Patrick Rudolph working on behalf of 9elements.
the code was also sent here for review:
https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00111.html
however, upstream never merged these patches. libreboot will have
to maintain these from now on. the patches have been rebased for
use with grub 2.12.
Signed-off-by: Leah Rowe <leah@libreboot.org>
There is no need to add multiple keymap files, because
GRUB can load keymaps from CBFS. The current build logic
is designed to avoid building multiple GRUB binaries,
which are expensive computationally because each one
would then have to be compressed for each board.
This patch provides the best of both worlds: less space
used in flash like in the old lbmk design (1 keymap per
board), but retaining the current build speeds and therefore
not re-introducing the slowness of lbmk's previous GRUB
build logic.
The grub.cfg file has been modified, accordingly. It now
only loads a keymap.gkb file from CBFS, by default. It does
this, only if that file exists; if not, GRUB already defaults
to US Qwerty layout anyway.
ALSO: compress all keymap gkb files with xz -6
GRUB automatically decompresses files when accessed.
This results in about 2KB of flash space saved in CBFS.
Here is real-world data, showing the increased flash space:
< fallback/payload 0x3eb80 simple elf 548821 none
< keymap.cfg 0xc4bc0 raw 16 none
< (empty) 0xc4c00 null 11633316 none
---
> fallback/payload 0x3eb80 simple elf 546787 none
> keymap.gkb 0xc43c0 raw 344 none
> (empty) 0xc4540 null 11635044 none
This was taken by diffing the cbfstool "print" output,
both before and after. The *after* result is with this change.
11633316. In this example, 1728 bytes have been saved. Therefore,
with compression taken into account, this patch saves about 1.7KB
of space in CBFS.
This change means that lbmk can now scale to support hundreds
of keymaps, without increasing the amount of flash space used,
in each given image. Since the keymap files are compressed in
lbmk.git, in advance, we spend no additional time on compression
at build time. The resulting change in build speed in negligible.
Adding your own keymap.gkb file was already possible, for changing
the keymap in libreboot images, if you didn't want to change the
memdisk (and thus re-compile grub.elf). Now, this is the default
behaviour, and the only way to do it. It's much more efficient.
The original keymap files can be restored, by running unxz.
Signed-off-by: Leah Rowe <leah@libreboot.org>
this is now used in grub, for the FS_PAYLOAD_MODULES
option in the make command
lbmk should generalise as much logic as possible. in
some parts of it, logic is hurrently hardcoded, specific
to a given project that lbmk uses, but lbmk is essentially
a source-based package manager, like what you might find
on a small linux distro, so we need to try to
be as generic as possible.
lbmk is the "build system of build systems", so it has to
work generically with as many of them as possible
Signed-off-by: Leah Rowe <leah@libreboot.org>
at present, the bootstrap and configure script is only
directly executed for grub, because grub is the only
project that uses them in lbmk
however, when i start adding linuxboot support, i will
have to start building a lot of projects, some of which
make use autoconf and bootstrap scripts
e.g.
./bootstrap --foo
./configure --bar
the "bootstrap" script is often used on GNU programs,
because they like to over-engineer absolutely everything
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe