| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch introduces '-m' or '--tpm_mode' flag, which either
enables or disables TPM.
(chroot) gsctool -m enable
open_device 18d1:5014
found interface 3 endpoint 4, chunk_len 64
READY
-------
(chroot) gsctool --tpm_mode disable
open_device 18d1:5014
found interface 3 endpoint 4, chunk_len 64
READY
-------
BUG=b:77543596
BRANCH=gsctool
TEST=manually
Signed-off-by: Namyoon Woo <namyoon@google.com>
Change-Id: I2feb8c51d4343a49f2f5d43291c304e3ad140057
Reviewed-on: https://chromium-review.googlesource.com/1106295
Commit-Ready: Namyoon Woo <namyoon@chromium.org>
Tested-by: Namyoon Woo <namyoon@chromium.org>
Reviewed-by: Namyoon Woo <namyoon@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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_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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 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>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To reset the TPM task, we send it an event so that it will reset
only when it's not busy doing actual TPM stuff that might fiddle
with the stack or shared memory. But that means that we can't
always know when the task finally gets around to resetting
itself.
This CL adds a tpm_reset() function that blocks until the reset
actually occurs. Obviously it can't do that if it's being called
in interrupt context or from the TPM task itself, but otherwise
it does.
BUG=chrome-os-partner:52366
BRANCH=none
CQ-DEPEND=CL:361680
TEST=make buildall, test on Gru, manual tests
In addition to the normal rebooting, logging in/out, and so
forth. I added a temporary console command to call tpm_reset()
and scattered a bunch of ccprintfs around it. When called due to
SYS_RST_L, it didn't block. When invoked with the console
command, it did.
Change-Id: I51e8b1299dbdcd1a12273cf48a890e93ed32a8c8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388125
Reviewed-by: Randall Spangler <rspangler@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than doing a full cr50 reset when the system reset SYS_RST_L is
asserted, just reset the state of the TPM task and library. Re-clear
.bss for those modules, then re-initialize.
BRANCH=none
BUG=chrome-os-partner:52366
CQ-DEPEND=CL:366792
TEST=make buildall; test on Gru
Trigger a SYS_RST_L by using the AP's reboot command, power
off/on, log in/out/in.
See that the Cr50 does not reboot and the firmware and userspace
are still happy about the TPM.
Change-Id: I32cd2bb72316f68c74db77a20a8d09112b402d4b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361680
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This CL includes changes in Cr50 required to support TPM via
the I2CS interface.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Limited testing so far. Verified that the I2CS interface is
initialized properly and that register reads occur when
initiated on the AP console via command i2cget -y 8 0x50 0x1 w
Change-Id: I16ac17c7c82d420a384908e4b5a9867a3b24bc9e
Reviewed-on: https://chromium-review.googlesource.com/356241
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a temp measure until a proper solution is implemented, reset the
restart counter when the PCR_Read command is issued by the host.
This is a good indication that Chrome OS is through the boot process,
as PCR value is used to determine the boot mode.
BRANCH=none
BUG=chrome-os-partner:55667
TEST=installed the new image on a Kevin cr50 and rebooted it in normal
and recovery modes, observed on the cr50 console the message like
> system_process_retry_counter:retry counter 1
Change-Id: Ib55e161d5edbf8f6e2d387fd756b94aa53c20ed8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364311
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This code allows to send extension commands over TPM protocol, no
callbacks have been registered yet.
The same buffer is used as input and output data. The header is
stripped off before the callback is called and then re-added after
processing.
This could be used for testing, for proprietary firmware update
protocol, etc.
BRANCH=none
BUG=chrome-os-partner:47524
TEST=none yet
Change-Id: I91f692cc6e20abe774ee4ef001be28e5af102b2a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312587
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Use the previously introduced endian conversion routines in the driver
and the TPM2 library.
Use packed TPM message header structure to make it easy to access
unaligned header fields.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=the tpm startup command still succeeds.
Change-Id: I03078481664858a19617e248f98cb20013c27445
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/312585
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
TPM command processing should not be happening on the interrupt
context.
This patch adds a skeleton of the task which handles TPM functions. It
initializes the TPM and then enters endless loop waiting for an event
trigger from interrupt, which happens when a valid FIFO message is
received.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=none yet
Change-Id: I63dce2762cc07370a05bf00bdf144c5d9eb6019b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/289332
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
|
|
|
This patch adds a module which runs on top of the SPS driver and
implements the TCG SPI TPM protocol.
Basic register read and write functions are implemented as well as
rudimentary TPM state machine (claiming/releasing locality).
An enhancement is made to the SPS driver to ensure that when the CS is
deasserted the transmit FIFO is reset too, on the off chance of the CS
going away mid transaction for whatever reason.
In this implementation the slave is guaranteed to stall the master for
a few bytes in both receive and transmit transactions, which is
further aggravated by the fact that RX FIFO threshold is set to 8
(this is the minimum number of bytes the master has to send to wake up
the slave). This could be fine tuned later, for instance made a
parameter of the receive callback registration function.
BRANCH=none
BUG=chrome-os-partner:43025
TEST=trunksd initialization (with minor changes to accommodate new
VID/DID and some status bits, to be published) succeeds with the
cr50 connected to the USB/SPI cable.
Change-Id: I28d37c3b57dde9adf59e81426efe4f58880cf0b0
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/285252
|
