| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
new behaviour:
* grub.cfg and grubtest.cfg no longer inserted to cbfs
* grub.cfg in memdisk instead
* grub.cfg in memdisk defers to cbfs/grub.cfg if added
(not added by default, anymore)
* does not defer to grubtest.cfg even if available
* only shows link to grubtest.cfg if available,
as a menuentry item
keymaps:
if /keymap.gkb exists in cbfs, it uses that by default,
but by default this isn't added. instead, it looks for
a file named keymap.cfg and sources that, which then
sets the keymap to one that is located under memdisk.
this file is inserted for each rom, per layout.
if keymap.gkb and keymap.cfg both absent, grub.cfg in
memdisk shall defer to usqwerty as the default keymap
grub_scan_disk: grub.cfg looks for cbfs file "scan.cfg"
and sources that if found, which will be inserted with
the string: set grub_scandisk=setting_goes_here (based
on target.cfg, generated by build/boot/roms automatically).
If no scan.cfg is found, it defaults to "both"
The "background.png" file remains unchanged, and present in
CBFS, used by grub.cfg if present (and it is, by default)
This change actually *saves* space in CBFS, due to compression,
and means that the grub.cfg is now compressed heavily. This
is also safer, because now the user overrides grub.cfg by
adding it, and they can still add grubtest.cfg for testing
first. If they accidentally delete both configs from cbfs,
Libreboot will fall back to the one in memdisk which would
presumably not be deleted.
This also means that lbmk can now more easily be used by
other build systems, that just want the GRUB part to re-use
in their own project. For example, people who want to build
custom coreboot images without using Libreboot's build system.
This change also *speeds* up the build process considerably,
on the parts where ROM images are copied. It's less than half
a second now, whereas previously it took about 30-45 seconds
for ROM images to copy, because of grub.elf being re-added in
each ROM via cbfstool, where compression is used; I believe
the compression part is what caused slowness.
Much, much faster, more versatile builds.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
With this change, about 54KB of compressed space is saved
inside of CBFS, on setups that use the GRUB payload.
The uncompressed saving is about 720KB, but payloads are
compressed inside each coreboot image, so the compressed
saving is much smaller. That 54KB saving means a lot,
especially on small (1MB or smaller) flash sizes.
The following modules were removed:
adler32, afsplitter, aout, archelp, backtrace, blocklist,
bswap_test, cat, cmdline_cat_test, cmosdump, cmostest, cmp,
cmp_test, cpuid, cs5536, ctz_test, date, datehook, datetime,
disk, diskfilter, div, div_test, dm_nv, efiemu, eval,
exfctest, extcmd, file, fshelp, functional_test, gdb,
gettext, gptsync, hashsum, hdparm, hello, hfspluscomp, http,
json, json, ldm, loadenv, macbless, macho, mda_text, morse,
mpi, msdospart, mul_test, net, ntfscomp, offsetio,
part_acorn, part_amiga, part_apple, part_dvh, part_plan,
part_sun, part_sunpc, parttool, pbkdf2, pbkdf2_test, pci,
play, priority_queue, probe, progress, random, rdmsr, read,
relocator, setjmp, setjmp_test, shift_test, signature_test,
sleep, sleep_test, smbios, strtoull_test, terminal,
terminfo, test_blockarg, testload, testspeed, tftp, tga,
time, tr, trig, usbtest, video_bochs, video_cirrus,
videoinfo, videotest, videotest_checksum, wrmsr, xnu_uuid,
xnu_uuid_test
These were retained, but moved to modules instead of
install modules:
geli, udf, ufs1, ufs1_be, ufs2
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
the argon2 patches are now included in grub,
but we need to add it in grub-mkstandalone
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
Patches pulled from:
https://git.nicholasjohnson.ch/grub
This is the author of the rebased patches:
https://nicholasjohnson.ch/
(Nicholas Johnson <nick@nicholasjohnson.ch>)
However, this is a *rebase* performed by Nicholas,
based on these patches:
https://aur.archlinux.org/cgit/aur.git/tree/?h=grub-improved-luks2-git
...at revision: 1c7932d90f1f62d0fd5485c5eb8ad79fa4c2f50d
The AUR patches were based on GRUB 2.06, whereas Nicholas's
rebase is upon grub 2.12, which Libreboot currently uses.
These patches import the PHC implementation of argon2i/id
key derivation functions, seen here:
https://github.com/P-H-C/phc-winner-argon2
GRUB (upstream) does not merge these patches and probably won't,
because even though they're libre, they're not copylefted or
otherwise under GPL terms that GRUB can accept.
Therefore, we in Libreboot must maintain these from now on,
for our version of GRUB. The upshot? LUKSv2 decryption should
now work, perfectly, in GRUB!
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
This is specifically the following Git revision:
7a994c87f571ac99745645be0bdde9827297321a
from 10 July 2023
The keyboard fix for HP EliteBooks was merged upstream,
so lbmk no longer needs this patch; it comes with GRUB.
Signed-off-by: Leah Rowe <leah@libreboot.org>
|
|
zopflipng is great!
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
|
|
python 3 is default now, in all the distros
specifically calling "python3" often doesn't work anymore
python2 is obsolete
let python2 die
|
|
the deleted patch (in this commit) was written to fix an
issue theoretically; it hasn't been fully tested, and some
people have reported strange issues since this patch was
merged - there is no proof that this patch causes them, but
removing this patch is the correct thing to do regardless
|
|
|
|
This reverts commit 1497ae045104145de677fd151da4de6e92be4e5a.
The blanket GRUB patch seems to break PS/2 keyboard handling across
other platforms, so revert it.
|
|
This introduces a patch to grub which disables the coreboot
specific handling, allowing PS/2 keyboards to be handled the
same as i386-pc. However this alone breaks the keyboard in
Linux, requiring coreboot to perform PS/2 initialization.
I think GRUB may be restoring the original configuration of
the PS/2 controller once it exits, and if coreboot doesn't
initialize the controller then it's restored to the default
state which Linux doesn't seem to like. I think the emulated
keyboard interface provided by the EC on the E6400 behaves
in a non-standard way that is incompatible with the old
coreboot specific handling.
|
|
|
|
|
|
|
|
gnulib too
gnulib...
|
|
to match the assimilated osboot, which had purple colours
|
|
|
|
with this change, it's unlikely we'll hit errors again. previously,
some projects used were calling "python" which in context was
python3, but on some setups, the user only has python2 and python3
but no symlink for "python" (which if exists, we assumed linked to
python3)
now it's unambiguous. docs/build/ can probably be updated now, as
a result of this change, to remove the advice about that
|
|
|
|
logic for setting it in grub.cfg will be done in the next commit
|
|
|
|
|
|
it's confusing, broken and most people nowadays don't use optical drives
it's not even possible in most setups anyway
|
|
|
|
hardcode everything. in practise, the new logic will work just the same in
almost all cases, for most people, but it works around performance issues in
grub. cleanup of grub.cfg will be done in the next commit
|
|
GRUB is slow at device enumeration. This patch works around it in the same way
as vitali64's recent patch.
|
|
On many boards, grub takes a very long time to
search for a grub.cfg file on the disk.
The problem is the search_grub function which
takes a long time to complete.
I (vitali64) studied the grub.cfg from 2016 and
the grub.cfg from 2021 and optimized the
grub.cfg. It should be faster now.
|
|
|
|
This reverts commit ed63e94914a407c68d91733a5563005138d4b05f.
|
|
|
|
|
|
tianocore is a liability for the libreboot project. it's a bloated mess, and
unreliable, broken on many boards, and basically impossible to audit.
i don't trust tianocore, so i'm removing it.
|
|
This reverts commit 84a1bc502b1f296d8ad6389b9e38aa3e0ca94958.
|
|
|
|
In most LUKS setups, the user configured LVM, so doing this check first will
increase boot speeds.
|
|
|
|
|
|
usb support is extremely buggy in grub, and can cause boot delay issues
|
|
There is literally an entire other menuentry just for this purpose.
|
|
There is already a separate menuentry for USB, and most people don't boot their
installed system from USB anyway. This will result in faster boot speeds.
|
|
mitigate missing characters in unifont for border/arrow characters. this saves
space because now it is no longer necessary to add a custom font
the background added has the libreboot logo on it, and it's 10kb in size unlike
the old gnulove background that was hundreds of KB
|
|
this is a compromise. i was going to do 30 for desktops, 1 for laptops.
however, some laptop users complain about the 1 second timeout being too fast.
10 seconds should just about please everyone.
|
|
|
|
Also, when a cryptomount is successful, break from the loop and boot from that.
In most cases, this will work just fine, and this change improves the boot
speed in the vast majority of cases.
From <https://notabug.org/libreboot/lbmk/issues/53>
This is based on commit 5767489cadc4a9a1f2e7bffe03457e29e1c9a101 from
https://github.com/shmalebx9/Bleeding-Libreboot/
|
|
|
|
this is forked from the "libre" branch in osboot, which is itself a libre,
deblobbed fork of osboot, a blobbed up fork of libreboot
libreboot needed to be purged clean. this is the new libreboot development
repository. the old one has been abandoned
|
