Currently the code considers the absence of the NVRAM firmware
rollback space a a trigger for invoking the TPM factory initialization
sequence.
Note that the kernel rollback and MRC cache hash spaces are created
after the firmware rollback space. This opens an ever so narrow window
of opportunity for bricking the device, in case a startup is
interrupted after firmware space has been created, but before kernel
and MRC hash spaces are created.
The suggested solution is to create the firmware space last, and to
allow for kernel and MRC cache spaces to exist during TPM factory
initialization.
BRANCH=none
BUG=chrome-os-partner:59654
TEST=odified the code not to create the firmware space, wiped out the
TPM NVRAM and booted the device. Observed it create kernel and
MRC cache spaces on the first run, and then reporting return code
0x14c for already existing spaces on the following restarts.
Verified that the device boots fine in normal and recovery modes
and TPM NVRAM spaces are writeable in recovery mode.
Change-Id: Id0e772448d6af1340e800ec3b78ec67913aa6289
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/17398
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Currently the tlcl_define_space() function returns the same error
value for any non-zero TPM response code. The thing is that the caller
might want to allow attempts to re-create existing NVRAM spaces. This
patch adds a new API return value to indicate this condition and uses
it as appropriate.
BRANCH=none
BUG=chrome-os-partner:59654
TEST=for test purposes modified the code not to create the firmware
space, wiped out the TPM NVRAM and booted the device. Observed it
create kernel and MRC index spaces on the first boot and then
reporting return code 0x14c for already existing spaces on the
following restarts.
Change-Id: Ic183eb45e73edfbccf11cc19fd2f64f64274bfb2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/17422
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
acpigen_write_if_lequal is used to generate ACPI code to check if two
operands are equal, where operand1 is an ACPI op and operand2 is an
integer. Update name of function to reflect this and fix code to write
integer instead of emitting byte for operand2.
TEST=Verified by disassembling SSDT on reef that ACPI code generated for
If with operand2 greater than 1 is correct.
If ((Local1 == 0x02))
{
Return (0x01)
}
Else
{
Return (Buffer (One)
{
0x00 /* . */
})
}
Change-Id: If643c078b06d4e2e5a084b51c458dd612d565acc
Reported-by: Naresh G Solanki <naresh.solanki@intel.com>
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17421
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit 83df672d2c.
It's based on the assumption that the H8 keeps its configuration
during a suspend/resume cycle. User reports indicate that this might
not be true.
Caching the settings in a cbtable entry might be a better approach.
Change-Id: Ic4ba862ee7068ffe214c2aeaadecb4390a0e0529
Reviewed-on: https://review.coreboot.org/17411
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Alexander Couzens <lynxis@fe80.eu>
BIOS needs to ensure that SPI write does not cross 256-byte
boundary. Else, if the write is across 256-byte boundary, then it
corrupts the block by wrapping write to start of current block. Thus,
ensure nuclear_spi_{read,write} operate within a single 256-byte block
only at a time.
BUG=chrome-os-partner:59813
BRANCH=None
TEST=Verified that elog writes do not corrupt the event log when write
is across 256-byte blocks.
Change-Id: I854ca2979d65b9f1232f93182cb84d4dee4f4139
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17419
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Replace the use of the old device_t definition inside
northbridge/via/vx800.
Change-Id: I14a2b4d847f8aeb327d90f385dea998779fae24f
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17316
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/via/cx700.
Change-Id: I6e25f898ab55ee959f1b3b8aba9616c3ba18986d
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17315
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/intel/i855.
Change-Id: Iae66d1ef838095a560868d9c9ff81f4208f814f1
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17314
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
northbridge/amd/agesa/family10.
Change-Id: I5723e217fc739ab576cbe3a1ee6d92023190267c
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17313
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
mainboard/via/vt8454c.
Change-Id: I94e22e1d814733c4049e78e5b3c23b9bb429f6fa
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17312
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
mainboard/via/epia-m700.
Change-Id: I7a16a9f396d50279cf2bd13de72bd78e8f53f7d8
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17311
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
mainboard/via/epia-cn.
Change-Id: I1b05abcedc427e4876e1fdab85298015308a3d17
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17310
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Replace the use of the old device_t definition inside
mainboard/tyan/s8226.
Change-Id: I41729fc03518a7804ae224c773967453a7ab60a7
Signed-off-by: Antonello Dettori <dev@dettori.io>
Reviewed-on: https://review.coreboot.org/17309
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
- Move members of struct edid to struct edid_mode
- Change `u32 pmmio` to `u8 *pmmio` in i915_lightup_sandy
Change-Id: Id64daf5eae1d4d8265105067b2e6ae55786a5638
Signed-off-by: Iru Cai <mytbk920423@gmail.com>
Reviewed-on: https://review.coreboot.org/17332
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
This is more consistent with other Intel GMCH code.
Change-Id: I7bfaa79b9031e2dcc5879a607cadacbdd22ebde7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17405
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
The TPM spaces created by the RO need to have different attributes
depending on the space's use. The firmware rollback counter and MRC
hash spaces are created by the RO code and need to be protected at the
highest level: it should be impossible to delete or modify the space
once the RO exits, and it is how it is done before this patch.
The rest of the spaces should be possible to modify or recreate even
after the RO exits. Let's use different set of NVRAM space attributes
to achieve that, and set the 'pcr0 unchanged' policy only for the
firmware counter and MRC cache spaces.
The definitions of the attributes can be found in "Trusted Platform
Module Library Part 2: Structures", Revision 01.16, section "13.2
TPMA_NV (NV Index Attributes)."
CQ-DEPEND=CL:410127
BRANCH=none
BUG=chrome-os-partner:59651
TEST=verified that the reef system boots fine in both normal and
recovery modes; using tpmc confirmed that firmware, kernel and
MRC cache NVRAM spaces are readable in both and writeable only in
recovery mode.
Change-Id: I1a1d2459f56ec929c9a92b39175888b8d1bcda55
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/17388
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
The Kconfig symbol CONSOLE_SERIAL_TEGRA210_UART_CHOICES was attached to
a choice, and isn't used anywhere. Remove it as unnecessary.
Change-Id: I4efd2e43ac34b266db0d40d1bc8c123bd377b3a2
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17391
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This patch adds punit initialization code after
FspMemoryInit so that turbo can be initialized after
that.
BUG=chrome-os-partner:58158
BRANCH=None
Change-Id: I4939da47da82b9a728cf1b5cf6d5ec54b4f5b31d
Signed-off-by: Shaunak Saha <shaunak.saha@intel.com>
Reviewed-on: https://review.coreboot.org/17203
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
To avoid garbage display in firmware on warm reset, we need
to enable eDP display in depthcharge instead when the framebuffer is
cleared.
Therefore limit edp_enable() in coreboot to just configure eDP,
and leave enabling the display to depthcharge.
CQ-DEPEND=CL:402071
BUG=chrome-os-partner:58675
BRANCH=none
TEST=Boot from kevin, and display work
Change-Id: I9d937ead33ebba58e33e02fd73b80d6e11bb69aa
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 38b0d18c3fae37dfccb18fe809f763b98703167c
Original-Change-Id: Ibbc283a5892b98f4922f02fd67465fe2e1d01b71
Original-Signed-off-by: Lin Huang <hl@rock-chips.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/402095
Original-Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/17207
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
This patch reduces the thermal time window to 100 milliseconds
for fast throttling action at prochot.
BUG=chrome-os-partner:59397
BRANCH=None.
TEST=Built for skylake platform and verified the thermal time
window value.
Change-Id: If79d213cb8e19277ffdb882267d2f8672df93446
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Reviewed-on: https://review.coreboot.org/17384
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This variable can be set in a debugger (e.g. Spike)
to finely control which traps go to coreboot and
which go to the supervisor.
Change-Id: I292264c15f002c41cf8d278354d8f4c0efbd0895
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17404
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
The riscv 1.9 standard defines a textual config string to be passed
to kernels and hypervisors. Change the payload function to pass
this string in a0.
Change-Id: I3be7f1712accf2d726704e4c970f22749d3c3f36
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17254
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
These functions will allow us to remove hardcodes,
as long as we can verify the qemu and lowrisc targets
implement the configstring correctly. Hence, for the
most part, we'll start with mainboard changes first.
Define a new config variable, CONFIG_RISCV_CONFIGSTRING,
which has a default value that works on all existing
systems but which can be changed
as needed for a new SOC or mainboard.
Change-Id: I7dd3f553d3e61f1c49752fb04402b134fdfdf979
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17256
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschäfer <j.neuschaefer@gmx.net>
I've tested this with commits to come later.
This is from the lowrisc bbl distribution, 87588c4,
with fixes so it builds.
Change-Id: I87893638872259c94d6972e1971578b633155e7e
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17255
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The end of firmware notification is currently not being tracked
so it's hard to get good data on how long it takes. Update the
code to provide timestamp data as well as post codes.
BUG=chrome-os-partner:56656
Change-Id: I74c1043f2e72d9d85b23a99b8253ac465f62a7f2
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17373
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>
Reviewed-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
If the boot media is memory mapped temporarily mark it as write
protect MTRR type so that memory-mapped accesses are faster.
Depthcharge payload loading was sped up by 75ms using this.
BUG=chrome-os-partner:56656,chrome-os-partner:59682
Change-Id: Iba87a51a05559d81b8e00fa4f6824dacf7a661f5
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17372
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>
Certain platforms have a poorly performing SPI prefetcher so even if
accessing MMIO BIOS once the fetch time can be impacted. Payload
loading is one example where it can be impacted. Therefore, add the
ability for a platform to reconfigure the currently running CPU's
variable MTRR settings for the duration of coreboot's execution.
The function mtrr_use_temp_range() is added which uses the previous
MTRR solution as a basis along with a new range and type to use.
A new solution is calculated with the updated settings and the
original solution is put back prior to exiting coreboot into the OS
or payload.
Using this patch on apollolake reduced depthcharge payload loading
by 75 ms.
BUG=chrome-os-partner:56656,chrome-os-partner:59682
Change-Id: If87ee6f88e0ab0a463eafa35f89a5f7a7ad0fb85
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17371
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>
The default register count calculations are leading to higher
frequencies than expected. Provide an alternative method for
calculating the register counts by utilizing the rise and
fall times of the bus. If the rise time is supplied the
rise/fall time values are used, but the register overrides
take precedence over the rise/fall time calculation. This
allows platforms to choose whichever method works the best.
BUG=chrome-os-partner:58889
Change-Id: I7747613ce51d8151848acd916c09ae97bfc4b86a
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17350
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Since tlcl library is used other than just vboot driver, ensure that the
library is initialized only once per stage.
BUG=chrome-os-partner:59355
BRANCH=None
TEST=Verified in recovery mode on reef, tlcl library is initialized only
once in romstage.
Change-Id: I6245fe9ed34f5c174341b7eea8db456b45113287
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17364
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
commit 80EF7B7 [IT8772F: Clean up it8772f includes and add a LED API]
broke power LED operation when it incorrectly transferred
values from the old function (it8772f_gpio_setup) to the new one (
it8772f_gpio_led). Restore the correct values so power LED illuminates
when powered on.
Change-Id: I99a38351bb52063fafa7436e6397a8da7fc1e952
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17266
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
This function is not used anywhere else in the code.
BRANCH=none
BUG=none
TEST=reef and kevin boards (using tpm1.2 and tpm2.0 respectively)
build successfully.
Change-Id: Ifcc345ae9c22b25fdcfc2e547e70766021d27e32
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/17387
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Have a common romstage.c file to prepare CAR stack guards.
MTRR setup around cbmem_top() is somewhat northbridge specific,
place stubs under northbridge for platrform that will move
to RELOCATABLE_RAMSTAGE.
Change-Id: I3d4fe4145894e83e5980dc2a7bbb8a91acecb3c6
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15762
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix regression, S3 resume not working on sandy/ivy after commit
9d6f365 ACPI S3: Remove HIGH_MEMORY_SAVE where possible
There is some 20ms delay with ACPI S3 wakeup time due to MTRR setup
being done after the backup copy. Moving to RELOCATABLE_RAMSTAGE fixes
this delay by removing need of this backup entirely.
Change-Id: Ib72ff914f5dfef8611f5f6cf9687495779013b02
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/15248
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Maxim98357a speaker amp requires BCLK & SFRM to be active
and stable before it is unmuted. If there is a BLCK and no
SFRM, it results in a pop sound.
sdmode_delay property already exists which facilitates this
configuration. This patch updates "sdmode_delay" to avoid
pop sound.
BUG=chrome-os-partner:59034
BRANCH=master
TEST=emerge-snappy coreboot chromeos-bootimage
Change-Id: Ic9095ae6812ba822c760229e69f5b27c6c244cdf
Signed-off-by: Wisley Chen <wisley.chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/17361
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Snappy is using APL SoC SKU's with 6W TDP max. As Reef,
the energy calculation is wrong with the current VR solution.
Experiments show that SoC TDP max (6W) can be reached
when RAPL PL1 is set to 12W.
Therefore, we've inserted 12W override after reading the fused value (6W)
so that the system can reach the right performance level.
BUG=chrome-os-partner:59034
BRANCH=master
TEST=emerge-snappy coreboot chromeos-bootimage
Change-Id: Idd702077cd05e2b43823542cb804b2d4b42f7116
Signed-off-by: Wisley Chen <wisley.chen@quantatw.com>
Reviewed-on: https://review.coreboot.org/17362
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Vadim Bendebury