Most useful to me are:
coreboot.modify_and_save_defconfig_in_place
coreboot.modify_and_save_oldconfig_in_place
linux.modify_and_save_oldconfig_in_place
linux.modify_and_save_defconfig_in_place
Which permit to take current in tree configs and translate them into other format.
This is useful when trying to version bump and build.
Also add helpers to save in versioned version to facilitate change tracking:
linux.generate_and_save-versioned-oldconfig
linux.regenerate_and_save_versioned_defconfig
Update kexec to 2.0.26. Add tracing to framebuffer initialization. In
particular, the driver name is traced if not recognized, and messages
about kernel config are shown if the kernel doesn't provide the
framebuffer pointer.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Add CONFIG_DRM_FBDEV_LEAK_PHYS_SMEM and related kernel parameters to
t440p. This board is already on kernel 5.10 and uses i915 graphics.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Allow leaking the DRM framebuffer pointer to userspace, and disable
framebuffer compression, like librem_15v4.
Tested booting memtest86+ and Debian netinstaller on Mini v2.
Do not enable this for L1UM, it uses Aspeed graphics which still don't
work. qemu uses virtio graphics, which also are not working.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
Compressed framebuffer requires the driver to track updates to the
framebuffer from the CPU and update the compressed framebuffer. This
doesn't work if we kexec into an OS that will use the linear
framebuffer, so disable it. (The OS kernel can still use compressed
framebuffer if it has i915.)
Linux 5.8 enabled compressed framebuffer on more chipsets using i915,
which is why this stopped working.
memtest86+ and Debian (manually blacklisted i915, comparable to
netinst) now boot correctly on Librem 15v4. This will need to be
enabled for other boards too.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
The i915 driver's ID changed again, now to i915drmfb.
It's unclear why kexec checks this, it seems it could populate the
target kernel's framebuffer info as long as it knows enough about the
host kernel's framebuffer, which it already checks. Maybe we could
improve this, for now just add the new ID again.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
kexec(8) needs to get the framebuffer address in order to set up the
new kernel's boot parameters. This is one of the reasons that using a
>4.20 kernel in Heads prevents framebuffer graphics from working in the
OS kernel.
Linux 4.20 started hiding this address from userspace, because
userspace is not supposed to need physical memory addresses. A
workaround was added to keep leaking the address, apparently for some
proprietary userspace OpenGL drivers. This requires both a Kconfig and
a kernel parameter.
This commit enables the Kconfig on the librem_common config, and the
kernel parameter on the librem_15v4 (where I'm testing this). We will
need to enable it on other >4.20 configs/boards as well.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
This isn't in a loop, continue makes no sense. ash had silently
ignored it. Proceeding to the do_boot below is the correct behavior.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
For partitioned media or when more than one device is present, this
fixes a benign script error that ash had apparently ignored.
Signed-off-by: Jonathon Hall <jonathon.hall@puri.sm>
By default json-c builds as debug instead of release.
Adding CMAKE_BUILD_TYPE=minsizerel ensures it does not
add debug info and also optimizes for file size.
Signed-off-by: Daniel Pineda <daniel.pineda@puri.sm>
- Trace calls need to happen after sourcing /etc/functions not before
- Move sourcing of external files at beginning of file, remove /etc/functions sourcing duplicate
- gpg error redirection was sent to /dev/null where expected to be added to whiptail in case of error (2>&1 instead and redirection to file)
Problem
When using a custom password for TPM, the OEM re-ownership process is broken
Impact
The OEM re-ownership process breaks for any user setting a custom password and not just using 12345678
First appeared
6923fb5e20
Detail
on line 498, if blank, the TPM custom password is overwritten with TPM_PASS_DEF (eg, when no custom password is set by the user installing)
```
if [ "$TPM_PASS" == "" ]; then TPM_PASS=$TPM_PASS_DEF; fi
```
so far so good. $TPM_PASS should be used for all TPM interaction from this point. $TMP_PASS_DEF is now a disposed of variable.
we see that happens when resetting the TPM on line 712 (generate_checksums) is that $TPM_PASS is used (correctly)
```## reset TPM and set password
if [ "$CONFIG_TPM" = "y" ]; then
echo -e "\nResetting TPM...\n"
tpmr reset "$TPM_PASS" >/dev/null 2>/tmp/error
---SNIP
```
The TPM now has either the custom password of the user, or the default of 12345678 depending on user selection.
On line 712, we duck into the generate_checksums sub, which for some reason reverts to TPM_PASS_DEF
```
# create Heads TPM counter
if [ "$CONFIG_TPM" = "y" ];then
if [ "$CONFIG_IGNORE_ROLLBACK" != "y" ]; then
tpmr counter_create \
-pwdo "$TPM_PASS_DEF" \
--SNIP
```
This then, rightly, fails due to
```
Authentication failed (Incorrect Password) (ox1) from TPM_CreateCounter
```
This patch adds ARCH="$(LINUX_ARCH)" to Linux targets working on config
files. Without it, the architecture defaults to that of host, which for
cross-compilation isn't right.
Signed-off-by: Krystian Hebel <krystian.hebel@3mdeb.com>
