- 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.
This avoids overwriting the busybox binary (and bricking the system)
by following a symlink when busybox and other module both provide
a command with the same filename.
Signed-off-by: Daniel Pineda <daniel.pineda@puri.sm>
- update module version, hash
- rename patch
- update config
Busybox 1.33.0 adds base32, which has been disabled in busybox.config
as it conflicts with tpmtotp's base32.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
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.
Remove options that haven't deviated from defaults in the Coreboot
Kconfig, despite being saved by `make savedefconfig`. Also, add
`CONFIG_BOARD_LENOVO_THINKPAD_T440P`, which was missing from the `make
savedefconfig` output, causing Heads builds to fail. And finally, bump
`CONFIG_CBFS_SIZE` to `0x800000` (8 MiB to bytes to hexadecimal).
This value for the CBFS size is arbitrary. Originally, I had totaled the
size of all binary blobs, subtracted that from the T440p's ROM size (12
MiB), and used the remaining space as the CBFS size (~11.68 MiB).
However, this caused very long RAM initialization times (courtesy of
`cbmem -t`). And, an anecdote in
https://groups.google.com/a/chromium.org/g/chromium-os-reviews/c/lUqRrGUoEBY/m/ka7L1f2BS8gJ
suggested that this value needs to be a power of 2.
So, I picked a size I expected our Linux payload to fit into that was a
power of 2 that I also expected would leave enough space in the ROM for
the IFD, ME, GbE, and Coreboot.
Now, it takes less than a second for RAM initialization after
flashing/first boot (anecdotally, it seems the MRC needs to be
"trained?").
