This change is a safegaurd to ensure that TPM register data is always
placed in the correct location in the HW read I2CS fifo. It is only
checked for 1 or 4 byte regsiter reads. Because of the way in which a
TPM command is sent and the response is read, there are multiple reads
of the STS register prior to reading the TPM fifo register. Therefore
ensuring the fifo has zero depth when 1 or 4 byte regsiter reads,
improves the robustness of the design.
Added a counter to track the number of times the fifo is adjusted and
a new console command 'i2cs disp|rst' to display the count and reset
it to 0 if desired.
Removed section in code for TPM fifo register reads intended to handle
the case where there was a mismatch between how many bytes were copied
into the fifo and the number read by the host. Since the burstcount
field in the status register always contains a valid amount of data
that can be read by the host, there should not be cases where the
host reads less data than was copied from the TPM fifo register. In
the unexpected cases where the host may not drain all of the I2CS read
fifo data during a TPM register read, the I2CS fifo depth will be
corrected the next time that it reads either the access or STS
register which happens prior to the start of any TPM transaction.
BRANCH=none
BUG=chrome-os-partner:57338,chrome-os-partner:59191
TEST=manual
Booted Reef and verfied that TPM functionality is working.
Change-Id: I065a55e64bbcc0cb3357a2bd83447a05400b8899
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382689
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The jittery clock and trng security features require high permissions to
be initialized. In the future these initializations and the permission
level drop may be moved to RO.
This change adds permission level checks before trying to access any
registers that require high permission, so when we update RO to change
the permission RW can still function fine.
BUG=chrome-os-partner:59107
BRANCH=none
TEST=Move the permission drop to the beginning of main and verify the
system still boots.
Change-Id: I5b7cb856decd0640288ad3476f875ec9edc42635
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/405840
This patch adds the initial support for ISH chip to enable the EC
firmware to boot on Intel Integrated Sensor Hub (ISH). The following are
enabled:
1. Inter-Processor Communication (IPC) driver that enables the ISH to
communicate with the host Operating system via shared registers.
2. High Precision Event Timer (HPET) driver that provides configurable
timers for the FW to use in task scheduling.
3. I2C bus driver for accessing sensors.
4. UART console driver with TX support only.
BUG=chrome-os-partner:51851
BRANCH=None
TEST=`make buildall -j`
Change-Id: I15d4c201b799cfa79bed220ee573b75f5cd7b1f7
Signed-off-by: Jaiber John <jaiber.j.john@intel.com>
Signed-off-by: Alex Brill <alexander.brill@intel.com>
Signed-off-by: Gomathi Kumar <gomathi.kumar@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/336710
Commit-Ready: Raj Mojumder <raj.mojumder@intel.com>
Tested-by: Jaiber J John <jaiber.j.john@intel.com>
Tested-by: Raj Mojumder <raj.mojumder@intel.com>
Reviewed-by: Jaiber J John <jaiber.j.john@intel.com>
Reviewed-by: Raj Mojumder <raj.mojumder@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We previously used binary extended Euclid. That does not perform well
when inverting a small public exponent.
We also abused that routine to perform the division of n by one of its
factors. Really did not perform well there either.
This CL introduces a classic Knuth long division and a normal extended
Euclid based on that.
This drops the execution time of the common inversions into the single
msec range (vs. multiple seconds before..)
TEST=tcg_tests pass the usual 381/391; test/tpm_test/bn_test passes.
BUG=chrome-os-partner:57422
BRANCH=none
Change-Id: Ic9b4aecd0356fcab3e823dbd60c5b228a87447d3
Reviewed-on: https://chromium-review.googlesource.com/406940
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This combines stm32 and chip/g usb_i2c interfaces so they
will not diverge. Note that this fixes the chip/g implementation
to use 8-bit i2c addresses.
BUG=chrome-os-partner:57059
BRANCH=none
TEST=servod interacts with servo_micro and servo_v4
Change-Id: Ibff217d84b132556202c8a71e3d42c07d546c634
Reviewed-on: https://chromium-review.googlesource.com/405108
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The i2c_xfer API assumes it's getting an 8 bit slave address, but the
driver was assuming a 7 bit slave address was being passed in. Fixed
the location where this is used to shift it back to 7 bits.
BRANCH=none
BUG=chrome-os-partner:57059
TEST=manual
Cr50 console 'ccd i2c on' then
> i2cxfer r16 0 0x40 0
Unknown error
Usage: i2cxfer r/r16/rlen/w/w16 port addr offset [value | len]
> i2cxfer r16 0 0x80 0
0x2771 [10097]
Shows that it's now assuming an 8 bit address
Change-Id: I791b7c136a741856749c281dd4c8166b5cf97ef9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/405780
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The RESETDET and USBRST USB interrupt status bits are often set
together. There is no point in resetting USB twice.
BRANCH=none
BUG=none
TEST=verified that cr50 still operates fine of Reef and ec and ap
consoles are available (still intermittently).
Change-Id: I467d975a3a5955b6072a2a3376de7a1501e7c6c5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404910
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously, sleep was being reenabled only after tpm fifo reads as
that would typcially be near the end of a host driven TPM
command. However, in the case the host reads or writes to the STS
register, then sleep would not be re-enabled. Moved the re-enable
point to at the end of every i2cs interrupt. Since sleep is delayed by
1 second prior to being reenabled then Cr50 will not go to sleep in
the middle of TPM command since the host is either writing or reading
STS at a much faster rate when a TPM command is being executed.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Added a debug counter in idle.c and shortened sleep delays from 3
minutes to 5 seconds. Unplugged suzyq and verified that when
reconnected, the counter was incrementing to verify that Reef would
go to sleep. Also verified that TPM worked successfully and kernel
was launched.
Change-Id: I03ad33ed3591bbba24b5c56445c06d0e11368019
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/401808
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When GPIOC6/GPIO76 are not selected as SMI/SCI function(ie. selected
as GPIO), the reading of SMIB/SCIB will be a fixed value. This means
it cannot reflect the actul SMI/SCI status. As a reault, use SET_BIT/
CLEAR_BIT macro to toggle SMIB/SCIB is not feasible. Firmware should
read the SMI/SCI status from VWEVSM(2) register before setting it.
This CL defines some macros to achieve it.
In the previous CL, SMI/SCI negative polarity is conditionally
disabled. However, the negative polarity is not used in current
firmware design. Set the SMI/SCI polarity as postive unconditionly by
default.
Modified drivers:
1. lpc.c: use macro NPCX_VW_SMI/NPCX_VW_SCI to generate Virtual wire.
use SMI/SCI postive polarity uncontionally by default.
2. register.h : define macro to handle SMI/SCI virtual wire.
BUG=chrome-os-partner:34346
BRANCH=none
TEST=make buildall; try hostevent on Wheatley and check virtual wire
signal is correct on logical analyzer.
Change-Id: Id4a7748addeaa3b35f280ff29f6fcd8a08b9894b
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/400161
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Prior x86 boards have had GPIO for toggling RCIN directly on the PCH,
although many likely had HW-assisted methods as well.
With eve we need to generate an eSPI Virtual Wire for RCIN, but in reality
software control over RCIN Virtual Wire is not available with the npcx EC,
so the legacy LPC interface for pulsing KBRST must be used instead as this
is the only way to generate RCIN.
This method will likely vary on different EC chips, but for skylake it
can just be abstracted into the LPC module.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=successful 'apreset warm' on eve EC console
Change-Id: I7f9e7544a72877f75d05593b5e41f2f09a50e1c9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400037
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Enable the chipset_reset_hook by adding interrupt trigger on
pltrst assertion and fix the compilation when built with
CONFIG_CHIPSET_RESET_HOOK enabled.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=build with CONFIG_ESPI and CONFIG_CHIPSET_RESET_HOOK
Change-Id: I64eb7a1acc58c07beba0d28f94d95ef33d7220fb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400035
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The check for whether or not to send an SMI needs to check the
same status bit that it is using to indicate that it is going
to send an SMI. The SMIE bit is enabled in lpc_init() so it is
always set.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=shutdown with lid close event at developer screen
Change-Id: I9a0f34025c4fa11175fca7be34224ec680bffbef
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400033
Reviewed-by: Shawn N <shawnn@chromium.org>
This fixes a build failure using gcc 5.3 where opcode and max_attempts
are used before being initialized.
BUG=None
BRANCH=None
TEST=Build all boards successfully.
Change-Id: Ia7c4273f8812cca9f127fcd71101ce3a4e4ad4c7
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/370662
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
This isn't supposed to be static. And with CL:401421, we noticed that
clang doesn't like this form. So fix this one too.
BRANCH=none
BUG=chromium:658436
TEST=build
Change-Id: Ibd0c5724d5178c5ce8fc8c1b74382aeddd8f744d
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/402068
Reviewed-by: Shawn N <shawnn@chromium.org>
clang doesn't like the array here:
ec-utils-0.0.1-r3361: x86_64-cros-linux-gnu-clang -std=gnu99 -g -Wall -Werror -Wpointer-arith -Wcast-align -Wcast-qual -Wundef -Wsign-compare -Wredundant-decls -Wmissing-declarations -O0 -I/build/reef/usr/include/libusb-1.0 -I../../include -I../../board/cr50 -I ../../chip/g -I../../util usb_updater.c -lusb-1.0 -lcrypto -o usb_updater
ec-utils-0.0.1-r3361: In file included from usb_updater.c:32:
ec-utils-0.0.1-r3361: In file included from ../../include/usb_descriptor.h:14:
ec-utils-0.0.1-r3361: ../../chip/g/usb_hw.h:29:14: error: tentative array definition assumed to have
ec-utils-0.0.1-r3361: one element [-Werror]
ec-utils-0.0.1-r3361: static int (*usb_iface_request[]) (struct usb_setup_packet *req);
ec-utils-0.0.1-r3361: ^
ec-utils-0.0.1-r3361: 1 error generated.
But it's willing to forgive if this is extern. It should be extern
anyway.
BRANCH=none
BUG=chromium:658436
TEST=reef pre-cq passes (building ec-utils)
Change-Id: I5b5f8eb8dcdc3340487b118b30469c8cee73e182
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/401421
Reviewed-by: Shawn N <shawnn@chromium.org>
The host command parameter and response buffers should be explicitly
aligned by the LPC/SPI/I2C drivers. But the host command handlers don't
know that, and the structs are all __packed, so the compiler generates
horribly inefficient ARM Cortex-M code to cope with unaligned accesses.
Add __ec_align{1,2,4} to force the param / response structs to be
aligned. Use it in a few structs now which were straightforward to
test. It should be added to more structs as space is needed, but that
would make this change unwieldy to review and test.
Add CONFIG_HOSTCMD_ALIGNED to enable the additional alignment.
Currently, this is enabled only for LM4 and samus_pd, so that EC code
can be tested without affecting other non-samus ToT development (none of
which uses LM4).
Fix the two handlers that weren't actually aligned (despite one of
them having comments to the contrary).
Also, add a CHROMIUM_EC define that can be used to determine if a file
is being compiled for an EC target. We need that so that we only force
structure alignment for EC binaries. On the AP side, buffers may not be
aligned, so we should not force alignment.
BUG=chromium:647727
BRANCH=none
TEST=Flash samus and samus_pd. Boot samus and run a bunch of ectool
commands (with and without --dev=1, so it tests both EC and PD).
System boots and all commands return expected results.
Change-Id: I4537d61a75cf087647e24281288392eb85f22eba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/387126
This is based off of the protocol in the stm32 directory. We should
unify these implementations and the other ccd endpoints at some point.
Right now I though that I should keep the implementation the same as the
other g chips ccd drivers.
BUG=chrome-os-partner:57059
BRANCH=none
CQ-DEPEND=CL:390015
TEST=manual
download the servo patch and run 'sudo servod -c ccd_cr50.xml -c
reef_r1_inas.xml'
Test the usb i2c bridge by running 'dut-control | grep pp'
Attach servo and verify cr50 will not enable i2c
Change-Id: I0f72671505f5451a960d3baea4b2c34b6910d892
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388896
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
The USB stream should check that there are bytes in the rx fifo to read
before trying to read them. This should have been in here already.
Checking if rx is valid in usb-stream makes the rx_valid call in usb_spi
unnecessary so that is removed.
BUG=none
BRANCH=none
TEST=manual
Test CCD functionality still works on gru and reef
AP/EC consoles
sudo flashrom -p raiden_debug_spi:[AP|EC] -r img.bin
usb updater
Change-Id: Ieb77e35cc471b1f97d540ea4560591f0f40dd600
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/397858
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In current FW implement, there are two ways to generate SMI/SCI:
(1) Controlled by GPIO module register.(#define CONFIG_SCI_GPIO)
(2) Controlled by PM module register.(#undef CONFIG_SCI_GPIO)
This CL fix for case(2):
In this case, these two dedicated pins(GPIOC6/GPIO76) are used
as SMI/SCI and must be enabled by pinmux. Set the related pinmux
at initial.
By default, the SMI/SCI polarity is negative. This means SMI/SCI
is inverted when writing to SMI/SCIB but not inverted when reading
from them(see Section 5.2.2, figure 61 in datasheet). It will cause
the code more complicated to implement. Disable negative polarity
at init.
Modified drivers:
1. lpc.c: set pinmux for dedicated SMI/SCI pins and disable the
negative polarity.
BUG=chrome-os-partner:34346
BRANCH=none
TEST=make buildall; try hostevent(lid switch) on Wheatley with
CONFIG_SCL_GPIO undefined.
Change-Id: Ia317e54deb6861d7189b3594bd7414b53408b933
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/396718
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
To be able to identify different cr50 devices connected to the same
machine we need a serial number. This change uses dev id 0 and 1 to come
up with one.
BUG=chrome-os-partner:56641
BUG=chrome-os-partner:58342
BRANCH=none
TEST=lsusb -vd 18d1:5014 | grep iSerial shows different numbers for
different devices. Verify when ccd is disabled the serial number is 0.
Change-Id: I85c54af4a21bdfd0542019c02aa8420d9a879fae
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395633
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Enable valid bits of SCI#/SMI# of eSPI's VW if there's no CONFIG_SCI_GPIO
definition in board-level driver. This CL also fixed the order of VW
event bits in comments.
Modified sources:
1. espi.c: Enable valid bits of SCI#/SMI#.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make all; test nuvoton IC specific drivers
Change-Id: I8d094513284b4ed42c5c26fe1975d71bbf050aa4
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/396618
Reviewed-by: Duncan Laurie <dlaurie@google.com>
This change adds options to the powerbtn console command to press and
release the power button.
BUG=chrome-os-partner:58123
BRANCH=none
TEST=manual
'powerbtn press' force a power button press
'powerbtn release' release the power button. This will not
override the signal if the button is physically pressed.
Change-Id: I52631d30dbae874ba6637f728cb6e435cb626e12
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/396207
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
On both Reef and Gru there are INA (shunt bus voltage monitor) ICs
connected to the Cr50 I2C master bus. The use case for these chips is
in a lab setting using case closed debugging. Power to the INA chips
is controlled by a separate Cr50 gpio signal.
By default, the INAs are powered off and the I2C master bus is not
connected. A function ina_connect() is provided which needs to be
called prior to attempting to access the INAs via I2C.
BRANCH=none
BUG=chrome-os-partner:57059
TEST=manual
Tested both Reef and Gru. Verified that console command 'ccd ina
on|off' works as expected and that can repeatedly read registers on
the INA using the following command "i2cxfer r16 0 0x40 0".
Read 0x2771 [10097] which is the default value. In addition
wrote register 14 (bits 15:1 are writeable) and verified the value was
able to read the value back which was written.
Change-Id: I670f7897555dae29642264531599dc4471c52bbd
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/394168
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Added i2cm driver to support chip_i2c-xfer function. The initial use
case is for INA chips on the Reef/Gru platforms. Note that this CL
does not include any board specific changes and therefore does not
include an I2C port definition or required pinmux settings.
BRANCH=none
BUG=chrome-os-partner:57059,chrome-os-partner:58355
TEST=manual
Used console command "i2cxfer r16 0 0x40 0" to read the config
register. Read 0x2771 [10097] which is the default value. In addition
wrote register 14 and read back the value.
Change-Id: If9e377da4c8f4835d4676281872a0f079fe56aa6
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388794
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Usually CR50 TPM reset happens when the AP reboots, the CR50 RO does
not get a chance to run in this case, so the running RW does not
change either,
Once the idle RW section was updated, the only way to start it is to
reboot the CR50 completely, Rebooting CR50 causes the whole system
reset, so it should not be happening at random moments in time.
This patch introduces a mechanism to delay reboot to the moment when
the TPM is reset. The reboot request would be posted in the end of the
update, and then the AP would reboot, triggering a TPM reboot, which
in turn would trigger the CR50 reset.
The USB update handler now posts the reboot request instead of
triggering the reboot immediately.
BRANCH=none
BUG=chrome-os-partner:58226
TEST=with the rest of the patches applied verified that the system
gets reset and the new image version kicks in on both gru (over
SPI) and reef (over USB).
Change-Id: Iff859f2e7a48c5035a27fffd17aefe7e318af569
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/395627
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The keyid field of struct SignedHeader is what distinguishes prod
keys from dev keys. This may be useful someday, so let's have the
update protocol return those values for the active RO and RW
images.
Bump the UPGRADE_PROTOCOL_VERSION accordingly.
Note: This doesn't enforce any keyid matches, it just returns the
current values as part of the initial upgrade handshake in case
we want to know.
BUG=chrome-os-partner:57956
BRANCH=none
TEST=make buildall; try on Gru
Make sure that Cr50 can be freely updated and downgraded between
firmwares that speak either v4 or v5 of the protocol, by using
the v5-aware usb_updater tool.
And of course, make sure that v5 images report their keyids. Duh.
Change-Id: If2cc0d4023dca2078b9398fd899618dc2cd409b9
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/394732
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reset-on-hibernate wake performs a soft-reset, which re-initializes GPIO
states to ROM POR values. Therefore, it is necessary to re-init GPIO
states once again based on board-level GPIO settings.
BUG=chrome-os-partner:58077
BRANCH=gru
TEST=Run `hibernate` on gru, wake, then run `bd99955_dump`. Verify
actual register values are printed rather than zeros.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib3eb1dd6aa264d00d42d8e386bfd1ef7f6cf7717
Reviewed-on: https://chromium-review.googlesource.com/395426
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This change adds apreset, ecreset, ec_rst, sys_rst and powerbtn options
to the ccd console command.
BUG=chrome-os-partner:58123
BUG=chrome-os-partner:56835
BRANCH=none
TEST=manual
sysrst resets the AP
sysrst on/off controls SYS_RST_L
ecrst resets the ec
ecrst on/off controls EC_RST_L
powerbtn 500 will simulate a power button press for 500 ms
Change-Id: I89adc88eb407730c9d57811a07bfef8fcf63c5b9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/393809
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch moves I2C_MAX_HOST_PACKET_SIZE to include/i2c.h. It's currently
used only by i2c-stm32*.c but should be commonly available for other chips.
It also moves i2c_get_protocol_info to common/i2c.c for the same reason.
BUG=none
BRANCH=none
TEST=make runtest
Change-Id: I28d8bca0167bb7b2ce99574601a6efb62fc20eca
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/393328
Reviewed-by: Randall Spangler <rspangler@chromium.org>
spi_transaction() can be called from motionsense, hooks, hostcmd,
console, and chipset tasks, so add a mutex to ensure an in-process
transaction isn't preempted by another transaction.
BUG=chrome-os-partner:57912
BRANCH=gru
TEST=On kevin, run "while true; do ectool motionsense odr 0 0; sleep 1;
ectool motionsense odr 0 1000000; sleep 1; done", verify watchdog crash
not encountered after 20 minutes.
Change-Id: I7ec495bab295dc03ce02372c20e5c7c5c196715d
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/391892
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit eabdea443775fab834aaabbb7afae871306c7530)
Reviewed-on: https://chromium-review.googlesource.com/392226
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
- changed the pad assignment for plt_rst_l from DIOA13 to DIOM3;
- removed the board property used to keep uart rx disabled, Uart0 is
now enabled by default on Cr50.
- removed resetting fallback counter on USB updates for reef boards,
they are going to use the same mechanism as kevin and gru.
BRANCH=none
BUG=chrome-os-partner:56540
TEST=Tested on Reef Board ID 1 and Gru Board ID 1. Verfied that
plt_rst_l signal is being detected and that there are no
interrupt storms related to not having a pullup resistor on the
uart rx line. Verified that both platforms successfully boot into
chrome OS using cr50 TPM.
Change-Id: I300a0c75e60acbecf93500b46aced303955a192a
Signed-off-by: Scott <scollyer@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/391140
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When tpm is reset the i2c slave interface initialization function is
called, but it does not quite re-initialize the interface.
This patch adds both a hardware pulse to make sure that the i2c slave
interface state machine is set into the initial state, and code to
zero static variables of the driver.
BRANCH=none
BUG=none
TEST=with the change on the AP firmware side which prevents losing i2c
ready interrupts early in the process tpm reset became much more
reliable. Resetting from EC, AP of cr50 consoles reliably
restarts reef without any TPM communications problems.
Change-Id: I604607c32d4dfc554b245d3d3d82b9ad38271962
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/392306
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Commit 9e7c12b added a command-line option to "make" to build
development versions of the Cr50 board. This makes the symbol
definition useful in makefiles and not just C code.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Id0719d63263b00e192a2e4866dbe1551ae49e23c
Reviewed-on: https://chromium-review.googlesource.com/391127
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The application may need to read/write/erase the flash memory,
but we not want console users to do so. This CL adds
CONFIG_FLASH_PHYSICAL, which allows the higher-level CONFIG_FLASH
to be undefined while still providing the chip-specific
flash_physical_* accessor functions.
There aren't many board.h files that needed changes, since
CONFIG_FLASH_PHYSICAL is enabled by default, just like CONFIG_FLASH.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
See that it still boots, updates, wipes, restores, etc. without
linking common/flash.o in the production image; and that the
flash commands are still there in the dev build.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I7eb1bbcb414b1c70ee427c4fcb5cea899dbb9e93
Reviewed-on: https://chromium-review.googlesource.com/391188
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
And even that's a bit of a stretch. This entire endpoint will
probably be deactivated until it's more useful. In the meantime,
we can just leave the one little debug command for debug builds.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Id4c185fe66d52fa49fcbee6a549df41d297c41af
Reviewed-on: https://chromium-review.googlesource.com/391045
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The rdd features are working (and it's better to test with
hardware anyway), so just delete this command.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ifcfc8c8a0e61a9fe31d28f0c96bcb50c3e2b93b5
Reviewed-on: https://chromium-review.googlesource.com/391314
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The pwm prescaler wasn't being calculated properly when used with
the 32 Khz clock.
BUG=chrome-os-partner:57526
BRANCH=none
TEST=Manuel
- With PWM frequency set to 100Hz, I verified on the scope that
the duty cycle changed from 0 to 100% in 10% increments.
- Verified on the scope that PWM frequency could be set to 100Hz,
200Hz, 300Hz, 400Hz, and 2600Hz.
Change-Id: Idf8ffb6b20d469c9ea58e5a34e944f79d475eb15
Reviewed-on: https://chromium-review.googlesource.com/388814
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
TPM resets happen asynchronously, conceivably there is some interface
(i2cs or sps) activity under way when TPM is reset.
Sps driver provides a means of disconnecting the client of the driver,
while the i2cs driver does not. Come to think of it, there is no real
need to provide a special function to disconnect a client, this makes
API simpler and allows to add driver initialization to the client
registration function.
To make tpm_registers.c more flexible - allow to register a callback
for interface initialization, this way when TPM is reset, the
interface can be also re-initialized and is guaranteed to start from
scratch after reset.
BRANCH=none
BUG=chrome-os-partner:52366
TEST=both firmware_TPMExtend and firmware_TPMKernelVersion autotests
pass
Change-Id: I212166a23f9cd512d8f75315377d1f5620aea070
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388886
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Similar to the TPM SPI interface, added code to disable sleep an I2CS
interrupt is received. Enabling sleep follwoing a 1 second delay when
the TPM fifo register has been read by the host. The I2CS TPM layer
doesn't know when a command has finished, but the one second delay is
more than enough delay since sleep will be disabled again when the
next I2CS interrupt is received.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Tested without these changes first. Shortened sleep delay to 30
seconds, and disconnected suzyq. Waited 30 seconds then issued the
command on the AP console:
tpmc read 0x1007 0xa
[ 59.796813] tpm tpm0: tpm_transmit: tpm_send: error -16
ERROR: write failure to TPM device: Device or resource busy
In addition, using logic analyzer verifed that there was activity on
SDA/SCL but no response from Cr50. With this CL in place, ran the
test and got the following:
tpmc read 0x1007 0xa
2 0 1 0 1 0 0 0 0 4f
With the logic analyzer I was able to confirm that there was no
activity from the host on the I2CS bus until the command was issued.
Change-Id: If07573ae8f72b983bca57979d53c22660b91b95e
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/387910
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Fixed an issue with word aligned write to fifo routine. There were two
errors. In the top section, the fifo was being read always from the
beginning word or the hw fito, but the updated word was written back
to the proper location.
The same error was in the section that dealt with the last < 4 bytes.
Both have been corrected. The error in the top section would in practice
be invisible because flow control prevents TPM fifo reads from
happening while one is in progress. The error in the bottom section
was responsible for the problem as described in chrome-os-partner:57782.
BRANCH=none
BUG=chrome-os-partner:57782
TEST=manual
Used special AP fw build that supports a 'tpm_raw' command to initiate
the Cr50 TPM fifo write/read.
'tpm_raw 0x80 0x01 0x00 0x00 0x00 0x16 0x00 0x00 0x01 0x7a 0x00
0x00 0x00 0x06 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x7f'
Without this CL, the 1st two bytes were incorrect ~50% of the time.
With the fix in place, verified that the first two bytes returned were
always correct.
Change-Id: Iff7620561eee463d599abfa6c07455c56bb5a5a6
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388785
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
cr50 should pretty much never reset, but when it does, for whatever
reason, the device it is running on must reset as well.
This patch makes every cr50 reset (be it command line induced, or
caused by an exception) a hard reset, such that it re-initializes the
R-box, which in turn causes reset of the entire platform.
CQ-DEPEND=CL:361680
BRANCH=none
BUG=chrome-os-partner:55948
TEST=verified that running commands like 'reset' or 'md 0xf0000'
(which triggers an exception) causes the entire chromebook to reboot.
Change-Id: Ifa160450b9b4c5ef25e512caf1ffdced9c97acd6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388007
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Rather than doing a full cr50 reset when the system reset SYS_RST_L is
asserted, just reset the state of the TPM task and library. Re-clear
.bss for those modules, then re-initialize.
BRANCH=none
BUG=chrome-os-partner:52366
CQ-DEPEND=CL:366792
TEST=make buildall; test on Gru
Trigger a SYS_RST_L by using the AP's reboot command, power
off/on, log in/out/in.
See that the Cr50 does not reboot and the firmware and userspace
are still happy about the TPM.
Change-Id: I32cd2bb72316f68c74db77a20a8d09112b402d4b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361680
