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>
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>
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>
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>
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>
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>
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>
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>
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>
set to release="n" for now until the eDP targets
are fixed.
the regular non-eDP targets are stable, and will be
released.
Signed-off-by: Leah Rowe <leah@libreboot.org>
some latitudes still used the old style for variables
in target.cfg, specifically arch="x86_64" - lbmk used to
then check that on a big if/else and translate it to the
correct target name for crossgcc, e.g. i386-elf, arm-eabi
now it just puts the arch directly, in a new variable:
xarch
change arch="x86_64" to xarch="i386-elf" in these files.
also remove a few obsolete variables. should build now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
github is unreliable. i host these files myself.
coreboot uses intel.com again now in the latest revisions, and
intel broke it before. i'm going to start backing up the acpica
releases onto my rsync server from now on, and keep patching
coreboot to use my files.
Signed-off-by: Leah Rowe <leah@libreboot.org>
raminit has never been fully reliable on this board, and so
this board has never been stable. so, now that lbmk specifies
such status per board, mark these boards as such.
Signed-off-by: Leah Rowe <leah@libreboot.org>
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>
On T60 with Libreboot 20231106 and the GRUB payload, a user
reported this error in GRUB when a battery was connected:
"alloc magic is broken at 0x7b1aedf0: 0"
This error disappears when a battery is not connected, or
when using Libreboot 20230625. The issue has persisted
through to LIbreboot 20240225 and after, and I believe the
issue will be somewhere in coreboot, not in GRUB itself.
For now, switch i945 laptops (X60, T60, Macbook2,1) back to
the February 2023 coreboot revision used in Libreboot 20230625.
A bisect can be done before the next Libreboot release, ETA
May 2024, if time permits. Otherwise, this revert should solve
the problem for now, at least so far as Libreboot is concerned.
The following coreboot patches have been backported:
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
These patches fixed S3 on GM45 machines, though it will be useful on
the i945 machines aswell.
The reason I'm doing it this way it is because I don't have a battery
for my X60 or T60, and my T60 isn't in a very good state either,
so I can't reproduce the error myself yet.
Signed-off-by: Leah Rowe <leah@libreboot.org>
i added mkukri's patch but didn't enable it. this was intentional.
this patch enables tpm by default, on all 9020 sff/mt targets.
most users probably won't need it, but enabling it won't hurt.
Signed-off-by: Leah Rowe <leah@libreboot.org>
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>
release="n" is set in target.cfg on haswell build targets
that use mrc.bin
script/update/release exports LBMK_RELEASE="y"
script/build/roms skips building a given target if release="n"
in target.cfg *and* LBMK_RELEASE="y"
you could also do the export yourself before running ./build roms,
for example:
export LBMK_RELEASE="y"
./build roms all
This would skip these ROM images. The native haswell raminit is
now stable enough in my testing, that I wish to delete the MRC-based
targets. This is in line with Libreboot's Binary Blob Reduction Policy,
which states: if a blob can be avoided, it should be avoided.
The problem is that users often run the inject script in *lbmk* from
Git, instead of from the src release archive. I forsee some users
running this on modern lbmk with older release images. If the mrc-based
target isn't there, the user may use an NRI-based target name, and
think it works; they will insert without MRC. I foresaw this ages
ago, which is why Caleb and I ensured that the script checks hashes,
and hashes are included in releases.
Therefore: for the time being, keep the MRC-based configs in lbmk
but do not include images for them in releases. This can be done
indefinitely, but I'll probably remove those configs entirely at
some point.
On the following boards, Libreboot now will *only* provide NRI-based
ROM images for the following machines:
* Dell OptiPlex 9020 SFF
* Dell OptiPlex 9020 MT
* Lenovo ThinkPad T440p
* Lenovo ThinkPad W541/W540
I now recommend exclusive use of NRI-based images, on Haswell
hardware. It's stable enough in my testing, and now supports S3.
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>
a hangover from earlier days, but i still disable it. i forgot
to do so on this config, when updating the nri code. do it now.
Signed-off-by: Leah Rowe <leah@libreboot.org>
hell added a patch fixing S3 on haswell NRI, but it seems
you still need to set 8MB CBFS size as with the MRC
tested on a t440p. S3 now works on haswell NRI.
Signed-off-by: Leah Rowe <leah@libreboot.org>
the t440p/w541 configs were re-done from scratch, because
the coreboot revisions are nearly two years apart.
i also added corebootfb configs.
hell updated their patchset. this patchset uses the following patch:
https://review.coreboot.org/c/coreboot/+/81948/1
it uses this, along with parent patches in the haswell nri patch series
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>
the grub payload was previously disabled, because the libre
mrc code sets up xhci rather than ehci, and grub did not have
xhci support (not natively).
libreboot now has xhci support in the grub payload, so enable
grub on these configurations.
Signed-off-by: Leah Rowe <leah@libreboot.org>
broadwell mrc enables both igpu and dgpu to be enabled
at any given time. if the onboard (intel) gpu is set as
primary, the logic to disable it is not executed within
coreboot; instead, the igpu is used for vga decode.
on some t440p/w541 thinkpads, both an intel and nvidia
gpu are present. in this setup, the intel gpu must be
used for vga, and all output, but rendering can be
offloaded to the nvidia gpu (nvidia optimus).
optimus would never work on haswell mrc.bin, because it
always disables the igpu when a dgpu is present, so a hack
exists in coreboot that hides the dgpu from mrc, so that the
igpu remains enabled. broadwell mrc doesn't do this, so the
option to hide PEG devices has been disabled in these
configs.
the broadwell mrc has better peg device handling, and can
support 16gb modules on broadwell hardware; it may well
support these modules on haswell hardware too, though ddr3
sodimms are very hard to find (and expensive). (and currently
untested, with this patch)
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>
Nicholas Chin