Drop the __weak qualifier as this function is not overridden.
BUG=b:260565911
BRANCH=firmware-brya-14505.B
TEST=emerge-brya coreboot chromeos-bootimage
Signed-off-by: Frank Chu <Frank_Chu@pegatron.corp-partner.google.com>
Change-Id: Ica25b2bc4325ff9d27be672926b4e3b550c86e96
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70235
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Frank Chu <frank_chu@pegatron.corp-partner.google.com>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Add Memory Error Section definitions from UEFI Specification rev 2.10
appendix N.2.5. The structure defined here may be used for machine
check handling.
Signed-off-by: Tim Chu <Tim.Chu@quantatw.com>
Change-Id: I0a165350a16a4cbe4033a3e7c43fa23a5b27c44b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69198
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
The original version of the mem_chip_info structure does not record rank
information and does not allow precise modeling of certain DDR
configurations, so it falls short on its purpose to compile all
available memory information. This patch updates the format to a new
layout that remedies these issues. Since the structure was introduced so
recently that no firmware using it has been finalized and shipped yet,
we should be able to get away with this without accounting for backwards
compatibility.
BRANCH=corsola
Cq-Depend: chromium:3980175
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: If34e6857439b6f6ab225344e5b4dd0ff11d8d42a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68871
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Xixi Chen <xixi.chen@mediatek.corp-partner.google.com>
Replace the amdblocks/gpio.h, amdblocks/gpio_defs.h and soc/gpio.h
includes with the common gpio.h which will include soc/gpio.h which will
include amdblocks/gpio.h which will include amdblocks/gpio_defs.h in the
AMD SoC case.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I37a33dd8821a00b7edfd1e5b593f71bea0e77630
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70434
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Replace the amdblocks/gpio.h, amdblocks/gpio_defs.h and soc/gpio.h
includes with the common gpio.h which will include soc/gpio.h which will
include amdblocks/gpio.h which will include amdblocks/gpio_defs.h in the
AMD SoC case.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I13bc33b91f6e6d52867da9043bb386f3befac5fb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70433
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The size of a pointer changes between a 32 and 64 bit coreboot build. In
order to be able to use a 32 bit FSP in a 64 bit coreboot build, change
the pointer in the UPDs to a uint32_t to always have a 32 bit field in
the UPD for this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I81f3a38344f91cecb4fe5431ed211834e5ed599c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69897
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The size of a pointer changes between a 32 and 64 bit coreboot build. In
order to be able to use a 32 bit FSP in a 64 bit coreboot build, change
the pointer in the UPDs to a uint32_t to always have a 32 bit field in
the UPD for this.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I419fef73d2881e323487bc7fe641b2ac4041cb17
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70135
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
DTTS indicated Dynamic Thermal Table Switching.The proposal would like
to develop the schematic for switching 6 thermal table by lid status,
machine body mode and temperature. After entering the OS, the thermal
table would be table A. If the “Motion” or “Lid status change” is
detected. The thermal table would switch to laptop mode or lid close
mode.
Once the higher environment temperatures are detected,the thermal
table would switch to the corresponding power throttle table (B, D or
F). Based on these table switching mechanisms, no matter how the
end-user uses Chromebook,they could enjoy more humanized thermal
designs.
Release Over Over Release .
Temp. Temp. Temp. Temp. .
-------------------------------------------------------- .
Desktop mode Table A Table B 50C 45C .
Lid open (Default) .
-------------------------------------------------------- .
Desktop mode Table C Table D 55C 50C .
Lid close .
-------------------------------------------------------- .
Laptop mode Table E Table F 45C 40C .
-------------------------------------------------------- .
On the proposal, the transmission rules are list below:
1. Table A is the default table after booting.
2. A, C, E (Release Temp) can switch to each other.
3. B, D, F (Over Temp) can switch to each other.
4. A and B, C and D, E and F can switch to each other.
5. If Lid open/close or mode switch event trigger, temperature release
tables will translation to each other, temperature over tables will
translation to each other.After that event trigger, EC will check the
new temperature condition and decide if the temperature need to be
trigger.For example, if table A will switch to table D, table A will
switch to C with Lid close event, if temperature is over 55C, EC will
trigger temperature to switch form table C to D.
6. EC will trigger 3 times body-detection events during power on boot
without any body-mode and lid status change. For this case if the
previous table label is on same group, we will based on the temperature
to decide the table.
For example, assume table A is current table. When the temperature
reaches 50C, than the table is switched from A to B. The current table
is B. When the temperature is downgrade below 45C, the table is
switched form B to A. The same rule is for C and D, E and F.
BRANCH=none
BUG=b:232946420
TEST=emerge-skyrim coreboot
Signed-off-by: EricKY Cheng <ericky_cheng@compal.corp-partner.google.com>
Change-Id: I866e5e497e2936984e713029b5f0b6d54cbc9622
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68471
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Include <amdblocks/gpio_defs.h> instead of "gpio_defs.h", since
gpio_defs.h is not only visible in a local scope, but also as
<amdblocks/gpio_defs.h>.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iab3e5bb235a5b1bc995b6cf8710f0d8c1886142d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70432
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This avoids the need to hardcode the IOAPIC ID.
Change-Id: I0965b511e71c58f1c31433bc54595a5fabb1c206
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70268
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Sean Rhodes <sean@starlabs.systems>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Some of these macros are too generic like "NONE" and create conflicts in
other compilation units.
Change-Id: I6131a576f115df20df4d3df712d4c3f59c6dceb7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70429
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
LARS has two variants, LARS and LILI, which are differentiated via
the customization_id field in the VPD. To make differentiation easier
outside of ChromeOS (ie, for Windows/Linux drivers), set the SKU ID
based on VPD so it can be easily read via SMBIOS.
Modeled after similar code in google/reef (snappy variant).
TEST=build/boot lili variant, verify sku1 populated in SMBIOS tables.
Change-Id: I148462b6f86b25fa8db26ea6e1537d1a5e47984b
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68754
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
There are four requirements for the SMI to hit a printk()
this commit now removes.
Build must have DEBUG_SMI=y, otherwise any printk() is a no-op
inside SMM.
ASL must have a TRAP() with argument 0x99 or 0x32 for SMIF value.
Platform needs to have IO Trap #3 enabled at IO 0x800.
The SMI monitor must call io_trap_handler for IO Trap #3.
At the moment, only getac/p470 would meet the above criteria
with TRAP(0x32) in its DSDT _INI method. The ASL ignores any
return value of TRAP() calls made.
A mainboard IO trap handler should have precedence over
a southbridge IO trap handler. At the moment we seem to have
no cases of the latter to support, so remove the latter.
Change-Id: I3a3298c8d9814db8464fbf7444c6e0e6ac6ac008
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70365
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
Avoid calling a function named mainboard_io_trap_handler() when
the dock (dis)connect is not triggered from IO trap.
Change-Id: Idc258a390f2de2c32d38a0e35fcce896d058d1b9
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70363
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Arthur Heymans <arthur@aheymans.xyz>
CONFIG_VBOOT_CBFS_INTEGRATION images are signed differently than normal
images. futility needs to be able to tell this difference, and it parses
the `config` file included in CBFS to do this. This change codifies that
dependency in Kconfig so that nobody can accidentally break this by
turning off config file inclusion.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I2b2d245b850bc65abb4e72f20b4e360312c828f7
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70157
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The intention of CB:69710 was that the expanded config file introduced
there would be a strict superset of the old version and could be used in
all the same cases. This is generally true except for a small oversight:
if a boolean Kconfig is `default y`, but was manually set to `n` by the
user, the new `config` file does not include a line for it. Running
`make olddefconfig` on such a file will again introduce the option as
`y`. It turns out that `make olddefconfig` actually parses those
"load-bearing comments" in that case.
This patch fixes the problem by also generating the minimal defconfig
(like before CB:69710), and then just appending the non-comment lines
from the full config that don't appear in it already. This ensures that
any "load-bearing comments" in the defconfig remain in the file and the
result of Kconfig utilities regenerating a full config from there will
again be the same as before CB:69710. In addition, it clearly separates
the "minimal defconfig" part of the file from the rest, making it easy
for people to extract that if they need it; while also keeping all the
config values in one file to make it easy to grep for a certain value.
Also eliminate that random backslash in the recipe that doesn't seem to
have any good reason to exist and was probably a typo to begin with.
Signed-off-by: Julius Werner <jwerner@chromium.org>
Change-Id: I52ba5d20d3536498fae79d529acf7135f97ef1a8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69955
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jakub Czapiga <jacz@semihalf.com>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
At the moment IO trap is not implemented for AMD platforms.
Change-Id: Ib62ac4e4e418a8bab80c30dfb5183ecd8beb998d
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70360
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Properly handle meminfo DIMMs with `dimm_size` of 0, which represent
empty slots. This allows platform code to create dummy meminfo DIMMs
so that SMBIOS tables have type 17 entries for empty DIMM slots.
Change-Id: I17ae83edf94483bd2eeef5524ff82721c196b8ba
Signed-off-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/64035
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently the MRC cache is updated in romstage, immediately after
returning from FSP-M. Since cbmem is not cached in romstage, the update
is slow (~6 ms on nissa). Specifically, the new MRC data returned by the
FSP is stored in the FSP reserved memory in cbmem, so hashing the new
data is slow.
Move the MRC cache update to ramstage, where cbmem is cached. On nissa,
this saves ~5 ms of boot time.
Before:
552:finished loading ChromeOS VPD (RW) 631,667 (16)
3:after RAM initialization 637,703 (6,036)
4:end of romstage 650,307 (12,603)
After:
552:finished loading ChromeOS VPD (RW) 631,832 (15)
3:after RAM initialization 633,002 (1,169)
4:end of romstage 645,582 (12,580)
In ramstage, save_mrc_data() takes ~138 us.
BUG=b:242667207
TEST=MRC caching still works as expected on nivviks - after clearing the
MRC cache, memory is retrained on the next boot, but cached data is used
on subsequent boots.
Change-Id: Ie6aa2dee83a3ab8913830746593935d36a034b8d
Signed-off-by: Reka Norman <rekanorman@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67669
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Julius Werner <jwerner@chromium.org>
Two GPIOs were set as SCI, but are not GEvent capable pins on morgana.
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: I00dc1b2595c047ce6898b394061d119ac8680755
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70282
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Modify the configuration of GPIO_74 (PMIC Thermal Trip Point) as
in it's current configuration, it stops the laptop entering S5.
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I0e31f095ff42a03e3ea1496fe67d69b0f1763a3c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67418
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
This reads back the ioapic id from hardware.
Change-Id: I214557bbe963d1086f35f96efb1cb47950099eb3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70267
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This is more robust than hardcoding whathever FSP has set up and is a
lot less code.
Change-Id: I6423ddc139d742879d791b054ea082768749c0a7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70265
Reviewed-by: Jonathan Zhang <jonzhang@fb.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Subrata Banik