summaryrefslogtreecommitdiff
path: root/config/coreboot
AgeCommit message (Collapse)Author
2024-08-13config/coreboot: Add config for Dell Latitude E6230Nicholas Chin
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-08-13config/coreboot: Add config for Dell Latitude E6330Nicholas Chin
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-08-13config/coreboot: Add config for Dell Latitude E6320Nicholas Chin
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-08-13config/coreboot: Add config for Dell Latitude E6220Nicholas Chin
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-08-12coreboot/x4x: fix build errorLeah Rowe
see relevant patch added in the diff set the clock on x4x boards to 96MHz like on GM45 fixes the following build error on x4x boards: hw-gfx-gma-plls.adb:465:46: error: "INTEL_GMA_DPLL_REF_FREQ" not declared in "Config" make: *** [Makefile:423: build/ramstage/libgfxinit/common/g45/hw-gfx-gma-plls.o] Error 1 Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-08-11coreboot/default: fix build issue with DDR2 fixLeah Rowe
some of my DDR2 checks were unnecessary, as nicholas pointed out on irc, because they were in places that only ran if DDR2 memory was used anyway. in another, valid place, I was checking the wrong variable for knowing what memory type is used. this patch fixes build errors in lbmk: src/northbridge/intel/gm45/raminit.c: In function 'dram_program_timings': src/northbridge/intel/gm45/raminit.c:1120:29: error: 'sysinfo' undeclared (first use in this function); did you mean 'sysinfo_t'? 1120 | if (sysinfo->spd_type == DDR2) | ^~~~~~~ | sysinfo_t src/northbridge/intel/gm45/raminit.c:1120:29: note: each undeclared identifier is reported only once for each function it appears in src/northbridge/intel/gm45/raminit.c: In function 'ddr2_odt_setup': src/northbridge/intel/gm45/raminit.c:1291:21: error: 'sysinfo' undeclared (first use in this function); did you mean 'sysinfo_t'? 1291 | if (sysinfo->spd_type == DDR2) { | ^~~~~~~ | sysinfo_t make: *** [Makefile:423: build/romstage/northbridge/intel/gm45/raminit.o] Error 1 Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-08-11fix typo in dell latitude coreboot coreboot configLeah Rowe
these configs were otherwise correct, but i typo'd a variable in them when manually rebasing the old configs, after switching to nicholas's new ports implemented as variants, where the old ones in lbmk were individual board ports for those same boards. Signed-off-by: Leah Rowe <info@minifree.org>
2024-08-10coreboot/fam15h: only use this, for amd boardsLeah Rowe
it is identical to fam15h_rdimm, with _udimm now removed; the latter had a patch that added certain behaviour only intended for rdimm, but the patch in question breaks various configurations. raminit has always been unreliable on these boards. i'd rather simplify it all, in lbmk. i'll probably update this to the dasharo tree later on, specificalyl for kgpe-d16 Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-08-10coreboot/default: re-merge coreboot/i945Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-08-10coreboot/default: merge coreboot/haswellLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-08-09coreboot/dell: merge into coreboot/defaultLeah Rowe
The libgfxinit patch and other patches e.g. DDR2 fix, are now provided in coreboot/default. The Latitude E6400 is now using the newer coreboot revision from late July 2024. Some other configs had to change because of this, relating to the new way that Nicholas handles timing on LVDS displays with the E6400 port; a default 96MHz clock is still used for pixel reference clock, overridden with a value of 100MHz on other GM45 machines, where 96MHz was previously hardcoded. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-08-09coreboot/default: Update to 97bc693ab (2024-07-29)Leah Rowe
Several patches are now merged upstream and no longer needed in lbmk, such as the HP EliteBook 8560w patch, and related patches. Some patches were changed, for example the Dell Latitude ivb/snb laptops are now variants in coreboot, instead of being individual ports; now they re-use the same base code. This this, the corresponding files under config/submodules have changed, for things like 3rdparty submodules e.g. libgfxinit, and tarballs e.g. crossgcc. This is long overdue, and will enable more boards to be added. This newer revision will be used in the next release, and some follow-up patches will merge these trees into default: * coreboot/haswell * coreboot/dell Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-07-06coreboot: set build_depend on target.cfg filesLeah Rowe
set a default one in mkhelper.cfg Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22roms: only support SeaBIOS/SeaGRUB on x86Leah Rowe
Never, ever build images where GRUB is the primary payload. These options have been removed from target.cfg handling: * seabios_withgrub * grub_withseabios The "payload_grub" variable now does the same thing as the old "seabios_withgrub" variable, if set. The "grubonly" configuration is retained, and enabled by default when SeaGRUB is enabled (non-grubonly also available). Due to lbmk issue #216, it is no longer Libreboot policy to make GRUB the primary payload on any board. GRUB's sheer size and complexity, plus the large number of memory corruption issues similar to it that *have* been fixed over the years, tells me that GRUB is a liability when it is the primary payload. SeaBIOS is a much safer payload to run as primary, on x86, due to its smaller size and much more conservative development; it is simply far less likely to break. If GRUB breaks in the future, the user's machine is not bricked. This is because SeaBIOS is the default payload. Since I no longer wish to ever provide GRUB as a primary payload, supporting it in lbmk adds needless bloat that will later probably break anyway due to lack of testing, so let's just assume SeaGRUB in all cases where the user wants to use a GRUB payload. You can mitigate potential security issues with SeaBIOS by disabling option ROM execution, which can be done at runtime by inserting integers into CBFS. The SeaBIOS documentation says how to do this. Libreboot's GRUB hardening guide still says how to add a bootorder file in CBFS, making SeaBIOS only load GRUB from CBFS, and nothing else. This, combined with the disablement of option ROM execution (if using Intel graphics), pretty much provides the same security benefits as GRUB-as-primary, for example when setting a GRUB password and GPG checks, with encrypted /boot as in the hardening guide. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22lib.sh: more unified config handlingLeah Rowe
replace it with logic that simply uses "." to load files directly. for this, "vcfg" is added as a variable in coreboot target.cfg files, referring to a directory in config/vendor/ containing a file named pkg.cfg, and this file then contains the same variables as the erstwhile config/vendor/sources config/git files are now directories, also containing pkg.cfg files each with the same variables as before, such as repository link and commit hash this change results in a noticeable reduction in code complexity within the build system. unified reading of config files: new function setcfg() added to lib.sh setcfg checks if a config exists. if a 2nd argument is passed, it is used as a return value for eval, otherwise a string calling err is passed. setcfg output is passed through eval, to set strings based on config; eval must be used, so that the variables are set within the same scope, otherwise they'd be set within setcfg which could lead to some whacky results. there's still a bit more more to do, but this single change results in a substantial reduction in code complexity. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-19roms: don't insert timeout.cfgLeah Rowe
this is bloat, because it's something the user can already do at runtime configuration anyway. set it to a reasonable default of 8 seconds instead of 5, and don't honour the timeout variable in target.cfg. this will be documented in the next release. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-15grub: insert background in memdisk insteadLeah Rowe
the background is only a few kb. the whole rationale before was to limit the space used in memdisk, but this decision was made when the background was much bigger; it has since been optimised greatly, and the grub modules were heavily reduce, so it should be safe. grub's memdisk breaks when you add too much data to it. as part of simplifying the rest of lbmk, this change removes some more bloat from the rest of lbmk. handling this in the memdisk is much simpler than handling it with cbfstool. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12haswell: add Mate's patch fixing IGD port listLeah Rowe
fixes DP++ and adds a DP that wasn't even there before, on all currently supported variants of these machines Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12haswell: add Nico's patch for IGD PCI IDsLeah Rowe
the patch fixes IGD on certain xeon processors Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-12grub: only enable nvme if needed on a boardLeah Rowe
remove nvme support from the "default" grub tree now there are three trees: * default: no xhci or nvme patches * nvme: contains nvme support * xhci: contains xhci and nvme support this is in case a bug like lbmk issue #216 ever occurs again, as referenced before during lbmk audit 5 there is no indication that the nvme patch causes any issues, but after previous experience i want to be sure Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-06handle build.list from config/data/, not config/Leah Rowe
certain code checks for build.list, to skip it, for example in items() we already use config/data/grub to store grub config data that applied to all trees create these directories too: config/data/coreboot config/data/u-boot config/data/seabios move the respective build.list files in here, and also to config/data/grub now multi-tree projects contain, per directory, just the target.cfg file and the patches directory. this is much cleaner, because some of the logic can be simplified more 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-29coreboot t440p/w541: enable nvme in grub_scan_diskLeah Rowe
these laptops do not officially have nvme slots on them, but there is an ngff wifi slot which is PCI-E x1, and you can use a special adapter on it to run nvme ssds. total throughput is retarded by the x1 PCI-E configuration, but it's still faster than a sata ssd (nvmes are x4 PCI-E). support it in grub_scan_disk on the off chance that some users may make use of this. it should work just fine. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-29do not allow dashes in coreboot target namesLeah Rowe
Command: ./vendor download kcma-d8-rdimm_16mb Output was: include/lib.sh: line 115: kcma-d8-rdimm=config/vendor: No such file or directory That will have to be audited later on, but the recent more stringent error checking in vendor.sh triggered this previously untriggered error message. The error was in fact already occuring before, silently. Anyway, mitigate by renaming all coreboot targets so that they do not contain hyphens in the name. This should avoid triggering errors in that eval command, on line 115 in lib.sh Signed-off-by: Leah Rowe <leah@libreboot.org>
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-21Fix E6400 display reference clock patchesNicholas Chin
The ones I submitted before seem to have been outdated ones that don't actually build properly. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-05-20Fix E6400 display issue with 1440 x 900 panelNicholas Chin
The E6400 uses a 100 MHz reference clock on DPLL_REF_SSCLK, whereas libgfxinit assumed that the reference was always 96 MHz. The frequency difference caused by a 100 MHz reference with PLL config values calculated assuming a 96 MHz reference were not significant enough to cause noticable issues with the more common 1280 x 800 panels, but are enough to matter for the 1440 x 900 panels which use a higher pixel clock. This only affected the pre-OS graphics environment provided by libgfxinit, as Linux drivers would determine the reference clock frequency based on data in the VBT. Fix this by making the reference clock frequency in libgfxinit configurable for GM45 based on a new coreboot Kconfig, which is set to 100 MHz for the E6400. Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-05-12disable x301 for next release (for now)Leah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-11remove haswell mrc blob (libre raminit stable now)Leah Rowe
broadwell mrc is retained, because it's needed on 820 g2 it's no longer needed on haswell, because nri is stable. nri is short for "native ram initialisation", and libreboot provides this for: thinkpad t440p, thinkpad w541, dell optiplex 9020 mt, and dell optiplex 9020 sff remove, in line with libreboot's binary blob reduction policy previous revisions, prior to the recent release, stated that it would be retained for compatibility, but it's really not right to retain it, because doing so violates libreboot's policy the recent release excluded mrc-based rom images for haswell machines, providing only those rom images that use the libre raminit, while retaining support for mrc in the build system, so that users could still run the lbmk inject script on older release roms that use mrc again: libreboot's binary blob reduction policy is very clear: https://libreboot.org/news/policy.html it is a policy that can be summarised, thus: if a blob can be avoided, it must be avoided. therefore, we will avoid the Haswell MRC raminit blob 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-04d510mo and d945gclf: disable for releaseLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04nb/haswell: lock policy regs when disabling IOMMULeah Rowe
Angel Pons told me I should do it. See comments here: https://review.coreboot.org/c/coreboot/+/81016 I see no harm in complying with the request. I'll merge this into the main patch at a later date and try to get this upstreamed. Just a reminder: on Optiplex 9020 variants, Xorg locks up under Linux when tested with a graphics card; disabling IOMMU works around the issue. Intel graphics work just fine with IOMMU turned on. Libreboot disables IOMMU by default, on the 9020, so that users can install graphics cards easily. I'm pretty sure this is the correct way to do it. The machine still seems to boot, in this configuration. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04deprecate MRC 9020MT/SFF (NRI 9020 is default now)Leah Rowe
NRI is libre raminit MRC is binary blob raminit the libre raminit is stable enough now that it's default the MRC-based targets will be removed in a future release Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04mark 9020 sff/mt stable for releaseLeah Rowe
i initially decided to say unstable, but the default configuration is reliable; the only caveat is that if you enable IOMMU, you must only be using intel graphics. this is already documented in warn.txt files, and on the website, so it's more than ok to call this stable. i use one of these myself as my daily driver and it's rock solid. i haven't had any problems with it. i also sell these to people with libreboot. no problems. mark it as stable, ready for a full release. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-04mark lenovo x301 as stable for releaseLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03coreboot/default: Add patches to fix S3 on SNB/IVB LatitudesNicholas Chin
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
2024-05-03remove x220edp/x230edp (keep regular x220/x230)Leah Rowe
nitrocaster boards are hard to find nowadays and i'm not comfortable supporting the knockoff chinese gear; quality varies greatly, and i can't know how reliable they are. nitrocaster has been out of business so it's just not viable to support this mod anymore. in fact, keeping the eDP-based targets is a liability to libreboot. regular x220/x230 (non-eDP-modded) are retained. the eDP modkit from nitrocaster let you use eDP screens instead of lvds, on thinkpad x220 and x230, letting you use higher resolution screens. older lbmk revs can still be used, if you happen to come across one of these boards. i only recommend using the official nitrocaster board, if youcan find one unused. ymmv with the chinese gear. better just use an unmodded x230 or get a different machine. 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-03Enable WiFi on HP EliteBook 8560w (GPIO config)Leah Rowe
angel pons said how to fix it. more info in the patch. works perfectly. i still see that scancode in dmesg and i guess i have to assign it to some function that sets software rfkill hw rfkill is no longer set. it's unblocked, and i can use wifi. just in time for the libreboot release. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03coreboot/x301: set release=n (will re-test)Leah Rowe
was reported broken on canoeboot 0.1, which uses 2021 coreboot. we use much newer coreboot now in libreboot, but still, better be cautious. set to release=n. i'll set status and remove release=n if it works on testing Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-03mark x4x boards ready for releaseLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-02Merge pull request 'Fixed QEMU x86 target's SMBIOS informations' (#205) from ↵Leah Rowe
livio/lbmk:qemux86_fix into master Reviewed-on: https://codeberg.org/libreboot/lbmk/pulls/205
2024-05-01Fixed QEMU x86 target's SMBIOS informationslivio
2024-05-01Fixed QEMU x86 target's SMBIOS informationslivio
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-01update release status for HP machinesLeah Rowe
Signed-off-by: Leah Rowe <leah@libreboot.org>