Enable x86 SHA accelerator for use by VBOOT library. This is useful when
CBFS verification verifies the hash of the file being loaded in x86.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim. Observe a boot time improvement of
~10 ms with CBFS verification enabled.
Change-Id: I14efe7be66f28f348330580d2e5733e11603a023
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68954
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Currently build rules allow using x86 SHA extensions for all coreboot
stages when enabled. On some SoCs where verstage can run in non-x86
environment, x86 SHA extension cannot be used. Update build rules
accordingly such that x86 SHA extensions can be used in AMD SoCs. This
is particularly useful when CBFS verificiation is enabled which verifies
the hash of the CBFS file being loaded.
BUG=b:227809919
TEST=Build and boot to OS in Skyrim. Observe that hardware acceleration
is used when a CBFS file is loaded and observe an overall improvement of
10 ms.
Change-Id: I4f388e963eb82990cda41d3880e66ad937334908
Signed-off-by: Karthikeyan Ramasubramanian <kramasub@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68953
Reviewed-by: Raul Rangel <rrangel@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kangheui Won <khwon@chromium.org>
Reviewed-by: Yu-Ping Wu <yupingso@google.com>
RTD3,_ON method sometimes can create delays during system boot.
Even when the power is already up, kernel still tries to call _ON
method to power up device, but it's unnecessary.
RTD3._STA returns device power, so _ON method can check _STA and see
if the power on process can be skipped
BUG=b:249931687
TEST=system can boot to OS with RTD3 pcie storage and save ~80 ms on
Crota. Suspend stress test passes 100 cycles
Change-Id: I296ce1b85417a5dbaca558511cd7fc51a3a38c84
Signed-off-by: Kane Chen <kane.chen@intel.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69189
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Subrata Banik <subratabanik@google.com>
This contains the following commits:
* 835724d: mainboard/starlabs/starbook: Update the EC binaries
for StarLabs
* ecbe941: soc/mediatek: Update capitalization of coreboot
* 0e4444e: soc/mediatek/mt8188: Update MCUPM firmware from
v1.01.02 to v1.01.03
* 88570f6: mainboard/starlabs/starbook/adl: Update the EC binary
to 1.01 by Sean Rhodes
* f8e84db@ mainboard/starlabs/cezanne/starbook: Add EC binary
1.02 by Sean Rhodes
Signed-off-by: Sean Rhodes <sean@starlabs.systems>
Change-Id: I7afd43102718f211fe8d4fd69061dcdce5bfc323
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68587
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Now that coreboot performs the necessary power sequencing, switch
from using the 'probed' flag to 'detect' for all I2C touchscreens.
This alleviates ChromeOS from having to probe to see which
touchscreen model is actually present, prevents breaking ACPI spec
by generating device entries with status 'enabled and present'
which aren't actually present, and improves compatibility with
upstream Linux and Windows.
BUG=b:121309055
TEST=build/boot ChromeOS and Linux on guybrush, ensure touchscreen is
functional, and ACPI device entry generated for correct touchscreen
model.
This mirrors the changes made for skyrim in CB:67779.
Change-Id: Ib6a76b969d3a245eccde5352231eb7e36736f2e0
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69199
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
As all variants have a touchscreen option, in baseboard table set the
enable GPIO high and hold in reset during romstage, then release reset
in ramstage. This will allow the touchscreen to make use of the runtime
I2C detect feature (enabled in a subsequent commit) so that an ACPI
device entry is created only for the touchscreen actually present.
Variants/SKUs which do not have a touchscreen (if any) can use the
romstage/ramstage GPIO override tables to set the associated enable/
reset GPIOs to NC.
This mirrors the change to skyrim in CB:67778.
BUG=b:121309055
TEST=build/boot guybrush with rest of patch series
Change-Id: I9b3356b8b3a0e68a307838a4b18775d25b32e548
Signed-off-by: Matt DeVillier <matt.devillier@amd.corp-partner.google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69178
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Raul Rangel <rrangel@chromium.org>
The patch sets the EPP to 50% (0x80) for Vell. With EPP at 50%, the Vell
system demonstrated better power improvement without sacrificing the
performance.
PLT Results(Perf) with EPP@40% and EPP@50%:
EPP@40%: Device1-656 mins, Device2-664 mins.
EPP@50%: Device1-678 mins, Device2-677 mins.
In short, with EPP@50%, PLT KPI ran for more than 13 to 22mins compared
to EPP@40%.
Branch=firmware-brya-14505.B
BUG=b:215526166
TEST=Verified code build for Vell board
Signed-off-by: Sridhar Siricilla <sridhar.siricilla@intel.com>
Change-Id: I41b15b84025d25cf59dac2d85826a3de9d725bae
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68900
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subratabanik@google.com>
Only a subset of variants has proximity sensors.
This patch by itself does not introduce functional changes to any board.
It is mainly to ease migrating SX9324 from the legacy driver to the
linux one - allowing gradual migration variant by variant.
BUG=b:242662878
TEST=Dump ACPI SSDT then verify they are identical w/ and w/o this patch
Change-Id: Ic00e0d9eafcef2c9eaf32571fecf6190777cec36
Signed-off-by: Victor Ding <victording@google.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69191
Reviewed-by: Reka Norman <rekanorman@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The GPIO debounce timebase bit 4 is only 183uS on Picasso. On the other
SoCs it is 244uS. This affects the 1mS and 2mS actual debounce times
slightly.
Time PCO Others
1mS 0.915mS 1.220mS
2mS 2.013mS 2.684mS
Signed-off-by: Fred Reitberger <reitbergerfred@gmail.com>
Change-Id: Id84bef75e6ab134778721ca269d763a4bb2ddde5
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69209
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The fingerprint(FP) feature is only for volmar,and it's not for zavala.
Add FPMCU_MASK field in fw_config to disable the FP function for
zavala, and reserve FP function for shipped volmar.
Define the value as following:
field FPMCU_MASK 10
option FPMCU_ENABLED 0
option FPMCU_DISABLED 1
end
BUG=b:250807253
TEST=build firmware and verify the fp function in volmar DUT.
write `disable=1` and 'enable=0' in FPCMU_MASK field.
check the fp function and run `ectool --name cros_fp version`
It works as expected.
Signed-off-by: Ren Kuo <ren.kuo@quanta.corp-partner.google.com>
Change-Id: I867771904811459697056662d5e29c545a1a9474
Reviewed-on: https://review.coreboot.org/c/coreboot/+/68917
Reviewed-by: David Wu <david_wu@quanta.corp-partner.google.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Reviewed-by: Tarun Tuli <taruntuli@google.com>
Reviewed-by: Nick Vaccaro <nvaccaro@google.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
In function 'set_power_limits' there is a path to bail out early if the
Kconfig switch SOC_INTEL_DISABLE_POWER_LIMITS is selected. In this case
reading the MSR PLATFORM_INFO is useless and can be avoided. So read it
right before the value is needed.
This was found by the scanbuild.
In addition, fix an unnecessary line break to increase code readability.
Change-Id: Ibdededdfd56287fb9b9223e78033a3cd6425e1a2
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/c/coreboot/+/69185
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Marc Jones <marc@marcjonesconsulting.com>
Reviewed-by: Angel Pons <th3fanbus@gmail.com>
Reviewed-by: Eric Lai <eric_lai@quanta.corp-partner.google.com>
Exposing the GPIOs via an ACPI PowerResource and the _CRS results in the
OS driver and ACPI thinking they own the GPIO. This can cause timing
problems because it's not clear which system should be controlling the
GPIO. I'm making this an error because we should really clean these up.
BUG=b:210694108
TEST=Boot guybrush and see error:
> I2C: 02:5d: ERROR: Exposing GPIOs in Power Resource and _CRS
> \_SB.I2C1.H05D: Goodix Touchscreen at I2C: 02:5d
Signed-off-by: Raul E Rangel <rrangel@chromium.org>
Change-Id: Ifcc42ed81fff295fb168a0b343e96b3a650b1c84
Reviewed-on: https://review.coreboot.org/c/coreboot/+/60174
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Tim Van Patten <timvp@google.com>
