Prior to this commit, ownerboot had quite a lot of "magic addresses"
and flash chip layouts. This commit eliminates all of them.
All flash chip geometry is now computed from first principles and
two parameters:
1. The flash chip size
2. The number of images per chip (two means NORMAL/FALLBACK)
If (flash-chip-size / num-images) is too small, coreboot's build
process will notice this and fail.
It should be possible to build a single-image (i.e. no FALLBACK)
ownerboot for use on 8mbyte flash chips, which lets people try this
out without having to buy a new flash chip or (in the case of the
rk3399-gru-kevin laptop) doing any soldering.
This commit significantly cleans up the assembly of the initramfs by
specifying and manipulating its contents using an attrset (in { dest
= src; } form) rather than chunks of bash script.
Previously the initramfs required overriders to use a custom
`$build` environment variable as the destination for files to be
packed into an initramfs image. This commit eliminates it, so the
standard $NIX_BUILD_TOP can be used instead.
commit fa3da49c84 "coreboot: update
patch to add master header in both images" still isn't causing
coreboot to put a master header into the NORMAL region. As a
result, images built after that commit but before this one will
always use the FALLBACK region.
This commit adds the master header explicitly, since I still can't
seem to get coreboot to do that on its own.
Previously ownerboot had separate `userspace` (the initramfs
contents without kernel modules) and `initramfs` (the complete
initramfs) expressions. This was done in order to allow the use of
CONFIG_INITRAMFS_SOURCE, which links an initramfs image into the
kernel itself.
I did this because I was having a hard time getting coreboot to load
a separate initrd on rk3399. I have since solved that problem, and
am now using coreboot to load an initramfs on all platforms. There
is no longer any need for this unusual separation.
Prior to this commit, ownerboot had to manually add the
cbfs-master-header to the NORMAL image, because the part of
coreboot's build machinery which adds it had not been updated to
understand ownerboot-style dual-CBFS images.
This commit updates the coreboot patch so that it does that job, and
removes the manual update from ownerboot.
As an added benefit, the NORMAL and FALLBACK images now have
identical layouts, except for the (top-aligned) bootblock on x86.
This commit includes, but does not apply, a patch that I was
experimenting with while solving the boot-hang problem.
This patch does not appear necessary, so it is not applied. However
I don't want to forget what I was experimenting with at the time, so
it is included here to make it part of the git history.
This commit adds a one-line coreboot patch which has finally solved
100% of my got-stuck-while-booting problems.
Upstream coreboot contains the following code:
/* Reset for HT, FIDVID, PLL and errata changes to take effect. */
if (!warm_reset_detect(0)) {
printk(BIOS_INFO, "...WARM RESET...\n\n\n");
soft_reset();
However `warm_reset_detect(0)` is *not* the complement of "cold
reset" (i.e. power supply was disconnected and reconnected).
Apparently there is a whole other category of "other resets" which
are neither warm nor cold. These conditions are detected by
`other_reset_detected()`.
The patch being added expands the condition above to include these:
if (other_reset_detected() || !warm_reset_detect(0)) {
After including this patch I have experienced zero of the infamous
"Assigning resources...<hang>" problems. Hooray!
This commit moves the `fmap` and `payload` arguments to `coreboot`
into the top-level scope, so they can be provided without needing to
override the `coreboot` expression.
This commit causes the coreboot payload (i.e. the Linux kernel,
initramfs, and any necessary DTBs) to be inserted into the coreboot
image as part of a separate derivation from the one which compiles
coreboot.
As a result, changing the contents of the initramfs is extremely
fast -- it can now be done without any recompilation.
As a result of this, the attribute name for the final image to be
flashed has changed from `coreboot` to `image`. The `coreboot`
attribute now builds a payloadless `coreboot.rom`.
This commit adds a coreboot patch which enables
CONFIG_USE_WATCHDOG_ON_BOOT for kgpe-d16; in upstream coreboot this
feature is found on only a few intel cpu platforms.
When enabled, this feature starts the hardware watchdog very early
in the boot process -- before PNP enumeration or DRAM
initialization. This ensures that any hangs or freezes due to
transient conditions (flakiness, temperature, electrical noise)
won't prevent the machine from eventually booting. This is very
useful for unattended servers.
On kgpe-d16 the watchdog is cancelled immediately before jumping to
the payload (i.e. Linux kernel). I found that if I left the
watchdog enabled, any attempt to use it (for example, to cancel it
or extend it) from Linux resulted in the machine resetting. Perhaps
this can be fixed, but for now I am content to simply re-enable the
watchdog from Linux rather than leaving it running.
Previously, the flashrom scripts would pass --fmap to every
invocation of flashrom, even when overwriting the entire image.
This was unnecessary, and would cause issues if the chip being
written to had a corrupted fmap table. This commit passes the
--fmap flag only when it is needed due to the -i flag being present.
This commit adds a coreboot patch which causes kgpe-d16 to skip the
PNP enumeration/assignment process for the "hardware monitor"
(basically a temperature sensor and fan-speed controller) block on
the southbridge chip.
I have found this patch solves the last remaining boot reliability
problem I was having with my unattended kgpe-d16 machines.
The commit message for this patch is below:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
The hardware monitor is one of the blocks within the w83667hg-a chip
(there are many others). It is basically a bunch of ADCs (analog to
digital converters) hooked up to voltage, current, and temperature
sensors in various locations on the motherboard.
This block has the ability to generate several different interrupts
(SMI#, OVT#, etc) in response to thermal conditions. It appears to
sometimes (about 10% of boot-ups, depending on temperature) spew
erroneous alarm interrupts the instant you enable it, when doing so
from within coreboot. This causes the w83667hg-a chip and the
entire system to hang, and the watchdog cannot recover from this
state because it is part of the w83667hg-a chip too.
An even bigger problem is that the hardware monitor is initialized
*before* the fans are brought up to full speed. So if the CPU is
above the critical temperature it will remain there because the fans
are in their default low-speed boot state. The chip just keeps
getting hotter and hotter -- not enough to damage itself, but hot
enough that it won't come down to an acceptable temperature with
simple reboots and power-cycles; you have to leave the system off
for a while. Since the fans aren't running while the system is off
this takes quite a while (several minutes). It's a very fussy and
fidgety process, and not something you want to walk a remote-hands
guy at the datacenter through over the phone.
To avoid this whole mess, let's simply not assign PNP resources to
the hardware monitor from coreboot. Linux doesn't need these
anyways; it communicates with the hardware using I2C.
This commit reorders the (rather large) list of patches to coreboot,
sorts them by category, and adds comments to explain them.
No change in the post-patchPhase source.
Now that 6deb86f6138265a715dd005c310ad33a2e2865ff has merged
upstream in nixpkgs we can directly reference arm-trusted-firmware
as part of the nixpkgs package set. This allows to eliminate a
<nixpkgs>-style path reference.
In order to write to the chromebook embedded controller flash we
need to use Google's fork of flashrom. However for writing to the
chromebook CPU firmware flash (which is a different flash chip) we
can use mainline flashrom. So let's do that.
On x86 platforms, it is necessary to wrap the entire image in a
BIOS@0 region which marks the memory-mapped flash image as needing
SMM protection. Unfortunately this creates overlapping FMAP
regions, which flashrom cannot handle without a patch.
On arm64 platforms, the BIOS@0 region is not needed. So let's not
include it. This allows us to skip the flashrom patch on arm64.
This commit changes a few path-references into `<nixpkgs/..>` so
they use attrset references instead. This way it is not necessary
to have nixpkgs accessible via $NIX_PATH when you build ownerboot.
Upstream describes this option as "Enable this option if coreboot
shall read options from the CMOS NVRAM instead of using hard-coded
values."
The RTC_BOOT_BYTE (which controls normal/fallback) indicator is
always taken from CMOS NVRAM, regardless of how this option is set.
When set to `no`, no other parts of the CMOS NVRAM are read or
written.
On KGPE-D16 I have found that USE_OPTION_TABLE=yes is frustratingly
flaky and unstable; about 1 in 20 boots will hang in the PNP device
enumeration. Apparently during SMP boot, multiple cores attempt to
access the (single) CMOS NVRAM concurrently, causing massive
headaches. Please don't turn this option on unless you are willing
to deal with extreme frustration.
Trying to write to a chip using --fmap will fail if the chip does
not yet have a valid fmap table (for example, a blank chip). Let's
omit this flag when writing the entire image.
This commit drops the verbatim `.config` files for coreboot that
were previously in the repository and converts them to NixOS-style
module configurations.
The big benefit of doing this is that the perl script in nixpkgs
that handles this will check to make sure that coreboot's Kconfig
machinery isn't silently ignoring any of our settings. It also
makes this configuration easier for end-users to customize.
Raito Bezarius
Adam Joseph