summaryrefslogtreecommitdiff
path: root/config/coreboot/e6530_12mb
AgeCommit message (Collapse)Author
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-04coreboot: update latitude release statusLeah Rowe
working s3 means i'm happy to mark it as being stable. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-01correct dell latitude status for releaseLeah Rowe
it should be marked unstable, though these machines are basically reliable; they have certain missing features and quirky behaviour so it's important not to over-sell it mark it as unstable, on all of the dell latitudes Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-01set dell latitudes stable for releaseLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-04-27Set status=unstable on dell latitudesLeah Rowe
also warn about issues, in a warn.txt file for each. 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-03-04config: Add Dell Latitude E5420Nicholas Chin
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-02-08config: Add Dell Latitude E5520Nicholas Chin
Tested by Minimum_Baseball_629 on Reddit Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-02-07Merge pull request 'Add Latitude E6420, E6520, and E5530' (#183) from ↵Leah Rowe
nic3-14159/lbmk:latitude-ports into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/183
2024-02-06config: Add Dell Latitude E5530Nicholas Chin
Tested by Martin Dawson. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-02-06config: Add Dell Latitude E6520Nicholas Chin
Tested by Martin Dawson. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-02-06config: Add Dell Latitude E6420Nicholas Chin
Tested by Martin Dawson. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-02-03import dell optiplex 7020/9020 patch from gerritLeah Rowe
coreboot gerrit patch 55232, patchset 31 the actual board will be enabled in a follow-up patch. merging the patch on its own first is better practise, to run ./update trees -u coreboot this way, there won't be a revision that breaks builds, due to the idiosyncratic nature of coreboot configuration. Signed-off-by: Leah Rowe <info@minifree.org>
2024-01-25dell/e6*30: use generic PS2K/PS2M EISAID stringsLeah Rowe
CONFIG_PS2M_EISAID. this is a a string used for the identifier on the mouse, in ACPI. CONFIG_PS2K_EISAID this is used for the keyboard. IASL comes back with this build error: dsdt.asl 1884: Name(_HID, EISAID("DLLK0534")) Error 6045 - ^ EISAID string must be of the form "UUUXXXX" (3 uppercase, 4 hex digits) (DLLK0534) Change DLLK0534 back to PNP0303 and change DLL0534 back to PNP0F13. These are generic identifiers for PS/2 keyboard and mouse. Any generic driver will work with the onboard mouse/keyboard on these machines. They do not need to be changed. These are the default values anyway. Just leave them explicitly defined to the default values, for now; if these options are not set, coreboot will default to these values. This shouldn't break anything for the users. I've reported this to Nicholas Chin, author of those patches. Libreboot imported the new versions of E6430/E6530 board patches in the coreboot revision update, but the new (technically correct) values broke IASL, so I've decided to use the old values for now. 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>
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-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-21build/roms: remove modify_coreboot_rom()Leah Rowe
don't handle "romtype" at all, in board target.cfg files add /dev/null as pike2008 rom on amd boards. this serves the same purpose, adding them as empty vga roms, to add an empty rom in cbfs. pike2008 cards cause seabios to hang, when their oproms are executed, so we insert a fake rom on i945 thinkpads, use the coreboot config option: CONFIG_INTEL_ADD_TOP_SWAP_BOOTBLOCK when set, this enables the same bootblock copy, for use with bucts. these two cases, namely pike2008 roms and i945 bootblock copies, no longer need to be handled in code Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-12-21update/trees: simplified crossgcc handlingLeah Rowe
only call crossgcc for coreboot and u-boot, but use hostcc for everything else. simplify the checking of which architecture to compile for. "arch" in target.cfg files has been modified, to allow further simplification. without this patch, the logic currently only *barely* avoids using crossgcc on things like utils, and only works in practise because, in practise, lbmk only works on x86_64 anyway. the new logic, as per this patch, is simpler and more robust. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-11-05Add Dell Latitude E6530 supportNicholas Chin
This is pretty much the same as the E6430 Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>