This commit exposes the `fmap` (flash chip partition table) used to
build the coreboot image as the `passthru.fmap` attribute so it can
be referenced from other expressions.
Sadly we need at least two different forks of flashrom, with
different patches (and therefore different capabilities) applied to
each. This commit parameterizes the flashrom expression and
includes those parameters in the `passthru` so downstream
expressions can check whether various needed features are present.
This commit makes `hostPlatform` part of the packageset for more
consistent handling. A top-level `hostPlatform` argument is exposed
to the caller, in case they want to customize the `hostPlatform`
(compiler flags, etc).
The `hostPlatform` argument is inherited into the ownerboot package
set, where it will be overridden by `src/platform/*.nix` if it has
not been set explicitly.
Making `hostPlatform` part of the package set allows for more
sophisticated overriding schemes, for example adding additional
compiler flags or sanity-checking the flags that the user has
provided.
Since we (unfortunately) need to use different forks of flashrom for
different platforms, flashrom must be overrideable. Moving it into
the ownerboot packageset is the way to do that.
On amd64 platforms, booting ownerboot with the recovery jumper
installed will wipe the battery-backed nvram (aka "cmos" aka "rtc
nvram") and overwrite it with known-safe values taken from the
coreboot source code (`src/mainboard/asus/kgpe-d16/cmos.default`).
You should always do this when flashing a motherboard with ownerboot
for the first time.
This commit allows the user to customize the set of known-safe
values which are written when the recovery jumper is installed. To
do so, copy `src/mainboard/asus/kgpe-d16/cmos.default` out of
coreboot, edit to suit your tastes, and then override
`cmos-defaults` with the path to your customized `cmos.default`
file.
The microcode blob is only needed for Opteron 63xx chips. I have a
few of these, so I add the blob in a local overlay.
If other people are interested in this I will publish the overlay.
The 63xx chips are kind of rare and more expensive than the 62xx
chips -- their only real benefit is lower power draw. I ended up
receiving some by accident due to an incorrect eBay listing.
I accidentally checked in "ectool-patches-of-unclear-provenance.patch",
which was never used in any way by the build expressions.
This file contained my local patches to a very old version of
ectool, some of which came from Debian and some of which I wrote
myself. The `ectool.nix` expression uses a newer version of ectool,
which has upstreamed the relevant changes from Debian. So those
patches no longer need to be carried. The other patches delete
functionality which I don't need, but other people might, so those
patches won't be included in ownerboot.
Since a6cd35, ownerboot includes a patch to flashrom which allows
nested (but non-overlapping) fmap regions, so the flashrom.layout
file is no longer necessary.
ATF v1.6 on gru-kevin causes the laptop to reset itself instead of
waking up from suspend-to-ram. The cause of this problem is
something in the ~835 commits prior to the v1.6 release.
For now, let's simply use an older commit from upstream;
suspend-to-ram is pretty important for laptops.
TODO: git bisect and revert only the commits that cause this problem.
This bumps the kernel version on non-gru-kevin to 5.10.148, which
has fixes for the notorious Linux kernel wifi RCE exploits:
CVE-2022-41674, CVE-2022-42719, and CVE-2022-42720.
This bumps the kernel version on gru-kevin to 5.10.148, which has
fixes for the notorious Linux kernel wifi RCE exploits:
CVE-2022-41674, CVE-2022-42719, and CVE-2022-42720.
On all other platforms the ownerboot kernel is used only to kexec()
another long-lived kernel, and is therefore built without wifi
support and not vulnerable.
The gru-kevin laptop cannot use kexec() due to unfixable bugs in
mid-2010s versions of ARM's GICv3.
In some cases this bug can be worked around by having the
pre-kexec() kernel not fully initialize the GIC:
https://lore.kernel.org/lkml/20180921195954.21574-1-marc.zyngier@arm.com/
Unfortunately this workaround leaves the gru-kevin's screen in a
glitchy state post-kexec() which makes the laptop mostly unusable.
Adam Joseph