Previously, timeout meant the number of attempts taken to receive. Now,
it means the number of microseconds before timing out.
TEST=printouts displaying time before and after rx attempt. Not included
in CL.
BUG=None
BRANCH=None
Change-Id: I00ccfc4bbf15f77c2777f35c911dceacaff98e4f
Signed-off-by: Levi Oliver <levio@google.com>
Reviewed-on: https://chromium-review.googlesource.com/368471
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
When disabling auto_good_crc, the reg variable was being used
without initialization. Mirror the code for enabling auto_good_crc
to set the variable.
TEST=Booted reef with updated code.
BUG=None
BRANCH=None
Change-Id: Ie552f2ff74df05750bd65b6344d8a80cc285f8b0
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368221
Reviewed-by: David Hendricks <dhendrix@chromium.org>
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>
If you try to build the EC codebase with GNU make version 3.81 or
less, you currently get an error:
Makefile.rules:286: *** multiple target patterns. Stop.
Since this message isn't helpful in letting you know that the version
of make needs to be updated, let's print something more useful.
ERROR: GNU make version 3.82 or higher required. Stop.
TEST=Built with Make 3.81 and saw the new error message. Built with
make 3.82 and 4.0 and the EC built correctly.
BRANCH=None
BUG=None
Change-Id: I5813fd26fa8120742544567c5ae04af01f993f94
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/367944
Reviewed-by: David Hendricks <dhendrix@chromium.org>
It looks to static analyzers as if the variable val could be used
without being initialized. That isn't actually the case because of
all the checks that are being done, but the flow can be simplified
to only get the value to write when we're on the write path.
BRANCH=None
TEST=Build and boot Reef
BUG=None
Change-Id: I9f6ce3c9dcbab74f3c6de18dbd1f2e07bc1c4a13
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368302
Reviewed-by: David Hendricks <dhendrix@chromium.org>
In command_flash_spi_sel_lock(), and command_flash_tristate() a value
could be printed without being initialized first.
Only display the values in the paths where the variable gets read.
BUG=None
TEST=Build and boot Reef
BRANCH=None
Change-Id: I8ef86f966d017290491d6fe2b1486ce913cd09fb
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368301
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Modified board level drivers for eSPI POC on wheatley. By adding CONFIG_ESPI
definition, ec can support espi protocols for host interface on x86 based
platform such as skylake and so on. CONFIG_VW_SIGNALS will be used in the
future for saving GPIOs during power sequence.
Modified sources:
1. wheatley/board.h: Enable/disable espi driver.
2, wheatley/board.c: Add VW signals in power signal list.
3. wheatley/gpio.inc: Save GPIOs if CONFIG_VW_SIGNALS is defined.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make BOARD=wheatley; test nuvoton IC specific drivers
Change-Id: I0e8a951de6eacd4f8be65ffaac242f38079375d5
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/366520
Reviewed-by: Randall Spangler <rspangler@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>
Add espi driver for x86-based platform which support espi interface such
as skylake and so on.
Added source:
1. espi.c: Add drivers which supports the utilities of peripheral and
virtual-wire channels so far.
2. espi.h: Add espi virtual-wire declaration for power sequence FW.
Modified sources:
1. lpc.c: Add interrupts and initialization steps for espi.
2. gpio.c: Add interrupt handler of espi reset.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make buildall -j; test nuvoton IC specific drivers
Change-Id: Ie80afe79d85aba47fc0b72898a8374c2898ec114
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/366181
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If an HPD IRQ event is seen, make note of it and keep the status set
until informing the host.
BUG=chrome-os-partner:55925
BRANCH=None
TEST=Manual on kevin, trigger HPD event, verify that event bit is set in
reply to first host command and not subsequent host commands.
Change-Id: I0900a683dcb344d5d4d03a1fa6e3d8de913597b2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366990
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Chris Zhong <zyw@rock-chips.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
This fixes several errors caused by these being defined as static
while being used in the inline function i2c_handle_sda_irq().
From the C99 Draft 6.7.4.3:
An inline definition of a function with external linkage shall not
contain a definition of a modifiable object with static storage
duration, and shall not contain a reference to an identifier with
internal linkage.
TEST=Build with GCC 5.3 flash and boot Reef board
BUG=None
BRANCH=None
Change-Id: Ie487f17b92736c2a56280783267da5d3bb12b969
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/367486
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Certain tasks (eg. chipset) may be woken directly by other tasks /
unrelated interrupts. Add an explicit wake event for ADC conversion done
so that we're not mistakenly woken.
BUG=chrome-os-partner:54971
BRANCH=None
TEST=Manual on kevin rev5, run "reboot ap-off" then "sysjump rw", verify
console isn't spammed with GPIO warning message due to ADC failure to
read board version.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5477e11c2b434e4b350d81393f4463eea1a91e7c
Reviewed-on: https://chromium-review.googlesource.com/366943
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This is a test suite with certain expected failures.
If making any changes to cts code other than simply
adding a test suite, run this to make sure you
didn't break cts.
BRANCH=None
BUG=None
TEST=Manual
- Build with "./cts.py -b --debug -m meta"
- Flash with "./cts.py -f -m meta"
- View results at /tmp/cts_results/<board_name>/meta.html
- Results should match debug descriptions
Change-Id: Ia5c10c7ce0e0d852fe6b14e481798eaff2a82c9c
Reviewed-on: https://chromium-review.googlesource.com/364273
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
You can now add debug messages into a cts test and
they will be displayed with the test report html page.
The macro to use is CTS_DEBUG_PRINTF
Adding debug messages can potentially change test
results by slowing down the test, so you can choose
when compiling a test suite if you want the debug
messages present or not by adding --debug as an
argument when you call ./cts --build.
BRANCH=None
BUG=None
TEST=Manual
- Add a debug statement to a test
- Build the test suite with --debug specified
- Flash the boards
- Run './cts/cts.py -r'
- Open /tmp/cts_results/<board_name>/<test_suite>.html
to view see your debug message for the test
Change-Id: Icad8e0ac5cc905010caa4e7616f81572ce6ac771
Reviewed-on: https://chromium-review.googlesource.com/362475
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
Reviewed-by: Randall Spangler <rspangler@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>
There seems to be flaky issue where the nvmem tests don't fully
complete. I need to spend some time to try and understand the
mechanism. It doesn't happen on every build attempt and never
happens when I just run this particular test.
In the meantime, I don't want the builder to fail due to this
issue so I am removing this test from the test-list-host while
I debug the issue.
BUG=chrome-os-partner:55854
BRANCH=none
TEST=manual
Execute the command 'make runtests' in /platform/ec and verified that
the nvmem test is no longer executed.
Change-Id: I9f0778fd9fa17cf8949292f7abe8b05ccab2bae2
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/367302
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If test suite doesn't finish or results are received
out of order, this is likely an indication of reset
or hang by one of the boards and all tests after the
point of corruption are marked as corrupted.
BRANCH=None
BUG=None
TEST=Manual
- Edit the gpio th code to change ordering of tests
or hang or reset, etc.
- Build and flash tests
- Run './cts/cts.py -r'
- You should see the results for all of the tests,
with all corrupted tests marked as corrupted
Change-Id: I7925e37db285a4e90e6e09bf3b187400ddfe9edf
Reviewed-on: https://chromium-review.googlesource.com/362614
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
Reviewed-by: Randall Spangler <rspangler@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>
While SPI routing on servo is not great, this is still fine
and asn't as painfully slow.
BUG=chromium:571477
TEST=flash some firmware
BRANCH=None
Change-Id: I26d67ed6cd1ba62a892388e96a21acc708265fc4
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366670
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Servo_micro sets usb config maxpower to 100mA.
Servo_v4 is set to self powered as it's powered by a
shared vbus and not be the bub it's connected to.
cr50 is self powered as no power is transmitted as part of CCD.
* Add CONFIG_USB_MAXPOWER_MA to define USB maximum power draw requested
per board.
* Add CONFIG_USB_SELF_POWERED to indicate that a device is not
powered by allocated USB power.
BUG=chromium:631302
TEST=lsusb reports 100mA bMaxPower (micro), Self powered (v4)
BRANCH=None
Change-Id: I79b8ce46f32d94f16104a4a8080104e30dce7f2c
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363153
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When you run a test suite, cts will now save your
results for the suite/dut combo as a basic html page
BRANCH=None
BUG=None
TEST=Manual
- Connect dut, th
- Build/flash desired test suite
- Run './cts -r' to run tests
- Open /tmp/cts_results/<board_name>/<test_suite>.html
- You should see a table with test names/results
Change-Id: Id3de3bd7833be1bc5dde437c516db411aac47579
Reviewed-on: https://chromium-review.googlesource.com/362091
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added in classes for Board (parent), DeviceUnderTest,
and TestHarness. Reading, etc. should be easier now
BRANCH=None
BUG=None
TEST=Manual
- Build default
- Flash default
- Run
- Open /tmp/cts_results/nucleo-f072rb/gpio.html
- Should see a clean results page
Change-Id: Ide3f75281f0b5b8b40dabd36f8c239737dc527d6
Reviewed-on: https://chromium-review.googlesource.com/364236
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This change disables sleep only when a cable is actually detected.
Before it would disable sleep no matter what and if a debug cable was
not plugged in and then deteached then it would never enable it.
BUG=none
BRANCH=none
TEST=manual
update cr50
unplug suzyq
boot to kernel
verify cr50 is asleep
run 'powerd_dbus_suspend'
cr50 will wake up for like a second then go back to sleep
run 'apreset' on EC console
boot to kernel
verify cr50 is asleep
run 'powerd_dbus_suspend'
cr50 will wake up for like a second then go back to sleep
Change-Id: I8337f694853b7840ef932b38bd0fa6453d31cb3d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366861
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>
I keep thinking this refers to "Embedded Controller" instead of
"Elliptic Curve Cryptography". Make it clearer.
There's no functional change, I'm just renaming a constant.
BUG=none
BRANCH=none
TEST=make buildall; run tests on Cr50 dev board
make -C test/tpm_test && sudo ./test/tpm_test/tpmtest.py
Change-Id: Iaf2e2839e88fdbbcb1a712934be56a0dd47e4a70
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366752
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Our UART interrupt must be able to preempt our SHI_CS interrupt,
otherwise console input may be lost. Adjust our relative IRQ priorities
to accommodate this.
BUG=chrome-os-partner:55920
BRANCH=None
TEST=Run `echo "kbpress 11 4 1" > /dev/pts/17` on kevin 200 times from
the recovery screen, verify that all input is received by the EC.
Change-Id: I36203511f5883272287ac22d0704098fbd933758
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366622
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Add __keep attribute to irqprio entries to ensure they are not dropped
when CONFIG_LTO is enabled.
BUG=chrome-os-partner:55920
BRANCH=None
TEST=Manual on kevin. Check build/RO/ec.RO.map, verify that
.rodata.irqprio section is not empty.
Change-Id: I51ae23556d6f46b2cd7ba098f0e7a785292b2853
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366571
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
KSI2 get stuck when Refresh+Pwrbtn is used to reset EC,
so it was not able to detect the Esc key if it is also
pressed to enter recovery mode.
BUG=chrome-os-partner:55548
BRANCH=none
TEST=Reef EVT is able to enter recovery mode with Esc+Refresh+Pwrbtn
Change-Id: I0539e8fad9980cb563de94417079fe763c311887
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/366411
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously, the strapping configuration pins were only being
read following a POR reset event. In all other cases, the
strapping configuration was presumed to be stored in a long
life register. An issue with this method is that when Cr50
FW is upgraded (via Suzyq), there is no POR reset event until
either the battery becomes fully discharged, or the battery
is manually disconnected. Without a POR, following a FW upgrade,
the long life register will contain 0 and so neither the SPI
interface (on Kevin/Gru) or I2C interface (on Reef) will be
properly initialized.
Come to think of it, the contents of the scratch register should never
be zero unless this is a power on event, or a restart after migration
from the version not setting the scratch register.
Let's read the scratch register always if its contents are zero.
BRANCH=none
BUG=chrome-os-partner:50728
TEST=manual
Via the Cr50 console, cleared the long life register with
temp console command. Then executed a FW upgrade with Suzyq
and verified that the strapping pins are read and the correct
value is stored in the long life register. Note that 'reboot'
commands from either the Cr50 or EC console do not cause
a hard reboot.
Change-Id: I1b3aa92552b14bde9bda848aa3dc4c8221ce73a9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366390
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The input should be active low, not active high.
BUG=chrome-os-partner:49959
BRANCH=none
TEST=manual
Remove and reattach the battery. "gpioget BATT_PRES_L" shows the
GPIO value changing appropriately.
Change-Id: I7d513471f6ab5e7e8cd0e601148915697fa9162a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366134
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
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 change fixes two issues. The first issue is that during rdd_init
debug_detect is set to the value of DEBUG_STATE_MAP. Debug_detect should
be the default map value of 0x420 which triggers an rdd interrupt when
cc1 and cc2 both have a value of 011 or 001. This will detect when a
debug cable is attached. ~debug_detect should detect when the cable is
detached.
The issue is after a soft reset DEBUG_STATE_MAP is not reset to the
default value so on the next rdd_init debug_detect was set to whatever
was DEBUG_STATE_MAP was last set to. If the debug cable is detected
before the soft reset then DEBUG_STATE_MAP will have a value of
~debug_detect and when rdd_init is called then debug_detect will be
initialized to that value of ~0x420. Now debug_detect does the opposite
of what we expect it to do. debug_detect detects when the cable is
detached and ~debug_detect detects when it is attached.
rdd_interrupt is called cr50 reads cc1 and cc2 and sees that a debug
accessory is attached so it sets DEBUG_STATE_MAP to ~debug_detect.
Because debug_detect does the opposite of what is expected then it will
trigger an interrupt when it detects a debug accessory. The debug
accessory is already attached so an interrupt is triggered. It reads cc1
and cc2 sees the debug_accessory attached resets the map to
~debug_detect. This cycle continues until the watchdog resets the
system. After this reset rdd_init reads the map to get debug_detect and
it is 0x420 because that is how it was last set and then rdd works
again.
This change fixes this issue by defining DEBUG_DETECT to be 0x420 and
not using the STATE_MAP value to do it.
It also looks like when the EC is off and we change the value of the
debug map, another RDD interrupt is triggered. Then it reads the debug
state and resets the map again another interrupt is triggered. It
continuously does this.
This change adds a check to see that the RDD was trying to detect the
state it currently senses before doing anything so the second interrupt
will be ignored.
BUG=chrome-os-partner:55793
BRANCH=none
TEST=manual
plug in a reworked suzyq
Flash the EC
verify a bunch of RDD interrupts aren't triggered and the
reworked suzyq can be used.
plug it in and out a couple of times to make sure everything
works.
Change-Id: I6f4e7b15cf9c53b965533df7fe23fae5b340f70d
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364724
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This reverts commit 25f19f5bbd, which was
causing host command issues after sysjump. IBUFSTAT seems to behave
strangely. Additional investigation is required.
BUG=chrome-os-partner:55710,chrome-os-partner:55795
BRANCH=None
TEST=Verify host commands continue to work after sysjump.
Change-Id: Id94a9c4677bcae597b9353e081418e649e823564
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366173
Reviewed-by: Randall Spangler <rspangler@chromium.org>
