lbmk/script/vendor/inject

240 lines
6.8 KiB
Plaintext
Raw Normal View History

#!/usr/bin/env sh
# SPDX-License-Identifier: GPL-3.0-only
# SPDX-FileCopyrightText: 2022 Caleb La Grange <thonkpeasant@protonmail.com>
# SPDX-FileCopyrightText: 2022 Ferass El Hafidi <vitali64pmemail@protonmail.com>
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
# SPDX-FileCopyrightText: 2023-2024 Leah Rowe <leah@libreboot.org>
. "include/err.sh"
. "include/option.sh"
nvmutil="util/nvmutil/nvm"
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
eval "$(setvars "" archive rom modifygbe nukemode release new_mac tree)"
main()
{
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
[ $# -lt 1 ] && $err "No options specified."
[ "${1}" = "listboards" ] && eval "items config/coreboot || :; exit 0"
archive="${1}"
while getopts n:r:b:m: option; do
case "${option}" in
n) nukemode="${OPTARG}" ;;
r) rom=${OPTARG} ;;
b) board=${OPTARG} ;;
m) modifygbe=true
new_mac=${OPTARG} ;;
*) : ;;
esac
done
check_board
build_dependencies
inject_vendorfiles
[ "${nukemode}" = "nuke" ] && return 0
printf "Friendly reminder (this is *not* an error message):\n"
printf "Please ensure that the files were inserted correctly.\n"
}
check_board()
{
failcheck="n"
check_release "${archive}" || failcheck="y"
if [ "${failcheck}" = "y" ]; then
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
[ -f "$rom" ] || $err "check_board \"$rom\": invalid path"
[ -z "${rom+x}" ] && $err "check_board: no rom specified"
[ -n "${board+x}" ] || board=$(detect_board "${rom}")
else
release="y"
much, much stricter, more verbose error handling lbmk is much more likely to crash now, in error conditions, which is a boon for further auditing. also: in "fetch", remove the downloaded program if fail() was called. this would also be done for gnulib, when downloading grub, but done in such a way that gnulib goes first. where calls to err write "ERROR" in the string, they no longer say "ERROR" because the "err" function itself now does that automatically. also: listmodes/listoptions (in "lbmk") now reports an error if no scripts and/or directories are found. also: where a warning is given, but not an error, i've gone through in some places and redirected the output to stderr, not stdout as part of error checks: running anything as root, except for the "./build dependencies *" commands, is no longer permitted and lbmk will throw an error mrc downloads: debugfs output no longer redirected to /dev/null, and stderr no longer redirected to stdout. everything is verbose. certain non-error states are also more verbose. for example, patch_rom in blobs/inject will now state when injection succeeds certain actual errors(bugs) were fixed: for example, build/release/roms now correctly prepares the blobs hash files for a given target, containing only the files and checksums in the list. Previously, a printf message was included. Now, with this new code: blobutil/inject rightly verifies hashes. doing all of this in one giant patch is cleaner than 100 patches changing each file. even this is yet part of a much larger audit going on in the Libreboot project. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-08-24 19:19:41 +00:00
board=$(detect_board "${archive}")
fi
boarddir="${cbcfgsdir}/${board}"
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
[ -d "$boarddir" ] || $err "check_board: board $board missing"
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
[ -f "$boarddir/target.cfg" ] || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "check_board $board: target.cfg missing"
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
. "$boarddir/target.cfg" 2>/dev/null
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
[ -z "$tree" ] && $err "check_board $board: tree undefined"; return 0
}
check_release()
{
[ -f "${archive}" ] || return 1
[ "${archive##*.}" = "xz" ] || return 1
printf "%s\n" "Release archive ${archive} detected"
}
# This function tries to determine the board from the filename of the rom.
# It will only succeed if the filename is not changed from the build/download
detect_board()
{
path="${1}"
filename=$(basename "${path}")
case ${filename} in
grub_*)
board=$(echo "${filename}" | cut -d '_' -f2-3) ;;
seabios_withgrub_*)
board=$(echo "${filename}" | cut -d '_' -f3-4) ;;
*.tar.xz)
_stripped_prefix=${filename#*_}
board="${_stripped_prefix%.tar.xz}" ;;
*)
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "detect_board $filename: could not detect board type"
esac
printf "%s\n" "${board}"
}
build_dependencies()
{
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
cbdir="src/coreboot/$tree"
cbfstool="cbutils/$tree/cbfstool"
ifdtool="cbutils/$tree/ifdtool"
[ -d "${cbdir}" ] || x_ ./update trees -f coreboot $tree
if [ ! -f "${cbfstool}" ] || [ ! -f "${ifdtool}" ]; then
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
x_ ./update trees -b coreboot utils $tree
fi
[ -z "$new_mac" ] || [ -f "$nvmutil" ] || x_ make -C util/nvmutil
[ "$nukemode" = "nuke" ] || x_ ./vendor download $board; return 0
}
inject_vendorfiles()
{
[ "${release}" != "y" ] && eval "patch_rom \"$rom\"; return 0"
patch_release_roms
}
patch_release_roms()
{
_tmpdir="tmp/romdir"
remkdir "${_tmpdir}"
tar -xf "${archive}" -C "${_tmpdir}" || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "patch_release_roms: !tar -xf \"$archive\" -C \"$_tmpdir\""
for x in "${_tmpdir}"/bin/*/*.rom ; do
printf "patching rom: %s\n" "$x"
patch_rom "${x}"
done
(
cd "${_tmpdir}/bin/"* || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "patch_release_roms: !cd ${_tmpdir}/bin/*"
# NOTE: For compatibility with older rom releases, defer to sha1
[ "${nukemode}" = "nuke" ] || sha512sum --status -c vendorhashes || \
sha1sum --status -c vendorhashes || sha512sum --status -c \
blobhashes || sha1sum --status -c blobhashes || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "patch_release_roms: ROMs did not match expected hashes"
) || $err "can't verify vendor hashes"
[ "${modifygbe}" = "true" ] && \
for x in "${_tmpdir}"/bin/*/*.rom ; do
modify_gbe "${x}"
done
[ -d bin/release ] || x_ mkdir -p bin/release
x_ mv "${_tmpdir}"/bin/* bin/release/
x_ rm -Rf "${_tmpdir}"
much, much stricter, more verbose error handling lbmk is much more likely to crash now, in error conditions, which is a boon for further auditing. also: in "fetch", remove the downloaded program if fail() was called. this would also be done for gnulib, when downloading grub, but done in such a way that gnulib goes first. where calls to err write "ERROR" in the string, they no longer say "ERROR" because the "err" function itself now does that automatically. also: listmodes/listoptions (in "lbmk") now reports an error if no scripts and/or directories are found. also: where a warning is given, but not an error, i've gone through in some places and redirected the output to stderr, not stdout as part of error checks: running anything as root, except for the "./build dependencies *" commands, is no longer permitted and lbmk will throw an error mrc downloads: debugfs output no longer redirected to /dev/null, and stderr no longer redirected to stdout. everything is verbose. certain non-error states are also more verbose. for example, patch_rom in blobs/inject will now state when injection succeeds certain actual errors(bugs) were fixed: for example, build/release/roms now correctly prepares the blobs hash files for a given target, containing only the files and checksums in the list. Previously, a printf message was included. Now, with this new code: blobutil/inject rightly verifies hashes. doing all of this in one giant patch is cleaner than 100 patches changing each file. even this is yet part of a much larger audit going on in the Libreboot project. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-08-24 19:19:41 +00:00
printf "Success! Your ROMs are in bin/release\n"
}
patch_rom()
{
rom="${1}"
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
check_defconfig "$boarddir" && $err "patch_rom $boarddir: no configs"
set -- "${boarddir}/config/"*
. "${1}" 2>/dev/null
[ "$CONFIG_HAVE_MRC" = "y" ] && \
inject "mrc.bin" "${CONFIG_MRC_FILE}" "mrc" "0xfffa0000"
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 "$CONFIG_HAVE_REFCODE_BLOB" ] && \
inject "fallback/refcode" "$CONFIG_REFCODE_BLOB_FILE" "stage"
[ "${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}"
[ -n "$CONFIG_VGA_BIOS_FILE" ] && [ -n "$CONFIG_VGA_BIOS_ID" ] && \
inject "pci${CONFIG_VGA_BIOS_ID}.rom" \
"${CONFIG_VGA_BIOS_FILE}" "optionrom"
[ "${CONFIG_INCLUDE_SMSC_SCH5545_EC_FW}" = "y" ] && \
[ -n "${CONFIG_SMSC_SCH5545_EC_FW_FILE}" ] && \
inject "sch5545_ecfw.bin" "$CONFIG_SMSC_SCH5545_EC_FW_FILE" raw
[ "${modifygbe}" = "true" ] && ! [ "${release}" = "y" ] && \
inject "IFD" "${CONFIG_GBE_BIN_PATH}" "GbE"
much, much stricter, more verbose error handling lbmk is much more likely to crash now, in error conditions, which is a boon for further auditing. also: in "fetch", remove the downloaded program if fail() was called. this would also be done for gnulib, when downloading grub, but done in such a way that gnulib goes first. where calls to err write "ERROR" in the string, they no longer say "ERROR" because the "err" function itself now does that automatically. also: listmodes/listoptions (in "lbmk") now reports an error if no scripts and/or directories are found. also: where a warning is given, but not an error, i've gone through in some places and redirected the output to stderr, not stdout as part of error checks: running anything as root, except for the "./build dependencies *" commands, is no longer permitted and lbmk will throw an error mrc downloads: debugfs output no longer redirected to /dev/null, and stderr no longer redirected to stdout. everything is verbose. certain non-error states are also more verbose. for example, patch_rom in blobs/inject will now state when injection succeeds certain actual errors(bugs) were fixed: for example, build/release/roms now correctly prepares the blobs hash files for a given target, containing only the files and checksums in the list. Previously, a printf message was included. Now, with this new code: blobutil/inject rightly verifies hashes. doing all of this in one giant patch is cleaner than 100 patches changing each file. even this is yet part of a much larger audit going on in the Libreboot project. Signed-off-by: Leah Rowe <leah@libreboot.org>
2023-08-24 19:19:41 +00:00
printf "ROM image successfully patched: %s\n" "${rom}"
}
inject()
{
[ $# -lt 3 ] && \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "inject $@, $rom: usage: inject name path type (offset)"
eval "$(setvars "" cbfsname _dest _t _offset)"
cbfsname="${1}"
_dest="${2##*../}"
_t="${3}"
[ $# -gt 3 ] && _offset="-b ${4}" && [ -z "${4}" ] && \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "inject $@, $rom: offset passed, but empty (not defined)"
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
[ -z "${_dest}" ] && $err "inject $@, ${rom}: empty destination path"
[ ! -f "${_dest}" ] && [ "${nukemode}" != "nuke" ] && \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "inject_${dl_type}: file missing, ${_dest}"
[ "$nukemode" = "nuke" ] || \
printf "Inserting %s/%s in file: %s\n" "$cbfsname" "$_t" "$rom"
if [ "${_t}" = "GbE" ]; then
x_ mkdir -p tmp
cp "${_dest}" "tmp/gbe.bin" || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "inject: !cp \"${_dest}\" \"tmp/gbe.bin\""
_dest="tmp/gbe.bin"
"${nvmutil}" "${_dest}" setmac "${new_mac}" || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "inject ${_dest}: can't change mac address"
fi
if [ "${cbfsname}" = "IFD" ]; then
if [ "${nukemode}" != "nuke" ]; then
"$ifdtool" -i ${_t}:${_dest} "$rom" -O "$rom" || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "inject: can't insert $_t ($dest) into $rom"
else
"$ifdtool" --nuke $_t "$rom" -O "$rom" || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "inject $rom: can't nuke $_t in IFD"
fi
else
if [ "${nukemode}" != "nuke" ]; then
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
if [ "$_t" = "stage" ]; then # broadwell refcode
"$cbfstool" "$rom" add-stage -f "$_dest" \
-n "$cbfsname" -t stage -c lzma
else
"$cbfstool" "$rom" add -f "$_dest" \
-n "$cbfsname" -t $_t $_offset || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "$rom: can't insert $_t file $_dest"
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
fi
else
"$cbfstool" "$rom" remove -n "$cbfsname" || \
safer, simpler error handling in lbmk in shell scripts, a function named the same as a program included in the $PATH will override that program. for example, you could make a function called ls() and this would override the standand "ls". in lbmk, a part of it was first trying to run the "fail" command, deferring to "err", because some scripts call fail() which does some minor cleanup before calling err. in most cases, fail() is not defined, and it's possible that the user could have a program called "fail" in their $PATH, the behaviour of which we could not determine, and it could have disastrous effects. lbmk error handling has been re-engineered in such a way that the err function is defined in a variable, which defaults to err_ which calls err_, so defined under include/err.sh. in functions that require cleanup prior to error handling, a fail() function is still defined, and err is overridden, thus: err="fail" this change has made xx_() obsolete, so now only x_ is used. the x_ function is a wrapper that can be used to run a command and exit with non-zero status (from lbmk) if the command fails. the xx_ command did the same thing, but called fail() which would have called err(); now everything is $err example: rm -f "$filename" || err "could not delete file" this would now be: rm -f "$filename" || $err "could not delete file" overriding of err= must be done *after* including err.sh. for example: err="fail" . "include/err.sh" ^ this is wrong. instead, one must do: . "include/err.sh" err="fail" this is because err is set as a global variable under err.sh the new error handling is much cleaner, and safer. it also reduces the chance of mistakes such as: calling err when you meant to call fail. this is because the standard way is now to call $err, so you set err="fail" at the top of the script and all is well. Signed-off-by: Leah Rowe <leah@libreboot.org>
2024-03-27 01:19:39 +00:00
$err "inject $rom: can't remove $cbfsname"
fi
fi
}
usage()
{
cat <<- EOF
USAGE: ./vendor inject -r [rom path] -b [boardname] -m [macaddress]
Example: ./vendor inject -r x230_12mb.rom -b x230_12mb
Adding a macadress to the gbe is optional.
If the [-m] parameter is left blank, the gbe will not be touched.
Type './vendor inject listboards' to get a list of valid boards
EOF
}
main $@