summaryrefslogtreecommitdiff
path: root/config/coreboot/hp820g2_12mb
AgeCommit message (Collapse)Author
2024-05-27re-configure grub_scan_disk on various targetsLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-27remove grub_scan_disk in all target.cfg filesLeah Rowe
A subsequest revision will set them again as needed, per coreboot target. 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-27coreboot: only run GRUB as a secondary payloadLeah Rowe
See: https://codeberg.org/libreboot/lbmk/issues/216 Almost all users will be OK running GRUB, but a minority of users have experienced a fatal error pertaining to grub_free() or grub_realloc() (as my investigation of GRUB sources reveal when grepping the error reported in the link above). We don't yet know what the bug is, only that the error occurs, leading to an effective brick if the user has GRUB as their primary payload. So far, it has only been reported on some Intel SandyBridge-based Dell Latitudes in Libreboot, but we can't be too sure. The user reported that memtest86+ passes just fine, and SeaBIOS works; BIOS GRUB also works, which means that the bug is likely only in an area of GRUB that runs specifically on the coreboot payload, so it's probably a driver in GRUB when running on the metal rather than BIOS/UEFI. The build system supports a configuration whereby SeaBIOS is the primary payload, but GRUB is available in the SeaBIOS boot select menu, and an additional configuration is available where GRUB is what SeaBIOS executes first (while still providing boot select); both of these are now the *only* configurations available, on all x86 targets except QEMU. The QEMU target is fine because if the bug occurs there, you can just close QEMU and try a different image. Even after this bug is later identified and fixed, the GRUB source code is vastly over-engineered and there are likely many more such bugs. SeaBIOS is a reliable payload; the code is small and robust. Remember always: Code equals bugs Therefore, this configuration change is likely going to be permanent. This will apply in the next release. 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-03update hp machines to status=stable for releaseLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-01update release status for HP machinesLeah 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-25hp820g2: allow building, but don't do release ROMsLeah Rowe
at present, the inject scripts compress refcode in a way that is not reproducible, so there's no way to verify that the firmware is correct, via checksum verification, when injecting vendor code on release images the lack of reproducibility in recompression will have to be addressed, but the issue is that lbmk does not provide its own sources for compression utilities, instead opting to use the system's own compression utility so the solution might be for lbmk not to use the host's utility, and compile its own, or insert the refcode uncompressed. for now, simply disable the hp 820 g2 target in libreboot releases this uses the same logic recently implemented for excluding mrc-based haswell images in libreboot releases Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-02-18./update trees -u corebootLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-25coreboot/default: update coreboot to January 2024Leah Rowe
Base revision changed to: commit b6cbfa977f63d57d5d6b9e9f7c1cef30162f575a Author: Morris Hsu <morris-hsu@quanta.corp-partner.google.com> Date: Fri Jan 5 16:48:17 2024 +0800 mb/google/dedede/var/metaknight:Add fw_config probe for multi codec and amplifier Of note: Several out-of-tree ports have been adjusted to use the new SPD config style, where it is defined in devicetree. I manually updated the E6530 patch myself, based on the update that Nicholas did on E6430 (Nicholas will later update the E6530 patch himself, and I'll re-merge the patch). Several upstream patches now exist in this revision, that we were able to remove from lbmk. The heap size patch was reverted upstream, as we did, but see: https://review.coreboot.org/c/coreboot/+/80023 https://review.coreboot.org/c/coreboot/+/79525 Although we still disable the TSEG Stage Cache, ivy/sandy/haswell should be reliable on S3 now (leaving TSEG Stage Cache disabled, for now, anyway). Also included in upstream now: commit 29030d0f3dad2ec6b86000dfe2c8e951ae80bf94 Author: Bill Xie <persmule@hardenedlinux.org> Date: Sat Oct 7 01:32:51 2023 +0800 drivers/pc80/rtc/option.c: Stop resetting CMOS during s3 resume Further patches from upstream: commit 432e92688eca0e85cbaebca3232f65936b305a98 Author: Bill Xie <persmule@hardenedlinux.org> Date: Fri Nov 3 12:34:01 2023 +0800 drivers/pc80/rtc/option.c: Reset only CMOS range covered by checksum This should fix S3 on GM45 thinkpads. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-01-10NEW MAINBOARD: HP EliteBook 820 G2Leah Rowe
This is of Broadwell platform, one generation above Haswell. Of note: this uses HP Sure Start. Although the flash is 16MB, our CBFS section (and IFD configuration) assumes 12MB flash, so the final 4MB will be left unflashed on installation, after blanking the private flash. The coreboot documents have more information about this. Some minor design changes in lbmk were made, to accomodate this port: Support for extracting refcode binaries added (pulled from Google recovery images). The refcode file is an ELF that initialises the MRC and the PCH. It is also responsible for enabling or disabling the Intel GbE device, where Google does not enable it, but lbmk modifies it per the instructions on the coreboot documentation, so as to enable Intel GbE. Google's recovery image stores the refcode as a stage file, but coreboot changed the format (for CBFS files) after 4.13 so coreboot 4.13's cbfstool is used to extract refcode. This realisation made me also change the script logic to use a cbfstool and ifdtool version matching the coreboot tree, for all parts of lbmk, whereas lbmk previously used only the default tree for cbfstool/ifdtool, on insertion and deletion of vendor files - it was 81dc20e744 that broke extraction of refcode on google's recovery images, where google used an older version of cbfstool to insert the files in their coreboot ROMs. A further backported patch has been added, copying coreboot revision f22f408956 which is a build fix from Nico Huber. Iru Cai submitted an ACPI bugfix after the revision lbmk currently uses, for coreboot/default, and this fix is needed for rebooting to work on Linux 6.1 or higher. This patch has been backported to lbmk, while it still uses the same October 2023 revision of coreboot. Broadwell MRC is inserted at the same offset as Haswell, so I didn't need to tweak that. Signed-off-by: Leah Rowe <leah@libreboot.org>