rustup conflicts with itself when a component is installed via the
toolchain file vs rustup directly. Update the apps so submodules do not
attempt to (re)install components using rustup.
If a board in models/ does not exist in coreboot, coreboot will emit a
warning and select the first available board for the vendor instead.
This may result in building and being able to flash coreboot with an
addw1 configuration on another board.
rustup 1.23.0 (2020-11-27) introduced support for TOML syntax for the
toolchain file. Use this and specify required compoenents.
To ensure you are using a new enough rustup, run:
rustup self update
If a board in models/ does not exist in coreboot, coreboot will emit a
warning and select the first available board for the vendor instead.
This may result in building and being able to flash coreboot with an
addw1 configuration on another board.
Fedora has apt packaged, which causes this script to do the wrong
thing if it is installed. Instead of checking for the package manager
binary, use os-release(5) data to select the correct package manager
to use.
Using the Intel GOP driver from proprietary firmware has resolved some
issues with the lemp10. Use UEFIExtract from UEFITool to extract the GOP
driver from the proprietary firmware for other boards.
./UEFIExtract <firmware.rom> 7755CA7B-CA8F-43C5-889B-E1F59A93D575
The version we have been using is what is present in gaze14.
Use minimal set of config selections and let coreboot generate the
default values for the rest of them.
The only differences are the following models selecting
CONFIG_CPU_MICROCODE_CBFS_DEFAULT_BINS instead of *_EXTERNAL_BINS:
- darp5
- darp6
- galp3-c
- galp4
- lemp9
My build failed on a Pop!_OS-Live-Stick until I installed `libudev-dev`. I don't remember if it was the firmware-open or the ec build that failed, but ec references deps.sh.
