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>
If Cr50 happens to start on a chip where Board ID programmed in INFO1
does not match the contents of the RW header, it means that for some
reason the other RW is not operational and the current image is the
only viable one.
In this case the Cr50 starts but operates in limited mode (only
commands for updating the image and reporting state are handled). In
this case the reason for recovery could be seen on the Recovery
screen, and the update could be done once Chrome OS boots in recovery
mode.
BRANCH=none
BUG=b:35586335
TEST=verified the following:
- if an image with wrong board ID is started, it tries to fall back
(sets the counter to a value above threshold and reboots)
- if the fallback fails, the image keeps running in the limited
capabilities mode but the update is possible, observed that the
new image took over worked after powercycling the device.
- observed proper error message on the recovery screen showing where
the error comes from
Change-Id: I46ba75392f8e891bb8503fb15aea2c56b5805e83
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535978
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@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>
When starting up the Cr50 should check if this image is supposed to
run on a chip with the board ID value read from INFO1.
If it is not supposed to run on this chip, and there is no rollback
counter overflow, set the rollback counter to a value which will
trigger a rollback and reboot.
If rollback counter has already exceeded the threshold - set a flag
indicating that the image is running in the "mismatch" mode and
continue.
BRANCH=cr50
BUG=b:35586335
TEST=with the rest of the patches applied verified both falling back
to an older image and continuing running with the flag set if
rollback is not possible.
Change-Id: I58d97de61dc446aaf1dd06b6e2b6bb426c14a172
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535977
Reviewed-by: Mary Ruthven <mruthven@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>
Cr50 needs to be able to bit bang the EC UART in order to flash certain
ECs such as the STM32 family. This is because the UART block on the
chip has no provision to change the parity which is necessary for the
STM32 bootloader protocol.
This commit adds a configuration to bit bang the EC UART. It's been
tested at 9600 baud.
BUG=b:35648297
BRANCH=cr50
TEST=With a logic analyzer, verify that TX to the EC can be bit banged
with no issues at 9600.
TEST=With some other changes, verify that cr50 is able to flash an EC
image to an STM32 EC.
Change-Id: Ice72aff133f268b5b7f0868aeec590a21404d1af
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/503474
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This patch adds vendor and console commands to read and write the
board ID space in the INFO1 block.
Current image's board ID settings are saved in the image header by the
latest codesigner.
Board ID write attempts are rejected if the board ID space is already
initialized, or if the currently running image will not be allowed to
run with the new board ID space settings.
Error codes are returned to the caller as a single byte value.
Successful read command returns 12 bytes of the board ID space
contents.
The console command always allows to read the board ID value, and
allows to write it if the image was built with debug enabled.
BUG=b:35586335
BRANCH=cr50
TEST=as follows:
- verified that board ID can be read by any image and set by debug
images.
- with the upcoming patches verified the ability to set and read
board ID values using vendor commands.
Change-Id: I35a3e2db92175a29de8011172b80091065b27414
Signed-off-by: Philip Chen <philipchen@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/522234
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Enable permanently the power button interrupt and discard the unneeded
presses, rather than enabling the interrupt on demand.
This is a preparatory work for the U2F feature which is using the power
button as the user physical presence sensing. It will need to be able to
detect all the button touches.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve.
Change-Id: Ifd90970932684d31ad7687db260bafa65a56e854
Reviewed-on: https://chromium-review.googlesource.com/518138
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add the robust non-volatile counter provided by CONFIG_FLASH_NVCOUNTER
in order to support the U2F implementation.
The counter implementation needs 2 (raw) pages of flash for its
underlying storage.
In order to try to avoid disrupting the existing machines by
invalidating the nvmem if we touch its mapping, those pages are placed
in each RW between the code/read-only and the read-write nvmem area by
shrinking the code/read-only by one page, so the nvmem mapping should be
untouched.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve.
Change-Id: Ib3d7dcb9a1b13cff74b56461332937e3a4cc9ae1
Reviewed-on: https://chromium-review.googlesource.com/518137
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
If CCD was set to the "keepalive" mode, removing the debug accessory
would cause the CCD_MODE_L pin to be pulled high, ignoring the keepalive
state. CCD was still kept alive, but the state reflected on the pin
didn't indicate so.
This commit changes the behaviour such that the CCD_MODE_L pin is set up
as an input only when CCD keepalive is not enabled.
BUG=None
BRANCH=cr50
TEST=Plug in debug accessory and remove debug accessory. Verify that
CCD_MODE_L is high after removal.
TEST=Enable ccd keepalive. Remove debug accessory. Verify that
CCD_MODE_L is still low.
Change-Id: I407994d5c394a717d6e1a87f283f6441bd26bf55
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/520603
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
It needs to be possible to prevent unlocking of CCD on enterprise
enrolled devices, in particular to prevent users from moving into dev
mode.
A bit in the FWMP structure flags field was allocated for the purposes
of preventing console unlock in those cases.
This patch adds code to read the FWMP structure from the TPM NVMEM,
verify it and determine if it should be possible to unlock the
console. The restriction is not honored by Cr50 DBG images.
The FWMP value is read only once per TPM reset, this means each time
the admin console changes the relevant flag bit, the Chrome OS device
has to be rebooted to pick up the new flag value.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=verified that FWMP is properly read and acted upon.
Change-Id: I17e15ea2b2293a0c096858fba3ccc389452caede
Reviewed-on: https://chromium-review.googlesource.com/457824
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Cr50 holds the EC in reset when it wants to flash the EC or AP. This
will trigger a pulse on the tpm reset signal. In early Cr50 versions
when the tpm was reset we would reboot cr50, so we added some code to
prevent cr50 from resetting itself when the update was going on.
sys_rst_asserted would check if there was an update going on and ignore
the signal if update in progress was true. At the end of the update the
deferred function was used to reset Cr50 after the update was complete.
None of this is needed anymore. We can just release the EC from reset at
the end of the update. This change removes usb_spi_update_in_progress
and the deferred update_finished.
BUG=b:35571516
BRANCH=none
TEST=flash the bob ec and ap using ccd.
Change-Id: I79416dba178c06bbc7289ad96968ee4e61947c4c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/506571
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
There many TODOs sprinkled in the code, some of them have been
addressed or do not apply any mode. This patch removes them.
BRANCH=cr50
BUG=none
TEST=built and ran cr50 on reef
Change-Id: Ica6edb204e5cc0cc9dc7f0d43fd39e7ddaf56809
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/506496
Reviewed-by: Randall Spangler <rspangler@chromium.org>
always_memset() implements a version of memset
that survives compiler optimization. This change
replaces instances of the (placeholder) call
dcrypto_memset() with always_memset().
Also add a couple of missing memsets and
fix related TODOs by replacing memset()
with always_memset().
BRANCH=none
BUG=none
TEST=TCG tests pass
Change-Id: I742393852ed5be9f74048eea7244af7be027dd0e
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/501368
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
This firmware supports a board used to initialize firmware on new cr50
parts.
BUG=b:36910757
BRANCH=None
TEST=boots on scribe board, spi/usb/uart/i2c functionality works.
TEST=cr50 boots on reef, CCD EC+AP SPI/UARTS work
Change-Id: I48818225393a6fc0db0c30bc79ad9787de608361
Reviewed-on: https://chromium-review.googlesource.com/437627
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Right now there is no way to verify cr50 is asleep just by looking at
the UART output. You can check by running taskinfo and seeing that the
GC_IRQNUM_PMU_INTR_WAKEUP_INT irq count has increased or by measuring
cr50 power.
In the past we have had Cr50 issues that we think are related to sleep.
Devices like poppy will have the Cr50 uart connected to servo, so we can
capture the Cr50 console output. It would be helpful if there was an
easy way to tell that cr50 is asleep from the UART output to more easily
confirm issues might be related to sleep. This change will print '.'
every time Cr50 resumes from sleep. Cr50 wakes up every half second for
HOOK_TICK, so with this change '.' prints every half second while cr50
is asleep.
BUG=none
BRANCH=none
TEST=boot a device, wait a while, and verify cr50 starts printing '.'
every half second. Turn off the device and verify the '.'s stop.
Change-Id: I94a82db00076062dbba2c3bc273cbe0731430520
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/463990
Reviewed-by: Scott Collyer <scollyer@chromium.org>
When Cr50 resumes from hibernate, it should use the WP state that was
stored in the long life scratch registers. All other boots should
simply follow the state of the BATT_PRES_L pin.
BUG=b:36659750
BRANCH=master,cr50
TEST=Power on Cr50 via battery, verify that WP_L remains asserted.
Change-Id: I516d43b6540d7c543e7629f8709ce63515bb7f76
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/464258
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The cr50 code might need access to certain variables stored in the TPM
NVMEM. In particular the upcoming FWMP support will require reading
the NVMEM FWMP space.
This patch adds a generic function which allows to access TPM NVMEM
spaces. The implementation was borrowed from NV_REad.c in the tpm2
tree, the only difference being that the location, if present, is read
unconditionally, without checking access controls.
The API accepts the NVMEM index in Chrome OS scope and maps it into
TPM2 specification's NVMEM index space based at HR_NV_INDEX. The
definitions are included straight from the tpm2 tree.
BRANCH=none
BUG=chrome-os-partner:62489, chrome-os-partner:62205
TEST=this code is not yet even being compiled, tested with the next
patch.
Change-Id: I8bcfd8637c192249780634491f30e4a28229984f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457823
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
With the rest of support in place, this patch adds code which would
corrupt the headers received during firmware updates.
The VENDOR_CC_TURN_UPDATE_ON vendor command will be required to enable
the new images.
Care should be taken that other commands operating on the inactive
image header do not do anything with it before it was enabled, some
code is being added for that.
The minor RW version is being bumped up to 19 to clearly indicate that
the device is expecting the vendor command to enable the new image
(this is used by usb_updater when downloading the image without the -p
or -u command line options).
BRANCH=cr50
BUG=b:35580805
TEST=verified that the new image can be installed and started by the
new usb_updater.
- the inactive header after uploading with the -p option (the
image_size field's offset is 0x32c):
> md 0x84320 4
00084320: 00000000 00000000 80033800 00084000
rebooting the device does not start the new image.
- the inactive header after uploading without the -p option:
> md 0x84320 4
00084320: 00000000 00000000 00033800 00084000
the device running a DBG image reports the following in the end of
the image update:
[64.176780 FW update: done]
turn_update_on: rebooting in 100 ms
Change-Id: I4d763eb89c8b1a43a13697033201066779826e85
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457678
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The upcoming move of the Cr50 firmware update to the background
requires postponing the activation of the newly uploaded Cr50 image to
a later point in time, when the AP is ready to switch to start using
the new Cr50 image.
The suggested way of achieving it is as follows: when downloading the
new image, the current Cr50 code modifies the header's 'image_size'
field, setting its top bit to 1. This both makes the size invalid and
guarantees that the new image would not verify on the following Cr50
restarts.
When the AP is ready to switch to running the new Cr50 image, it will
send a vendor command, which would trigger the currently running Cr50
image to restore the other image's size field. This vendor command
would also communicate the timeout for the Cr50 to wait before
rebooting, if there has been at least one header (ro or rw) restored.
Rebooting the Cr50 would trigger rebooting the AP, resulting in the
entire system running the updated firmware.
Response sent to the AP will indicate if there has been a header
restored and the reboot is indeed upcoming, this would allow the AP to
quiesce the state of the device to handle the reboot gracefully.
BRANCH=cr50
BUG=b:35580805
TEST=with the rest of the patches applied observed the system properly
after the new header version was restored.
Change-Id: Ia1edee67b6aa8f458810d5dc2931477cfaab1566
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457676
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When an x86 based system is reset, a pulse on the plt_rst_l line is
generated. This pulse is supposed to reset the system and the pulse'
rising edge is an interrupt trigger for H1 to reset the TPM. If H1 is
in sleep state at the time of the rising edge, the interrupt request
could be lost.
Luckily, the minimum plt_rst_l pulse duration is 1 ms, and the worst
case max time to wake up from sleep for H1 150 us. Let's wake up on
low level of plt_rst_l, this way by the time the rising edge comes
along the H1 would be awake and ready to process the interrupt.
BRANCH=cr50
BUG=b:35995492
TEST=verified that platform_KernelErrorPaths.CORRUPT_STACK passes
hundreds of times on a system were it was failing after a few
runs before this fix.
- verified that suspend_stress_test still succeeds at least 300
iterations
Change-Id: Ib9984efa08bdd185a95716dc9e48077cf4bb3c2a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/455579
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
With enabling INFO1 map based rollback protection it is important to
be able to tell the state of the flash map and the currently installed
images' infomap header field.
The new function counts number of zero words in the info map and zero
bits in both RW headers, and returns them in a string printed out by
the sysinfo command.
BRANCH=cr50
BUG=b:35774863
TEST=built images with different manifest info field contents and
verified that the string printed by the sysinfo command makes sense.
Change-Id: If633a6c678dc34197b2dad116b6180b2d549e089
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450905
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The cr50 RO image compares INFO rollback map space against the
contents of the RW image's infomap field.
To ensure that no rollback is possible, the RW should verify that the
INFO space state is consistent with the current RW and RW_B headers,
and if not, update the INFO state to comply.
This should happen only when running prod images, so that debug images
could be rolled back if so desired.
Also fixed the bug in functions enabling read and write access to the
INFO1 region. Write access is now a superset of read access setting.
BRANCH=cr50
BUG=b:35774863
TEST=as follows:
- built and ran a new image, observed it start successfully;
- modified the manifest to erase the first map location, built and
ran a new image, observed it start successfully
- restored the manifest, built and tried running a new image,
observed that the earlier version is starting.
Change-Id: I62253c3e98cd24ed24424b8bb9de22692a262d89
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447966
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The issue is with how we have the sys_rst_l wake pin setup. How it is
now, the gpio controller never sees that sys_rst_l is asserted, so it
can't tell when there is a rising edge.
sys_rst_l is a rising edge wake pin. Cr50 would enter sleep with
sys_rst_l high. While cr50 was asleep sys_rst_l would be asserted and
then deasserted. The rising edge would wake cr50 up, and when cr50 woke
up the gpio controller would see that sys_rst_l is still high, so it
wouldn't think there was an edge and it wouldn't trigger the tpm reset
interrupt.
This change makes sys_rst_l wake low instead of wake rising. This means
that cr50 will remain awake whenever sys_rst_l is asserted and it will
be awake to see the rising edge on sys_rst_l.
BUG=b:35774896
BRANCH=cr50
TEST=Turn off bob. Wait until cr50 enters regular sleep. Turn the device
back on and make sure it doesn't boot to recovery.
Change-Id: Ibee6c8112d32b3abb8953aa71d68e1f510932286
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450874
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This commit changes the behaviour of handling the CCD_MODE_L pin. When
Cr50 is not in CCD mode, it will stop driving the pin and turn it into
an input. This allows the pin to be driven by the EC. Cr50 will then
poll the CCD_MODE_L pin to see when it is pulled low and then enter CCD
mode. Once the pin is deasserted, CCD mode is disabled.
However, when Cr50 itself makes the decision to enter CCD mode, it
changes the pin from an input to an output and drives the pin low.
NOTE: The rdd interrupt does not directly trigger CCD mode, but now
drives the pin low. A side-effect of the pin going low is that CCD is
enabled. Once Cr50 decides to leave CCD mode, it then reconfigures the
pin to be setup as an input again.
CQ-DEPEND=CL:448988
BUG=b:35804738
BRANCH=cr50
TEST=Flash dev board, use `ccd` console command to both enable and
disable CCD. Verify that when CCD is enabled, the state of DIOM1 does
not disable CCD. Verify that when CCD is disabled, pulling DIOM1 low
enables CCD. Letting it float disables CCD.
TEST=Verify that CCD mode is reflected in the device state.
Change-Id: I44645f28b362977ca6a502b646e4f4ff1a7430c7
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/448161
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We had disabled wakeups on the AP phy when we were running on gru,
because the AP phy was not in use. We never changed that for reef, so
UTMI wakeups were disabled even when the AP USB was supposed to be
enabled. After Cr50 went to sleep any usb transactions would drop bits,
because Cr50 wouldn't notice anything was happening until it woke up on
one of the HOOK_TICK events.
This change reenables UTMI wakeups on boards with AP usb. It writes 1 to
USB_PCGCCTL_STOPCLK. This makes the controller disable the PHY clock
whenever it detects a usb suspend. When it resumes out of suspend, this
bit has no effect.
BUG=b:35774906
BRANCH=cr50
TEST=Boot up reef. Wait until cr50 goes to sleep run 'usb_updater -f'
and verify that it runs successfully. Make sure deep sleep still works
Change-Id: I54bd866111b5c9b5738575f23757e0cbe4907ec4
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448988
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Flash INFO access API presently is hardcoded to access the endorsement
space. To enable INFO map based rollback protection one needs to be
able to access different areas of the INFO.
The FLASH REGION3 register used by the API is in fact used for NVMEM
flash accesses too, so it is better to leave it alone and use REGION6
for the purpose of accessing of the INFO space.
The API now requires the user to specify flash offset and region size,
the size must be power of 2, the offset must be aligned at size, and
the region must not spill beyond the INFO space address range.
BRANCH=cr50
BUG=b:35774863
TEST=with the rest of the patches applied it is possible to erase the
base word in the info map segment;
reading of the endorsement space at startup still works fine.
Change-Id: I008165ee9e11a7b49985d2b30683509cf6699431
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447965
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This commit enables the use of the nvmem vars module. The console lock
state is migrated from using the long life scratch register, to nvmem
vars instead which will persist across power on reboots.
BUG=b:35586145
BRANCH=None
TEST=Flash a dev image. Lock the console. Remove all power from the
system. Power on system and verify that console is still locked.
Unlock the console, remove power from the system, power on the system,
verify that the console is now unlocked.
TEST=Repeat the above test, but using the nvtestvar console command
instead.
Change-Id: I03a2098bb0017cfca59889457a332eafb0e95db6
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445804
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Cr50 on x86 will run normally enter deep sleep and then wake up
immediately. When the AP turns off it stops pulling up the i2cs signals.
When cr50 enters deep sleep it sees that the i2cs signals are low then
wakes up immediately. After resuming cr50 will remain awake for 20 then
enter deep sleep. At this point it will remain asleep.
This change disables i2cs_sda and scl as wake pins when entering deep
sleep. Just like ARM these tpm signals are not in use when the device is
off. We have other signals to detect when the system leaves s3 or s5, so
we should rely on those.
We need this change because we want cr50 to fully enter deep sleep when
we run suspend resume tests. Right now the AP does not sleep long enough
for cr50 to enter the second deep sleep.
BUG=none
BRANCH=none
TEST=turn off the AP and make sure cr50 doesn't resume from deep sleep
immediately. run suspend_stress_test -c 5000 and verify cr50 enters deep
sleep and resumes correctly. verify dioa9 and dioa1 are enabled as wake
pins on resume
Change-Id: Ided8b2b7d5455650bca1e8d781063d092fb74c43
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/443389
Currently, manually triggered reboots cause the retry counter to be
incremented. However, if the system is responsive enough to process the
reboot commands from either the console or TPM vendor command, we can
assume that the image is "ok". This commit changes the Cr50 behaviour
to decrement the retry counter when a reboot is issued on the console or
the TPM vendor command is received.
BUG=chrome-os-partner:62687
BRANCH=None
TEST=Flash cr50. Flash an older image in the other slot. Enter the
reboot command on the console over 10 times and verify that retry
counter never exceeds RW_BOOT_MAX_RETRY_COUNT and older image is never
executed.
CQ-DEPEND=CL:444264
Change-Id: Ic35bdc63c4141834584a00a7ecceab2abe8dfc21
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/443330
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
With this change, only DEV images will have the capability to unlock the
Cr50 console.
BUG=chrome-os-partner:62727
BRANCH=None
TEST=Build a prod image, flash Cr50, try to unlock the console. Verify
that access is denied and console remains locked.
TEST=Attempt to read EC and AP flash over ccd. Verify that it fails.
TEST=Remove AC and battery. Plug in AC. Verify that console is still
locked.
TEST=Plug in AC, unplug battery, verify that write protect is disabled.
Verify that console is still locked and cannot be unlocked.
TEST=Build a dev image, verify that console can be locked and unlocked.
Change-Id: Ic47aa34f42ee295e74ba3a40b709ac42c34a30b7
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/439764
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Poppy uses SPI, Plt_Rst, and USB to AP. Its strapping option is 1M PU
on both DIOA9|DIOA1 which gives it a strap_config value of 0xA.
Rowan uses I2C and it's strapping option is 5k PD on DI0A12 and 5k PU
on DI0A6 which gives it a strap_config value of 0x30.
BRANCH=none
BUG=chrome-os-partner:59833
TEST=manual
Used H1 dev board with external PU/PD resistors to replicate both the
Poppy and Rowan configurations.
With Poppy config console shows:
[0.004468 Valid strap: 0xa properties: 0x45]
With Rowan config console shows:
[0.004460 Valid strap: 0x30 properties: 0x2]
Change-Id: I569960114c6f1844a55912fbf7f3d97008f9f71f
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/428000
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
x86 devices use TPM_RST_L to detect the AP state, so we set
device_states[DETECT_AP].detect to GPIO_TPM_RST_L on those boards.
board_update_device_state uses this signal to poll the AP state once a
second to detect if the device is off.
If for some reason TPM_RST_L is deasserted, but the tpm reset handler
has not yet set the state to 'on', we will catch it when we poll the AP
state with board_update_device_state. It will call device_state_on with
TPM_RST_L. In that case device_state_on used to silently disable the
TPM_RST_L interrupt and not change the AP state. This change modifies
device_state_on to notify the tpm reset handler and prevent it from
disabling the tpm reset interrupt.
BUG=chrome-os-partner:62748
BRANCH=none
TEST=disable the deferred_tpm_rst_isr call in
configure_board_specific_gpios. Close the lid and wait 5 minutes. Open
the lid. Verify cr50 prints "device_state_on: tpm_rst_isr hasn't set the
AP state to 'on'" and the system boots normally.
Change-Id: I6e5b722fab6e7b0acb91dda0e5207e4411e97363
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/439816
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This commit changes the Cr50 write protect behaviour to simply follow
the state of the battery present pin. The state can still be overridden
both ways by using the `wp` console command. A user can either force
write protect enabled or force write protect disabled. Additionally,
the behaviour can be reset to follow the state of the battery pin by
issuing `wp follow_batt_pres`. However, the ability to force the write
protect state requires an unlocked console.
BUG=chrome-os-partner:62726
BRANCH=None
TEST=Plug in battery, verify that WP is enabled. Plug in AC and unplug
battery, verify that WP is disabled.
TEST=Unplug battery, unplug AC, plug in AC, verify that WP is disabled.
TEST=Unplug battery, verify that WP is disabled. Use `wp' command to
enable WP, verify that it is enabled.
TEST=Plug in battery, disable WP using `wp` command, put cr50 into deep
sleep, wake it up, verify that WP is still disabled.
TEST=Plug in AC, plug in battery, disable WP using `wp` command, unplug
and plug battery connector, verify that WP is still disabled.
Change-Id: I83d9820067800801ddbde311eab0853c3c2216d3
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/439485
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
After configuring tpm_rst_l to be connected to the correct pin, check
the level of GPIO_TPM_RST_L to make sure we did not miss the rising
edge. If we did then call the tpm reset handler
BUG=chrome-os-partner:62748
BRANCH=none
TEST=verify electro boots, close the lid, wait 5 minutes, open the lid
and verify it still boots
Change-Id: I1a229fa53664767f0e5cad5f80285f5f030f2197
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/439879
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The ap uart tx signal is disconnected if servo is attached, but it is
never reconnected when servo is detached. The 'ccd uart enable' command
only reconnects the EC uart tx signal, so if servo is detached the only
way to reenable ap uart tx is to detach and reattach suzyq. This can
cause cr50 to lose some ccd state.
This change reconnects the ap uart when servo is detached.
BUG=none
BRANCH=none
TEST=manual
disconnect servo
attach suzyq
verify the ap console is read write
attach servo
verify the ap console is read only
detach servo
verify the ap console is read write
Change-Id: I11cdd932b14d968ec77b18adf93dd0d3808fb2e9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/439704
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The reset count is very useful for debugging whether the tpm is locked
or if the version rolled back. This change makes reading the value
easier by adding it to the sysinfo command
BUG=none
BRANCH=none
TEST=reboot cr50 8 times verifying the reset count value is correct each
time and that sysinfo also shows a rollback is detected after the 7th
boot.
Change-Id: I94ac11a444ee73aa04bbdcc066c8e1c7a0a3ae8e
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/438788
Reviewed-by: Scott Collyer <scollyer@chromium.org>
There is no need to invalidate the inactive RW image if it's already
been done. Check the magic area of the header and if already 0s, then
set *response_size and return VENDOR_RC_SUCCESS.
BUG=chrome-os-partner:62588
BRANCH=none
TEST=manual
Update H1 FW on Eve. Using 'ver' command verify that it has valid A/B
RW images. Log into chromeos and see console messages indicating that
inactive image is being invalidated and via 'ver' command. Reboot via
H1 console and see that this time the message
vc_invalidate_inactive_rw: Inactive region already corrupted
is displayed.
Change-Id: I0894d456fdc63f64fc7272ad55d75ba94dbe94c4
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/438787
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Since the INAs are now enabled based on rdd_attach, there is no need
to have a a delay following enabling the 3.3V rail and the delay can't
be a usleep() because ina_connect() is not being called from
rdd_attach which is running in an interrupt context.
BUG=chrome-os-partner:62375
BRANCH=none
TEST=manual The usleep() call was causing a reboot but was only
visible when using UART console. Verified that with this CL the reboot
was no longer happening.
Change-Id: Id9bbef4e89dee39a2dfa443c3af54c1f9a611ebd
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/438675
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
There is no point in keeping in one file multiple hooks task callbacks
to handle chipset shutdown and resume conditions.
Also, the policy of disabling deep sleep needs to be decided in the
board level hooks.
BRANCH=none
BUG=chrome-os-partner:59007
TEST=ran reef through 200 cycles of suspend/resume
Change-Id: I4d30cd04b986b243a5bea44c6978a5f82f8f62a7
Reviewed-on: https://chromium-review.googlesource.com/437729
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Trybot-Ready: Vadim Bendebury <vbendeb@chromium.org>
The cr50 needs to be aware of the power state of the system and of the
moment when the AP is reset, because this is when the TPM needs to be
reset too.
Arm and x86 platforms provide different hints in these cases.
In case of x86 there is a single signal cr50 can rely on: PLT_RST_L.
This active low signal is asserted when the system is going into any
power state deeper than s0ix. The cr50 can fall into deep sleep when
PLT_RST_L is asserted, and has to wake up and reset the TPM when this
signal is deasserted. There could be other wake triggers, but the tpm
should not be reset unless PLT_RST_L is inactive. It is also important
not to fall into deep sleep when PLT_RST_L is pulsed to reboot the
system.
In case of ARM there are two separate signals. Deasserting SYS_RST_L
signal is the trigger to reset the TPM, The GPIO_DETECT_AP going low
for a duration of time is the indication of the AP going into some
kind of sleep mode. The ARM case requires more clarification.
This adds run time configuration of the the sleep state control input.
Once the input turns low, the CHIPSET_SHUTDOWN signal is sent and deep
sleep mode is enabled. Again, this will require adjustment for ARM
platforms.
The wake from deep sleep state is controlled by the wake pins as
before, but by level instead of edge. This makes sure that in case the
trigger for deep sleep goes away while deep sleep preparation is under
way, the device resumes immediately instead of getting stuck missing
the edge.
The TPM_RST_ input is now triggering interrupts on deassertion
- this is the moment when the TPM needs to be reset. The ISR is being
renamed accordingly.
The processing previously happening inside the ISR is being moved into
a deferred function running on the hooks task context.
There is no need to invoke TPM reset related functions from the PMU
wake up ISR anymore.
BRANCH=none
BUG=chrome-os-partner:59007
TEST=as follows:
1. make buildall -j succeeds
2. started on Reef, still in progress after 100 iterations, early to
call
suspend_stress_test --suspend_min 40 --suspend_max 45 \
--wake_max 15 wake_min 10
(note that reef does not fall into s3 any more, so the test does not
verify H1 deep sleep)
3. modified the target to fall into s3 during the test and
successfully repeated it for 100 iterations
4. tried battery disconnect a few times and observe successful boot.
Change-Id: Ica06ec0d363b53eede3be327404ff5807fa3a610
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436865
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The INAs are only used for development and testing
purposes. Therefore, the 3.3V rail to the INAs is off by default and
the I2Cm module is not enabled. Enabling INA power and connecting the
I2Cm module was done at the beginning of each USB to I2C request. The
problem with this approach is that INA measurments didn't always
succeed due to not enough time for the INAs to initialize.
Rather than add some arbitrary delay, it is better to tie the INAs to
when rdd is attached/detached. It is only when rdd is attached that
the INAs will be accessed, so there is no need to enable/disable for
each individual I2C transaction.
This CL ties the enabling/disabling of the INA and I2Cm module to the
rdd state. This change makes the previous use of
usb_i2c_board_enable() and usb_i2c_board_disable() obslete.
BRANCH=none
BUG=chrome-os-partner:62375
TEST=manual
Connect servo with suzyq connected:
sudo servod -p 0x5014 -b eve -c eve_r0_inas.xml
Then execute single INA reads dut-control pp3300_dx_edp_mv and verify
that it returns meaningful numbers. Without this CL single reads via
dut-control would always return 0.
Change-Id: I799552bfd0701efd1828a0d720ac2a6cedee5ca1
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436864
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This patch makes it clear what state each of the straps is in, the
information is printed on the console at startup time.
BRANCH=none
BUG=chrome-os-partner:59833
TEST=tried the new code on the dev board, observed the following in
the console output at startup:
strap pin readings: a1:3 a9:1 a6:1 a12:3
which is consistent with expectations give the dev board
schematics and mode of operation.
Change-Id: Ie7b2511e0da84b8c9e3462d3f88365e6f2227bfe
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/434938
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The commit changes the behaviour to block accesses over the USB-SPI
bridge while the console is restricted.
BUG=chrome-os-partner:62340
BRANCH=None
TEST=Build and flash cr50 on snappy; lock console; try to flash EC bin
using CCD. Verify that it fails with flashrom not able to find a flash
chip.
TEST=Disable console lock; Try to flash EC bin; verify it succeeds.
TEST=Repeat above tests but trying to read AP flash instead.
TEST=make -j buildall
Change-Id: Ib69af1a7372d841783acee2262efbf995d031234
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/435437
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Previously, and invalid strap configuraiton was not updating the copy
in the long life register. Since we don't expect to have invalid strap
pins, but if they are read, it's not expected to change run to
run. Therefore, to have consistent behavior, store the properties
determined in the long life register in all cases.
BRANCH=none
BUG=chrome-os-partner:59833
TEST=manual
Tested with Reef/Gru which both have valid table entries and verified
that board properties were being saved in the long life
register. Tested on Eve which has currently an invalid strap config
and repeated the test.
Change-Id: I3a018db0e3a88ad33a85125a892b74b44593d5df
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436004
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The current strap pin logic was checking for case of no pullup
resistors detected on either pair of strap pins, but did not check
explicitly for at least one pullup on each pair or strap pins. This
condition, which isn't expected, is an invalid configuration and
therefore can't be used to determine either SPI vs I2C or as a table
lookup entry.
BRANCH=none
BUG=chrome-os-partner:59833
TEST=manual
Tested on Eve which has 4.7k pullup resistors to PP3300_A this rail is
not going down as expected. The result is that a pullup is read on
DIOA6 which is expected and strong pullups are read on
DIOA9|DIOA1. With this CL the strapping pin logic produces the
folloiwng output:
--- UART initialized after reboot ---
[Reset cause: hard]
[Image: RW_B, 0.0.14/DEV/cr50_v1.1.5933-18d527f
tpm2:v0.0.286-21er-linux.mtv.corp.go]
[0.004160 Inits done]
[0.005476 Invalid strap pins! default properties = 0x42]
Change-Id: Ibe85bc55d62b4c060b6c39629a225edc6d1dc341
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433146
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
This vendor command allows the host to retrieve the internal TPM
state. The first version of the command will return the failure
information collected during assert, if it ever happened, retry
counter value and the maximum retry counter value to be able to detect
if TPM is in lockout.
The structure is packed, it is serialized before being sent to the
host.
BRANCH=none
BUG=chrome-os-partner:60555
TEST=when running on a reef with a depthcharge image capable of
displaying TPM state on errors observed state information added
to the recovery screen text display.
Change-Id: I9d37f7a971013ce802f63218d43697fab68276c9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/430952
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
