summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2023-07-09coreboot/fam15h: support distclean on cbfstoolLeah Rowe
lbmk uses distclean on cbfstool, which newer cbfstool supports, but this old version (in coreboot 4.11) does not. fix that. it just runs make-clean Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-09grub: flip the bootsplash background 180 degreesLeah Rowe
c-libreboot, and GNU Boot, is a 180 U-turn versus current libreboot policy, as seen here: https://libreboot.org/news/policy.html Therefore, rotate the bootsplash pic 180 degrees, for comical effect. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-09coreboot/fam15h: re-add kgpe-d16 and kcma-d8Leah Rowe
also kfsn4-dre this is still based on the old coreboot 4.11 version. i have on todo to adapt dasharo coreboot for use in the master branch of lbmk, for mainline libreboot releases. since i'm doing c-libreboot for the GNU project, namely GNU Boot, and since GNU Boot has dre/d8/d16 in their tree, re-add it here for them. i literally just copied this from them, who in turn copied it from libreboot in an older revision anyway. but there is one fix: src/vendorcode/cavium/bdk/libbdk-hal/if/bdk-if-phy-vetesse.c ^ this blob wasn't being deleted by gnuboot, nor by libreboot in the older revision that it forked from. an oversight. i decided to audit the deblobbing and found this one was overlooked, out of about 900 files picked up by deblob-check. so this re-addition of dre/d8/d16 support is actually even better deblobbed than gnuboot, or old-libreboot. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-08download/coreboot: re-add book-burning supportLeah Rowe
see: https://en.wikipedia.org/wiki/Book_burning i'll actually update blobs.list for each coreboot rev in a subsequent commit. this logic was taken from an old libreboot revision, which uses different coreboot revisions. as i write this, i'm running deblob-check from linux-libre deblob scripts. my process is: i just check each file and decide whether it's a blob, or like, test data. in some cases it flags other false positives, like... a C source file that has a bunch of magic numbers in it for things (not a blob) Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-08remove blobutil and boards/utils needing/for blobsLeah Rowe
delete all blobs. TODO: actually deblob coreboot/uboot when downloading. i'll that in a little while, in an upcoming commit. yes. purge it all, in fsf style. censor what the fsf doesn't like. so that they can feel good about having less, because ideological purity is better than helping more people use coreboot, yes? Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-08rename project to c-libreboot (c = censored)Leah Rowe
because that's what fsdg policy is: censorship fsf will censor any existence of less-than-pure hardware from coreboot, despite the fact that coreboot provides more freedom for the user than fully proprietary firmware, even in cases where blobs are needed. i criticise that here: https://libreboot.org/news/policy.html FSF's fork of libreboot, formerly libreboot.at and now named GNU Boot*, is still based on old lbmk from october 2022, they haven't written *any* code since December 2022 when they supposedly first started working on the fork i'm doing a gnuboot for them, purely for fun, called c-libreboot. c-libreboot is essentially the same as old libreboot, prior to the osboot merge, but i'm including all the new things such as dell latitude e6400 or gru chromebooks, all of which are suitable under the old libreboot policy and, by extension, GNU Boot policy *URL: https://savannah.gnu.org/projects/gnuboot/ (it actually is a GNU project, though the FSF has not yet announced it officially, as I write this) Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-08coreboot: never add microcode update to ROM imageLeah Rowe
this way, default psdg libreboot roms that enable microcode can be used in fsdg libreboot, unmodified. these configs enable microcode, but this change to the coreboot build system avoids adding them regardless of configuration this saves hours of work that would otherwise be required, to reconfigure all of the coreboot images, and will allow gnuboot to use the same configs as libreboot fsf makes such a fuss over this, when it's really quite simple. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-07-08build/boot/roms: fix coreboot-version in releasesLeah Rowe
This error was observed, in the coreboot build system: In file included from src/lib/version.c:4: build/build.h:10:32: error: 'libreboot' undeclared here (not in a function) 10 | #define COREBOOT_MAJOR_VERSION libreboot-20230625 | ^~~~~~~~~ src/lib/version.c:35:46: note: in expansion of macro 'COREBOOT_MAJOR_VERSION' 35 | const unsigned int coreboot_major_revision = COREBOOT_MAJOR_VERSION; | ^~~~~~~~~~~~~~~~~~~~~~ This happened on the 20230625 *release archive*, when a user tried to build for W541 MRC on an Arch Linux container. This change fixes the error. I never got the error on my end when build testing the release archives, but this will prevent the error. Fix it by only inserting libreboot version string YYYYMMDD representing the Libreboot version. (libreboot uses ISO dates as version numbers) Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-25update .gitignore20230625Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-25build/release/src: clean spkmodem/e6400 utilsLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-25build/roms_helper: reset d521fca7, backport fixesLeah Rowe
I keep getting random linker issues when running: ./build boot roms all I think the issue lies somewhere in here, from when I did that massive audit. So I'm undoing the audit which mostly re-factored the code style here. These changes are being backported: f338697b build/boot/roms: Support removing microcode 941fbcb run coreboot utils from own directory f256ce98 build/boot/roms: say board name on stderr I removed this change: 6d6bd5ee (the script now uses dedicated utils directory) additionally: cbutils is built much earlier on in the script, first thing after initialising variables the other changes not backported are all code style changes, and I believe these are responsible. if no other fixes occur to this fire before the next libreboot release, then my hunch was right. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-25Revert "Revert "Add 4MB version of HP 8200 SFF""Leah Rowe
This reverts commit 2099545078d5a5586743d32b2470a296b66cb5c7. Wasn't this config's fault, the problem happens elsewhere too. I'm going to revert build/boot/roms to an older version and backport a few recent changes, to see if that fixes the problem. If it does, then I know that the recent linker issues happen due to recent changes in build/boot/roms The linker errors typically appear in util/kconfig/ but can happen elsewhere, seemingly random, which means I'm not handling distclean properly. Something isn't getting cleaned properly. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-25build/boot/roms: say board name on stderrLeah Rowe
That way, I can more easily debug build issues with specific boards, e.g. ./build boot roms all 2>lbmk.err.log Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-25Revert "Add 4MB version of HP 8200 SFF"Leah Rowe
This reverts commit 0f7a5386b9219111418a8de8637039c8533d99ea. Random linker errors, must investigate after release. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-24build/roms: distclean coreboot before each buildLeah Rowe
don't clean it, distclean it Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-24run coreboot utils from own directoryLeah Rowe
this means coreboot can now be distcleaned safely, before and after each build of a rom image Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-24build/cbutils: distclean before buildingLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-24build/cbutils: exit if utils dir doesn't existLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-24build/cbutils: tab indentation, not spacesLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-24build/cbutils: rename variable for clarityLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-24blobs/sources: rename t440p to t440plibremrcLeah Rowe
this fixes blobutil not downloading me.bin for the target, which was renamed to t440plibremrc Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-22Merge pull request 'losslessly compress pngs' (#85) from Riku_V/lbmk:master ↵Leah Rowe
into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/85
2023-06-22losslessly compress pngsRiku Viitanen
zopflipng is great! Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
2023-06-22Merge pull request 'u-boot: Increase EFI variable buffer size' (#83) from ↵Leah Rowe
alpernebbi/lbmk:uboot-efivar-size into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/83
2023-06-22Merge pull request 'cros: Disable coreboot related BL31 features' (#84) from ↵Leah Rowe
alpernebbi/lbmk:cros-disable-bl31-coreboot-makearg into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/84
2023-06-22cros: Disable coreboot related BL31 featuresAlper Nebi Yasak
I don't know why, but removing this BL31 make argument lets gru-kevin power off properly when shut down from Linux. Needs investigation. Do it as a cros-only HACK patch so people don't have to hold the power button after every shutdown. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
2023-06-22u-boot: Increase EFI variable buffer sizeAlper Nebi Yasak
Debian's signed shim allocates too many EFI variables to fit in the EFI variable memory buffer. Normally it would then try to continue booting in non-secure-boot mode, but its error handling throws a synchronous abort that reboots the board, making it impossible to boot into Debian unless one manually loads GRUB instead of shim. Increase EFI variable buffer size to avoid triggering the bug. Signed-off-by: Alper Nebi Yasak <alpernebiyasak@gmail.com>
2023-06-20re-add gigabyte/ga-g41m-es2lLeah Rowe
turns out it's just picky ram. errant reports of "no boot" (users did not have debug dongles) were likely "bad" ram notes will be written on libreboot.org about this Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-20nuke boards: delete nyan* (for now)Leah Rowe
not well-tested, and existing testing has revealed video issues on some of them (or just no boot) for now, retain only qemu and gru-* on arm Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-20build/boot/roms_helper nicer indent on switch loopLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-20blobs/download: exit if no board configs foundLeah Rowe
fixes ./build boot roms all in detect_firmware(), "set" is used to get values from configs, to know if things like ME/MRC are needed on some "board" configs under resources/coreboot/, no actual coreboot configs are provided, because they are used as a reference (coreboot revision, tree name etc) for actual boards, with actual coreboot configs when attempting to build for such a board, running "set" on such non-existent files would cause a non-zero exit, when we want zero. the non-zero exit then caused the build/boot/roms command to fail, when running "all" if it found, for example, resources/coreboot/cros/ which has the above problem, in this context work around it by verifying that coreboot configs exist for the given target name, in the blobutil download script. if no such configs exist, then exit zero (success) doing so is correct, because the script is intended to do just that, erroring only if it is detected that blobs are needed for a given board, but other errors occur; if no coreboot configs exist, then no roms will be built and, therefore, no blobs are needed Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-20build/boot/roms: remove wrong parenthesesLeah Rowe
will pass all args as a single arg, which is wrong fix that Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-20build/boot/roms: nicer indent style on switch loopLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-20lbmk: run ./.gitcheck clean on errorLeah Rowe
a glaring oversight on my part Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-20lbmk: exit 1 if script failedLeah Rowe
script is -e anyway, so this is redundant, but best put it here anyway. it can only help. correct behaviour is always to fail on error, except in certain cases that would be handled on a case-by-case basis in each script
2023-06-20build/boot/roms: only set firstoption if argc>0Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-20update release filesLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-19Merge pull request 'Cache downloads based on checksum' (#81) from ↵Leah Rowe
Riku_V/lbmk:dl_cache into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/81
2023-06-19board/t440p_12mb: rename to t440plibremrc_12mbLeah Rowe
t440pmrc_12mb is the blob one. t440p_12mb is the libre one, but this isn't clear. rename accordingly. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-19build/boot/roms: Support removing microcodeLeah Rowe
From now on, the following rules are available for all mainboards, in resources/coreboot/boardname/board.cfg: * blobs_required="n" or "y" * microcode_required="n" or "y" The blobs setting, if set to "n", simply renames filename.rom to filename_noblobs.rom. The microcode setting, if set to "n", copies the ROM (with or without _noblobs) to filename_nomicrocode.rom (if blobs="n", it would be filename_noblobs_nomicrocode.rom). Where "nomicrocode" is set, ROMs with microcode will still be provided by lbmk and in relesase, but ROMs will also be provided alongside it that lacks any microcode updates. If the *original* ROM already lacks microcode updates, then the original ROM will be *renamed* to include "nomicrocode" in the name. This is done on images for ARM platforms, for instance, where microcode is never used whatsoever. Example filenames now generated: seabios_e6400_4mb_libgfxinit_corebootfb_noblobs_nomicrocode.rom seabios_e6400_4mb_libgfxinit_corebootfb_noblobs.rom seabios_withgrub_hp8300usdt_16mb_libgfxinit_corebootfb_colemak_nomicrocode.rom seabios_withgrub_hp8300usdt_16mb_libgfxinit_corebootfb_colemak.rom uboot_payload_gru_kevin_libgfxinit_corebootfb_noblobs_nomicrocode.rom A vocal minority of people were not happy with some of the changes made in Libreboot last year, including on existing supported hardware from before those changes were made. I did this before the last release, out of respect: https://libreboot.org/news/gm45microcode.html (re-add mitigations for no-microcode setup on GM45) This new change is done as an further, extended courtesy. Tested and works fine. (testing using cbfstool-print) Actual Libreboot policy about binary blobs is nuanced. See: https://libreboot.org/news/policy.html (reduction policy) and: https://libreboot.org/freedom-status.html (implementation) Well, the status page talks about descriptor vs non-descriptor on Intel platforms, and where me_cleaner is used (on platforms that need Intel ME firmware), it regards the descriptored setups to be blob-free if coreboot does not require binary blobs. In this paradigm, microcode updates are not considered to be binary blobs, because they aren't technically software, they're more like config files that just turn certain features on or off within the CPU. However, for lbmk purposes, "noblobs" means that, after the ROM is fully ready to flash on the chip, there will be no blobs in it (except microcode). So for example, an X200 that does not require ME firmware is considered blob-free under this paradigm, even though Libreboot policy regards X230 as equally libre when me_cleaner is used; in this setup, ROMs will not contain "blobfree" in the filename, for X230 (as one example). Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-17Cache downloads based on checksumRiku Viitanen
Since many boards use the same ME firmware, we could save everyone's bandwidth and time by caching the update files. Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
2023-06-17Merge pull request 'Add HP 8300 USDT' (#80) from Riku_V/lbmk:hp8300usdt into ↵Leah Rowe
master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/80
2023-06-17Add HP 8300 USDTRiku Viitanen
Still on Gerrit. ME downloader failed with HP update file, so let's just use Lenovo's instead. Both contain identical ME8_5M_Production.bin files. Tested and working: * Native raminit with both DIMMs * Libgfxinit textmode and framebuffer on both DisplayPorts and VGA * External USB2 and USB3 ports: they all work * USB 3.0 SuperSpeed (rear, 4 ports) * Ethernet * Mini-PCIe WLAN * SATA: 2.5" SSD and optical drive bay * SeaBIOS and GRUB (boot to linux) * PS/2 keyboard and mouse * S3 suspend and resume, wake using USB keyboard * Headphone output, line out, internal speaker * Wake on LAN * Rebooting * CMOS options & nvramcui Untested: * Line in, mic input * MXM graphics card * EHCI debug Not working: * Mini-PCIe USB: I couldn't get it working on vendor BIOS either, so maybe it just isn't present * PS/2 keyboard wake from S3 * mSATA (I have no mSATA drives)
2023-06-16Merge pull request 'Add HP Elitebook 2570p' (#79) from Riku_V/lbmk:hp2570p ↵Leah Rowe
into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/79
2023-06-16Add HP Elitebook 2570pRiku Viitanen
Tested with Johan Ehnberg (johan@molnix.com) The following is tested and confirmed working: - backlight control - touchpad - USB (external, smart card, fingerprint, bluetooth, webcam, WWAN) - touchpad - Wi-Fi - 2,5" SATA - USB 3.0 - SD card - Memory: 2+2 (matched or unmatched), 8+2, 8+8 - internal flashing from libreboot - SeaBIOS and GRUB payloads - Boots Devuan and Ubuntu Untested: - ExpressCard - DVD - dock - external displays - eSATA - trackpoint (not present on this aftermarket keyboard)
2023-06-14util/nvmutil: reduced indentation inside loopLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-14util/spkmodem-recv: rename function for clarityLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-13util/spkmodem-recv: remove unnecessary error checkLeah Rowe
the loop in main() already checks EOF, and errno is properly handled at the end of main() we only need to call ferror(), to check error state this fixes a bogus error message when pressing ctrl+D to terminate the program, *which is the intended way to terminate this program* (that, or EOF is reached in any other another way) do not treat intended behaviour as an error condition! Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-13util/spkmodem-recv: say cc, not gcc, in commentLeah Rowe
i've build-tested this code with clang and that also works. in practise, a user is going to have clang or gcc Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-06-13util/spkmodem-recv: fix bad commentLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>