If there was an error getting the capacity or page size, don't update
the values with an incorrect/unknown/uninitialized value.
BUG=None
BRANCH=None
TEST=Build all boards successfully.
Change-Id: I907f14f219f721ec9e9753a38e4bf998bbc16324
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/370665
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Ewout van Bekkum <ewout@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>
This adds support for CONFIG_RESTRICTED_CONSOLE_COMMANDS. If the
appropriate options are configured, restricted commands can be
prevented from running.
Nothing in this CL actually uses that, but it works if you turn
it on.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall, test on Cr50 hardware
I also tested it manually. If you add this to board.h:
#define CONFIG_CONSOLE_COMMAND_FLAGS
#define CONFIG_RESTRICTED_CONSOLE_COMMANDS
#define CONFIG_CONSOLE_COMMAND_FLAGS_DEFAULT CMD_FLAG_RESTRICTED
and this to board.c:
static int restricted_state;
int console_is_restricted(void)
{
return restricted_state;
}
static int command_lock(int argc, char **argv)
{
int enabled;
if (argc > 1) {
if (!parse_bool(argv[1], &enabled))
return EC_ERROR_PARAM1;
restricted_state = enabled;
}
ccprintf("The restricted console lock is %s\n",
restricted_state ? "enabled" : "disabled");
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND_FLAGS(lock, command_lock,
"[<BOOLEAN>]",
"Get/Set the restricted console lock",
0); /* no restrictions */
then you can use the "lock" command to enable and disable every
other console command except for it and "help".
Change-Id: Ic9517f9ea7a9867f15e5d14b302246070163d558
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376186
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If we add a .flags field to the console commands data structure,
we can use it to distinguish some commands from others, for
example to mark some commands as safe and others as dangerous.
This just adds the undefined CONFIG_ options. They aren't used
anywhere, so there's no behavioral difference yet.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall
Change-Id: I17fdf177dcb4324c77565bd95344da1405ea15ed
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376185
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If a TCPC fails to initialize then the PD task probably won't
function as expected when put in its default state and the console
will likely get spammed with errors. Fall back to the suspended
state instead.
BUG=none
BRANCH=none
TEST=booted on Reef EVT without TCPC1 connected, console is
no longer spammed with errors.
Change-Id: I94577c065e53bc6076c507b50c5bec22dbd8bdce
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376182
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The console command "sleepmask" refers to another, nonexistant
command, "dsleepmask". We shouldn't refer people to look for
things that don't exist.
BUG=none
BRANCH=none
TEST=make buildall
Before:
> help sleepmask
Usage: sleepmask [ on | off | <sleep_mask>]
Display/force sleep mask.
See also 'dsleepmask'.
>
After:
> help sleepmask
Usage: sleepmask [ on | off | <sleep_mask>]
Display/force sleep mask
>
Change-Id: Ia95b48fc1e27315895e431b88ab39179a08d34cf
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376078
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add API to switch the Rp pull-up value on CC dynamically at runtime.
This is a preparatory work for boards having a more complex maximum
source current policy (eg 2 ports sharing a common pool of power).
For fusb302, update the voltage thresholds for open/Rd/Ra as they depend
on the Rp (was missing from the previous change).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:56110
TEST=make buildall
Change-Id: Id3c24a31a16217075a398ec21ef58ee07187a882
Reviewed-on: https://chromium-review.googlesource.com/373501
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@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>
when TCPC takes a longer time to update its CC status upon
connection, a legacy C-to-A charger or certain Type-C charger
that presents 5V VBUS by default, TCPM could be mistaken the
charger as a debug accessory.
BUG=chrome-os-partner:55980
BRANCH=none
TEST=Manually tested on Reef. PD, Type-C, BC1.2, non-BC1.2,
DP, HDMI are working on both C-ports.
Change-Id: Ic3b0ecd3d14109239d8c0ff0064476595b7f93a0
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/367950
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Nothing has used this config option since Spring and Skate, back
in early 2014. There's nothing in ToT that uses it at all. I want
to add something similar for other purposes, and having two
similar-sounding options will just cause confusion.
NOTE: Although the comments in include/system.h said that the two
functions
system_get_console_force_enabled()
system_set_console_force_enabled()
were only useful when CONFIG_CONSOLE_RESTRICTED_INPUT is defined,
they were being used in chip/stm32/system.c. But since the
bkpdata registers are only accessible to the EC, there was no way
to initialize or modify the one relevant bit that those functions
cared about, so they almost certainly had no effect.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall
Change-Id: Id41541193d4559f5c507bdd0268b049166af4497
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374525
When the charger is detached, the host event would sometimes be
sent before the charge info was updated, resulting in the host
thinking that the charger was still connected.
BUG=chrome-os-partner:55584
BRANCH=none
TEST=Connected charger to kevin 15 times and verified that the
icon was removed in 2-seconds or less.
Change-Id: I1a4e4e0f7cc23010210570fc261da8308d8e8070
Reviewed-on: https://chromium-review.googlesource.com/367809
Commit-Ready: Wonjoon Lee <woojoo.lee@samsung.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Rotation by identity matrix from a to b fails if a != b.
BUG=none
BRANCH=none
TEST=Use identity matrix in test motion_lid.c, check test passes.
Change-Id: I852132ee8cd67063921077cd0b7d848d10a730e0
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373722
Reviewed-by: Aseda Aboagye <aaboagye@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>
Can now accept and maintain a single connection indefinitely by
sending empty packets at every connection interval to keep the
connection alive.
TEST=BTLE dongle sending connect requests and connecting to NRF51
running this code. Connection was established and ran for at least
48 hours until manual termination.
BUG=None
BRANCH=None
Change-Id: Iad4bd434ecd1edd6c5c8dfe8b72ca41fd82d0bb4
Signed-off-by: Levi Oliver <levio@google.com>
Reviewed-on: https://chromium-review.googlesource.com/370839
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@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>
Support Rp/Rp debug accessories in the USB PD state machine
including detecting the polarity and the available type-C current.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:52592
TEST=manual, plug a Suzy-Q reworked with Rp3A0/Rp1A5 resistors
on a Kevin, and see the PD state machine is going to
PD_STATE_SNK_ACCESSORY (and leaving it on unplug).
Re-verify a few existing accessories (Rd/Rd SuzyQ, legacy RpUSB cable,
Rp3A0 power supply).
Change-Id: Icef6c90027105d7c633f2785210ab9dae74fc33c
Reviewed-on: https://chromium-review.googlesource.com/368700
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The version string reported through TPM_FW_VER register has become way
too long, it takes too much time to transmit at startup, especially at
i2c speeds.
Let's limit it to the essentials: header versions and hashes of the
active RO and RW sections.
BRANCH=none
BUG=chrome-os-partner:49954
TEST=verified version in the firmware log
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: B2:0 RO_A:0.0.1/84e2dde7 RW_A:0.0.3/cr50_v1.1.5106-f7349c9+
Change-Id: Ic391f90673fe21c0100b776944f6efc080213ff3
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/372380
Reviewed-by: Scott Collyer <scollyer@chromium.org>
stm32f446 has two types of i2c blocks, the traditional
stm i2c, and "fast mode plus" i2c, which need different drivers.
This commit adds both, muxed in i2c-stm32f4, as the ec
codebase doesn't really support multiple types of the same interface.
BUG=chromium:608039
TEST=i2c works on all 4 channels
BRANCH=None
Change-Id: I6a9ac632f44142bd809ffee5782a192ae47af1f0
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368358
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Use EC_CMD_HOST_EVENT_GET_WAKE_MASK (already implemented on LPC
platforms) to share CONFIG_MKBP_WAKEUP_MASK with the host.
BUG=chrome-os-partner:56164
BRANCH=None
TEST=Run `ectool eventgetwakemask` on kevin, verify
CONFIG_MKBP_WAKEUP_MASK mask is printed.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I252c8d6297e3db97dd3df506b3a386a3ad777174
Reviewed-on: https://chromium-review.googlesource.com/372320
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Douglas Anderson <dianders@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>
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
