summaryrefslogtreecommitdiff
path: root/config/data/grub
AgeCommit message (Collapse)Author
2024-07-10trees: remove project-specific hacksLeah Rowe
move the coreboot-specific includes into mkhelper.cfg for that project. on some projects, we need variables from mkhelper.cfg to be global, so I was including serprog and coreboot mkhelper.cfg files in this script. instead, set a new variable "mkhelpercfg" pointing to the config file. if it doesn't exist, create and then point to a temporary (empty) mkhelper.cfg file. the rom.sh include has been moved to coreboot mkhelper.cfg The only remaining project-specific logic, in this trees script, is now the coreboot crossgcc handling, but this needs to be there as it's also used to build U-Boot. The way this now works, certain includes are done twice. For example, include/rom.sh will be included once globally, outside of main(), and then again in configure_project(). This means that certain functions will be defined twice. I'm uncertain if shell has anything equivalent to an ifdef guard as in C, but we actually want this here anyway, and it shouldn't cause any problems. It's a bit of a hack, but otherwise results in much cleaner code. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-07-06GRUB: only load xhci from grub.cfgLeah Rowe
don't put it in the install modules. this works around a hanging issue on haswell thinkpads. when any usb device is inserted, GRUB will sometimes hang if started from the SeaBIOS payload, *while* the USB device is plugged in. plugging in the USB device after GRUB starts worked. it will have to be investigated more at a later date, but this simply configuration change works. the xhci module is already loaded explicitly, in grub.cfg Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-07-01GRUB: use mkhelper.cfg for common variablesLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12grub: only enable nvme if needed on a boardLeah Rowe
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>
2024-06-09re-add ability to use cbfs grub.cfg as defaultLeah Rowe
i removed this before, when making grub multi-tree, because the design i used in an earlier version of the patch actually added the grub.elf generation to grub source itself, but then i decided to hack around the grub build system from lbmk/cbmk instead re-add this functionality, so that users can easily insert their own custom grub.cfg into cbfs without needing to re-build their image. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-06handle build.list from config/data/, not config/Leah Rowe
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>
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>