Having same memory region set as both WRPROT and WRBACK
using MTRRs is undefined behaviour. This could happen if
we allow DCACHE_RAM_BASE to be located within CBFS in SPI
flash memory and XIP romstage is at the same location.
As SPI master by default decodes all of top 16MiB below
4GiB, initial cache-as-ram line fills may have actually
read from SPI flash even in the case DCACHE_RAM_BASE was
below the nominal 4GiB - ROM_SIZE.
There are no reasons to have this as board-specific setting.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17806
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I2cce80731ede2e7f78197d9b0c77c7e9957a81b5
Reviewed-on: https://chromium-review.googlesource.com/422239
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Select this to provide menu in menuconfig to add flash
descriptor file. ME or GbE firmwares themselves are not
required, but integrated NIC MAC and SPI configuration
fields are still useful.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17805
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: I14b86e2f38ec39924d2cbf0932d82f66ed356a03
Reviewed-on: https://chromium-review.googlesource.com/422238
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Just before jumping to OS wakeup vector do the same
tasks to signal coreboot completion that would be done
before entry to payload on normal boot path.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Kysti Mlkki <kyosti.malkki@gmail.com>
Reviewed-on: https://review.coreboot.org/17794
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: I7514c498f40f2d93a4e83a232ef4665f5c21f062
Reviewed-on: https://chromium-review.googlesource.com/422236
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
RISCV requires that timer interrupts be handled in machine
mode and delegated as necessary. Also you can only reset the
timer interrupt by writing to mtimecmp. Further, you must
write a number > mtime, not just != mtime. This rather clumsy
situation requires that we write some value into the future
into mtimecmp lest we never be able to leave machine mode as
the interrupt either is not cleared or instantly reoccurs.
This current code is tested and works for harvey (Plan 9)
timer interrupts.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Ronald G. Minnich <rminnich@gmail.com>
Reviewed-on: https://review.coreboot.org/17807
Tested-by: build bot (Jenkins)
Reviewed-by: Jonathan Neuschfer <j.neuschaefer@gmx.net>
Change-Id: I8538d5fd8d80d9347773c638f5cbf0da18dc1cae
Reviewed-on: https://chromium-review.googlesource.com/422235
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This reverts commit c86da67436.
Alas, I have to disagree with this in every single line. The comment
added to the top of the file only applies to a single function therein
which sits over a hundred lines below. That's not much helpful. More-
over, the link in the comment is already down ofc.
The comment is also irritating as it doesn't state in which way (enco-
ding!) it applies to the code, which presumably led to the wrong in-
terpretation of the IDs.
At last, if anything should have changed it is the strings, the IDs
are resolved to. `smbios_fill_dimm_manufacturer_from_id()` has to
resolve the IDs it gets actually fed and not a random selection from
any spec.
Since I digged into it, here's why the numbers are correct: The func-
tion started with the SPD encoding of DDR3 in mind. There, the lower
byte is the number of a "bank" of IDs with an odd-parity in the upper
most bit. The upper byte is the ID within the bank. The "correction"
was to clear the parity bit for naught. The function was later exten-
ded with IDs in the DDR2-SPD encoding (which is actually 64-bit not
16). There, a byte, starting from the lowest, is either an ID below
127 plus odd-parity, or 127 which means look in the next byte/bank.
Unused bytes seem to be filled with 0xff, I guess from the 0xff2c.
BUG=None
BRANCH=None
TEST=None
Reviewed-on: https://review.coreboot.org/17873
Tested-by: build bot (Jenkins)
Reviewed-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-by: HAOUAS Elyes <ehaouas@noos.fr>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: Icdb48e4f2c102f619fbdca856e938e85135cfb18
Reviewed-on: https://chromium-review.googlesource.com/422234
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Currently only there is only one eaglelake board in coreboot
(ga-g41m-es2l) featuring a G41 variant northbridge.
Adding boards with a different variant (Q43, Q45, G43, G45, B43) will
require this change for graphic initialisation.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17900
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ida32c563a99576b66685dfdadf9a534fd6e197dc
Reviewed-on: https://chromium-review.googlesource.com/422233
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
ELAN touchscreen device expects firmware to export GPIOs and ACPI
regulators for managing power to the device. Thus, provide the
required ACPI elements for OS driver to properly manage this device.
BUG=chrome-os-partner:60194
BRANCH=None
TEST=Verified that touchscreen works properly on boot-up and after
suspend/resume.
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17799
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I298ca5de9c0ae302309d87e3dffb65f9be1e882e
Reviewed-on: https://chromium-review.googlesource.com/422232
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change the Carrizo settings used for Bettong to ones specific
to Stoney on Gardenia.
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: Marc Jones <marcj303@gmail.com>
(cherry picked from commit e99b2c7e2c913413fdc83ad37c5519837a38c7fb)
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17225
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I4376421c8c08dab9d7ff1428993eed3978e89657
Reviewed-on: https://chromium-review.googlesource.com/422228
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Remove a duplicated check and setting for xHCI during the
AMD_INIT_RESET callout. This is handled by the wrapper. Also
remove nearby commented code. EcChannel0 is not a member of
FCH_RESET_DATA_BLOCK.
Leave the check in AMD_INIT_ENV. Although AGESA honors what
was previously requested, additional settings depend on the
state of Usb.Xhci0Enable.
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: Marc Jones <marcj303@gmail.com>
(cherry picked from commit ca862fbacbe80b1345ad6f23262a9769f05c50fd)
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17223
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I45a5123e158cd7399d6d286999371d4a0e0fa963
Reviewed-on: https://chromium-review.googlesource.com/422226
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Gardenia makes no special considerations for a board_id regarding
SPD access and addressing. Remove this from the source and use
the standard AGESA call.
Make SPD address changes to devicetree.cb. Note that Gardenia is
designed to be a two channel, single DIMM/channel system (some SKUs
with two DIMMs on the second channel). However, this port is for
the Stoney processor which is a single channel. As a result, the
second DIMM slot is not usable. A future improvement could involve
a port using a different processor, with unique devicetree files
for each.
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
Original-Reviewed-by: Marc Jones <marcj303@gmail.com>
(cherry picked from commit 77511f98f819dfe08c3ed16ebc11e1b328bdca15)
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17219
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: Id00c2be83340ceeec043ec86e96779e6bf46ae7b
Reviewed-on: https://chromium-review.googlesource.com/422222
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use bettong as the reference for the gardenia mainboard.
Update makefiles etc so it builds.
This patch intentionlly keeps the carrizo_fch.asl file to
remain synchronized with the AMD PI package.
Remove items that do not apply to the Stoney APU, rewrite the
comments associated with the PCIe devices, and fix up the
SPD register association to match the 00670F00 chip.h.
Original-Signed-off-by: Marc Jones <marcj303@gmail.com>
Original-Signed-off-by: Marshall Dawson <marshalldawson3rd@gmail.com>
(cherry picked from commit 82accfcf9ec76a042156fb6e528f7900987b6e7e)
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Marc Jones <marcj303@gmail.com>
Reviewed-on: https://review.coreboot.org/17218
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I014fec5c99c01fc02e129be514b704c8ba27d464
Reviewed-on: https://chromium-review.googlesource.com/422221
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Enable default acpi path PCI0.LPCB if TPM support is
selected in the kconfig system and the acpi path is not set via
acpi_name callback in the platform code.
Thanks to Aaron Durbin for providing this fix.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/17855
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Idb56cafe71efc8a52eee5a5a663478da99152360
Reviewed-on: https://chromium-review.googlesource.com/422220
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add custom files for Sandybridge and IvyBridge functions.
Move only the minimal required functions into separate files.
Both files' functions are going to call raminit_common functions.
No functionality is changed.
Sandybridge code path tested on Lenovo T420.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/17605
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I1b1dfbd0857b59d3ae4392b73c033ee7a5aed243
Reviewed-on: https://chromium-review.googlesource.com/422218
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Sometime preram cbmem logs are truncated due to lack of
space (default preram cbmem console size is 0xc00).
Provide Kconfig option to configure preram cbmem console
size so that mainboard can configure it to required value.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Reviewed-on: https://review.coreboot.org/17839
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Change-Id: I221d9170c547d41d8bd678a3a8b3bca6a76ccd2e
Reviewed-on: https://chromium-review.googlesource.com/422216
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add power management type config option that allows mainboards to
either:
1. Define a power resource that uses the reset and enable gpios to
power on and off the device using _ON and _OFF methods, or
2. Export reset and enable GPIOs in _CRS and _DSD so that the OS can
directly toggle the GPIOs as required.
GPIO type needs to be updated in drivers_i2c_generic_config to use
acpi_gpio type so that it can be used for both the above cases.
BUG=chrome-os-partner:60194
BRANCH=None
TEST=Verified that elan touchscreen works fine on reef using exported
GPIOs.
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17797
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I4d76f193f615cfc4520869dedc55505c109042f6
Reviewed-on: https://chromium-review.googlesource.com/422214
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
I've recently added an assertion to ensure that the effective I2C
frequency on Rockchip SoCs is not too far off the 400KHz target due to
divisor rounding errors. A 10KHz margin worked fine for RK3399, but it
turns out that RK3288 actually only ever hit 387KHz since its I2C clocks
are based off the already pretty low 75MHz PCLKs. While we could
probably change the PCLKs to make this closer, that seems like a too
intrusive change for something that has already worked just fine for
years, so just loosen the restriction a little more instead.
BRANCH=None
BUG=chromium:675043
TEST=None
Change-Id: I7e96a1a75b38f8ad3971dd33046699cceb17b80d
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/421095
Reviewed-by: Randall Spangler <rspangler@chromium.org>
It was unsigned, not a good place to be for testing < 0.
Change-Id: I126fe86422900bbae2c3ca16052be27985cfed53
Original-Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Found-by: Coverity Scan #1241911
Original-Reviewed-on: https://review.coreboot.org/17888
Original-Reviewed-by: Nico Huber <nico.h@gmx.de>
Original-Tested-by: build bot (Jenkins)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/421220
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Enable the actual touch devices to be probed by the kernel
and remove the placeholder devices that I put in before
and were used for initial bringup.
BUG=chrome-os-partner:58666
TEST=tested on eve
Change-Id: I7fc6f9da83b1abbae6dd069f759b220d59153d1c
Original-Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/17896
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Original-Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/421210
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
When trying to bring up a device with a malfunctioning TPM2 chip, the
driver currently gets stuck waiting for SPI flow control, causing
bricked devices.
This patch puts a 100 ms cap on the waiting time - this should be
enough even for a longest NVRAM save operation which could be under
way on the TPM device.
BRANCH=gru
BUG=chrome-os-partner:59807
TEST=with a matching change in depthcharge, now a gru with corrupted
SPI TPM comes up to the recovery screen (it was not showing signs
of life before this change).
Change-Id: I63ef5dde8dddd9afeae91e396c157a1a37d47c80
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://review.coreboot.org/17898
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Original-Tested-by: build bot (Jenkins)
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/421209
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Put the UART pins into native mode in bootblock so they are not
floating when we try to communicate with H1 over I2C. Without
a serial console enabled BIOS these pins were not configured
until ramstage.
BUG=chrome-os-partner:60935
BRANCH=None
TEST=Boot Eve board without serial console and H1 TPM enabled
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17893
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I30f3bf0bacc1bbd776b351a9c09748b0601c39bc
Reviewed-on: https://chromium-review.googlesource.com/421173
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add a generic I2C-HID driver for these types of devices that
do not need extra functionality. This allows a new device to
be added without having to write a new driver.
The i2c-hid PNP0C50 is automatically added as the _CID for the
device in the ACPI Device.
BUG=chrome-os-partner:58666
BRANCH=None
TEST=used on eve to describe a new i2c-hid touch controller
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17856
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: I94e9531a72f9bf1d6b3ade362b88883b21b83d0a
Reviewed-on: https://chromium-review.googlesource.com/421172
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The Roda Lizard RV11 is a comparatively lightweight, full-rugged
notebook. It's based on a 17W TDP dual core Ivy Bridge CPU.
The Lizard RW11 is its bigger brother (45W TDP quad core, more i/o
options).
The RV11 is the first board to use the native graphics initialization
by libgfxinit. Tested so far, are the internal eDP port, DP and VGA.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Dennis Wassenberg <dennis.wassenberg@secunet.com>
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/17446
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: Iea283059ce3402dc36184baf16928b55285a9eeb
Reviewed-on: https://chromium-review.googlesource.com/421171
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Checking for memory self refresh can generate false positives,
as explained in faa6beb: "northbridge/intel/i945:
CHECK_SLFRCS_ON_RESUME Kconfig option".
This seems to be the case for this motherboard.
TESTED on ga-945gcm-s2l.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/17617
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: Iadf0a73b054470b652e1dc02557fb1715131f823
Reviewed-on: https://chromium-review.googlesource.com/421169
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The type3 SMBIOS table has a non-optional SKU field at the end,
which causes a parsing error when missing. Add but do not populate it.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17851
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I988d0626b8680740697e1db58eb6d0b87874bfde
Reviewed-on: https://chromium-review.googlesource.com/421168
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
ToString() requires the input buffer data to be null-terminated,
but the data returned by the EC is not, leading Windows to fail
to report any battery data at all. Correct this by concatenating
a null terminator (0x00) to the end of the buffer data before
inputting to ToString() where needed
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17783
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Change-Id: Ic86048d1d6354b9b0dac3c8957df318d0825c905
Reviewed-on: https://chromium-review.googlesource.com/421167
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
For Chrome OS the normal MRC cache should be cleared when a hardware
retrain recovery request is observed. The reason is that since there
are 2 different MRC cache slots there needs to be a mechanism which
allows an end user make a system bootable again if the MRC settings
happen to not allow the system to boot any longer. Therefore, one
just needs to enter recovery with the hardware retrain flag and
the system normal MRC cache slot will be invalidated.
BUG=chrome-os-partner:60592
BRANCH=reef
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17871
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: I6ad32ed0dd217d66404b77467a88689a06044544
Reviewed-on: https://chromium-review.googlesource.com/421030
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Allow a board/platform to invalidate the normal MRC cache when
hardware retraining is requested in recovery mode. A small 4 byte
payload is used to update the latest data written. It will of course
fail on MRC cache retreival on next usage.
BUG=chrome-os-partner:60592
BRANCH=reef
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17870
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ic88cd66802664813562d003f50d54e4a4ea375ef
Reviewed-on: https://chromium-review.googlesource.com/421029
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The EC switches, including the hardware retrain flag, are
cleared when handing off the vboot state in romstage. However,
one may still want to query the state of the hardware retrain
flag. Thus, add a method to get the flag from cbmem.
BUG=chrome-os-partner:60592
BRANCH=reef
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17869
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Change-Id: Ic76cfb3255a8d3c179d5f8b13fa13c518f79faa2
Reviewed-on: https://chromium-review.googlesource.com/421028
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
The cbmem_possibly_online() is a helpful construct. Therefore,
push it into cbmem.h so other users can take advantage of it.
BUG=chrome-os-partner:60592
BRANCH=reef
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17868
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: If5a1c7815ed03874dcf141014b8ffefb82b7cc92
Reviewed-on: https://chromium-review.googlesource.com/421027
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
VARIANT_DIR is defined in coreboot/Makefile.inc, so doesn't need to be
defined in each mainboard.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/17841
Tested-by: build bot (Jenkins)
Reviewed-by: Nico Huber <nico.h@gmx.de>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: Ic93957b710e4a9863774de7fcf3bd006696b6aa1
Reviewed-on: https://chromium-review.googlesource.com/421006
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Remove any assumptions required for the drivers using i2c_generic to
have drivers_i2c_generic_config structure at the start of the driver
config. Instead pass in a pointer to drivers_i2c_generic_config from
the calling driver.
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17857
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Change-Id: I51dc4cad1c1f246b51891abf7115a7120e87b098
Reviewed-on: https://chromium-review.googlesource.com/420845
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
ToString() requires the input buffer data to be null-terminated,
but the data returned by the EC is not, leading Windows to fail
to report any battery data at all. Correct this by concatenating
a null terminator (0x00) to the end of the buffer data before
inputting to ToString().
BUG=None
BRANCH=None
TEST=None
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Reviewed-on: https://review.coreboot.org/17782
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Change-Id: I4fdbf97e9b75030374dffc99a954dd9faa6a5209
Reviewed-on: https://chromium-review.googlesource.com/420844
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Update the mrc cache implementation to use region_file. Instead
of relying on memory-mapped access and pointer arithmetic
use the region_devices and region_file to obtain the latest
data associated with the region. This removes the need for the
nvm wrapper as the region_devices can be used directly. Thus,
the library is more generic and can be extended to work on
different boot mediums.
BUG=chrome-os-partner:56151
BRANCH=None
TEST=None
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/17717
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: Ic14e2d2f7339e50256b4a3a297fc33991861ca44
Reviewed-on: https://chromium-review.googlesource.com/420843
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
In the case where the RTC is initialized after the battery is
completely drained the bits for power_mode and cof_selection are set up
with wrongly applied masks.
In the case where the RTC is re-initialized again with no power-loss
after the last initialization the bits for cap_sel, power_mode and
cof_selection are not shifted to the right position.
Both errors lead to a wrong initialization of the RTC and in turn to a
way larger current consumption (instead of 120 nA the RTC current rises
to over 2 A).
This patch fixes both errors and the current consumption is in the right
range again.
TEST=booted mc_bdx1 and verified current consumption of RTC
BUG=None
BRANCH=None
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/17829
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Martin Roth <martinroth@google.com>
Change-Id: I8594f6ac121a175844393952db2169dbc5cbd2b2
Reviewed-on: https://chromium-review.googlesource.com/420842
Commit-Ready: Furquan Shaikh <furquan@chromium.org>
Tested-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
