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>
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>
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>
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>
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>
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>
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>
Leah Rowe