summaryrefslogtreecommitdiff
path: root/common/tpm_registers.c
Commit message (Collapse)AuthorAgeFilesLines
* cr50: do not enable TPM when compiling for dcrypto testsVadim Bendebury2019-07-171-5/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no room in the flash for both dcrypto tests and the TPM library. Let's disable TPM function (and not link the library) when the image is compiled with dcrypto tests included. BRANCH=cr50, cr50-mp BUG=b:137659935 TEST=verified that there is plenty of room for tests now: $ make BOARD=cr50 -j -k CRYPTO_TEST=1 CR50_DEV=1 . . . *** 8124 bytes in flash and 61564 bytes in RAM still ... in cr50 RO *** *** 66100 bytes in flash and 6000 bytes in RAM still ... in cr50 RW *** - building without CRYPTO_TEST=1 still produces a functional Cr50 image; - when building with CRYPTO_TEST=1, the version string reflects it: $ strings build/cr50/ec.bin | grep cr50_v | head -1 DBG/CT/cr50_v2.0.1776-46b015f6a - CCD of the images built with crypto test enabled is fully functional, in particular USB updates are operational. Change-Id: Iae91ca36dc203301ac423fe048fc67eb44ef5de6 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1704608 Reviewed-by: Namyoon Woo <namyoon@chromium.org>
* cleanup: refactor CPRINTF("[%T ...]\n") to CPRINTSJack Rosenthal2019-07-171-2/+2
| | | | | | | | | | | | | | | | Looking at where the non-standard %T printf modifier is used in EC codebase, the majority is cases where CPRINTS could have been used instead of CPRINTF. This is a somewhat-mechanical refactor of these cases, which will make implementing a standard printf easier. BUG=chromium:984041 BRANCH=none TEST=buildall Change-Id: I75ea0be261bfbfa50fb850a0a37fe2ca6ab67cb9 Signed-off-by: Jack Rosenthal <jrosenth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1703128 Reviewed-by: Evan Green <evgreen@chromium.org>
* tpm: reset command_ready bit when entering idle stateVadim Bendebury2019-06-051-4/+6
| | | | | | | | | | | | | | | | | | | | TPM could enter idle state even when current command has not yet been fully processed (for instance if the AP releases locality at an arbitrary moment). The status register command_ready bit needs to be unconditionally reset when TPM enters idle state. BRANCH=cr50, cr50-mp BUG=none TEST=verified reliable behavior during lengthy concurrent runs of processes accessing TPM. The same type of testing was causing occasional TPM lockups before this fix. Change-Id: I6e1dc334713c666e4ef566d41bd0cbff841f1179 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/ec/+/1643828 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* tasks: convert TASK_EVENT_CUSTOM macro to bitJett Rink2019-04-241-3/+3
| | | | | | | | | | | | | | | | | | | | | We should ensure that all custom task definition are non-zero and fit with the globally defined events. Add compile time check and change semantics to specify bit number (instead of making all callers use the BIT macro). This also fixes an error with TASK_EVENT_PHY_TX_DONE for ITE being 0. The bug that made that happen hasn't landed on any firmware branches that use it though. BRANCH=none BUG=none TEST=builds Cq-Depend:chrome-internal:1178968,chrome-internal:1178952 Change-Id: I5e1d1312382d200280c548e9128e53f4eddd3e61 Signed-off-by: Jett Rink <jettrink@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1570607 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
* cr50: complete support of the new NVMEM structureVadim Bendebury2019-04-051-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch eliminates unnecessary legacy nvmem.c and nvmem_vars.c code and brings the code base to the state where the new NVMEM layout is fully functional. BRANCH=cr50, cr50-mp BUG=b:69907320, b:129710256 CQ-DEPEND=CL:1450278 TEST=the following tests pass: - test cases in ./test/nvmem.c - TCG suite (passes on par with the existing Cr50 code with the reduced code footprint TPM2 library) - Chrome OS device migrates from legacy to new implementation with user account maintained. - Chrome OS user account is maintained over AP and H1 reboots and deep sleep cycles. Change-Id: If4bc2dd125873a79dbe0e268eb32100a8b8b352d Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1496607 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* cr50: convert functions into staticNamyoon Woo2019-04-051-1/+1
| | | | | | | | | | | BUG=b:112778363 BRANCH=cr50 TEST=ran test_that suite:faft_cr50_prepvt on coral. Change-Id: I1b3c573ee5fcb40290541f231c78bf31650c13c4 Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1410482 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: move to use flash event logVadim Bendebury2019-03-281-7/+0
| | | | | | | | | | | | | | | | | | | | | With upcoming Cr50 changes which might trigger occasional reboots, it is better to keep the Cr50 log in the newly introduced flash log space as opposed to the circular log in SRAM. There is no need to log TPM resent events, as this is not something worth tracking in a flash log. Enabling flash log facility adds 624 bytes to the prod Cr50 image and 1420 bytes to the DBG Cr50 image. BRANCH=cr50, cr50-mp BUG=b:63760920 TEST=with modified code observed saving of FE_TPM_I2C_ERROR event. Change-Id: Id6779de887dac20ce6c1091c8b1571ae900623fd Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1525145 Reviewed-by: Namyoon Woo <namyoon@chromium.org>
* common: replace 1 << digits, with BIT(digits)Gwendal Grignou2019-03-261-18/+18
| | | | | | | | | | | | | | | | Requested for linux integration, use BIT instead of 1 << First step replace bit operation with operand containing only digits. Fix an error in motion_lid try to set bit 31 of a signed integer. BUG=None BRANCH=None TEST=compile Change-Id: Ie843611f2f68e241f0f40d4067f7ade726951d29 Signed-off-by: Gwendal Grignou <gwendal@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1518659 Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
* tpm_registers: check if_stop has been initialized before calling itMary Ruthven2019-03-061-1/+3
| | | | | | | | | | | | | | | | | It's possible tpm_stop will be called before the interface has been registered. Don't call if_stop unless it has been initialized. BUG=none BRANCH=cr50 TEST=none Change-Id: I45b6d11553ce0eda5b097184a5be81f8b79726aa Signed-off-by: Mary Ruthven <mruthven@google.com> Reviewed-on: https://chromium-review.googlesource.com/1480710 Commit-Ready: Mary Ruthven <mruthven@chromium.org> Tested-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Keith Short <keithshort@chromium.org>
* tpm: explicitly include tpm2 data in the appropriate sectionVadim Bendebury2019-02-151-9/+9
| | | | | | | | | | | | | | | | | | | | With the recent move to enabling LTO the tpm_registers module's data variables which are supposed to be cleared on TPM reset ended up not included in the appropriate part of the .bss section. With this patch all variables of interest are marked with the section name they need to be placed in. BRANCH=cr50, cr50-mp BUG=b:124450448 TEST=before this patch after RMA clear every TPM reset was wiping out the TPM NVMEM, with this patch in place only the following reset wipes out the NVMEM. Change-Id: If0cbdeae2ff37f2b9cf67672c0a3b5c57efd6248 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1474892 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* cr50/ec: add a console command to display event logs.Namyoon Woo2019-02-071-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 'dlog' console command is introduced, which displays event logs on console. To activate this command, CONFIG_CMD_DLOG should be defined in board.h. 'dlog clear' clears all event logs. BUG=b:63760920 BRANCH=cr50 TEST=manually > help dlog Usage: dlog [clear] Display/clear TPM event logs > tpm_log 1 0xABCD > tpm_log 2 0x1234 > dlog TIMESTAMP | TYPE | DATA | SIZE | PAYLOAD 749 1 0xABCD 0 8325 2 0x1234 0 > dlog clear > dlog TIMESTAMP | TYPE | DATA | SIZE | PAYLOAD > Change-Id: I313beeb2e5ec04c108296cd4c017d938aab24b0d Signed-off-by: Namyoon Woo <namyoon@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1454136 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* common: fix tpm_task prototypeVadim Bendebury2019-02-071-1/+1
| | | | | | | | | | | | | | | The actual main task function prototype includes a void pointer as a parameter. Enabling link time optimization shows that tpm_task() prototype is not compliant, let's fix it. BRANCH=cr50, cr50-mp BUG=b:65253310 TEST=building Cr50 with CONFIG_LTO enabled does not fail any more. Change-Id: Ia5ca961ced6cbef66894a52b25b711f8a2317244 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1450814 Reviewed-by: Andrey Pronin <apronin@chromium.org>
* cr50: reset burstcnt to max when entering idleAndrey Pronin2019-01-131-0/+3
| | | | | | | | | | | | | | | | | | | | | | Before this CL, when entering idle state after aborted command (response not read or read partially, then aborted by setting COMMAND_READY set in STS), the last burstcnt set for the response was carried over to processing the next command. Reset burstcnt on entering idle to max value, as we do in tpm_init and fifo_reg_read when the last chunk is read. BUG=b:118178519 BRANCH=cr50, cr50-mp TEST=1) boot, login normally; 2) imitate lost TPM ready IRQs in host tpm driver (see BUG), verify that trunksd starts and TPM communication work after that. Change-Id: I76061090bf48a36509ab7f4678716f8bc426846a Signed-off-by: Andrey Pronin <apronin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1405626 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: unset DATA_AVAIL when going to idle stateAndrey Pronin2019-01-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Before the CL, if a TPM command was aborted (READY set in STS) while the response was not completely read, and there was still response data in FIFO, the DATA_AVAIL flag in STS remained set. So, on the next command, the host would see this flag in STS and read this data before the command is processed and the response is formed. As the result, the host would get garbage in FIFO. Transitioning to idle status already resets FIFO read/write indices, so data can't be available after that. This CL additionally unsets DATA_AVAIL flag in STS. BUG=b:118178519 BRANCH=cr50, cr50-mp TEST=imitate several lost TPM ready IRQs in host tpm driver (see BUG), verify that trunksd starts and TPM communication work after that. Change-Id: I38bcf7153b885cbefc94d1f705d385be98be8c8e Signed-off-by: Andrey Pronin <apronin@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1406248 Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: Disabling TPM or enabling TPM.Namyoon Woo2018-06-211-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch introduces a new firmware status, TPM mode along with a new TPM vendor command VENDOR_CC_TPM_MODE. TPM mode indicates whether TPM is enabled or disabled. Initially, this value shall be TPM_MODE_ENABLED_TENTATIVE, which means TPM is enabled but can be changed. VENDOR_CC_TPM_MODE changes this value either as TPM_MODE_ENABLED or TPM_MODE_DISABLED. This is for one time use only until next TPM reset event. Once TPM is disabled, any subsequent TPM commands shall fail. TPM_MODE_TPM_MODE command may be issued with input size as zero, which would not change TPM mode value. Either with the valid input value or without any input value, it returns the current TPM mode value in uint8_t type. This adds 160 bytes in binary. BUG=b:77543596 BRANCH=cr50 TEST=manually (chroot) ./extra/usb_updater/gsctool -h Usage: gsctool [options] [<binary image>] Options: -m,--tpm_mode [enable|disable] Query or control tpm mode (dut) gsctool -a -i Board ID space: XXXXXXXX:XXXXXXXX:XXXXXXXX (chroot) ./extra/usb_updater/gsctool -m enable (dut) gsctool -a -i Board ID space: XXXXXXXX:XXXXXXXX:XXXXXXXX (chroot) gsctool -m enable Error 7 in enabling TPM. (dut) gsctool -a -i Board ID space: XXXXXXXX:XXXXXXXX:XXXXXXXX (dut) reboot (chroot) ./extra/usb_updater/gsctool -m disable (dut) gsctool -a -i Problems reading from TPM, got 10 bytes Error: Failed to send vendor command 25 (dut) tpm_version [ERROR:... TRUNKS_RC_WRITE_ERROR (dut) tpm-manager [INFO:tpm_manager_v2.cc(51)] Initializing TPM. [tpm_manager.TakeOwnershipReply] { status:STATUS_NOT_AVAILABLE } (dut) reboot (chroot) ./extra/usb_updater/gsctool -m TPM Mode: enabled (0) (dut) gsctool -a -i Board ID space: XXXXXXXX:XXXXXXXX:XXXXXXXX (dut) tpm_version TPM2.0 Version Info: ... (dut) tpm-manager [INFO:tpm_manager_v2.cc(51)] Initializing TPM. [INFO:tpm_manager_v2.cc(66)] TPM initialization successful (21 ms). Change-Id: I1453d1a8d03f13cc7fc203863cbc50bf84c9dd8c Signed-off-by: Namyoon Woo <namyoon@google.com> Reviewed-on: https://chromium-review.googlesource.com/1105614 Commit-Ready: Namyoon Woo <namyoon@chromium.org> Tested-by: Namyoon Woo <namyoon@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* cr50: pass params to vendor commands as structRandall Spangler2018-05-231-13/+13
| | | | | | | | | | | | | | | | | | | | | | | This makes it easier to add params or flags for vendor commands without changing all of the command handlers. It also reduces code size by 56 bytes. For now, existing command handlers continue to use DECLARE_VENDOR_COMMAND(). Added DECLARE_VENDOR_COMMAND_P() for handlers which take the params struct directly. The CCD command will be the first user of that, since it will have different rules for 'open' based on where the command comes from. No change to existing command behavior. BUG=b:79983505 BRANCH=cr50 TEST=gsctool -I still works Change-Id: I7ed288a9c45e381162e246b50ae88cf76e67490d Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1069538 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: tpm_alt_extension() specifies command origin is USBRandall Spangler2018-05-231-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, calls to tpm_alt_extension() were treated as if they came from the AP via the TPM interface, even though they actually originated from the cr50 console, which is accessible via the USB interface. This affects the following console commands: spi_hash - was already allowed as both a safe console command and via the USB vendor command interface. No change. rma_auth - was allowed as a safe console command, but not via the USB vendor command interface. Now allowed from both. No change in security, since anyone could already do it via the console. Unfortunately, getting a challenge fails because commands issued via the USB vendor command interface have a maximum payload of 32 bytes and the challenge is bigger than that; that's tracked in b:80098603. ccd - was already allowed as a safe console command. This directly called ccd_command_wrapper() for lock, open, and password subcommands. It made an extra check for password set for the unlock subcommand. Moved the unlock check to the vendor command handler. Also changed the order of checks so that FWMP disabling unlock and open supersedes an existing password; this matches go/ccd-open-simple. (That has no effect on existing systems, because CCD is disabled at a higher level.) Reduces code size by 8 bytes. BUG=b:79983505 BRANCH=cr50 TEST=manual, on a CR50_DEV=1 build Compile with DEBUG_EXTENSION defined to print extra debug output 'ccd lock' now shows as coming from USB 'ccd unlock' fails because no password is set 'ccd unlock' and 'ccd open' fail if FWMP disallows unlock 'rma_auth' prints a challenge 'gsctool -t -r' prints a challenge from AP root shell 'gsctool -r 12345678' returns error 6 (incorrect challenge), rather than error 127 (no such command). 'gsctool -I' works from the host 'gsctool -t -I' still works from AP root shell Change-Id: I2cd1027f5135b9c336df97ee4b1b1a15354728b4 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1068102 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cr50: Refactor tracking vendor command originRandall Spangler2018-05-221-5/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | Added flags parameter to extension_route_command(). The caller now specifies whether the command comes from the USB interface or the AP. Moved USB-specific shuffling of response to embed result code into usb_upgrade.c, so extension_route_command() can be more generic. No change to permissions/behavior for existing commands. ccd_command_wrapper() still sends vendor commands as if they come from the AP. That's fixed in the next CL. Reduces code size by 128 bytes BUG=b:79983505 BRANCH=cr50 TEST=manual Build with DEBUG_EXTENSION defined, to turn on printing each command 'ccd lock' comes from AP and works From host, 'gscutil -I' comes from USB and fails From AP, 'gscutil -t -I' comes from AP and works Change-Id: I7136bb54073de9c5951a174c308151b1871c56f3 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/1068101 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* tpm: ccd: allow alternative commands when ap is held in resetVadim Bendebury2018-02-151-6/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A typical CCD use case is when the DUT is not fully functional, or even completely dead, including corrupted AP/EC firmware. We still want to be able to enable CCD in this case, but routing CCD commands through TPM task context (necessary to ensure the large stack size some CCD commands require) is blocked if TPM was not reset after startup. Let's allow both reset requests and alternative commands when AP is held in reset after reboot. The only situation when the alternative command arrives would be the CCD use case of the system not generating TPM reset pulse at startup and the operator is trying to execute a CCD or RMA reset command. BRANCH=cr50, cr50-mp BUG=b:73292631 TEST=on a reef device: destroyed AP firmware and observed that the 'ccd open' command indeed results in the hung Cr50 console after Cr50 is reset in this state. Loaded the new Cr50 image, (which caused another Cr50 reset), successfully took it through the 'ccd open' sequence resulting in enabling AP flash write access, restored the AP flash and observed the DUT boot into Chrome OS. Change-Id: I4413bc200f5b2be563ba666ff80dd2d889ae5790 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/920924 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* tpm: set waiting task ID earlier.Vadim Bendebury2018-02-071-3/+10
| | | | | | | | | | | | | | | | | | The TPM task is running on a higher priority than the hook task invoking TPM reset for RMA purposes. The waiting task ID value needs to be set before TPM task is signaled to reset. BRANCH=cr50, cr50-mp BUG=b:37952913 TEST=with the corresponding ccd_config.c changes fully verified RMA process (not just generating and processing the challenge). Change-Id: Id112d59ae0c3fd31a32e652c6a043fc3fd3bbe07 Signed-off-by: Vadim Bendebury <vbendeb@google.com> Reviewed-on: https://chromium-review.googlesource.com/905925 Commit-Ready: Vadim Bendebury <vbendeb@chromium.org> Tested-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: pass essential ccd commands through tpm task contextVadim Bendebury2018-01-111-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Using and extending the existing framework, move ccd commands 'password, lock, open, and unlock to the same processing path. The first three commands accept a single parameter, password. It is required for the password command and optional for unlock and open. The lock command does not require any parameters. Wiping the TPM, if necessary, now happens on the same context where CCD command is executed, i.e. the TPM task context. This is why the same context TPM reset function needs to be exported and used here. ccd_open() and ccd_unlock() could be further refactored, this would require a bit more effort to find appropriate balance between commonalities and differences. BRANCH=cr50 BUG=b:62537474 TEST=verified that ccd commands to open, unlock, lock and set and clear password all work. Change-Id: I2b9f2b550347b590a55bfaef262a4f050d3f4c1c Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/854709 Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: do not cache FWMP contentsVadim Bendebury2017-12-081-4/+0
| | | | | | | | | | | | | | | | | | | | | | | Using FWMP for CCD management requires that FWMP contents could be read even when the AP is not operational, i.e. before TPM2_Startup command is issued. A fix is added to the TPM2 library to allow access to FWMP contents even if TPM is not used by the AP. With that in mind there is no need to delay reading FWMP until TPM2_Startup command is issued. With the console task stack increase FWMP contents can be read directly on the console task context. BRANCH=Cr50 BUG=b:62537474 TEST=with TPM patch applied verified that CCD can be opened when AP is down (i.e. TPM2_Startup command was not issued). Change-Id: Ibf4325917a512a855fc658edb9e51e4837328f43 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/817896 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* tpm: do not prevent reading registers during pending resetVadim Bendebury2017-11-161-3/+0
| | | | | | | | | | | | | | | The host should be able to retrieve proper TPM status and ID registers while TPM reset is pending. BRANCH=cr50 BUG=b:68012381 TEST=after appropriate fixes in coreboot the firmware_Cr50ClearTPMOwner autotest does not fail any more Change-Id: I245656ccb1c05e46715deb18bd5f8985c4197c52 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/775281 Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* cr50: fix event definition collisionVadim Bendebury2017-11-071-4/+7
| | | | | | | | | | | | | | | | | | | | | 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>
* tpm: provide means of shutting down comms layer while in resetVadim Bendebury2017-11-071-7/+18
| | | | | | | | | | | | | | | | | | | | | | | 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>
* tpm: let the caller of TPM reset decide if the EC needs to be reset tooVadim Bendebury2017-10-241-17/+2
| | | | | | | | | | | | | | | | | | | TPM reset sequence when TPM wipeout is requested has a side effect of rebooting the entire device. This is not always desirable, in some cases other actions need to happen before the device is rebooted. This patch makes resetting the EC the TPM reset caller's responsibility, BRANCH=cr50 BUG=none TEST=verified that RMA reset and WP disable properly wipe out the TPM and reboot the device. Change-Id: I6e827ce923a2454ae5b2e2597d1a4c9390bbb8b6 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/733813 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Mary Ruthven <mruthven@chromium.org>
* common: add alternative TPM command execution contextVadim Bendebury2017-10-131-14/+109
| | | | | | | | | | | | | | | | | | | | | | | | | The TPM task provides access to various cryptographic functions which require huge stack size. Some other contexts might require to execute these functions, but no other task in the system has enough stack. The suggested solution is to create an alternative TPM task execution path, where the command comes not from the communications interface (SPI or I2C), but from another task in the system. An interface function is created to allow a single task to pass the command to the TPM task. The task requesting the alternative execution path creates the command context, sends an event to the TPM task to alert it to the presence of the command and then polls the flag indicating that the TPM task has completed execution of the command. BRANCH=cr50 BUG=b:67008109 TEST=tested after applying the next patch (add console command for generating RMA auth challenge). Change-Id: I168489a5fbb4a3e1d718198812019116738b2f61 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/699523
* cr50: log tpm reset eventVadim Bendebury2017-08-231-0/+5
| | | | | | | | | | | | | | | | | Use the previously introduced TPM logging framework to log TPM reset events. The two lowest data field bits are used to communicate the type of reset passed to tpm_reset_request(), BRANCH=cr50 BUG=b:63760920 TEST=with the upcoming patches verified that TPM initialization is logged as expected Change-Id: Ic0874723ec6df616a8237b036542398b29fe5ccc Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/620113 Reviewed-by: Mary Ruthven <mruthven@chromium.org> Reviewed-by: Shawn N <shawnn@chromium.org>
* cr50: Add helper functions for device-is-enabledRandall Spangler2017-08-171-2/+1
| | | | | | | | | | | | | | | | | | | | A subsequent CL will massively refactor the device state machines. Add the helper functions which will be used by that CL, so that the refactoring touches fewer files. No change in functionality. BUG=none BRANCH=cr50 TEST=make buildall; boot cr50 with a CR50_DEV=1 image Change-Id: I3499d45e93fa15b6de9c04ce398d1c5bfbbc01e9 Signed-off-by: Randall Spangler <rspangler@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/616300 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>
* cr50: make sure tpm reset in factory mode always happensVadim Bendebury2017-08-011-11/+17
| | | | | | | | | | | | | | | | | | | | | When the chip is used in the factory harness, the AP device state is set to off, which prevents tpm reset from being invoked, which in turn prevent the certificate from being copied into NVMEM. Let's not wait for the AP to be up when running in chip factory mode. BRANCH=cr50 BUG=b:63686091 TEST=running cert installation procedure produces SPI dummy byte of c0c0c0c0... after the successful installation and of cbcbcbcb... after repeated cert installation attempts. Change-Id: Ibc4ff50511dccd8412a380ec03fc5ff8a14b0282 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/594953 Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
* cr50: provide chip factory mode supportVadim Bendebury2017-07-301-5/+34
| | | | | | | | | | | | | | | | | | | | | | 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>
* cr50: handle board ID mismatch gracefullyVadim Bendebury2017-06-161-4/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* cr50: read fwmp and act on it when controlling console restrictionsVadim Bendebury2017-05-311-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Store console lock state in NvMem vars.Aseda Aboagye2017-02-271-1/+6
| | | | | | | | | | | | | | | | | | | | | | 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: Make sure TPM wipe only clears TPM data.Aseda Aboagye2017-02-231-2/+2
| | | | | | | | | | | | | | | | | | | | Previously, wiping the TPM would wipe all of NvMem, however, it really should only clear the TPM's NvMem space. This commit adds a function to clear a given NvMem user's space and makes the TPM only clear its space. BUG=chrome-os-partner:61597 BRANCH=None TEST=Add code for using nvmem vars, create a test variable, add a user to snappy, unlock the console, verify that the user is no longer present on the system and the test nvmem var still exists. TEST=make -j buildall Change-Id: Ic98baa5166a1ef9ae76e910b1b9ab100300e947f Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/445803 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* g: extension: Add a whitelist for vendor commands.Aseda Aboagye2017-02-181-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The USB FW upgrade endpoint should really only accept vendor commands required to perform the firmware update. This commit adds a whitelist that is checked whenever a vendor command is received over this endpoint. The allowed commands over USB are the following: - EXTENSION_POST_RESET - VENDOR_CC_IMMEDIATE_RESET (only for dev images) There is also functionality to have a whitelist for vendor commands that come over the TPM interface. BUG=chrome-os-partner:62815 BRANCH=None TEST=Flash Cr50 with image containing this change. Verify that an upgrade over USB to newer image works. TEST=Try using usb_updater to send a vendor command that's not in the whitelist. Verify that the vendor command is dropped. Change-Id: I71f8ba090a1cc6c9e7c30ce0dd3c25259e8f292f Signed-off-by: Aseda Aboagye <aaboagye@google.com> Reviewed-on: https://chromium-review.googlesource.com/443447 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Aseda Aboagye <aaboagye@chromium.org> Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* cleanup: Move chip/g-specific system() prototypes to system_chip.hShawn Nematbakhsh2017-02-181-0/+1
| | | | | | | | | | | | | BUG=chromium:693148 BRANCH=None TEST=`make buildall -j` Change-Id: I7a758e6b5a04721d0422cfe8b767d85abddb1ad2 Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/444264 Commit-Ready: Aseda Aboagye <aaboagye@chromium.org> Tested-by: Shawn N <shawnn@chromium.org> Reviewed-by: Randall Spangler <rspangler@chromium.org>
* cr50: rework sleep state and tpm reset triggersVadim Bendebury2017-02-071-6/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* tpm: rename tpm_reset to tpm_reset_requestMary Ruthven2017-01-281-13/+18
| | | | | | | | | | | | | | tpm_reset just requests a tpm reset it doesn't reset the tpm. Rename the function to reflect that. BUG=none BRANCH=none TEST=make buildall Change-Id: I6f4763b5de578a8cf263b2fac98fad3af2c25d65 Signed-off-by: Mary Ruthven <mruthven@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/434245 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* nvmem: do not use malloc for cached bufferVadim Bendebury2017-01-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With introduction of encryption it is becoming impossible to read NVMEM contents directly from flash. Decrypting the contents each time there is a read request creates a significant performance hit. NVMEM needs to be rearchitecture such that there is no need to run decryption each time NVMEM read is performed. This patch does just that, implementation details are described in the header comment in common/nvmem.c. To reduce memory impact the size of NVMEM is being decreased from 16K to 12K. This is acceptable because eviction objects stored in NVMEM serialized now, which dramatically reduces NVMEM size requirements. The TPM2 NVMEM size definition must be kept in sync. Another optimization this change introduces is bypassing writing into the flash if NVMEM contents did not change, which is verified by examining the hash of the cached storage. A test is added to verify that the new commit scheme works as expected, and the nvmem test is re-introduced to the list of test ran on each 'make buildall'. CQ-DEPEND=CL:433839 BRANCH=none BUG=chrome-os-partner:62260,chrome-os-partner:62421 BUG=chrome-os-partner:62437 TEST=ran the following tests, all succeeded make buildall -j TEST_LIST_HOST=nvmem make runtests tcg test suite corp enroll on reef, reboot a few times, verify that enrollment sticks Change-Id: I177daa3ceb4fd7aac299ca26b4506b863e31b946 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/433184 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* cr50: reinstate nvmem commits 3 s after tpm resetVadim Bendebury2017-01-141-13/+38
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Relying on the AP sending a PCR read as an indication of the completed boot process does not work on the resume path. Let's just enable commits 3 s after they were stopped to process tpm reset. BRANCH=none BUG=chrome-os-partner:61795 TEST=observed the following on the cr50 console on a reef during reboot: [0.018692 tpm_init] tpm_manufactured: manufactured [0.021180 tpm_reset_now: done] . . [1.166496 Skipping commit] [1.425888 Skipping commit] [1.439112 Skipping commit] . . [3.021892 Committing NVMEM changes.] and verified that reef booted normally. Change-Id: I5f64fe24b961a9d0366f8e4f40a0e44d4e7263fa Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/427328 Reviewed-by: Aaron Durbin <adurbin@chromium.org>
* cr50: Avoiding nvram commits at startupVadim Bendebury2017-01-051-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch eliminates NVMEM commits at system startup, namely between the moment the TPM is reset and the moment the AP is trying to read a PCR (which is an indication of the AP having booted into OS). To avoid losing NVMEM changes in case TPM is reset before PCR Read command is issued, pending changes (if any) are saved before TPM reset is processed. For the same reason TPM reset invocation is being added to the hard reboot path; this will kick in when there is a restart after cr50 firmware update. BRANCH=none BUG=chrome-os-partner:59873 TEST=with instrumented coreboot/depthcharge observed the following execution times for various TPM command issued at startup command 0x144, 15203 us command 0x14e, 11814 us command 0x182, 12461 us command 0x182, 12456 us command 0x138, 11503 us command 0x138, 11512 us command 0x14e, 14648 us command 0x14e, 12597 us command 0x121, 11353 us which totals 113 ms and shaves more than 200 ms off the boot time. Change-Id: Ic52309291fdb9c3ede96e0ad015ad9fc076bddc5 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/424063 Reviewed-by: Aaron Durbin <adurbin@chromium.org> Reviewed-by: Andrey Pronin <apronin@chromium.org>
* Cr50: Prevent rebooting when unlocking the consoleBill Richardson2016-11-191-20/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the console is unlocked, the function nvmem_wipe_or_reboot() is called. This holds the EC in reset, clears nvmem, resets the TPM task, then releases the EC. Nothing about that should cause the Cr50 to reboot, but it was happening anyway. This CL addresses several subtle problems. First, holding the EC in reset invoked the sys_rst_asserted() interrupt handler, triggering extra (and early) calls to tpm_reset(). That should wait until after nvmem is cleared, and only be called once. Second, the intentional call to tpm_reset() caused the current (HOOKS) task to wait for the operation to finish, but it didn't wait long enough (recreating the endorsement certs can take over a second). When the task_wake_event() returned, a timeout was indicated in addition to the completion event. Third, because we checked for the timeout first, we reported an error even though tpm_reset() completed successfully, just slower than we expected. We didn't get the timeout event before it completed because the TPM task runs at a higher priority. This CL addresses all of these cases, and makes wiping nvmem the responsibility of the TPM task as well, so that it can do it when it's ready. Note that the EC (and thus AP too) will be held in reset while nvmem is erased. BUG=chrome-os-partner:59902 BRANCH=none TEST=make buildall, manual tests From the Cr50 console, run the "lock on" and "lock off" commands. Try it both with and without the battery present. Observe that the Cr50 no longer reboots just because the console unlocks. Change-Id: I65a342502718acc5b9bda8c6f28dcd27e8f027f7 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/411379 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* Improve readability for file-scoped variablesBill Richardson2016-11-181-7/+33
| | | | | | | | | | | | | | | | | | | File-scoped variables in common/tpm_registers.c must be handled specially to avoid unexpected behavior when calling tpm_reset(). Enhance the comments and add a couple of macros to help explain it better. BUG=none BRANCH=none TEST=make buildall; Run on Reef This is just commenting and code cleanup. No changes in behavior are expected; none are observed. Change-Id: If70e56d00642a11df7b5ceb5d5d32c485236f7a8 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/412407 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* Fix various misspellings in commentsMartin Roth2016-11-151-2/+2
| | | | | | | | | | | | | No functional changes. BUG=none BRANCH=none TEST=make buildall passes Change-Id: Ie852feb8e3951975d99dce5a49c17f5f0e8bc791 Signed-off-by: Martin Roth <martinroth@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/403417 Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
* Cr50: Add TPM-compliant commands for console lockBill Richardson2016-11-111-8/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This allows custom TPM commands to be declared using the a DECLARE_VENDOR_COMMAND macro instead of the original (and still unchanged) DECLARE_EXTENSION_COMMAND macro. The new commands are nearly identical, but they are encapsulated using the vendor-specific protocols described in the TPMv2 spec. Our original extensions use a non-standard command code, and return a non-standard struct on completion, which can be confusing to standard TPM drivers and tools. Demonstrating the use of the new macros, this adds commands to obtain the state of the Cr50 restricted console lock, or to set the lock. There is intentionally no command to unlock the console. Note that this CL just adds the commands to the Cr50. We still need to provide a nice userspace utility for the AP to use. BUG=chrome-os-partner:58230 BUG=chrome-os-partner:57940 BRANCH=none TEST=make buildall; load, boot, test, and update again on Reef On Reef, I can use the trunks_send tool to send the raw TPM bytes to invoke these commands: Get the lock state: # trunks_send 80 01 00 00 00 0C 20 00 00 00 00 10 80010000000D00000000001000 The last byte 00 indicates that the lock is NOT set, so set it: # trunks_send 80 01 00 00 00 0C 20 00 00 00 00 10 80010000000C000000000011 Success. On the Cr50 console, I see it take effect: [480.080444 The console is locked] Query the state again: # trunks_send 80 01 00 00 00 0C 20 00 00 00 00 10 80010000000D00000000001001 and now the last byte 01 indicates that the console is locked. And of course the existing extension commands still work as before. In addition to uploading firmware, I can use the usb_updater from my build machine to query the running firmware version: $ ./extra/usb_updater/usb_updater -f open_device 18d1:5014 found interface 4 endpoint 5, chunk_len 64 READY ------- start Target running protocol version 5 Offsets: backup RO at 0x40000, backup RW at 0x4000 Keyids: RO 0x3716ee6b, RW 0xb93d6539 Current versions: RO 0.0.10 RW 0.0.9 $ Change-Id: I7fb1d888bf808c2ef0b2b07c782e926063cc2cc4 Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/409692 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* Cr50: Let NVMEM take more time and memoryBill Richardson2016-11-051-0/+2
| | | | | | | | | | | | | | | | | | | | | | We were getting occasional stack overflow and watchdog timeouts when clearing NVMEM. Bump up the stack size a bit in the HOOKS task, and pet the watchdog before invoking the tpm2 init functions. BUG=chrome-os-partner:59419 BRANCH=none TEST=make buildall, manual Lock the console, then unlock it. This will reboot the EC & AP, but should never reboot the Cr50. Before this CL, it did about half the time. After, it doesn't. Change-Id: I33adfeb7360bf7d146a55ef16c923a1a0416393d Signed-off-by: Bill Richardson <wfrichar@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/407847 Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* tpm: do not try running endorsement commands before nvram is availableVadim Bendebury2016-10-061-2/+3
| | | | | | | | | | | | | | | | | | | | Recent tpm2 repository changes introduced more strict checks of the NV RAM operations' return status. The problem is that in case TPM is not manufactured tpm_endorse() is invoked before nvram is declared available, and this causes endorsement operation failure. Make sure NVRAM initialization is complete before endorsement is attempted. BRANCH=none BUG=none TEST=tpm manufacturing now succeeds again. Change-Id: I2217f33915ab8b4d872a9498def6d6862f4b1913 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/394129 Tested-by: Marius Schilder <mschilder@chromium.org> Reviewed-by: Marius Schilder <mschilder@chromium.org>
* cr50: tpm: ignore sys_rst_l/plt_rst_l when TPM reset is in progressVadim Bendebury2016-09-271-1/+6
| | | | | | | | | | | | | | | | | | | | | | There is no point in invoking TPM reset while the current invocation is in progress. One of the cases when this is happening is early start up on Kevin/Gru: the device starts booting, the EC comes around to pulsing sys_rst_l when TPM is already busy installing endorsement certificates. There is no point in issuing another reset at that point, just let the process continue. BRANCH=none BUG=chrome-os-partner:52366 TEST=firmware_TPMKernelVersion firmware_TPMExtend autotests still pass on kevin. Certificate installation during startup does not get interrupted any more. Change-Id: Ibdface9f7a76186e210ef0f4111cd5fe9905bba9 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/389811 Reviewed-by: Bill Richardson <wfrichar@chromium.org>
* tpm: reset communications channels when resetting TPMVadim Bendebury2016-09-261-8/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | TPM resets happen asynchronously, conceivably there is some interface (i2cs or sps) activity under way when TPM is reset. Sps driver provides a means of disconnecting the client of the driver, while the i2cs driver does not. Come to think of it, there is no real need to provide a special function to disconnect a client, this makes API simpler and allows to add driver initialization to the client registration function. To make tpm_registers.c more flexible - allow to register a callback for interface initialization, this way when TPM is reset, the interface can be also re-initialized and is guaranteed to start from scratch after reset. BRANCH=none BUG=chrome-os-partner:52366 TEST=both firmware_TPMExtend and firmware_TPMKernelVersion autotests pass Change-Id: I212166a23f9cd512d8f75315377d1f5620aea070 Signed-off-by: Vadim Bendebury <vbendeb@chromium.org> Reviewed-on: https://chromium-review.googlesource.com/388886 Reviewed-by: Randall Spangler <rspangler@chromium.org> Reviewed-by: Bill Richardson <wfrichar@chromium.org>
View Lorry Controller Status