Signed-off-by: Leah Rowe <leah@libreboot.org>

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>

the patch fixes IGD on certain xeon processors

Signed-off-by: Leah Rowe <leah@libreboot.org>

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>

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>

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>

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>

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>