2022-02-24 01:08:27 +01:00
|
|
|
coreboot 4.16
|
2021-10-29 20:00:50 +02:00
|
|
|
================================
|
|
|
|
|
2022-02-24 01:08:27 +01:00
|
|
|
The 4.16 release is planned for February 25th, 2022.
|
2021-11-08 19:52:36 +01:00
|
|
|
|
2022-02-24 01:08:27 +01:00
|
|
|
Since 4.15 there have been more than 1730 new commits by more than 171 developers.
|
|
|
|
Of these, over 35 contributed to coreboot for the first time.
|
2021-10-29 20:00:50 +02:00
|
|
|
|
2022-02-24 01:08:27 +01:00
|
|
|
Welcome to the project!
|
2021-10-29 20:00:50 +02:00
|
|
|
|
2022-02-24 01:08:27 +01:00
|
|
|
Thank you to all the developers who continue to make coreboot the
|
|
|
|
great open source firmware project that it is.
|
|
|
|
|
|
|
|
New mainboards:
|
|
|
|
-------------------
|
|
|
|
* Acer Aspire VN7-572G
|
|
|
|
* AMD Chausie
|
|
|
|
* ASROCK H77 Pro4-M
|
|
|
|
* ASUS P8Z77-M
|
|
|
|
* Emulation QEMU power9
|
|
|
|
* Google -> Agah
|
|
|
|
* Google -> Anahera4ES
|
|
|
|
* Google -> Banshee
|
|
|
|
* Google -> Beadrix
|
|
|
|
* Google -> Brya4ES
|
|
|
|
* Google -> Crota
|
|
|
|
* Google -> Dojo
|
|
|
|
* Google -> Gimble4ES
|
|
|
|
* Google -> Herobrine_Rev0
|
|
|
|
* Google -> Kingler
|
|
|
|
* Google -> Kinox
|
|
|
|
* Google -> Krabby
|
|
|
|
* Google -> Moli
|
|
|
|
* Google -> Nereid
|
|
|
|
* Google -> Nivviks
|
|
|
|
* Google -> Primus4ES
|
|
|
|
* Google -> Redrix4ES
|
|
|
|
* Google -> Skyrim
|
|
|
|
* Google -> Taeko4ES
|
|
|
|
* Google -> Taniks
|
|
|
|
* Google -> Vell
|
|
|
|
* Google -> Volmar
|
|
|
|
* Intel Alderlake-N RVP
|
|
|
|
* Prodrive Atlas
|
|
|
|
* Star Labs Star Labs StarBook Mk V (i3-1115G4 and i7-1165G7)
|
|
|
|
* System76 gaze16 3050
|
|
|
|
* System76 gaze16 3060
|
|
|
|
* System76 gaze16 3060-b
|
|
|
|
|
|
|
|
Removed mainboards:
|
|
|
|
-------------------
|
|
|
|
* Google -> Corsola
|
|
|
|
* Google -> Nasher
|
|
|
|
* Google -> Stryke
|
|
|
|
|
|
|
|
Added processors:
|
|
|
|
-------------------
|
|
|
|
* src/cpu/power9
|
|
|
|
|
|
|
|
|
|
|
|
Submodule Updates
|
|
|
|
-----------------
|
|
|
|
/3rdparty/amd_blobs (6 commits)
|
|
|
|
/3rdparty/arm-trusted-firmware (965 commits)
|
|
|
|
/3rdparty/blobs (30 commits)
|
|
|
|
/3rdparty/chromeec (2212 commits)
|
|
|
|
/3rdparty/intel-microcode (1 commits)
|
|
|
|
/3rdparty/qc_blobs (13 commits)
|
|
|
|
/3rdparty/vboot (44 commits)
|
|
|
|
|
|
|
|
Deprecations and incompatible changes
|
|
|
|
-------------------------------------
|
2021-10-29 20:00:50 +02:00
|
|
|
|
|
|
|
Significant changes
|
|
|
|
-------------------
|
|
|
|
|
|
|
|
### Add significant changes here
|
2021-11-23 09:13:38 +01:00
|
|
|
|
|
|
|
### Option to disable Intel Management Engine
|
2022-02-24 01:08:27 +01:00
|
|
|
|
2021-12-15 10:12:37 +01:00
|
|
|
Disable the Intel (Converged Security) Management Engine ((CS)ME) via HECI based
|
|
|
|
on Intel Core processors from Skylake to Alder Lake. State is set based on a
|
|
|
|
CMOS value of `me_state`. A value of `0` will result in a (CS)ME state of `0`
|
|
|
|
(working) and value of `1` will result in a (CS)ME state of `3` (disabled). For
|
|
|
|
an example CMOS layout and more info, see
|
|
|
|
[cse.c](../../src/soc/intel/common/block/cse/cse.c).
|
2022-02-24 01:08:27 +01:00
|
|
|
|
|
|
|
### Add [AMD] apcb_v3_edit tool
|
|
|
|
|
|
|
|
apcb_v3_edit.py tool edits APCB V3 binaries. Specifically it will inject
|
|
|
|
up to 16 SPDs into an existing APCB. The APCB must have a magic number
|
|
|
|
at the top of each SPD slot.
|
|
|
|
|
|
|
|
|
|
|
|
### Allow enable/disable ME via CMOS
|
|
|
|
|
|
|
|
Add .enable method that will set the CSME state. The state is based on
|
|
|
|
the new CMOS option me_state, with values of 0 and 1. The method is very
|
|
|
|
stable when switching between different firmware platforms.
|
|
|
|
|
|
|
|
This method should not be used in combination with USE_ME_CLEANER.
|
|
|
|
|
|
|
|
State 1 will result in:
|
|
|
|
ME: Current Working State : 4
|
|
|
|
ME: Current Operation State : 1
|
|
|
|
ME: Current Operation Mode : 3
|
|
|
|
ME: Error Code : 2
|
|
|
|
|
|
|
|
State 0 will result in:
|
|
|
|
ME: Current Working State : 5
|
|
|
|
ME: Current Operation State : 1
|
|
|
|
ME: Current Operation Mode : 0
|
|
|
|
ME: Error Code : 0
|
|
|
|
|
|
|
|
### Move LAPIC configuration to MP init
|
|
|
|
|
|
|
|
Implementation for setup_lapic() did two things -- call
|
|
|
|
enable_lapic() and virtual_wire_mode_init().
|
|
|
|
|
|
|
|
In PARALLEL_MP case enable_lapic() was redundant as it
|
|
|
|
was already executed prior to initialize_cpu() call.
|
|
|
|
For the !PARALLEL_MP case enable_lapic() is added to
|
|
|
|
AP CPUs.
|
|
|
|
|
|
|
|
### Add ANSI escape sequences for highlighting
|
|
|
|
|
|
|
|
This patch adds ANSI escape sequences to highlight a log line based on
|
|
|
|
its loglevel to the output of "interactive" consoles that are meant to
|
|
|
|
be displayed on a terminal (e.g. UART). This should help make errors and
|
|
|
|
warnings stand out better among the usual spew of debug messages. For
|
|
|
|
users whose terminal or use case doesn't support these sequences for
|
|
|
|
some reason (or who simply don't like them), they can be disabled with a
|
|
|
|
Kconfig.
|
|
|
|
|
|
|
|
While ANSI escape sequences can be used to add color, minicom (the
|
|
|
|
presumably most common terminal emulator for UART endpoints?) doesn't
|
|
|
|
support color output unless explicitly enabled (via -c command line
|
|
|
|
flag), and other terminal emulators may have similar restrictions, so in
|
|
|
|
an effort to make this as widely useful by default as possible I have
|
|
|
|
chosen not to use color codes and implement this highlighting via
|
|
|
|
bolding, underlining and inverting alone (which seem to go through in
|
|
|
|
all cases). If desired, support for separate color highlighting could be
|
|
|
|
added via Kconfig later.
|
|
|
|
|
|
|
|
### Add cbmem_dump_console
|
|
|
|
|
|
|
|
This function is similar to cbmem_dump_console_to_uart except it uses
|
|
|
|
the normally configured consoles. A console_paused flag was added to
|
|
|
|
prevent the cbmem console from writing to itself.
|
|
|
|
|
|
|
|
### Add coreboot-configurator
|
|
|
|
|
|
|
|
A simple GUI to change settings in coreboot's CBFS, via the nvramtool utility.
|
|
|
|
|
|
|
|
### Update to NixOS 21.11
|
|
|
|
|
|
|
|
Update configs so that they work with NixOS 21.11. Drop `iasl` package
|
|
|
|
since it was replaced with `acpica-tools`.
|
|
|
|
|
|
|
|
### Move to v2021.10
|
|
|
|
|
|
|
|
Move to building the latest U-Boot.
|
|
|
|
|
|
|
|
### Support systems with >128 cores
|
|
|
|
|
|
|
|
Each time the spinlock is acquired a byte is decreased and then the
|
|
|
|
sign of the byte is checked. If there are more than 128 cores the sign
|
|
|
|
check will overflow. An easy fix is to increase the word size of the
|
|
|
|
spinlock acquiring and releasing.
|
|
|
|
|
|
|
|
### Add [samsung] sx9360 [proximity sensor] driver
|
|
|
|
Add driver for setting up Semtech sx9360 SAR sensor.
|
|
|
|
The driver is based on sx9310.c. The core of the driver is the same, but
|
|
|
|
the bindings are slightly different.
|
|
|
|
|
|
|
|
Registers are documented in the kernel tree:
|
|
|
|
Documentation/devicetree/bindings/iio/proximity/semtech,sx9360.yaml
|
|
|
|
[https://patchwork.kernel.org/project/linux-iio/patch/20211213024057.3824985-4-gwendal@chromium.org/]
|
|
|
|
|
|
|
|
### Add driver for Genesys Logic [SD Controller] GL9750
|
|
|
|
|
|
|
|
The device is a PCIe Gen1 to SD 3.0 card reader controller to be
|
|
|
|
used in the Chromebook. The datasheet name is GL9750S and the revision
|
|
|
|
is 01.
|
|
|
|
|
|
|
|
The patch disables ASPM L0s.
|
|
|
|
|
|
|
|
### Add support for Realtek RT8125
|
|
|
|
|
|
|
|
The Realtek RT8168 and RT8125 have a similar programming interface,
|
|
|
|
therefore add the PCI device ID for the RT8125 into driver for support.
|
|
|
|
|
|
|
|
### Add Fibocom 5G WWAN ACPI support
|
|
|
|
|
|
|
|
Support PXSX._RST and PXSX.MRST._RST for warm and cold reset.
|
|
|
|
PXSX._RST is invoked on driver removal.
|
|
|
|
|
|
|
|
build dependency:
|
|
|
|
soc/intel/common/block/pcie/rtd3
|
|
|
|
|
|
|
|
This driver will use the rtd3 methods for the same parent in the device
|
|
|
|
tree. The rtd3 chip needs to be added on the same root port in the
|
|
|
|
devicetree separately.
|
|
|
|
|
|
|
|
### Fix bug in vr_config
|
|
|
|
|
|
|
|
The `cpu_get_power_max()` function returns the TDP in milliwatts, but
|
|
|
|
the vr_config code interprets the value in watts. Divide the value by
|
|
|
|
1000 to fix this.
|
|
|
|
|
|
|
|
This also fixes an integer overflow when `cpu_get_power_max()` returns
|
|
|
|
a value greater than 65535 (UINT16_MAX).
|
|
|
|
|
|
|
|
### Make mixed topo work
|
|
|
|
|
|
|
|
When using a mixed memory topology with DDR4, it's not possible to boot
|
|
|
|
when no DIMMs are installed, even though memory-down is available. This
|
|
|
|
happens because the DIMM SPD length defaults to 256 when no DIMM SPD is
|
|
|
|
available. Relax the length check when no DIMMs are present to overcome
|
|
|
|
this problem.
|
|
|
|
|
|
|
|
### Add FSP 2.3 support
|
|
|
|
|
|
|
|
FSP 2.3 specification introduces following changes:
|
|
|
|
|
|
|
|
1. FSP_INFO_HEADER changes
|
|
|
|
Updated SpecVersion from 0x22 to 0x23
|
|
|
|
Updated HeaderRevision from 5 to 6
|
|
|
|
Added ExtendedImageRevision
|
|
|
|
FSP_INFO_HEADER length changed to 0x50
|
|
|
|
|
|
|
|
2. Added FSP_NON_VOLATILE_STORAGE_HOB2
|
|
|
|
|
|
|
|
Following changes are implemented in the patch to support FSP 2.3:
|
|
|
|
|
|
|
|
- Add Kconfig option
|
|
|
|
- Update FSP build binary version info based on ExtendedImageRevision
|
|
|
|
field in header
|
|
|
|
- New NV HOB related changes will be pushed as part of another patch
|
|
|
|
|
|
|
|
### Join hash calculation for verification and measurement
|
|
|
|
|
|
|
|
This patch moves the CBFS file measurement when CONFIG_TPM_MEASURED_BOOT
|
|
|
|
is enabled from the lookup step into the code where a file is actually
|
|
|
|
loaded or mapped from flash. This has the advantage that CBFS routines
|
|
|
|
which just look up a file to inspect its metadata (e.g. cbfs_get_size())
|
|
|
|
do not cause the file to be measured twice. It also removes the existing
|
|
|
|
inefficiency that files are loaded twice when measurement is enabled
|
|
|
|
(once to measure and then again when they are used). When CBFS
|
|
|
|
verification is enabled and uses the same hash algorithm as the TPM, we
|
|
|
|
are even able to only hash the file a single time and use the result for
|
|
|
|
both purposes.
|
|
|
|
|
|
|
|
### Skip FSP Notify APIs
|
|
|
|
|
|
|
|
Alder Lake SoC deselects Kconfigs as below:
|
|
|
|
- USE_FSP_NOTIFY_PHASE_READY_TO_BOOT
|
|
|
|
- USE_FSP_NOTIFY_PHASE_END_OF_FIRMWARE
|
|
|
|
to skip FSP notify APIs (Ready to boot and End of Firmware) and make
|
|
|
|
use of native coreboot driver to perform SoC recommended operations
|
|
|
|
prior booting to payload/OS.
|
|
|
|
|
|
|
|
Additionally, created a helper function `heci_finalize()` to keep HECI
|
|
|
|
related operations separated for easy guarding again config.
|
|
|
|
|
|
|
|
TODO: coreboot native implementation to skip FSP notify phase API (post
|
|
|
|
pci enumeration) is still WIP.
|
|
|
|
|
|
|
|
### Add support for PCIe Resizable BARs
|
|
|
|
|
|
|
|
Section 7.8.6 of the PCIe spec (rev 4) indicates that some devices can
|
|
|
|
indicates support for "Resizable BARs" via a PCIe extended capability.
|
|
|
|
|
|
|
|
When support this capability is indicated by the device, the size of
|
|
|
|
each BAR is determined in a different way than the normal "moving
|
|
|
|
bits" method. Instead, a pair of capability and control registers is
|
|
|
|
allocated in config space for each BAR, which can be used to both
|
|
|
|
indicate the different sizes the device is capable of supporting for
|
|
|
|
the BAR (powers-of-2 number of bits from 20 [1 MiB] to 63 [8 EiB]), and
|
|
|
|
to also inform the device of the size that the allocator actually
|
|
|
|
reserved for the MMIO range.
|
|
|
|
|
|
|
|
This patch adds a Kconfig for a mainboard to select if it knows that it
|
|
|
|
will have a device that requires this support during PCI enumeration.
|
|
|
|
If so, there is a corresponding Kconfig to indicate the maximum number
|
|
|
|
of bits of address space to hand out to devices this way (again, limited
|
|
|
|
by what devices can support and each individual system may want to
|
|
|
|
support, but just like above, this number can range from 20 to 63) If
|
|
|
|
the device can support more bits than this Kconfig, the resource request
|
|
|
|
is truncated to the number indicated by this Kconfig.
|