| Age | Commit message (Collapse) | Author |
|---|
|
Monitor/Mwait is broken on APL. So, it needs to be disabled.
BUG=chrome-os-partner:56922
BRANCH=None
Change-Id: I12cd4280de62e0a639b43538171660ee4c0a0265
Signed-off-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Reviewed-on: https://review.coreboot.org/17200
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
framebuffer address is dynamically chosen by libpayload now, so there's
no need to configure it in coreboot.
CQ-DEPEND=CL:401402
BUG=chrome-os-partner:58675
BRANCH=none
TEST=Boot from kevin, dev screen is visible
Change-Id: I9f1e581d5c63b3579b26be22ce5c8d1e71679f6f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: b3b6675420592c30e1e0abc8f8e9dd6ed5abd04c
Original-Change-Id: I7e3162f24a4dc426fe4e10d74865cf0042c80db5
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/401401
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17109
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Near the end of DDR initialization, the system switches to the index1
configuration. Sometimes this failed and a status bit that coreboot was
waiting for was never set, hanging the system.
Instead, give the system 100ms to reach the new configuration or reboot
it, which generally fixes the issue. Also reset when training the index1
configuration fails.
BUG=chrome-os-partner:57988
BRANCH=None
TEST=The error condition now leads to a reboot of coreboot which
recovers the system, instead of hanging.
Change-Id: Icb4270369102ff7a4ce91b0677e04b4eb10f1204
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ca250d0628ea3b6b39d5131246eaba68637c5140
Original-Change-Id: Id6e8936d90e54b733ac327f8476d744b45639232
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/399681
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17106
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
1. Update write leveling value to 0x200.
When the wrdqs slave delay is changed to 0x200, the phase between the
dqs and the clock is 0 degrees. The pcb layout can make sure the tDQSS
timing is smaller than 0.25tck, so this value is useful for both higher
and lower frequencies.
2. Disable read leveling for LPDDR3.
The read leveling result is unreliable - the value is not in the middle
of the read eye. To fix this, disable read leveling and fix the read
DQSn slave delay setting for DQn to 0x080 (1/4 cycle delay of the
input signal).
BUG=None
BRANCH=None
TEST=Boot from kevin; Check by shmoo read eye and stability test, that
the updated value of 0x80 is better.
Change-Id: Ia72b601d9bf4e34ba1b0b4584b2c5c3ce9dafbd4
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 37e8dfe783db3ce71aa026b4609ed0bfa16db06f
Original-Change-Id: I2a5d40c0348449b2a7c609c1db65da4ed5f1c09f
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Signed-off-by: Jeff Chen <cym@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/396598
Original-Commit-Ready: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Reviewed-on: https://review.coreboot.org/17105
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
To enable DDR Dynamic Voltage and Frequency Scaling (DVFS) we need to
train alternative configurations first, so do the training and store the
values.
BUG=None
BRANCH=None
TEST=Boot from kevin
Change-Id: I944a4b297a4ed6966893aa09553da88171307a42
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 94533ff3ba21bcb0ace00bedcf0cebb89a341be2
Original-Change-Id: I4a98bc0db5553d154fedb657e35b926a92aa80c7
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/386596
Original-Commit-Ready: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Derek Basehore <dbasehore@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17104
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Testing for "devfn < 0" on an unsigned doesn't work, and i2c_bus_to_devfn
returns an int (with -1 for "error"), so use int for devfn.
Adapt Change-Id I7d1cdb6af4140f7dc322141c0c018d8418627434 to fix more
instances.
Change-Id: I001a9b484a68e018798a65c0fae11f8df7d9f564
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1357450, #1357449
Reviewed-on: https://review.coreboot.org/17054
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Some of our RK3399 devices have panel resolutions as high as 2400x1600.
With 16bpp that barely still fit into an 8MB framebuffer, but then we
changed it to 32bpp for better image quality...
Note that this is a band-aid. Coreboot-allocated framebuffers shouldn't
be used at all on ARM64 devices, since libpayload is perfectly capable
to dynamically allocate it with the right size based on EDID-information
on this architecture. That will require some more elaborate work to be
fixed with later patches.
BRANCH=gru
BUG=chrome-os-partner:58044
TEST=Warm-reboot Kevin on the dev screen, confirm that you don't see the
lower half of the screen that overflowed our allocated framebuffer
preserved from the last boot as soon as the backlight turns on.
Change-Id: I00a63cfef35a8ee734543abbdb298344fb529283
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d2718efcacb50371624d9f6a3b586c298e8c2fec
Original-Change-Id: Ia1fa28971c65d7d0639966e715f742309245172b
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/399966
Original-Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/17108
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Add soc core init to set up the following feature MSRs:
1. C-states
2. IO/Mwait redirection
BUG=chrome-os-partner:56922
BRANCH=None
TEST= Check C-state functioning using 'powertop'. Check 0xE2 and
0xE4 MSR to verify IO/Mwait redirection.
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Change-Id: I99b66b02eb790b6b348be7c964d21ec9a6926926
Reviewed-on: https://review.coreboot.org/17168
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
All current implementations of ramstage_cache_invalid() were just
resetting the system based on the RESET_ON_INVALID_RAMSTAGE_CACHE
Kconfig option. Move that behavior to a single implementation
within prog_loaders.c which removes duplication.
Change-Id: I67aae73f9e1305732f90d947fe57c5aaf66ada9e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17184
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
ramstage_cache_invalid which was added in
I83fe76957c061f20e9afb308e55923806fda4f93 (review.coreboot.org/#/c/17112)
requires hard_reset to be defined in postcar stage.
BUG=None
BRANCH=None
TEST=Compiles successfully for reef.
Change-Id: I283277c373259e0e2dfe72e3c889ceea012544f2
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17182
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
While using '3' is fine for the standard gpe0 for skylake, I want
to make sure anyone that copies this code doesn't tweak GPE0_REG_MAX
without the hard coded index. If that does happen now things will
still work, but it may just not match the hardware proper.
BUG=chrome-os-partner:58666
Change-Id: I434b9a765a0a2f263490bb2b4ecb3635292d46c9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17160
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Add a GPIO macro that allows a pin to be routed to the APIC with
the input inverted. This allows a normal interrupt to get used as
a GPE during firmware and still be used as a perhiperal interrupt
in the kernel.
BUG=chrome-os-partner:58666
TEST=boot en eve and use TPM IRQ in firmware and OS
Change-Id: I77f727f749fdd5281ff595a9237fe1e634daba96
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17176
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
uart_debug.c was accidentally dropped in verstage in
64ce1d122c0464a4ef138fb7452a91b408b1a7c2
(https://review.coreboot.org/17136). Fix that.
Change-Id: If37a028550d419bada80d157c4de02fd82d26c89
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17175
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
|
|
Make bootblock_fsp_temp_ram_init as static inline.
Change-Id: Iacf24728a45fc6554d7a425feecc25e55ac5da6c
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17084
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Add the necessary infrastructure to support eSPI SMI events,
and a mainboard handler to pass control to the EC.
BUG=chrome-os-partner:58666
TEST=tested on eve board with eSPI enabled, verified that lid
close event from the EC during firmware will result in an SMI
and shut down the system.
Change-Id: I6367e233e070a8fca053a7bdd2534c0578d15d12
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17134
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Export the pmc_gpe_init() function from pmc.c to pmutil.c
so it can be used in bootblock, and then call it from there
to initialize any GPEs for use in firmware.
BUG=chrome-os-partner:58666
TEST=test working GPE as TPM interrupt on skylake board
Change-Id: I6b4f7d0aa689db42dc455075f84ab5694e8c9661
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17135
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Add the SOC definition for acpi_get_gpe() so it can be used
by the I2C TPM driver. Also add the I2C support code to
verstage so it can get used by vboot.
BUG=chrome-os-partner:58666
TEST=boot with I2C TPM on skylake board
Change-Id: I553f00a6ec25955ecc18a7616d9c3e1e7cbbb8ca
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17136
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
The Deep S3 state will lose a lot of register contents that we
used to rely on for determining wake source.
In order to make use of this override the enable bit for wake
sources that are enabled for Deep S3 in devicetree.cb.
BUG=chrome-os-partner:58666
TEST=check for _SWS reporting wake source on S3 resume on skylake
Change-Id: If5113d6890f6cbecc32f92af67a29952266fe0ac
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17137
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Remove the FADT from the individual mainboards and select and
use COMMON_FADT in the SOC instead. Set the ACPI revision to 5.
Change-Id: Ieb87c467c71bc125f80c7d941486c2fbc9cd4020
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17138
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
|
|
Three things are required to enable wake-on-usb:
1. 5V to USB ports should be enabled in S3.
2. ASL file needs to have appropriate wake bit set.
3. XHCI controller should have the wake on attach/detach bit set for the
corresponding port in PORTSCN register.
Only part missing was #3.
This CL adds support to allow mainboard to define a bitmap in
devicetree corresponding to the ports that it wants to enable
wake-on-usb feature. Based on the bitmap, wake on attach/detach bits in
PORTSCN would be set by xhci.asl for the appropriate ports.
BUG=chrome-os-partner:58734
BRANCH=None
TEST=Verified that with port 5 enabled, chell wakes up from S3 on usb
attach/detach.
Change-Id: I40a22a450e52f74a0ab93ebb8170555d834ebdaf
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17056
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Use intel common infrastructure to enable support for write-protecting
SPI flash range. Also, enable this protection for RW_MRC_CACHE.
BUG=chrome-os-partner:58896
TEST=Verified that write to RW_MRC_CACHE fails in OS using
"flashrom -p host -i RW_MRC_CACHE -w /tmp/test.bin"
Change-Id: I35df12bc295d141e314ec2cb092d904842432394
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17117
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
BUG=chrome-os-partner:58896
Change-Id: I281c799a1798f3353d78edd8a6cd16bbe762bc2c
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17116
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Write-protect SPI flash range provided by caller by using a free Flash
Protected Range (FPR) register. This expects SoC to define a callback
for providing information about the first FPR register address and
maximum number of FPRs supported.
BUG=chrome-os-partner:58896
Change-Id: I4e34ede8784e5587a5e08ffa10e20d2d14e20add
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17115
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Change-Id: I8d81b9cf280e724c935106c8f00692300094ad3f
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17119
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
This reverts commit a52f883b100f3229dd4d86c81c08781993861f73
(https://review.coreboot.org/16587).
The above commit caused another sever kernel boot regression upwards
of 2 minutes to get through kernel init on quad core systems.
BUG=chrome-os-partner:58994
Change-Id: Id4abc332bf2266e3b3b7be714371ce9cf329bcd9
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17121
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
|
|
We found sdram may fail in pctl_cfg(), so we check the status in this
function. If it exceeds 100ms still in this function, we will restart
the system. We also found there are rare chances DDR training fails,
so also restart system in that case.
BUG=chrome-os-partner:57988
BRANCH=None
TEST=coreboot resets on failure and eventually the system comes up
Change-Id: Icc0688da028a8f4f81eafe36bbaa79fdf2bcea74
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 89e45f8352f62e19a203316330aba14ccc5c8b11
Original-Change-Id: If4e78983abcfdfe1e0e26847448d86169e598700
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/397439
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17045
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Implement GPIO ACPI AML generating functions that can be called by
coreboot drivers to generate GPIO manipulation code in AML. Following
functions are implemented:
1. acpigen_soc_read_rx_gpio
2. acpigen_soc_get_tx_gpio
3. acpigen_soc_set_tx_gpio
4. acpigen_soc_clear_tx_gpio
BUG=chrome-os-partner:55988
Change-Id: I3d8695d73a1c43555032de90f14ee47ccee45559
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17082
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
This patch adds a Makefile rule for mvmap2315 to install a BDB and
bootblock code in the BOOTBLOCK region. The resulting BDB has a
header and data both signed by a RSA-4096 key.
BUG=chrome-os-partner:57889
BRANCH=none
TEST=emerge-rotor coreboot and examined the output binary. Booted
coreboot.rom.
Change-Id: I1e20a09b12f8f8ed4d095aa588e3eb930f359fc5
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://review.coreboot.org/16747
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
While we stub out free(), tools like coverity scan have no idea, and it
might change in the future. So free it.
Change-Id: I1d93a6f45b64445662daa95b51128140ad0a87e2
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1260716
Reviewed-on: https://review.coreboot.org/17055
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
|
|
Enable mainboard Kconfig to select between FSP 2.0 & 1.1 driver to be
used.
If mainboard Kconfig selects MAINBOARD_USES_FSP2_0 the FSP2_0 driver is
used else FSP1_1.
Change-Id: I724aaa87c2b0b8f6ddb18f61af9c37176ef632f2
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/17044
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This refactoring was already carried into RK3288 with commit 6911219
(edid: Add helper function to calculate bits-per-pixel dependent values)
but it seems that the code for RK3399 was copy&pasted from it too early
to pick this up. Fix that so that future Rockchip SoCs can copy&paste
the right thing.
Change-Id: I5050c58d18db38fffabc7666e67a622d4a828590
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17050
Tested-by: build bot (Jenkins)
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Skip FSP initiated core/MP init as it is implemented and initiated
in coreboot.
Add soc core init to set up the following feature MSRs:
1. C-states
2. IO/Mwait redirection
BUG=chrome-os-partner:56922
BRANCH=None
TEST= Check C-state functioning using 'powertop'. Check 0xE2 and
0xE4 MSR to verify IO/Mwait redirection.
Signed-off-by: Ravi Sarawadi <ravishankar.sarawadi@intel.com>
Change-Id: I97c3d82f654be30a0d2d88cb68c8212af3d6f767
Reviewed-on: https://review.coreboot.org/16587
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch sets the package power limit (PL1) value in RAPL MSR
and disables MMIO register. Added configurable PL1 override
parameter to leverage full TDP capacity.
BUG=chrome-os-partner:56922
TEST=webGL performance(fps) not impacted before and after S3.
Change-Id: I34208048a6d4a127e9b1267d2df043cb2c46cf77
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Signed-off-by: Venkateswarlu Vinjamuri <venkateswarlu.v.vinjamuri@intel.com>
Reviewed-on: https://review.coreboot.org/16884
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
In FSP1.1 all the platform resets including global was handled
on its own without any intervention from coreboot.
In FSP2.0, any reset required will be notified to coreboot
and it is expected that coreboot will perform platform reset.
Hence, implement platform global reset hooks in coreboot. If Intel
ME is in non ERROR state then MEI message will able to perform
global reset else force global reset by writing 0x6 or 0xE to
0xCF9 port with PCH ETR3 register bit [20] set.
BUG=none
BRANCH=none
TEST=Verified platform global reset is working with MEI
message or writing to PCH ETR3.
Change-Id: I57e55caa6d20b15644bac686be8734d9652f21e5
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16903
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
As per ME BWG, there are two mechanism to generate a Global
Reset (resets both host and Intel ME), one is through CF9h
IO write of 6h or Eh with "CF9h Global Reset" (CF9GR) bit set,
PMC PCI offset ACh[20]. Another is to issue the Global Reset
MEI message. Because any attempts to cause global reset without
synchronizing the two sides might cause unwanted side effects,
such as unwritten flash data that will get destroyed if the
host were to cause a global reset without informing Intel ME
firmware, the recommended method is to send a Global Reset MEI
message when the following conditions are met:
The PCH chipset firmware just needs to complete the Intel ME
Interface #1 initialization and check the Intel ME HFSTS state
if Intel ME is not in ERROR state and is accepting MEI commands
then firmware should be able to use Global Reset MEI message to
trigger global reset.
Furthermore, if Intel ME is in ERROR state, BIOS can use I/O 0xCF9
write of 0x06 or 0x0E command with PCH ETR3 register bit [20]
to perform the global reset.
BUG=none
BRANCH=none
TEST=Verified Global Reset MEI message is able to perform platform
global issue in ME good state.
Change-Id: If326a137eeadaa695668b76b84c510e12c546024
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Reviewed-on: https://review.coreboot.org/16902
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This patch programs and enables BAR for ME (bus:0/
device:0x16/function:0) device to have early ME communication.
BUG=none
BRANCH=none
TEST=Verified Global Reset MEI message can able to perform platform
global reset during romstage.
Change-Id: I99ce0ccd42610112a361a48ba31168c9feaa0332
Signed-off-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-on: https://review.coreboot.org/17016
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
VBOOT_EC_SLOW_UPDATE should be selected if EC_GOOGLE_CHROMEEC is used as
building coreboot with Chrome OS support & without Chrome EC gives a
build error in coreboot.
Change-Id: I77eed0e1bdc1ba49381b72e21b0e18f573cadff0
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17020
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The clearing of the PMC registers was not being called resulting
in state persisting across reboots. This state is queried and
events are added to the eventlog like 'RTC reset' events. However,
the RTC reset event is a one time thing so it should only be logged
once. Without the clearing of the state the event was logged on
every boot.
BUG=chrome-os-partner:58496
Change-Id: I60aa7102977c2b1775ab8c54d1c147737d2af5e2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17027
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
This reverts commit 28821dbb2261267462a7e9b0cc1c23b51af2d3ee.
(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>
|
|
BUG=b:31690391
TEST=Tested with board ID
BRANCH=none
Change-Id: I9a2b7eec111a79827f72a506942a8ec833ba7e60
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: f23e2b6e72491aaafa15774f9bded3e14363abbc
Original-Change-Id: I23183db29d7f7dd812e94ab6a1f2f1329c46ac60
Original-Signed-off-by: Kan Yan <kyan@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/388778
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Suresh Rajashekara <sureshraj@chromium.org>
Reviewed-on: https://review.coreboot.org/16770
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>
|
|
There are two modifications in the driver:
1. Correctly set speeds based on DDR frequency.
Control the speeds in the predriver circuits to reduce power.
SPEED[1:0]
2'b00:less than 800Mbps(400MHz)
2b01 : 800Mbps(400MHz) to 1600Mbps(800MHz)
2b10 : 1600Mbsp(800MHz) to 2400Mbps(1200MHz)
2b11 : 3200Mbps and greater
2. Configure the number of cycles for the phy clock pll wait time after
locking, based on the DDR config file.
BRANCH=none
BUG=chrome-os-partner:56940
TEST=do memtester on kevin board, and pass
Change-Id: Iaf6da59c6c5c290867e0922a2a99de272f4c7bde
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 125cf8afac3a682d33896fe74a20ba1d498a3bd2
Original-Change-Id: Iabc17df37a701c4f052540c3c259f209a1db3c59
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/387428
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16722
Reviewed-by: Martin Roth <martinroth@google.com>
Tested-by: build bot (Jenkins)
|
|
In USB2 only mode, the Type-C PHY will be held in reset and
only the USB2 logic of the USB3 OTG controller and PHY will be
used over the USB2 pins on the Type-C connector to support Low,
Full and High-speed USB operation.
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: Ic265c0c91c24f63b2f9c3106eb2bb277a589233b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: a37ccc5b6019967483eac6b5a360d67bc3326e93
Original-Change-Id: I582f04f84eef447ff0ba691ce60e9461ed31cfad
Original-Signed-off-by: Liangfeng Wu <wulf@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/385837
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/16717
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
To improve sdram 800MHz and 933MHz stability, we
need to modify write leveling flow to get the
proper write leveling value.
BUG=chrome-os-partner:56940
BRANCH=none
TEST=Boot from kevin on 933MHz, and do stressapptest
Change-Id: I5b24c93d4a57917fb9af7e5e2a95d8423ccbaa7e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: d84bf25b3e5de373c7913e6d534a810cb984b3fd
Original-Change-Id: I87efddf628c3683fcb85d6875e029cf3cbc482be
Original-Signed-off-by: Jianqun Xu <jay.xu@rock-chips.com>
Original-Signed-off-by: Xing Zheng <zhengxing@rock-chips.com>
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/384292
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/16716
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
We found that we may want to load some components of BL31 on the RK3399
into SRAM. As usual, these components may not overlap any coreboot
regions still in use at that time, as is already statically checked by
the check-ramstage-overlaps rule in Makefile.inc.
On RK3399, the only such regions are TTB and STACK. This patch moves the
TTB region back to the end of SRAM (right before STACK), so that a large
contiguous region of SRAM before that remains usable for BL31.
BRANCH=gru
BUG=None
TEST=Booted Kevin.
Change-Id: I1689d0280d79bad805fea5fc3759c2ae3ba24915
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 1d4c6c6f6cc0efe97d6962a81e309a1c040d1def
Original-Change-Id: I37c94f2460ef63aec4526caabe58f35ae851bab0
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/384635
Original-Reviewed-by: Simon Glass <sjg@google.com>
Reviewed-on: https://review.coreboot.org/16714
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
With a SPI clock above about 24MHz the APB cannot keep up when doing
individual byte transfers. Adjust the driver to use 16-bit reads when
it can, to remove this bottleneck.
Any transaction which involves writing bytes still uses 8-bit transfers,
to simplify the code. These are the transfers that are not time-critical
since they tend to be small. The case that really matters is reading from
SPI flash.
In general we can use 16-bit reads anytime we are transferring an even
number of bytes. If the code detects an odd number of bytes, it tries to
perform the operation in two steps: once in 16-bit mode with an even
number of bytes, and once in 8-bit mode for the final byte. This allow
us to use 16-bit reads even if asked to transfer (for example) 0xf423
bytes.
The limit on in_now and out_now is adjusted to 0xfffe to avoid an extra
transfer when transferring ~>=64KB.
CQ-DEPEND=CL:383232
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see that things still work correctly. I tested (with
extra debugging) that the 16-bit case is being picked when it should be.
Change-Id: If5effae9a84e4de06537fd594bedf7f01d6a9c88
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: ec250b4931c7d99cc014e32ab597fca948299d08
Original-Change-Id: Idc5b7e5d82cdbdc1e8fe8b2d6da819edf2d5570c
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381312
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/16712
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Some of the asserts for valid clock divisor ranges were off by one. This
patch corrects them and writes them all in a consistent way.
BRANCH=None
BUG=None
TEST=Booted Kevin.
Change-Id: I81749408a40822100797f1734f3b88987d12d8d5
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e09cdfde26700496aaa1fc41489f63a355e8a89d
Original-Change-Id: I429edb99e2d5ff2302d9750e6569b3d21f5686fa
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381574
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/16704
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This patch moves the big CPU cluster initialization on the RK3399 from
the clock init bootblock function into ramstage. We're only really doing
this to put the cluster into a sane state for the OS, we're never
actually taking it out of reset ourselves... so there's no reason to do
this so early.
Also cleaned up the interface for rkclk_configure_cpu() a bit to make it
more readable.
BRANCH=None
BUG=chrome-os-partner:54906
TEST=Booted Kevin.
Change-Id: I568b891da0abb404760d120cef847737c1f9e3ec
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bd7aa7ec3e6d211b17ed61419f80a818cee78919
Original-Change-Id: Ic3d01a51531683b53e17addf1942441663a8ea40
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/377541
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16698
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
At higher SPI bus speeds the SPI RX value is not available in time for
sampling at the normal time. Add a delay to ensure that we read the
correct data.
The value of 40ns is chosen arbitrarily. In my testing I can use a sample
delay of 1 even at 24MHz. But since it is not necessary, I have left that
case alone. It kicks in at 25MHz and up.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=boot on gru and see no change at current speed
Change-Id: I3ef335d9a532eaef1e76034bd02e185acf11176a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: e9b620c47fc3e39211487507fadb8657afdebee7
Original-Change-Id: I65d66d752cbbbee4d02f475de23a52069a0e9782
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381311
Original-Commit-Ready: Julius Werner <jwerner@chromium.org>
Original-Tested-by: Simon Glass <sjg@google.com>
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16707
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch fixes a typo in the clock initialization code that caused the
PERILP1_PCLK_HZ constant to be ignored and the clock to always run at
the same speed as its parent (PERILP1_HCLK_HZ). Since we've done all our
previous tests and validation with this bug, we should probably increase
the value of the constant (that had not actually been used) to the value
that we had been incorrectly using instead (which also makes effective
SPI read times faster).
BRANCH=None
BUG=chrome-os-partner:56556
TEST=Booted Kevin.
Change-Id: Ibeb08f5fe5e984a74e3f57e60c62d4bfb644b6ca
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 06e605a5fcb9bdf13a3d301112380633b892fd4e
Original-Change-Id: Icb5e079f53eb22b0dbf0ea4d1c2ff08688e3fa8e
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/381031
Original-Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-on: https://review.coreboot.org/16703
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Output GPIOs should never have a pull-up or pull-down resistor attached
since they're actively driven. Since some GPIOs get initialized with a
pull at power-on reset, we should explicitly overwrite that setting.
Most other platforms do this on gpio_output, but Rockchip hadn't yet.
Also, shuffle some code around to make things cleaner and allow for
easier code reuse.
BRANCH=None
BUG=chrome-os-partner:52526
TEST=Booted Kevin.
Change-Id: I1425d074ea1e90f4484e1e84a8002b057192c5f7
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: df5b236bfd58b172435043c1cb792b917a4ec4ab
Original-Change-Id: I044266d71ef8bd0518316ff72d829d1ca1e30f35
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/382531
Original-Reviewed-by: Simon Glass <sjg@google.com>
Reviewed-on: https://review.coreboot.org/16710
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
As far as I know, the Cortex-A53 cores in RK3399 are of a newer revision
that is not affected by ARM erratum 843419. If it was, the workaround
would also need to be enabled in libpayload and Chrome OS userspace,
which it currently isn't. I assume this was just incorrectly copied over
from another SoC and we can safely remove it.
BRANCH=None
BUG=chrome-os-partner:56700
TEST=Booted Kevin.
Change-Id: I5b1534c954a6d985499b481738723cabbdc07253
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 4891cc866583532ee3dcb1a5ad5b81670eb0743d
Original-Change-Id: Iadb57428f8727ce0e563204723644e2c79e3007c
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376363
Original-Commit-Queue: Douglas Anderson <dianders@chromium.org>
Original-Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16702
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Kconfig hex values don't need to be in quotes, and should start with
'0x'. If the default value isn't set this way, Kconfig will add the
0x to the start, and the entry can be added unnecessarily to the
defconfig since it's "different" than what was set by the default.
A check for this has been added to the Kconfig lint tool.
Change-Id: I86f37340682771700011b6285e4b4af41b7e9968
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16834
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
|
|
Change-Id: Ia9c1c065f20bf2b37afc7485ef8df3abd35e2f14
Reviewed-on: https://review.coreboot.org/16607
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
The microcode for the BSP gets loaded early from the fit table, but in
case we have newer microcode in cbfs, try to load it again from cbfs.
BUG=chrome-os-partner:53013
TEST=Boot and verify that microcode tries to load into the BSP.
Change-Id: Ifd6c78d7b0eec333b79e0fe5cb6a81981b078f5d
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16829
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
A copy of our uart8250io driver sneaked in with Broadwell-DE support.
The only difference is the lack of initialization (due to FSP handling
that).
TEST=manually compared resulting object files
Change-Id: I09be10b76c76c1306ad2c8db8fb07794dde1b0f2
Signed-off-by: Nico Huber <nico.h@gmx.de>
Reviewed-on: https://review.coreboot.org/16786
Tested-by: build bot (Jenkins)
Reviewed-by: York Yang <york.yang@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Fix the build issues with FSP 2.0:
* Remove struct from the various data structures.
* Properly display the serial port UPDs.
* Change chipset_handle_reset parameter type
BRANCH=none
BUG=None
TEST=Build FSP 2.0 (SEC/PEI core with all FSP debug off) and run on
Galileo Gen2
Change-Id: Icae578855006f18e7e5aa18d2fd196d300d0c658
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16808
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add support for multiple versions of FSP.
BRANCH=none
BUG=None
TEST=Build FSP 1.1 (SEC/PEI core, with all FSP debug off) and run on
Galileo Gen2
Change-Id: Ie7e7f0f883c4d3bfcb18fa25571e505cdde00b2d
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16807
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Add Kconfig values to select the FSP setup:
* FSP version: 1.1 or 2.0
* Implementation: Subroutine or SEC/PEI core based
* Build type: DEBUG or RELEASE
* Enable all debugging for FSP
* Remove USE_FSP1_1 and USE_FSP2_0
Look for include files in vendorcode/intel/fsp/fsp???/quark
BRANCH=none
BUG=None
TEST=Build FSP 1.1 (subroutine) and run on Galileo Gen2
Change-Id: I3a6cb571021611820263a8cbfe83e69278f50a21
Signed-off-by: Lee Leahy <Leroy.P.Leahy@intel.com>
Reviewed-on: https://review.coreboot.org/16806
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
A dedicated pmc_ipc DSDT entry is required for pmc_ipc kernel driver.
The ACPI mode entry includes resources for PMC_IPC1, SRAM, ACPI IO and
Punit Mailbox.
BRANCH=None
BUG=chrome-os-partner:57364
TEST=Boot up into OS successfully and check with dmesg to see the
driver has been loaded successfully without errors.
Change-Id: I3f60999ab90962c4ea0a444812e4a7dcce1da5b6
Signed-off-by: Zhao, Lijian <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/16649
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Intel telemetry support will require PMC IPC1 and SRAM devices to be
operated in ACPI mode. Then using fixed resources on BAR0, BAR1
and BAR2 (PMC only) for those two devices will help
the resource assignment in DSDT stage.
BUG=chrome-os-partner:57364
BRANCH=None
TEST=Boot up into Chrome OS successfully and check with dmesg to see
the driver has been loaded successfully without errors.
Change-Id: I8f0983a90728b9148a124ae3443ec29cd7b344ce
Signed-off-by: Zhao, Lijian <lijian.zhao@intel.com>
Reviewed-on: https://review.coreboot.org/16648
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Instead of having each mainboard provide the power button,
uncondtionally provide the power button ACPI device on behalf
of each mainboard.
BUG=chrome-os-partner:56677
Change-Id: I94c9e0353c8d829136f0d52a356286c6bedcddd5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16731
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Initialize the PCNT variable in GNVS so it is available to ACPI code
that expects to know the number of CPUs.
Change-Id: I7a6e003ac94218061bf98e8883ed2c62d856af8d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16693
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This patch corrects the comment section in gpio.asl for
GPE method.
Change-Id: I45771a295ee1eda00b9699f42cddd120223ff7bf
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/16647
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Implement the generic acpi_get_gpe() function to read and clear
the GPE status for a specific GPE.
Tested by watching GPE status in a loop while generating interrupts
manually from the EC console.
BUG=chrome-os-partner:53336
Change-Id: I482ff52051a48441333b573f1cd0fa7f7579a6ab
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16671
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
Initialize the GPEs from mainboard config in bootblock, so they
can be used in verstage to query latched interrupt status.
I still left it called in ramstage just to be sure that the
configuration was not overwritten in FSP stages.
Tested by reading and reporting GPE status in a loop in verstage
and manually triggering an interrupt on EC console.
BUG=chrome-os-partner:53336
Change-Id: Iacd0483e4b3229aca602bb5bb40586eedf35a6ea
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16670
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
These values are found in util/cbfstool/cbfs.h.
Change-Id: Iea4807b272c0309ac3283e5a3f5e135da6c5eb66
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/16646
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
The SPI driver is quite slow at reading data. For example, with a 24MHz
clock on gru it achieves a read speed of only 13.9Mbps.
We can correct this by reading the status registers once, then reading as
many bytes as are available before checking the status registers again. It
seems likely that a status register read requires synchronizing with the
SPI FIFO clock domain, which takes a while.
BUG=chrome-os-partner:56556
BRANCH=none
TEST=run on gru and see the speed increase from 13.920 Mbps to 24.712 Mbps
Change-Id: I24aed0c9c6c5445634c4e056922afaee4e9a7b33
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 49c2fc20d7d7d703763e9b0a6f68313a349a84b9
Original-Change-Id: I42745f01f0fe069f6ae26d866004d36bb257e6b2
Original-Signed-off-by: Simon Glass <sjg@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/376945
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/16582
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This patch adds support to reboot the whole board after a hardware
watchdog reset, to avoid the usual TPM issues. Work 100% equivalent to
Veyron.
From my tests it looks like both SRAM and PMUSRAM get preserved across
warm reboots. I'm putting the WATCHDOG_TOMBSTONE into PMUSRAM since that
makes it easier to deal with in coreboot (PMUSRAM is currently not
mapped as cached, so we don't need to worry about flushing the results
back before reboot).
BRANCH=None
BUG=chrome-os-partner:56600
TEST='stop daisydog; cat > /dev/watchdog', press CTRL+D, wait 30
seconds. Confirm that system reboots correctly without entering recovery
and we get a HW watchdog event in the eventlog.
Change-Id: I317266df40bbb221910017d1a6bdec6a1660a511
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 3b8f3d064ad56d181191c1e1c98a73196cb8d098
Original-Change-Id: I17c5a801bef200d7592a315a955234bca11cf7a3
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/375562
Original-Commit-Queue: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://review.coreboot.org/16578
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
This reverts commit 5e3dad66227bba4be9365ee76d00231bb5577b56.
|
|
This reverts commit 3d43a7c111d00be246160a04023fe438ae0cac57.
|
|
Implement the generic acpi_get_gpe() function to read and clear
the GPE status for a specific GPE.
Tested by watching GPE status in a loop while generating interrupts
manually from the EC console.
BUG=chrome-os-partner:53336
Change-Id: Id885e98d48c2133a868da19eca3360e2dfb82e84
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
Initialize the GPEs from mainboard config in bootblock, so they
can be used in verstage to query latched interrupt status.
I still left it called in ramstage just to be sure that the
configuration was not overwritten in FSP stages.
Tested by reading and reporting GPE status in a loop in verstage
and manually triggering an interrupt on EC console.
BUG=chrome-os-partner:53336
Change-Id: I1af3e9ac1e5c59b9ebb5c6dd1599309c1f036581
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
|
|
This patch sets some magic number in magic undocumented registers that
are rumored to make USB 2.0 signal integrity better on Kevin. I don't
see any difference (unfortunately it doesn't solve the problems with
long cables on my board), but I guess it doesn't hurt either way.
BRANCH=None
BUG=chrome-os-partner:56108,chrome-os-partner:54788
TEST=Booted Kevin with USB connected through Servo. Seems to have
roughly the same failure rate as before.
Change-Id: If31fb49f1ed7218b50f24e251e54c9400db72720
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 0c5c8f0f80ea1ebb042bcb91506a6100833e7e84
Original-Change-Id: Ifbd47bf6adb63a2ca5371c0b05c5ec27a0fe3195
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/370900
Original-Reviewed-by: Guenter Roeck <groeck@chromium.org>
Original-Reviewed-by: David Schneider <dnschneid@chromium.org>
Reviewed-on: https://review.coreboot.org/16265
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
|
|
Add FSP 2.0 support in ramstage.
Populate required Fsp Silicon Init params and configure mainboard
specific GPIOs.
Define function fsp_soc_get_igd_bar needed by fsp2.0 driver for
pre OS screens.
Change-Id: Ib38ca7547b5d5ec2b268698b8886d5caa28d6497
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/16592
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
This implements acpi name for PCIe root port.
BUG=chrome-os-partner:56483
Change-Id: Ifec1529c477f554d36f3932b66f62eea782fdcaa
Signed-off-by: Vaibhav Shankar <vaibhav.shankar@intel.com>
Reviewed-on: https://review.coreboot.org/16621
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
In order to ensure bootblock console output shows up in cbmem
console unconditionally select BOOTBLOCK_CONSOLE.
BUG=chrome-os-partner:57513
Change-Id: Ie560dd0e7102c79f6db186a11d6f934505bac116
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16622
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Unconditionally turn on postcar console for apollolake.
BUG=chrome-os-partner:57513
Change-Id: I3d956be4a5834a4721767d34216eebeabef3e315
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16620
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
When the boot media is memory mapped mark it as cacheable
after romstage. Otherwise the boot media is uncacheable and
all loads from it take longer. Loading FSP-S alone in ramstage
went down to 17.5ms from 54ms.
BUG=chrome-os-partner:56656
Change-Id: I6703334ba8fe98aca26ba1c995d6d3abb0ddef33
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16613
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Currently we are setting the gpio_tier1_sci in smihandler before
going to S3. But this won't work for S0iX as it happens from Linux
kernel and SMI handler is not involved in that flow. We need to
set this bit i.e. bit 15 in ACPI gpe0a register at 0x430h. The Linux
kernel before going to sleep checks what values are passed through
ASL as wake events (through _PRW), keeps those enabled only and
clears other bits in gpe0 enable registers. So we need to inform
the kernel to keep gpio_tier_sci also set as these are needed for
any wake event. This patch adds ASL code for sleep button device with
HID id PNP0C0E. We are adding _PRW method for sleep button device
with this patch.
BUG=chrome-os-partner:56483
TEST=System resumes from S3 on lidopen, powerbutton and USB wake.
Also from S0iX system is resuming for WIFI wake.
Change-Id: Ie8517cad9cd37c25788c22250894d4f9db344ff9
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/16564
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
|
|
move lb_framebuffer function in soc/intel/apollolake
to driver/intel/fsp20 so that fsp 2.0 bases soc's can
use common lb_framebuffer function.
Change-Id: If11bc7faa378a39cf7d4487f9095465a4df84853
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/16549
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
|
|
Populate SoC related Memory initialization params.
Post memory init, set DISB, setup stack and MTRRs using the postcar
funtions provided in postcar_loader.c.
TEST=Build and boot kunimitsu, dram initialization done.
ramstage is loaded.
Change-Id: I8d943e29b6e118986189166d92c7891ab6642193
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/16315
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
It is very useful to have the ability to see I2C transactions
performed by the host firmware. This patch adds a simple
Kconfig option that will enable debug output.
Change-Id: I55f1ff273290e2f4fbfaea56091b2df3fc49fe61
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16590
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This change modifies the lpss_i2c driver to behave more like
the Linux kernel driver. In particular the controller is only
enabled when processing a transaction, and is disabled after.
This means that errors in one transaction will not affect later
transactions.
Also when disabling the controller the code is supposed to wait
on the enable bit in the "enable status" register and not in
the enable control register. In order to get access to this
register the reg map was expanded to include all registers.
This was tested with the cr50 TPM driver to ensure that if a
transaction does fail that it can be successfully retried instead
of the bus being unusable.
Change-Id: I43a546d54996ba0f08550a801927b8f7a6690cda
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16589
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Due to an incorrect value set for the power limit PL1, the
system is not able to leverage full TDP capacity. FSP code
sets the PL1 value as 6W in RAPL MMIO register based on
fused soc tdp value. This RAPL MMIO register is a physically
separate instance from RAPL MSR register. This patch sets
PL1 value to 15W in RAPL MMIO register.
BUG=chrome-os-partner:56524
TEST=Built, booted on reef and verifed the package power
with heavy workload.
Change-Id: Ib344247cd8d98ccce7c403e778cd87c13f168ce0
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/16595
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
|
|
This implements GNVS variable to store the address of PERST_0,
_ON/_OFF methods to power gate PCIe during S0ix entry, and
PERST_0 assertion/de-assertion methods.
BUG=chrome-os-partner:55877
TEST=Suspend and resume using 'echo freeze > /sys/power/state'.
System should resume with PCIE and wifi functional.
Change-Id: I9f63ca0b8a6565b6d21deaa6d3dfa34678714c19
Signed-off-by: Vaibhav Shankar <vaibhav.shankar@intel.com>
Reviewed-on: https://review.coreboot.org/16351
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
The code was not previously initializing the GNVS structure
to all 0's in the ACPI write tables path. Fix this and also
rearrange the ordering of updating the fields to only handle
the chip_info specific bits till last such that most of the
structure is filled in prior to bailing out in the case of a
bad devicetree.
Change-Id: I7bdb305c6b87dac96af35b0c3b7524a17ce53962
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/16597
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Andrey Petrov <andrey.petrov@intel.com>
Reviewed-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This driver is only a prototype driver, real driver
will be integrated at a later time.
Testing: booted successfully.
Change-Id: I372764962e96e5c9c827d524bc369978c5c1fda8
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/16554
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Testing: booted successfully.
Change-Id: I003f6929b00476d46be931773cd35418fe6622a6
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/15529
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Testing: booted successfully.
Change-Id: Ie9c9297f321c838f86e5536aab29f67a0eeb053d
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/15519
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
This driver uses BootROM callback to read and write
to the nvm using I2C.
Testing: booted successfully.
Change-Id: I8639af3e004f6631d7e596507c106159835f979f
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/16161
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
A2BUS is a custom fabric.
Testing: booted successfully.
Change-Id: If6e61f5aa30217eb601ac460d9306166b8433569
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/15523
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
Testing: booted successfully.
Change-Id: I168206585f403d2259efe424e563982be661df0b
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/16149
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
|
APMU is the AP power management unit.
It is a separate processor that handles enabling
individual power rails.
This driver handles sending and receiving commands
from/to APMU.
Testing: booted successfully.
Change-Id: I5ae07849f8432bece8a0ae9066a3f786e6e8d2fe
Signed-off-by: Hakim Giydan <hgiydan@marvell.com>
Reviewed-on: https://review.coreboot.org/15518
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
|
