Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
The actual values in cstate_cfg_table haven't been checked against the
reference code yet.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I4f5743dd2e4dfdfeb3ffb2e9b964bdc75c84e6c3
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73502
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3669c66094f0137081888ebdd1af838e2ea269b5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73501
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id97fcb74ff3d48994a3181d9c31cbbeb5a76c60a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Rework the way the C state info is generated before it gets passed to
acpigen_write_CST_package in generate_cpu_entries by separating the data
from the code. For this, the newly introduced common get_cstate_info
function is used. Separating the data from the code will eventually
allow moving generate_cpu_entries to the common AMD code.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Id6bd8879ce5968b24893b43041be98db55a4c3c6
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73499
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Instead of using a magic constant in the bit_offset field of the C state
resource for the C1 state that's entered via the MWAIT instruction, use
the existing ACPI_FFIXEDHW_CLASS_MWAIT define. This value is checked by
acpi_processor_ffh_cstate_probe in the Linux kernel.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I9edc681efab15b5ceba91c8105f7dc6d687d8be8
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73498
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Introduce the get_cstate_info helper function that populates the caller-
provided cstate_values array with the data returned by the SoC-specific
get_cstate_config_data function. From the array get_cstate_config_data
returns, only the ctype, latency and power fields are used, so the rest
can be left uninitialized. Those 3 fields are compile-time constants.
For each entry, write_cstate_entry will generate the corresponding
resource information from the given data. In the C1 case where ctype is
1, the state is entered via a MWAIT instruction, while the higher C
states are entered by doing an IO read from a specific IO address. This
IO address is x - 1 bytes into the IO region starting at
MSR_CSTATE_ADDRESS for the Cx state. So for example C2 is entered by
reading from the C state IO base address + 1. This resource information
is generated during runtime, since the contents of MSR_CSTATE_ADDRESS
aren't necessarily known at compile-time.
MAX_CSTATE_COUNT is introduced so that the caller can allocate and pass
a buffer with space for the maximum number of C state entries. This
maximum number corresponds to the number of IO addresses the CPU traps
beginning from MSR_CSTATE_ADDRESS. In practice, it's unlikely that more
than 3 or maybe 4 C states will be available though.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c36c1d604ced349c609882b9d9fe84d5f726a8d
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73428
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
To deprecate VBOOT_VBNV_CMOS [1], replace VBOOT_VBNV_CMOS with
VBOOT_VBNV_FLASH for lenovo boards: t400, t410, t420, t420s, t430,
t430s, t520, t530, x131e, x1_carbon_gen1, x60, x200, x201, x220, x230. A
0x2000 RW_NVRAM region is allocated for them, with the COREBOOT size
reduced by 0x2000.
Also remove the VBOOT_VBNV_OFFSET config, since it's only used for
VBOOT_VBNV_CMOS.
[1] https://web.archive.org/web/20230115020833/https://issuetracker.google.com/issues/235293589?pli=1
BUG=b:235293589
TEST=./util/abuild/abuild -t LENOVO_T430S -a # with VBOOT enabled
Change-Id: I7e29db7eeceec499fbbcf902a26bfe9a2076de40
Signed-off-by: Yu-Ping Wu <yupingso@chromium.org>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/72809
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
EC_HOST_EVENT_GPU was renamed from
EC_HOST_EVENT_USB_CHARGER and thought to no longer
be used. It was subsequently removed in
I9e3e0e9b45385766343489ae2d8fc43fb0954923
Add back the mask for this event as it is infact
required on certain Brya (Agah) and Hades variants.
Signed-off-by: Tarun Tuli <taruntuli@google.com>
BUG=b:216485035,b:258126464,b:266631157
BRANCH=none
TEST=D-notifier events are received again from EC
Change-Id: I9d7bf52efa9572e1bbd2f307420e09a7398a1ca9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73217
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Caveh Jalali <caveh@chromium.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Add SODIMM support, drop the solderdown based on schematics.
BUG=b:271199379
TEST=abuild -a -x -c max -p none -t google/brya -b hades
Signed-off-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Change-Id: I85ec79c3d8f1147a875c4d04017bb50347121ebb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73389
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Raptor Lake i9 CPUs have 8P+16E cores for a total of 32 threads.
Change-Id: I26a729a585e7dc14f38c9092056eb0280726f053
Signed-off-by: Tim Crawford <tcrawford@system76.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73514
Reviewed-by: Subrata Banik <subratabanik@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In a recent coreboot leadership meeting, the decision was made to allow
(but not require) braces around single line statements if the author
wishes to put them in.
This patch removes the checks for single line statement blocks, while
still checking for other issues in braces.
Just because they're allowed now, please do not reformat the entire
codebase to add them. coreboot has a policy of not making widespread
changes to the entire codebase unless something actually violates the
style guidelines.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: I137b10889ec880959c4c1b035dc54bf8ebf32488
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73515
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The XHCI code does not currently contain a structure that corresponds
to the XHCI capability registers. These registers contain various
useful information about the controller. Create a`xhci_capability_regs`
struct to address this.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Change-Id: If38bfde726bd4e5dd314456f25a2b08acd3cd20c
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69915
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
When building libflashrom ontop of libpayload, meson calls the lpgcc
wrapper with -xc but without a file to obtain information about the C
compiler. To make this work guard $_LIBGCC with -xnone in the lpgcc
wrapper. -xnone tells the compiler to interpret the following files of
libpayload by their suffix, not the privious given -x option.
Change-Id: I9e037ff44c0a6d0585d8a6f8aeabae6e651142e2
Signed-off-by: Thomas Heijligen <src@posteo.de>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/70117
Reviewed-by: Julius Werner <jwerner@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Instead of having binaryPI generate a PSTATE SSDT that uses \_PR_ as the
scope for the CPU objects and patching this SSDT in coreboot to use the
\_SB_ scope in patch_ssdt_processor_scope, request binaryPI to use the
\_SB_ scope instead by setting the late platform configuration option
ProcessorScopeInSb to true.
TEST=Careena still boots and Linux doesn't show any ACPI errors with
this patch applied. With only patch_ssdt_processor_scope removed, but
the ProcessorScopeInSb option not set, Linux will complain that it can't
resolve the \PR.P00x symbols.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If88820a0f5df923f129e2e3b5335f5f0e38ee7f5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73385
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martin.roth@amd.corp-partner.google.com>
This patch updates the print msg of mrc_cache size from hex to
decimal for easier understanding while debugging the issue.
TEST=Able to build and boot google/rex.
Without this patch:
[SPEW ] MRC cache found, size ee75
With this patch:
[SPEW ] MRC cache found, size 61045 bytes
Change-Id: I69feeb36423e47a5992c9f27d9a7042803a492cd
Signed-off-by: Subrata Banik <subratabanik@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73490
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Ivy Jian <ivy.jian@quanta.corp-partner.google.com>
Reviewed-by: Dinesh Gehlot <digehlot@google.com>
It is necessary to increase the AVDD/AVEE of TPS65132s PMIC to +-5.7V
for powering on BOE_TV110C9M_LL0. So we set the default value to +-5.7V
and program the value to the EEPROM when configuring the display at the
first time. In this way, TPS65132s could load the correct setting from
the EEPROM after booting into kernel.
BUG=b:268292556
TEST=test firmware display pass and AVDD/AVEE is +-5.7V on Geralt.
Change-Id: I29236818444cac84d42386a371cd8934048ff948
Signed-off-by: yangcong <yangcong5@huaqin.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73443
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Move the sustained_power_limit_mW setting from the baseboard
to variants. This setting will be needed before STT is enabled,
but once STT is enabled, this setting should be removed.
BUG=b:265267957
BRANCH=none
TEST=Build/Boot to ChromeOS
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Change-Id: I7b9779600cfa8c7581732e936a714728fd618d20
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73426
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Fast VMode makes the SoC throttle when the current exceeds the I_TRIP
threshold.
BUG=b:270242461
BRANCH=firmware-brya-14505.B
TEST=Verify that the feature is enabled by reading from fsp log
Signed-off-by: Joey Peng <joey.peng@lcfc.corp-partner.google.com>
Change-Id: I82c2016d9dfb39ff7b372815737d4ae62875340c
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73373
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
To support an RPL SKU on taeko, taeko must use the FSP for RPL.
Select SOC_INTEL_RAPTORLAKE for taeko so that it will use the RPL
FSP headers for taeko.
BUG=b:270242461
BRANCH=firmware-brya-14505.B
TEST=cherry-pick Cq-Depends, then "emerge-brya intel-rplfsp
coreboot-private-files-baseboard-brya coreboot chromeos-bootimage",
flash and boot taeko to kernel.
Signed-off-by: Joey Peng <joey.peng@lcfc.corp-partner.google.com>
Cq-Depend: chrome-internal:5544049, chromium:4302529
Change-Id: Ic97400555dabb237325e7c4a8d5edcbb4779cdb1
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73371
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
This board is based off b75pro3-m, which is very similar. Compared to
it, it just lacks a COM1 header, and the secondary ASMedia SATA3
controller.
Tested with:
CPUs:
- Core i5-3330
- Core i5-3470
- Core i7-3770
RAM:
- single bank 4GB CL11
- two banks 4+4GB CL9
- two banks 8+8GB CL10
OS:
- Gentoo Linux LiveUSB, KDE desktop (Linux 5.15.72)
Working:
- GRUB2 payload with embedded default config for boot from USB, disk
- UEFI EDK2 payload
- Intel ME stripped
- Native raminit
- Integrated graphics with libgfxinit (HDMI, DVI and VGA)
- (boot from) SATA2, SATA3, ports
- Rear USB 2 and 3 ports (supports boot)
- Internal USB 3.0 ports
- Realtek GbE NIC
- 2.0 channel audio via lineout jack output
- ACPI (power button triggers OS event)
Untested:
- Internal USB 2.0 ports
- eSATA port
- 7.1 channel audio
Signed-off-by: Fabian Groffen <grobian@gentoo.org>
Change-Id: Ia6a6eb3e922920f4afbcb7828cd2b779b9caebcb
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73097
Reviewed-by: Kevin Keijzer
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
The legacy ACPI CPU control registers in IO space where the first 4 IO
locations control the CPU throttling value don't exist any more on the
Zen-based CPUs. Instead this IO address is written to MSR_CSTATE_ADDRESS
in set_cstate_io_addr which will cause accesses from the 8 IO addresses
beginning with ACPI_CSTATE_CONTROL to be trapped in the CPU core. Reads
from those IO addresses will cause the CPU to enter low C states.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I2c34e201cc0add1026edd7a97c70aa57f057782b
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73427
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Finally figured out why ACPI_GPE0_BLK only being 4 bytes after
ACPI_CPU_CONTROL won't work and its due to the CPU trapping 8 IO
addresses from ACPI_CPU_CONTROL on for C state control. This is set up
in set_cstate_io_addr by writing the ACPI_CPU_CONTROL value into
MSR_CSTATE_ADDRESS.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iedf53bbdae6ca65224601aad5cd1163df4b54131
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73423
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Picasso and newer don't implement the P_CNT register to control the CPU
duty cycle and also trap the C state control IO addresses directly in
the CPU, so those won't reach the FCH. This register is unused in the
Picasso code and not even defined any more in the Cezanne PPR. The
Picasso PPR does define this register, but since it's useless and might
even just be a leftover form a pre-Zen CPU generation, drop the define.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I3820db542c4714a100c7d36de673daa1a06e4a67
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73422
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the duty_offset and duty_width FADT field in
acpi_fill_fadt for all SoC except Stoneyridge.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Ib63b24891d44298841153dfc500b030619e1a5ea
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73421
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
Picasso neither has the corresponding P_CNT register implemented nor
writes a _PTC ACPI object that would specify the P_CNT register. The
Picasso UEFI reference code also sets the duty_width FADT entry to 0.
This also aligns the Picasso code with the Cezanne code in this regard.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: I74645e5c4e54a2ad6bc7f9e72f5f656027a79860
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73420
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the pstate_cnt FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: If3ddb466de1d437361d811e45e328a1dbff02fcc
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73419
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@mailbox.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The FADT data structure is zero-initialized in acpi_create_fadt which
then calls the SoC-specific acpi_fill_fadt function, therefore it's not
needed to assign 0 to the mon_alrm FADT field in acpi_fill_fadt.
Signed-off-by: Felix Held <felix-coreboot@felixheld.de>
Change-Id: Iabb5fc7367f1e4e7acea1a58abdb643fc46ca776
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73418
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Fred Reitberger <reitbergerfred@gmail.com>
The ASRock B75 Pro3-M port was lacking a cmos.default and cmos.layout,
which means nvramtool could not be used to change any nvram values, and
the defaults were always being used.
I have "borrowed" the files from the similar h77pro4-m port, which
work fine for the b75pro3-m. I can now adjust things like gfx_uma_size
and power_on_after_fail, which are quite useful to be able to modify.
Additionally, this board did not have a data.vbt, so I extracted
vbt.bin from the VGABIOS and added it.
Change-Id: I40822f2f7b013b7ac0658d66d7972b447066d593
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73451
Reviewed-by: Fabian Groffen <grobian@gentoo.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Felix Singer <felixsinger@posteo.net>
On the ASRock B75 Pro3-M, resuming from S3 has always been broken;
see commit 928c6c6336 (mainboard/asrock: add ASRock B75 Pro3-M).
This was because 3VSBSW# was not enabled during S3, causing the
board to reboot instead of resume. This change enables 3VSBSW#
during S3, which leads to S3 resume working normally.
Another issue with this board was that hardware monitoring was not
working. The nct6775 Linux kernel module could not be loaded, due to
the device having a base I/O port of 0. This change also enables the
Super I/O properly, so that sensors-detect can find the sensor and
the kernel module can be used.
Change-Id: I6e504fe4b60da1d7b9830bea5029101bb8cebcb5
Signed-off-by: Kevin Keijzer <kevin@quietlife.nl>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73450
Reviewed-by: Fabian Groffen <grobian@gentoo.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Skyrim does not have a cardbus socket, so disable it.
Maybe cardbus support shouldn't be enabled by default?
BUG=None
TEST="PC Card (PCMCIA) is supported" no longer shows up
in dmidecode output.
Signed-off-by: Martin Roth <gaumless@gmail.com>
Change-Id: Ic941b075e8b5082b5e61e728a77fd79c0ebba35e
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73167
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Jason Glenesk <jason.glenesk@amd.corp-partner.google.com>
Reviewed-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Only Frostflow supports the stylus, so remove the gpio-keys ACPI node
from Skyrim.
The Kconfig value DRIVERS_GENERIC_GPIO_KEYS is still enabled for all
Skyrim variants, since coreboot will drop the driver from the BIOS image
if there are no references to it (in the devicetree). If some other
design ends up using the stylus in the future we won't have to bring it
back.
BUG: none
TEST: build_packages --board=skyrim chromeos-bootimage --autosetgov
Change-Id: I9ffe215741b72b678d74405769f35167d8ded4b5
Signed-off-by: Tim Van Patten <timvp@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73299
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin L Roth <gaumless@gmail.com>
Add a config "USE_NAU8318" to enable NAU8318 support.
NAU8318 is another speaker used in Geralt. NAU8318 supports beep
function via GPIO control. So we configure the GPIO pins and pass them
to the payload.
BUG=b:250459803
BRANCH=none
TEST=Verify beep function through CLI in depthcharge successfully.
Change-Id: I21009a20809f398de4628ff0c11bcbd0e7591443
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73413
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Add a config "USE_MAX98390" to enable MAX98390 support.
MAX98390 is an I2S smart amplifier used in Geralt. It is also the
default speaker for Geralt reference board.
BUG=b:250459803
BRANCH=none
TEST=Verify beep function through CLI in depthcharge successfully.
Change-Id: I814f440cc5ac2a13404d01fb3baafeec092b1e74
Signed-off-by: Trevor Wu <trevor.wu@mediatek.com>
Signed-off-by: jason-ch chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73412
Reviewed-by: Yidi Lin <yidilin@google.com>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Enable bus protection for display to avoid bus hang and incomplete bus
transaction.
BUG=b:264204465
TEST=test firmware and kernel display pass for MIPI panel on geralt.
Change-Id: Iac61a69f2b84966dd468442daaa59d83eec775aa
Signed-off-by: Liju-Clr Chen <liju-clr.chen@mediatek.com>
Signed-off-by: jason-ch chen <Jason-ch.Chen@mediatek.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73411
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Bus protection is a HW mechanism to avoid bus hang and incomplete bus
transactions. Bus protection HW must be enabled while the receiver of
the transaction is not able to respond.
BUG=b:264204465
TEST=build pass
Change-Id: I14aa63c4934073a14552cef64f40657d0197bbe1
Signed-off-by: garmin chang <garmin.chang@mediatek.corp-partner.google.com>
Signed-off-by: jason-ch chen <jason-ch.chen@mediatek.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73375
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Rex-BC Chen <rex-bc.chen@mediatek.com>
Reviewed-by: Yidi Lin <yidilin@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The XHCI device functions currently use functions that require a
access to the device tree. Create variant of these functions that can
operate with a resource* as an argument and refactor the existing
device*-based functions to operate by calling the resource*-based
variants. This is useful for stages like SMM that may not have access to
the device tree.
BRANCH=guybrush
BUG=b:186792595
TEST=Ran on skyrim device, verified that XHCI ACPI tables are still
generated correctly.
Change-Id: If5a74f9529d5dc6031ec968ef5f40a9cad5ffbc4
Signed-off-by: Robert Zieba <robertzieba@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69914
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
In certain cases data within protected memmory areas like SMRAM could
be leaked or modified if an attacker remaps PCI BARs to point within
that area. Add support to the existing SMM runtime to allow storing
PCI resources in SMRAM and then later retrieving them.
BRANCH=guybrush
BUG=b:186792595
TEST=builds
Signed-off-by: Robert Zieba <robertzieba@google.com>
Change-Id: I23fb1e935dd1b89f1cc5c834cc2025f0fe5fda37
Reviewed-on: https://review.coreboot.org/c/coreboot/+/67931
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
Remove the last slash '/' from directories in excludelist, so that they
will be correctly filtered by grep.
Fixes:
grep: util/goswid: Is a directory
grep: util/nvidia/cbootimage: Is a directory
Signed-off-by: Maximilian Brune <maximilian.brune@9elements.com>
Change-Id: I90cc2cff9a98bbd0af344156332b970bfd6430b9
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73396
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Elyes Haouas <ehaouas@noos.fr>
Because SPD tool now supports 8533Mbps, so modify speed to regenerate
the SPD file for Hynix H58G66BK8BX067 and H58G56BK8BX068.
BUG=b:263189532, b:270629852
TEST=util/spd_tools/bin/spd_gen spd/lp5/memory_parts.json lp5
Change-Id: I813fc1495836dbe33de426cf41a1f58c8e8a046e
Signed-off-by: John Su <john_su@compal.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73251
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Dtrain Hsu <dtrain_hsu@compal.corp-partner.google.com>
Reviewed-by: Ian Feng <ian_feng@compal.corp-partner.google.com>
Reviewed-by: Chao Gui <chaogui@google.com>
Reviewed-by: Karthik Ramasubramanian <kramasub@google.com>
According to thermal_table_0215, adjust DPTC and STT settings.
BRANCH=none
BUG=b:257149501
TEST=emerge-skyrim coreboot chromeos-bootimage
Then the thermal team has verified.
Signed-off-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
Change-Id: Id7df3f9bfa3f0e1337c502bc7db9e09e12cd956a
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73081
Reviewed-by: Tim Van Patten <timvp@google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: John Su <john_su@compal.corp-partner.google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Add stt settings for dptc tablet mode.
BUG=b:257149501
BRANCH=None
TEST=Check if the STT value matches the clamshell/tablet mode.
Run the WebGL aquarium with 5000 fish and verify that there is
no power drop peak.
Change-Id: Ib4aad3af8761b20084717b15a462edf4704b83cc
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73205
Reviewed-by: Tim Van Patten <timvp@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Frank Wu <frank_wu@compal.corp-partner.google.com>
The SPL parameter for DPTC settings is not available for STT-enabled
platforms. It needs to be removed to avoid confusing STT calculations.
BUG=b:265267957
BRANCH=none
TEST=Run the WebGL aquarium with 5000 fish and verify that
there are no power drop peaks.
Change-Id: I8e6dad7d24883f8aadce83ebac401ecd4137d61a
Signed-off-by: Chris Wang <chris.wang@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/73124
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
Felix Held