This change will improve build times by allowing the T440p to share the
Coreboot 4.17 cache with the Librem boards. Once we update the other
ThinkPad boards to use Coreboot 4.19, we'll make the T440p depend on the
X230 again.
Co-authored-by: Thierry Laurion <insurgo@riseup.net>
Because we're using pushd/popd to make the Coreboot util invocation
cleaner, we need to use realpath so that the scripts will work with any
user input.
Before, the T440p blob scripts would look for Coreboot using the find
command. Now, we require the user to specify the path to Coreboot in the
COREBOOT_DIR environment variable. Also, add an output directory
argument to each script.
These changes will make it easier to integrate with the Heads build
system and CI.
- I extracted the gbe.bin blob from my T440p's original ROM using the
blobs/t440p/extract script.
- Using a hex editor, I corrected the sign bit in part 0 that I found
was malformed in my analysis:
https://github.com/osresearch/heads/pull/1282#issuecomment-1400634600.
- After correcting the sign bit, nvmutil showed that both parts of my
gbe.bin blob had valid checksums.
- Finally, I used nvmutil to set the MAC address to 00🇩🇪ad:c0:ff:ee.
pkg-config will still pick up system default directories from
PKG_CONFIG_LIBDIR even if PKG_CONFIG_PATH is set. Per the docs,
cross compilation requires clearing PKG_CONFIG_PATH and setting
PKG_CONFIG_LIBDIR (which is always searched after PKG_CONFIG_PATH).
Fixes issues observed in tpm2_retry branch picking up packages from
host environment.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
- Add TRACE function tracing output under etc/functions, depending on CONFIG_ENABLE_FUNCTION_TRACING_OUTPUT enabled in board configs
- Replace current DEBUG to TRACE calls in code, reserving DEBUG calls for more verbose debugging later on (output of variables etc)
- add 'export CONFIG_ENABLE_FUNCTION_TRACING_OUTPUT=y' in qemu-coreboot(fb)whiptail-tpm1(-hotp) boards to see it in action
The calculations outlined at https://github.com/osresearch/heads/pull/1282#discussion_r1072473677
Sums to having 'ifdtool -f layout.txt ifd_shrinked.bin && cat layout.txt'
The example for T440p:
00000000:00000fff fd
00021000:00bfffff bios
00003000:00020fff me
00001000:00002fff gbe
Here: 00bfffff-00021000=BDEFFF
Which is exact result of @rbeslow's calculations.
There is an issue on haswell, maybe because of car, maybe because of non native memory init blob.
But this is not the case for xx20/xx30 boards.
- add x230-maximized-fhd_edp and x230-hotp-maximized-fhd_edp board configs
- add/rework coreboot patch for x230 fhd variant to be applied on top of 4.13
- add coreboot config to point to x230-edp variant, fixing path to vbt file since default path is wrong under. Comment made upstream https://review.coreboot.org/c/coreboot/+/28950/22#message-4904ce82f01ba0505b391e072e4537b6a9f1a229
- remove no gfx init and replace with libgfxinit(defonfig default), set internal display as default
- add x230-hotp-maximized-fhd_edp and x230-maximized-fhd_edp to CircleCI builds
- One single shared coreboot config between boards/x230-hotp-maximized-fhd_edp/x230-hotp-maximized-fhd_edp.config and boards/x230-maximized-fhd_edp/x230-maximized-fhd_edp.config
- Coreboot 4.13 patch from coreboot at patches/coreboot-4.13/0002-x230-fhd-variant.patch
- config/coreboot-x230-maximized-fhd_edp.config points to seperate coreboot config per patch (CONFIG_BOARD_LENOVO_X230_EDP)
- kexec-save-default extracts initrd crypttab files and creates /boot/kexec_initrd_crypttab_overrides.txt entries pointing to /secret.key
- kexec-insert-key applies /boot/kexec_initrd_crypttab_overrides.txt to replace initrd's crypttabs files pointing to inserted /secret.key through cpio
- Both scripts inform the user of applied magic on screen
Not all distro put crypttab under /etc/ within initramfs, but finding it at
runtime needs unpacking, which may be hard to do, so it is made overridable
with a file at /boot/kexec_initrd_crypttab_path.txt, whose content could be
obtained with $ cpio -t < ${uncompressed_initrd} | grep crypttab .
The "target" field of the record within the crypttab stored in the root
file system for the luks container which is going to be unlocked via
kexec-insert-key should be modified into the same "luks-$uuid" format,
otherwise the boot sequence will get stuck when OS is trying to unlock them
again, in order to map them according to "target" fields written in the
crypttab stored in the root fs.
I went through all of the different options we copied from the Librem
config. The only thing that stood out as irrelevant was NVMe support.
However, I'm not a Linux kernel expert, and I didn't do a deep dive, so
I'm sure there is still room for improvement.
