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>
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
# Copyright (c) 2023-2025 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"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
hashfiles="vendorhashes blobhashes" # blobhashes for backwards compatibility
|
|
|
|
|
dontflash="!!! AN ERROR OCCURED! Please DO NOT flash if injection failed. !!!"
|
|
|
|
|
vfix="DO_NOT_FLASH_YET._FIRST,_INJECT_BLOBS_VIA_INSTRUCTIONS_ON_LIBREBOOT.ORG_"
|
|
|
|
|
vguide="https://libreboot.org/docs/install/ivy_has_common.html"
|
|
|
|
|
tmpromdel="$PWD/tmp/DO_NOT_FLASH"
|
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: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
archive EC_url boarddir rom cbdir DL_url nukemode cbfstoolref FSPFD_hash \
|
|
|
|
|
_7ztest ME11bootguard ME11delta ME11version ME11sku ME11pch tmpromdir \
|
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: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
TBFW_hash TBFW_size hashfile has_hashes xromsize xchanged $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
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
rm -f "$TMPDIR/tmpcbcfg" || $err "!rm $TMPDIR/tmpcbcfg - $dontflash"
|
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" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "!rm $TMPDIR/tmpcbcfg2 - $dontflash"
|
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
|
|
|
grep "$cbc" "$cbcfgfile" 1>"$TMPDIR/tmpcbcfg2" \
|
|
|
|
|
2>/dev/null || :
|
|
|
|
|
[ -f "$TMPDIR/tmpcbcfg2" ] || continue
|
|
|
|
|
cat "$TMPDIR/tmpcbcfg2" >> "$TMPDIR/tmpcbcfg" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "!cat $TMPDIR/tmpcbcfg2 - $dontflash"
|
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
|
|
|
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
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
rm -Rf "${_dl}_extracted" || $err "!rm ${_ul}_extracted. $dontflash"
|
2024-06-30 18:22:58 +00:00
|
|
|
e "$_dest" f && return 0
|
|
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
mkdir -p "${_dest%/*}" || \
|
|
|
|
|
$err "mkdirs: !mkdir -p ${_dest%/*} - $dontflash"
|
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" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
[ "$dl_type" = "e6400vga" ] || \
|
|
|
|
|
$err "mkd $_dest $dl_type: !extract. $dontflash"
|
2023-10-15 09:00:23 +00:00
|
|
|
|
2024-07-26 14:24:00 +00:00
|
|
|
eval "extract_$dl_type"; set -u -e
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
e "$_dest" f missing && $err "!extract_$dl_type. $dontflash"; :
|
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
|
|
|
{
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
e "$mecleaner" f not && $err "$cbdir: me_cleaner missing. $dontflash"
|
2024-05-26 00:54:36 +00:00
|
|
|
|
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
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
mv "$_metmp" "$_me" || $err "!mv $_metmp $_me - $dontflash"
|
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)"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
mkdir -p "$sdir" || \
|
|
|
|
|
$err "extract_intel_me: !mkdir -p \"$sdir\" - $dontflash"
|
./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#/}"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
cd "$cdir" || $err "extract_intel_me: !cd \"$cdir\" - $dontflash"
|
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
|
|
|
|
|
)
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
rm -Rf "$sdir" || $err "extract_intel_me: !rm -Rf $sdir - $dontflash"
|
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" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "Error running deguard for $_me - $dontflash"
|
|
|
|
|
) || $err "Error running deguard for $_me - $dontflash"
|
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" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "!mv '${_dl}_extracted' '$2' - $dontflash"; :
|
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" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "decat_fspfd '$1' '$2': Can't de-concatenate; $dontflash"; :
|
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
|
|
|
}
|
|
|
|
|
|
2023-09-28 00:21:58 +00:00
|
|
|
extract_kbc1126ec()
|
2023-05-14 19:06:03 +00:00
|
|
|
{
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
e "$kbc1126_ec_dump" f missing && \
|
|
|
|
|
$err "$cbdir: kbc1126 util missing - $dontflash"
|
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 || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
unar -D 68*.CAB Rom.bin || \
|
|
|
|
|
$err "can't extract Rom.bin - $dontflash"
|
2023-10-01 05:33:43 +00:00
|
|
|
x_ mv Rom.bin ec.bin
|
2023-04-22 01:04:37 +00:00
|
|
|
fi
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
[ -f ec.bin ] || \
|
|
|
|
|
$err "extract_kbc1126_ec $board: can't extract - $dontflash"
|
|
|
|
|
"$kbc1126_ec_dump" ec.bin || \
|
|
|
|
|
$err "!1126ec $board extract ecfw - $dontflash"
|
|
|
|
|
) || $err "can't extract kbc1126 ec firmware - $dontflash"
|
|
|
|
|
|
|
|
|
|
e "$appdir/ec.bin.fw1" f not && \
|
|
|
|
|
$err "$board: kbc1126ec fetch failed - $dontflash"
|
|
|
|
|
e "$appdir/ec.bin.fw2" f not && \
|
|
|
|
|
$err "$board: kbc1126ec fetch failed - $dontflash"
|
|
|
|
|
|
|
|
|
|
cp "$appdir/"ec.bin.fw* "${_dest%/*}/" || \
|
|
|
|
|
$err "!cp 1126ec $_dest - $dontflash"; :
|
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"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
[ -f "bios.bin" ] || \
|
|
|
|
|
$err "extract_e6400vga: can't extract bios.bin - $dontflash"
|
2024-05-26 00:54:36 +00:00
|
|
|
"$e6400_unpack" bios.bin || printf "TODO: fix dell extract util\n"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
) || $err "can't extract e6400 vga rom - $dontflosh"
|
2024-05-26 00:54:36 +00:00
|
|
|
cp "$appdir/$E6400_VGA_romname" "$_dest" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "extract_e6400vga $board: can't cp $_dest - $dontflash"; :
|
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!
|
|
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
"$uefiextract" "$_bios" || $err "sch5545 !extract - $dontflash"
|
|
|
|
|
cp "$_sch5545ec_fw" "$_dest" || \
|
|
|
|
|
$err "$_dest: !sch5545 copy - $dontflash"; :
|
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" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "extract_tbfw $_dest: Can't extract TBT.bin - $dontflash"
|
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
|
|
|
while read -r f; do
|
|
|
|
|
[ -f "$f" ] || continue
|
|
|
|
|
[ -L "$f" ] && continue
|
|
|
|
|
cp "$f" "tmp/tb.bin" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "extract_tbfw $_dest: Can't copy TBT.bin - $dontflash"
|
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
|
|
|
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 || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "extract_tbfw $_dest: Can't pad TBT.bin - $dontflash"
|
|
|
|
|
cp "tmp/tb.bin" "$_dest" || \
|
|
|
|
|
$err "extract_tbfw $_dest: copy error - $dontflash "; :
|
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
|
|
|
}
|
|
|
|
|
|
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" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "copy_fsp: Can't copy $1 to $_dest - $dontflash"; :
|
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
|
|
|
}
|
|
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
fail_inject()
|
2024-05-11 04:33:43 +00:00
|
|
|
{
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
[ -L "$tmpromdel" ] || [ ! -d "$tmpromdel" ] || \
|
|
|
|
|
rm -Rf "$tmpromdel" || :
|
|
|
|
|
printf "\n\n%s\n\n" "$dontflash" 1>&2
|
|
|
|
|
printf "WARNING: File '%s' was NOT modified.\n\n" "$archive" 1>&2
|
|
|
|
|
printf "Please MAKE SURE vendor files are inserted before flashing\n\n"
|
|
|
|
|
fail "$1"
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
vendor_inject()
|
2024-05-11 04:33:43 +00:00
|
|
|
{
|
2025-01-02 10:17:39 +00:00
|
|
|
_olderr="$err"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
err="fail_inject"
|
|
|
|
|
remkdir "$tmpromdel"
|
|
|
|
|
|
|
|
|
|
set +u +e; [ $# -lt 1 ] && $err "No options specified. - $dontflash"
|
|
|
|
|
eval `setvars "" nukemode new_mac xchanged`
|
|
|
|
|
|
|
|
|
|
archive="$1";
|
|
|
|
|
[ $# -gt 1 ] && case "$2" in
|
|
|
|
|
nuke) nukemode="nuke" ;;
|
|
|
|
|
setmac)
|
|
|
|
|
new_mac="??:??:??:??:??:??"
|
|
|
|
|
[ $# -gt 2 ] && new_mac="$3" ;;
|
|
|
|
|
*) $err "Unrecognised inject mode: '$2'"
|
|
|
|
|
esac
|
|
|
|
|
|
|
|
|
|
check_release "$archive" || \
|
|
|
|
|
$err "You must run this script on a release archive. - $dontflash"
|
|
|
|
|
if readcfg; then
|
|
|
|
|
[ "$nukemode" = "nuke" ] || x_ ./mk download $board
|
|
|
|
|
patch_release_roms
|
2024-05-11 04:33:43 +00:00
|
|
|
else
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
printf "Tarball '%s' (board '%s) doesn't need vendorfiles.\n" \
|
|
|
|
|
"$archive" "$board"
|
2025-01-02 10:17:39 +00:00
|
|
|
err="$_olderr"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
return 0
|
2024-06-28 23:33:31 +00:00
|
|
|
fi
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
|
|
|
|
|
xtype="patched" && [ "$nukemode" = "nuke" ] && xtype="nuked"
|
|
|
|
|
[ "$xchanged" = "y" ] || \
|
|
|
|
|
printf "\nRelease archive '%s' was not modified.\n" "$archive"
|
|
|
|
|
[ "$xchanged" = "y" ] && \
|
|
|
|
|
printf "\nRelease archive '%s' successfully %s.\n" \
|
|
|
|
|
"$archive" "$xtype"
|
|
|
|
|
[ "$xchanged" = "y" ] && [ "$nukemode" = "nuke" ] && \
|
|
|
|
|
printf "!!!WARNING!!! -> Vendor files removed. DO NOT FLASH.\n"
|
2025-01-02 10:17:39 +00:00
|
|
|
err="$_olderr"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
return 0
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
check_release()
|
|
|
|
|
{
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
[ -L "$archive" ] && \
|
|
|
|
|
$err "'$archive' is a symlink, not a file - $dontflash"
|
2024-05-26 00:54:36 +00:00
|
|
|
[ -f "$archive" ] || return 1
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
archivename="`basename "$archive"`"
|
|
|
|
|
[ -z "$archivename" ] && \
|
|
|
|
|
$err "Cannot determine archive file name - $dontflash"
|
|
|
|
|
|
|
|
|
|
case "$archivename" in
|
|
|
|
|
*_src.tar.xz)
|
|
|
|
|
$err "'$archive' is a src archive, silly!" ;;
|
|
|
|
|
grub_*|seagrub_*|custom_*|seauboot_*|seabios_withgrub_*)
|
|
|
|
|
return 1 ;;
|
|
|
|
|
*.tar.xz) _stripped_prefix="${archivename#*_}"
|
2024-05-11 04:33:43 +00:00
|
|
|
board="${_stripped_prefix%.tar.xz}" ;;
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
*) $err "'$archive': could not detect board type - $dontflash"
|
|
|
|
|
esac; :
|
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-12-31 14:44:31 +00:00
|
|
|
rmodtool="elf/cbfstool/$tree/rmodtool"
|
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()
|
|
|
|
|
{
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
has_hashes="n"
|
|
|
|
|
|
|
|
|
|
tmpromdir="tmp/DO_NOT_FLASH/bin/$board"
|
|
|
|
|
remkdir "${tmpromdir%"/bin/$board"}"
|
|
|
|
|
tar -xf "$archive" -C "${tmpromdir%"/bin/$board"}" || \
|
|
|
|
|
$err "Can't extract '$archive'"
|
|
|
|
|
|
|
|
|
|
for _hashes in $hashfiles; do
|
|
|
|
|
[ -L "$tmpromdir/$_hashes" ] && \
|
|
|
|
|
$err "'$archive' -> the hashfile is a symlink. $dontflash"
|
|
|
|
|
[ -f "$tmpromdir/$_hashes" ] && has_hashes="y" && \
|
|
|
|
|
hashfile="$_hashes" && break; :
|
2024-05-11 04:33:43 +00:00
|
|
|
done
|
|
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
x_ mkdir -p "tmp"; [ -L "tmp/rom.list" ] && \
|
|
|
|
|
$err "'$archive' -> tmp/rom.list is a symlink - $dontflash"
|
|
|
|
|
x_ rm -f "tmp/rom.list" "tmp/zero.1b"
|
|
|
|
|
x_ dd if=/dev/zero of=tmp/zero.1b bs=1 count=1
|
|
|
|
|
|
|
|
|
|
find "$tmpromdir" -maxdepth 1 -type f -name "*.rom" > "tmp/rom.list" \
|
|
|
|
|
|| $err "'$archive' -> Can't make tmp/rom.list - $dontflash"
|
|
|
|
|
|
|
|
|
|
if readkconfig; then
|
|
|
|
|
while read -r _xrom ; do
|
|
|
|
|
process_release_rom "$_xrom" || break
|
|
|
|
|
done < "tmp/rom.list"
|
|
|
|
|
rm -f "$tmpromdir/README.md" || :
|
|
|
|
|
[ "$nukemode" != "nuke" ] || \
|
|
|
|
|
printf "Make sure you inserted vendor files: %s\n" \
|
|
|
|
|
"$vguide" > "$tmpromdir/README.md" || :
|
|
|
|
|
else
|
|
|
|
|
printf "Skipping vendorfiles on '$archive'"
|
|
|
|
|
fi
|
2024-05-11 04:33:43 +00:00
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
(
|
|
|
|
|
cd "$tmpromdir" || $err "patch '$archive': can't cd $tmpromdir"
|
2024-05-11 04:33:43 +00:00
|
|
|
# NOTE: For compatibility with older rom releases, defer to sha1
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
if [ "$has_hashes" = "y" ] && [ "$nukemode" != "nuke" ]; then
|
|
|
|
|
sha512sum --status -c "$hashfile" || \
|
|
|
|
|
sha1sum --status -c "$hashfile" || \
|
|
|
|
|
$err "'$archive' -> Can't verify vendor hashes. $dontflash"
|
|
|
|
|
rm -f "$hashfile" || \
|
|
|
|
|
$err "$archive: Can't rm hashfile. $dontflash"
|
|
|
|
|
fi
|
|
|
|
|
) || $err "'$archive' -> Can't verify vendor hashes. $dontflash"
|
|
|
|
|
|
|
|
|
|
if [ -n "$new_mac" ]; then
|
|
|
|
|
if ! modify_mac_addresses; then
|
|
|
|
|
printf "\nNo GbE region defined for '$board'\n" \
|
|
|
|
|
1>&2
|
|
|
|
|
printf "Therefore, changing the MAC is impossible.\n" \
|
|
|
|
|
1>&2
|
|
|
|
|
printf "This board probably lacks Intel ethernet.\n" \
|
|
|
|
|
1>&2
|
|
|
|
|
fi
|
|
|
|
|
fi
|
|
|
|
|
|
|
|
|
|
[ "$xchanged" = "y" ] || rm -Rf "$tmpromdel" || :
|
|
|
|
|
[ "$xchanged" = "y" ] || return 0
|
|
|
|
|
(
|
|
|
|
|
cd "${tmpromdir%"/bin/$board"}" || \
|
|
|
|
|
$err "Can't cd '${tmpromdir%"/bin/$board"}'; $dontflash"
|
|
|
|
|
# ../../ is the root of lbmk
|
|
|
|
|
mkrom_tarball "bin/$board"
|
|
|
|
|
) || $err "Cannot re-generate '$archive' - $dontflash"
|
|
|
|
|
|
|
|
|
|
mv "${tmpromdir%"/bin/$board"}/bin/${relname}_${board}.tar.xz" \
|
|
|
|
|
"$archive" || \
|
|
|
|
|
$err "'$archive' -> Cannot overwrite - $dontflash"; :
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
process_release_rom()
|
|
|
|
|
{
|
|
|
|
|
_xrom="$1"; _xromname="${1##*/}"
|
|
|
|
|
[ -L "$_xrom" ] && \
|
|
|
|
|
$err "$archive -> '${_xrom#"tmp/DO_NOT_FLASH/"}' is a symlink"
|
|
|
|
|
[ -f "$_xrom" ] || return 0
|
|
|
|
|
|
|
|
|
|
[ -z "${_xromname#"$vfix"}" ] && \
|
|
|
|
|
$err "'$_xromname'->'"${_xromname#"$vfix"}"' empty. $dontflash"
|
|
|
|
|
# Remove the prefix and 1-byte pad
|
|
|
|
|
if [ "$nukemode" != "nuke" ] && \
|
|
|
|
|
[ "${_xromname#"$vfix"}" != "$_xromname" ]; then
|
|
|
|
|
_xromnew="${_xrom%/*}/${_xromname#"$vfix"}"
|
|
|
|
|
|
|
|
|
|
# Remove the 1-byte padding
|
|
|
|
|
stat -c '%s' "$_xrom" > "tmp/rom.size" || \
|
|
|
|
|
$err "$_xrom: Can't get rom size. $dontflash"
|
|
|
|
|
read -r xromsize < "tmp/rom.size" || \
|
|
|
|
|
$err "$_xrom: Can't read rom size. $dontflash"
|
|
|
|
|
|
|
|
|
|
expr "X$xromsize" : "X-\{0,1\}[0123456789][0123456789]*$" \
|
|
|
|
|
1>/dev/null 2>/dev/null || $err "$_xrom size non-integer"
|
|
|
|
|
[ $xromsize -lt 2 ] && $err \
|
|
|
|
|
"$_xrom: Will not create empty file. $dontflash"
|
|
|
|
|
|
|
|
|
|
# TODO: check whether the size would be a multiple of 64KB
|
|
|
|
|
# the smallest rom images we do are 512kb
|
|
|
|
|
xromsize="`expr $xromsize - 1`"
|
|
|
|
|
[ $xromsize -lt 524288 ] && \
|
|
|
|
|
$err "$_xrom size too small; likely not a rom. $dontflash"
|
|
|
|
|
|
|
|
|
|
dd if="$_xrom" of="$_xromnew" bs=$xromsize count=1 || \
|
|
|
|
|
$err "$_xrom: Can't resize. $dontflash"
|
|
|
|
|
rm -f "$_xrom" || $err "Can't rm $_xrom - $dontflash"
|
|
|
|
|
|
|
|
|
|
_xrom="$_xromnew"
|
|
|
|
|
fi
|
2024-05-11 04:33:43 +00:00
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
[ "$nukemode" = "nuke" ] && \
|
|
|
|
|
mksha512sum "$_xrom" "vendorhashes"
|
|
|
|
|
|
|
|
|
|
patch_rom "$_xrom" || return 1 # if break return, can still change MAC
|
|
|
|
|
[ "$nukemode" != "nuke" ] && return 0
|
|
|
|
|
|
|
|
|
|
# Rename the file, prefixing a warning saying not to flash
|
|
|
|
|
# the target image, which now has vendor files removed. Also
|
|
|
|
|
# pad it so that flashprog returns an error if the user tries
|
|
|
|
|
# to flash it, due to mismatching ROM size vs chip size
|
|
|
|
|
cat "$_xrom" tmp/zero.1b > "${_xrom%/*}/$vfix${_xrom##*/}" || \
|
|
|
|
|
$err "'$archive' -> can't pad/rename '$_xrom'. $dontflash"
|
|
|
|
|
rm -f "$_xrom" || $err "'$archive' -> can't rm '$_xrom'. $dontflash"
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
patch_rom()
|
|
|
|
|
{
|
2024-08-11 21:04:08 +00:00
|
|
|
rom="$1"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
|
|
|
|
|
if [ "$has_hashes" != "y" ] && [ "$nukemode" != "nuke" ]; then
|
|
|
|
|
printf "inject: '%s' has no hash file. Skipping.\n" \
|
|
|
|
|
"$archive" 1>&2
|
|
|
|
|
return 1
|
|
|
|
|
fi
|
2024-05-26 00:54:36 +00:00
|
|
|
|
|
|
|
|
[ -n "$CONFIG_HAVE_REFCODE_BLOB" ] && inject "fallback/refcode" \
|
|
|
|
|
"$CONFIG_REFCODE_BLOB_FILE" "stage"
|
2024-12-31 14:44:31 +00:00
|
|
|
[ "$CONFIG_HAVE_MRC" = "y" ] && inject "mrc.bin" "$CONFIG_MRC_FILE" \
|
|
|
|
|
"mrc" "0xfffa0000"
|
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
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
# TODO: modify gbe *after checksum verification only*
|
|
|
|
|
# TODO: insert default gbe if doing -n nuke
|
2024-05-11 04:33:43 +00:00
|
|
|
|
2024-06-28 22:44:47 +00:00
|
|
|
printf "ROM image successfully patched: %s\n" "$rom"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
xchanged="y"
|
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)"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
[ "$2" = "/dev/null" ] && return 0
|
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 \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
"$rom" -O "$rom" || $err "$rom: !nuke IFD/$_t"
|
|
|
|
|
xchanged="y"
|
|
|
|
|
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" || \
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
$err "inject $rom: can't remove $cbfsname"
|
|
|
|
|
xchanged="y"
|
|
|
|
|
return 0
|
2024-05-11 04:33:43 +00:00
|
|
|
fi
|
2025-01-01 18:30:57 +00:00
|
|
|
if [ "$_t" = "stage" ]; then # the only stage we handle is refcode
|
2024-12-31 14:44:31 +00:00
|
|
|
x_ mkdir -p tmp; x_ rm -f "tmp/refcode"
|
|
|
|
|
"$rmodtool" -i "$_dest" -o "tmp/refcode" || "!reloc refcode"
|
|
|
|
|
"$cbfstool" "$rom" add-stage -f "tmp/refcode" -n "$cbfsname" \
|
|
|
|
|
-t stage || $err "$rom: !add ref"
|
|
|
|
|
else
|
|
|
|
|
"$cbfstool" "$rom" add -f "$_dest" -n "$cbfsname" \
|
|
|
|
|
-t $_t $_offset || $err "$rom !add $_t ($_dest)"
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
fi; xchanged="y"; :
|
2024-05-11 04:33:43 +00:00
|
|
|
}
|
2024-06-28 15:24:07 +00:00
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
modify_mac_addresses()
|
2024-06-28 15:24:07 +00:00
|
|
|
{
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
[ "$nukemode" = "nuke" ] && \
|
|
|
|
|
$err "Cannot modify MAC addresses while nuking vendor files"
|
2024-06-28 15:24:07 +00:00
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
# chkvars CONFIG_GBE_BIN_PATH
|
|
|
|
|
[ -n "$CONFIG_GBE_BIN_PATH" ] || return 1
|
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
|
|
|
|
vendor.sh: MUCH, MUCH, MUCH safer ./mk inject
Don't extract to bin/release/
Modify the tarball instead. Previously, the tarball would
not be modified, but a lot of users thought the tarball was
being modified and ignored bin/release/, where the injected
images were actually being saved to.
Don't copy the tarball either. Just modify it in-place.
Don't allow single-rom injection either; only allow the
tarball-based method.
The command syntax has changed, but:
./mk inject tarball.tar.xz
This is the same. What has changed is nuke, and MAC address
modification. Observe:
./mk inject tarball.tar.xz nuke
./mk inject tarball.tar.xz setmac
./mk inject tarball.tar.xz setmac ??:??:??:??:??:??
./mk inject tarball.tar.xz setmac 00:1f:16:??:22:aa
These are just a few examples. The MAC address syntax is
the same as used for nvmutil, which means you can set it
randomly. Also:
./mk inject tarball.tar.xz setmac
You can use the *setmac* command *repeatedly*, even if
you've already injected a given archive. It'll just
update the archive, but skip injecting other files
that were already injected.
If you use setmac without a MAC address, it will randomise
the MAC address. This is therefore very similar to the
command structure used in nvmutil.
The code for injection is generally more robust, with
stronger error checks. This design change was done, so
that the user doesn't accidentally brick their machine.
The non-injected images have a prefix in the file name
saying "DO_NOT_FLASH", and those non-injected images are
padded by 1 byte. That way, the user knows not to flash it
and if they try, flashprog will throw an error.
The prefix and padding is removed on injection. Old images
without the padding/prefix can still be injected, via
tarballs; this new code is backwards-compatible with tarballs
from older Libreboot releases.
A common thing I see sometimes is a user will say they have
a black screen or something, and I say: did you insert vendor
files? And they say yes. And they did. But they extracted and
flashed from the tarball, which wasn't injected, because
they didn't release about bin/release/
No amount of RTFM is justified. The previous design flaw
is a bug. We must always observe user safety first, no matter
what, so that has now been done.
Signed-off-by: Leah Rowe <leah@libreboot.org>
2025-01-02 02:25:24 +00:00
|
|
|
x_ make -C util/nvmutil
|
|
|
|
|
x_ mkdir -p tmp
|
|
|
|
|
[ -L "tmp/gbe" ] && $err "tmp/gbe exists but is a symlink"
|
|
|
|
|
[ -d "tmp/gbe" ] && $err "tmp/gbe exists but is a directory"
|
|
|
|
|
if [ -e "tmp/gbe" ]; then
|
|
|
|
|
[ -f "tmp/gbe" ] || $err "tmp/gbe exists and is not a file"
|
|
|
|
|
fi
|
|
|
|
|
x_ cp "${CONFIG_GBE_BIN_PATH##*../}" "tmp/gbe"
|
|
|
|
|
|
|
|
|
|
x_ "util/nvmutil/nvm" "tmp/gbe" setmac "$new_mac"
|
|
|
|
|
|
|
|
|
|
find "$tmpromdir" -maxdepth 1 -type f -name "*.rom" > "tmp/rom.list" \
|
|
|
|
|
|| $err "'$archive' -> Can't make tmp/rom.list - $dontflash"
|
|
|
|
|
|
|
|
|
|
while read -r _xrom; do
|
|
|
|
|
[ -L "$_xrom" ] && continue
|
|
|
|
|
[ -f "$_xrom" ] || continue
|
|
|
|
|
"$ifdtool" $ifdprefix -i GbE:"tmp/gbe" "$_xrom" -O \
|
|
|
|
|
"$_xrom" || $err "'$_xrom': Can't insert new GbE file"
|
|
|
|
|
xchanged="y"
|
|
|
|
|
done < "tmp/rom.list"
|
|
|
|
|
printf "\nThe following GbE NVM words were written in '$archive':\n"
|
|
|
|
|
x_ util/nvmutil/nvm tmp/gbe dump
|
2024-06-28 15:24:07 +00:00
|
|
|
}
|