The variable rv was being returned without being initialized. Instead,
return EC_SUCCESS.
BUG=None
BRANCH=None
TEST=Build all boards successfully.
Change-Id: If37057b737e6419c1d5cc22215a7d76d920d1267
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/370664
Allow the host to self-report its sleep state through
EC_CMD_HOST_SLEEP_EVENT, which will typically be sent with SUSPEND
param when the host begins its sleep process. While the host has
self-reported that it is in SUSPEND, don't assert the interrupt
line, except for designated wake events.
BUG=chrome-os-partner:56156
BRANCH=None
TEST=On kevin, run 'ectool hostsleepstate suspend', verify that
interrupt assertion is skipped for battery host event. Run 'ectool
hostsleepstate resume' and verify interrupt is again asserted by the
battery host event.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I74288465587ccf7185cec717f7c1810602361b8c
Reviewed-on: https://chromium-review.googlesource.com/368391
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The nvmem_write() and nvmem_move() funcitons return an error
if the write or move operation would exceed the user buffer
boundary. However, the TPM2 functions which call these functions
do not check for errors. Instead TPM2 NvMem relies on the return
value of the nv_commit() function to determine if a TPM command
which modifies NvMem succeeds or fails.
This CL adds a nvmem_write_error flag which is set in cases where
an nvmem_write/nvmem_move returns an error. This error flag
is then checked in nvmem_commit() so that the commit operation can
be abandonded and the error returned back up the TPM2 stack.
Tested in full system for two cases.
Installed TPM certificates on the Cr50, then manually erased NvMem with
flasherase 0x7b000 0x5000 and rebooted system. Then on Kevin console
entered the command <trunks_client --own>
NV_MEMORY_SIZE = 9932
NVMEM_TPM_SIZE = 7168
Case 1 -> Without internal write error state, so commit() always
executes if called. In this case, the Kevin console reports
a TRUNKS_RC_WRITE_ERROR and there is a Cr50 reboot.
Kevin Console:
localhost ~ # trunks_client --own
[INFO:tpm_utility_impl.cc(1692)] CreateStorageRootKeys: Created RSA SRK.
[INFO:tpm_utility_impl.cc(1735)] CreateStorageRootKeys: Created ECC SRK.
[ 134.056217] tpm tpm0: Operation Timed out
[ERROR:tpm_utility_impl.cc(1987)] DoesPersistentKeyExist:
querying handles: TRUNKS_RC_WRITE_ERROR
[ERROR:tpm_utility_impl.cc(269)] TakeOwnership: Error creating salting
key: TRUNKS_RC_WRITE_ERROR
[ERROR:trunks_client.cc(98)] Error taking ownership: TRUNKS_RC_WRITE_ERROR
Cr50 Console:
> [131.501920 nv_commit()]
[142.494755 nv_wr: max off = 0x1250]
[142.496347 nv_wr: max off = 0x17b4]
[142.548296 nv_commit()]
[142.678001 nv_rd: max off = 0x1250]
[142.679350 nv_rd: max off = 0x1254]
[143.269614 Nv Wr: overflow stop: reqst = 0x1d1c, avail = 0x1c00]
[143.271460 Nv Wr: overflow stop: reqst = 0x1d20, avail = 0x1c00]
[143.273055 Wr Err = TRUE, Resetting error only, not returning]
[143.325073 nv_commit()]
--- UART initialized after reboot ---
[Reset cause: rtc-alarm]
[Image: RW_B, cr50_v1.1.5056-8e5dc99+ private-cr51:v0.0.69- 12:23:02]
[0.004349 Inits done]
[0.007150 Active NVram partition set to 0]
[0.008086 Debug Accessory connected]
[0.009076 USB PHY B]
Console is enabled; type HELP for help.
tpm_manufactured: manufactured
[1.155766 usb_reset]
[1.240155 usb_reset]
[1.311188 SETAD 0x6c (108)]
Case 2 -> Using internal error state to gate the commit() operation.
In this case, the attempted write overflow sets the internal error
state and the commit() following attempted overflow detection is not
exectued. It results in a different AP TPM error shown below as
Error encrypting salt. The other different behavior is that observed
is that if after failing on the RSA SRK, the ECC SRK write is still
attempted.
Kevin Console:
localhost ~ # trunks_client --own
[INFO:tpm_utility_impl.cc(1692)] CreateStorageRootKeys: Created RSA SRK.
[INFO:tpm_utility_impl.cc(1735)] CreateStorageRootKeys: Created ECC SRK.
[ERROR:session_manager_impl.cc(154)] Error fetching salting key public
info: Handle 1: TPM_RC_HANDLE
[ERROR:session_manager_impl.cc(94)] Error encrypting salt: Handle 1:
TPM_RC_HANDLE
[ERROR:tpm_utility_impl.cc(277)] TakeOwnership: Error initializing
AuthorizationSession: Handle 1: TPM_RC_HANDLE
[ERROR:trunks_client.cc(98)] Error taking ownership: Handle 1:
TPM_RC_HANDLE
Cr50 Console:
> [107.867473 nv_commit()]
[133.743522 nv_wr: max off = 0x123f]
[133.744908 nv_wr: max off = 0x1250]
[133.746159 nv_wr: max off = 0x17b4]
[133.798498 nv_commit()]
[133.900131 nv_rd: max off = 0x1250]
[133.901496 nv_rd: max off = 0x1254]
[134.507033 Nv Wr: overflow stop: reqst = 0x1d1c, avail = 0x1c00]
[134.508852 Nv Wr: overflow stop: reqst = 0x1d20, avail = 0x1c00]
[134.510440 Wr Err = TRUE, Aborting Commit!]
[144.856751 Nv Wr: overflow stop: reqst = 0x1d1c, avail = 0x1c00]
[144.858611 Nv Wr: overflow stop: reqst = 0x1d20, avail = 0x1c00]
[144.860198 Wr Err = TRUE, Aborting Commit!]
BRANCH=none
BUG=chrome-os-partner:55910
TEST=manual Test in system as described above and
ran NVMEM unit tests and verified that when a write would overrun the
user buffer, the write fails and sets the error state. Then,
verified that the nv_commit() call returns an error and clears
the internal error state.
Change-Id: I376e17b273003ff3d75459b4e68ed69d42dc7415
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366757
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Moved link layer-specific constants into link layer .h file.
Renamed data channel function to better represent its function.
TEST=make BOARD=hadoken
BUG=None
BRANCH=None
Change-Id: I239d535cf3725bf003443fc211fc802bc8aee13f
Signed-off-by: Levi Oliver <levio@google.com>
Reviewed-on: https://chromium-review.googlesource.com/367805
Commit-Ready: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Re-wrote ble_radio_init to work with both data and
advertising packets. Updated all calls to refactored function.
RADIO_PCNF0_ADV renamed because it applies to advertisement and
data packet formats. Updated all references to this value.
TEST=make BOARD=hadoken
BUG=None
BRANCH=None
Change-Id: I0fdbe0eb146ce5cbc40e3ac67bf4d0e5465dcc2f
Signed-off-by: Levi Oliver <levio@google.com>
Reviewed-on: https://chromium-review.googlesource.com/367732
Commit-Ready: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Myles Watson <mylesgw@chromium.org>
Remove repeated deadline resets. Deadline reset now in the STANDBY state.
Set radio frequency to match selected channel.
TEST=ble_hci_adv 0
BUG=None
BRANCH=None
Change-Id: Ic7ff0dba862c0216301d138413a89e4ef4a812fe
Signed-off-by: Levi Oliver <levio@google.com>
Reviewed-on: https://chromium-review.googlesource.com/367094
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Sometimes a perfectly sane image enters rolling reboot mode in case
some data change triggered a bug which prevents the normal startup and
causes a reset.
The most likely task causing in in case of cr50 would be the tpm task.
Let's add another check of the restart counter: should it reach the
value of 50, do not start the TPM task.
BRANCH=none
BUG=chrome-os-partner:55708
TEST=with this code plus an unaligned access introduced in tpm
initialization sequence in both RW_A and RW_B, program the full
image on the dev board.
Observe the device reset 50 time is rapid succession and then
stop with the following message on the console:
Bldr |511709
retry|50
Himg =4F992103..408D193E
Hfss =384E4655..EE13EBD0
Hinf =44D21600..B70529BD
jump @00044000
--- UART initialized after reboot ---
[Reset cause: rtc-alarm]
[Image: RW, cr50_v1.1.5044-8d6f7a2+ private-cr51:v0.0.68-633229c ...
+ cryptoc:v0.0.4-5319e83 2016-08-07 19:37:16 vbendeb@kvasha]
[0.004130 Inits done]
[0.006919 Active NVram partition set to 0]
Console is enabled; type HELP for help.
> system_rolling_reboot_suspected: roling reboots suspected. Try \
powercycling to clear
this condition.
[0.010502 Task 2 (TPM) exited!]
Change-Id: I6b08c5c1a02da9edf9bdf394e57cc56d2e595ad1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366892
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The nvmem space defined in the ec code base for the cr50 board is used
by the TPM2 library, which has its own nvram size definition. The two
definitions must match.
On top of the fact that the definitions are not locked to each other,
there is a third completely unrelated nvram size definition in
board/cr50/board.c.
This patch unifies nvmem size definitions between cr50 and tpm2
repositories by adding a compile time check for the size to be the
same on both sides.
Also, it turns out that two certificates (RSA and ECC) together do not
quite fit into the cr50 TPM nvram. Hence the total allocated nvmem
space is being increased to 20K (note that the actual nvram size
available to the TPM is less than half of this).
BRANCH=none
BUG=chrome-os-partner:55898
TEST=tpm does not lock up any more when 'tpm_client --own' is ran on the
Kevin-tpm2 command line
CQ-DEPEND=CL:367010
Change-Id: I20b4f54118bd2fa12e5bd5741d6c58fbe91f65d1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366796
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Add a case statement to handle HCI commands.
Add a test commands.
Try to match the hcitool syntax, so the same commands
can be executed on a Linux host.
Added lcmd (long cmd) to pass more parameters in fewer arguments
BUG=None
BRANCH=None
TEST=Use HCI commands to configure an advertiser and listen for
it using `hcitool lescan` on the host.
Change-Id: Ie28038847c9549eb1c27a605aa0fbad5efd3b2c7
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362145
Commit-Ready: Dan Shi <dshi@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There are few reasons why the SoC may reboot which we haven't
been reporting (they just show up as "[Reset cause: other]").
This adds a bit of decoding to explain some of those "other"
reasons.
BUG=none
BRANCH=none
TEST=make buildall; try on Cr50
I tested one of the new reasons using "crash hang". It shows up
correctly as "{Reset cause: security]". I haven't specifically
tested all of the new reasons, but since this is basically just a
change to console message they should work too. I'll double-check
those cases once some blocking bugs are fixed.
Change-Id: I46daed29d7e37bda9034a3486127bed0ea25f803
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366400
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The crash command is used to intentionally invoke various failure
modes in a running system. This adds one more (and cleans up the
command slightly). The "crash hang" command does the same thing
as "crash watchdog", except that it disables interrupts first.
Some SoCs may require special handling to recover from that case.
BUG=none
BRANCH=none
TEST=make buildall; run on Cr50 hardware
Invoked all the options to the crash command, observed that the
appropriate response occurred in each case (a stack trace if
possible, followed by a reboot).
Change-Id: I18897cfc04726e6aeda59f4c6e742d7a0037cf80
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366127
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
This removes write-protect ranges that are unnecessary so
that we save a bit of space.
BUG=chromium:633431
BRANCH=none
TEST=compiled only.
Change-Id: Ib34c6a125b001fc92a21f795ac3d922e77143342
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365210
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The chip revision and board version show up on the second line of
the returned string, immediately before the build info.
BRANCH=none
BUG=chrome-os-partner:55558
TEST=Queried version string using tpm_test
make -C test/tpm_test && sudo ./test/tpm_test/tpmtest.py
Starting MPSSE at 800 kHz
Connected to device vid:did:rid of 1ae0:0028:00
RO_A:* 0.0.2/d0c9abe3 RO_B: 0.0.2/13eda43f RW_A: cr50_ [...]
B2:0 cr50_v1.1.5013-ab0e228+ [...]
^^^^
Change-Id: Iaa1efe5dca441aca24f281f76c1f218e24c844be
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365421
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
Image sizes must be aligned to block erase size to ensure that the host
can erase the entire image and nothing but the image.
BUG=chrome-os-partner:55828
BRANCH=None
TEST=Manual on kevin, rebuild FW with new EC, rebuild + flash EC once
again, verify that SW sync completes and unit boots to OS.
Change-Id: If6110f39869d6421038a3fe7afdc7d918323249e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365142
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Both build string (which includes status of all firmware components of
the running image) and the firmware version string (which show
versions of various objects in the flash) are important to the user.
Let's include both of these strings into the TPM_FW_VER register
output. Buffer storing the string needs to be increased accordingly.
BRANCH=none
BUG=chrome-os-partner:55558
TEST=verified the contents of the AP firmware console log:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: RO_A: 0.0.1/84e2dde7 RO_B:* 0.0.2/13eda43f RW_A: ...
cr50_v1.1.5003-af11829+ private-cr51:v0.0.66-bd9a0fe tpm2:v0.0.259-8f3d735...
Change-Id: I67df3e810bd07053d0b7d8b6fac350253ca06bb0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364830
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
As the version string grows longer, reading it in 4 byte chunks
becomes more and more expensive, the overhead of setting up a separate
SPI transaction per very chunk is just too much.
There is no reason not to allow the host to read as many bytes at a
time as it requires (limiting it by the maximum version string buffer
size of course).
BRANCH=none
BUG=chrome-os-partner:55558
TEST=verified that the version string is still read properly by the
TPM driver on Kevin
Change-Id: Ib76cd151e8dc32374f87135af36266b4ec725a56
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364831
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The only place where two separate buffers for the RO version strings
is required is the tpm_registers.c:set_version_string() function.
In preparation of reporting the build string along with the version
string, let's rearrange the function not to require separate buffers
for the RO versions.
BRANCH=none
BUG=chrome-os-partner:55558
TEST=verified that version reported by the TPM driver on Kevin is
still correct:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: RO_A: 0.0.1/84e2dde7 RO_B:* 0.0.2/13eda43f RW_A:*...
Change-Id: I8924ac48bd838851670f0d659e95aa92a8524665
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364587
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Some boards now provide very long build version strings including
version strings of multiple subcomponents.
Let the version command split those long lines printing each
subcomponent's version string in a separate line.
BRANCH=none
BUG=chrome-os-partner:55373
TEST=verified on cr50:
> vers
Chip: g cr50 B2
Board: 0
RO_A: 0.0.1/84e2dde7
RO_B: * 0.0.2/13eda43f
RW_A: * cr50_v1.1.4980-2b9f3e1
RW_B: cr50_v1.1.4979-8cec36d+
Build: cr50_v1.1.4980-2b9f3e1
private-cr51:v0.0.66-bd9a0fe
tpm2:v0.0.259-2b12863
cryptoc:v0.0.4-5319e83
2016-07-28 20:40:55 vbendeb@kvasha
Change-Id: Ie14af3aa9febd5a3b02b273a7ab6302e74777e43
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364491
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>
'+' flag can be used with signed integer type (%d) and causes positive
integers to be prefixed with '+' (e.g. +1745). This emphasizes output
values as a signed value. It can be mixed with left-justification flag
'-': %-+8d. It's ignored when used with unsigned integer or non-integer
types: %u, %x, %p, %s, %c, etc.
BUG=none
BRANCH=none
TEST=make buildall &&
int32_t d = 1745;
CPRINTS("'%-+8d'", -d); /* '-1745 ' */
CPRINTS("'%-+8d'", d); /* '+1745 ' */
CPRINTS("'%d'", d); /* '1745' */
CPRINTS("'%+08d'", -d); /* '000-1745' */
CPRINTS("'%+08d'", d); /* '000+1745' */
CPRINTS("'%+d'", -d); /* '-1745' */
CPRINTS("'%+d'", d); /* '+1745' */
CPRINTS("'%+s'", "foo"); /* 'foo' */
CPRINTS("'%-+8s'", "foo"); /* 'foo ' */
CPRINTS("'%+08x'", d); /* '000006d1' */
CPRINTS("'%+u'", d); /* '1745' */
Change-Id: I8dcd34b0cf03dbefc500b9c98fea235d85bde8d3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363924
When the case close debug (CCD) feature is provided by an external chip
(e.g security chip or TCPC), we still need to be able to detect debug
accessory with Rd/Rd (by setting Rp/Rp when VBUS is detected without
seeing Rp).
Add a CONFIG_CASE_CLOSED_DEBUG_EXTERNAL configuration parameter for this
case.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:55410
TEST=manual:on Kevin, enable CONFIG_CASE_CLOSED_DEBUG_EXTERNAL,
plug a SuzyQ (with Rd/Rd) and verify that the device in debug mode
when transitioning to S5.
Change-Id: Ie04a000a7b0eb670e3808f7bca1180298dfcd9db
Reviewed-on: https://chromium-review.googlesource.com/363400
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The SoC looks for two RO images at reset, and is typically
configured for two RW images as well. This CL reports version
strings for all those images, as well as identifying the active
RO and RW copies.
Since the RO image doesn't contain a version string, we create
one using the epoch_, major_, minor_, and img_chk_ members of its
signed header.
BUG=chrome-os-partner:55558
BRANCH=none
TEST=make buildall; run on Cr50 hardware
The "version" command now includes information like this:
RO_A: * 0.0.2/a3c3d5ea
RO_B: 0.0.2/8895c9eb
RW_A: cr50_v1.1.4965-a6c1c73-dirty
RW_B: * cr50_v1.1.4959-2f49d5c
The '*' indicates the active image.
The test/tpm_test/tpmtest.py program has been updated to request
the version information at startup, and it also now reports
similar information, just all on one line:
RO_A:* 0.0.2/a3c3d5ea RO_B: 0.0.2/8895c9eb RW_A: cr50_v1.1 ...
The active images are marked with a '*' following the ':', so
that the same regexp can match either format:
($ro, $rw) = m/RO_[AB]:\s*\*\s+(\S+).*RW_[AB]:\s*\*\s+(\S+)/s;
Change-Id: Ic27e295d9122045b2ec5a638933924b65ecc8e43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362861
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
For the purpose of spoofing dual-role capability, treat
soft-disconnected batteries as not present, since they are not capable
of supplying a current until they are revived.
BUG=chrome-os-partner:55617
BRANCH=None
TEST=Manual on kevin w/ subsequent CL. Put battery into soft-disconnect
state. Attach charger and verify EC doesn't lose power and battery again
supplies current.
Change-Id: Ie6b83b3d4e1e33c4bbbd1a90450506e7dcd1dfb2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363003
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BD99955 charger auto exits from the battery learn mode if the charge
is inhibited. Hence, do not inhibit the charger in battery learn mode.
BUG=chrome-os-partner:55491
BRANCH=none
TEST=Manually tested on Reef using 'ectool chargecontrol' command.
Able to enter/exit battery learn mode safely.
Change-Id: If05f9a9451842b77619e0a8c5db5e54fec24f399
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/362123
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This change implements logic for installing
endorsement certificates in the RW section.
The endorsement certificates are initially
provisioned in a fixed RO flash region and
are copied in the RW TPM data region (once
this region has been initialized).
Also add code for reading from the info bank,
which is where the endorsement seed is
initially stored.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115
TEST=TCG tests running
Change-Id: Id8c16d399202eee4ac0c4e397bdd29641ff9d2f3
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/362402
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Flush our UART buffer to ensure that we don't miss prints when we reboot
the EC.
BUG=chrome-os-partner:55539
BRANCH=None
TEST=Manual on kevin, issue cold reboot host command, verify that
"Executing host reboot command" is seen on console.
Change-Id: I96d5687b413ba4f603e3e7845b5cbba1c2d65efa
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362681
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The tpm firmware version register should report the current RW image's
version, not the RW_A.
BRANCH=none
BUG=chrome-os-partner:55145
TEST=verified that tpm firmware version reported by coreboot on the AP
console matches the version running on the device, for both RW_A
and RW_B.
From coreboot console log on two different runs:
Firmware version: RO: 84e2dde7 RW: cr50_v1.1.4943-f81a901
Firmware version: RO: 84e2dde7 RW_B: cr50_v1.1.4943-f81a901
Change-Id: I43f5432e44e38dbf9b42750dd2042a0f005bcbfb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362612
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
During initialization the NvMem module looks for either a valid
partition or that the NvMem area is fully erased. If neither of
these two conditions were found, then it was only returning an
error code and logging a message to the console.
This CL modifies nvmem_init() so that if the error case as described
above is detected, then it will call nvmem_setup() which will
create two valid partitions. In addition, the setup function
erases all of the existing data in the NvMem space.
Enhanced the unit test that deals with both partitions being
corrupted so that it verifies the version numbers are correct
and that all user buffer data is set to 0xff.
BUG=chrome-os-partner:55536
BRANCH=None
TEST=Manual
Executed make runtests TEST_LIST_HOST=nvmem and verifed that all
tests passed.
Change-Id: Ib932e02f15bd1aad7811032a12d826c76476e53f
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362448
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The clock() function was introduced to provide free running clock for
the TPM2 library, which expects this clock to run with a millisecond
resolution.
This patch fixes the bug where the function in fact was returning the
clock running at a microsecond resolution.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115
TEST=with the appropriate modification of the user of this function
all lockout related TCG tests pass.
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361180
(cherry picked from commit b4e78b309900402499b8742199fb4536570d3000)
(cherry picked from commit fefaa02a4f2c807a3ad50137bd7dba7f5f081c31)
Change-Id: Ic02fffca610426d22e58609eb8c3693aec96ad5c
Reviewed-on: https://chromium-review.googlesource.com/362118
The manufacturing status check verifies if the proper certificates are
found in the device NV RAM. This check can not succeed unless NV RAM
metadata is initialized by calling _TPM_Init().
If the check shows that the device has not been through manufacturing
sequence yet, TPM_Manufacture() needs to be invoked to make sure that
all relevant TPM structures are initialized and properly stored in NV
RAM. _TPM_Init() needs to be invoked again after that.
BRANCH=ToT
BUG=chrome-os-partner:43025
TEST=restarting Kevin device with pre-manufactured CR50 takes it
through factory initialization on every reboot. Restarting Kevin
once TPM is through manufacturing process shows that the
previously saved rollback counters are preserved.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361093
Reviewed-by: Nagendra Modadugu <ngm@google.com>
(cherry picked from commit 61a0fe734e808d1dbdf56fb6023e04adf66553b3)
(cherry picked from commit 3207a57fb2f5957b6e833d9ab1f9ea46021c5e1e)
Change-Id: I80b69f2c4b8d0e4cca154db510867df39c707ce2
Reviewed-on: https://chromium-review.googlesource.com/362084
This copies the generic USB update code into common
so it can be used on other platforms. There should be
no functional change. cr50 folks want no change to their
code so vbendeb@chomium.org will refactor this back
together at a later date.
BUG=chromium:571476
TEST=none
BRANCH=none
Change-Id: I710afb22940013e7db5d8694898b90c0ae245777
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362131
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In certain test scenarios the tpm task is hogging all resource and
causes watchdog resets. Let's kick the watchdog in every loop, Long
calculations already have watchdog kicking in place.
BRANCH=ToT
BUG=none
TEST=tests executed in rapid succession do not cause watchdog resets
any more.
(cherry picked from commit de8fb11bfd07d3fea2048b6848b8a183c31e2580)
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360229
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Change-Id: Ifaad6f9b4af2218f601412a36a075b4b4275d56f
Reviewed-on: https://chromium-review.googlesource.com/362170
MKBP can now support buttons, so this commit adds the
keyboard_update_button() function which will be used to handle the
non-matrixed buttons.
BUG=chrome-os-partner:54976
BUG=chromium:626863
BRANCH=None
TEST=Flash kevin, press volume and power buttons and verify that
keyboard is still functional.
TEST=make -j buildall
CQ-DEPEND=CL:358633
Change-Id: I1c2d36d2113715cf6bd8c6fa7b26fe9253f6ac9f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/358634
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Currently, the matrix keyboard protocol does not have support for
handling non-matrixed keys. This commit adds support for buttons which
do not appear in the keyboard matrix as well as switches.
Additionally, the keyboard FIFO is now just a general MKBP events FIFO
which MKBP events are free to use. Now, buttons and switches wil join
the key matrix event.
BUG=chrome-os-partner:54988
BUG=chrome-os-partner:54976
BUG=chromium:626863
BRANCH=None
TEST=Flash kevin, and verify that keyboard is still functional.
TEST=make -j buildall
CQ-DEPEND=CL:358926
Change-Id: If4ada904cbd5d77823a0710d4671484b198c9d91
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/358633
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Blink the LED in S3 as well as S0iX states so there is no user visible
difference in their behavior.
BUG=chrome-os-partner:55225
BRANCH=glados
TEST=Enter S0iX on cave and verify LED blinks.
Also verify that the LED still blinks in S3.
Change-Id: I883147b1c8e599de077c9f06e567a63d535a01f8
Signed-off-by: james_chao <james_chao@asus.com>
Reviewed-on: https://chromium-review.googlesource.com/359985
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
There's a new OTP change for the BD99955 and therefore the following
changes needed to be made.
- Change VFASTCHG_SET1 to 8.704V before CHG_EN is set to 1.
- Change VSYS_REG to 6.144V when starting Fast Charging.
- Change VSYS_REG back to 8.906V when Fast Charge is finished.
- Wait for 50ms to set CHG_EN to off (0) after Fast Charging has ended.
BUG=chrome-os-partner:55220
BUG=chrome-os-partner:55238
BRANCH=None
TEST=Flash kevin, plug discharged battery in. Plug AC in. `bd99955 r
0x11 1' and verify that VSYSREG is set to 0x1800 (6144mV).
TEST=`bd99955 r 0x1a 1' and verify that VFASTCHARGE is set to
0x2200 (8704mV).
TEST=Remove battery. `bd99955 r 0x11 1' and verify that VSYSREG is set
to 0x2300 (8960 mV).
TEST=Plug in battery and let charge to full. Verify that VSYSREG is set
to 0x2300 (8960 mV).
Change-Id: I5e5ca2cdcd4ead383416901c904df1e6fe5a9e28
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360421
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Added code to get the VBUS level by reading the charger registers.
BUG=chrome-os-partner:55117
BRANCH=none
TEST=Manually tested on Amenia, VBUS_VAL (5Ch) & VCC_VAL (5Eh)
registers are updated with the correct VBUS value on the
respective ports.
Change-Id: I3b019b2d87e4c347f12596df387a2a659092ae25
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/359416
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
When cr50 is not trying to do ccd, we dont need to monitor the devices.
Disable device state detection interrupts and the AP and EC UARTs.
BUG=none
BRANCH=none
TEST=gru and kevin monitor devices correctly when ccd is enabled, and
dont monitor anything when it is disabled.
Change-Id: Ic3f5974320486ff6dd0147c490a1c294cc2f6a76
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/356770
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
