vimuser
pushed to 9020tpm at libreboot/libreboot
- 2d7debd33c 9020 sff/mt: add tpm enable patch from mate kukri
Signed-off-by: Leah Rowe <leah@libreboot.org>
- 08859bb4a5 lbmk: export TMPDIR from err.sh, not build
lbmk sets TMPDIR to /tmp, and then creates a tmpdir, then
exports *that* as the value of TMPDIR. this unified TMPDIR
location then contains all subsequent files and directories,
when any script or program makes use of /tmp, via mktemp. at
least, that's the theory!
in practise, because it was only being properly exported from
the main build scripts, subscripts that are then called were
not exporting it, at least that is my assumption because in
some cases, i found that the coreboot build system was leaving
errant files behind outside of our own TMPDIR, and that build
system did not seem to be setting TMPDIR itself; more debugging
is needed.
anyway: use the exact same logic, but do it from err.sh. since
err.sh is included from every lbmk script, that means it will
always be exported when running every single part of lbmk. this
should reduce the chance that mktemp creates files and directories
outside of our custom TMPDIR location.
this is because in lbmk, we mitigate unhandled tmpdirs/files by
unifying it in the manner described, then deleting the entire
TMPDIR on exit from the main lbmk parent process (the main
script that the user called from, which is always the "build"
file).
in lbmk, effort is made to clean up temporary files properly,
without relying on this catch-all, but we can't rely on that.
the catch-all should also be as robust as possible.
Signed-off-by: Leah Rowe <leah@libreboot.org>
- f5f2c58a0e build/roms: add missing deletion of tmp file
the temporary rom per build was not being deleted after
finishing the current target. this adds up in /tmp during
large builds, when building for many targets. fix this!
Signed-off-by: Leah Rowe <leah@libreboot.org>
- 02e4c0b28e hp820g2: allow building, but don't do release ROMs
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>
- ed0678ae2e haswell: only provide NRI-based ROMs in releases
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>
1 day ago