Add patches to convert the E6400 port into a GM45 Latitude variant and
add the E4300 as another variant, and create a config for the E4300.
Tested on my E6400 and E4300.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
Dell OptiPlex 3050 Micro
I ran ./mk -u coreboot, to update existing configs
after merging. Actualy IFD and coreboot configs will
be done in the next revision. I've already added logic
for handling deguard, in preparation for this.
Signed-off-by: Leah Rowe <leah@libreboot.org>
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>
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>
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>
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>
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>
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>
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>
sff happened to work, but mt would not boot with the patch,
because it called die() on unknown chassis type, and the gpio
happened to have a bad value in the old patch, because it wasn't
reading the right gpio.
i tested the fix on the old patch, but then decided to use
mate's new patch because instead of calling die(), it simply
boots with fan control disabled (max fan speed in that case),
if this happens again.
mt and sff have both been tested with this new version of the
patch. both of them boot, and they both have proper fan control.
Signed-off-by: Leah Rowe <leah@libreboot.org>
see:
https://review.coreboot.org/c/coreboot/+/81529
what i've merged is patchset 4. i had to rebase it slightly,
because the libreboot version has the iommu toggle on cmos
configs, which are files that mate's patch also changes,
leading to merge conflict.
Signed-off-by: Leah Rowe <leah@libreboot.org>
broadwell mrc has better peg handling and can support 16gb
modules on broadwell machines - the blob can be used on haswell
machines too, instead of haswell mrc, and it might support 16gb
modules on these machines (not yet tested, but using broadwell
mrc does at least boot as reliably as haswell mrc anyway)
one little quirk with haswell mrc is that it actually handles
vga decode, disabling the igpu entirely, when a dgpu is used.
the broadwell mrc enables both GPUs and does not handle vga
decoding, so we must handle this the usual way; my patch for
this was merged upstream and i'm also adding it to libreboot,
which currently uses an older coreboot revision. this is needed
for dgpu to work. see patch:
0040-nb-haswell-Disable-iGPU-when-dGPU-is-used.patch
broadwell mrc may also make dealing with nvidia optimus setups
more reliable, on laptops that have nvidia GPUs, but this patch
does not add bmrc configs for t440p/w541
NOTE: on t440p/w541 laptops with nvidia graphics, the video output
is wired to intel but rendering can be offloaded to nvidia. in this
setup, we want vga decode to be done on intel, so i've set these
configs to enable CONFIG_ONBOARD_VGA_IS_PRIMARY (set it to y)
Signed-off-by: Leah Rowe <leah@libreboot.org>
3rd sata slot (of 3) broken on 9020 sff, and the 3rd and 4th (of 4)
slots are broken on 9020 mt
this patch fixes them on both, so that all ports work properly
Signed-off-by: Leah Rowe <leah@libreboot.org>
Needed to make graphics cards work. Turn it on if you're using
only the Intel GPU.
With IOMMU *enabled*, graphics cards do not work reliably at all.
The cause still needs to be investigated, but the symptoms are
graphical corruption on the screen, and Xorg usually crashes.
In some cases (on some cards), TTYs can still be used; the payload
can still be used reliably, on a graphics card, but Xorg fails to
work properly.
This could be a bug in Linux drivers, instead of anything that
coreboot does (not yet tested in factory BIOS).
Leaving it off by default will ensure reliable operation on all
setups, whether an iGPU or dGPU is used.
Signed-off-by: Leah Rowe <leah@libreboot.org>
It is now possible to disable the IOMMU on Haswell
boards, by doing this on your ROM image:
./nvramtool -C libreboot.rom -w iommu=Disable
To enable it again, do this:
./nvramtool -C libreboot.rom -w iommu=Enable
If not specified, the default behaviour is *on*.
A follow-up patch will turn IOMMU *off* by default,
on Dell OptiPlex 9020 SFF/MT, by setting it as such
in cmos.default. This is to make graphics cards work
properly to work around a bug when it's turned on.
Leaving the IOMMU enabled is recommended, if it works.
It works in most cases, including on 9020 SFF/MT when
using the Intel GPU without a graphics card inserted.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Iru Cai's port from Gerrit:
https://review.coreboot.org/c/coreboot/+/39398
Now with the proper MXM structure, which removes the 30 second POST
delay. Tested with i7-2670QM, Quadro 2000M and 32GB RAM.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
The OptiPlex 9020/7020 port was merged first and was numbered 31.
Increment the numbering of the Latitude patches to reflect this.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
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>
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>
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/+/80023https://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>
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>
Inside the BIOS update, there's 68SCE and 68SCF variants.
Based on Qubes HCL and browsing linux-hardware.org, these are
Probook 6360b and Elitebook 8460p respectively.
I checked the KBC1126 EC Firmwares within the update file, both
use the exact same firmware images. Following-up will be a very
similar but untested port for 6360b.
Signed-off-by: Riku Viitanen <riku.viitanen@protonmail.com>
the ddr2 fix broke *ddr3* on gm45 thinkpads in
testing, depending on memory modules. this was
established by removing patches, re-doing
configs etc, on a user's X200 (testing gentoo
and freebsd). the X200 kept randomly rebooting
or having random glitches.
the configs themselves (gm45 thinkpads) will
also be re-done, because i found minor issues
unrelated, but this patch moves dell e6400 to
its own tree. the ddr2 fix is no longer present
in coreboot/default, only coreboot/dell.
i noticed minor differences in gm45 thinkpad
configs, when re-doing the configs, versus
what are currently in lbmk master; for instance,
vbt was not enabled anymore, on thinkpad x200.
modifications to these will be done separately.
Signed-off-by: Leah Rowe <leah@libreboot.org>
The original E6430 patch included the Intel VBT file, but did not
actually enable it in Kconfig. Update the patch to enable it and
update the E6430 configs.
it's preferable that the vram setting be as high as
feasible, for users. we overlooked this on some
newer platforms that were added, over several
releases. these levels won't offend most users,
and people who want less can always turn it down
Signed-off-by: Leah Rowe <leah@libreboot.org>
My previous fix to revert didn't fix S3 on GM45, one
of the platforms reported fixed by 78263; I'm merging
that instead, at patch set 10.
It is referenced by 78815/1 which was split from it,
so merge that too (restores overrides of higher values,
on certain platforms that we don't use yet).
https://review.coreboot.org/c/coreboot/+/78623/10https://review.coreboot.org/c/coreboot/+/78815/1
Accordingly, update configs to match the new default.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the patch included in this revision is pulled from:
https://review.coreboot.org/c/coreboot/+/54024/2
contrary to hell's assertion of "not for merge", this does
in fact work nicely on a dell e6400; nicholas chin tested
on e6400 and found that those RCOMP values are the same
nicholas was testing some errant modules that seemed to
fail raminit in coreboot. in some cases, dell e6400 would
regularly fail coldboot even though reboot was ok; this was
therefore the cause of suspicioun for it being raminit-related
with this patch from hell (Angel Pons, but knows as hell
on IRC) it should fix boot issue on Dell Latitude E6400
Signed-off-by: Leah Rowe <leah@libreboot.org>
the patch:
https://review.coreboot.org/c/coreboot/+/78270
this has been reverted, because it caused s3 resume
issues on most intel laptops in libreboot.
i was going to merge this instead:
https://review.coreboot.org/c/coreboot/+/78623
however, it's under review, and this doesn't change
to the old behaviour; it keeps the new universal
config, but changes the default
we know the old logic works, so keep that for now.
in fact, the offending patch was only merged to
main in coreboot, one day before i recently
updated coreboot revs in coreboot/default - i used
a 12 october revision, the patch above is 11 october
i then ran "./update trees -u coreboot" which updated
the heap sizes back to the old defaults. this should
fix s3 suspend/resume where it was broken, in the
libreboot 20231021 release - a point release with this
and a few other fixes is planned soon.
Signed-off-by: Leah Rowe <leah@libreboot.org>
github's httpd b0rked the fuck out and i didn't want to wait
for them to fix it (ssl cert error) before i continued a build.
i now host the relevant acpica tarball on libreboot rsync,
mirrored to princeton.
Signed-off-by: Leah Rowe <leah@libreboot.org>
Leah Rowe