Move board configuration into `boards/` instead of `config/`
Fix mistake in building kernel module tree before kernel was done.
Allow per-board initrd builds (#278)
Allow per-board configurations for things (#304)
This modifies the `Makefile.nerf` to create files based on the
$(BOARD) variable, which is necessary as we start to support
multiple mainboards.
The config files must define five variables, all in bytes:
* `NERF_SIZE` - for the EFI firmware volume that contains Linux
* `PEI_SIZE` - size of the PEI image in the vendor ROM
* `PEI_OFFSET` - offset of the PEI image in the vendor ROM
* `ME_SIZE` - size of the ME image in the vendor ROM, or 0 if
there is no ME image to be extracted.
* `ME_OFFSET` - offset of the ME image in the vendor ROM
The `ifd.bin` must be created and can be checked in.
The default ROM input file is `blobs/$(BOARD)/$(BOARD).rom`,
and it *must not* be checked in.
This links in the AcpiTableDxe and AcpiPlatform executables from
the edk2 build tree and adds a depex dependency for the Linux
kernel on the AcpiTable being setup. The `acpi.cpio` file is
no longer included in the Linux kernel bzImage.
The `Makefile.nerf` has been re-written to generate the firmware
file system (FFS) files via rules.
TODO: figure out how to add LZMA compressed sections so that the
900k acpi tables can be compressed to about 100k.
This allows flashrom to work on the r630 NERF server, but
also increases the size of the flashrom executable significantly
since it brings in all chipset and flash types.
This development branch builds a NERF firmware for the Dell R630
server. It does not use coreboot; instead it branches directly
from the vendor's PEI core into Linux and the Heads runtime
that is setup to be run as an EFI executable.
Changed the checking of required hashes or required rollback state
to be right before boot, allowing the user to sign/set defaults
in interactive mode.
Also cleaned up usages of recovery and fixed iso parameter
regression.
Similar to qubes-update, it will save then verify the hashes of
the kexec files. Once TOTP is verified, a normal boot will verify
that the file hashes and all the kexec params match and if
successful, boot directly to OS.
Also added a config option to require hash verification for
non-recovery boots, failing to recovery not met.
Refactored boot parsing code and applied that in local-init to
scan /boot for grub options and allow the user to unsafely boot
anything. This goes a long way to addressing #196.
Optionally the user can customize those boot parameters or enforce
arbitrary hashes on the boot device by creating and signing config
files in /boot/ or /media/ or /media/kexec_iso/ISO_FILENAME/.
Supports booting from USB media using either the root device or
a signed ISO as the boot device. Boot options are parsed with
quick/dirty shell scripts to infer kexec params.
Closes#195 and begins to address #196
Replace libuuid with util-linux libuuid (and libblkid,
although we are not using libblkid right now).
This also requires a much larger coreboot cbfs, which was
fixed as part of issue #154.
This addresses multiple issues:
* Issue #63: initrd is build fresh each time, so tracked files do not matter.
* Issue #144: build time configuration
* Issue #123: allows us to customize the startup experience
* Issue #122: manual start-xen will go away
* Issue #25: tpmtotp PCRs are updated after reading the secret
* Issue #16: insmod now meaures modules
This is a step towards unifying the server and laptop config (issue #139)
and also makes it possible to later remove the USB modules from the
normal boot path.
No patches are required to boot 4.9 as a coreboot payload,
unlike the 4.7 kernel that required a head_64.S patch.
The new kernel is about 40 KB larger than the 4.7; the
config might be shrinkable.
Close issue #61.
rename TARGET to BOARD (fix#55)
use .INTERMEDIATE trick to avoid building multiple times (fix#52)
Don't touch build/*/.config if we don't have to (fix#51)
This touches most of the module configurations since the
coreboot build process had to add a few new features.
The Linux kernel could make use of it as well if we need
separate x230/chell/qemu kernels, for instance.
