2023-09-25 01:19:30 +00:00
|
|
|
# SPDX-License-Identifier: GPL-3.0-only
|
2024-05-26 00:54:36 +00:00
|
|
|
# Copyright (c) 2022 Caleb La Grange <thonkpeasant@protonmail.com>
|
|
|
|
# Copyright (c) 2022 Ferass El Hafidi <vitali64pmemail@protonmail.com>
|
|
|
|
# Copyright (c) 2023-2024 Leah Rowe <leah@libreboot.org>
|
2022-11-14 00:51:12 +00:00
|
|
|
|
2024-05-26 00:54:36 +00:00
|
|
|
e6400_unpack="$PWD/src/bios_extract/dell_inspiron_1100_unpacker.py"
|
|
|
|
me7updateparser="$PWD/util/me7_update_parser/me7_update_parser.py"
|
|
|
|
pfs_extract="$PWD/src/biosutilities/Dell_PFS_Extract.py"
|
2024-06-07 20:30:43 +00:00
|
|
|
uefiextract="$PWD/elf/uefitool/uefiextract"
|
2024-05-16 02:56:52 +00:00
|
|
|
vendir="vendorfiles"
|
2024-07-18 23:48:09 +00:00
|
|
|
appdir="$vendir/app"
|
2024-06-06 01:45:09 +00:00
|
|
|
cbcfgsdir="config/coreboot"
|
2023-10-15 10:22:43 +00:00
|
|
|
|
vendor.sh: don't load entire coreboot configs
instead, only grep for the entries required, such
as Intel ME paths.
some variables in coreboot configs use $(), which
is used in *make*, on the coreboot build system, and
there refers to variables.
here, we are sourcing them from sh, which treats this
as a mini subshell to run a command; for example
CONFIG_FOO would be executed, which is bad.
The current logic still theoretically has this problem,
with this patch, but the entries we scan from the configs
do not currently have variable names in the strings.
So: filter out just what we need, into a temporary config,
when scanning for vendor files in coreboot configs, and
use the temporary config.
This fixes a build error when compiling for e5520_6mb.
Signed-off-by: Leah Rowe <info@minifree.org>
2024-08-11 20:19:33 +00:00
|
|
|
cv="CONFIG_HAVE_ME_BIN CONFIG_ME_BIN_PATH CONFIG_INCLUDE_SMSC_SCH5545_EC_FW \
|
|
|
|
CONFIG_SMSC_SCH5545_EC_FW_FILE CONFIG_KBC1126_FIRMWARE CONFIG_KBC1126_FW1 \
|
|
|
|
CONFIG_KBC1126_FW2 CONFIG_KBC1126_FW1_OFFSET CONFIG_KBC1126_FW2_OFFSET \
|
|
|
|
CONFIG_VGA_BIOS_FILE CONFIG_VGA_BIOS_ID CONFIG_BOARD_DELL_E6400 \
|
|
|
|
CONFIG_HAVE_MRC CONFIG_MRC_FILE CONFIG_HAVE_REFCODE_BLOB \
|
T480/T480S: Support fetching ThunderBolt firmware
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-18 02:20:08 +00:00
|
|
|
CONFIG_REFCODE_BLOB_FILE CONFIG_GBE_BIN_PATH CONFIG_IFD_BIN_PATH \
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
CONFIG_LENOVO_TBFW_BIN CONFIG_FSP_FD_PATH CONFIG_FSP_M_FILE \
|
|
|
|
CONFIG_FSP_S_FILE CONFIG_FSP_S_CBFS CONFIG_FSP_M_CBFS CONFIG_FSP_USE_REPO \
|
|
|
|
CONFIG_FSP_FULL_FD"
|
vendor.sh: don't load entire coreboot configs
instead, only grep for the entries required, such
as Intel ME paths.
some variables in coreboot configs use $(), which
is used in *make*, on the coreboot build system, and
there refers to variables.
here, we are sourcing them from sh, which treats this
as a mini subshell to run a command; for example
CONFIG_FOO would be executed, which is bad.
The current logic still theoretically has this problem,
with this patch, but the entries we scan from the configs
do not currently have variable names in the strings.
So: filter out just what we need, into a temporary config,
when scanning for vendor files in coreboot configs, and
use the temporary config.
This fixes a build error when compiling for e5520_6mb.
Signed-off-by: Leah Rowe <info@minifree.org>
2024-08-11 20:19:33 +00:00
|
|
|
|
2024-06-22 03:06:07 +00:00
|
|
|
eval `setvars "" EC_url_bkup EC_hash DL_hash DL_url_bkup MRC_refcode_gbe vcfg \
|
2023-10-15 10:22:43 +00:00
|
|
|
E6400_VGA_DL_hash E6400_VGA_DL_url E6400_VGA_DL_url_bkup E6400_VGA_offset \
|
vendor.sh: don't load entire coreboot configs
instead, only grep for the entries required, such
as Intel ME paths.
some variables in coreboot configs use $(), which
is used in *make*, on the coreboot build system, and
there refers to variables.
here, we are sourcing them from sh, which treats this
as a mini subshell to run a command; for example
CONFIG_FOO would be executed, which is bad.
The current logic still theoretically has this problem,
with this patch, but the entries we scan from the configs
do not currently have variable names in the strings.
So: filter out just what we need, into a temporary config,
when scanning for vendor files in coreboot configs, and
use the temporary config.
This fixes a build error when compiling for e5520_6mb.
Signed-off-by: Leah Rowe <info@minifree.org>
2024-08-11 20:19:33 +00:00
|
|
|
E6400_VGA_romname SCH5545EC_DL_url_bkup SCH5545EC_DL_hash _dest tree \
|
2024-05-26 00:54:36 +00:00
|
|
|
mecleaner kbc1126_ec_dump MRC_refcode_cbtree new_mac _dl SCH5545EC_DL_url \
|
vendor.sh: don't load entire coreboot configs
instead, only grep for the entries required, such
as Intel ME paths.
some variables in coreboot configs use $(), which
is used in *make*, on the coreboot build system, and
there refers to variables.
here, we are sourcing them from sh, which treats this
as a mini subshell to run a command; for example
CONFIG_FOO would be executed, which is bad.
The current logic still theoretically has this problem,
with this patch, but the entries we scan from the configs
do not currently have variable names in the strings.
So: filter out just what we need, into a temporary config,
when scanning for vendor files in coreboot configs, and
use the temporary config.
This fixes a build error when compiling for e5520_6mb.
Signed-off-by: Leah Rowe <info@minifree.org>
2024-08-11 20:19:33 +00:00
|
|
|
archive EC_url boarddir rom cbdir DL_url nukemode cbfstoolref vrelease \
|
2024-12-01 00:39:52 +00:00
|
|
|
verify _7ztest ME11bootguard ME11delta ME11version ME11sku ME11pch \
|
T480/T480S: Support fetching ThunderBolt firmware
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-18 02:20:08 +00:00
|
|
|
IFD_platform ifdprefix cdir sdir _me _metmp mfs TBFW_url_bkup TBFW_url \
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
TBFW_hash TBFW_size FSPFD_hash $cv`
|
2023-10-15 10:22:43 +00:00
|
|
|
|
2024-05-11 04:33:43 +00:00
|
|
|
vendor_download()
|
2023-05-14 19:06:03 +00:00
|
|
|
{
|
2024-07-26 14:24:00 +00:00
|
|
|
[ $# -gt 0 ] || $err "No argument given"; export PATH="$PATH:/sbin"
|
|
|
|
board="$1"; readcfg && readkconfig && bootstrap && getfiles; :
|
2023-05-14 19:06:03 +00:00
|
|
|
}
|
|
|
|
|
2024-06-29 00:26:31 +00:00
|
|
|
readkconfig()
|
2023-05-14 19:06:03 +00:00
|
|
|
{
|
2024-06-27 02:18:23 +00:00
|
|
|
check_defconfig "$boarddir" 1>"$TMPDIR/vendorcfg.list" && return 1
|
vendor.sh: don't load entire coreboot configs
instead, only grep for the entries required, such
as Intel ME paths.
some variables in coreboot configs use $(), which
is used in *make*, on the coreboot build system, and
there refers to variables.
here, we are sourcing them from sh, which treats this
as a mini subshell to run a command; for example
CONFIG_FOO would be executed, which is bad.
The current logic still theoretically has this problem,
with this patch, but the entries we scan from the configs
do not currently have variable names in the strings.
So: filter out just what we need, into a temporary config,
when scanning for vendor files in coreboot configs, and
use the temporary config.
This fixes a build error when compiling for e5520_6mb.
Signed-off-by: Leah Rowe <info@minifree.org>
2024-08-11 20:19:33 +00:00
|
|
|
|
|
|
|
rm -f "$TMPDIR/tmpcbcfg" || $err "!rm -f \"$TMPDIR/tmpcbcfg\""
|
2024-05-28 23:48:18 +00:00
|
|
|
while read -r cbcfgfile; do
|
vendor.sh: don't load entire coreboot configs
instead, only grep for the entries required, such
as Intel ME paths.
some variables in coreboot configs use $(), which
is used in *make*, on the coreboot build system, and
there refers to variables.
here, we are sourcing them from sh, which treats this
as a mini subshell to run a command; for example
CONFIG_FOO would be executed, which is bad.
The current logic still theoretically has this problem,
with this patch, but the entries we scan from the configs
do not currently have variable names in the strings.
So: filter out just what we need, into a temporary config,
when scanning for vendor files in coreboot configs, and
use the temporary config.
This fixes a build error when compiling for e5520_6mb.
Signed-off-by: Leah Rowe <info@minifree.org>
2024-08-11 20:19:33 +00:00
|
|
|
for cbc in $cv; do
|
|
|
|
rm -f "$TMPDIR/tmpcbcfg2" || \
|
|
|
|
$err "!rm $TMPDIR/tmpcbcfg2"
|
|
|
|
grep "$cbc" "$cbcfgfile" 1>"$TMPDIR/tmpcbcfg2" \
|
|
|
|
2>/dev/null || :
|
|
|
|
[ -f "$TMPDIR/tmpcbcfg2" ] || continue
|
|
|
|
cat "$TMPDIR/tmpcbcfg2" >> "$TMPDIR/tmpcbcfg" || \
|
|
|
|
$err "!cat $TMPDIR/tmpcbcfg2"
|
|
|
|
done
|
2024-06-27 02:18:23 +00:00
|
|
|
done < "$TMPDIR/vendorcfg.list"
|
2024-05-11 04:33:43 +00:00
|
|
|
|
vendor.sh: don't load entire coreboot configs
instead, only grep for the entries required, such
as Intel ME paths.
some variables in coreboot configs use $(), which
is used in *make*, on the coreboot build system, and
there refers to variables.
here, we are sourcing them from sh, which treats this
as a mini subshell to run a command; for example
CONFIG_FOO would be executed, which is bad.
The current logic still theoretically has this problem,
with this patch, but the entries we scan from the configs
do not currently have variable names in the strings.
So: filter out just what we need, into a temporary config,
when scanning for vendor files in coreboot configs, and
use the temporary config.
This fixes a build error when compiling for e5520_6mb.
Signed-off-by: Leah Rowe <info@minifree.org>
2024-08-11 20:19:33 +00:00
|
|
|
eval `setcfg "$TMPDIR/tmpcbcfg"`
|
|
|
|
|
2023-09-27 14:01:49 +00:00
|
|
|
for c in CONFIG_HAVE_MRC CONFIG_HAVE_ME_BIN CONFIG_KBC1126_FIRMWARE \
|
T480/T480S: Support fetching ThunderBolt firmware
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-18 02:20:08 +00:00
|
|
|
CONFIG_VGA_BIOS_FILE CONFIG_INCLUDE_SMSC_SCH5545_EC_FW \
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
CONFIG_LENOVO_TBFW_BIN CONFIG_FSP_M_FILE CONFIG_FSP_S_FILE; do
|
2024-05-29 02:23:30 +00:00
|
|
|
eval "[ \"\${$c}\" = \"/dev/null\" ] && continue"
|
lib.sh: more unified config handling
replace it with logic that simply uses "." to load
files directly. for this, "vcfg" is added as a variable
in coreboot target.cfg files, referring to a directory
in config/vendor/ containing a file named pkg.cfg, and
this file then contains the same variables as the
erstwhile config/vendor/sources
config/git files are now directories, also containing
pkg.cfg files each with the same variables as before,
such as repository link and commit hash
this change results in a noticeable reduction in code
complexity within the build system.
unified reading of config files: new function setcfg()
added to lib.sh
setcfg checks if a config exists. if a 2nd argument is
passed, it is used as a return value for eval, otherwise
a string calling err is passed. setcfg output is passed
through eval, to set strings based on config; eval must
be used, so that the variables are set within the same
scope, otherwise they'd be set within setcfg which could
lead to some whacky results.
there's still a bit more more to do, but this single change
results in a substantial reduction in code complexity.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22 01:35:25 +00:00
|
|
|
eval "[ -z \"\${$c}\" ] && continue"
|
|
|
|
eval `setcfg "config/vendor/$vcfg/pkg.cfg"`; return 0
|
2023-09-27 14:01:49 +00:00
|
|
|
done
|
lib.sh: more unified config handling
replace it with logic that simply uses "." to load
files directly. for this, "vcfg" is added as a variable
in coreboot target.cfg files, referring to a directory
in config/vendor/ containing a file named pkg.cfg, and
this file then contains the same variables as the
erstwhile config/vendor/sources
config/git files are now directories, also containing
pkg.cfg files each with the same variables as before,
such as repository link and commit hash
this change results in a noticeable reduction in code
complexity within the build system.
unified reading of config files: new function setcfg()
added to lib.sh
setcfg checks if a config exists. if a 2nd argument is
passed, it is used as a return value for eval, otherwise
a string calling err is passed. setcfg output is passed
through eval, to set strings based on config; eval must
be used, so that the variables are set within the same
scope, otherwise they'd be set within setcfg which could
lead to some whacky results.
there's still a bit more more to do, but this single change
results in a substantial reduction in code complexity.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-06-22 01:35:25 +00:00
|
|
|
printf "Vendor files not needed for: %s\n" "$board" 1>&2; return 1
|
2023-05-14 19:06:03 +00:00
|
|
|
}
|
|
|
|
|
2024-06-20 00:15:06 +00:00
|
|
|
bootstrap()
|
2023-05-14 19:06:03 +00:00
|
|
|
{
|
2024-07-26 14:24:00 +00:00
|
|
|
x_ ./mk -f coreboot ${cbdir##*/}
|
lib.sh: new function mk() to handle trees in bulk
single-tree projects cannot be handled in bulk, e.g.
./mk -f project1 project2 project3
that is still the case, from the shell, but internally
it is now possible:
mk -f project1 project2 project3
mk() is a function that simply handles the given flag,
and all projects specified.
it does not handle cases without argument, for example
you cannot do:
mk -f
arguments must be provided. it can be used internally,
to simplify cases where multiple single-tree projects
must be handled, but *also* allows multi-tree projects
to be specified, without being able to actually handle
trees within that multi-tree project; so for example,
you can only specify coreboot, and then it would run
on every coreboot tree.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-07-28 12:30:25 +00:00
|
|
|
mk -b uefitool biosutilities bios_extract
|
2024-06-29 01:11:45 +00:00
|
|
|
[ -d "${kbc1126_ec_dump%/*}" ] && x_ make -C "$cbdir/util/kbc1126"
|
NEW MAINBOARD: HP EliteBook 820 G2
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>
2024-01-07 13:25:33 +00:00
|
|
|
[ -n "$MRC_refcode_cbtree" ] && \
|
2024-06-29 00:27:42 +00:00
|
|
|
cbfstoolref="elf/cbfstool/$MRC_refcode_cbtree/cbfstool" && \
|
2024-07-26 14:24:00 +00:00
|
|
|
x_ ./mk -d coreboot $MRC_refcode_cbtree; return 0
|
2023-04-01 10:13:04 +00:00
|
|
|
}
|
|
|
|
|
2024-06-20 00:15:06 +00:00
|
|
|
getfiles()
|
2023-05-14 19:06:03 +00:00
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -z "$CONFIG_HAVE_ME_BIN" ] || fetch intel_me "$DL_url" \
|
|
|
|
"$DL_url_bkup" "$DL_hash" "$CONFIG_ME_BIN_PATH"
|
|
|
|
[ -z "$CONFIG_INCLUDE_SMSC_SCH5545_EC_FW" ] || fetch sch5545ec \
|
|
|
|
"$SCH5545EC_DL_url" "$SCH5545EC_DL_url_bkup" "$SCH5545EC_DL_hash" \
|
|
|
|
"$CONFIG_SMSC_SCH5545_EC_FW_FILE"
|
|
|
|
[ -z "$CONFIG_KBC1126_FIRMWARE" ] || fetch kbc1126ec "$EC_url" \
|
|
|
|
"$EC_url_bkup" "$EC_hash" "$CONFIG_KBC1126_FW1"
|
2024-12-02 06:12:59 +00:00
|
|
|
[ -z "$CONFIG_VGA_BIOS_FILE" ] || fetch e6400vga "$E6400_VGA_DL_url" \
|
|
|
|
"$E6400_VGA_DL_url_bkup" "$E6400_VGA_DL_hash" "$CONFIG_VGA_BIOS_FILE"
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -z "$CONFIG_HAVE_MRC" ] || fetch "mrc" "$MRC_url" "$MRC_url_bkup" \
|
T480/T480S: Support fetching ThunderBolt firmware
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-18 02:20:08 +00:00
|
|
|
"$MRC_hash" "$CONFIG_MRC_FILE"
|
|
|
|
[ -z "$CONFIG_LENOVO_TBFW_BIN" ] || fetch "tbfw" "$TBFW_url" \
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
"$TBFW_url_bkup" "$TBFW_hash" "$CONFIG_LENOVO_TBFW_BIN"
|
|
|
|
#
|
|
|
|
# in the future, we might have libre fsp-s and then fsp-m.
|
|
|
|
# therefore, handle them separately, in case one of them is libre; if
|
|
|
|
# one of them was, the path wouldn't be set.
|
|
|
|
#
|
|
|
|
[ -z "$CONFIG_FSP_M_FILE" ] || fetch "fspm" "$CONFIG_FSP_FD_PATH" \
|
|
|
|
"$CONFIG_FSP_FD_PATH" "$FSPFD_hash" "$CONFIG_FSP_M_FILE" copy
|
|
|
|
[ -z "$CONFIG_FSP_S_FILE" ] || fetch "fsps" "$CONFIG_FSP_FD_PATH" \
|
|
|
|
"$CONFIG_FSP_FD_PATH" "$FSPFD_hash" "$CONFIG_FSP_S_FILE" copy; :
|
2022-11-14 00:51:12 +00:00
|
|
|
}
|
|
|
|
|
2023-10-15 09:00:23 +00:00
|
|
|
fetch()
|
|
|
|
{
|
2024-06-29 01:21:00 +00:00
|
|
|
dl_type="$1"; dl="$2"; dl_bkup="$3"; dlsum="$4"; _dest="${5##*../}"
|
2024-07-18 23:31:57 +00:00
|
|
|
[ "$5" = "/dev/null" ] && return 0; _dl="$XBMK_CACHE/file/$dlsum"
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
if [ "$dl_type" = "fspm" ] || [ "$dl_type" = "fsps" ]; then
|
|
|
|
# HACK: if grabbing fsp from coreboot, fix the path for lbmk
|
|
|
|
for _cdl in dl dl_bkup; do
|
|
|
|
eval "$_cdl=\"\${$_cdl##*../}\"; _cdp=\"\$$_cdl\""
|
|
|
|
[ -f "$_cdp" ] || _cdp="$cbdir/$_cdp"
|
|
|
|
[ -f "$_cdp" ] && eval "$_cdl=\"$_cdp\""
|
|
|
|
done
|
|
|
|
fi
|
2023-10-15 09:00:23 +00:00
|
|
|
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
dlop="curl" && [ $# -gt 5 ] && dlop="$6"
|
|
|
|
download "$dl" "$dl_bkup" "$_dl" "$dlsum" "$dlop"
|
2023-10-15 09:00:23 +00:00
|
|
|
|
2024-07-26 14:24:00 +00:00
|
|
|
rm -Rf "${_dl}_extracted" || $err "!rm -Rf ${_ul}_extracted"
|
2024-06-30 18:22:58 +00:00
|
|
|
e "$_dest" f && return 0
|
|
|
|
|
|
|
|
mkdir -p "${_dest%/*}" || $err "mkdirs: !mkdir -p ${_dest%/*}"
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
remkdir "$appdir"; extract_archive "$_dl" "$appdir" "$dl_type" || \
|
2024-07-26 14:24:00 +00:00
|
|
|
[ "$dl_type" = "e6400vga" ] || $err "mkd $_dest $dl_type: !extract"
|
2023-10-15 09:00:23 +00:00
|
|
|
|
2024-07-26 14:24:00 +00:00
|
|
|
eval "extract_$dl_type"; set -u -e
|
|
|
|
e "$_dest" f missing && $err "!extract_$dl_type"; :
|
2023-10-15 09:00:23 +00:00
|
|
|
}
|
|
|
|
|
2023-09-28 00:21:58 +00:00
|
|
|
extract_intel_me()
|
2023-05-14 19:06:03 +00:00
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
e "$mecleaner" f not && $err "$cbdir: me_cleaner missing"
|
|
|
|
|
2024-12-01 00:39:52 +00:00
|
|
|
cdir="$PWD/$appdir"
|
|
|
|
_me="$PWD/$_dest"
|
|
|
|
_metmp="$PWD/tmp/me.bin"
|
|
|
|
|
|
|
|
mfs="" && [ "$ME11bootguard" = "y" ] && mfs="--whitelist MFS" && \
|
|
|
|
chkvars ME11delta ME11version ME11sku ME11pch
|
|
|
|
[ "$ME11bootguard" = "y" ] && x_ ./mk -f deguard
|
|
|
|
|
|
|
|
x_ mkdir -p tmp
|
|
|
|
|
|
|
|
extract_intel_me_bruteforce
|
|
|
|
if [ "$ME11bootguard" = "y" ]; then
|
|
|
|
apply_me11_deguard_mod
|
|
|
|
else
|
|
|
|
mv "$_metmp" "$_me" || $err "!mv $_metmp" "$_me"
|
2024-09-24 15:47:21 +00:00
|
|
|
fi
|
2024-12-01 00:39:52 +00:00
|
|
|
}
|
2024-09-24 15:47:21 +00:00
|
|
|
|
2024-12-01 00:39:52 +00:00
|
|
|
extract_intel_me_bruteforce()
|
|
|
|
{
|
|
|
|
[ $# -gt 0 ] && cdir="$1"
|
NEW MAINBOARD: HP EliteBook 820 G2
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>
2024-01-07 13:25:33 +00:00
|
|
|
|
2024-12-01 00:39:52 +00:00
|
|
|
e "$_metmp" f && return 0
|
2023-04-01 12:47:01 +00:00
|
|
|
|
2024-12-01 00:39:52 +00:00
|
|
|
[ -z "$sdir" ] && sdir="$(mktemp -d)"
|
safer, simpler error handling in lbmk
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>
2024-03-27 01:19:39 +00:00
|
|
|
mkdir -p "$sdir" || $err "extract_intel_me: !mkdir -p \"$sdir\""
|
./vendor download: more fine-tuned error control
By default, the build system does set -u -e
Some errors are unavoidable and have to be handled, so
we have to set +u +e (turn off error handling in sh),
when downloading vendor files, but only certain parts of
vendor.sh trigger errors (which cause an exit).
Replace the current bazooka approach with a more fine
grained approach, turning error handling back on again
when it is safe to do so.
In the parts of the code where it is disabled, the code
is written very, very carefully, with errors still handled
manually, but more careful auditing is required.
This change has been tested and makes the command much
safer to run. In security (or any bug auditing), it is
the principle of least privilege that holds true.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-29 00:49:07 +00:00
|
|
|
|
|
|
|
set +u +e
|
2023-04-01 16:59:09 +00:00
|
|
|
(
|
2023-12-24 09:04:36 +00:00
|
|
|
[ "${cdir#/a}" != "$cdir" ] && cdir="${cdir#/}"
|
safer, simpler error handling in lbmk
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>
2024-03-27 01:19:39 +00:00
|
|
|
cd "$cdir" || $err "extract_intel_me: !cd \"$cdir\""
|
2023-04-01 16:59:09 +00:00
|
|
|
for i in *; do
|
2024-12-01 00:39:52 +00:00
|
|
|
[ -f "$_metmp" ] && break
|
2023-12-24 09:04:36 +00:00
|
|
|
[ -L "$i" ] && continue
|
|
|
|
if [ -f "$i" ]; then
|
2024-12-01 00:39:52 +00:00
|
|
|
_r="-r" && [ -n "$mfs" ] && _r=""
|
|
|
|
"$mecleaner" $mfs $_r -t -O "$sdir/vendorfile" \
|
|
|
|
-M "$_metmp" "$i" && break
|
|
|
|
"$mecleaner" $mfs $_r -t -O "$_metmp" "$i" && break
|
|
|
|
"$me7updateparser" -O "$_metmp" "$i" && break
|
2023-04-01 16:59:09 +00:00
|
|
|
_7ztest="${_7ztest}a"
|
2023-12-24 09:04:36 +00:00
|
|
|
extract_archive "$i" "$_7ztest" || continue
|
2024-12-01 00:39:52 +00:00
|
|
|
extract_intel_me_bruteforce "$cdir/$_7ztest"
|
2023-04-01 16:59:09 +00:00
|
|
|
elif [ -d "$i" ]; then
|
2024-12-01 00:39:52 +00:00
|
|
|
extract_intel_me_bruteforce "$cdir/$i"
|
2023-04-01 16:59:09 +00:00
|
|
|
else
|
2023-07-29 06:28:36 +00:00
|
|
|
continue
|
2023-04-01 16:59:09 +00:00
|
|
|
fi
|
2024-07-26 14:24:00 +00:00
|
|
|
cdir="$1"; [ "${cdir#/a}" != "$cdir" ] && cdir="${cdir#/}"
|
2024-05-26 00:54:36 +00:00
|
|
|
cd "$cdir" || :
|
2023-04-01 16:59:09 +00:00
|
|
|
done
|
|
|
|
)
|
2024-05-26 00:54:36 +00:00
|
|
|
rm -Rf "$sdir" || $err "extract_intel_me: !rm -Rf $sdir"
|
2022-11-14 00:51:12 +00:00
|
|
|
}
|
|
|
|
|
2024-12-01 00:39:52 +00:00
|
|
|
apply_me11_deguard_mod()
|
2024-09-24 15:47:21 +00:00
|
|
|
{
|
|
|
|
(
|
2024-12-01 00:39:52 +00:00
|
|
|
x_ cd src/deguard/
|
|
|
|
./finalimage.py --delta "data/delta/$ME11delta" \
|
|
|
|
--version "$ME11version" \
|
|
|
|
--pch "$ME11pch" --sku "$ME11sku" --fake-fpfs data/fpfs/zero \
|
|
|
|
--input "$_metmp" --output "$_me" || \
|
|
|
|
$err "Error running deguard for $_me"
|
|
|
|
) || $err "Error running deguard for $_me"
|
2024-09-24 15:47:21 +00:00
|
|
|
}
|
|
|
|
|
2023-10-15 09:00:23 +00:00
|
|
|
extract_archive()
|
|
|
|
{
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
if [ $# -gt 2 ]; then
|
|
|
|
if [ "$3" = "fspm" ] || [ "$3" = "fsps" ]; then
|
|
|
|
decat_fspfd "$1" "$2"
|
|
|
|
return 0
|
|
|
|
fi
|
|
|
|
fi
|
|
|
|
|
2024-12-22 23:13:43 +00:00
|
|
|
innoextract "$1" -d "$2" || python "$pfs_extract" "$1" -e || 7z x \
|
2024-09-05 18:46:37 +00:00
|
|
|
"$1" -o"$2" || unar "$1" -o "$2" || unzip "$1" -d "$2" || return 1
|
2024-12-06 10:34:36 +00:00
|
|
|
|
|
|
|
[ ! -d "${_dl}_extracted" ] || cp -R "${_dl}_extracted" "$2" || \
|
|
|
|
$err "!mv '${_dl}_extracted' '$2'"; :
|
2023-10-15 09:00:23 +00:00
|
|
|
}
|
|
|
|
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
decat_fspfd()
|
|
|
|
{
|
|
|
|
_fspfd="$1"
|
|
|
|
_fspdir="$2"
|
|
|
|
_fspsplit="$cbdir/3rdparty/fsp/Tools/SplitFspBin.py"
|
|
|
|
|
|
|
|
$python "$_fspsplit" split -f "$_fspfd" -o "$_fspdir" -n "Fsp.fd" || \
|
|
|
|
$err "decat_fspfd '$1' '$2': Cannot de-concatenate"; :
|
|
|
|
}
|
|
|
|
|
2023-09-28 00:21:58 +00:00
|
|
|
extract_kbc1126ec()
|
2023-05-14 19:06:03 +00:00
|
|
|
{
|
2024-06-29 02:06:58 +00:00
|
|
|
e "$kbc1126_ec_dump" f missing && $err "$cbdir: kbc1126 util missing"
|
2023-04-02 00:33:33 +00:00
|
|
|
(
|
2024-07-26 14:24:00 +00:00
|
|
|
x_ cd "$appdir/"; mv Rompaq/68*.BIN ec.bin || :
|
2024-06-29 02:09:03 +00:00
|
|
|
if [ ! -f "ec.bin" ]; then
|
2023-09-28 02:21:42 +00:00
|
|
|
unar -D ROM.CAB Rom.bin || unar -D Rom.CAB Rom.bin || \
|
safer, simpler error handling in lbmk
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>
2024-03-27 01:19:39 +00:00
|
|
|
unar -D 68*.CAB Rom.bin || $err "can't extract Rom.bin"
|
2023-10-01 05:33:43 +00:00
|
|
|
x_ mv Rom.bin ec.bin
|
2023-04-22 01:04:37 +00:00
|
|
|
fi
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -f ec.bin ] || $err "extract_kbc1126_ec $board: can't extract"
|
|
|
|
"$kbc1126_ec_dump" ec.bin || $err "!1126ec $board extract ecfw"
|
safer, simpler error handling in lbmk
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>
2024-03-27 01:19:39 +00:00
|
|
|
) || $err "can't extract kbc1126 ec firmware"
|
2024-05-26 00:54:36 +00:00
|
|
|
|
|
|
|
e "$appdir/ec.bin.fw1" f not && $err "$board: kbc1126ec fetch failed"
|
|
|
|
e "$appdir/ec.bin.fw2" f not && $err "$board: kbc1126ec fetch failed"
|
|
|
|
|
|
|
|
cp "$appdir/"ec.bin.fw* "${_dest%/*}/" || $err "!cp 1126ec $_dest"
|
2023-05-06 20:21:42 +00:00
|
|
|
}
|
|
|
|
|
2023-05-14 19:06:03 +00:00
|
|
|
extract_e6400vga()
|
|
|
|
{
|
./vendor download: more fine-tuned error control
By default, the build system does set -u -e
Some errors are unavoidable and have to be handled, so
we have to set +u +e (turn off error handling in sh),
when downloading vendor files, but only certain parts of
vendor.sh trigger errors (which cause an exit).
Replace the current bazooka approach with a more fine
grained approach, turning error handling back on again
when it is safe to do so.
In the parts of the code where it is disabled, the code
is written very, very carefully, with errors still handled
manually, but more careful auditing is required.
This change has been tested and makes the command much
safer to run. In security (or any bug auditing), it is
the principle of least privilege that holds true.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-05-29 00:49:07 +00:00
|
|
|
set +u +e
|
2024-06-29 01:23:02 +00:00
|
|
|
chkvars E6400_VGA_offset E6400_VGA_romname
|
2023-12-22 13:05:32 +00:00
|
|
|
tail -c +$E6400_VGA_offset "$_dl" | gunzip > "$appdir/bios.bin" || :
|
2023-05-06 20:21:42 +00:00
|
|
|
(
|
2024-05-26 00:54:36 +00:00
|
|
|
x_ cd "$appdir"
|
safer, simpler error handling in lbmk
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>
2024-03-27 01:19:39 +00:00
|
|
|
[ -f "bios.bin" ] || $err "extract_e6400vga: can't extract bios.bin"
|
2024-05-26 00:54:36 +00:00
|
|
|
"$e6400_unpack" bios.bin || printf "TODO: fix dell extract util\n"
|
safer, simpler error handling in lbmk
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>
2024-03-27 01:19:39 +00:00
|
|
|
) || $err "can't extract e6400 vga rom"
|
2024-05-26 00:54:36 +00:00
|
|
|
cp "$appdir/$E6400_VGA_romname" "$_dest" || \
|
|
|
|
$err "extract_e6400vga $board: can't copy vga rom to $_dest"
|
2023-05-06 20:21:42 +00:00
|
|
|
}
|
|
|
|
|
NEW BOARD: Dell Precision T1650
Very nice ivybridge board that supports ECC RAM.
NOTE: I couldn't get onboard graphics working yet, but
this was confirmed working with a graphics card (in my
case nvidia quadra k420) booted in text mode on the SeaBIOS
payload. The GRUB payload also works, when loaded from SeaBIOS.
Therefore, this is a SeaBIOS-only board (as far as first payload
is concerned), but you can pick GRUB from the menu.
You could make it "GRUB-only" in practise by setting SeaBIOS
boot order to only load GRUB, and disable the SeaBIOS menu.
We refer to this as "SeaGRUB".
I've made lbmk use biosutilities and uefiextract, to
get at the SMSC SCH5545 Environmental Control (EC) firmware.
This firmware is needed for fan control. This is automatically
downloaded and extracted, from Dell UEFI firmware updates.
As with other blobs such as Intel ME, this firmware is then
scrubbed by the release build scripts. The blobutil "inject"
script can be used to re-insert it.
Of note: there is no fixed offset, but no other blobs to
be inserted in CBFS either, so the offset when re-inserting
on release ROMs should still be the same, and thus the ROM
checksums should match, when running blobutil inject.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-08-11 13:50:17 +00:00
|
|
|
extract_sch5545ec()
|
|
|
|
{
|
|
|
|
# full system ROM (UEFI), to extract with UEFIExtract:
|
2024-05-26 00:54:36 +00:00
|
|
|
_bios="${_dl}_extracted/Firmware/1 $dlsum -- 1 System BIOS vA.28.bin"
|
NEW BOARD: Dell Precision T1650
Very nice ivybridge board that supports ECC RAM.
NOTE: I couldn't get onboard graphics working yet, but
this was confirmed working with a graphics card (in my
case nvidia quadra k420) booted in text mode on the SeaBIOS
payload. The GRUB payload also works, when loaded from SeaBIOS.
Therefore, this is a SeaBIOS-only board (as far as first payload
is concerned), but you can pick GRUB from the menu.
You could make it "GRUB-only" in practise by setting SeaBIOS
boot order to only load GRUB, and disable the SeaBIOS menu.
We refer to this as "SeaGRUB".
I've made lbmk use biosutilities and uefiextract, to
get at the SMSC SCH5545 Environmental Control (EC) firmware.
This firmware is needed for fan control. This is automatically
downloaded and extracted, from Dell UEFI firmware updates.
As with other blobs such as Intel ME, this firmware is then
scrubbed by the release build scripts. The blobutil "inject"
script can be used to re-insert it.
Of note: there is no fixed offset, but no other blobs to
be inserted in CBFS either, so the offset when re-inserting
on release ROMs should still be the same, and thus the ROM
checksums should match, when running blobutil inject.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-08-11 13:50:17 +00:00
|
|
|
# this is the SCH5545 firmware, inside of the extracted UEFI ROM:
|
2024-05-26 00:54:36 +00:00
|
|
|
_sch5545ec_fw="$_bios.dump/4 7A9354D9-0468-444A-81CE-0BF617D890DF"
|
|
|
|
_sch5545ec_fw="$_sch5545ec_fw/54 D386BEB8-4B54-4E69-94F5-06091F67E0D3"
|
|
|
|
_sch5545ec_fw="$_sch5545ec_fw/0 Raw section/body.bin" # <-- this!
|
|
|
|
|
|
|
|
"$uefiextract" "$_bios" || $err "sch5545 !extract"
|
|
|
|
cp "$_sch5545ec_fw" "$_dest" || $err "$_dest: !sch5545 copy"
|
NEW BOARD: Dell Precision T1650
Very nice ivybridge board that supports ECC RAM.
NOTE: I couldn't get onboard graphics working yet, but
this was confirmed working with a graphics card (in my
case nvidia quadra k420) booted in text mode on the SeaBIOS
payload. The GRUB payload also works, when loaded from SeaBIOS.
Therefore, this is a SeaBIOS-only board (as far as first payload
is concerned), but you can pick GRUB from the menu.
You could make it "GRUB-only" in practise by setting SeaBIOS
boot order to only load GRUB, and disable the SeaBIOS menu.
We refer to this as "SeaGRUB".
I've made lbmk use biosutilities and uefiextract, to
get at the SMSC SCH5545 Environmental Control (EC) firmware.
This firmware is needed for fan control. This is automatically
downloaded and extracted, from Dell UEFI firmware updates.
As with other blobs such as Intel ME, this firmware is then
scrubbed by the release build scripts. The blobutil "inject"
script can be used to re-insert it.
Of note: there is no fixed offset, but no other blobs to
be inserted in CBFS either, so the offset when re-inserting
on release ROMs should still be the same, and thus the ROM
checksums should match, when running blobutil inject.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-08-11 13:50:17 +00:00
|
|
|
}
|
|
|
|
|
T480/T480S: Support fetching ThunderBolt firmware
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-18 02:20:08 +00:00
|
|
|
# Lenovo ThunderBolt firmware updates:
|
|
|
|
# https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
|
|
|
|
extract_tbfw()
|
|
|
|
{
|
2024-12-18 03:42:45 +00:00
|
|
|
chkvars TBFW_size # size in bytes, matching TBFW's flash IC
|
T480/T480S: Support fetching ThunderBolt firmware
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-18 02:20:08 +00:00
|
|
|
x_ mkdir -p tmp
|
2024-12-18 03:49:58 +00:00
|
|
|
x_ rm -f tmp/tb.bin
|
T480/T480S: Support fetching ThunderBolt firmware
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-18 02:20:08 +00:00
|
|
|
find "$appdir" -type f -name "TBT.bin" > "tmp/tb.txt" || \
|
|
|
|
$err "extract_tbfw $_dest: Can't extract TBT.bin"
|
|
|
|
while read -r f; do
|
|
|
|
[ -f "$f" ] || continue
|
|
|
|
[ -L "$f" ] && continue
|
|
|
|
cp "$f" "tmp/tb.bin" || \
|
|
|
|
$err "extract_tbfw $_dest: Can't copy TBT.bin"
|
|
|
|
break
|
|
|
|
done < "tmp/tb.txt"
|
2024-12-18 03:42:45 +00:00
|
|
|
dd if=/dev/null of=tmp/tb.bin bs=1 seek=$TBFW_size || \
|
T480/T480S: Support fetching ThunderBolt firmware
Though not used in coreboot builds, and not injected into the
builds in any way, these files are now created seperately when
handling T480/T480s vendor files:
vendorfiles/t480/tb.bin
vendorfiles/t480s/tb.bin
These are created by extracting Lenovo's ThunderBolt firmware
from update files. The updated firmware fixes a bug; older firmware
enabled debug commands that wrote logs to the TB controller's
own flash IC, and it'd get full up with logs, bricking the controller.
If you've already been screwed by this, you must flash externally,
using a padded firmware from Lenovo's updates.
Lenovo's own updater requires creating a boot CD or booting
Windows. This patch in lbmk auto-downloads just the firmware,
and you can flash it externally.
You could simply do this as a matter of course, when installing
Libreboot. You are recommended to update the Lenovo UEFI/EC firmwares
first, before installing Libreboot; please look at the Libreboot
documentation to know exactly which versions.
Then dump the ThunderBolt firmware first, to be sure, and then you
can flash these files. Flashing these updates will prevent the bug
described here:
https://pcsupport.lenovo.com/us/en/products/laptops-and-netbooks/thinkpad-t-series-laptops/thinkpad-t480-type-20l5-20l6/20l5/solutions/ht508988
You can download Lenovo's installers for various ThinkPad models
there, including T480s/T480s. It is these downloads that this lbmk
patch uses, to extract those files directly.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-18 02:20:08 +00:00
|
|
|
$err "extract_tbfw $_dest: Can't pad TBT.bin"
|
|
|
|
cp "tmp/tb.bin" "$_dest" || $err "extract_tbfw $_dest: copy error"; :
|
|
|
|
}
|
|
|
|
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
extract_fspm()
|
|
|
|
{
|
|
|
|
copy_fsp M; :
|
|
|
|
}
|
|
|
|
|
|
|
|
extract_fsps()
|
|
|
|
{
|
|
|
|
copy_fsp S; :
|
|
|
|
}
|
|
|
|
|
|
|
|
# this copies the fsp s/m; re-base is handled by ./mk inject
|
|
|
|
copy_fsp()
|
|
|
|
{
|
|
|
|
cp "$appdir/Fsp_$1.fd" "$_dest" || \
|
|
|
|
$err "copy_fsp: Can't copy $1 to $_dest"; :
|
|
|
|
}
|
|
|
|
|
2024-05-11 04:33:43 +00:00
|
|
|
vendor_inject()
|
|
|
|
{
|
2024-07-26 14:24:00 +00:00
|
|
|
set +u +e; [ $# -lt 1 ] && $err "No options specified."
|
vendor.sh: Safer exit when vendorfiles not needed
When vendor files were not needed on a given board,
the script would directly exit. This is bad, because
the inject functions are called directly from the main
script, which means the parent instance of lbmk.
This means that the lock file and temporary files were
not being removed on exit. On a subsequent run, this
would cause the error stating that a lock file is present,
which would cause further error, making the user believe
something is broken in lbmk.
Modify the behaviour accordingly; exits are now returns,
and these are handled in the calling functions, in such
a way that a proper exit occurs, whereby temporary files
and the lock file are deleted.
For context, please read the main "build" script where
it calls vendor_inject and vendor_download. At the end
of that script, it calls tmp_cleanup, which removes the
TMPDIR that was created, and the lock file. In lbmk,
the TMPDIR is not /tmp, but rather a subdirectory
under /tmp, so that further calls to mktemp create
everything under one single temporary directory, which
lbmk automatically removes on exit.
Therefore, this patch also avoids leaving temporary files
laying around on the disk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-24 13:33:20 +00:00
|
|
|
[ "$1" = "listboards" ] && eval "ls -1 config/coreboot || :; return 0"
|
2024-05-11 04:33:43 +00:00
|
|
|
|
2024-07-26 14:24:00 +00:00
|
|
|
archive="$1"; while getopts n:r:b:m: option; do
|
2024-05-26 00:54:36 +00:00
|
|
|
case "$option" in
|
|
|
|
n) nukemode="$OPTARG" ;;
|
|
|
|
r) rom="$OPTARG" ;;
|
|
|
|
b) board="$OPTARG" ;;
|
2024-06-28 21:31:09 +00:00
|
|
|
m) new_mac="$OPTARG"; chkvars new_mac ;;
|
2024-05-11 04:33:43 +00:00
|
|
|
*) : ;;
|
|
|
|
esac
|
|
|
|
done
|
|
|
|
|
2024-06-28 23:33:31 +00:00
|
|
|
check_board || return 0
|
2024-12-24 16:58:23 +00:00
|
|
|
[ "$nukemode" = "nuke" ] || x_ ./mk download $board
|
vendor.sh: Safer exit when vendorfiles not needed
When vendor files were not needed on a given board,
the script would directly exit. This is bad, because
the inject functions are called directly from the main
script, which means the parent instance of lbmk.
This means that the lock file and temporary files were
not being removed on exit. On a subsequent run, this
would cause the error stating that a lock file is present,
which would cause further error, making the user believe
something is broken in lbmk.
Modify the behaviour accordingly; exits are now returns,
and these are handled in the calling functions, in such
a way that a proper exit occurs, whereby temporary files
and the lock file are deleted.
For context, please read the main "build" script where
it calls vendor_inject and vendor_download. At the end
of that script, it calls tmp_cleanup, which removes the
TMPDIR that was created, and the lock file. In lbmk,
the TMPDIR is not /tmp, but rather a subdirectory
under /tmp, so that further calls to mktemp create
everything under one single temporary directory, which
lbmk automatically removes on exit.
Therefore, this patch also avoids leaving temporary files
laying around on the disk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-24 13:33:20 +00:00
|
|
|
if [ "$vrelease" = "y" ]; then
|
|
|
|
patch_release_roms
|
2024-12-26 22:13:46 +00:00
|
|
|
printf "\nPatched images saved to bin/release/%s/\n" \
|
|
|
|
"$board"
|
vendor.sh: Safer exit when vendorfiles not needed
When vendor files were not needed on a given board,
the script would directly exit. This is bad, because
the inject functions are called directly from the main
script, which means the parent instance of lbmk.
This means that the lock file and temporary files were
not being removed on exit. On a subsequent run, this
would cause the error stating that a lock file is present,
which would cause further error, making the user believe
something is broken in lbmk.
Modify the behaviour accordingly; exits are now returns,
and these are handled in the calling functions, in such
a way that a proper exit occurs, whereby temporary files
and the lock file are deleted.
For context, please read the main "build" script where
it calls vendor_inject and vendor_download. At the end
of that script, it calls tmp_cleanup, which removes the
TMPDIR that was created, and the lock file. In lbmk,
the TMPDIR is not /tmp, but rather a subdirectory
under /tmp, so that further calls to mktemp create
everything under one single temporary directory, which
lbmk automatically removes on exit.
Therefore, this patch also avoids leaving temporary files
laying around on the disk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-24 13:33:20 +00:00
|
|
|
else
|
|
|
|
patch_rom "$rom" || :
|
|
|
|
fi; :
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
check_board()
|
|
|
|
{
|
2024-06-28 12:59:26 +00:00
|
|
|
failcheck="y" && check_release "$archive" && failcheck="n"
|
2024-05-26 00:54:36 +00:00
|
|
|
if [ "$failcheck" = "y" ]; then
|
2024-05-11 04:33:43 +00:00
|
|
|
[ -f "$rom" ] || $err "check_board \"$rom\": invalid path"
|
|
|
|
[ -z "${rom+x}" ] && $err "check_board: no rom specified"
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -n "${board+x}" ] || board="$(detect_board "$rom")"
|
2024-05-11 04:33:43 +00:00
|
|
|
else
|
2024-06-28 21:49:59 +00:00
|
|
|
vrelease="y"; board="$(detect_board "$archive")"
|
2024-06-28 23:33:31 +00:00
|
|
|
fi
|
|
|
|
readcfg || return 1; return 0
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
check_release()
|
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -f "$archive" ] || return 1
|
2024-05-11 04:33:43 +00:00
|
|
|
[ "${archive##*.}" = "xz" ] || return 1
|
2024-05-26 00:54:36 +00:00
|
|
|
printf "%s\n" "Release archive $archive detected"
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
# This function tries to determine the board from the filename of the rom.
|
|
|
|
# It will only succeed if the filename is not changed from the build/download
|
|
|
|
detect_board()
|
|
|
|
{
|
2024-07-26 14:24:00 +00:00
|
|
|
path="$1"; filename="$(basename "$path")"
|
2024-05-26 00:54:36 +00:00
|
|
|
case "$filename" in
|
2024-07-17 18:06:53 +00:00
|
|
|
grub_*|seagrub_*|custom_*)
|
|
|
|
board="$(echo "$filename" | cut -d '_' -f2-3)" ;;
|
2024-05-11 04:33:43 +00:00
|
|
|
seabios_withgrub_*)
|
2024-05-26 00:54:36 +00:00
|
|
|
board="$(echo "$filename" | cut -d '_' -f3-4)" ;;
|
2024-07-26 14:24:00 +00:00
|
|
|
*.tar.xz) _stripped_prefix="${filename#*_}"
|
2024-05-11 04:33:43 +00:00
|
|
|
board="${_stripped_prefix%.tar.xz}" ;;
|
2024-06-29 00:47:14 +00:00
|
|
|
*) $err "detect_board $filename: could not detect board type"
|
|
|
|
esac; printf "%s\n" "$board"
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
2024-06-28 12:33:50 +00:00
|
|
|
readcfg()
|
|
|
|
{
|
2024-06-28 23:33:31 +00:00
|
|
|
if [ "$board" = "serprog_rp2040" ] || \
|
2024-12-28 16:46:59 +00:00
|
|
|
[ "$board" = "serprog_stm32" ] || \
|
|
|
|
[ "$board" = "serprog_pico" ]; then
|
2024-06-28 23:33:31 +00:00
|
|
|
return 1
|
2024-07-26 14:24:00 +00:00
|
|
|
fi; boarddir="$cbcfgsdir/$board"
|
|
|
|
eval `setcfg "$boarddir/target.cfg"`; chkvars vcfg tree
|
2024-06-28 12:33:50 +00:00
|
|
|
|
2024-05-11 04:33:43 +00:00
|
|
|
cbdir="src/coreboot/$tree"
|
2024-06-06 20:45:53 +00:00
|
|
|
cbfstool="elf/cbfstool/$tree/cbfstool"
|
2024-06-29 00:19:29 +00:00
|
|
|
mecleaner="$PWD/$cbdir/util/me_cleaner/me_cleaner.py"
|
|
|
|
kbc1126_ec_dump="$PWD/$cbdir/util/kbc1126/kbc1126_ec_dump"
|
|
|
|
cbfstool="elf/cbfstool/$tree/cbfstool"
|
2024-06-06 20:45:53 +00:00
|
|
|
ifdtool="elf/ifdtool/$tree/ifdtool"
|
Add config for Dell OptiPlex 3050 Micro
This is using Mate Kukri's port, which was added in
previous lbmk revisions. I've added an IFD that sets
the HAP bit, and unlocks regions as standard.
vcfg is set to 3050micro, which defines downloading
of the MEv11 image and it will run deguard automatically.
I made a small adjustment to vendor.sh, because the hotpatch
logic for deguard uses -C in git, and when doing that, the
specified directory path is relative to that Git repository;
the .patch path has been adjusted accordingly.
Also add 3rdparty/fsp to coreboot/default modules.
This board requires the ifdtool option: -p sklkbl
The -p option tells flashrom what quirks are present in a
given IFD. We don't normally need this on other Libreboot
targets that we currently support. The -p option was needed
for creating this modified IFD, and it is therefore needed in
the inject script. Therefore, an "IFD_platform" option is
specified in a given board's target.cfg file. If this is set,
another variable is set that makes -p be used.
In this case, 3050's target.cfg says:
IFD_platform="sklkbl"
This option enables quirks for skylake/kabylake descriptors,
as required when using ifdtool.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-09-24 20:42:43 +00:00
|
|
|
[ -n "$IFD_platform" ] && ifdprefix="-p $IFD_platform"
|
2024-06-29 17:55:41 +00:00
|
|
|
|
2024-07-26 14:24:00 +00:00
|
|
|
x_ ./mk -d coreboot $tree
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
patch_release_roms()
|
|
|
|
{
|
2024-07-26 14:24:00 +00:00
|
|
|
remkdir "tmp/romdir"; tar -xf "$archive" -C "tmp/romdir" || \
|
2024-06-28 21:49:59 +00:00
|
|
|
$err "patch_release_roms: !tar -xf \"$archive\" -C \"tmp/romdir\""
|
2024-05-11 04:33:43 +00:00
|
|
|
|
2024-06-28 21:49:59 +00:00
|
|
|
for x in "tmp/romdir/bin/"*/*.rom ; do
|
vendor.sh: Safer exit when vendorfiles not needed
When vendor files were not needed on a given board,
the script would directly exit. This is bad, because
the inject functions are called directly from the main
script, which means the parent instance of lbmk.
This means that the lock file and temporary files were
not being removed on exit. On a subsequent run, this
would cause the error stating that a lock file is present,
which would cause further error, making the user believe
something is broken in lbmk.
Modify the behaviour accordingly; exits are now returns,
and these are handled in the calling functions, in such
a way that a proper exit occurs, whereby temporary files
and the lock file are deleted.
For context, please read the main "build" script where
it calls vendor_inject and vendor_download. At the end
of that script, it calls tmp_cleanup, which removes the
TMPDIR that was created, and the lock file. In lbmk,
the TMPDIR is not /tmp, but rather a subdirectory
under /tmp, so that further calls to mktemp create
everything under one single temporary directory, which
lbmk automatically removes on exit.
Therefore, this patch also avoids leaving temporary files
laying around on the disk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-24 13:33:20 +00:00
|
|
|
patch_rom "$x" || return 0
|
2024-05-11 04:33:43 +00:00
|
|
|
done
|
|
|
|
|
|
|
|
(
|
2024-06-28 21:49:59 +00:00
|
|
|
cd "tmp/romdir/bin/"* || $err "patch roms: !cd tmp/romdir/bin/*"
|
2024-05-11 04:33:43 +00:00
|
|
|
|
|
|
|
# NOTE: For compatibility with older rom releases, defer to sha1
|
2024-06-28 23:23:26 +00:00
|
|
|
[ "$verify" != "y" ] || [ "$nukemode" = "nuke" ] || \
|
|
|
|
sha512sum --status -c vendorhashes || \
|
2024-05-11 04:33:43 +00:00
|
|
|
sha1sum --status -c vendorhashes || sha512sum --status -c \
|
|
|
|
blobhashes || sha1sum --status -c blobhashes || \
|
|
|
|
$err "patch_release_roms: ROMs did not match expected hashes"
|
|
|
|
) || $err "can't verify vendor hashes"
|
|
|
|
|
2024-06-28 21:49:59 +00:00
|
|
|
[ -n "$new_mac" ] && for x in "tmp/romdir/bin/"*/*.rom ; do
|
|
|
|
[ -f "$x" ] && modify_gbe "$x"
|
|
|
|
done
|
2024-05-11 04:33:43 +00:00
|
|
|
|
2024-06-28 21:49:59 +00:00
|
|
|
x_ mkdir -p bin/release
|
|
|
|
mv tmp/romdir/bin/* bin/release/ || $err "$board: !mv release roms"
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
patch_rom()
|
|
|
|
{
|
2024-08-11 21:04:08 +00:00
|
|
|
rom="$1"
|
vendor.sh: Safer exit when vendorfiles not needed
When vendor files were not needed on a given board,
the script would directly exit. This is bad, because
the inject functions are called directly from the main
script, which means the parent instance of lbmk.
This means that the lock file and temporary files were
not being removed on exit. On a subsequent run, this
would cause the error stating that a lock file is present,
which would cause further error, making the user believe
something is broken in lbmk.
Modify the behaviour accordingly; exits are now returns,
and these are handled in the calling functions, in such
a way that a proper exit occurs, whereby temporary files
and the lock file are deleted.
For context, please read the main "build" script where
it calls vendor_inject and vendor_download. At the end
of that script, it calls tmp_cleanup, which removes the
TMPDIR that was created, and the lock file. In lbmk,
the TMPDIR is not /tmp, but rather a subdirectory
under /tmp, so that further calls to mktemp create
everything under one single temporary directory, which
lbmk automatically removes on exit.
Therefore, this patch also avoids leaving temporary files
laying around on the disk.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-24 13:33:20 +00:00
|
|
|
readkconfig || return 1
|
2024-05-26 00:54:36 +00:00
|
|
|
|
|
|
|
[ "$CONFIG_HAVE_MRC" = "y" ] && inject "mrc.bin" "$CONFIG_MRC_FILE" \
|
|
|
|
"mrc" "0xfffa0000"
|
|
|
|
[ -n "$CONFIG_HAVE_REFCODE_BLOB" ] && inject "fallback/refcode" \
|
|
|
|
"$CONFIG_REFCODE_BLOB_FILE" "stage"
|
2024-06-29 00:41:48 +00:00
|
|
|
[ "$CONFIG_HAVE_ME_BIN" = "y" ] && inject IFD "$CONFIG_ME_BIN_PATH" me
|
|
|
|
[ "$CONFIG_KBC1126_FIRMWARE" = "y" ] && inject ecfw1.bin \
|
|
|
|
"$CONFIG_KBC1126_FW1" raw "$CONFIG_KBC1126_FW1_OFFSET" && inject \
|
|
|
|
ecfw2.bin "$CONFIG_KBC1126_FW2" raw "$CONFIG_KBC1126_FW2_OFFSET"
|
2024-05-11 04:33:43 +00:00
|
|
|
[ -n "$CONFIG_VGA_BIOS_FILE" ] && [ -n "$CONFIG_VGA_BIOS_ID" ] && \
|
2024-07-26 14:24:00 +00:00
|
|
|
inject "pci$CONFIG_VGA_BIOS_ID.rom" "$CONFIG_VGA_BIOS_FILE" optionrom
|
2024-05-26 00:54:36 +00:00
|
|
|
[ "$CONFIG_INCLUDE_SMSC_SCH5545_EC_FW" = "y" ] && \
|
|
|
|
[ -n "$CONFIG_SMSC_SCH5545_EC_FW_FILE" ] && \
|
2024-06-29 00:41:48 +00:00
|
|
|
inject sch5545_ecfw.bin "$CONFIG_SMSC_SCH5545_EC_FW_FILE" raw
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
#
|
|
|
|
# coreboot adds FSP-M first. so we shall add it first, then S:
|
|
|
|
# NOTE:
|
|
|
|
# We skip the fetch if CONFIG_FSP_USE_REPO or CONFIG_FSP_FULL_FD is set
|
|
|
|
# but only for inject/nuke. we still run fetch (see above) because on
|
|
|
|
# _fsp targets, coreboot still needs them, but coreboot Kconfig uses
|
|
|
|
# makefile syntax and puts $(obj) in the path, which makes no sense
|
|
|
|
# in sh. So we modify the path there, but lbmk only uses the file
|
|
|
|
# in vendorfiles/ if neither CONFIG_FSP_USE_REPO nor CONFIG_FSP_FULL_FD
|
|
|
|
# are set
|
|
|
|
#
|
|
|
|
[ -z "$CONFIG_FSP_USE_REPO" ] && [ -z "$CONFIG_FSP_FULL_FD" ] && \
|
|
|
|
[ -n "$CONFIG_FSP_M_FILE" ] && \
|
|
|
|
inject "$CONFIG_FSP_M_CBFS" "$CONFIG_FSP_M_FILE" fsp --xip
|
|
|
|
[ -z "$CONFIG_FSP_USE_REPO" ] && [ -z "$CONFIG_FSP_FULL_FD" ] && \
|
|
|
|
[ -n "$CONFIG_FSP_S_FILE" ] && \
|
|
|
|
inject "$CONFIG_FSP_S_CBFS" "$CONFIG_FSP_S_FILE" fsp
|
2024-06-28 22:33:31 +00:00
|
|
|
[ -n "$new_mac" ] && [ "$vrelease" != "y" ] && modify_gbe "$rom"
|
2024-05-11 04:33:43 +00:00
|
|
|
|
2024-06-28 22:44:47 +00:00
|
|
|
printf "ROM image successfully patched: %s\n" "$rom"
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
inject()
|
|
|
|
{
|
2024-05-26 00:54:36 +00:00
|
|
|
[ $# -lt 3 ] && $err "$@, $rom: usage: inject name path type (offset)"
|
2024-06-28 23:23:26 +00:00
|
|
|
[ "$2" = "/dev/null" ] && return 0; verify="y"
|
2024-05-11 04:33:43 +00:00
|
|
|
|
2024-06-22 03:06:07 +00:00
|
|
|
eval `setvars "" cbfsname _dest _t _offset`
|
2024-06-28 21:49:59 +00:00
|
|
|
cbfsname="$1"; _dest="${2##*../}"; _t="$3"
|
|
|
|
|
vendor.sh: Handle FSP insertion post-release
The Libreboot 20241206 release provided FSP pre-assembled
and inserted into the ROM images; the only file inserted
by vendor.sh was the Intel ME.
Direct distribution of an unmodified FSP image is permitted
by Intel, provided that the license notice is given among
other requirements. Due to how coreboot works, it must split
up the FSP into subcomponents, and adjust certain pointers
within the -M component (for raminit).
Such build-time modifications are perfectly fine in a coreboot
context, where it is expected that you are building from source.
The end result is simply what you use.
In a distribution such as Libreboot, where we provide pre-built
images, this becomes problematic. It's a technicality of the
license, and it seems that Intel themselves probably intended
for Libreboot to use the FSP this way anyway, since it is they
who seem to be the author of SplitFspBin.py, which is the
utility that coreboot uses for splitting up the FSP image.
Due to the technicality of the licensing, the FSP shall now
be scrubbed from releases, and re-inserted.
Coreboot was inserting the -S component with LZ4 compression,
which is bad news for ./mk inject beacuse the act of compression
is currently not reproducible. Therefore, coreboot has been
modified not to compress this section, and the inject command
doesn't compress it either. This means that the S file is using
about 180KB in flash, instead of about 140KB. This is totally OK.
The _fsp targets are retained, but set to release=n, because these
targets *still* don't scrub fsp.bin; if released, they would
include fsp files, so they've been set to release=n. These can
be used on older Libreboot release archives, for compatibility.
The new ROM images released for the affected machines are:
t480_vfsp_16mb
t480s_vfsp_16mb
dell3050micro_vfsp_16mb
Note the use of _vfsp instead of _fsp. These images are released,
unlike _fsp, and they lack fspm/fsps in the image. FSP S/M must
be inserted using ./mk inject.
This has been tested and confirmed to boot just fine.
The 20241206 images will be re-compiled and re-uploaded with this
and other recent changes, to make Libreboot 20241206 rev8.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-12-26 17:11:10 +00:00
|
|
|
if [ "$_t" = "fsp" ]; then
|
|
|
|
[ $# -gt 3 ] && _offset="$4"
|
|
|
|
else
|
|
|
|
[ $# -gt 3 ] && _offset="-b $4" && [ -z "$4" ] && \
|
|
|
|
$err "inject $@, $rom: offset given but empty (undefined)"
|
|
|
|
fi
|
2024-05-11 04:33:43 +00:00
|
|
|
|
2024-06-28 22:44:47 +00:00
|
|
|
e "$_dest" f n && [ "$nukemode" != "nuke" ] && $err "!inject $dl_type"
|
2024-05-11 04:33:43 +00:00
|
|
|
|
2024-05-26 00:54:36 +00:00
|
|
|
if [ "$cbfsname" = "IFD" ]; then
|
Add config for Dell OptiPlex 3050 Micro
This is using Mate Kukri's port, which was added in
previous lbmk revisions. I've added an IFD that sets
the HAP bit, and unlocks regions as standard.
vcfg is set to 3050micro, which defines downloading
of the MEv11 image and it will run deguard automatically.
I made a small adjustment to vendor.sh, because the hotpatch
logic for deguard uses -C in git, and when doing that, the
specified directory path is relative to that Git repository;
the .patch path has been adjusted accordingly.
Also add 3rdparty/fsp to coreboot/default modules.
This board requires the ifdtool option: -p sklkbl
The -p option tells flashrom what quirks are present in a
given IFD. We don't normally need this on other Libreboot
targets that we currently support. The -p option was needed
for creating this modified IFD, and it is therefore needed in
the inject script. Therefore, an "IFD_platform" option is
specified in a given board's target.cfg file. If this is set,
another variable is set that makes -p be used.
In this case, 3050's target.cfg says:
IFD_platform="sklkbl"
This option enables quirks for skylake/kabylake descriptors,
as required when using ifdtool.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-09-24 20:42:43 +00:00
|
|
|
[ "$nukemode" = "nuke" ] || "$ifdtool" $ifdprefix -i \
|
|
|
|
$_t:$_dest "$rom" -O "$rom" || \
|
|
|
|
$err "failed: inject '$_t' '$_dest' on '$rom'"
|
|
|
|
[ "$nukemode" != "nuke" ] || "$ifdtool" $ifdprefix --nuke $_t \
|
|
|
|
"$rom" -O "$rom" || $err "$rom: !nuke IFD/$_t"; return 0
|
2024-06-29 02:27:31 +00:00
|
|
|
elif [ "$nukemode" = "nuke" ]; then
|
2024-06-28 22:44:47 +00:00
|
|
|
"$cbfstool" "$rom" remove -n "$cbfsname" || \
|
2024-06-29 02:27:31 +00:00
|
|
|
$err "inject $rom: can't remove $cbfsname"; return 0
|
2024-05-11 04:33:43 +00:00
|
|
|
fi
|
2024-06-28 22:44:47 +00:00
|
|
|
[ "$_t" != "stage" ] || "$cbfstool" "$rom" add-stage -f \
|
|
|
|
"$_dest" -n "$cbfsname" -t stage -c lzma || $err "$rom: !add ref"
|
|
|
|
[ "$_t" = "stage" ] || "$cbfstool" "$rom" add -f "$_dest" \
|
2024-07-26 14:24:00 +00:00
|
|
|
-n "$cbfsname" -t $_t $_offset || $err "$rom !add $_t ($_dest)"; :
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
2024-06-28 15:24:07 +00:00
|
|
|
|
|
|
|
modify_gbe()
|
|
|
|
{
|
2024-06-28 20:43:23 +00:00
|
|
|
chkvars CONFIG_GBE_BIN_PATH
|
2024-06-28 15:24:07 +00:00
|
|
|
|
2024-06-28 20:43:23 +00:00
|
|
|
e "${CONFIG_GBE_BIN_PATH##*../}" f n && $err "missing gbe file"
|
2024-06-28 15:24:07 +00:00
|
|
|
x_ make -C util/nvmutil
|
|
|
|
|
2024-06-28 20:43:23 +00:00
|
|
|
x_ cp "${CONFIG_GBE_BIN_PATH##*../}" "$TMPDIR/gbe"
|
2024-06-28 21:31:09 +00:00
|
|
|
x_ "util/nvmutil/nvm" "$TMPDIR/gbe" setmac $new_mac
|
2024-10-16 14:48:43 +00:00
|
|
|
"$ifdtool" $ifdprefix -i GbE:"$TMPDIR/gbe" "$1" -O "$1" || \
|
|
|
|
$err "Cannot insert modified GbE region into target image."
|
2024-06-28 15:24:07 +00:00
|
|
|
}
|