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>
see:
https://github.com/9elements/grub/commits/xhci-module-upstreaming-squash_v4/
grub only supports xhci on bios/uefi targets, but not coreboot.
some newer machines don't have ps/2 controllers, and boot in a
way where ehci isn't available at startup; the controller can't
be used by ehci code, there must be xhci support.
the code is from Patrick Rudolph working on behalf of 9elements.
the code was also sent here for review:
https://lists.gnu.org/archive/html/grub-devel/2020-12/msg00111.html
however, upstream never merged these patches. libreboot will have
to maintain these from now on. the patches have been rebased for
use with grub 2.12.
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>
lbmk otherwise uses nproc to set the number of build threads,
in these places:
* generic make commands in script/update/trees
* crossgcc make command in script/update/trees
the -T0 option is also used in script/update/release, when running
tar.
with this change, you can do:
export LBMK_THREADS=x
where x is the number of threads. when you then run
lbmk, your chosen number of threads will override
the default. this may be useful on a host that does
not have a lot of memory.
Signed-off-by: Leah Rowe <leah@libreboot.org>
in shell scripts, a function named the same as a program included in
the $PATH will override that program. for example, you could make a
function called ls() and this would override the standand "ls".
in lbmk, a part of it was first trying to run the "fail" command,
deferring to "err", because some scripts call fail() which does
some minor cleanup before calling err.
in most cases, fail() is not defined, and it's possible that the user
could have a program called "fail" in their $PATH, the behaviour of
which we could not determine, and it could have disastrous effects.
lbmk error handling has been re-engineered in such a way that the
err function is defined in a variable, which defaults to err_ which
calls err_, so defined under include/err.sh.
in functions that require cleanup prior to error handling, a fail()
function is still defined, and err is overridden, thus:
err="fail"
this change has made xx_() obsolete, so now only x_ is used. the x_
function is a wrapper that can be used to run a command and exit with
non-zero status (from lbmk) if the command fails. the xx_ command
did the same thing, but called fail() which would have called err();
now everything is $err
example:
rm -f "$filename" || err "could not delete file"
this would now be:
rm -f "$filename" || $err "could not delete file"
overriding of err= must be done *after* including err.sh. for
example:
err="fail"
. "include/err.sh"
^ this is wrong. instead, one must do:
. "include/err.sh"
err="fail"
this is because err is set as a global variable under err.sh
the new error handling is much cleaner, and safer. it also reduces
the chance of mistakes such as: calling err when you meant to
call fail. this is because the standard way is now to call $err,
so you set err="fail" at the top of the script and all is well.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is a copy of coreboot's autoport utility, with a patch applied to
support Haswell/Lynx Point platforms. That patch is currently in review
on coreboot's Gerrit.
https://review.coreboot.org/c/coreboot/+/30890
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
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>
the current entry is fine, but it would then not support
other configs of different flash sizes, unless they are
explicitly defined.
Signed-off-by: Leah Rowe <leah@libreboot.org>
This is required by the Latitude E5530, which uses a Broadcom NIC
instead of the Intel ones. The original port was missing this file.
Signed-off-by: Nicholas Chin <nic.c3.14@gmail.com>
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>
this merges the fix from:
https://codeberg.org/libreboot/pico-serprog/pulls/1
however, PRs are not to be sent there. riku merged it in
his repository, and i pulled it in the mirror hosted
on libreboot codeberg
Signed-off-by: Leah Rowe <leah@libreboot.org>
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>
i enabled it but it's buggy according to comments on gerrit.
disable for now. dgpu didn't work anyway, even with it turned
off, when i had this tested.
Signed-off-by: Leah Rowe <leah@libreboot.org>
keep dell9020mt_12mb
dell9020mtvga_12mb doesn't actually work (was tried for
running a graphics card on its own, with no igpu init)
Signed-off-by: Leah Rowe <leah@libreboot.org>
this was done automatically by running:
./update trees -u coreboot
this has to be done when adding patches for now board ports,
because of the way lbmk and also coreboot's build systems work.
the configs just have to be re-generated to include a line
that says the entry for the newly added boards isn't set. look
at the diff of this commit as an example.
Signed-off-by: Leah Rowe <leah@libreboot.org>
./update release -m u-boot
if someone just wants to make u-boot, they can
use this and it tars up all the trees.
Signed-off-by: Leah Rowe <info@minifree.org>
on a dgpu setup, igpu was still in use, when tested
by a user. do separate roms that don't enable anything
vga in coreboot, relying instead only on seabios to
execute a vga rom. these roms will only work if you
have a graphics card.
Signed-off-by: Leah Rowe <info@minifree.org>
Leah Rowe