Flash operations in do_flash_op() involve waiting polling for the chip
to complete the operation. If a concurrent operation is started while
another operation is in progress, flash gets confused and locks up.
Let's add a mutex to ensure that flash operation runs to completion
before another operation starts.
BRANCH=cr50
BUG=b:67651754
TEST=multiple times ran firmware update while the device was coming up
and saving TPM status in NVMEM. Observed no failures.
Change-Id: I777a38f8a63cf17d60edb11cc3f916a4ea904741
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/894180
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
- Add a vendor command that provides alert counter. Userspace can use
it e.g. for user metric analysis.
- Add 'alerts' debug console command. It provides information about
chip alerts: supported alerts, fuse status, interrupt status, alert
counter.
- Add 'alerts fire [INT]' command to fire a software defined alert
(globalsec/fwN where N is 0,1,2,3).
Signed-off-by: Anatol Pomazau <anatol@google.com>
BUG=b:63523947
TEST=ran the FW at Pyro and checked alerts data sent to host
Change-Id: I7cec0c451ed71076b44dad14a151b147ff1337e8
Reviewed-on: https://chromium-review.googlesource.com/817639
Commit-Ready: Anatol Pomazau <anatol@google.com>
Tested-by: Anatol Pomazau <anatol@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Typically this routine runs on low priority hook task.
A pre-emption by a higher priority task might be mistaken for timeout.
Double check the transfer done status after the timeout time has passed.
Also clear the TXDONE status before starting a fresh transaction to make sure
we wait for the current transaction to complete; an errand TXDONE status
at start of the transaction will pre-empt waiting for the current transaction
and return stale data.
BRANCH=none
TEST=mn50 stress test fails within minutes vs. now stable.
Main test component is higher priority console task
that does intermittent compute during usb-spi transfers.
Change-Id: Ide4390e42d3957bc45eea8160617a52dd31ed866
Reviewed-on: https://chromium-review.googlesource.com/849662
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Some upcoming designs based on the g chip require GPIOs connected to
open drain circuits.
Even though the chip explicitly provides only two open drain GPIOs,
the desired behavior of the rest of the pins when configured as 'open
drain' could be simulated by software if when 'high' is required the
output is disabled instead of driving the pin value.
To make sure there is no fallout from RO driving the pins, also add an
explicit 'disable output' initialization in case a GPIO is configured
for open drain and the initial output value is 'high'.
BRANCH=cr50
BUG=none
TEST=verified that Cr50 booted successfully, also confirmed that on
the test board that GPIOs defined as Open Drain allow we set
output to 1 only if pulled up.
Change-Id: Id2daa19b992bab7fb01148b6fa7b57fd0728b33d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/848152
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Nobody is calling the flush function for consumer_ops structure,
so let's remove it to save flash space, until we find a use for it.
CQ-DEPEND=CL:*529221
BRANCH=none
BUG=chromium:795624
TEST=make buildall -j, saves from 40 to 128 bytes on some boards.
Change-Id: Iad18b30f419ccebc54a90914ec46da84b8d19601
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/826905
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Stalling reset during when CS is asserted is useful to start with, it
was added before out of abundance of caution, but come to think of it,
should the reset happen asynchronously driven be the EC, the AP would
be reset too. And when AP is reset on its own accord, it would not be
transmitting anything on the SPI interface.
On top of that it turns out that in some cases reset on ARM platforms
is accompanied by the CS line driven low, which causes infinite loop
if Cr50 is waiting for CS to deassert before proceeding.
BRANCH=cr50
BUG=b:67008109
TEST=verified that RMA reset operates properly on both ARM and x86
platforms.
Change-Id: I43efd0cefa5d6eb543dfd27e3c9fb3b4bf1a8ea6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/791818
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
We were using bn_modexp() to perform a simple modular square.
A bn_modexp_word() does this faster.
BRANCH=none
BUG=b:68167013
TEST=generate 128 primes from prng seed and verify they're same as before; tcg_test passes
Change-Id: I411a7d3fe2d68f93dc40bf74b941a637f9aa20ed
Reviewed-on: https://chromium-review.googlesource.com/778057
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Sometimes the AP will generate a short 'wake' pulse on the SPS CS line
just in case the chip is in the sleep state. This pulse is supposed to
wake up the chip and prepare it to process the actual SPS transaction
which follows the wake pulse in 100 us.
It turns out that under certain conditions it takes the Cr50 longer
than 100 us to react to the wake pulse, for instance when it writing
into flash which is in the same bank the code is running from, there
is no way to avoid stalling in this case.
What happens then is that the 'CS deasserted' interrupt for the wake
pulse comes while the actual SPS transaction is in progress. In this
case when processing the CS deassertion interrupt the Cr50 should not
consider it an end of a transaction, but just ignore it making sure
that the next CS deassertion still would trigger an interrupt.
BRANCH=none
BUG=b:68012381
TEST=verified that this patch helps the AP firmware test case which
was often failing due to TPM getting out of sync.
Change-Id: I412459552f4b2d13cd72800c1af7d583226e8466
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754505
TPM reset processing takes certain time, and conceivably the AP could
start SPI transactions before TPM reset is finished. If the SPS
interface comes up while the CS line is active, the H1 controller
considers this a start of the SPI cycle, even though it is not - the
AP has already transferred the header and is waiting for the flow
control.
Let's not complete SPS interface initialization while the CS line is
kept active.
BRANCH=cr50
BUG=b:68012381
TEST=verified that the AP firmware test passes
Change-Id: I53cd49c6139f3c29c4b6d234c7ee4d527c8282f6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754504
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is no point in invoking SPS receive handler if there has been no
data transferred while CS was asserted, as would be the case when the
AP generates the wake up pulse.
Also, make sure that the flag indicating that data was seen is cleared
when the interface is reinitialized, as TPM reset could come during an
SPS transaction.
BRANCH=cr50
BUG=b:68012381
TEST=verified that the AP firmware test passes
Change-Id: I82d63d257b67a715d6dbc540c2d7480e5ff718ff
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754503
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Events used when TPM task is running are defined in two different
places, one of them shared with other boards running on H1.
Let's avoid collision by redefining Cr50 only events to be different
from shared ones used by dcrypto.
BRANCH=cr50
BUG=b:68729265
TEST=verified that there is no more 'tpm_reset_request: already
scheduled' messages generated when TPM is reset when performing
long dcrypto operation.
Change-Id: Ic9517fa98be21f3ef5f19b82c593d96b0ddbaf6b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756914
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently the Cr50 code resets TPM communications layer at a certain
point during TPM reset process.
It turns out that this is not sufficient - the comms layer keeps
receiving and trying to invoke TPM layer, which does not mesh well
with TPM reset.
Let's provide two callbacks for each comms layer - to shut it down and
to bring it back up. We shut down the comms when starting TPM reset
and bring them back up when reset is completed.
BRANCH=cr50
BUG=b:68012381
TEST=ran AP firmware test suite on both SPI and I2C based devices.
Change-Id: I7caf4a09b9a5c6e5fc6bfe60eae1c0d64ab24904
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754502
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
gcc 6.3 (as provided by coreboot-sdk) needs that to know which code
paths end early.
Also add a loop after the command that is "supposed" to reset the
machine so that the compiler believes it (and in case that assumption
fails).
BRANCH=none
BUG=b:65441143
TEST=none
Change-Id: Idb87253ec7880d66ffec30d75f4d007f02f63aab
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/742916
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
In some scenarios we want to take RW updates w/o taking version numbers into consideration,
much like the behavior we get w/ CR50_DEV.
But then without the additional CR50_DEV features enabled for the rest of the code.
BRANCH=none
BUG=none
TEST=compiles
Change-Id: I7dd946ab77bbdc35850ed934cd53735418e13845
Reviewed-on: https://chromium-review.googlesource.com/724967
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Trybot-Ready: Marius Schilder <mschilder@chromium.org>
It turns out the code logic is not exactly correct: the range for
coarse trim values is 0..0xFF.
Use the fixed top of the range value and do not print messages if the
value is at the range boundary.
BRANCH=cr50
BUG=b:67788437
TEST=Observed occasional messages on the Cr50 console when
plugging/unplugging Suzy-Q, but not the constant spew.
Change-Id: I94ab581769ba8326346b636b1342136e98d61ff1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/723981
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Previously, an error reading Board ID would prevent any image from
running, even a wildcard (unrestricted) image with mask=flags=0 which
would match any Board ID.
Now, if Board ID can't be read, match the image against
type=type_inv=flags=0. This will match only an unrestricted image.
(This is better than checking directly for an unrestricted image,
because that check is more susceptible to clock-jitter-induced errors.)
BUG=b:67651806
BRANCH=cr50
TEST=Hack read_board_id() to return error. See that an unrestricted
image will now boot.
Change-Id: I1071e146b4541e8efd50c8409b8f76012a107731
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/713574
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Add a PERSO_AUTH appid to sign data passed through the
AUTH mn50.
Add a signer command to start and generate signatures.
Clean UART init to avoid spurious nonprinting characters
that will contaminate the siugnature.
BUG=b:36910757
BRANCH=None
TEST=generates signature for uart and spi
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: I5fc3c4ee34898421060b57b774a09734f6a1bae5
Reviewed-on: https://chromium-review.googlesource.com/670984
Reviewed-by: Marius Schilder <mschilder@chromium.org>
To aid with severe flash space shortage, let's enable
CRYPTO_TEST_SETUP only if CR50_DEV is set to a value exceeding 1.
board/mn50/board.h used to define CR50_DEV without any value assigned
to it, correct this so that the check in dcrypto.h works when mn50 is
built.
BRANCH=cr50
BUG=b:65253310
TEST=compiling with CR50-DEV=1 vs CR50_DEV=2 saves more than
17.5 Kbytes per RW image.
Change-Id: Ic77fa45b1a8f7631efa91c08e63438d412196eed
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690993
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The array storing deltas between sequential prime numbers could be
compressed, as the vast majority of the values in the array does not
require more than 4 buts to store.
The new storage format is as follows:
- each differential value (difference between two consecutive primes)
is halved and stored in 4 bits, two halved values are packed per
byte.
- I the first one of of the two sequential halved values exceeds 0xf,
it is stored in the array followed by a zero, stored as is (without
halving), thus taking two bytes.
- if the second one of the two sequential halved values exceeds 0xf,
both values are stored in the array as is, both prepended by zeros,
thus taking 4 bytes.
The code calculating the sequential primes parses the array according
to this format. Storing the primes in this format allows to shave from
the image size 1848 bytes.
BRANCH=cr50
BUG=b:65253310, b:65287300
TEST=verified that test_rsa test from the tpmtest suite passes.
verified that the list of prime numbers printed out when
PRINT_PRIMES is defined and test_rsa is ran is the same before
and after this patch.
Change-Id: Ifdc2858a48f868ef816ccb4e351d9f60703d16e7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/664253
Reviewed-by: Nagendra Modadugu <ngm@google.com>
This change is required to reboot the chip without bringing down the
entire platform on boards where GPIOs are wired to external active reset
signals.
BRANCH=none
BUG=none
TEST=Scoped a pin across a reset.
Change-Id: I58d93697d39a8adcdac9324d5dd9da00745aec9a
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/644179
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When compilation is enabled, this function prints all prime numbers
generated using the PRIME_DELTAS array.
BRANCH=cr50
BUG=none
TEST=verified that prime numbers are printed out when running rsa_test.py
Change-Id: I37961aad146c4aeecca9a84550f313450e6c5853
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/683074
Reviewed-by: Shawn N <shawnn@chromium.org>
The WebUSB specification defines a specific Platform Descriptor in the
Binary Object Store:
https://wicg.github.io/webusb/#webusb-platform-capability-descriptor
This descriptor provides a special 'Landing page' URL to the host
browser and associated privileges for it.
Bump the USB version for BOS descriptors to 2.1 to be compatible with
Chrome implementation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=none
BRANCH=twinkie
TEST=manual: on Twinkie (chip/stm32) and HG proto2 (chip/g), enumerate
WebUSB descriptors with lsusb and connect to a WebUSB page in Chrome
R61+.
Change-Id: I7211ab554f4a6c156c1e8e79a3d9f0d6644217c6
Reviewed-on: https://chromium-review.googlesource.com/664813
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the USB 2.0 specification, the "8.5.3 Control Transfers"
chapter says that "When all of the data structure is returned to the host,
the function should indicate that the Data stage is ended by returning a
packet that is shorter than the MaxPacketSize for the pipe. If the data
structure is an exact multiple of wMaxPacketSize for the pipe, the function
will return a zero-length packet to indicate the end of the Data stage."
When doing a 'Control Read' transfer and the returned data (in IN
packets) was a multiple of MaxPacketSize, we were omitting the
zero-length packet and so the host was blocked waiting for a successful
IN transaction.
This corner-case was a regression introduced by the re-writing of the
control transfer handling done by CL 318864. So the STM32 USB code which
is similar to the former code is dealing properly with this case.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=none
TEST=manual, extend the configuration descriptor to be exactly 64 bytes,
and see the enumeration is no longer failing.
Change-Id: I108e8c6bb9eb727c41f3e1c607f0919fa1192d5a
Reviewed-on: https://chromium-review.googlesource.com/664814
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
lsusb scans for USB_DT_DEBUG, which produces logspam
on the cr50 console. This isn't an error, just unimplemented.
Remove the printout.
BRANCH=cr50
BUG=b:65407184
TEST=no logspam on lsusb
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: Ib4fc7105015506927f45ee02f587f97e46e1ad9b
Reviewed-on: https://chromium-review.googlesource.com/663786
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For historical reasons, CCD, reset, and power button control were
scattered around several files. Consolidate the code in more sensible
(in retrospect) places.
No functional changes, just moving code.
BUG=none
BRANCH=cr50
TEST=make buildall; boot cr50
Change-Id: Ic381a5a5d0627753cc771189aa377e88b81b155e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/653766
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In USB FS on a bulk/interrupt endpoint, the transactions normally toggles
between DATA0 and DATA1 PIDs.
After a USB suspend/resume cycle, we need to restart from the PID we
were at before suspend.
In our current code, when going to deep-sleep during USB suspend, we are
re-initializing everything when the MCU restarts at each resume. So we set
implicitly the PID to DATA0. The USB Hardware IP just silently discards the
packet when the PID of an incoming OUT packet is not matching the
expectation in the endpoint register.
In order to preserve DATA PIDS, record the state of the PID toggling on
each endpoint when going to deep-sleep and restore it during the USB
initialization.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:38160821
TEST=manual, plug a HG proto2 on a Linux host machine and enable
'auto-suspend' for this USB device. Let it go to sleep and wake-it up by
sending a U2FHID request. Repeat the process several times and see that
the key answers every time (while it was failing after the second cycle
before).
Change-Id: I75e2cfc39f22483d9e9b32c5f8b887dbafc37108
Reviewed-on: https://chromium-review.googlesource.com/655238
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Currently, the Cr50 state machines (EC, AP, RDD, bitbang, etc.) manage
their own enabling and disabling of the ports (UART, SPI, etc.) This
is tricky because the rules for when ports should be enabled are
non-trivial and must be applied in the correct order. In additionl
the changes all need to be serialized, so that the hardware ends up in
the correct state even if multiple state machines are changing
simultaneously.
Consolidate all of that into chip/g/rdd.c. The debug command for it
is now 'ccdstate', which just prints the state machines. This will
allow subsequent renaming of the 'ccdopen', etc. commands to 'ccd
open', etc.
Also include UART bit-banging into that state which must be
consistent. Previously, it was possible for bit-banging to leave UART
TX connected, instead of returning it to the previous state.
Use better names for CCD config fields for UART. I'd had them backwards.
BUG=b:62537474
BRANCH=cr50
TEST=manual, with a CR50_DEV=1 image
1) No servo or CCD
Pull SERVO_DETECT low (disconnected)
Pull CCD_MODE_L high (disabled)
Pull EC_DETECT and AP_DETECT high (on)
Reboot. RX is enabled even if cables are disconnected so we buffer.
ccdstate -> UARTAP UARTEC
Pull EC_DETECT low.
ccdstate -> UARTAP
Pull EC_DETECT high and AP_DETECT low.
ccdstate -> UARTEC
Pull AP_DETECT high.
ccdstate -> UARTAP UARTEC
2) Servo only still allows UART RX
Pull SERVO_DETECT high (connected).
ccdstate -> UARTAP UARTEC
3) Both servo and CCD prioritizes servo.
Pull CCD_MODE_L low (enabled).
ccdstate -> UARTAP UARTEC
Reboot, to make sure servo wins at boot time.
ccdstate -> UARTAP UARTEC
Bit-banging doesn't work when servo is connected.
bitbang 2 9600 even -> superseded by servo
bitbang -> disabled
ccdstate -> UARTAP UARTEC
4) CCD only allows more ports and remembers we wanted to bit-bang
Pull SERVO_DETECT low.
ccdstate --> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate --> UARTAP+TX UARTEC+TX I2C SPI
Reboot and see we don't take over servo ports until we're
sure servo isn't present.
ccdstate --> UARTAP UARTEC (for first second)
ccdstate --> UARTAP+TX UARTEC+TX I2C SPI (after that)
5) Bit-banging takes over ECTX
bitbang 2 9600 even
bitbang -> baud rate 9600, parity even
ccdstate -> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate -> UARTAP+TX UARTEC+TX I2C SPI
6) Permissions work. Allow easy access to full console and ccdopen:
ccdset OpenNoTPMWipe always
ccdset OpenNoLongPP always
ccdset GscFullConsole always
Default when locked is full AP UART EC RO, no I2C or SPI
ccdlock
ccdstate -> UARTAP+TX UARTEC
No EC transmit permission means no bit-banging
bitbang 2 9600 even
bitbang -> disabled
ccdstate -> UARTAP+TX UARTEC
But it remembers that we wanted to
ccdopen
ccdstate -> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate -> UARTAP+TX UARTEC+TX I2C SPI
Try turning on/off permissions
ccdset UartGscTxECRx always
ccdlock
ccdstate -> UARTAP+TX UARTEC+TX
No read means no write either
ccdset UartGscRxECTx ifopened
ccdlock
ccdstate -> UARTAP+TX
ccdopen
ccdset UartGscRXAPTx ifopened
ccdlock
ccdstate -> (nothing)
Check AP transmit permissions too
ccdopen
ccdset UartGscRxAPTx always
ccdset UartGscTxAPRx ifopened
ccdlock
ccdstate -> UARTAP
Check I2C
ccdopen
ccdset I2C always
ccdlock
ccdstate -> UARTAP I2C
SPI port is enabled if either EC or AP flash is allowed
ccdopen
ccdset flashap always
ccdlock
ccdstate -> UARTAP I2C SPI
ccdopen
ccdset flashec always
ccdset flashap ifopened
ccdlock
ccdstate -> UARTAP I2C SPI
Back to defaults
ccdoops
Change-Id: I641f7ab2354570812e3fb37b470de32e5bd10db7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/615928
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
There is no point in updating the Cr50 to an image which will not be
allowed to run due to board ID settings mismatch.
This patch modifies the prototype of check_board_id_mismatch() to
allow to pass to this function an arbitrary pointer to an image
header, so that the function can check not only the image in the flash
memory, but also the image which just arrived over the line.
The contents_allowed() function now checks if the new image is
compatible with the Board ID value in Info1 and rejects the new image
if there is a mismatch.
BRANCH=cr50
BUG=none
TEST=tried updating a Cr50 to an image which is incompatible with the
Info1 fields contents. The update attempt is rejected. Verified
that updating to a compatible image still works as designed.
Change-Id: I3d6c16df11fcabd05888f3cbf5e9a81dc51fe66f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/650812
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When checking if the new contents are allowed the updater can reject
the image for different reasons, let's make it possible to pass the
actual rejection reason to the caller of the contents_allowed()
function.
BRANCH=cr50
BUG=none
TEST=verified that attempts to update to an older image are still
being rejected with the proper error code (as generated by
contents_allowed() now).
Change-Id: I24ac7671c4f461ec089f272581723ec2c3a232ff
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/650811
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently, only usb_pd_protocol.c cares about the actual ccd mode
(disabled/partial/enabled). Everything else just cares whether it's
enabled or not. So promote the boolean ccd_is_connected() from
board/cr50 up to chip/g, and rename it to ccd_ext_is_enabled() to
match the new nomenclature (since 'CCD' itself is now too overloaded).
This will make it easier to handle CCD state directly in board/cr50
after we split it from common/case_closed_debug.c
BUG=none
BRANCH=cr50
TEST=make buildall; boot cr50; make sure USB endpoints still work
Change-Id: Ic3df7467bfe29f1c5d7060cac1309a1f0e090d9e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/648212
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
CCD_CHANGE_HOOK should use CONFIG_CASE_CLOSED_DEBUG_V1.
All boards which use chip/g either use both CONFIG_USB_SERIALNO and
CONFIG_CASE_CLOSED_DEBUG or neither of them, so just depend on
CONFIG_USB_SERIALNO.
This is in preparation for making common/case_closed_debug refer only
to the usb_pd_protocol version (with mode=disabled/partial/enabled),
and cr50 will have its own version (with only enabled/disabled, and
tied more closely to CCD config).
No functionality changes.
BUG=none
BRANCH=cr50
TEST=make buildall -j; boot cr50 and see change hook called
Change-Id: I1985c8c48c1a85fed4549402a7b47b8a9cf135d7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/648067
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Previously, chip/g/rdd provided a method for an external console
command to override the Rdd cable detect state. But since we'll be
refactoring the 'ccd' command, it's tidier to move this to a console
command inside the rdd driver itself.
BUG=none
BRANCH=cr50
TEST=manual, with no debug cable present
rdd enable -> Rdd connect
rdd -> keepalive
rdd disable
rdd -> connected (hasn't had a chance to run state machine)
(wait <1 sec)
rdd -> debouncing
(wait 1 sec) -> Rdd disconnect
Change-Id: I141eedf8070b4ad2c96cc5a364f4e37dc29bed70
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/647991
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently, the console inhibited output when is_readonly=1, and only
inhibited input when is_enabled=0. That's harmless in the current
implementation, because common/case_closed_debug() only ever calls it
with enabled=0/readonly=1 or enabled=1/readonly=0. But if we ever do
decide to use enabled=1/readonly=1, that would have acted like
write-only, not read-only.
Fix that.
BUG=none
BRANCH=cr50
TEST=Attach to cr50 USB console, console is read/write.
Hack USB console to set is_readonly=1, console is read-only.
Change-Id: I04258fe2b040a00f98067d8be48a0632eb16e9c1
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/647336
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Add a function to translate device_state enum into a string, then use
it for printing the ec and RDD state.
Refactor ec_state so that all state transitions go through a
set_state() function, which makes it easier to turn on debugging all
state transitions. That's normally not compiled in because it would
be spammy during debouncing.
BUG=none
BRANCH=cr50
TEST=ccd command prints EC and RDD states
Change-Id: Ie7bc56c7b66beee23d1d1989711c640e5e39ce43
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/642121
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
On some boards, it was seen that SuzyQable wasn't detected by the rdd
block. The voltage around 0.4V is marginal with a Vbus around 4.75V.
This commit simply adjust the 0.4V comparator reference voltage to 0.3V
in order to make the detection work.
BUG=b:64847312
BRANCH=cr50
TEST=Find a soraka where SuzyQable didn't work. Verify with this patch,
it does work. Additionally, verify that servo_v4 continues works.
Change-Id: If54630ec469408031cd84ffb93ef5fea42bdee3b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/633403
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently, chip/g uses jtag_pre_init() to do some chip
pre-initialization that isn't actually related to JTAG. This has been
harmless, but it's currently the only chip which actually does "JTAG"
pre-init, and we'd like to get rid of that. So, move that
functionality to a new optional chip_pre_init() function.
BUG=chromium:747629
BRANCH=cr50
TEST=make buildall
boot cr50
make all dis; confirm chip_pre_init() is called early in <main>
Change-Id: I3cae0747ab0c3cc974fce9f108947207b38e035f
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/629876
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
We want to be able to collect statistics of the i2c bus problems. This
patch logs an event each time the wedged bus recovery happens.
BRANCH=cr50
BUG=b:63760920
TEST=with the upcoming patches verified that i2c recovery events are
logged as expected.
Change-Id: I1241b2dece33f89cd724d53a48f94e17f4415c62
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/620114
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
A common failure condition on the i2c bus is when the master
unexpectedly stops clocking the bus while the slave is driving the SDA
line low. In this case the master is not able to issue Stop or Start
sequences, which makes the bus unusable.
Good slave controllers are able to detect this condition and recover
from it by removing the pull down from the SDA line. This patch adds
this capability to the g chip i2c slave controller.
A new timer function is created which samples the SDA line twice a
second. If it detects that SDA is low in two consecutive invocations
and the number of i2cs read interrupts has not advanced, it decides
that the "hosed slave" condition is happening and reinitializes the
i2c driver, which removes the hold from the SDA line.
Even though the state of the SDA line is supposed to be accessible
through the I2CS_READVAL register, it in fact is not, reads always
return zero in the SDA bit. To work around this a GPIO (port 0, bit
14) is being allocated to allow to monitor the state of the line, it
is multiplexed to the same pin the SDA line uses.
When the AP is in low power modes the SDA line is held low, this state
should not trigger i2c reinitializations.
CQ-DEPEND=CL:616300
BRANCH=none
BUG=b:35648537
TEST=connected H1 on the test board to an I2c master capable of
stopping clocking mid byte. Observed that the existing code would
just sit in the "hosed" state indefinitely. The code with the fix
recovers from the condition (drives the SDA line high) 500ms to
1s after the failure condition is created.
Change-Id: Iafc7433bbae9e49975a72ef032a923274f8aab3b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/614391
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Add a delay to allow the clocks and usb signals to settle.
BUG=b:63767046,b:63867566
BRANCH=cr50
TEST=put the eve ec into hibernate, wait until cr50 enters deep sleep,
use the uart to wake it up, and verify that it eventually reenters deep
sleep
Change-Id: I26463ce3e00996368a791a245b0f9de01737478c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/598448
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We previously disabled the USB PHY to the AP. But the BOARD_AP_USB
property lingered on. Remove the property.
Also clean up the idle task deciding when to do utmi wakes. With the
AP USB connection disabled, that's only necessary when the debug cable
is attached, so we can check that explicitly.
BUG=none
BRANCH=cr50
TEST=make buildall; boot CR50_DEV=1 image
Change-Id: If81a7bcfe845d9d70dcc7e16239244a4f5f2427b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/616301
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The device_state module is used for debouncing GPIO inputs to
determine device sstate. It was overkill for managing the CCD cable
(RDD) attach/detach state, and split that handling between 3 files
(board.c, rdd.c, device_state.c). Move all of that logic into rdd.c
so it's easier to maintain.
BUG=none
BRANCH=cr50
TEST=manual
plug in CCD cable (or ground DIOM1)
ccd command reports cable connected and AP UART TX+RX
unplug CCD cable (or un-ground DIOM1)
ccd command reports cable disconnected and AP UART disabled
Change-Id: Id8fcd3a51605ae7a4843668ea18dd0ef84aceb2c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/604499
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Implement the RFC 6979 to get a deterministic integer k when doing the
ECDSA signing of the x.509 certificates used by U2F and particularly
individual attestation mechanism, rather than using the random generator
as per the original ECDSA algorithm.
So the generated certs have bit-for-bit identical signatures when the
content is identical.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=pass U2FTest and manually dump several individual attestation certs,
run the "rfc6779" console command when enabled.
Change-Id: I7b73eee6d5a863aae9a7eec49db884151bad5ab4
Reviewed-on: https://chromium-review.googlesource.com/558073
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The new signer (version: 1.2 00840c1b6) allows hex values in the
manifest, which means there is no need to explicitly convert the
values before adding them to the manifest.
A nice side effect of this is the fact that there is no need to care
about the sign of the values any more, the signer does the right
thing.
BRANCH=none
BUG=none
TEST=built an image using the following invocation:
$ make BOARD=cr50 H1_DEVIDS='0x12009015 0x90e95664' -j
and successfully ran it on a device. Note that the old signer was
chocking on hex values exceeding 0x7fffffff, the new one handles
them properly.
Change-Id: I08c0339f922d287c82d56fb51570bfbf7107531e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/598728
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Save a small amount of time when the USB resume is making the chip boot
from deep-sleep by removing the verbose serial traces in main and
increasing the usb initialization priority.
This brings us from borderline timings wrt the USB specification to a
reasonable margin.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:38160821
TEST=run on hotelgolf, go to deep-sleep on USB-suspend.
On USB resume, measure the time from CPU boot to the end of usb_init
using the CPU cycle count. We are shaving 1.3ms.
Change-Id: Ia5bf69c0ca26748dec59a87f3908a5fe68296b36
Reviewed-on: https://chromium-review.googlesource.com/563206
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
