Commit 9e7c12b added a command-line option to "make" to build
development versions of the Cr50 board. This makes the symbol
definition useful in makefiles and not just C code.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Id0719d63263b00e192a2e4866dbe1551ae49e23c
Reviewed-on: https://chromium-review.googlesource.com/391127
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The application may need to read/write/erase the flash memory,
but we not want console users to do so. This CL adds
CONFIG_FLASH_PHYSICAL, which allows the higher-level CONFIG_FLASH
to be undefined while still providing the chip-specific
flash_physical_* accessor functions.
There aren't many board.h files that needed changes, since
CONFIG_FLASH_PHYSICAL is enabled by default, just like CONFIG_FLASH.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
See that it still boots, updates, wipes, restores, etc. without
linking common/flash.o in the production image; and that the
flash commands are still there in the dev build.
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: I7eb1bbcb414b1c70ee427c4fcb5cea899dbb9e93
Reviewed-on: https://chromium-review.googlesource.com/391188
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
And even that's a bit of a stretch. This entire endpoint will
probably be deactivated until it's more useful. In the meantime,
we can just leave the one little debug command for debug builds.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Id4c185fe66d52fa49fcbee6a549df41d297c41af
Reviewed-on: https://chromium-review.googlesource.com/391045
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The rdd features are working (and it's better to test with
hardware anyway), so just delete this command.
BUG=chrome-os-partner:57408
BRANCH=none
TEST=make buildall; try on Gru with and without CR50_DEV=1
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Change-Id: Ifcfc8c8a0e61a9fe31d28f0c96bcb50c3e2b93b5
Reviewed-on: https://chromium-review.googlesource.com/391314
Reviewed-by: Vadim Bendebury <vbendeb@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>
Similar to the TPM SPI interface, added code to disable sleep an I2CS
interrupt is received. Enabling sleep follwoing a 1 second delay when
the TPM fifo register has been read by the host. The I2CS TPM layer
doesn't know when a command has finished, but the one second delay is
more than enough delay since sleep will be disabled again when the
next I2CS interrupt is received.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Tested without these changes first. Shortened sleep delay to 30
seconds, and disconnected suzyq. Waited 30 seconds then issued the
command on the AP console:
tpmc read 0x1007 0xa
[ 59.796813] tpm tpm0: tpm_transmit: tpm_send: error -16
ERROR: write failure to TPM device: Device or resource busy
In addition, using logic analyzer verifed that there was activity on
SDA/SCL but no response from Cr50. With this CL in place, ran the
test and got the following:
tpmc read 0x1007 0xa
2 0 1 0 1 0 0 0 0 4f
With the logic analyzer I was able to confirm that there was no
activity from the host on the I2CS bus until the command was issued.
Change-Id: If07573ae8f72b983bca57979d53c22660b91b95e
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/387910
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Fixed an issue with word aligned write to fifo routine. There were two
errors. In the top section, the fifo was being read always from the
beginning word or the hw fito, but the updated word was written back
to the proper location.
The same error was in the section that dealt with the last < 4 bytes.
Both have been corrected. The error in the top section would in practice
be invisible because flow control prevents TPM fifo reads from
happening while one is in progress. The error in the bottom section
was responsible for the problem as described in chrome-os-partner:57782.
BRANCH=none
BUG=chrome-os-partner:57782
TEST=manual
Used special AP fw build that supports a 'tpm_raw' command to initiate
the Cr50 TPM fifo write/read.
'tpm_raw 0x80 0x01 0x00 0x00 0x00 0x16 0x00 0x00 0x01 0x7a 0x00
0x00 0x00 0x06 0x00 0x00 0x02 0x00 0x00 0x00 0x00 0x7f'
Without this CL, the 1st two bytes were incorrect ~50% of the time.
With the fix in place, verified that the first two bytes returned were
always correct.
Change-Id: Iff7620561eee463d599abfa6c07455c56bb5a5a6
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388785
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
cr50 should pretty much never reset, but when it does, for whatever
reason, the device it is running on must reset as well.
This patch makes every cr50 reset (be it command line induced, or
caused by an exception) a hard reset, such that it re-initializes the
R-box, which in turn causes reset of the entire platform.
CQ-DEPEND=CL:361680
BRANCH=none
BUG=chrome-os-partner:55948
TEST=verified that running commands like 'reset' or 'md 0xf0000'
(which triggers an exception) causes the entire chromebook to reboot.
Change-Id: Ifa160450b9b4c5ef25e512caf1ffdced9c97acd6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/388007
Reviewed-by: Bill Richardson <wfrichar@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 change sets UART_FIFO_RXILVL to 3 for the AP and EC UART. With this
change RXINT will only be triggered when 4 characters are received
instead of for every character.
The change also flushes the RX FIFO whenever console input is received
through usb make sure to the user can see their input as they are typing.
BUG=none
BRANCH=none
TEST=run taskinfo after the system finishes booting.
Before Change the IRQ count for 181 should be around 20000.
After the change it should be around 5000.
Use the AP and EC console over USB and verify there is no
noticeable change in their usability.
Change-Id: I134ea0d2bc254038dad6c341b94f822adb90c000
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/387175
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
On CHIPSET_SHUTDOWN set the idle_action to deep sleep. If sleep is
enabled it will go into deep sleep. If not it will wait until sleep is
sleep is enabled.
This change also sets the idle_action to IDLE_DEFAULT when resuming from
deep sleep or during init. Before cr50 kept track of the previous idle
state in a PWRDN register and then used that state during the next
resume. If we went into deep sleep, on resume we want the idle action to
be reset to sleep and then only enter deep sleep if we have detected the
AP is off.
BUG=chrome-os-partner:56100
BUG=chrome-os-partner:55747
BRANCH=none
TEST=manual
run 'poweroff' on the AP and see that cr50 enables deep sleep
verify that even if the ap is powered off it doesn't prevent ccd
from working and when suzyq is unplugged cr50 will go into deep
sleep
After running poweroff on the AP wait a while and run powerbtn
on the EC. Verify the system can boot up fully without going
into recovery.
Do this on gru and reef.
Change-Id: I07f5a9d85dd0467cd22e499d4261c75caf653563
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373139
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We want the default build to be ready for production use, without
any unlocked security features, development-only tests, etc.
Running "make buildall" or "make BOARD=cr50" builds the
default (production) image.
To build a development image, use
CR50_DEV=1 make BOARD=cr50
This CL adds "-DCR50_DEV=$(CR50_DEV)" to the CFLAGS for use in
compiled code.
BUG=chrome-os-partner:55557
BRANCH=none
TEST=make buildall
Verify that
#ifdef CR50_DEV
[stuff]
#endif
works inside C code.
Change-Id: Id5e16e9ba0135828f4365fc1ac4a23384f30ba01
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/385059
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
If the host sends a back to back I2CS write followed by a read of the
access register, then the read IRQ can be missed by FW because it was
clearing this bit at the end of the ISR. This would result in a
following write to have the incorrect number of bytes since the
address register byte from the read that wasn't processed gets left in
the HW write fifo.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
The issue was happening at the beginning of depthcharge. Without this
fix, I would see the Cr50 console message:
'data size mismatch for reg 0x0 rx 2, need 1'
After moving the IRQ clear could not reproduce this message. In
addition, the debug I2CS log showed that there was a read transaction
immediately following the write.
Change-Id: I9854dde6880a789e0acb2b1f6a06b43c73a5a2df
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382687
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
There is no point in waiting for a reset to clear the fallback
counter, it can be cleared as soon as USB update is finished.
BRANCH=none
BUG=chrome-os-partner:56864
TEST=on a kevin-tpm2 device: set the reset counter to 7 by running
> rw 0x40000128 1
> rw 0x4000012c 7
on the cr50 console. Then try uploading a new RW image over Suzy-Q
and verify that it is running after reset.
Then verify that cr50 can still be updated
Change-Id: I098a87c48b2fe864143715b1e90d4bb2409b9eae
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/383077
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Sanity tested by powering up cr50 and checking for correct RBOX
register values.
This patch is mainly to address RBOX debounce issues and key blocking
while EC_RST is asserted. A debounce value less than 4, sometimes
causes initial pin values to be incorrectly detected. The latter is
related to https://chromium-review.googlesource.com/#/c/357590/.
As RBOX controls cannot be selectively bypassed (they have to be
bypassed as a group), all registers are set up in this patch
BUG=chrome-os-partner:54602
BRANCH=None
CQ-DEPEND=CL:377621
TEST=manual on Kevin
Do three-finger salute, enter recovery mode.
Change-Id: Ieb82c94fa33888ead359a77bf77981567998b3fc
Signed-off-by: Timothy Chen <timothytim@google.com>
Reviewed-on: https://chromium-review.googlesource.com/372001
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
We don't really have the ability to build the latest signer yet, but
this should not stop us from being able to build a properly signed
image using the ec makefiles.
As a stopgap measure the suggestion is to keep the latest signer
binary in ~/bin/codesigner in chroot, then with this patch applied
invoking make with CR50_DEV=1 will cause the proper sighner used and
proper signing procedure followed.
The signed targets need to be built in series to avoid concurrent use
of the signer fob, an addition dependency is being added to enforce
that.
BRANCH=none
BUG=chrome-os-partner:55557
TEST=ran make as follows:
CR50_DEV=1 make BOARD=cr50
touched the fob when requested, uploaded the generated
build/cr50/ec.bin on a kevin-tpm2 using usb_updater, and observed
it boot properly with the new version.
Change-Id: Ia9494bdc60b4bd3b8e5e09cbcbd8b27409c739d2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376885
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reads of the TPM fifo by the Host are done in chunks of up to 63 bytes
at a time. The existing routine used to copy data read from the TPM
layer to the I2CS fifo operates one byte at a time. This method is
fine for single and four byte register reads. However, for larger
buffers the performace can be improved by aligning the the fifo write
pointer to be at a word boundary.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Utilized test code on the host to initiate TPM fifo reads of various
lengths and added timing markers on the Cr50 to compare performance
between the existing byte at a time and the new full buffer write
funciton. Verifed that the fifo reads will still correct and compared
the time consumed copy TPM fifo data to the I2CS HW fifo.
This test processed 1910 bytes over 34 fifo reads.
Byte at a time method:
1910 bytes: 6375 uS: Avg Time = 3.233 uS per byte
Full buffer write:
1910 bytes: 3009 uS: Avg Time = 1.57 uS per byte
Change-Id: I3a47a350ab7af740a452fd115c33117b453b9611
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/377663
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This CL adds support for reading of TPM fifo registers. Since I2C does
not provide means to communicate how many bytes the host wants to read
there must be some handshake involved between the host and Cr50.
The method added by this CL to allow Host reads of the TPM fifo
assumes the following steps:
1. Host reads burstcount from Cr50 (which will be set to default 63)
2. Host reads 1st 10 bytes of the TPM response.
3. Cr50 will copy MIN(burstcount, msg_len) bytes into its I2CS HW fifo
4. Host computes msg_len and calculates amount of data still buffered
5. Host does a TPM fifo read of buffered data only
(The following steps are repeated until the response read is complete)
6. Host reads burstcount from STS register.
7. Host issues read of burscount bytes from TPM fifo
8. I2CS will copy burstcount amount of bytes in to I2CS HW fifo
9. TPM layer sets burstcount to MIN(63, remaining msg bytes)
The version register is treated similar to a fifo access. The data
written or the number of bytes is a don't care, but there must be
at least one byte of data written with the version register write.
In the case of reads, the host must read burstcount bytes of the
version register. If burstcount is longer than the Cr50 version string
there is no issue because the version register read function always
returns the number of bytes requested, stuffing in 0s once the end of
the version string is reached.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Created test code in coreboot that exercises TPM register reads and
writes. In addition, created a means to spoof a TPM cmd send and
response read by Host. For these tests the header length is defined as
10 bytes and used 3 different payload lengths. The results for a
payload length of 256 and 39 (message < 63) are shown below. Note the
0xaa and 0x55 have been inserted by the TPM spoof code on the host to
mark the end of the header.
=================================================
Cr50 TPM Register Read tests
TPM Access = 0x0
TPM2 STS = 0x4003f80
TPM2 DID_VID = 0x281ae0
DID = 0x28, VID = 0x1ae0
Ver segment read 1, ret = 0
Version: B2:0 RO_A:0.0.1/84e2dde7 RW_A:0.0.1/cr50_v1.1.5151-acaef21+
=================================================
TPM Cmd: 266 bytes, Hdr = 10, Payload = 256 (last = ff)
TPM STS: Sending command_ready
fifo wr: burstcount = 63
fifo wr: Sent TPM Cmd: len = 266 bytes
TPM STS: Sending TPM GO
TPM STS: data_avail set
TPM STS: 04 00 3f d0: burst = 63
fifo rd: Msg_len = 266
fifo rd: Hdr Len = 10, fifo_adjust = 53
fifo rd: Drained Cr50 HW fifo of 53 bytes
fifo rd: burst = 63
fifo rd: burst = 63
fifo rd: burst = 63
fifo rd: burst = 14
fifo rd: complete 266 byte msg read
[0000]: 00 00 00 00 01 0a 00 00 aa 55 00 01 02 03 04 05
[0010]: 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
[0020]: 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
[0030]: 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35
[0040]: 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45
[0050]: 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55
[0060]: 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65
[0070]: 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75
[0080]: 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85
[0090]: 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95
[00a0]: 96 97 98 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5
[00b0]: a6 a7 a8 a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5
[00c0]: b6 b7 b8 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5
[00d0]: c6 c7 c8 c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5
[00e0]: d6 d7 d8 d9 da db dc dd de df e0 e1 e2 e3 e4 e5
[00f0]: e6 e7 e8 e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5
[0100]: f6 f7 f8 f9 fa fb fc fd fe ff 00 00 00 00 00 00
=================================================
TPM Cmd: 49 bytes, Hdr = 10, Payload = 39 (last = 26)
TPM STS: Sending command_ready
fifo wr: burstcount = 63
fifo wr: Sent TPM Cmd: len = 49 bytes
TPM STS: Sending TPM GO
TPM STS: data_avail set
TPM STS: 04 00 3f d0: burst = 63
fifo rd: Msg_len = 49
fifo rd: Hdr Len = 10, fifo_adjust = 39
fifo rd: Drained Cr50 HW fifo of 39 bytes
fifo rd: complete 49 byte msg read
[0000]: 02 00 00 00 00 31 00 00 aa 55 00 01 02 03 04 05
[0010]: 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
[0020]: 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
[0030]: 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Change-Id: I0e05156d6012c6dc86844e4c0ea80cc04f45734a
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374528
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Removed 3 TPM register definitions which were not used in
tpm_registers.c and added missing entries to the I2CS translation
table for TPM register address lookup.
Moved the SPI specific locality 0 offset from tpm_registers.c to
sps_tpm.c so the register defines in tmp_registers.c can be
common to both the SPS and I2CS interface.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
For I2CS verification on Reef AP console used the command 'i2cget
-y 8 0x50 <addr> b' to read both the TPM access and RID register.
For SPI verifcation updated Cr50 FW on Kevin and verified that the
AP successfully boots. Additionally, issued the command from the
Kevin console 'trunks_client --own' and got the following console
output without any errors being listed.
[INFO:tpm_utility_impl.cc(1692)] CreateStorageRootKeys: Created RSA SRK.
[INFO:tpm_utility_impl.cc(1735)] CreateStorageRootKeys: Created ECC SRK.
Change-Id: Ib0b70e22cd46de2c59bd2e73f3c9aebd661e66c4
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368621
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
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>
CONFIG_FLASH_NVMEM_SIZE was set to CFG_TOP_SIZE and then the partition
size was computed by dividing this value by 2. Changed this so that
now the partition size is set to CFG_TOP_SIZE and the total size is
the partition size * 2. Also reduced the CFG_TOP_SIZE to 0x4000 as
that should be plenty for TPM requirements and leaves room for future
gnubby use.
BRANCH=none
CQ-DEPEND=CL:379076
BUG=chrome-os-partner:56798
TEST=manual
Tested on Kevin, erased the existing NvMem area and verified that TPM
was still manufactured and executed the command: trunks_client --own
Erased parition 0 and 1 in the new locations and repeated the tests.
Change-Id: Ie8910bec641d8d1ff390be5b03b430bf39d18404
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/379095
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
There is now a call to reset the retry counter before the hard reset
after an update. Cr50 will use the updated image for the next 5 boots,
but on the 6th it sees the retry counter is greater than 5 and then
jumps back to the old image. Cr50 needs to call
system_process_retry_counter to reset the counter and corrupt the old
image header to prevent falling back to the old image.
Normally the reset counter would be processed after it receives a TPM
command. Reef does not have Cr50 TPM support. Until Cr50 has TPM
support for Reef, Cr50 should have a different point to know when the
update is good. This change adds a board property to mark the process
the reset counter once the Cr50 USB controller receives a set address
request from the host. On Reef the controller defaults to the AP PHY
when suzyq is not connected, so it should have a connection to the AP
or through suzyq after boot.
The board property is only added to Reef. Behavior on Kevin and Gru is
unchanged.
BUG=chrome-os-partner:56864
BRANCH=none
TEST=update reef. Wait until Cr50 prints 'SETAD' then run 'rw
0x4000012c' and verify it is reset to 0.
Change-Id: If517202f25a694cd70550e3be047ea502e7c5383
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380354
If both e, and MOD are even, then no modular
inverse exists. This change adds handling
for this set of inputs. Adding this change
for completeness (there are no dcrypto library
call paths that generate both e and N as even).
BRANCH=none
BUG=chrome-os-partner:47524
TEST=bn_test passes
Change-Id: Ide64f980501175e9b6078efff92086d12bc1ae2d
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/376180
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If the firmware was just updated clear the reset counter before
rebooting. This will ensure that the update can complete even if the TPM
isn't being used.
BUG=chrome-os-partner:56864
BRANCH=none
TEST=Set the reset counter to 7 by running 'rw 0x40000128 1' and
'rw 0x4000012c 7'. Then make sure cr50 can still be updated
Change-Id: Ic304fc7a20a4f2af7792f80e970d28e0eb10967e
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380235
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The high speed clock does not run when cr50 is in sleep. The low speed
timers do run in sleep and deep sleep. This change modifies the hwtimer
to use the low speed timers instead of the high speed ones.
With this change the system timer frequency is reduced and will only
tick once every 4 mircoseconds. Now the system will resume from sleep
whenever an event is scheduled, but still wont resume from deep sleep.
BUG=chromium:635620
BRANCH=none
TEST=manual
Disable sleep
add a function that prints something every second.
Verify the rollover works at ~4295s.
Change the system time using force_time.
Re-enable sleep and reduce the sleep delays in
board/cr50/board.c and chip/g/idle.ci so cr50 will go to
sleep more quickly. Verify the rollover and changing system
time works.
check that cr50 can go into deep sleep and that the print
statement wont wake it up.
Put the system into deep sleep. Use a wake pin to make it
resume. Verify it can be put back into deep sleep without the
wakepin interrupt constantly triggering.
Change-Id: I70bbc9312cd172661de53334d256949ebab6b5e9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376800
UART0 RX only needs to be disabled on reef. This change uses a system
property instead of a #define to disable UART0 RX that way it can just
be done on Reef not Gru or the dev board.
BUG=chrome-os-partner:55510
BRANCH=none
TEST=manual
rw 0x4060000c shows a value of 1 for reef and 3 for gru
gru kevin and reef still boot.
Connect DIOA13 to DIOA1 on the dev board and verify the console
can be used.
Change-Id: I5ee3559c2b35f959c0d67f233d1dfa40743b4064
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/378336
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
There is leakage on SYS_RST_ODL from the internal pullup cr50 has on
DIOM0. This change removes the internal pullup.
Without the internal pull up SYS_RST_ODL is asserted when the EC is off.
This change modifies how sys_rst_asserted is handled so cr50 will ignore
the sys_rst interrupt whenever rbox asserts EC_RST to make sure cr50
doesn't reset itself every time it resets the EC. If the EC resets
itself and sys_rst_l is no longer pulled up, it is fine if cr50 resets.
BUG=chrome-os-partner:53544
CQ-DEPEND=CL:377504
BRANCH=none
TEST=manual
'rw 0x40550010 1' causes the EC to reset but not cr50
On the development board verify DIOM0 is not pulled up.
Test cr50 boots normally on reef, gru and kevin dvt1
Change-Id: Id8e8f6f7bb91741da34bdd6fec89eb841dd94f35
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376886
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In order to disable the restricted console lock, the user has to
poke the power button repeatedly for some time. This CL
implements the logic to tell when this is happening, and whether
it is successful or not.
With this CL, unlocking only takes 10 seconds. This period will
be extended for production use. Right now we're just testing.
BUG=chrome-os-partner:55322
BUG=chrome-os-partner:55510
BRANCH=none
TEST=make buildall; test on cr50 hardware
At the console, run the "lock" command to see if it's already
disabled. If it is, run "lock enable" to lock it.
To unlock it, run "lock disable". A countdown will appear, after
which you will need to poke the Power button every 2 seconds for
10 seconds. If you do so, the console will be unlocked.
Change-Id: Ib5a94172080e627f3268d50d2587ec58bf8d9473
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/377621
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Even when CONFIG_RESTRICTED_CONSOLE_COMMANDS is enabled, there
are many commands that can't do anything dangerous. This marks
some of those commands as safe to use, even when restrictions are
enforced.
I'm only marking commands that are used by the Cr50, since that's
the only board that has restrictions.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall, test on Cr50 hardware
Change-Id: I6289d332830175b6adcb6b20cb4c21d01d27a25e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376188
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Version 4 of the update protocol provides the host with version
numbers of currently running RO and RW.
Another enhancement is that flash erase is postponed til the moment
the first chunk of data for the section arrives. This allows to quiry
running firmware versions in a non-destructive fashion.
BRANCH=none
BUG=chrome-os-partner:49954
TEST=ran usb_update on a Reef with an old cr50 image on it. Observed
it complete once with exit code of 2 (RO could not be updated),
ran it again, observed it succeed, and verified that both RO and
RW on the Reef got updated.
Change-Id: I27841c464cd0a414fa8959b686b59d8f07765387
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374760
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Trying to use usb_updater in the upstart script made its shortcomings
very obvious: it is difficult to tell if the cr50 needs to have both
RO and RW updated, and if so - if it is even capable of updating RW.
Also, it is not clear that the target should erase its backup sections
as soon as it receives the transfer originating PDU. It is not known
in advance if the host has a newer RW section, of if the host is even
going to transfer the RO section.
These issues are addressed by version 4 of the image transfer
protocol.
The target now reports versions of its currently active RO and RW
sections back to the host. The host compares versions running on the
target with the versions retrieved from the image prepared for the
update and decides which sections, if any, need to be transferred.
The host also takes into account protocol version currently running by
the target's RW: versions below 3 do not allow RO updates.
In the development environment USB transfer ends with the target
reset. This is not desirable when the update is happening on a
Chromebook running production code. Also, in the development
environment there could exist multiple versions of the image with the
same signer header version fields, with only difference in the
timestamp. We want to be able to update using these images in
development environment, but in production we want to rely to the
header version fields.
These two mode (dev versus production) are now controlled by the
-u/--upstart command line flag.
The updater now can return four different exit values:
- 0 means that the update was not required, the device is already
running the current code.
- 1 means update was completed, the target must be reset for the
update to kick in.
- 2 means that the RW transfer was completed, but the RO transfer
could bot be attempted, because the target is running an early
protocol version and is not capable of the RO updates.
This exit value is the indicator that the utility needs to be run
again after target restated, so that the new RW version can accept
an RO update.
- 3 means the update failed due to some internal error.
BRANCH=none
BUG=chrome-os-partner:49954
TEST=updates of targets running earlier protocol version still work
fine.
Change-Id: Ia56f63072eaf88dcdefebf621b7341535748c7d7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374759
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Cr50 needs to connect to the AP phy when not in ccd so cr50 can be
updated and used as a gnubby. This change uses the strapping options
to detect when it is on reef and modifies the ccd behavior to
initialize usb on the AP phy when ccd is disabled. On gru the cr50
behavior is unchanged.
In RDD this change removes the checks that the current_map is the
correct one based on the detected debug state. rdd_init calls
rdd_interrupt to set up the usb and ccd state correctly. Having that
check prevents that initial rdd_interrupt from calling rdd_detached.
Before rdd_detached just disabled usb and we knew during init it
would already be disabled. Now we want to make sure it is called if a
debug accessory is not attached to initialize usb on the AP PHY.
BUG=chrome-os-partner:56098
BRANCH=none
TEST=manual
verify ccd still works on gru
disconnect suzyq and reset reef.
run lsusb on the AP and verify it shows cr50 as a device.
connect suzyq and check that the AP no longer sees cr50.
disconnect suzyq and verify the AP sees it again
Change-Id: I3c1ccc54895835bce12302f3ea43fc2e751b4c97
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/372920
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
* Added MACRO for specifying row size of flash device.
* Set chip/g specific values for flash row size.
The flash API for g/chip will segment large write operations into a
maximum of 32 word blocks for batch writes to flash memory. Prior to
the change in this commit, the segmentation will adhere to avoiding
crossing page boundaries (2048B) but will not respect row boundaries
(256B). The flash controller will reject any write op that crosses a
row boundary and set a row boundary violation code on its error
register.
BRANCH=none
BUG=b:30819377
TEST=make BOARD=haven_dev
Change-Id: I489122ec0f0db6374dd373a1385c3012bdface20
Reviewed-on: https://chromium-review.googlesource.com/371003
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Commit-Ready: Johnnie Chan <johnniec@google.com>
Tested-by: Johnnie Chan <johnniec@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Since pretty much always, we've declared console commands to take
a "longhelp" argument with detailed explanations of what the
command does. But since almost as long, we've never actually used
that argument for anything - we just silently throw it away in
the macro. There's only one command (usbchargemode) that even
thinks it defines that argument.
We're never going to use this, let's just get rid of it.
BUG=none
BRANCH=none
CQ-DEPEND=CL:*279060
CQ-DEPEND=CL:*279158
CQ-DEPEND=CL:*279037
TEST=make buildall; tested on Cr50 hardware
Everything builds. Since we never used this arg anyway, there had
better not be any difference in the result.
Change-Id: Id3f71a53d02e3dc625cfcc12aa71ecb50e35eb9f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374163
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There is leakage on SYS_RST_ODL from the internal pullup cr50 has on
DIOM0. This change removes the internal pullup.
Without the internal pull up SYS_RST_ODL is not pulled up whenever the
EC is off. I changed how sys_rst_asserted is handled so it will ignore
the sys_rst interrupt whenever rbox asserts EC_RST to make sure cr50
doesn't reset itself every time it resets the EC. If the EC resets
itself and sys_rst_l is no longer pulled up, it is fine if cr50 resets.
BUG=chrome-os-partner:53544
BRANCH=none
TEST=manual
'rw 0x40550010 1' causes the EC to reset but not cr50
On the development board verify DIOM0 is not pulled up.
Test cr50 boots normally on reef and gru
Change-Id: Ic1d4d160ddb0d69081cb1f194d50939dac6fc5c2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373838
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The parse_bool() function exists so we don't have to litter our
console commands with stuff like this:
if (!strncasecmp(argv[1], "on") ||
!strncasecmp(argv[1], "enable" ||
!strncasecmp(argv[1], "true" ||
[...]
This CL uses parse_bool instead of that kind of thing so I don't
have to remember which commands use "enable" and which use "on"
and so forth.
I only changed the commands that Cr50 uses.
BUG=none
BRANCH=none
TEST=make buildall; test on Cr50 hardware
I tested all the affected commands to ensure that they still work
correctly: usb, ccd, flashwp (which doesn't do anything anyway).
Change-Id: I7d875ab22934fb4b500e3d0f62ebe3e04101272d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373658
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch modifies CR50 code to switch to firmware update protocol
version 3. In this version both SPI and USB updates use exactly the
same messages (apart from the size field added by USB to help
reassembly of the fragmented frames).
Bot unused RO and RW sections can be now programmed.
BRANCH=none
BUG=chrome-os-partner:55789
TEST=on a Kevin running the existing cr50 image programmed the new
cr50 image, restarted the device, programmed the cr50 image again
(this time using version 3), restarted the device, then
programmed both RO and RW images and restarted the device. Each
time verified that the proper image is running.
Change-Id: I0cf196ec6de1786510433f8252164a33ccdc6dec
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/371941
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
I don't think that the received_data pointer in sps_rx_interrupt can
actually be used without initialization in the current code flow, but
GCC 5.3 thinks that it can, and throws an error.
sps_check_rx() always sets the pointer or returns 0. In either case
we should be ok, but initializing it to null here won't hurt anything
since it's not masking an actual error.
BUG=None
BRANCH=None
TEST=Build all boards successfully.
Change-Id: Idaea7efd1af3067c492a3ade4c89104e975f4c1d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/370663
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This feature is not enabled, is awkwardly written, and shouldn't
be left lying around to use as a bad example. This CL doesn't
change any compiled code.
A followup CL will add a working RBOX interrupt handler.
BUG=none
BRANCH=none
TEST=make buildall; test on Cr50 hardware
Change-Id: I5d0701f55ab9521bf1f29e7ec18994c4401d68fb
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373600
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
At one time we could switch between TPM and HC protocols on the
SPI slave bus. We disabled the HC protocol long ago with commit
e4690f6152. This CL removes the spstpm command, since there's
no longer any point to having a console command to disable the
TPM protocol too (which would leave us with nothing listening to
incoming traffic on the SPI bus).
BUG=none
BRANCH=none
TEST=make buildall; test on Cr50 hardware
Change-Id: Ic5028dfc1631fab4ddf2584635cb48be50d05d4d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373638
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This patch introduces support for the cr50 firmware update protocol
version 3. It is described in more details in the comment in the
patch, the bottom line is that both RO and RW updates are supported,
and SPI and USB modes use the same protocol now.
The notions of PDU (protocol data unit) passed between the host and
the programming function on the CR50 is introduced, and USB mode
framing is described.
BRANCH=none
BUG=chrome-os-partner:55789
TEST=verified that version 1 and 2 updates still work. Version 3 mode
was tested later, when the device side patches were applied.
Change-Id: If51854b6a0b140730e85853bc42039233550fe8c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/371509
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In preparation of introducing new update protocol version this patch
cleans up the existing implementation.
The receive and transmit PDU headers are separated into their own
structures and are now shared between the server and client sides.
Some comments have been added to better explain different protocol
versions' details.
BRANCH=none
BUG=chrome-os-partner:55789
TEST=verified that it is still possible to update RW_A and RW_B on a
Kevin CR50, works using both USB and SPI.
Change-Id: Ied65b2c2a7800bae045f1d2dd64e58dd5e793d27
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368989
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Header version fields are instrumental when determining which of the
available images is started by the RO. Let's include the header
version when reporting the RW images' version as well as RO.
BRANCH=none
BUG=none
TEST=verified that RW header information is now included in the
version command output:
> vers
Chip: g cr50 B2
Board: 0
RO_A: * 0.0.8/8755904e
RO_B: -1.-1.-1/ffffffff
RW_A: 0.0.1/cr50_v1.1.5093-751a584+
RW_B: * 0.0.1/cr50_v1.1.5093-d27f65f
Build: 0.0.1/cr50_v1.1.5093-d27f65f
...
Change-Id: I675c473a277e272f55670324fafdab8a6e6edd78
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/370939
Reviewed-by: Scott Collyer <scollyer@chromium.org>
