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>
Remove the code switching between PHY0 and PHY1. We now only use the CCD
PHY on all boards.
BUG=b:36488273
BRANCH=cr50
TEST=ccd works fine. cr50 usb doesn't show up on the AP. You cannot
switch the PHY on cr50.
Change-Id: I6ff641af9d7129daa8592f952f9df97c3862395b
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/595201
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
AP and EC UART now use the CCD V1 capabilities to determine when
access is allowed. Transmit to AP and EC can be toggled independently
from read access to output from those UARTs.
Note that disabling read access disables both transmit and receive.
That is, it's not possible to set a UART where transmit is allowed but
receive isn't. Why would you want to do that, anyway?
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=cr50
TEST=manual with CR50_DEV=1
ccdoops
ccdset cr50fullconsole always -> so we can use ccd command for testing
ccd -> AP RX+TX, EC RX+TX
ccdset uartecrx unlesslocked
ccdset uartectx ifopened
ccdset uartaprx always
ccdset uartaptx unlesslocked
ccdunlock
ccd -> AP RX+TX, EC RX
ccdlock
ccd -> AP RX, EC disabled
ccdoops
ccdset cr50fullconsole always
ccd -> AP RX+TX, EC RX+TX
ccdset uartaprx ifopened
ccdlock
ccd -> AP disabled, EC RX
Change-Id: I55db5897bb52cd60658ab221eadf5c59fc86744a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/595196
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
When in factory mode, we should not be trying to figure out board
strapping options, just enable SPI interface so that the tester can
communicate with the chip.
Also, to close the loop with the tester, let's add indication of the
cert installation result, by setting the two top bits of the DUMMY
(aka underrun) character to 1 and the lower bits to the endorsement
operation result (0 means success, nonzero values communicate
different failure modes) and by preventing the TPM driver from sending
anything but underrun chars on the SPI interface.
BRANCH=cr50
BUG=b:63686091
TEST=pending
Change-Id: I1a22ed6988ad87dd929a393359c4604e6ecd3b58
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/578651
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Because that's what it means. That is, it reports the state of
uartn_tx_connect(), not uartn_enable().
No functional changes; just a rename.
BUG=none
BRANCH=cr50
TEST=make buildall -j
Change-Id: Ie2273b277bd73a40307be7ec215417c1225cd567
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/590859
SPI access now depends on CCD_CAP_AP_FLASH and CCD_CAP_EC_FLASH.
usb_spi_state.enabled_host and .enabled_device are now bitfields which
depend on which SPI interface is enabled. This was implied before by
a single & comparing enabled_host to enabled_device, but is now
explicit so that the device can decide to enable just a subset of
buses.
BUG=b:62537474
BRANCH=cr50
BRANCH=cr50
TEST=manual with CR50_DEV=1
Connect host PC to dev board USB port
On host PC:
sudo servod -c ccd_cr50.xml -c reef_r1_inas.xml
In test protocol below, (test EC) means this command:
sudo flashrom -p raiden_debug_spi:target=EC --wp-status
And (test AP) means this command:
sudo flashrom -p raiden_debug_spi:target=AP --wp-status
"pass" means no console warning about "SPI access denied"
"fail" means console warnings about "SPI access denied"
To get even more confirmation, in chip/g/usb_spi.c temporarily
put this debug statement at the end of usb_spi_deferred():
CPRINTS("SPI res=%d", (int)res);
Pass is res=0, fail is res=5.
ccdoops
(test AP) --> pass
(test EC) --> pass
ccdunlock
(test AP) --> fail
(test EC) --> fail
ccdoops
ccdset flashap unlesslocked
ccdunlock
(test AP) --> pass
(test EC) --> fail
ccdoops
ccdset flashec unlesslocked
ccdunlock
(test AP) --> fail
(test EC) --> pass
Change-Id: I3d37d088b748832f164f2ca0ff29a93d6532ebed
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/590858
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
One Time Programmable memory can be used to store permanent data like
serial numbers.
Reorganize the code to support writing serial number to OTP, in
addition to pstate (if using its own memory bank) or autogenerate from
unique id (hammer).
+ Add CONFIG_OTP to enable OTP code
+ Add CONFIG_SERIALNO_LEN to indicate the size of the serial number
string. Currently set to 28, when USB serial number is needed.
+ Expose flash_read|write_pstate_serial and add otp_read|write_serail,
remove more generic flash_read|write_serial.
+ Make board_read|write_serial generic, declared outside of USB subsystem.
Priority order to read|write serial string:
- board definition (like hammer)
- pstate location, if stored in its private memory bank
- otp area
If none of these methods are available, a compilation error is raised.
BUG=chromium:746471
BRANCH=none
TEST=compile
Change-Id: I3d16125a6c0f424fb30e38123e63cf074b3cb2d3
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/580289
Reviewed-by: Nick Sanders <nsanders@chromium.org>
hwtimer ticks at 8 * 32768 Hz rather than 250 KHz, so adjust our timing
appropriately. Also ensure that udelay() will delay for at least the
requested time, taking into account our timer precision.
BUG=b:63858553
TEST=Generate square wave with 1000us udelay between GPIO edge toggle,
verify period is 1000us + code overhead. Also verify timer behavior on
overflow with 'forcetime' command. Also verify accuracy of system clock
to 0.2% with `timerinfo` and a stopwatch.
BRANCH=None
Change-Id: I5da41bd7250db87de5143cc54ebd0bb750fb7003
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/578551
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Split bn_modexp() into three variants:
bn_modexp() for large exponents (as before)
bn_modexp_word() for single word public exponents
bn_modexp_blinded() for large exponents w/ randomization
We randomize bn_modexp_blinded() with:
1) pick 64 bit random R1 and compute R1 ** -1 and R1 ** pubexp, mod N.
2) multiply input by R1 ** pubexp
3) pick 64 bit random R2 and add (e*d*R2 - R2) to private exponent (i.e.
a random multiple of phi(N))
4) exponentiate
5) multiply output w/ R1 ** -1 to obtain expected result
Since we enlarge the exponent, bn_modexp_blinded() is slower than
bn_modexp(). We only use bn_modexp_blinded() when private exponents are
in play and we have phi(N) available.
Also refactored the combined p256 and rsa dcrypto binary blob into two
parts. And added unique first word to each dcrypto blob to make code
caching reliable.
The TPM task stack maxes out at 8040/8192 in tcg_test due to increased
stack usage of bn_modexp_blinded() but is still within safe bounds,
with 88 byte redzone.
BRANCH=cr50
BUG=b:35587382,b:35587381
TEST=buildall, tcg_test (200+)
Change-Id: Ied1f908418f31f8025363179537aa4ebd2c80420
Reviewed-on: https://chromium-review.googlesource.com/540684
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
After entering prepare_to_sleep() and doing interrupt_disable(), if an
interrupt happens, it will stay pending (as the handler is masked).
Then, when calling 'wfi' in __idle(), we will go through the instruction
rather than entering deep-sleep (if requested) as we have a pending
interrupt.
The downside of this corner case is that we never undo the actions done
to prepare for deep-sleep in the IDLE_DEEP_SLEEP clause of
prepare_to_sleep(). For USB suspend, this means that on the subsequent
deep-sleep entry, we are going to try to save GR_USB_CFG/the USB
device address while the USB controller is already in reset/power-down,
recording a null value in SCRATCH18. Then, at resume time, we will
restore 0 in USB_CFG and the USB device will no longer work.
As the USB configuration is difficult to restore in case of deep-sleep
abortion, simply skip writing a bogus value in SCRATCH18 on the real
deep-sleep entry happening afterwards. This is good enough to resume
properly on USB.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:38160821
TEST=manual: add a (long) panic_printf trace in prepare_to_sleep() in
order to dramatically increase the probability of getting an
interruption pending after entering the function. On cr52, trigger USB
suspends by suspending the host, and see we no longer regularly get a
null USB device address at USB resume.
Change-Id: Ied3fc003eefe7fc164a320b15b5f9d400551198e
Reviewed-on: https://chromium-review.googlesource.com/559332
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>
Don't discard irqprio data when the IRQ_PRIORITY macro is used directly
(for watchdog / watchdog timer).
This change is probably a NOP for all platforms, since the power-on
default for the IRQ prio register seems to be zero, which is the same
priority we're setting in our direct use of IRQ_PRIORITY.
BUG=chromium:634701
BRANCH=None
TEST=Verify 'prio_44' entry exists in irqprio section by checking
ec.RO.map on kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Idaffc484a2ce4749c18212f179b3951ff570aed0
Reviewed-on: https://chromium-review.googlesource.com/545201
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The INFO1 mask field contents serves as input for the rollback
protection mechanism, when the RO decides if an RW is allowed to run
on the device.
The existing code updates INFO1 mask to match the lowest rollback
priority of the two images (RW_A and RW_B) present on the device.
INFO1 mask should be also updated when the current image is endorsed
by the host. In this case the alternative RW is destroyed, so the
INFO1 mask could be set based solely on the currently running image.
This patch refactors the code to allow setting INFO1 mask based on one
or both RW headers' contents.
BRANCH=cr50
BUG=b:62138152
TEST=verified that "normal" INFO1 mask updates still work as before,
the mask is modified to match the image with the lowest rollback
priority.
Also verified that when the VENDOR_CC_INVALIDATE_INACTIVE_RW
command is received the INFO1 mask is updated based on the
currently running image.
Change-Id: I23172388674e1f3a4c2489e139dd197a84029f54
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/541738
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reject updates for the first 60 seconds after a hard reboot. This should
prevent people from using the reboot at the end of an update to get
around the update rate limiting. Reboots don't happen during normal cr50
operation, so this should not prevent updates. It will just prevent
updating cr50 many times in a row.
This change does not limit updates after deep sleep or POR.
BUG=b:62097097
BRANCH=cr50
TEST=Try to update cr50 two times. Verify that on the second time the
update is rejected. Put cr50 into deep sleep, wake it up and verify it
can be updated immediately. Get cr50 to do a POR and verify it can be
updated immediately.
Change-Id: I828ef210e1c5bcf59d4753b8178ee4e1369d5d36
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/520727
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add support for update related vendor commands in mn50 by relocating
relevant code from board/cr50 to chip/g.
BUG=b:36910757
BRANCH=None
TEST=./extra/usb_updater/usb_updater -d 18d1:502a build/mn50/ec.bin
Change-Id: Iec0fe5585b5b6eb099f9254dfb0e5b02d5106abc
Reviewed-on: https://chromium-review.googlesource.com/537999
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Holding the mutex just around the dcrypto_call is not enough: dcrypto
instruction memory content might change in presence of multiple calling
tasks.
Switching to broad acquire/release pattern instead.
Note to sub-projects: pair your dcrypto_init(_and_lock) w/ matching dcrypto_unlock
BUG=none
BRANCH=cr50
TEST=tcg_tests pass
Change-Id: Idb7f2d79ce533db95cab51d89e3869ecf9f3d499
Reviewed-on: https://chromium-review.googlesource.com/535916
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Nadim Taha <ntaha@chromium.org>
with the board ID match happening in the RW we need to be able to set
the rollback counter to a value which would guarantee a fallback
during the next boot.
BRANCH=cr50
BUG=b:35586335
TEST=with the rest of the patches verified the ability to set the
counter to trigger a fallback on the next reboot.
Change-Id: I161f39354e5523121e26e8ad84a791a8b06e5123
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535976
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Until the Board ID check is moved to RO, it is possible to start an RW
with a mismatching Board ID.
Let's add a function to check for mismatch and report the status.
Also eliminating the unnecessary check for empty header Board ID field
- it is going to match any board ID anyways and fixing a CPRINTF
statement in read_board_id().
BRANCH=cr50
BUG=b:35586335
TEST=verified that empty board ID header does not trigger a mismatch
on a board with a non-empty INFO1. With the rest of the patches
applied verified that board ID mismatch is reported properly.
Change-Id: Ie03f8137e494117b7a238e3af72527e0a46369e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535975
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In the FIDO U2F Authenticator Transports Extension, the list of
transports will be extended to:
FIDOU2FTransports ::= BIT STRING {
bluetoothRadio(0), -- Bluetooth Classic
bluetoothLowEnergyRadio(1),
uSB(2),
nFC(3),
uSBInternal(4)
}
Given our implementation is internal, update the value from bit(2) uSB
to bit(4) uSBInternal.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve
and manually verify the individual attestation certificate
with an ASN.1 parser.
Change-Id: I62fe72ffed9b7eb34e31164fded46f458e5cbc16
Reviewed-on: https://chromium-review.googlesource.com/536775
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Implement system_get_chip_unique_id() for the g hardware.
It includes the hardware revision, the chip device id and
the read-only key id.
The key-id is included because this unique id is used as serial number
inside certificates and for security reason, we want a different id if
the RO has changed (e.g Node locked firmware).
The id is also 32-byte long for convenience reason when used for
certificates, but the high 16 bytes are currently zeros.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=dump the x.509 individual attestation certificate which includes
the unique id as serial number.
Change-Id: If24597d0de696d2700122d425724f14703fc5256
Reviewed-on: https://chromium-review.googlesource.com/536774
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Before this change, the current task id was cached in dcrypto_init() if
it hadn't already been called. This resulted in the task id of the first
caller to dcrypto_init() being cached until reset.
The cached task id was used when generating notifications that hardware
crypto operations were complete. This was fine as long as the task that
invoked dcrypto_init() was also the task that invoked dcrypto_call(). If
this wasn't the case, the task that invoked dcrypto_init() would be
notified of an event it wasn't expecting and the task that invoked
dcrypto_call() would not be notified and would time out.
This change locks a mutex and then caches the current task id in
dcrypto_call() before invoking the hardware operation so that the
correct task will be notified when the operation has completed.
BRANCH=none
BUG=none
TEST=make -j buildall
Change-Id: I30a920d85359cc990d77c88b1607bbe4cf674206
Reviewed-on: https://chromium-review.googlesource.com/522350
Commit-Ready: Carl Hamilton <carlh@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The contents of the board ID fields of the Cr50 image headers is an
important piece of information which determines if an image can run on
a particular H1 chip.
This patch adds this information to the output of the 'version'
command, printing both the contents of the fields of the RW images and
if the image would run with the current INFO1 board ID contents (Yes
or NO).
The board_id feature is in fact g chipset specific, this is why
board_id support files are being moved from the cr50 board scope to
the g chip scope.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=observed expected output in the version command:
> bid
Board ID: 000000fa, flags 000000ff
> vers
Chip: g cr50 B2-C
Board: 0
RO_A: * 0.0.10/29d77172
RO_B: 0.0.10/c2a3f8f9
RW_A: * 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
RW_B: 0.0.20/DBG/cr50_v1.1.6543-2c68a2630+
BID A: 00000000:00000000:00000000 Yes
BID B: 000000ea:0000fffc:000000ff No
Build: 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
tpm2:v0.0.289-cb2de5a
cryptoc:v0.0.8-6283eee
2017-06-09 15:34:19 vbendeb@eskimo.mtv.corp.google.com
>
Change-Id: I5b283abf304a7408ca8f424407044fca238185e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/530033
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
