The chip PCA9538 is a 8 bit I/O expander connected to the systems I2C
bus. Add a chip driver to support this chip.
Beside the pure chip driver two interface functions are provided to read
the state of the pins and write output values to the pins.
As the slave address of this chip is hardware configurable the function
pca9538_get_dev() is used to get the right slave address. This function
needs to be implemented in mainboard code if one needs to use the
interface functions to read and write I/O state.
Change-Id: Ic856123b4f4c8b721928ee3a2a4bb37833ea4b20
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/23748
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
The designware i2c controller indicates that the slave address
shouldn't be programmed while the controller is enabled. Therefore,
switch the ordering of the slave target address and the enable.
Additionally, ensure the controller is disabled prior to the
start of the slave programming sequence.
Lastly, chunk up the i2c_msg segments at differing slave address
boundaries. That allows for simpler programming for the controller
by only doing one slave address transaction chunk at a time.
BUG=b:70232394,b:69250772
Change-Id: Iebc08e2db847cb182fad98e0ff3d799b9a64aca7
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23513
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
To set address on AMD, IC_ENABLE == 0.
BUG=b:69416132
BRANCH=none
TEST=Test communication with i2c TPM on grunt and coral
Change-Id: I7faee8e11439deceab946cc82d30d274b529b90d
Signed-off-by: Chris Ching <chingcodes@chromium.org>
Reviewed-on: https://review.coreboot.org/23293
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Grunt (a amd-stoneyridge based platform) uses a GPIO to interface with
the tpm. This change allows devicetree entries to use a irq_gpio entry
to describe the interface with the TPM.
BUG=b:72655090
Change-Id: I08289891408d7176f68eb9c67f7a417a2448c2de
Signed-off-by: Justin TerAvest <teravest@chromium.org>
Reviewed-on: https://review.coreboot.org/23500
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Right now dw_i2c_get_soc_cfg() is expecting the SoC to implement
that callback for obtaining the bus config. However, we're currently
forcing another parameter of struct device so one can do the lookup.
This works for Intel-based systems since the struct device was needed
to program the BAR, etc. However, from an API standpoint, it just
complicates matters by needing to obtain the struct device. The SoC
already has knowlege of its own devices so it can get the config
itself by bus number. Therefore, remove that contraint from the API.
BUG=b:70232394
Change-Id: Id8558f5deedda0963a46a532a7bf984e168fb270
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23420
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In ramstage the device_operations are needed for the i2c designware
host controller. Move the intel/common/block/i2c implementation
into the generic driver so other platforms can take advantage of it.
BUG=b:72121803
Change-Id: Id249933fadcc016bfba00e7a6d65f56dfc220724
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23372
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
If one wants to implement both i2c_bus.h and i2c_simple.h APIs
the compilation unit needs to be guarded or coordinated carefully
with different compilation units. Instead, name the i2c_bus
functions with _dev such that it indicates that they operate on
struct device. One other change to allow i2c_bus.h to be built in
non-ramstage environments is to ensure DEVTREE_CONST is used for
the dev field in struct bus.
BUG=b:72121803
Change-Id: I267e27e62c95013e8ff8b0728dbe9e7b523de453
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/23370
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Furquan Shaikh <furquan@google.com>
* Move code from src/lib and src/include into src/security/tpm
* Split TPM TSS 1.2 and 2.0
* Fix header includes
* Add a new directory structure with kconfig and makefile includes
Change-Id: Id15a9aa6bd367560318dfcfd450bf5626ea0ec2b
Signed-off-by: Philipp Deppenwiese <zaolin@das-labor.org>
Reviewed-on: https://review.coreboot.org/22103
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The Cr50 i2c driver provides separate entry points for probing and
initialization, but probing function does not really do much.
It also claims and releases locality on every coreboot stage, but
there is no need for this - locality should be definitely claimed
after reset and then it could be retained through the boot process.
On top of that the driver does not properly account for long time it
could take the Cr50 chip to come around to reset processing if TPM
reset request was posted during a lengthy TPM operation.
This patch addresses the issues as follows:
- tpm_vendor_probe() and tpm_vendor_cleanup() become noops, kept
around to conform to the expected driver API.
- tpm_vendor_init() invokes a function to process TPM reset only in
the first stage using TPM (typically verstage), the function
checks if locality is claimed and if so - waits for it to be
released, which indicates that TPM reset processing is over.
- before claiming locality check if it is already taken, and if so -
just proceed.
BRANCH=none
BUG=b:65867313, b:68729265
TEST=Verified that reef no longer hangs during EC reboot and
firmware_Cr50ClearTPMOwner (not yet merged) tests.
Change-Id: Iba8445caf1342e3a5fefcb2664b0759a1a8e84e3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://review.coreboot.org/22554
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
In case the TPM is doing a long crypto operation the initial probe
could be very delayed. Rather than end up in recovery make the delay
long enough to accommodate the (current) long crypto times.
BUG=b:65867313, b:68729265
TEST=Verified that Soraka no longer hangs during EC reboot test.
Change-Id: I3bccff70e001dfc065c24be8ad34ef239a144db1
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/22379
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Some Siemens copyright entries incorrectly contain a dot at the end of
the line. This is fixed with this patch.
Change-Id: I8d98f9a7caad65f7d14c3c2a0de67cb636340116
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/22355
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
There's no reason to mutate the struct device when determining
the ACPI name for a device. Adjust the function pointer
signature and the respective implementations to use const
struct device.
Change-Id: If5e1f4de36a53646616581b01f47c4e86822c42e
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/21527
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Subrata Banik <subrata.banik@intel.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This change list adds imon and vmon slot numbers as params for
Maxim 98927 driver. These values are looked up in the kernel driver
to confiure IV feedback for audio playback on speakers.
BUG=b:36724448
TEST=After boot, the register dump for Max98927 codecs should have
imon and vmon slots numbers set in 0x1e register.
Change-Id: I21d72ba91af83782587f11018b2d1d1c8d4f676c
Signed-off-by: Harsha Priya <harshapriya.n@intel.com>
Reviewed-on: https://review.coreboot.org/21195
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
There is at least one I2C device (being used by Soraka) that has 3
controls -- enable, reset and stop. If the stop gpio is not put into
the right state when turning off the device in suspend mode, then it
causes leakage. Thus, we need control in power resource to be able to
stop the device when entering suspend state.
BUG=b:64987428
TEST=Verified on soraka that touchscreen stop is correctly configured
on suspend.
Change-Id: Iae5ec7eb3972c5c7f80956d60d0d3c321bbefb0f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/21249
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Replaces the ics/954309 driver with a more generic version to
accommodate clockgens with a different amount of registers.
It also features a mask to only touch certain bits of the clockgen.
TODO: set appropriate mask for X60/T60 since the datasheets for their
clockgens can be found.
Change-Id: Ie43c4de7891a39f2f443e78213ecd688134e68d7
Signed-off-by: Arthur Heymans <arthur@aheymans.xyz>
Reviewed-on: https://review.coreboot.org/20042
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add support for providing additional free form device properties via
devicetree in order to make this driver suitable for kernel drivers
that need additional board-specific device properties.
This currently allows adding up to 10 additional properties to a device.
BUG=b:63413023
TEST=manual testing to ensure that newly added properties are in SSDT
Change-Id: I2b8ceb208f4aba01053746547def6d07c8f8f3a2
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://review.coreboot.org/21270
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Split `i2c.h` into three pieces to ease reuse of the generic defi-
nitions. No code is changed.
* `i2c.h` - keeps the generic definitions
* `i2c_simple.h` - holds the current, limited to one controller driver
per board, devicetree independent I2C interface
* `i2c_bus.h` - will become the devicetree compatible interface for
native I2C (e.g. non-SMBus) controllers
Change-Id: I382d45c70f9314588663e1284f264f877469c74d
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20845
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Our current struct for I2C segments `i2c_seg` was close to being compa-
tible to the Linux version `i2c_msg`, close to being compatible to SMBus
and close to being readable (e.g. what was `chip` supposed to mean?) but
turned out to be hard to fix.
Instead of extending it in a backwards compatible way (and not touching
current controller drivers), replace it with a Linux source compatible
`struct i2c_msg` and patch all the drivers and users with Coccinelle.
The new `struct i2c_msg` should ease porting drivers from Linux and help
to write SMBus compatible controller drivers.
Beside integer type changes, the field `read` is replaced with a generic
field `flags` and `chip` is renamed to `slave`.
Patched with Coccinelle using the clumsy spatch below and some manual
changes:
* Nested struct initializers and one field access skipped by Coccinelle.
* Removed assumption in the code that I2C_M_RD is 1.
* In `i2c.h`, changed all occurences of `chip` to `slave`.
@@ @@
-struct i2c_seg
+struct i2c_msg
@@ identifier msg; expression e; @@
(
struct i2c_msg msg = {
- .read = 0,
+ .flags = 0,
};
|
struct i2c_msg msg = {
- .read = 1,
+ .flags = I2C_M_RD,
};
|
struct i2c_msg msg = {
- .chip = e,
+ .slave = e,
};
)
@@ struct i2c_msg msg; statement S1, S2; @@
(
-if (msg.read)
+if (msg.flags & I2C_M_RD)
S1 else S2
|
-if (msg.read)
+if (msg.flags & I2C_M_RD)
S1
)
@@ struct i2c_msg *msg; statement S1, S2; @@
(
-if (msg->read)
+if (msg->flags & I2C_M_RD)
S1 else S2
|
-if (msg->read)
+if (msg->flags & I2C_M_RD)
S1
)
@@ struct i2c_msg msg; expression e; @@
(
-msg.read = 0;
+msg.flags = 0;
|
-msg.read = 1;
+msg.flags = I2C_M_RD;
|
-msg.read = e;
+msg.flags = e ? I2C_M_RD : 0;
|
-!!(msg.read)
+(msg.flags & I2C_M_RD)
|
-(msg.read)
+(msg.flags & I2C_M_RD)
)
@@ struct i2c_msg *msg; expression e; @@
(
-msg->read = 0;
+msg->flags = 0;
|
-msg->read = 1;
+msg->flags = I2C_M_RD;
|
-msg->read = e;
+msg->flags = e ? I2C_M_RD : 0;
|
-!!(msg->read)
+(msg->flags & I2C_M_RD)
|
-(msg->read)
+(msg->flags & I2C_M_RD)
)
@@ struct i2c_msg msg; @@
-msg.chip
+msg.slave
@@ struct i2c_msg *msg; expression e; @@
-msg[e].chip
+msg[e].slave
@ slave disable ptr_to_array @ struct i2c_msg *msg; @@
-msg->chip
+msg->slave
Change-Id: Ifd7cabf0a18ffd7a1def25d1d7059b713d0b7ea9
Signed-off-by: Nico Huber <nico.huber@secunet.com>
Reviewed-on: https://review.coreboot.org/20542
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Ensure that the VLF bit will be cleared after a power loss event even if
the stopwatch has expired before the code to clear the bit is reached.
Change-Id: Ib2cfdabf4cd4df834395d6a102c6ae70568e71db
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/20893
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
This excludes files which are mostly spaces, which I felt should be
handled separately.
Change-Id: I33043a3090e2fc6e9d2fd81e8a5e46fb6cb0aa35
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://review.coreboot.org/20731
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
According to the datasheet the RTC needs a power rising slope of no more
than 100µs/V to ensure a correct power-on reset. If the mainboard that
hosts the RTC cannot guarantee this, a software reset sequence is needed
in the case where the battery was drained completely.
As the rising slope of the power supply depends on so many parameters
and is highly mainboard specific, refactor the initialization code to
perform a software reset every time a power loss event is recognized by
the RTC.
Change-Id: If64d672e51667523058041bd00e1e50ac047143d
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/20412
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Martin Roth <martinroth@google.com>
The RTC RX6110SA has several configuration options which might be
interesting to set. To make this setup independent of the driver itself
but let it still be configurable on mainboard level, add more
configuration options to the chip driver.
Change-Id: I7f8b2aa7cd001a887f271be36f655e10e60e778b
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/20084
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Mario Scheithauer <mario.scheithauer@siemens.com>
The driver for the RTC RX6110SA is designed to be used with I2C bus.
This patch adds the possibility to use SMBus operations to access the
RTC. For this purpose the Kconfig switch RX6110SA_USE_SMBUS is added. It
is not enabled per default so that I2C will be used. One can set this
switch on board level to use SMBus instead.
Change-Id: I4827ae2c544e8002399d94a1159acacd8176c5e9
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/19978
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
This driver enables the usage of the external RTC chip RX6110 SA
(http://www5.epsondevice.com/en/products/i2c/rx6110sab.html) which is
connected to the I2C bus. The I2C address of this device is fixed. One
can change parameters in the device tree so that the used setup can be
adapted to match the configuration of the device on the mainboard.
Change-Id: I1290a10c2d5ad76a317c99c8b92a013309a605d6
Signed-off-by: Mario Scheithauer <mario.scheithauer@siemens.com>
Reviewed-on: https://review.coreboot.org/19625
Tested-by: build bot (Jenkins) <no-reply@coreboot.org>
Reviewed-by: Werner Zeh <werner.zeh@siemens.com>
The vendor.irq field was originally intended for use as the TPM 1.2
"command complete" interrupt. However, all actual coreboot tpm drivers
and hardware use the vendor.status method of checking command completion
instead, and this irq field is not used.
Let's just remove this unused functionality to simplify the code.
BRANCH=none
BUG=b:36786804
TEST=Boot reef w/ serial enabled firmware, verify verstage sees
"cr50 TPM" and does not complain about lack of tis_plat_irq_status().
TEST=Boot eve w/ serial enabled firmware, verify verstage sees
"cr50 TPM" and does not complain about lack of tis_plat_irq_status().
Change-Id: I994c5bfbd18124af9cb81d9684117af766ab0124
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/19396
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
The Cr50 TPM uses an IRQ to provide a "status" signal used for hand-shaking
the reception of commands. Real IRQs are not supported in firmware,
however firmware can still poll interrupt status registers for the same
effect.
Commit 94cc485338 ("drivers/i2c/tpm/cr50: Support interrupts for status")
added support for the Cr50 driver on X86 platforms to use a KConfig file
to supply an IRQ which it would poll using acpi_get_gpe. If the IRQ is
not supplied, the Cr50 driver inserts a 20 ms wait.
Unfortunately this doesn't work so well when using the i2c connected Cr50
on ARM platforms. Luckily, a more generic implementation to allow a
mainboard to supply a Cr50 IRQ status polling function was solved for SPI
connected Cr50s by commit 19e3d335bd ("drivers/spi/tpm: using tpm irq to
sync tpm transaction").
Let's refactor the i2c c50 driver to use this same approach, and change
eve and reef boards to make use of DRIVER_TPM_TIS_ACPI_INTERRUPT for
specifying the TPM flow control interrupt.
This essentially reverts these two commits:
48f708d199 drivers/i2c/tpm/cr50: Initialize IRQ status handler before probe
94cc485338 drivers/i2c/tpm/cr50: Support interrupts for status
And ports this commit to i2c/tpm/cr50:
19e3d335bd drivers/spi/tpm: using tpm irq to sync tpm transaction
As a side effect the tpm_vendor_specific IRQ field goes back to its
original usage as the "TPM 1.2 command complete" interrupt, instead of
being repurposed to hold the flow control IRQ.
BRANCH=none
BUG=b:36786804
TEST=Boot reef w/ serial enabled firmware, verify verstage sees
"cr50 TPM" and does not complain about lack of tis_plat_irq_status().
TEST=Boot eve w/ serial enabled firmware, verify verstage sees
"cr50 TPM" and does not complain about lack of tis_plat_irq_status().
Change-Id: I004329eae1d8aabda51c46b8504bf210484782b4
Signed-off-by: Daniel Kurtz <djkurtz@chromium.org>
Reviewed-on: https://review.coreboot.org/19363
Reviewed-by: Julius Werner <jwerner@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Depend on I2C_TPM to prevent showing the menu entry on systems
that do not have an I2C TPM installed.
Change-Id: I7cd647c9c7e9721eab96ab64b844a882f156ee68
Signed-off-by: Patrick Rudolph <siro@das-labor.org>
Reviewed-on: https://review.coreboot.org/19374
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com>
1. Move common TIS macros to include/tpm.h.
2. Use common TIS macros while referring to status and access registers.
3. Add a new function claim_locality to properly check for required
access bits and claim locality 0.
BUG=b:36873582
Change-Id: I11bf3e8b6e1f50b7868c9fe4394a858488367287
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/19213
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
The tis.c module is needlessly copying data to/from a 1260 byte
buffer on the stack. Each device's transport implementation (cr50.c
or tpm.c) maintains its own buffer, if needed, for framing purposes.
Therefore, remove the duplicated buffer.
BUG=b:36598499
Change-Id: I478fb57cb65509b5d74bdd871f1a231f8080bc2f
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://review.coreboot.org/19061
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
In builds without CONFIG_VBOOT_SEPARATE_VERSTAGE, verstage files are
linked directly into the bootblock or the romstage. However, they're
still compiled with a separate "libverstage" source file class, linked
into an intermediate library and then linked into the final destination
stage.
There is no obvious benefit to doing it this way and it's unclear why it
was chosen in the first place... there are, however, obvious
disadvantages: it can result in code that is used by both libverstage
and the host stage to occur twice in the output binary. It also means
that libverstage files have their separate compiler flags that are not
necessarily aligned with the host stage, which can lead to weird effects
like <rules.h> macros not being set the way you would expect. In fact,
VBOOT_STARTS_IN_ROMSTAGE configurations are currently broken on x86
because their libverstage code that gets compiled into the romstage sets
ENV_VERSTAGE, but CAR migration code expects all ENV_VERSTAGE code to
run pre-migration.
This patch resolves these problems by removing the separate library.
There is no more difference between the 'verstage' and 'libverstage'
classes, and the source files added to them are just treated the same
way a bootblock or romstage source files in configurations where the
verstage is linked into either of these respective stages (allowing for
the normal object code deduplication and causing those files to be
compiled with the same flags as the host stage's files).
Tested this whole series by booting a Kevin, an Elm (both with and
without SEPARATE_VERSTAGE) and a Falco in normal and recovery mode.
Change-Id: I6bb84a9bf1cd54f2e02ca1f665740a9c88d88df4
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://review.coreboot.org/18302
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support for using GPIO IRQ instead of PIRQ with an I2C device.
This allows a device to use an edge triggered interrupt that will
trigger on both high and low transitions.
The _DSD method for describing these GPIOs has a field for 'active
low' which is supposed to be 1 if the pin is active low, otherwise
is zero. The value in here doesn't mean too much for GpioInt() as
those will end up using the value from GpioInt() when it actually
requests the interrupt.
BUG=b:35581264
BRANCH=none
TEST=test on Eve board that codec IRQ can be delcared as GPIO IRQ
Change-Id: I02c64c7fc28dc2d608ad40db889c7242892f16db
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18835
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
The I2C interface for the Atmel AT97SC3204 TPM varies greatly from the
existing I2C TPM support. The Atmel part just passes the commands and
responses from the TIS layer across the I2C interface.
TEST=Build and run on Galileo Gen2 with Crypto Shield and vboot enabled
Change-Id: Ib2ef0ffdfc12b2fc11fe4c55b6414924d4b676dd
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18800
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add debugging support for the TIS transactions for the I2C TPM chips.
TEST=Build and run on reef
Change-Id: Ibc7e26fca781316d625f4da080f34749f18e4f9b
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Fix the following warnings detected by checkpatch.pl:
WARNING: Prefer 'unsigned int' to bare use of 'unsigned'
WARNING: braces {} are not necessary for single statement blocks
WARNING: Unnecessary parentheses - maybe == should be = ?
WARNING: line over 80 characters
WARNING: missing space after return type
TEST=Build and run on Galileo Gen2
Change-Id: I56f915f6c1975cce123fd38043bad2638717d88c
Signed-off-by: Lee Leahy <leroy.p.leahy@intel.com>
Reviewed-on: https://review.coreboot.org/18832
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Wacom I2C driver does the same thing as I2C HID driver, other than
defining macros for Wacom HID. Instead of maintaining two separate
drivers providing the same functionality, update all wacom devices to
use generic I2C HID driver.
BUG=None
BRANCH=None
TEST=Verified that ACPI nodes for wacom devices are unchanged.
Change-Id: Ibb3226d1f3934f5c3c5d98b939756775d11b792c
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/18401
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Move the function that adds a power resource block from
i2c/generic to the acpi device code at src/arch/x86/acpi_device.c
so it can be used by more drivers.
BUG=chrome-os-partner:61233
TEST=verify SSDT table generation is unchanged
Change-Id: I0ffb61a4f46028cbe912e85c0124d9f5200b9c76
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/18391
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Maxim 98927 kernel driver requires entries in the ACPI SSDT table,
add a SSDT generator as part of this driver.
BUG=chrome-os-partner:62051
BRANCH=None
TEST=After boot, dump and verify that the generated SSDT ACPI table has the
required entries.
Change-Id: Ic2d4d8449288bc00d085852220b2e1e7a208e9ef
Signed-off-by: Naresh G Solanki <naresh.solanki@intel.com>
Signed-off-by: Rizwan Qureshi <rizwan.qureshi@intel.com>
Signed-off-by: M Naveen <naveen.m@intel.com>
Signed-off-by: Dylan Reid <dgreid@chromium.org>
Reviewed-on: https://review.coreboot.org/18211
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Linux kernel expects that power management with ACPI should always be
handled using PowerResource. However, some kernel drivers (e.g. ELAN
touchscreen) check to see if reset gpio is passed in by the BIOS to
decide whether the device loses power in suspend. Thus, until the kernel
has a better way for drivers to query if device lost power in suspend,
we need to allow passing in of GPIOs via _CRS as well as exporting
PowerResource to control power to the device.
Update mainboards to export reset GPIO as well as PowerResource for
ELAN touchscreen device.
BUG=chrome-os-partner:62311,chrome-os-partner:60194
BRANCH=reef
TEST=Verified that touchscreen works on power-on as well as after
suspend-resume.
Change-Id: I3409689cf56bfddd321402ad5dda3fc8762e6bc6
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/18238
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
We've found that the SLB9645 TPM sometimes seems to randomly start
returning 0xFF bytes for all requests. The exact cause is yet unknown,
but we should try to write our TIS code such that it avoids bad
interactions with this kind of response (e.g. any wait_for_status()
immediately succeeds because all "status bits" are set in the response).
At least for status and burstCount readings we can say for sure that the
value is nonsensical and we're already reading those in a loop until we
get valid results anyway, so let's add code to explicitly discount 0xFF
bytes.
BRANCH=oak
BUG=chrome-os-partner:55764
TEST=None
Change-Id: I934d42c36d6847a22a185795cea49d282fa113d9
Signed-off-by: Julius Werner <jwerner@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420470
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://review.coreboot.org/18006
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
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.
Change-Id: I4d76f193f615cfc4520869dedc55505c109042f6
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>
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
TEST=used on eve to describe a new i2c-hid touch controller
Change-Id: I94e9531a72f9bf1d6b3ade362b88883b21b83d0a
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)
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.
Change-Id: I51dc4cad1c1f246b51891abf7115a7120e87b098
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)
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
Change-Id: I8594f6ac121a175844393952db2169dbc5cbd2b2
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>
Wacom I2C driver can be used by devices other than
touchscreen. e.g. digitizer. So there is no need to name the driver
with touchscreen specific attributes. Only a separate descriptor name
is required that needs to be set by mainboard correctly.
BUG=chrome-os-partner:56246
BRANCH=None
TEST=Compiles successfully.
Change-Id: I0d32a4adae477373b3f4c5f3abbe188860701194
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17341
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
WACOM request to add a new identifier `WCOMNTN2`,
and use that for the board Pyro with all LCD combinations.
BRANCH=master
BUG=chrome-os-partner:58093
TEST=emerge-pyro vboot_reference coreboot chromeos-bootimage
Signed-off-by: Janice Li <janice.li@quantatw.com>
Change-Id: I95cf357efba958d7e864d2736d324e0aad70e307
Reviewed-on: https://review.coreboot.org/17257
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Increase the IRQ timeout to prevent issues if there is a delay
in the TPM responding to a command. Split the no-IRQ case out
so it doesn't suffer unnecessarily.
BUG=chrome-os-partner:59191
TEST=suspend/resume testing on eve board
Change-Id: I1ea7859bc7a056a450b2b0ee32153ae43ee8699f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/17204
Reviewed-by: Furquan Shaikh <furquan@google.com>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
1. Export i2c_generic_fill_ssdt to allow other device-specific i2c
drivers to share and re-use the same code for generating AML code for
SSDT. In order to achieve this, following changes are required:
a. Add macro I2C_GENERIC_CONFIG that defines a structure with all
generic i2c device-tree properties. This macro should be placed by the
using driver at the start of its config structure.
b. Accept a callback function to add any device specific information to
SSDT. If generic driver is used directly by a device, callback would be
NULL. Other devices using a separate i2c driver can provide a callback
to add any properties to SSDT.
2. Allow device to provide _CID.
BUG=chrome-os-partner:57846
Change-Id: I3a0054e22b81f9d6d407bef417eae5e9edc04ee4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17089
Tested-by: build bot (Jenkins)
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Add support to allow a device to define PowerResource in its SSDT AML
code. PowerResouce ACPI generation expects SoC to define the
callbacks for generating AML code for GPIO manipulation.
Device requiring PowerResource needs to define following parameters:
1. Reset GPIO - Optional, GPIO to put device into reset or take it out
of reset.
2. Reset delay - Delay after reset GPIO is de-asserted (default 0).
3. Enable GPIO - Optional, GPIO to enabled device.
4. Enable delay - Delay after enable GPIO is asserted (default 0).
BUG=chrome-os-partner:55988
Change-Id: Ieb2dd95fc1f555f5de66f3dda425172ac5b75dad
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://review.coreboot.org/17081
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Tested-by: build bot (Jenkins)
UX Doc = go/gale-hw-ui
This color wasn't changed earlier as the change wasn't done in
the OS also. However, since we cannot change this later in FW
(but OS can change anytime), I am making this change after discussing
with the UX team.
BUG=b:31501528, b:31633562
TEST=Change the device state to 'recovery mode' to observe the new
color.
BRANCH=none
Change-Id: Ia91f14eb77492095cb41a9de0bb9790e72aa4851
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 36a3d8c6eabbc0b23d0a15d5bddc5ed3bdeebe70
Original-Change-Id: I88768b94cf91804a6005e44b1a168e059698ec4b
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/388206
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Christopher Book <cbook@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16767
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Colors and patterns as defined by the UX team
BUG=b:31501528
TEST=Move the device to different states in FW using rec and dev
button and verify the colors
BRANCH=None
Change-Id: I66d41a54590cd3ce4e5202c7cfa890f462fe195e
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 703559d5dddaeeb7d435d6cadbb2009a1b7a76c8
Original-Change-Id: I95ab1fa59b483396ff1498a28f1ee98ac08d02d7
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/387258
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Christopher Book <cbook@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16718
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Gale EVT3 has only one LED controller (earlier we had 2).
Remove the support for the second controller and also the
corresponding microcode. The color values used are the same
as onHub (Arkham to be specific).
BUG=b:30890905
TEST=Move the device to different states manually by appropriate
actions (like dev mode, rec mode etc) and observe the different
colors.
BRANCH=None
Change-Id: I853035610ea7ea7c8d29c30d2de13c9e2e786b2b
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 593905d2d69daa7482318aa5f5c5cd7cf984043e
Original-Change-Id: If8f22abd605faac6f6215ef600041740ce15ea0c
Original-Signed-off-by: Suresh Rajashekara <sureshraj@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/370821
Original-Commit-Ready: Suresh Rajashekara <sureshraj@chromium.org>
Original-Tested-by: Suresh Rajashekara <sureshraj@chromium.org>
Original-Reviewed-by: Kan Yan <kyan@google.com>
Reviewed-on: https://review.coreboot.org/16697
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
Move the setup of the IRQ status handler so it will be set up properly
before the early probe happens.
BUG=chrome-os-partner:53336
Change-Id: I4380af1233d2a252899459635a3cb69ca196088d
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16861
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
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>
Add a config option to the generic I2C device driver to indicate to
the OS that this device should be probed before being added.
This can be used to provide ACPI device instantiations to devices that
may not actually exist on the board. For example, if multiple trackpad
vendors are supported on the same board they can both be described in
ACPI and the OS will probe the address and load the driver only if the
device responds to the probe at that address.
BUG=chrome-os-partner:57686
Change-Id: I22cffb4b15f25d97dfd37dc58bca315f57bafc59
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16742
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Support reading the ACPI GPE status (on x86) to determine when
the cr50 is ready to return response data or is done processing
written data. If the interrupt is not defined by Kconfig then
it will continue to use the safe delay.
This was tested with reef hardware and a modified cr50 image
that generates interrupts at the intended points.
BUG=chrome-os-partner:53336
Change-Id: Ic8f805159650c45382cacac8840450a1f8b4d7a1
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16672
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Unify the function names to be consistent throughout the driver
and improve the handling while waiting for data available and
data expected flags from the TPM.
BUG=chrome-os-partner:53336
Change-Id: Ie2dfb7ede1bcda0e77070df945c47c1428115907
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16668
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Clean up the mask and timeout handling in the locality functions
that were copied from the original driver.
BUG=chrome-os-partner:53336
Change-Id: Ifdcb3be0036b2c02bfbd1bcd326e9519d3726ee0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16667
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Rename the low-level functions from iic_tpm_read/write to
cr50_i2c_read/write to better match the driver name, and pass in the
tpm_chip structure to the low-level read/write functions as it will
be needed in future changes.
BUG=chrome-os-partner:53336
Change-Id: I826a7f024f8d137453af86ba920e0a3a734f7349
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16666
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Use two different timeouts in the driver. The 2ms timeout is needed
to be safe for cr50 to cover the extended timeout that is seen with
some commands. The other at 2 seconds which is a TPM spec timeout.
BUG=chrome-os-partner:53336
Change-Id: Ia396fc48b8fe6e56e7071db9d74561de02b5b50e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16665
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reduce the static buffer size from the generic default 1260
down to 64 to match the max FIFO size for the cr50 hardware
and reduce the footprint of the driver.
BUG=chrome-os-partner:53336
Change-Id: I6f9f71d501b60299edad4b16cc553a85391a1866
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16664
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Originally I thought it would be cleaner to keep this code in one
place, but as things continue to diverge it ends up being easier
to split this into its own driver. This way the different drivers
in coreboot, depthcharge, and the kernel, can all be standalone
and if one is changed it is easier to modify the others.
This change splits out the cr50 driver and brings along the basic
elements from the existing driver with no real change in
functionality. The following commits will modify the code to make
it consistent so it can all be shared with depthcharge and the
linux kernel drivers.
BUG=chrome-os-partner:53336
Change-Id: I3b62b680773d23cc5a7d2217b9754c6c28bccfa7
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16663
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Move the common enums and variables to tpm.h so it can be
used by multiple drivers.
BUG=chrome-os-partner:53336
Change-Id: Ie749f13562be753293448fee2c2d643797bf8049
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16662
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Support reading the ACPI GPE status (on x86) to determine when
the cr50 is ready to return response data or is done processing
written data. If the interrupt is not defined by Kconfig then
it will continue to use the safe delay.
This was tested with reef hardware and a modified cr50 image
that generates interrupts at the intended points.
BUG=chrome-os-partner:53336
Change-Id: I9f78f520fd089cb4471d8826a8cfecff67398bf8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Unify the function names to be consistent throughout the driver
and improve the handling while waiting for data available and
data expected flags from the TPM.
BUG=chrome-os-partner:53336
Change-Id: I7e3912fb8d8c6ad17d1af2d2a7189bf7c0c52c8e
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Clean up the mask and timeout handling in the locality functions
that were copied from the original driver.
BUG=chrome-os-partner:53336
Change-Id: Ifa1445224b475aec38c2ac56e15cb7ba7fcd21ea
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Rename the low-level functions from iic_tpm_read/write to
cr50_i2c_read/write to better match the driver name, and pass in the
tpm_chip structure to the low-level read/write functions as it will
be needed in future changes.
BUG=chrome-os-partner:53336
Change-Id: Ib4a68ce1b3a83ea7c4bcefb9c6f002f6dd4aac1f
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Use two different timeouts in the driver. The 2ms timeout is needed
to be safe for cr50 to cover the extended timeout that is seen with
some commands. The other at 2 seconds which is a TPM spec timeout.
BUG=chrome-os-partner:53336
Change-Id: I77fdd7ea646b8b2fef449f07e3a08bcce174fe8b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reduce the static buffer size from the generic default 1260
down to 64 to match the max FIFO size for the cr50 hardware
and reduce the footprint of the driver.
BUG=chrome-os-partner:53336
Change-Id: Ia88facca607f3fd5072d0d986323fde075f15855
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Originally I thought it would be cleaner to keep this code in one
place, but as things continue to diverge it ends up being easier
to split this into its own driver. This way the different drivers
in coreboot, depthcharge, and the kernel, can all be standalone
and if one is changed it is easier to modify the others.
This change splits out the cr50 driver and brings along the basic
elements from the existing driver with no real change in
functionality. The following commits will modify the code to make
it consistent so it can all be shared with depthcharge and the
linux kernel drivers.
BUG=chrome-os-partner:53336
Change-Id: Ia9a65e72519b95f5739e3b7a16b9c2431d64ebe2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Move the common enums and variables to tpm.h so it can be
used by multiple drivers.
BUG=chrome-os-partner:53336
Change-Id: I0febe98620d0ddd4ec6b46cd3073e48c12926266
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
The TPM driver was largely ignoring the meaning of the command
ready bit in the status register, instead just arbitrarily
sending it at the end of every receive transaction.
Instead of doing this have the command ready bit be set at the
start of a transaction, and only clear it at the end of a
transaction if it is still set, in case of failure.
Also the cr50 function to wait for status and burst count was
not waiting the full 2s that the existing driver does so that
value is increased. Also, during the probe routine a delay is
inserted after each status register read to ensure the TPM has
time to actually start up.
Change-Id: I1c66ea9849e6be537c7be06d57258f27c563c1c2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16591
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
The early TPM probe was done directly in tis.c ignoring the lower
layer that provides appropriate access to the chip. Move this into
a tpm_vendor_probe() function so it can use iic_tpm_read() with all
of the built-in delays and semantics instead of calling i2c_readb()
directly from the wrong layer.
This fixes early init failures that were seen with the cr50 i2c tpm
on the reef mainboard.
Change-Id: I9bb3b820d10f6e2ea24c57b90cf0edc813cdc7e0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16527
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
If the TPM completely fails to respond then the vendor structure may not
have assigned handlers yet, so catch that case and return error so the
boot can continue to recovery mode instead of asserting over and over.
Change-Id: If3a11567df89bc73b4d4878bf89d877974044f34
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16416
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Add code to generate an ACPI descriptor for an I2C TPM based
on the device as described in devicetree.cb.
This currently requires the devicetree to provide the HID,
since we don't currently talk to the TPM in ramstage and I
didn't want to add yet another init path for it here.
This was tested on a reef board to ensure that the device
is described properly in the SSDT.
Change-Id: I43d7f6192f48e99a4074baa4e52f0a9ee554a250
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16397
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add support for the cr50 TPM used in apollolake chromebooks.
This requires custom handling due to chip limitations, which
may be revisited but are needed to get things working today.
- timeouts need to be longer
- must use the older style write+wait+read read protocol
- all 4 bytes of status register must be read at once
- same limitation applies when reading burst count from status reg
- burst count max is 63 bytes, and burst count behaves
slightly differently than other I2C TPMs
- TPM expects the host to drain the full burst count (63 bytes)
from the FIFO on a read
Luckily the existing driver provides most abstraction needed to
make this work seamlessly. To maximize code re-use the support
for cr50 is added directly instead of as a separate driver and the
style is kept similar to the rest of the driver code.
This was tested with the cr50 TPM on a reef board with vboot
use of TPM for secdata storage and factory initialization.
Change-Id: I9b0bc282e41e779da8bf9184be0a11649735a101
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16396
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
Allow the sleep durations used by the driver to be set by the
specific chip so they can be tuned appropriately.
Since we need to read the chip id to know the values use very
conservative defaults for the first command and then set it
to the current values by default.
Change-Id: Ic64159328b18a1471eb06fa8b52b589eec1e1ca2
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16395
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Use CAR accessors where needed for accessing static data.
In some cases this required some minor restructuring to pass
in a variable instead of use a global one.
For the tpm_vendor_init the structure no longer has useful
defaults, which nobody was depending on anyway. This now
requires the caller to provide a non-zero address.
Tested by enabling I2C TPM on reef and compiling successfully.
Change-Id: I8e02fbcebf5fe10c4122632eda1c48b247478289
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/16394
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
(val & 4) == 1 is always false. Since val & 4 is either zero or
non-zero, just drop the second test (for "== 1").
Validated against the data sheet that this is really the right register,
bit and value.
Change-Id: I627df9a9b4fddfff486689e405f52a3b54135eef
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Found-by: Coverity Scan #1241864
Reviewed-on: https://review.coreboot.org/16009
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
These files are required by storm and gale boards for enabling elog
support in ramstage.
BUG=chrome-os-partner:55639
Change-Id: I2bbfee2acf2bfe2f896a8619b1276dcea1b87f16
Signed-off-by: Furquan Shaikh <furquan@google.com>
Reviewed-on: https://review.coreboot.org/15893
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Tested-by: build bot (Jenkins)
This driver enables the usage of an external RTC chip PCF8523 which is
connected to the I2C bus. The I2C address of this device is fixed.
One can change parameters in device tree so that the used setup can be
adapted in device tree to match the configuration of the device on the
mainboard.
Change-Id: I2d7e161c9e12b720ec4925f1acfd1dd8ee6ee5f5
Signed-off-by: Werner Zeh <werner.zeh@siemens.com>
Reviewed-on: https://review.coreboot.org/15641
Tested-by: build bot (Jenkins)
Reviewed-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Add a device driver to generate the device and required properties
into the SSDT.
This driver uses the ACPI Device Property interface to generate the
required parameters into the _DSD table format expected by the kernel.
This was tested on the reef mainboard to ensure that the SSDT contained
the equivalent parameters that are provided by the current DSDT object.
Change-Id: Ia809e953932a7e127352a7ef193974d95e511565
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15538
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There is a second ACPI _DSD document from the UEFI Forum that details
how _DSD style tables can be nested, creating a tree of similarly
formatted tables. This document is linked from acpi_device.h.
In order to support this the device property interface needs to be
more flexible and build up a tree of properties to write all entries
at once instead of writing each entry as it is generated.
In the end this is a more flexible solution that can support drivers
that need child tables like the DA7219 codec, while only requiring
minor changes to the existing drivers that use the device property
interface.
This was tested on reef (apollolake) and chell (skylake) boards to
ensure that there was no change in the generated SSDT AML.
Change-Id: Ia22e3a5fd3982ffa7c324bee1a8d190d49f853dd
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15537
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Until now it was assumed that all TPM devices were of the same type
(TCG 1.2 spec compliant) and x86 based boards had LPC connected TPMs
and all other boards had I2C connected TPMs.
With the advent of TPM2 specification there is a need to be able to
configure different combinations of TPM types (TPM or TPM2) and
interfaces (LPC, I2C and SPI).
This patch allows to do it. Picking Chrome OS still assumes that the
board has a TPM device, but adding MAINBOARD_HAS_TPM2 to the board's
Kconfig will trigger including of TPM2 instead.
MAINBOARD_HAS_LPC_TPM forces the interface to be set to LPC, adding
SPI_TPM to the board config switches interface choice to SPI, and if
neither of the two is defined, the interface is assumed to be I2C.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=verified that none of the generated board configurations change
as a result of this patch. With the rest of the stack in place it
is possible to configure different combinations of TPM types and
interfaces for ARM and x86 boards.
Change-Id: I24f2e3ee63636566bf2a867c51ed80a622672f07
Signed-off-by: Martin Roth <martinroth@chromium.org>
Original-Commit-Id: 5a25c1070560cd2734519f87dfbf401c135088d1
Original-Change-Id: I659e9301a4a4fe065ca6537ef1fa824a08d36321
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/349850
Original-Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://review.coreboot.org/15294
Tested-by: build bot (Jenkins)
Reviewed-by: Furquan Shaikh <furquan@google.com>
Reviewed-by: Philipp Deppenwiese <zaolin.daisuki@googlemail.com>
This variable name was changed in chip.h but not the consumer
and it was submitted before it was caught.
Change-Id: I7c492b588b2fd854a9eeac36029a46da324a7b1b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15109
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
This adds a generic I2C driver that can be described in the devicetree
and used to generate ACPI objects in the SSDT based on the information
provided in the config registers.
The I2C bus can be configured and the device can provide an interrupt and
wake capability to the OS. A configuration option allows for a GPIO to
be provided that will be checked to determine if the device is preset on
the board before including it in the generated SSDT.
The driver is generic enough to be used for basic I2C devices that do
not have special configuration needs such as touchpads, touchscreens,
sensors, some audio codec/amplifiers, etc.
Sample usage for a touchpad device:
device pci 15.1 on
chip drivers/i2c/generic
register "hid" = ""ELAN0000""
register "desc" = "ELAN Touchpad"
register "irq" = "IRQ_EDGE_LOW(GPP_B3_IRQ)"
register "wake" = "GPE0_DW0_05"
device i2c 15.0 on end
end
end
Will result in the following code in the SSDT:
Scope (\_SB.PCI0.I2C1) {
Device (D015) {
Name (_HID, "ELAN0000")
Name (_UID, 0)
Name (_S0W, 4)
Name (_PRW, Package () { 5, 3 })
Method (_STA) { Return (0x0f) }
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x15, ControllerInitiated, 400000, AddressingMode7Bit,
"\\_S.PCI0.I2C1", 0, ResourceConsumer)
Interrupt (ResourceConsumer, Edge, ActiveLow) { 51 }
})
}
}
Change-Id: Ib32055720835b70e91ede5e4028ecd91894d70d5
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://review.coreboot.org/15016
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The Nuvoton NAU8825 audio codec is an I2C device that has a number of
tunable parameters that can be provided to the kernel device driver for
basic configuration and optimal operation.
The configuration options are exposed to devicetree as registers and then
presented as Device Properties via ACPI to the operation system.
This sample configuration in devicetree:
device pci 19.2 on
chip drivers/i2c/nau8825
register "irq" = "IRQ_LEVEL_LOW(GPP_F10_IRQ)"
register "jkdet_enable" = "1"
register "sar_threshold_num" = "2"
register "sar_threshold[0]" = "0x0c"
register "sar_threshold[1]" = "0x1c"
device i2c 1a on end
end
end
Will generate the following code in the SSDT, trimmed for this commit
message as there are more properties that can be configured:
Scope (\_SB.PCI0.I2C4)
{
Name (_HID, "10508825")
Name (_UID, Zero)
Name (_DDN, "Nuvoton NAU8825 Codec")
Method (_STA) { Return (0xF) }
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x1A, ControllerInitiated, 0x61A80, AddressingMode7Bit,
"\_SB.PCI0.I2C4", 0, ResourceConsumer)
Interrupt (ResourceConsumer, Level, ActiveLow) { 0x3A }
})
Name (_DSD, Package () {
ToUUID ("daffd814-6eba-4d8c-8a91-bc9bff4aa301"),
Package () {
Package () { "nuvoton,jkdet-enable", 1 },
Package () { "nuvoton,sar-threshold-num", 2 },
Package () { "nuvoton,sar-threshold", Package () { 0x0c, 0x1c } }
}
})
}
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Change-Id: I480d72daf5ac3dded9b1cbb5fbc737b9dfde3834
Reviewed-on: https://review.coreboot.org/15015
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reorder drivers to fit src/drivers/[X]/[Y]/ scheme to make
them pluggable.
Change-Id: Ia210e6832c18270043c0cb21b4881d9c802f3b2b
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: https://review.coreboot.org/14058
Tested-by: build bot (Jenkins)
Reviewed-by: Martin Roth <martinroth@google.com>
It encourages users from writing to the FSF without giving an address.
Linux also prefers to drop that and their checkpatch.pl (that we
imported) looks out for that.
This is the result of util/scripts/no-fsf-addresses.sh with no further
editing.
Change-Id: Ie96faea295fe001911d77dbc51e9a6789558fbd6
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/11888
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
Add full support for fan control, fan monitoring, and voltage
monitoring. Fan speeds and functions are configurable via
each mainboard's devicetree.cb file.
NOTE: This patch effectively rewrites large portions of
the original driver. You may need to re-verify correct
operation on your hardware if you were using the old
driver code.
Change-Id: I3e246af0e398d65ee43ea708060885c67fd7d202
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/11936
Reviewed-by: Felix Held <felix-coreboot@felixheld.de>
Tested-by: build bot (Jenkins)
Reviewed-by: Peter Stuge <peter@stuge.se>
coreboot has no CREDITS file.
Change-Id: Iaa4686979ba1385b00ad1dbb6ea91e58f5014384
Signed-off-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Reviewed-on: http://review.coreboot.org/11514
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The many different places to put vboot support in can be confusing.
Instead of using libverstage (which isn't enough since those functions are
sometimes called outside that, too), mention all stages where it can resides
explicitly.
Change-Id: Idddb9f5e2ef7bcc273f429d9f432bd37b4573567
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10728
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
That way it's available wherever the verstage code ends up, bootblock,
verstage or romstage.
Change-Id: I0665e297f199acd60cff93e1b39812f183115d33
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10707
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
It's derived from EEPROM on Lenovo machines and not from user config
which is ignored.
Change-Id: I54fb76a3160e47cd36d33d2937c4bfaddcd36a69
Signed-off-by: Vladimir Serbinenko <phcoder@gmail.com>
Reviewed-on: http://review.coreboot.org/7055
Tested-by: build bot (Jenkins)
Reviewed-by: Nicolas Reinecke <nr@das-labor.org>
Used command line to remove empty lines at end of file:
find . -type f -exec sed -i -e :a -e '/^\n*$/{$d;N;};/\n$/ba' {} \;
Change-Id: I816ac9666b6dbb7c7e47843672f0d5cc499766a3
Signed-off-by: Elyes HAOUAS <ehaouas@noos.fr>
Reviewed-on: http://review.coreboot.org/10446
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Use of scan_static_bus() and tree traversals is somewhat convoluted.
Start cleaning this up by assigning each path type with separate
static scan_bus() function.
For ME, SMBus and LPC paths a bus cannot expose bridges, as those would
add to the number of encountered PCI buses.
Change-Id: I8bb11450516faad4fa33b8f69bce5b9978ec75e5
Signed-off-by: Kyösti Mälkki <kyosti.malkki@gmail.com>
Reviewed-on: http://review.coreboot.org/8534
Tested-by: build bot (Jenkins)
Reviewed-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
As per discussion with lawyers[tm], it's not a good idea to
shorten the license header too much - not for legal reasons
but because there are tools that look for them, and giving
them a standard pattern simplifies things.
However, we got confirmation that we don't have to update
every file ever added to coreboot whenever the FSF gets a
new lease, but can drop the address instead.
util/kconfig is excluded because that's imported code that
we may want to synchronize every now and then.
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, *MA[, ]*02110-1301[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335, USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 59 Temple Place[-, ]*Suite 330, Boston, MA *02111-1307[, ]*USA:Foundation, Inc.:" {} +
$ find * -type f -exec sed -i "s:Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.:Foundation, Inc.:" {} +
$ find * -type f
-a \! -name \*.patch \
-a \! -name \*_shipped \
-a \! -name LICENSE_GPL \
-a \! -name LGPL.txt \
-a \! -name COPYING \
-a \! -name DISCLAIMER \
-exec sed -i "/Foundation, Inc./ N;s:Foundation, Inc.* USA\.* *:Foundation, Inc. :;s:Foundation, Inc. $:Foundation, Inc.:" {} +
Change-Id: Icc968a5a5f3a5df8d32b940f9cdb35350654bef9
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/9233
Tested-by: build bot (Jenkins)
Reviewed-by: Vladimir Serbinenko <phcoder@gmail.com>
The build system includes a bunch of files into verstage that
also exist in romstage - generic drivers etc.
These create link time conflicts when trying to link both the
verstage copy and romstage copy together in a combined configuration,
so separate "stage" parts (that allow things to run) from "library" parts
(that contain the vboot specifics).
Change-Id: Ieed910fcd642693e5e89e55f3e6801887d94462f
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-on: http://review.coreboot.org/10041
Tested-by: build bot (Jenkins)
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It became necessary to indicate the beginning of the normal boot
process. This patch adds a new pattern, a slow (over 2 seconds) fade
in into the 0, 87, 155 color.
BRANCH=storm
BUG=chrome-os-partner:39044
TEST=tested by the next patch.
Change-Id: Idd977688e5aa2cc55fc295072c0766526ae95016
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 577c8bd6f8c69073cfdd7acd4a87e7ae603d48e6
Original-Change-Id: I9aff3f4558e733ff2e47206075533556e400f183
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/265535
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9922
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
After testing on a final assembly the PD team adjusted the wipeout
request and recovery request modes' colors.
BRANCH=storm
BUG=none
TEST=verified new colors while booting an SP5 device in recovery mode
Change-Id: I9bd2dac63b99140573533c2cda8eaa9213478ab1
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 41c34a619dc0317af67907f18ee844c71a73d623
Original-Change-Id: Iab84710ebdeed35ddd4a8a163bbb6b8ac9cdb799
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/262602
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9890
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Modify colors as suggested by product review folks. This is not final,
to make it easier to identify RGB locations in the hex dumps, express
their values in decimal as opposed to hex.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=verified new all three color schemes while pressing the recovery
button at boot for 20 seconds.
Change-Id: I7461acd7004e3d10cba6665a9bfe25ec8aa6f3ba
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 7a075824a1954eb5d1b65ce887304924724a6d21
Original-Change-Id: I7f5968e361333572fd1f84aa11b7150194ad902a
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261690
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9880
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The originally loaded blinking program was written to allow gradual
change in LED brightness, which required controlling each LED with its
own engine. In fact there is no need in gradual brightness changes
when the firmware is controlling the ring. This allows to control all
LEDs by one engine, making the code simpler and more robust (no need
to synchronize the three engines any more).
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=verified that recovery boot WW ring patterns work as expected.
Change-Id: I89d231fb61693f4e834d8d9323ae5a7ddd149525
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 19809cf8120df8865da9b5b9e7b8e932334bf4b5
Original-Change-Id: I41038fd976dc9600f223dc0e9c9602331baf68f9
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261026
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9873
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The two controllers on the ring are programmed independently, and if
the second controller is running the old pattern while the first one
was loaded with a new pattern, there is a window of when the two
unrelated patterns might interact.
To avoid this shut down execution on both controllers before starting
downloading the new pattern code.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=verified recovery/wipeout LED ring behavior did not change.
Change-Id: I163f2983d414fe839208054ae3e9025663a46aeb
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 3502ca6b119c033855b45388e7b782d35cfdd82b
Original-Change-Id: I0f71f94a7e82f6c0e7f98d3aad1f93ece207248f
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/261200
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9872
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
Add compiled lp55231 code snippets to allow display certain patterns
when booting the device with the recovery button pressed.
As soon as the press is detected, the low intensify solid white
pattern is enabled. Holding recovery button long enough causes the
device transition between the wipeout requested and recovery requested
states, with the appropriate changes in the displayed pattern.
The patch also includes the source code for the LED controller as well
as instructions on how to compile and modify the code to result in
different colors, intensities, blink periods and duty cycles.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=reboot an SP5 device with the LED ring attached, keep the
recovery button pressed, observe the changes in the LED display
pattern while the device progresses through the boot sequence.
Change-Id: Ic7d45fc7c313b6d21119d4ae6adaeb4f46f7d181
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 0fd6a5c0067d705197816629f41640a931d2f7cd
Original-Change-Id: Ib5cc5188c2eeedbba128101bf4092a0b9a74e155
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/260670
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9870
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
The patterns displayed on the LED ring while under the coreboot
control are not driven by the vboot, but by the board code instead,
The four distinct states of the LED display are:
- all off
- recovery button push detected, waiting for it to be released
- wipeout request pending - recovery button was pushed long enough
to trigger this request
- recovery request pending - recovery button was pushed long enough
to trigger this request.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=no functional changes
Change-Id: I38d9a3028013b902a7a67ccd4eb1c5d533bf071c
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: bdfff0e646283da6a2faaacf33e0179d2fea221c
Original-Change-Id: Ie279151b6060a2888268a2e9a0d4dc22ecaba460
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/260649
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9868
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
When in development environment, some SP5 devices might not have the
LED ring attached. They are still fully functional, but when booting
up are generating massive amount of i2c error messages. This patch
prevents accesses to non-existing lp55321 devices.
When loading the program into the device the vendor recommends 1 ms
delay when accessing the program control register. This patch
separates these accesses into a function and add a delay after every
access.
Another fix - advance the program address when loading multipage
programs.
Set the global variable register 3c, not used by coreboot programs, to
a fixed value. This will allow depthcharge to avoid re-initializing
the controller when not necessary.
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=booted firmware on an SP5 with no LED ring attached, no excessive
error messages are generated, saw the default pattern displayed
when the recovery button is pressed during reset.
Change-Id: I6a2a27968684c40dae15317540a16405b1419e30
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: 5e0b4c84aca27460db594da1faf627ddee56f399
Original-Change-Id: I10f1f53cefb866d11ecf76ea48f74131d8b0ce77
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/260648
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9867
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This is a copy of the depthcharge ww ring driver implementation ported
into coreboot. The main differences are:
- direct use of the i2c driver instead of using the callback driver
description
- no dynamic memory allocation for the controller structures
BRANCH=storm
BUG=chrome-os-partner:36059
TEST=with the rest of the patches applied the LED ring gets
initialized to the default pattern at coreboot start.
Change-Id: I6902c8b76fc173ad2ec28b8cc94695e892df338a
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: eda24b78f8aff311dd6296d458bdfecf26c3d65a
Original-Change-Id: I5660dc3f255aab8fbe3a87041c72916a645c193b
Original-Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/257730
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9858
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
This patch removes quite a bit of code duplication between cpu_to_le32()
and clrsetbits_le32() style macros on the different architectures. This
also syncs those macros back up to the new write32(a, v) style IO
accessor macros that are now used on ARM and ARM64.
CQ-DEPEND=CL:254862
BRANCH=none
BUG=chromium:444723
TEST=Compiled Cosmos, Daisy, Blaze, Falco, Pinky, Pit, Rambi, Ryu,
Storm and Urara. Booted on Jerry. Tried to compare binary images...
unfortunately something about the new macro notation makes the compiler
evaluate it more efficiently (not recalculating the address between the
read and the write), so this was of limited value.
Change-Id: If8ab62912c952d68a67a0f71e82b038732cd1317
Signed-off-by: Patrick Georgi <pgeorgi@chromium.org>
Original-Commit-Id: fd43bf446581bfb84bec4f2ebb56b5de95971c3b
Original-Change-Id: I7d301b5bb5ac0db7f5ff39e3adc2b28a1f402a72
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/254866
Original-Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: http://review.coreboot.org/9838
Tested-by: build bot (Jenkins)
Reviewed-by: Stefan Reinauer <stefan.reinauer@coreboot.org>
As per the TCG PC Client TPM Interface Specification v1.2, bit 7 of the
access register (tmpRegValiSts bit) stays "0" until the TPM has complete
through self test and initialization. This bit is set "1" to indicate that
the other bits in the register are valid.
BRANCH=chromeos-2013.04
BUG=chrome-os-partner:35328
TEST=Booted up storm p0.2 and whirwind sp3.
Verified TPM chip is detected and reported in coreboot logs.
Change-Id: I1049139fc155bfd2e1f29e3b8a7b9d2da6360857
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 006fc93c6308d6f3fa220f00708708aa62cc676c
Original-Change-Id: I9df3388ee1ef6e4a9d200d99aea1838963747ecf
Original-Signed-off-by: Sourabh Banerjee <sbanerje@codeaurora.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/242222
Original-Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Original-Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: http://review.coreboot.org/9567
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
The TPM driver by default allocates a 4K transfer buffer on the stack,
which leads to lots of fun on boards with 2K or 3K stack sizes. On
RK3288 this ends up writing over random memory sections which dependent
on the memlayout of the day might contain timestamp data (no big deal)
or page tables (-> bad time).
This patch fixes the problem by reducing the buffer size to slightly
above 1K, which still seems to work as far as I can tell. There was
already some really odd code that #undef'ed this value and redefined it
with the lower number in one .c file (unfortunately not the one with the
buffer declaration), with no explanation whatsoever... I'm removing that
and just assume the smaller value will be fine for everything.
BRANCH=veyron
BUG=None
TEST=Booted Pinky and Falco.
Change-Id: I440a5662b41cbd8b7becab3113262e1140b7f763
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Original-Commit-Id: 3d3288041b6629b7623b9d58816e782e72836b81
Original-Change-Id: Idf80f44cbfb9617c56b64a5c88ebedf7fcb4ec71
Original-Signed-off-by: Julius Werner <jwerner@chromium.org>
Original-Reviewed-on: https://chromium-review.googlesource.com/236976
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: http://review.coreboot.org/9481
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
This code ports antirollback module and tpm library from platform/vboot_reference.
names are modified to conform to coreboot's style.
The rollback_index module is split in a bottom half and top half. The top half
contains generic code which hides the underlying storage implementation.
The bottom half implements the storage abstraction.
With this change, the bottom half is moved to coreboot, while the top half stays
in vboot_reference.
TEST=Built with USE=+/-vboot2 for Blaze. Built Samus, Link.
BUG=none
Branch=none
Original-Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Original-Change-Id: I77e3ae1a029e09d3cdefe8fd297a3b432bbb9e9e
Original-Reviewed-on: https://chromium-review.googlesource.com/206065
Original-Reviewed-by: Randall Spangler <rspangler@chromium.org>
Original-Reviewed-by: Luigi Semenzato <semenzato@chromium.org>
(cherry picked from commit 6b66140ac979a991237bf1fe25e0a55244a406d0)
Change-Id: Ia3b8f27d6b1c2055e898ce716c4a93782792599c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Reviewed-on: http://review.coreboot.org/8615
Tested-by: build bot (Jenkins)
Reviewed-by: Aaron Durbin <adurbin@google.com>
Fan 2 and Fan 3 were inexplicably set to zero after device
setup.
Change-Id: I37945745dbfaf33eb28808d85cdf75dca401e44b
Signed-off-by: Timothy Pearson <tpearson@raptorengineeringinc.com>
Reviewed-on: http://review.coreboot.org/8520
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Tested-by: build bot (Jenkins)
The correct type-signature of 'do_smbus_write_byte' is:
int do_smbus_write_byte(u32 smbus_io_base, u32 device, u32 address, u8 val)
and so storing the return type in a 'u32' is inappropriate, leading
to a tautological compare of 'ret < 0' and 'err < 0'.
Change-Id: I65486df7156c70af84fa00c336142d9a45998620
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/8209
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Tested-by: build bot (Jenkins)
Reviewed-by: Ronald G. Minnich <rminnich@gmail.com>
The new API is in use in depthcharge and is based around the "i2c_transfer"
function instead of i2c_read and i2c_write. The new function takes an array of
i2c_seg structures which represent each portion of the transfer after a start
bit and before the stop bit. If there's more than one segment, they're
seperated by repeated starts.
Some wrapper functions have also been added which make certain common
operations easy. These include reading or writing a byte from a register or
reading or writing a blob of raw data. The i2c device drivers generally use
these wrappers but can call the i2c_transfer function directly if the need
something different.
The tegra i2c driver was very similar to the one in depthcharge and was simple
to convert. The Exynos 5250 and 5420 drivers were ported from depthcharge and
replace the ones in coreboot. The Exynos 5420 driver was ported from the high
speed portion of the one in coreboot and was straightforward to port back. The
low speed portion and the Exynos 5250 drivers had been transplanted from U-Boot
and were replaced with the depthcharge implementation.
BUG=None
TEST=Built and booted on nyan with and without EFS. Built and booted on, pit
and daisy.
BRANCH=None
Original-Change-Id: I1e98c3fa2560be25444ab3d0394bb214b9d56e93
Original-Signed-off-by: Gabe Black <gabeblack@google.com>
Original-Reviewed-on: https://chromium-review.googlesource.com/193561
Original-Reviewed-by: David Hendricks <dhendrix@chromium.org>
Original-Reviewed-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Tested-by: Jimmy Zhang <jimmzhang@nvidia.com>
Original-Reviewed-by: Hung-Te Lin <hungte@chromium.org>
Original-Commit-Queue: Gabe Black <gabeblack@chromium.org>
Original-Tested-by: Gabe Black <gabeblack@chromium.org>
(cherry picked from commit 00c423fb2c06c69d580ee3ec0a3892ebf164a5fe)
This cherry-pick required additional changes to the following:
src/cpu/allwinner/a10/twi.c
src/drivers/xpowers/axp209/axp209.c
Signed-off-by: Marc Jones <marc.jones@se-eng.com>
Change-Id: I691959c66308eeeec219b1bec463b8b365a246d7
Reviewed-on: http://review.coreboot.org/7751
Tested-by: build bot (Jenkins)
Reviewed-by: Alexandru Gagniuc <mr.nuke.me@gmail.com>
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Change-Id: I7d8922d1812814ea2ebd72aaf5b5e28dc592bfb3
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7590
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-by: Paul Menzel <paulepanter@users.sourceforge.net>
Thereby making consistent with other i2c drivers
Change-Id: I5ddc9d98fbbc1db68a933e3b9a6b92f309b72c41
Signed-off-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-on: http://review.coreboot.org/7589
Tested-by: build bot (Jenkins)
Reviewed-by: Patrick Georgi <pgeorgi@google.com>
Maulik V Vaghela