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>
