Pass in recovery button press/release information to AP using MKBP
button driver.
BUG=b:63893483
BRANCH=None
TEST=Behavior verified by Shelley.
Change-Id: I7a6e50ec8595d99327b5fc8e822bf762e0ce13e0
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/580539
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This adds the CCD configuration module, and the console commands to
control it. It is not wired up to any of the CCD capabilities; that's
coming in the next CL.
Briefly:
* CCD configuration is persistently stored in nvmem_vars. Use ccdinfo to
print it.
* CCD can be Locked, Unlocked (some capabilities), or Opened
(all capabilities), using the ccdlock / ccdunlock / ccdopen commands.
* CCD config can be restricted by setting a password via ccdpass.
* Individual config capabilities can be set via ccdset. Some of those will
be used to gate access to things like write protect and UARTs. Others
affect the requirements for ccdunlock / ccdopen (for example, is physical
presenc required).
* The entire config can be reset via ccdreset. If only unlocked, config
that is restricted to Opened is not reset.
* If CR50_DEV=1, ccdoops will force-reset and open the config.
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=none
TEST=manual with CR50_DEV=1 build
gpioget # make sure GPIO_BATT_PRES_L=0
ccdlock # lock, because CR50_DEV=1 builds start unlocked
ccdinfo # locked, flags=0, all capabilities default
ccdpass # access denied (we're locked)
ccdreset # access denied
ccdset flashap always # access denied
ccdunlock
ccdinfo # unlocked
ccdpass foo
ccdinfo # flags=2 (password set when unlocked)
ccdset flashap always # access denied
ccdset uartectx unlesslocked
ccdinfo # yes, uartectx permission changed
ccdlock
ccdunlock # fails without password
ccdunlock bar # wrong password
ccdunlock foo # busy
(wait 3 sec)
ccdunlock foo
ccdreset
ccdinfo # no password, flags 0, capabilities all default
ccdopen # requires physical presence; tap power or use 'pp'
ccdset uartectx unlesslocked
ccdset batterybypasspp ifopened
ccdpass baz
ccdinfo # password set, flag 0, ccdset changes worked
ccdunlock
ccdreset
ccdinfo # uartectx back to ifopened, password still set
ccdopen baz # still requires physical presence
ccdset opennolongpp always
ccdlock
ccdopen baz # no pp required
ccdset unlocknoshortpp unlesslocked
ccdlock
ccdopen baz # short pp sequence required (3 taps)
ccdlock
ccdunlock baz # short pp sequence required
ccdopen baz # pp not required
ccdset unlocknoshortpp always
ccdlock
testlab open # access denied
testlab enable # access denied
ccdunlock baz
testlab open # access denied
testlab enable # access denied
ccdopen baz
testlab enable # requires short pp
ccdinfo # flags 1
ccdreset
ccdinfo # no password, flags=1, caps all default
ccdlock
testlab open
ccdinfo # opened
testlab disable # requires short pp; let it time out
ccdinfo # still opened, flags=1
ccdlock
ccdoops # backdoor in CR50_DEV images to force-reset CCD
ccdinfo # opened, flags=0, all defaults (yes, oops wipes out testlab)
ccdreset rma
ccdinfo # flags = 0x400000, everything but Cr50FullConsole always
ccdreset # back to flags=0, all default
Change-Id: I24e8d8f361874671e6e94f27492ae00db919bea9
Reviewed-on: https://chromium-review.googlesource.com/569439
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Tested-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This will be used as part of case closed debugging configuration.
Currently, this only adds the state machine, and a test command which
is available when CR50_DEV=1. It also adds a new sleep mask flag for
physical presence detect, instead of oveloading FORCE_NO_DSLEEP.
The physical presence state machine supports both short (tap 5 times
in 15 seconds) and long (short, followed by 4 more taps 1-5 minutes
apart) sequences. It will call a callback function at the end of the
sequence, so that multiple things can each request physical presence
in turn. This will be used by ccdopen / ccdunlock / testlab commands
for CCD V1.
Eventually, CCD config will replace the unlock sequence handling in
wp.c. But for now, we don't touch that.
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=none
TEST=manual
Short sequence:
pp short
pp
pp
pp # See "Physical presence good"
Timeout
pp short
pp # 15 sec later, get timeout error
Long sequence:
pp long
pp
pp
pp
(wait 2 sec)
pp
(wait 2 sec)
pp # See "PP good"
Long sequence, presses too fast:
pp long
pp
pp
pp
pp # See "PP L too soon"
(wait 2 sec)
pp
(wait 2 sec)
pp # See "Physical presence good"
Abort:
pp short
pp abort # See "Physical presence aborted"
Change-Id: I09da81ad11d328e7d7740c3fe838a5f67d7b8708
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/568796
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This patch clears RESET_FLAG_AP_OFF on recovery boot so that the
system boots immediately regardless of the previous power state.
BUG=b:63669512
BRANCH=none
TEST=Verify the followings on reworked Fizz:
1. Press RB and PB in S0: FAIL(*1)/PASS
2. Press RB and PB in S5: FAIL(*1)/PASS
3. Unplug AC in S0 then press RB and plug in AC: PASS/PASS
4. Unplug AC in S5 then press RB and plug in AC: PASS/PASS
(*1: b:63668669)
Change-Id: If300fc9ec28ff0f7833e84a02e174e501b6a5016
Reviewed-on: https://chromium-review.googlesource.com/570948
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change makes EC run vboot in the HOOK task. The vboot routine
requires battery and charger info. It waits in a deferred call
loop until the charge manager is initialized.
BUG=b:63586051
BRANCH=none
TEST=Verify the following cases:
A. Hardware reboot (type-c/BJ)
1. Unplug AC in S0 then plug in AC: BOOT/BOOT
2. Unplug AC in S5 then plug in AC: S5/S5
3. Unplug AC after A.2 then plug in AC: S5/S5
4. Press PB in S5: BOOT/BOOT
B. Software reboot (type-c/BJ)
1. Run EC reboot command in S0: BOOT/BOOT
2. Run EC reboot command in S5: BOOT/BOOT
3. Run EC reboot ap-off command in S0: S5/S5
4. Run EC reboot ap-off command in S5: S5/S5
5. Run host reboot command: BOOT/BOOT
6. Run host shutdown command: S5/S5
C. Recovery tests
1. Press RB and PB in S0: FAIL(*1)/PASS
2. Press RB and PB in S5: FAIL(*1)/PASS(*2)
3. Unplug AC in S0 then press RB and plug in AC: PASS/PASS
4. Unplug AC in S5 then press RB and plug in AC: PASS(*2)/PASS(*2)
*1: b:63668669
*2: b:63669512. Requires one more PB press.
Change-Id: I28f37fdad7f83d0d44570b9003e8c6a4b83b832f
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/568699
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch moves the code which can be shared with other data
verification schemes (e.g. RWSIG) under common/vboot. It also
adds unit tests for it.
BUG=b:38462249
BRANCH=none
TEST=make run-vboot. Verify verification succeeds on Fizz.
Change-Id: Icab4d96dd2c154a12b01c41ebe9b46286b4b590e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/563463
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch gives EC the capability of verifying and jumping to
RW_A or RW_B. EC tries the slot stored in a persistent storage
(e.g. BBRAM). If verification fails due to invalid contents, EC
tries the other slot. AP's expectation and its reaction to the
state of the slots and the currently running image are summarized
below.
Since the system is still unlocked (CONFIG_SYSTEM_UNLOCKED), EC
won't try to verify or jump to RW yet.
| AP expects X
----------+---------------------------
SLOT_A=X | proceed
SLOT_B=X | proceed
----------+---------------------------
SLOT_A=X' | reboot to B
SLOT_B=X | proceed
----------+---------------------------
SLOT_A=X | proceed
SLOT_B=X' | reboot to A
----------+---------------------------
SLOT_A=X' | write X to B, reboot to B
SLOT_B=X' | write X to A, reboot to A
BUG=b:38462249
BRANCH=none
TEST=Lock the system and boot Fizz on barrel-jack and type-c.
Change-Id: I51e3abd4d9af44ab3d531561cb9bfa2e8d775f6a
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/556286
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This commit increases the precision used in the noisy magnitude
deviation check by multiplying the scaled sensor data by 8 in the
intermediate calculations. Prior to this, due to some bits being lost,
certain devices would determine the lid angle as unreliable in specific
angles, even though the device was at rest.
BUG=b:63148973
BRANCH=eve,gru,reef
TEST=Flash bob, set DUT on desk, run `while true; do ectool motionsense
lid_angle; sleep 0.1; done`, slowly move the lid from 15 degrees until
~350. Verify that no particular angle results in a unreliable lid angle
reading.
TEST=Run `evtest` and examing cros-ec-buttons, fold screen all the way
back to make tablet mode, shake device for at least 30s. Verify that
there are no spurious transitions of the tablet mode switch.
TEST=Repeat above tests on kevin.
Change-Id: Iff06c1df2dd33c60e26a59183f62f29b71548729
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/567050
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This patch defines load addresses of regions using macros to increase
readability.
BUG=none
BRANCH=none
TEST=Diff firmware_image.lds before and after the change.
Change-Id: I24a13f4676b194efb748522f03c3134d1568f5ae
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/566940
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
For hammer, we do not want to require finalization in factory, so
we just protect RO whenever WP GPIO is set.
BRANCH=none
BUG=b:63378217
TEST=Enable CONFIG_FLASH_PSTATE_LOCKED, flash hammer,
check with flashinfo that RO protection matches WP status.
Change-Id: I902ee478c00a3c932277d2a7d0622c070654a5eb
Reviewed-on: https://chromium-review.googlesource.com/563217
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Virtual battery implements a smart battery interface, but the actual
battery on the system may speak a different protocol. Support such
batteries by removing direct i2c access from the virtual battery driver.
Fetch data from storage when available, and call generic battery
routines when not.
BUG=chromium:717753
BRANCH=None
TEST=Manual on kevin, boot and verify "Unhandled VB reg" prints are not
seen. Verify by-eye that all regs in cros 4.4 kernel sbs-battery.c are
handled (except REG_MANUFACTURER_DATA). Verify that sysfs manufacturer,
model name, time_to_full_avg and time_to_empty_avg values are all sane.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia8fc0a80ac7576fa8bdcc3b7dac0609d9d754234
Reviewed-on: https://chromium-review.googlesource.com/547004
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
- Move generic implementation to curve25519-generic.o
- Always use optimized version on cortex-m0.
- Rename .s files to .S, remove unnecessary lines in assembly files.
- Rename crypto_scalarmult_curve25519 to x25519_scalar_mult to match
the signature provided by the generic implementation.
- Replace some handcoded memcpy with function calls
- Remove unnecessary "volatile" specifications in the code.
BRANCH=none
BUG=b:62813194
TEST=To test old implementation only:
- Increase CONFIG_RO_SIZE to 60kb
- Increase console stack size to 2048
make BOARD=hammer PROJECT=x25519 TEST_BUILD=y
./util/flash_ec --board=hammer --image=build/hammer/x25519.bin
EC console: runtest, taskinfo
=> Used to takes ~4'17" to run (X25519 duration 256347 us).
1496/2048 stack size usage in CONSOLE task
=> Now takes ~1'25" to run (X25519 duration 84520 us)
732/2048 stack size usage in CONSOLE task
TEST=In test/x25519.c, uncomment #define TEST_X25519_1M_ITERATIONS
make BOARD=hammer PROJECT=x25519 TEST_BUILD=y
./util/flash_ec --board=hammer --image=build/hammer/x25519.bin
EC console: runtest, wait ~23 hours, test passes.
TEST=- Define CONFIG_CURVE25519_CORTEXM0 (next patch)
makes newsizes
build/hammer/RW/ec.RW.flat shrank by 1888 bytes: (52208 to 50320)
Change-Id: Icce38d3c32f431a85ac0f951cf34456b490dc665
Reviewed-on: https://chromium-review.googlesource.com/540962
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
RMA auth uses X25519 to generate a relatively small challenge and
response.
Currently, nothing calls the rma_auth code. We'll need console and
TPM vendor commands to do so.
BUG=b:37952913
BRANCH=none
TEST=make buildall
Change-Id: Iec7f2d0e3dc8243f79b009ead16bb3ba9f1bef9d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/544184
as it turns out, we're pretty aggressive in iterating over all TCPCs
checking for alerts when any of them generate an interrupt or their
interrupt line is low. this can cause unfortunate behavior if the
driver hasn't initialized itself (and the chip) yet for interrupts to
be handled or we've released (disconnected) the driver so we can do a
TCPC firmware update. so, check the PD task state to see if it makes
sense to service the port's interrupt.
note: there seems to be a quirk with the ps8751 in that it holds its
ALERT# (interrupt) line low during firmware update. this line is
supposed to be falling edge triggered, so it's technically not
interrupting, but since we also poll the line level, we think there's
a continuous interrupt that isn't acutally there. we get away with
this because pd_exchange_status() has a 5ms delay in its polling loop
to avoid spinning.
the particular test case was to unplug the PD power brick during TCPC
firmware update (over i2c). the interrupt handler would be called,
accessing the TCPC over i2c and causing all sorts of havoc.
TEST=tested with follow-up CLs and verified ps8751 firmware update
works on electro.
BRANCH=none
BUG=b:35586896
Change-Id: I880cff49e0e9637256efa9003bcc46274536e631
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/544661
Reviewed-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
In order to report specific wake events from differernt devices
add a host command that allows setting device event mask, and
triggering a host event when that device event is set.
This is done as a separate command and mask because we are running
out of host events, and it takes over the unused thermal overload
event that was never used in EC or BIOS.
The first use case for this is platforms that have AP wake events
that go to the EC, for instance devices that use Deep S3 and have
a limited set of wake pins. (such as Eve)
This allows the AP to determine the exact wake source for an event
so it can be logged and acted on by the AP if necessary.
BUG=b:36024430
BRANCH=eve
TEST=manual testing on eve with trackpad and dsp wake events
Change-Id: I48d94014c00dc1dad098ab96af0ddc7860229762
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/555632
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Add the common code to support FIDO U2F (Universal second factor
authentication) protocol implementation: the APDU parsing and standard
commands execution, plus a few non-standard flags and hooks.
The u2f.h header is the unmodified copy from the U2F v1.1
Specifications archive.
Mostly copied over from the cr52 code-base.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve.
CQ-DEPEND=CL:*390230
Change-Id: I636d4a77ea69d69b5ab18a958e58ee6fcb2476bc
Reviewed-on: https://chromium-review.googlesource.com/518136
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Base32 encoding is used to turn the RMA reset binary
challenge/response into less-typo-prone text, at 5 bits per character.
BUG=b:37952913
BRANCH=none
TEST=make runtests
Change-Id: I474750a20204ba353cea1e91982aa03e8071c0c2
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/544177
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This patch makes EC read the slot to verify and jump to from the
battery backed up RAM (BBRAM).
BUG=b:38462249
BRANCH=none
TEST=Boot Fizz
Change-Id: I0c78861ea3ccdc45d0aa08e690e3a68f53658409
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/518255
similar to the USB_PD_TCPC case, add release/init operations when the
pd_task enters/leaves the PD_STATE_SUSPENDED state. one use case for
PD_SUSPEND is to get exlusive access to the TCPC for things like
firmware update, so the release/init operation is needed to get the
TCPC and driver into a good state.
updated all tcpm_drv style drivers. for backward compatibility, "old"
drivers that may not handle init/release properly simply return
EC_ERROR_UNIMPLEMENTED for tcpm_release(). pd_task() uses this as a
signal that it should not try to re-init() the driver.
TEST=tested in combination with follow-on CLs to do TCPC firmware
update on electro. also built for kevin, eve, sand which are
some of the other boards using these drivers.
"make buildall -j" passes.
BRANCH=none
BUG=b:35586896
Change-Id: I3d2964a79e710428f7a6e7004d68ab424af85be8
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/544660
Reviewed-by: Shawn N <shawnn@chromium.org>
This patch sets/clears RESET_FLAG_AP_OFF on S5<->S3 transitions.
It's set when the system gracefully shuts down and cleared when the
system boots up. The result is EC tries to go back to the
previous state upon AC plug-in on battery-less systems.
This is required for digital signage and kiosk.
This also reverts: CL 514209, 486946, and 486945.
BUG=b:37536389
BRANCH=none
TEST=Tested as follows:
A. Boot to S0
A.1. Unplug AC while system is in S0 then plug in - PASS
A.2. Unplug AC while system is in S3 then plug in - PASS
A.3. Press recovery+power in S0 - PASS
A.4. Press recovery+power in G3 - FAIL (To be fixed)
A.5. Execute reboot console command - PASS
A.6. Execute reboot OS command - PASS
A.7. Execute reboot console command in G3 - PASS
B. Boot to G3
B.1 Unplug AC while system is in G3 then plug in - PASS
B.2 Unplug AC after B.1 then plug in - PASS
B.3 Shutdown by power button on recovery screen then unplug
plug in AC - PASS
B.4 Execute reboot ap-off console command - PASS
B.5 Execute shutdown command from OS then plug in AC - PASS
Change-Id: Iaa6f930585050fdd3511c711b449dff47525066d
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/517287
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds vboot for EC by EC (vboot EC) for x86 systems.
When ec is transitioning s5->s3, it checks the power supply is
enough to boot AP or not. If not, it runs other checks and may
finally validate and jump to a RW image.
BUG=b:38462249
BRANCH=none
TEST=Boot Fizz on barrel jack and type-c charger.
Change-Id: I5988b0595976370c5303c45541702ae89d86fc97
Reviewed-on: https://chromium-review.googlesource.com/518254
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
looks like we had a bit of a race condition: set_state() was
effectively just an assignment opration to pd[port].task_state. it's
called asynchronously from pd_set_suspend() in response to a
PD_SUSPEND message from the AP as well as from pd_task() before it
enters its main event loop. this can take a long time because
tcpci_tcpm_init() has a 300ms timeout. last one wins.
similarly, when pd_task() is running its main loop, pd_set_suspend()
really needs to wait for pd_task() to actually enter the
PD_STATE_SUSPENDED state before the caller can assume that the
pd_task() has stopped accessing the TCPC.
the particular failure case was when depthcharge would decide to do a
TCPC firmware update. it starts by sending a PD_SUSPEND to the EC,
then accessing the TCPC. unfortunately, the pd_task() hadn't gotten
out of the way yet, thus causing TCPC access chaos.
so, i'm adding a req_suspend_state flag to the pd_protocol struct so
we can tell pd_task() to suspend itself in a controlled manner. when
pd_task() is ready to do a state change - basically at the top of the
main event loop - it'll change to PD_STATE_SUSPENDED and clear the
req_suspend_state flag.
in any case, pd_set_suspend() still needs to wait around for pd_task()
to enter the suspended state as we don't have a fancy handshake
mechanism between these tasks.
TEST=in combination with some follow-on CLs, ps8751 firmware update
works properly where previously it needed a ~2 second delay
for the EC pd_task() to settle. the way to trigger the
failure was to insert or remove the power brick.
BRANCH=none
BUG=b:62356808
Change-Id: I363803ff60db31ccf84d592f8c9d1610fbe0f9ce
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/544659
Reviewed-by: Shawn N <shawnn@chromium.org>
Recovery mode can be triggered with or without hw reinit. And both the
modes are triggered using the same button combination held down for
different amount of time. For recovery mode with hw reinit (>30
seconds), LED blinks for 4 seconds. However, for recovery mode without
hw reinit(>10 seconds), there is no user indication. This change turns
on the LED as soon as the >10 second condition is satisfied. This
provides an indication to the user that recovery mode is triggered.
BUG=b:62886608
BRANCH=None
TEST=make -j buildall
Change-Id: I949c3e7e98441131df987b6351c1f614f3b4831c
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/549775
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
If we have requested the host to go to recovery mode, the host will
usually not need an RW hash because it won't do EC SW sync. Therefore,
do not auto-start calculation of our hash if we've requested recovery.
This may avoid past recovery-breaking bugs due to unexpected RW contents.
If the host does need the hash after all, it will manually request that
the computation start.
BUG=chromium:612966
BRANCH=None
TEST=Boot to recovery mode on kevin, verify that "hash start" print is
not seen on UART.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I66d2d74398357dfe30e39882feec8cfba4cc945c
Reviewed-on: https://chromium-review.googlesource.com/540695
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add a delay before flash_erase deferred started so the task does not halt
CPU, and cause the response of EC_CMD_FLASH_ERASE to not be delivered.
When the above situation happens the host I2C controller will timeout.
A 100ms delay should be long enough on any board to allow the response
to be sent.
BRANCH=none
BUG=b:38018926
TEST=on eve units where flashrom always fail:
`flashrom -p ec:type=tp -w ec.bin` succeeds.
Change-Id: I399a60064392da41a3e27f8630175ab427047ab7
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/547375
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@google.com>
On a keyboard-less, volume-button-less board, we support simplified
sysrq handling.
For Fizz, we use the recovery button to trigger sysrq event and
holding it down to trigger warm reset.
BUG=b:38418116,b:38417391
BRANCH=none
TEST=On Fizz, try
1. Press recovery button and release -> sysrq sent
2. Press and hold recovery button -> warm reset
3. Press recovery button and power button -> enter recovery mode
Change-Id: If8760319dba3df4545e9805b396ac89c241dae80
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/537817
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Mapped reads are relative to CONFIG_EC_*_STORAGE_OFF, not
CONFIG_R*_MEM_OFF. The previous implementation happened to work for
internal mapped storage (eg. stm32) but failed for external mapped
storage which is copied to SRAM before execution (eg. npcx).
BUG=b:62841029
TEST=Verify sysjump works again on eve/poppy/soraka. Verify sysjump
and sig verification continues to work on fizz and stm32.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Id51ce5697555eea38b246b58dbf47f22d4befaa7
Reviewed-on: https://chromium-review.googlesource.com/541861
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This API checks battery charge level and current power supply
to determine whether the AP has enough power to boot or not.
BUG=b:38462249
BRANCH=none
TEST=make buildall
Change-Id: I489f7ea92f230701b8f18c94d3e698aad90b4a03
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/517272
This patch adds wait between DSW_PWROK and PWRBTN assert. It is
required to be 95 msec or longer for Kaby Lake and Sky Lake.
Refer to the timing diagram for G3 to S0 on Sky Lake or Kaby Lake
platform design guide for details.
BUG=b:62584658
BRANCH=none
TEST=On Fizz, measured time between DSW_PWROK high and PWRBTN assert
for 1:AC plug-in, 2:recovery+power press, 3: reboot ec command.
Change-Id: I89a14ac9a49e20a332bd662d90be62f8ea23b003
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/534901
Until HOOK_INIT has completed, do not allow any tasks other than HOOKS
or IDLE to be scheduled. Programmers often make the assumption that
a HOOK_INIT function is guaranteed to be run before task code that depends
on it, so let's make it so.
BUG=chromium:649398
BRANCH=None
TEST=Manual on kevin, compare boot without patch:
...
[0.004 power state 0 = G3, in 0x0008] <-- from chipset task
RTC: 0x00000000 (0.00 s)
[0.004 power state 4 = G3->S5, in 0x0008]
RTC: 0x00000000 (0.00 s)
[0.005 clear MKBP fifo]
[0.006 clear MKBP fifo]
[0.006 KB init state: ... <-- from keyscan task
[0.012 SW 0x05]
[0.155 hash start 0x00020000 0x00019a38]
[0.158 HOOK_INIT DONE!]
... to boot with patch:
...
RTC: 0x58cc614c (1489789260.00 s)
[0.004 clear MKBP fifo]
[0.005 clear MKBP fifo]
[0.010 SW 0x05]
[0.155 hash start 0x00020000 0x000198e0]
[0.157 HOOK_INIT DONE!]
...
Also, verify kevin boots to OS and is generally functional through
sysjump and basic tasks, and verify elm (stm32f0 / cortex-m0) boots.
Change-Id: If56fab05ce9b9650feb93c5cfc2d084aa281e622
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/456628
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Cortex-M4 supports a floating point square root function that takes 14
cycles to execute, which is a speed improvement over the existing binary
search, and saves flash space.
BUG=chromium:687624
BRANCH=None
TEST=On kevin, verify that both sqrtf methods (binary search vs HW
instruction) have identical results for fractional input (eg.
sqrt(15.999999) = 3), except when floating point representation of
square root rounds up to an integer. Verify identical results for all
integers [-100, 16793602). Note that 16793602 is the first integer for
which the floating point representation of sqrt rounds up to an integer.
Also verify basic motion sense functions on kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I8521c9a28c958b340ca83c37342253e424df0c91
Reviewed-on: https://chromium-review.googlesource.com/537734
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
If Cr50 happens to start on a chip where Board ID programmed in INFO1
does not match the contents of the RW header, it means that for some
reason the other RW is not operational and the current image is the
only viable one.
In this case the Cr50 starts but operates in limited mode (only
commands for updating the image and reporting state are handled). In
this case the reason for recovery could be seen on the Recovery
screen, and the update could be done once Chrome OS boots in recovery
mode.
BRANCH=none
BUG=b:35586335
TEST=verified the following:
- if an image with wrong board ID is started, it tries to fall back
(sets the counter to a value above threshold and reboots)
- if the fallback fails, the image keeps running in the limited
capabilities mode but the update is possible, observed that the
new image took over worked after powercycling the device.
- observed proper error message on the recovery screen showing where
the error comes from
Change-Id: I46ba75392f8e891bb8503fb15aea2c56b5805e83
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535978
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Handle UPDATE_EXTRA_CMD_PAIR_CHALLENGE command, where the
lid sends a random x25519 public key, and nonce, and the base
replies with its own (stable) x25519 public key, and computes
a shared secret using its private key to verify its identity.
BRANCH=none
BUG=b:38486828
TEST=Flash hammer, ./usb_updater2 -c always reports the same
device public key, and authenticator is correct.
Change-Id: Ida60ffa7476794ee92669951c740dbe35950fb9c
Reviewed-on: https://chromium-review.googlesource.com/532475
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This change ensures that the power button pulse setting is saved and
restored across a sysjump. It uses the SYSJUMP_TAG "PB" (0x5042).
BUG=b:62445190
BRANCH=None
TEST=The condition mentioned in the bug could be reproduced using
following steps:
1. reboot on EC console
2. Use Vup/Vdn to select any option other than Power off.
3. Press power button
After step #3 above, device would shut down instead of selecting the
option. Verified that with this change, the device does not power off
anymore at step #3.
Change-Id: Icebe9c17d39a82fc3854dd75cc3a1dea032a234a
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/533921
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The contents of the board ID fields of the Cr50 image headers is an
important piece of information which determines if an image can run on
a particular H1 chip.
This patch adds this information to the output of the 'version'
command, printing both the contents of the fields of the RW images and
if the image would run with the current INFO1 board ID contents (Yes
or NO).
The board_id feature is in fact g chipset specific, this is why
board_id support files are being moved from the cr50 board scope to
the g chip scope.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=observed expected output in the version command:
> bid
Board ID: 000000fa, flags 000000ff
> vers
Chip: g cr50 B2-C
Board: 0
RO_A: * 0.0.10/29d77172
RO_B: 0.0.10/c2a3f8f9
RW_A: * 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
RW_B: 0.0.20/DBG/cr50_v1.1.6543-2c68a2630+
BID A: 00000000:00000000:00000000 Yes
BID B: 000000ea:0000fffc:000000ff No
Build: 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
tpm2:v0.0.289-cb2de5a
cryptoc:v0.0.8-6283eee
2017-06-09 15:34:19 vbendeb@eskimo.mtv.corp.google.com
>
Change-Id: I5b283abf304a7408ca8f424407044fca238185e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/530033
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Adds a mechanism that allows a board to disable interrupting the AP /
kernel when the status of any one of the EC_HOST_EVENTS included in
CONFIG_HOST_EVENT_REPORT_MASK changes state. Default state enables
reporting of all events; a board can override this by defining
CONFIG_HOST_EVENT_REPORT_MASK in its board.h file.
NOTE: The host_set_events() and host_clear_events() routines no longer
interrupt the AP if none of the host events the AP is interested in
changed state.
BRANCH=none
BUG=chromium:637061
TEST=make buildall passes
Signed-off-by: Nick Vaccaro <nvaccaro@chromium.org>
Change-Id: I678fb9d9dab6890848b94b314efd711842b1fd48
Reviewed-on: https://chromium-review.googlesource.com/502078
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The upcoming changes in usb_updater will allow to issue vendor
commands to set and get board ID value. It is also useful to be able
to corrupt the alternative RW header over Suzy-Q when Cr50 is running
a debug image.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=not yet.
Change-Id: I54ac6eb4cebd85f97407211c5212b868d61e560f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/524894
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
When vendor commands are processed by the TPM device, the result of
the command execution is communicated through the TPM response header.
When vendor commands are sent through USB the command execution result
value is lost, as the USB reply includes only the response payload,
(if any), but not the result value.
With this patch the single byte result value is prepended to the USB
response payload. The recipient will always look for the value in the
first byte of the response to find the vendor command execution
status.
The corresponding change to the Cr50 usb_updater will remove the
response code from the payload before considering the command's return
data.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=verified proper existing extension commands processing (post
reset, turn update on) by the new version of usb_updater and
backwards compatibility with earlier Cr50 RW version (down to
0.0.13).
Change-Id: I5c8b3ea71d3cbbaccc06c909754944b3ab04675d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/525093
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Mix in board-generated entropy with the externally provided one,
which should help make the per-device secret stronger.
BRANCH=none
BUG=b:38486828
TEST=reboot; rollbackaddent Hello => works fine when USB is connected,
fails otherwise, as board-generated entropy relies on USB timing.
Change-Id: I314f44759c5f8b859913a748db95e9d42b5cdd11
Reviewed-on: https://chromium-review.googlesource.com/518609
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The default USB packet has a maximum size of 64 bytes, however, we need
to support some USB over I2C write transaction that exceed this default.
To support so with protocol backwards-compatible in mind, we enable a
config option CONFIG_USB_I2C_MAX_WRITE_COUNT that will enlarge the USB
RX queue.
BRANCH=none
BUG=b:35587174
TEST=Complete presubmit test.
TEST=Manually update elan trackpad firmware with interrupt disabled.
Change-Id: Ia8983b036b7297f7ca673459ae34b7e5ecd2ee01
Reviewed-on: https://chromium-review.googlesource.com/513642
Commit-Ready: Chun-ta Lin <itspeter@chromium.org>
Tested-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Some device has large pages that take up to 2s to erase.
Add support to send a deferred erase command, that willi
be processed on HOOK task.
It can leave the other tasks (HOST_CMD) responsive.
If the whole EC can stall on flash erase, like the STM32F4 do,
at least the command FLASH_ERASE_GET_RESULT can be retried when it times
out.
BRANCH=none
TEST=Check with flashrom doing a loop of overwrites.
BUG=b:38018926
Change-Id: I8ce8e901172843d00aac0d8d59a84cbd13f58a10
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/510012
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
