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.
This commit cleans up the selection of the serial console device and
gives it sensible default values (usually, the DB9 header on the
back I/O panel) on each platform.
This commit integrates five more kgpe-d16 patches from my local
tree:
treewide: reduce many messages to BIOS_SPEW
southbridge/amd/sb700/lpc.c: leave LPC timeout mechanism enabled
I've been experiencing boot hangs during PNP enumeration of the LPC
bus. The southbridge chip comes with a mechanism to prevent
unresponsive/syncflooding LPC devices from wedging the system; let's
use it.
mainboard/asus/kgpe-d16/romstage.c: support console on ttyS1
Currently the romstage serial console initialization always
initializes SP1 (the DB9 header on the back of the motherboard).
Changing UART_FOR_CONSOLE simply causes the romstage to map the same
serial port at a different address (0x2f8).
This commit accounts for UART_FOR_CONSOLE (and its effect on
TTYS0_BASE) correctly: if UART_FOR_CONSOLE is changed from 0 to 1,
the romstage console output will be printed on the SP2 header (the
IDC ribbon header on the motherboard).
southbridge/amd/sb700/lpc.c: set SPI flash aperture to 16MB
The SPI flash aperture for the southbridge chip is set to 8MB, even
when a 16MB chip is used. Let's make the aperture large enough for
the maximum size chip that this board can accomodate.
amd/sb700/early_setup.c: select console properly
Currently, sb700/early_setup.c has this comment:
// XXX Serial port decode on LPC is hardcoded to 0x3f8
... and it unconditionally sets the output enable for ttyS0, even if
ttyS1 is also enabled. As a result, if coreboot is configured to
use ttyS1 for serial output, the romstage console output will appear
on *both* consoles.
This commit fixes that.
kgpe-d16: disable TPM
I have never heard of anybody using a TPM on this board, and the
fewer things we need to deal with during the somewhat-flaky LPC
init, the better.
On kgpe-d16 coreboot has long been plagued with occasional boot
hangs somewhere deep within the PNP initialization code. I'm still
hunting down the root cause, but for the moment reducing the logging
level helps.
Reducing the log level results in fewer fewer writes to the serial
port. The serial port has a very finicky initialization sequence,
because it needs to be usable *before* the PNP initialization has
run.
This commit adds several useful scripts (alongside the coreboot
image) in a `main` expression, which should be the primary build
expression going forward.
The following scripts should exists on all platforms:
- flashrom wrappers:
- `flashrom.sh`
- `flash-write-all.sh`
- `flash-write-fallback.sh`
- `flash-write-normal.sh`
- scripts to select which image (normal or fallback) is used for the
next boot:
- `nextboot-show.sh`
- `nextboot-use-fallback.sh`
- `nextboot-use-normal.sh`
- a script to write an image to the em100 flash-chip-emulator device:
- `em100-write.sh`
This commit generalizes the selection and activation of the serial
console by promoting it to a top-level package-set member.
The top-level package set is starting to attract clutter, so I will
soon be moving all the non-package constitutents into a `config`
attrset.
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.
At this point I am the only person who has contributed to ownerboot,
so I'm able to make this correction unilaterally. I wanted to do
this while I still had the chance.
Adam Joseph