summaryrefslogtreecommitdiff
path: root/config/grub/patches
AgeCommit message (Collapse)Author
2024-06-02make GRUB multi-tree and re-add xhci patchesLeah Rowe
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>
2024-05-27GRUB: remove XHCI patches for now (will re-add)Leah Rowe
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>
2024-05-20Add NVMe support to GRUB2 payloadMate Kukri
Tested on OptiPlex 3050 (via injecting grub2.elf into WIP coreboot port).
2024-05-04Libreboot 20240504 release20240504Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-05grub xhci supportLeah Rowe
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>
2024-02-25Libreboot 2024022520240225Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-26Libreboot 2024012620240126Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-06Libreboot 2023110620231106Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-05grub: avoid printing empty error messagesLeah Rowe
this replaces the previous behaviour, which erred on a specific value of grub_errno, which was a problem if other types of errors used that value. due to the way i patch out the prefix error messages, this new patch ensures that only those errors are silenced. all other messages will be printed. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-05further silence grub prefix errorsLeah Rowe
it still printed "error: ." on screen, instead of the prefix message. now it's silent. it just says: Welcome to GRUB! Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-05grub: don't print messages if a module isn't foundLeah Rowe
it can annoy some users, so just silence it. we don't need a lot of modules so we only have a few, but some distro grub configs can load modules frivilously. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-05grub: don't print prefix errors on the screenLeah Rowe
still set grub_errno, and behave the same, but don't print anything. just carry on execution as normal. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-01Libreboot 2023110120231101Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-10-31GRUB: don't spew "Unknown key 0xff" in errorLeah Rowe
Faulty keyboards make GRUB unusable. Normally it happens when a user plugs in a faulty USB keyboard, but if it's the laptop keyboard, then GRUB becomes unusable and the user cannot boot anything. So, your laptop keyboard is a ticking timebomb if you use GRUB; with this patch, that's no longer the case. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-10-31fix grub keyboard init on dell e6400 and e6430Leah Rowe
also, enable seabios_withgrub on e6400, but not grubfirst; right now, we also support dgpu which would brick on grubfirst. on my tested nvidia model, loading grub from seabios worked, so i'm going to re-add seabios_grubfirst functionality like in older libreboot revisions, enabled selectively on a given target. e6430 currently only has igpu support anyway, but i've done the same thing there, in anticipation of future dgpu support. e6400 and e6430 ec report scancode set 2 with translation by default, but only actually output scancode set 1 grub is trying to use scancode set 2 without scancode translation, so the key inputs get messed up fix it by forcing scancode set 2 with translation, but only on coreboot; other build targets on GRUB will retain the same behaviour as before courtesy goes to Nicholas Chin who inspired me, and helped me to fix this. tested on Nicholas's E6400 and E6430, and my E6400; Riku also tested it on non-Dell, as did I (some thinkpads), and all seems OK. The new behaviour in coreboot GRUB is essentially no different to that of SeaBIOS, which does the same. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-10-21Libreboot 2023102120231021Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-09-25split up grub patches into subdirectoriesLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-09-04merge config/ and resources/Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>