| Age | Commit message (Collapse) | Author |
|---|
|
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>
|
|
|
|
|
|
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
|
