The datasheets "Intel® Core™ Duo Processor and Intel® Core™ Solo
Processor on 65 nm Process" mentions cpu C-states substates which can
either be attained by adding a substate hint to the MWAIT/P_LVLx request
or automatically by setting some msr bits correctly.
This just sets the same msr bits as model_6fx to enable
dynamic L2 cache, C2E and C4E acpi cpu states.
The result is that when limiting a thinkpad x60 with a yonah T2400
cpu to the acpi cpu C2 state, the idle power usage drops from 18W to
14W. When the lowest C-state is set to C4 the idle power usage seems
to remain similar.
Change-Id: I6c422656ace04659f32082a5944617eda6c79ec3
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/16901
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
max_regions is set to the maximal regions based on the ifd version
Change-Id: I9fa5a4565f4dbd67b5c6df97756311560e2a18bc
Signed-off-by: Alexander Couzens <lynxis@fe80.eu>
Reviewed-on: https://review.coreboot.org/16934
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
When timestamp is enabled, the system hangs because the timestamp data
is not yet available. Add a temporary work around that starts the
timestamp after the FspInit() making this data available.
Verified on Intel Camelback Mountain CRB and ensured that system can
boot to payload with timpstamp feature enabled.
Change-Id: I59c4bb83ae7e166cceca34988d5a392e5a831afa
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: https://review.coreboot.org/16894
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
The enforced FSP 1.0 APIs call was used to work around an fsp1.0 driver
issue. As the issue has been addressed in fsp1.0 driver (Change 9780),
remove the enforced workaround. Otherwise will see error message
'FSP API NotifyPhase failed' in serial log.
Verified on Intel Camelback Mountain CRB and confirmed that the serial
log error message regarding the 'FSP API NotifyPhase failed' is gone.
Change-Id: Iafa1d22e2476769fd841a3ebaa1ab4f9713c6c39
Signed-off-by: York Yang <york.yang@intel.com>
Reviewed-on: https://review.coreboot.org/16892
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
When compiling a non-x86 platform with DRIVERS_INTEL_WIFI enabled,
we get the build error:
src/drivers/intel/wifi/wifi.c:17:30: fatal error:
arch/acpi_device.h: No such file or directory
acpi_device.h only exists in the x86 architecture directory.
Change-Id: Id0e29558336bf44e638cfcb97c22f31683ea4ec7
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16906
Tested-by: build bot (Jenkins)
Reviewed-by: Antonello Dettori <dev@dettori.io>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Some PVT units encountered DRAM calibration failure during
power on/off tests. The failure is caused by higher impedance
of the DRAM on those units. So increase the driving strength
for 4GB DRAMs.
BUG=chrome-os-partner:57392
TEST=run cold reboot 100 times on PVT units which have DRAM
calibration issue.
Change-Id: I8a329093db3f1def566e4b7afec3c4f4bfe44c6a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: cf1aa5ade856af433fa056f51a20d18553ae241d
Original-Change-Id: I0d1776cd1a5892d1f82e9bf414620d1ef6d29132
Original-Signed-off-by: PH Hsu <ph.hsu@mediatek.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/394451
Original-Commit-Ready: Yidi Lin <yidi.lin@mediatek.com>
Original-Tested-by: Yidi Lin <yidi.lin@mediatek.com>
Original-Reviewed-by: Pin-Huan Hsu <ph.hsu@mediatek.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/16917
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We found that Kevin board PHY0 and PHY1 eye-diagram margin
is not enough to make compliance test pass, and the PHY0 USB
SI is worse than PHY1, because of the higher PCB impedance.
For PHY0, we can't improve the eye-diagram by SW PHY tuning,
so we need to reduce the RBIAS resistance from 133 ohm to 115
ohm, it can help to increase the eye-height.
For PHY1, we can improve the eye-diagram by setting the max
pre-emphasis level.
And after the above change, the USB2 signal amplitude will
become larger at the test point near to SOC USB2 PHY, in order
to avoid mis-trigger the disconnect detection (650mV), we need
to disable pre-emphasize in eop state.
BRANCH=None
BUG=chrome-os-partner:53863
TEST=do USB 2.0 compliance test for Kevin C0 and C1 port.
Change-Id: I95c0acd79623aeca9a0ae077b1dd3836d91fe561
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: de3cdef128966d76e7d8e2ebd641763b911c3ad5
Original-Change-Id: I00cb325b9938e4276cc77b5d6f5faa7023379608
Original-Signed-off-by: William wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/390615
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16911
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Though we don't use Type-C PHY to support USB3 in firmware,
we still need to initialize the Type-C PHY, and make sure
the power state of pipe is always fixed to U2/P2. After
this, we can force USB3 controller to work in USB2 only
mode.
BRANCH=none
BUG=chrome-os-partner:56425
TEST=Go to recovery mode, plug a Type-C USB drive containing
chrome OS image into both ports in all orientations, check if
system can boot from USB.
Change-Id: I95bb96ff27d4fecafb7b2b9e9dc2839b5c132654
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8ec98507845276119d8a9d5626934dedcb35f2dd
Original-Change-Id: Ie3654cd1c1cb76b62aa9b247879b60cbecee0155
Original-Signed-off-by: William wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/391412
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16910
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
We do this so that the riscv objdump can be used on the coreboot.elf file.
Change-Id: Ib8bf85a3299dd75b779e7fa3757f5b62c9c7170b
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/16918
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
Converged Security Engine (CSE) has a secure variable storage feature.
However, this storage is expected to be reset during S3 resume flow.
Since coreboot does not use secure storage feature, disable HECI2 reset
request. This saves appr. 130ms of resume time.
BUG=chrome-os-partner:56941
BRANCH=none
TEST=powerd_dbus_suspend; resume; check time with cbmem -t. Note
FspMemoryInit time is not significantly different from normal boot
time case.
Change-Id: I485a980369c6bd97c43b9e554d65ee89e84d8233
Signed-off-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-on: https://review.coreboot.org/16870
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These header files contain a few new UPDs. The EnableS3Heci2
UPD will be used to save ~100ms from the S3 resume time on
Apollolake chrome platforms.
BUG=chrome-os-partner:58121
BRANCH=none
TEST=built coreboot for reef and verified no regressions
Change-Id: I1f324d00237c7150697800258a2f7b7eed856417
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16869
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
commit 028200f7 - x86/acpi_device: Add support for GPIO output polarity
updated ACPI_GPIO_OUTPUT to ACPI_GPIO_OUTPUT_ACTIVE_HIGH for the other
boards that needed it, but pyro wasn't in the tree when it was initially
pushed. Now that pyro is in the tree, it needs to be updated as well.
Change-Id: I617999b06ee584e0543d7ae3232bb2be2ff7429c
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16930
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Between GNU Tar 1.28 & 1.29, the files excluded by --exclude-vcs was
updated. This breaks the reproducibility. Instead, just manually
exclude the files to match what was excluded in v 1.28 and earlier.
Change-Id: Ie0717891506f4a6d750ff264f9cc2494a296265b
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16900
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
- Add more help text.
- Remove braces from variables where the variable is isolated.
- Remove --recurse-submodules from clone. This breaks on old coreboot
versions.
- Add some whitespace between blocks.
- Fix all shellcheck warnings.
- Verify tar version and fail if it doesn't support --sort.
Change-Id: I4a49df99532d9a92a4a05bceff16f96a4fc3e205
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16883
Tested-by: build bot (Jenkins)
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch enables stage cache to save ~40ms during S3 resume.
It saves ramstage in the stage cache and restores it on resume
so that ramstage does not have to reinitialize during the
resume flow. Stage cache functionality is added to postcar stage
since ramstage is called from postcar.
BUG=chrome-os-partner:56941
BRANCH=none
TEST=built for Reef and tested ramstage being cached
Change-Id: I1551fd0faca536bd8c8656f0a8ec7f900aae1f72
Signed-off-by: Brandon Breitenstein <brandon.breitenstein@intel.com>
Reviewed-on: https://review.coreboot.org/16833
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Instead of hard-coding the polarity of the GPIO to active high/low,
accept it as a parameter in devicetree. This polarity can then be used
while calling into acpi_dp_add_gpio to determine the active low status
correctly.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that correct polarity is set for reset-gpio on reef.
Change-Id: I4aba4bb8bd61799962deaaa11307c0c5be112919
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16877
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Only acpi_dp of type DP_TYPE_TABLE is allowed to be an array. This
DP_TYPE_TABLE does not have a value which is written. Thus,
acpi_dp_write_array needs to start counting from the next element type
in the array. Fix this by updating the initialization in for loop for
writing array elements.
BUG=chrome-os-partner:55988
BRANCH=None
TEST=Verified that the correct number of elements are passed for
add_gpio in maxim sdmode-gpio.
Change-Id: I8e1e540d66086971de2edf0bb83494d3b1dbd176
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/16871
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Some Chrome OS ECs require a small amount of time after a SPI
transaction to reset their controllers before they can service the next
CS assertion. The kernel and depthcharge have always enforced a 200us
minimum delay for this... coreboot should've done the same.
BRANCH=gru
BUG=chrome-os-partner:58046
TEST=Booted Kevin in recovery mode, confirmed that recovery events got
logged with correct timestamps in eventlog.
Change-Id: I32ec343f3293ac93729d3e6e2f43d7605a396cdb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b9e4696533d4318ae7c8715b71ab963d8897c16c
Original-Change-Id: I6a7baf7859d5d50e299495d118e7890dcaa2c1b0
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/392206
Original-Tested-by: Shawn N <shawnn@chromium.org>
Original-Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-on: https://review.coreboot.org/16885
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
GPIO1_B3 (WLAN_MODULE_RST#) defaults as a pull-up input, but it is also
"pulled up" by 1.8V_WLAN. However, 1.8V_WLAN remains low for some time
during early boot. This leaves the signal floating somewhere in the
middle.
This has two potential issues:
(1) we're leaking some power for some (hopefully) short period of time
(2) we are possibly screwing with the Wifi power sequence; we aren't
supposed to deassert PDn (i.e., MODULE_RST#) until all the rails
have fully ramped for some period of time
Neither of the above issues are likely to be significant, but it is nice
to fix, I expect.
BRANCH=gru
BUG=chrome-os-partner:54026
TEST=measure WLAN_MODULE_RST# on scope at boot time
Change-Id: Ia6af9ad6954ad8feeda33015e3f205842380939e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0e890a2787bf034d3358a33fc88c2dd8078593ab
Original-Change-Id: I120e26ad0ca486a326874986e142dcaee965b62d
Original-Signed-off-by: Brian Norris <briannorris@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/388009
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16882
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This reverts commit 28821dbb22.
(https://review.coreboot.org/16649)
This change causes the kernel to boot really slow. Maybe there is an
interrupt storm that prevents the kernel from making any
progress. Reverting until the proper kernel dependency is met.
BUG=chrome-os-partner:57364
BRANCH=None
TEST=Kernels boots to prompt fine on DVT.
Change-Id: I1c9913b4476a08303f9dd887b8631601c847dcf7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d7014ee1bb88df7a2d7f6b3dced797fef75b252d
Original-Change-Id: I061c0b03b43b516a190b370c04888e73a410fcf1
Original-Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/391233
Original-Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/16881
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
CL:377541 was supposed to remove the big CPU cluster initialization from
rkclk_init() in the bootblock and move it to a more suitable place in
ramstage. Except that next to all the code cleanup I did in that patch,
I seem to have forgotten to actually remove that old code.
Big thanks to Nico for spotting that in the upstream coreboot review.
BRANCH=gru
BUG=chrome-os-partner:54906
TEST=Booted Kevin.
Change-Id: I09fe948b4587536802b42329b813177439e0804f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 77f9eaf0446b22adfca79d0adf8a0ecfd93c0040
Original-Change-Id: I13dab208225b7e43ad864f2f3cf51b3c104acd4b
Original-Reported-by: Nico Huber <nico.h@gmx.de>
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/389236
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16769
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This selects the rank to train before training is triggered. This is
to prevent any race conditions with the hardware.
BRANCH=none
BUG=chrome-os-partner:56940
TEST=stressapptest -M 1536 -s 1000
Change-Id: I892bace414cf4495619d41bdaea0c4e91c1e29b3
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 8f2dd6f52978a9e54ddd2688eb68fd237aabfe2d
Original-Change-Id: I4e7118d8509b59e391d0a254477b5390dfdd43a5
Original-Signed-off-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/387907
Original-Commit-Ready: Douglas Anderson <dianders@chromium.org>
Original-Tested-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: 云平 汤 <typ@rock-chips.com>
Reviewed-on: https://review.coreboot.org/16768
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
UX Doc = go/gale-hw-ui
This color wasn't changed earlier as the change wasn't done in
the OS also. However, since we cannot change this later in FW
(but OS can change anytime), I am making this change after discussing
with the UX team.
BUG=b:31501528, b:31633562
TEST=Change the device state to 'recovery mode' to observe the new
color.
BRANCH=none
Change-Id: Ia91f14eb77492095cb41a9de0bb9790e72aa4851
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36a3d8c6eabbc0b23d0a15d5bddc5ed3bdeebe70
Original-Change-Id: I88768b94cf91804a6005e44b1a168e059698ec4b
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/388206
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Christopher Book <cbook@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16767
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Nico Huber