summaryrefslogtreecommitdiff
path: root/script/roms
AgeCommit message (Collapse)Author
2024-06-09minor code cleanup in the build systemLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-06put coreboot utils in elf/, not cbutils/Leah Rowe
one directory per util, under elf/ e.g. elf/cbfstool/ further split by tree name, e.g.: elf/cbfstool/default/ elf/cbfstool/foo/ Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-06use correct memtest86plus path in script/romsLeah Rowe
the previous change makes memtest.bin get cached in elf/ but the path was being prefixed with src/ by script/roms do away with the prefix Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-06put memtest86plus builds in elf/memtest86plus/Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-03better help text on invalid commandsLeah Rowe
adding help again is a bad idea. code should never document itself; that's what documentation is for. so, make the code do a better job telling the user where to find documentation. 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>
2024-05-28roms: allow user override of grub_scan_diskLeah Rowe
this effectively lets you change the boot order. example: ./build roms -s "nvme ata" t1650_12mb the above example would set: grub_scan_disk="nvme ata" another example: ./build roms -s nvme t1650_12mb this would set: grub_scan_disk="nvme" this overrides what's set in target.cfg for the given target. useful for quick reconfiguration if building from source Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-28roms: fix bad eval when comparing optionsLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27grub.cfg: use grub_scan_disk to set boot orderLeah Rowe
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>
2024-05-27minor correctionLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27roms: make grubfirst if seabios_withgrub=yLeah Rowe
rather than if seabios_grubonly=y if grubonly=y, still make the grubonly rom this complements the previous commit Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-26rename include/option.sh to include/lib.shLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-26roms: rename bstr variableLeah Rowe
i forgot to do this in the recent cleanup. it is now initialised as a variable named "x" Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-26general code cleanup in the build systemLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-21fix building coreboot images on i686 hostsLeah Rowe
firstly, memtest86+ is currently not cross compiled and relies on 64-bit headers (x86_64 only). a 32-bit distro is unlikely to be able to build 64-bit binaries. secondly: vboot throws a build error due to -Werror when building on 32-bit hosts. we rely on vboot code to build cbfstool, so turn off -Werror on vboot that's all. 32-bit hosts are not recommended; it is assumed that you are building on an x86_64 host. work will go into the build system at a later date to make it more portable, by cross compiling everything, but this should fix 32-bit for now. there are some x60/t60 users who still want to build roms, so let's allow them that possibility. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-19build/roms: skip target if config/ dir missingLeah Rowe
fixes a regression when running ./build roms all now it should work again Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-19option.sh: mktar_release to mkrom_tarballLeah Rowe
that's all it's used for, to compress the rom images Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-19build/roms: rename moverom to copyromLeah Rowe
it copies, it doesn't move, so name it right Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-19minor code cleanup in the build systemLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-18build/roms: simplify serprog list commandLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-18build/roms: simplified config payload checksLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-16lbmk: allow easier sync with cbmkLeah Rowe
an equivalent change has been made in cbmk. certain lbmk-specific variable names have been made generic, with certain functions and other variables moved around. i maintain sync between libreboot and canoeboot, where both projects can have the same behaviours, and most of the merge conflicts have to do with variable names containing "LBMK", "lbmk", "cbmk" or "CBMK", or indeed "canoeboot" and "libreboot" LBMK/lbmk/CBMK/cbmk variables between canoeboot and libreboot now contain the string XBMK/xbmk it should now be *much* easier to merge build system changes between lbmk and cbmk. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-15remove help commands (user should read docs)Leah Rowe
i always say, code should never document itself. that's what documentation is for. the releases contain documentation under docs/ but the git repository does not; for that, use the website. (in practise, lbmk usually needs internet anyway) Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-15remove check_project() (always set variables)Leah Rowe
in lbmk, we call check_project() to set variables such as projectname, version, version date this is unnecessary, because all main scripts use this functionality anyway do it by default Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-15build/roms: clean up tarball handlingLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-15build/roms: create full release tarball nameLeah Rowe
set relname from option.sh under check_project() now the release logic simply has to move a directory Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-15unified sha512sum creation for tarballsLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-14move rom tarball creation to script/romsLeah Rowe
export LBMK_RELEASE="y" if this is done, the tarball is created instead of a directory, and the rom images are nuked using ./vendor inject with the nuke option, inserting the correct version files; the rom directory is deleted now the release script logic simple renames existing tarballs. the benefit of this change is fewer lines of code, and now lbmk doesn't use an insane amount of disk space when building a *lot* of release images (the uncompressed directories are deleted after each build) Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-11remove all status checks. only handle release.Leah Rowe
the release variable is all we need, turning a target on or off for a given release. the status checks were prone to bugs, and unnecessary; it also broke certain benchmark scripts. it's better to keep the lbmk logic simpler. board status will be moved to the documentation instead. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-11move script/*/* to script/Leah Rowe
there are only two scripts under script/ now, and there probably won't be many more. lbmk's design has simplified to such a degree that the two-level directory structure is no longer necessary. the existing command structure has not changed. for example: ./build roms list ./update trees -f coreboot default these will still work, but the symlinks to "build" are now strictly for backwards compatibility; they may be removed at a later date, but i'll keep the current design for now. this also leads to a quirk, for example: ./build roms all ./update roms all these now do the exact same thing, whereas "./update roms all" would have previously been an invalid command. Signed-off-by: Leah Rowe <leah@libreboot.org>