summaryrefslogtreecommitdiff
path: root/script/build
AgeCommit message (Collapse)Author
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>
2024-05-09build/roms: print serprog helpLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-09merge script/build/serprog with script/build/romsLeah Rowe
previous command: ./build serprog now it is: ./build roms serprog after that, it's the same arguments e.g. ./build roms serprog stm32 ./build roms serprog rp2040 further cleanup to commence Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-09build/roms: remove unnecessary commandLeah Rowe
there is no need to return 0 at the end of a function. sh does that anyway Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-06merge include/err.sh with include/option.shLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-05build/roms: don't rely on x in handle_targetLeah Rowe
x is part of the for loop in main() and may or not still be available from handle_target, depending on your implementation of sh, but this should not be assumed do it properly Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-05build/roms: don't use exit status from skip_boardLeah Rowe
the printf could potentially return non-zero, which might make the script not skip a given target Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-05build/roms: split up main()Leah Rowe
it's starting to get a big big, so break it up Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-05build/roms: allow searching status by mismatchLeah Rowe
for example: ./build roms list stable this lists all images that are marked "stable" now: ./build roms list _stable this lists all images that are *not* marked stable this will help me keep track during development Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04build/roms: more useful status warningsLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-29build/roms: simplified list handlingLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-28build/roms: if release, allow all non-broken romsLeah Rowe
this includes untested roms Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-28build/roms: always display warningsLeah Rowe
(even if status=stable) Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-28build/roms: reduce indentation in skip_board()Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-28build/roms: simplified status handlingLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-28build/roms: simplified seagrub handlingLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-28build/roms: support SeaGRUB *with menu enabled*Leah Rowe
This is useful on desktops, where you want GRUB to automatically start, but you still want access to the GRUB menu, in the case where you rely on SeaBIOS to execute the VGA ROM inside your graphics card. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-27build/roms: tell the user how to ignore statusLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-27allow disabling status checks during buildsLeah Rowe
export LBMK_STATUS=n if not set, the status checks and confirmation dialogs persist. if set to y they persist. if you set it to n, all checks are disabled, so e.g.: ./build roms all this would once again build all targets, regardless of status. this is if you want the old behaviour. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-26build/roms: update help, pertaining to statusLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-26build/roms: let "list" specify status typesLeah Rowe
for example: ./build roms list this will list every now, still. same behaviour. now see: ./build roms list stable this will list all stable roms ./build roms list untested this lists untested roms. but wait! ./build roms list untested broken unstable ./build roms list broken unstable yes. it works this way. now you can use lbmk to easily see what rom status are, during maintenance. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-26erroneous returnLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-26build/roms: report status when building imagesLeah Rowe
export LBMK_VERSION_TYPE=x x can be: stable, unstable in target.cfg files, specify: status=x x can be: stable, unstable, broken, untested if unset, lbmk defaults to "unknown" if LBMK_VERSION_TYPE is set, no confirmation is asked if the given target matches what's set (but what's set in that environmental variable can only be stable or unstable) if LBMK_RELEASE="y", no confirmation is asked, unless the target is something other than stable/unstable "unstable" means it works, but has a few non-breaking bugs, e.g. broken s3 on dell e6400 whereas, if raminit regularly fails or it is so absolutely unreliable as to be unusable, then the board should be declared "broken" untested means: it has not been tested With this change, it should now be easier to track whether a given board is tested, in preparation for releases. When working on trees/boards, status can be set for targets. Also: in the board directory, you can add a "warn.txt" file which will display a message. For example, if a board has a particular quirk to watch out for, write that there. The message will be printed during the build process, to stdout. If status is anything *other* than stable, or it is unstable but LBMK_VERSION_TYPE is not set to "unstable", and not building a release, a confirmation is passed. If the board is not specified as stable or unstable, during a release build, the build is skipped and the ROM is not provided in that release; this is in *addition* to release="n" or release="y" that can be set in target.cfg, which will skip the release build for that target if "n" Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-25build/roms: add missing deletion of tmp fileLeah Rowe
the temporary rom per build was not being deleted after finishing the current target. this adds up in /tmp during large builds, when building for many targets. fix this! Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-24haswell: only provide NRI-based ROMs in releasesLeah Rowe
release="n" is set in target.cfg on haswell build targets that use mrc.bin script/update/release exports LBMK_RELEASE="y" script/build/roms skips building a given target if release="n" in target.cfg *and* LBMK_RELEASE="y" you could also do the export yourself before running ./build roms, for example: export LBMK_RELEASE="y" ./build roms all This would skip these ROM images. The native haswell raminit is now stable enough in my testing, that I wish to delete the MRC-based targets. This is in line with Libreboot's Binary Blob Reduction Policy, which states: if a blob can be avoided, it should be avoided. The problem is that users often run the inject script in *lbmk* from Git, instead of from the src release archive. I forsee some users running this on modern lbmk with older release images. If the mrc-based target isn't there, the user may use an NRI-based target name, and think it works; they will insert without MRC. I foresaw this ages ago, which is why Caleb and I ensured that the script checks hashes, and hashes are included in releases. Therefore: for the time being, keep the MRC-based configs in lbmk but do not include images for them in releases. This can be done indefinitely, but I'll probably remove those configs entirely at some point. On the following boards, Libreboot now will *only* provide NRI-based ROM images for the following machines: * Dell OptiPlex 9020 SFF * Dell OptiPlex 9020 MT * Lenovo ThinkPad T440p * Lenovo ThinkPad W541/W540 I now recommend exclusive use of NRI-based images, on Haswell hardware. It's stable enough in my testing, and now supports S3. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27safer, simpler error handling in lbmkLeah Rowe
in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-18GRUB: insert only 1 keymap per board, in cbfsLeah Rowe
There is no need to add multiple keymap files, because GRUB can load keymaps from CBFS. The current build logic is designed to avoid building multiple GRUB binaries, which are expensive computationally because each one would then have to be compressed for each board. This patch provides the best of both worlds: less space used in flash like in the old lbmk design (1 keymap per board), but retaining the current build speeds and therefore not re-introducing the slowness of lbmk's previous GRUB build logic. The grub.cfg file has been modified, accordingly. It now only loads a keymap.gkb file from CBFS, by default. It does this, only if that file exists; if not, GRUB already defaults to US Qwerty layout anyway. ALSO: compress all keymap gkb files with xz -6 GRUB automatically decompresses files when accessed. This results in about 2KB of flash space saved in CBFS. Here is real-world data, showing the increased flash space: < fallback/payload 0x3eb80 simple elf 548821 none < keymap.cfg 0xc4bc0 raw 16 none < (empty) 0xc4c00 null 11633316 none --- > fallback/payload 0x3eb80 simple elf 546787 none > keymap.gkb 0xc43c0 raw 344 none > (empty) 0xc4540 null 11635044 none This was taken by diffing the cbfstool "print" output, both before and after. The *after* result is with this change. 11633316. In this example, 1728 bytes have been saved. Therefore, with compression taken into account, this patch saves about 1.7KB of space in CBFS. This change means that lbmk can now scale to support hundreds of keymaps, without increasing the amount of flash space used, in each given image. Since the keymap files are compressed in lbmk.git, in advance, we spend no additional time on compression at build time. The resulting change in build speed in negligible. Adding your own keymap.gkb file was already possible, for changing the keymap in libreboot images, if you didn't want to change the memdisk (and thus re-compile grub.elf). Now, this is the default behaviour, and the only way to do it. It's much more efficient. The original keymap files can be restored, by running unxz. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-17build/roms: err if -k layout doesn't existLeah Rowe
if the user defines a layout that doesn't exist, throw an error in lbmk. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-17build/roms: regression fix: uninitialised variableLeah Rowe
the "kmapdir" variable was removed in an earlier audit, but was overlooked for -k because that option was untested. rather than initialise the variable, re-use grubcfgsdir. this fix enables e.g. "-k usdvorak" to work again. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-01build/roms: tidy up payload configuration handlingLeah Rowe
the eval for loop is overkill Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-01build/roms: remove unused variableLeah Rowe
the kmapdir variable is only used once, and just the string makes it obvious what this is for Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-01build/roms: don't needlessly re-build grub.elfLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-01build/roms: create elf/grub if non-existentLeah Rowe
i overlooked this during previous re-factoring Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-01fix oversight in previous commitLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-01build/roms: rename more functions for clarityLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-01build/roms: rename payload functions for clarityLeah Rowe
they are functions that build payloads, so name them as such. don't call them "dependencies" functions Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-01build/roms: simplify seabios dependency checkLeah Rowe
the update/trees script checks this binary itself, before deciding whether to recompile/compile, so we don't need to do such checks here. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-01build/roms: simplify grub dependency checkLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-30unify script/update/trees and script/build/grubLeah Rowe
the script can now also handle autoconf build systems, whereas this could previously only be done for grub. with this change, the overall sloccount is also lower Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-28lbmk scripts: general code cleanupLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-27build/serprog: err if basename failsLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-27update/trees: further simplify crossgcc handlingLeah Rowe
arch no longer needs to be set, on multi-tree projects, and it has been renamed to xarch the new behaviour is: if xarch is set, treat it as a list of crossgcc targets and go through the list. set the first one as the target, for what lbmk builds, but build all of the defined crossgccc targets crossgcc_ada is now xlang, and defines which languages to build, rather than whether to build gcc-gnat Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-24lbmk scripts: shorter code linesLeah Rowe
while seemingly pedantic, this does actually make code easier to read. mostly just switching to shorthand for variable names, where no expansions or patterns are used Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-24build/roms: rename two functions for clarityLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-23lbmk scripts: general code cleanup/optimisationLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-23build/roms: improved error handling for romsLeah Rowe
the rom functions print a path to the rom they built, which is then used, but these are called inside what are essentially subshells, and we had no error handling Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-23build/roms: remove redundant checkLeah Rowe
cros roms are always using libgfxinit, with a coreboot framebuffer, so the "normal" initmode is never used. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-23set version/projectname properlyLeah Rowe
lbmk used to set version/versiondate directly in err.sh, but now it's handled there by a function, which is called by the main script. script/update/release hadn't yet been adapted. the only change necessary is to call check_project() script/update/trees also makes use of it script/build/roms is using "projectname" Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-23don't delete microcode updates in rom imagesLeah Rowe
at present, lbmk can remove microcode updates on images for a given target, if the target specifies microcode_required="n" in target.cfg lbmk then provides images with microcode, and images without, in a given release. although the user can also remove them manually, this just makes it a bit more convenient, for those users who do wish to run without the updates. this functionality is provided only on those platforms where no-microcode is tested. well, this behaviour implements a compromise on libreboot policy, which is to always include microcode updates by default. see: Binary Blob Reduction Policy the *canoeboot* project now exists, developed in parallel with libreboot, and it ships without microcode updates, on the same targets where lbmk also handled this. running without microcode updates is foolish, and should not be encouraged. clean up lbmk by not providing this kludge. the libreboot documentation will be updated, telling such users to try canoeboot instead, or to remove the update from a given libreboot rom - this is still possible, and mitigations such as PECI disablement on GM45 are still in place (and will be kept), so that this continues to work well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-23lbmk scripts: general code cleanupLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>