In newer ADL/RPL PCH EDS 619362 revision 2.1 the ESPI ID 0x7A8A
belongs to the W790 chipset. Earlier revisions had the chipset with
ID 0x7A8A named W685, which was probably just a temporary name.
Change the naming throughout the tree to W790, which is the real
existing chipset.
Change-Id: I87603298d655e9bf898b34acdd5b403f5affaee3
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76191
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
CPUID is the same for Alder Lake and Raptor Lake S and HX variants.
To reduce the confusion and concerns how to name the macros, remove
the suffixes from macros and platform reporting strings. Thankfully
the stepping names are unique across mobile (P suffixed) and desktop
(S and HX suffixed) SKUs. Distinguishing the S from HX is possible via
host bridge PCI ID.
Change-Id: Ib08fb0923481541dd6f358cf60da44d90bd75ae2
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76203
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Add PCI IDs, default VR values and power limits for Raptor Lake S
CPUs. Based on docs 639116 and 640555.
TEST=Tested on a MSI PRO Z690-A (ms7d25) with i9-13900K with Ubuntu
22.10 and LinuxBoot (Linux + u-root). Also tested on MSI PRO Z790-P
with i5-13600K (UEFI Payload) usign RPL-S IoT FSP and Ubuntu 22.04.
Change-Id: I767dd08a169a6af59188d9ecd73520b916f69155
Signed-off-by: Max Fritz <antischmock@googlemail.com>
Signed-off-by: Michał Żygowski <michal.zygowski@3mdeb.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69798
Reviewed-by: Tim Crawford <tcrawford@system76.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Michał Kopeć <michal.kopec@3mdeb.com>
Some of the microcode update files listed in the Makefile are redundant:
* 06-97-02 is exactly the same as 06-97-05
* 06-9a-03 is completely contained in 06-9a-04 (at offset 0x1c400)
So drop these files. This saves us about 200KiB CBFS space in each case.
Change-Id: Idfcab1de26ea4712295c1d22790bab3a73c17f93
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76381
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
This patch drops the unnecessary alignment of 64 bytes that was
introduced when implementing the split Intel microcode packing logic
into CBFS.
- The 16-byte alignment that is already used for Intel microcode is
sufficient.
- Removes unnecessary alignment check of 64 bytes against an AMD
platform specific config.
TEST=Able to build and boot google/rex without any functional
impact.
Change-Id: Icc44e9511e321592de7ab8d1346103d0a9951c9b
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76397
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
The commit 4d8da8ed ("Docs: Update sphinx targets with the build directory")
introduces an additional variable intending to allow an user to specify
a different build directory. Since the variable is not writable from the
outside and also the Docker container used to build doc.coreboot.org
calls the Makefile with `BUILDDIR` instead of `SPHINXDIR`, building the
documentation within the container doesn't work anymore.
Thus, change the variable name to `BUILDDIR` and make it writable.
Steps to reproduce:
cd util/docker
make doc.coreboot.org
make docker-build-docs
Change-Id: Ibc44134cf1996592597252aeb9dcf7ffb3378ee3
Signed-off-by: Felix Singer <felixsinger@posteo.net>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75893
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nicholas Chin <nic.c3.14@gmail.com>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
During the ACPI dump of the System Resource Affinity Table (SRAT), it
was noticed that the reserved field within the Memory Affinity structure
contained a non-zero value. This commit addresses the issue by
performing a memset to zero on the reserved field, ensuring the
avoidance of any potential problems arising from garbage values.
TEST= Build for ibm/sbp1 & make sure SRAT Memory Affinity entries
reserved fields read zeroes
Signed-off-by: Naresh Solanki <Naresh.Solanki@9elements.com>
Change-Id: I4ba697a6bd59054e74c84b98f3d9b517d333a5d8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75417
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Patrick Rudolph <siro@das-labor.org>
This configures GPIO IO Standby State of GPP_F00 - GPP_F05 as masked
for CNVi.
Meteor Lake rex platform does not wake up from low power state by
bluetooth keyboard and mouse properly. It is identified that IO Standby
State needs to be configured as masked to function properly for CNVi.
BUG=None
TEST=Make rex platform suspend to s0ix state and press a key from
bluetooth keyboard. Check the platform wakes up properly from s0ix.
Change-Id: Ia98abde584699fa01acba47a9df4ef6332ac16fd
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76338
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Reviewed-by: Sukumar Ghorai <sukumar.ghorai@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The actual NVM size of camera module is 64KB; however, only 8KB is in
use to store data. This reduces the size of both NVM0 and NVM1 to 8KB
to minimize the time taken to read NVM and launch Camera preview.
BUG=NONE
TEST=Launch Chrome camera application and check the time taken to
read eeprom from camera service log and show camera preview. It takes
2 to 3 seconds to show camera preview while it takes 4 to 5 seconds
without the changes.
Before the changes:
06:21:04.204944Z OpenDevice(): camera_id = 1
06:21:07.297584Z Read camera eeprom from eeprom
06:21:08.763491Z Read camera eeprom from nvmem
After the changes:
21:37:23.923676Z OpenDevice(): camera_id = 1
21:37:24.386020Z Read camera eeprom from eeprom
21:37:24.574515Z Read camera eeprom from nvmem
Change-Id: I0e2272b3307fea60ea7406fc6899ae2cb0134fa3
Signed-off-by: Jamie Ryu <jamie.m.ryu@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76189
Reviewed-by: Kiran2 Kumar <kiran2.kumar@intel.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
This patch skips reading the MEM_CH_SEL GPIO aka GPP_E13 to determine
the memory channel configuration. The signal behavior is not proper,
hence limiting the DIMM capacity to half (only MC0 is enabled).
This patch always reports the full memory capacity as in dual channel
(both MC0 and MC1 enabled).
This change is necessary to ensure that the system reports the correct
memory capacity, even if the MEM_CH_SEL GPIO is not working properly.
BUG=b:290174538
TEST=Able to detect 32GB memory capacity while booting google/ovis.
Without this patch:
localhost ~ # cat /proc/meminfo
MemTotal: 16183080 kB
With this patch:
localhost ~ # cat /proc/meminfo
MemTotal: 32673664 kB
Change-Id: I6c3fa941abb044b79b13785f7b65d09957f0487d
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76359
Reviewed-by: Sumeet R Pawnikar <sumeet.r.pawnikar@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Kapil Porwal <kapilporwal@google.com>
The AW37503 is designed to supply positive/negative supply for driving
the MIPI panel. It doesn't integrate non-volatile memory(EEPROM), so we
need to program the registers at boot. We program the target
positive/negative output voltage via I2C and enable the power rails by
pulling up ENP and ENN pins.
On Starmie, we need +/-6V power supply for the MIPI panel. We program
the AW37503 registers in coreboot so that kernel can control AW37503
via fixed regulators without additional settings(what we did for
TPS65132). Since we distinguish AW37503 and TPS65132 by reading the
vendor ID, we need to initialize I2C bus as early as possible.
Therefore, we move mtk_i2c_bus_init() to mainboard_init().
BUG=b:289482828
TEST=emerge-staryu coreboot chromeos-bootimage
TEST=Test the sequence the voltage
Change-Id: I9ccd4db19c93a032226f006eab0427f78f7b6dc8
Signed-off-by: Ruihai Zhou <zhouruihai@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76219
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: cong yang <yangcong5@huaqin.corp-partner.google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The BT VGPIOs pad config in variant of gpio.c won't be overwritten on board eventually because no matched gpios existed here.
Put BT VGPIOs in gpio_table, ensure that these were able to be overwritten.
The fix included crota and omnigul BT offload work successfully.
BUG=b:264834572
TEST=test Bluetooth offload playback/capture in SCO profile.
Change-Id: I62cecf26abd0411f7cbb0a56b8b8f0a25d370c69
Signed-off-by: Mac Chiang <mac.chiang@intel.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76247
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Derek Huang <derekhuang@google.com>
In VBOOT_STARTS_IN_ROMSTAGE=y case, vboot_run_logic() did not
get called when postcar was loaded from TSEG stage cache on
ACPI S3 resume path. Resume failed as MP init attempts to
access microcode update from unverified FW_MAIN_A/B section.
In a similar fashion, for POSTCAR=n, loading ramstage from
TSEG stage cache would bypass the call to vboot_run_logic().
TEST=samsung/lumpy with VBOOT_STARTS_IN_ROMSTAGE=y is able
to complete S3 resume.
Change-Id: I77fe86d5fd89d22b5ef6f43e65a85a4ccd3259d9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76209
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Julius Werner <jwerner@chromium.org>
This patch fixes the boot hang due to commit 053a45bcdb ("cpu/x86/lapic: Fix X2APIC_ONLY regression") on platform which selects X2APIC_LATE_WORKAROUND config.
[EMERG] Switching from X2APIC to XAPIC mode is not implemented.
Without this patch: Boot gets stuck inside at BS_WRITE_TABLES when enable_lapic() gets called after X2APIC mode has been enabled. The fix is to change enable_lapic() to track when late enablement for X2APIC mode happens with X2APIC_LATE_WORKAROUND.
TEST=Able to build and boot google/rex to chromeos.
Change-Id: I41e72380e9cfb59721d0df607ad875d7b6546974
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/76384
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The current design of the `ucode-<variant>.bin` file combines all
possible microcode per cpuid into a unified blob. This model increases
the microcode loading time from RW CBFS due to higher CBFS verification
time (the bigger the CBFS binary the longer the verification takes).
This patch creates a provision to pack individual microcodes (per CPUID)
into the CBFS (RO and RWs). Implementation logic introduces
CPU_INTEL_MICROCODE_CBFS_SPLIT_BINS config which relies on converting
Intel CPU microcode INC file into the binary file as per format
specified as in `cpu_microcode_$(CPUID).bin`.
For example: Intel CPU microcode `m506e3.inc` to convert into
`cpu_microcode_506e3.bin` binary file for coreboot to integrate if
CPU_INTEL_MICROCODE_CBFS_SPLIT_BINS config is enabled.
Another config named CPU_INTEL_UCODE_SPLIT_BINARIES is used to specify
the directory name (including path) that holds the split microcode
binary files per CPUID for each coreboot variants.
For example: if google/kunimitsu had built with Intel SkyLake processor
with CPUID `506e3` and `506e4` then CPU_INTEL_UCODE_SPLIT_BINARIES
refers to the directory path that holds the split microcode binary
files aka cpu_microcode_506e3.bin and cpu_microcode_506e4.bin.
Refer to the file representation below:
|---3rdparty
| |--- blobs
| | |--- mainboard
| | | |--- google
| | | | |--- kunimitsu
| | | | | |--- microcode_inputs
| | | | | | |--- kunimitsu
| | | | | | | |--- cpu_microcode_506e3.bin
| | | | | | | |--- cpu_microcode_506e4.bin
Users of this config option requires to manually place the microcode
binary files per CPUIDs as per the given format
(`cpu_microcode_$(CPUID).bin`) in a directory. Finally specify the
microcode binary directory path using CPU_UCODE_SPLIT_BINARIES config.
Additionally, modified the `find_cbfs_microcode()` logic to search
microcode from CBFS by CPUID. This change will improve the microcode
verification time from the CBFS, and will make it easier to update
individual microcodes.
BUG=b:242473942
TEST=emerge-rex sys-firmware/mtl-ucode-firmware-private
coreboot-private-files-baseboard-rex coreboot
Able to optimize ~10ms of boot time while loading microcode using
below configuration.
CONFIG_CPU_MICROCODE_CBFS_SPLIT_BINS=y
CONFIG_CPU_UCODE_SPLIT_BINARIES="3rdparty/blobs/mainboard/
$(CONFIG_MAINBOARD_DIR)/microcode_inputs"
Without this patch:
10:start of ramstage 1,005,139 (44)
971:loading FSP-S 1,026,619 (21,479)
> RO/RW-A/RW-B CBFS contains unified cpu_microcode_blob.bin
Name Offset Type Size Comp
...
cpu_microcode_blob.bin 0x1f740 microcode 273408 none
intel_fit 0x623c0 intel_fit 80 none
...
...
bootblock 0x3ee200 bootblock 32192 none
With this patch:
10:start of ramstage 997,495 (43)
971:loading FSP-S 1,010,148 (12,653)
> RO/RW-A/B CBFS that stores split microcode files per CPUID
FMAP REGION: FW_MAIN_A
Name Offset Type Size Comp
fallback/romstage 0x0 stage 127632 none
cpu_microcode_a06a1.bin 0x1f340 microcode 137216 none
cpu_microcode_a06a2.bin 0x40bc0 microcode 136192 none
...
...
ecrw 0x181280 raw 327680 none
fallback/payload 0x1d1300 simple elf 127443 none
At reset, able to load the correct microcode using FIT table (RO CBFS)
[NOTE ] coreboot-coreboot-unknown.9999.3ad3153 Sat May 20 12:29:19
UTC 2023 x86_32 bootblock starting (log level: 8)...
[DEBUG] CPU: Genuine Intel(R) 0000
[DEBUG] CPU: ID a06a1, MeteorLake A0, ucode: 00000016
Able to find `cpu_microcode_a06a1.bin` on google/rex with ES1 CPU
stepping (w/ CPUID 0xA06A1) (from RW CBFS)
localhost ~ # cbmem -c -1 | grep microcode
[DEBUG] microcode: sig=0xa06a1 pf=0x80 revision=0x16
[INFO ] CBFS: Found 'cpu_microcode_a06a1.bin' @0x407c0 size 0x21800 in
mcache @0x75c0d0e0
[INFO ] microcode: Update skipped, already up-to-date
Signed-off-by: Subrata Banik <subratabanik@google.com>
Change-Id: Ic7db73335ffa25399869cfb0d59129ee118f1012
Reviewed-on: https://review.coreboot.org/c/coreboot/+/75357
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Lean Sheng Tan <sheng.tan@9elements.com>
