PS8751 does not restore all register contents when resuming
from low power mode. This change makes tcpm call board_init
when it stops auto-toggling so that register contents can be
restored.
BUG=b:35585399
BRACH=none
TEST=On Snappy, the board_init funciton is called every time a device
is plugged in and register contents are restored.
Change-Id: I50c51334f43c02e3c4d8453e1e966bf6eb3ce769
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/454139
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Let's split the usb headers in 3 different parts, instead of having
usb_descriptor.h pull in usb_hw.h and usb_api.h.
- usb_api.h: EC functions related to usb (e.g. connect/disconnect)
- usb_descriptor.h: common USB names and structures
- usb_hw.h: Functions required for interactive with EC's USB HW
BRANCH=none
BUG=b:35587171
TEST=make buildall -j
Change-Id: I37ead61e3be5e7ae464f1c9137cf02eaab0ff92e
Reviewed-on: https://chromium-review.googlesource.com/454861
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Image used size is now part of the image_data struct present in all
images at a fixed offset, so use it rather than scanning from the end of
the image.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that system_get_image_used() returns
the same value as the old implementation, for both RO and RW images.
BRANCH=None
Change-Id: I35f0aa87f5ab1371dbd8b132f22b9d0044358223
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450859
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I7b8dc3ac8cf2df3184d0701a0e0ec8032de8d81b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450858
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In order to make pass through charging safe, there must be a mechanism
to signal the CHG port manager that Vbus is available and in a steady
state. When a typec only charger is used for the CHG port, then it's
steady state is SRC_DISCOVERY. Need a way to differentiate the TypeC
only charger from a USB PD charger that's also going through
SNK_DISCOVERY.
In addition, to allow a DTS device to support PD messaging, can't
stay in SRC_ACCESSORY state. This CL makes a modification to the
USB PD state machine so that if a debug accessory is detected and
CONFIG_USB_PD_DTS is defined, then the state machine will advance to
SRC_STARTUP and prepare for messages similar to when a UFP attach
is detected.
BUG=b:35586526
BRANCH=servo
TEST=Manual Built for both Plankton and Reef, verified that Reef
connects as both SNK and SRC.
Change-Id: I9aea0341cd9b6e6773023f0923a9a18a86fc4627
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448987
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Pass "full_build_string" to ccprintf() as expected. I believe that this
code only worked previosly due to blind luck; the compiler allocated
"full_build_string" on the stack in such a way that it was available at the
end of the call frame for ccprintf().
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: Ib307547a4c4d6300ccf018b33aee4db7a4f364f8
Reviewed-on: https://chromium-review.googlesource.com/451084
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
pdcontrol suspend command will be used to prevent tcpm from putting
the chip into sleep while firmware update is taking place. Currently
the command suspends or resumes port 0. This patch makes the command
apply to ports individually.
pd enable console command now takes a port number:
pd <port> enable/disable.
This patch also replaces CONFIG_USB_PD_COMM_ENABLED with _DISABLED.
When it's defined, PD communication is disabled at startup.
Plankton undefines CONFIG_USB_PD_COMM_ENABLED enable, intending to
disable PD communication at startup. Therefore, this patch defines
CONFIG_USB_PD_COMM_DISABLED in its board.h.
BUG=b:35586859
BRANCH=none
TEST=From AP console:
localhost # /tmp/ectool pdcontrol suspend 1
[600.188013 TCPC p1 suspended!]
> pd 1 state
Port C1 CC1, Dis - Role: SNK-UFP State: SUSPENDED, Flags: 0x0020
localhost # /tmp/ectool pdcontrol resume 1
[678.516613 TCPC p1 resumed!]
> pd 1 state
Port C1 CC1, Ena - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
From ec console:
> pd 1 disable
Port C1 disable
> pd 1 state
Port C1 CC1, Dis - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
> pd 1 enable
Port C1 enabled
> pd 1 state
Port C1 CC1, Ena - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
Change-Id: Ia0cc4904ac52adc4b89de20918968c8df78b9c80
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447968
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Using -O3 optimization level rather than -Os results in a large speed-up
for a minor code size increase for the RSA code with our current GCC
toolchain.
Add the CONFIG_RSA_OPTIMIZED option to do it on platforms which are not
too size-constrained.
On cortex-M4 based STM32L432, I'm measuring a 37 to 40% speed increase
(depending on CPU frequency) for a 200 bytes code size delta.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=manual: benchmark RSA2048 with F4 exponent on STM32L432:
-Os -O3
@16Mhz 185163 us --> 111942 us
@80Mhz 39286 us --> 24582 us
Change-Id: I8c2e4b757f037f4f645fb73ba0faaaa471b24896
Reviewed-on: https://chromium-review.googlesource.com/445218
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
When battery is fully charged, Reef starts discharging to protect
battery and starts charging again when charge level goes down
around 95%. To prevent the battery LED from showing blue with the
charger plugged in, this patch adds a new state for discharge +
nearly full. Reef shows a color indicating battery is full if
an external charger is present.
BUG=b:35775017
BRANCH=none
TEST=Fully charge Electro. Plug in OEM charger. LED lights blue.
Change-Id: I4c7c62f2c51c1d39188d1b271331984e89d5d7a3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448961
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The host may ask for our switch state at any time, so do initialization
immediately after lid + power button are initialized.
BUG=chrome-os-partner:63073
BRANCH=gru
TEST=On kevin, verify system boots when EC reset is triggered with lid
open. Verify lid close and power button press still succeed to
power-down from dev screen.
Change-Id: I8e37c02ef4f4d2d7c06beb383cdbda8eea67bc5c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/444322
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 106d33cd3a8e4f3356950a3b2b92ea587977b4e7)
Reviewed-on: https://chromium-review.googlesource.com/445276
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
The function tcpm_select_rp_value() is used to set a given Rp
value. This function was not supported for boards that use the config
option CONFIG_USB_PD_TCPC. This CL adds a weak board_ function which
can be overloaded for boards that have the requirement to set Rp to
different values.
BUG=chrome-os-partner:61878
BRANCH=servo
TEST=run 'make buildall'. On plankton added a console command to trigger
a call to tcpm_select_rp_value(0, 0), verified that it returned
2 (EC_ERROR_NOT_IMPLEMENTED). Then added board_select_rp_value() to
plankton's board.c and verified that it returned 0.
Change-Id: I1cd6f0ed51717736d30575c58025bd9a1c5d6fc4
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/446685
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This commit enables the use of the nvmem vars module. The console lock
state is migrated from using the long life scratch register, to nvmem
vars instead which will persist across power on reboots.
BUG=b:35586145
BRANCH=None
TEST=Flash a dev image. Lock the console. Remove all power from the
system. Power on system and verify that console is still locked.
Unlock the console, remove power from the system, power on the system,
verify that the console is now unlocked.
TEST=Repeat the above test, but using the nvtestvar console command
instead.
Change-Id: I03a2098bb0017cfca59889457a332eafb0e95db6
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445804
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Our previous idea to cut Rd for many reset cases cannot work if cr50
consistently resets the EC by asserting the reset pin shortly after
power-on. Therefore, make a decision based upon whether battery-backed
memory indicates we previously negotiated a PD power contract as a sink.
If we previously did not negotiate a contract, or if power was removed
from the device (causing battery-backed memory to wipe) then we can
assume that we don't have an active power contract.
BUG=chrome-os-partner:62952
BRANCH=reef
TEST=On reef, run "cutoff" on the console, reattach AC, and verify
device successfully wakes. Also verify Rp is dropped on console 'reboot'
and F3 + power from RW.
Change-Id: Ie300b9589cac6be7a69b77678bea6b1b6b25578c
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/443356
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
ROLLBACK region will be used to store rollback information, and
can be protected independently of RW (it can only be protected when
RO is protected, though).
This is only supported on stm32f0 currently.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=on hammer (stm32f072)
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp all; reboot => RO+RW+RB protected
flashwp noall; reboot => only RO protected
flashwp rw; reboot => only RO+RW protected
flashwp rb; reboot => RO+RW+RB protected
flashwp norb; reboot => RO+RW protected
flashwp all; reboot => RO+RW+RB protected
flashwp norw; reboot => RO+RB protected
TEST=on reef, rb/norb commands not available
Change-Id: I45ffc66d91cf3699ecff025e5114c59a73dc8274
Reviewed-on: https://chromium-review.googlesource.com/430519
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add generic routines to read or write a byte to battery-backed RAM, and
implement vbnvcontext get/set using these routines.
BUG=chrome-os-partner:62952
BRANCH=reef
TEST=On reef, with subsequent commit, run "cutoff" on the console,
reattach AC, and verify device successfully wakes. Also verify Rp is
dropped on console 'reboot' and F3 + power from RW.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I14691923f2e5198e901b6b5199e92c58c68cd18d
Reviewed-on: https://chromium-review.googlesource.com/444444
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The idea of this flag is to be able to protect/unprotect only the
RW portion of the flash. In the (usual) case where ALL=RO+RW, with
no other region, this makes no difference compared to the existing
EC_FLASH_PROTECT_ALL_* flag, and this flag may not be supported.
This is necessary for futher work, where a ROLLBACK region is added,
so that RW/ROLLBACK can be protected/unprotected individually.
Only support for stm32f0 is added, as this is the target for hammer.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=build and flash hammer (stm32f072)
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp all; reboot => RO+RW protected
flashwp noall; reboot => only RO protected
flashwp rw/norw not available
TEST=enable CONFIG_FLASH_PROTECT_RW
build and flash hammer (stm32f072)
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp all; reboot => RO+RW protected
flashwp noall; reboot => only RO protected
flashwp rw; reboot => RO+RW protected
flashwp norw; reboot => only RO protected
TEST=build and flash reef (npcx)
flashinfo => RO+RW not protected
flashwp true => RO protected
flashwp all; flashinfo => all_now displayed
reboot => RO protected
flashwp rw/norw not available
Change-Id: Ica6f499cf2e8a9345b08ef52c915655a983ffe3c
Reviewed-on: https://chromium-review.googlesource.com/442265
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Saves a little bit of flash size:
Compared 167 of 167 files.
77 files changed.
Total size change: -3240 bytes.
Average size change: -42 bytes.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=make buildall -j
TEST=hammer: 'flashwp true' works as expected
TEST=hammer+CONFIG_FLASH_PSTATE_BANK: 'flashwp true' still works
TEST=reef: 'flashwp now' sets all_now flag in flashinfo
Change-Id: Ic2fe8f0c67520afea276369fdf8c59e75e95208e
Reviewed-on: https://chromium-review.googlesource.com/444488
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Keep only the most compact version of the curve25519 code
and remove the remaining unused code for easier compilation.
Do the minimal changes to make it compile in the EC code base,
there should be no real functional changes.
Re-use the wording from BoringSSL include/openssl/curve25519.h for the
header.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:62991
TEST=run x25519 on host (ie 'make run-x25519')
and the STM32L4 target:
make BOARD=eve_fp PROJECT=x25519 TEST_BUILD=y
./util/flash_ec --board=eve_fp --image=build/eve_fp/x25519.bin
execute 'runtest' in the console.
Change-Id: I13dbe453eff39b461effb1b3ffa549afc1749fef
Reviewed-on: https://chromium-review.googlesource.com/444187
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Adam Langley <agl@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Import the implementation of the curve25519 public key cryptography
from BoringSSL.
It's the unmodified crypto/curve25519/curve25519.c file from the
repository at sha c034e2d3ce16df5f89134515bc113eb4f3a28e0e.
(current HEAD of chromium-stable branch)
It will be used as a primitive to implement a Diffie-Hellman exchange.
The test code in test/x25519.c is also imported unmodified
from BoringSSL crypto/curve25519/x25519_test.cc.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:62991
TEST=with follow-up CLs, run curve25519 test vectors
on host, MEC1322 and STM32 targets.
Change-Id: Ie497f78249f505e32d8e025b0537e82bf4476298
Reviewed-on: https://chromium-review.googlesource.com/444186
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Previously, wiping the TPM would wipe all of NvMem, however, it really
should only clear the TPM's NvMem space. This commit adds a function to
clear a given NvMem user's space and makes the TPM only clear its space.
BUG=chrome-os-partner:61597
BRANCH=None
TEST=Add code for using nvmem vars, create a test variable, add a user
to snappy, unlock the console, verify that the user is no longer present
on the system and the test nvmem var still exists.
TEST=make -j buildall
Change-Id: Ic98baa5166a1ef9ae76e910b1b9ab100300e947f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/445803
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The code deciding which partition to choose properly determines which
one is newer, but invariably populates the cache with the second one,
when both partitions are valid.
This is obviously wrong, on top of that there is no need to check both
partitions' validity, if the newer one checks out.
BRANCH=none
BUG=chrome-os-partner:60555, chrome-os-partner:61972
BUG=chrome-os-partner:61716, chrome-os-partner:61234
BUG=chrome-os-partner:61167, chrome-os-partner:60555
TEST=successfully ran
$ ssh 192.168.1.102 suspend_stress_test --suspend_min 10 \
--suspend_max 10 --wake_max 10 --wake_min 10
for more than 300 cycles (it still is going)
Change-Id: I02d9bb062b9edbbb9787a95ba760872e09ff2761
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/445356
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
The USB FW upgrade endpoint should really only accept vendor commands
required to perform the firmware update. This commit adds a whitelist
that is checked whenever a vendor command is received over this
endpoint.
The allowed commands over USB are the following:
- EXTENSION_POST_RESET
- VENDOR_CC_IMMEDIATE_RESET (only for dev images)
There is also functionality to have a whitelist for vendor commands that
come over the TPM interface.
BUG=chrome-os-partner:62815
BRANCH=None
TEST=Flash Cr50 with image containing this change. Verify that an
upgrade over USB to newer image works.
TEST=Try using usb_updater to send a vendor command that's not in the
whitelist. Verify that the vendor command is dropped.
Change-Id: I71f8ba090a1cc6c9e7c30ce0dd3c25259e8f292f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/443447
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Currently, manually triggered reboots cause the retry counter to be
incremented. However, if the system is responsive enough to process the
reboot commands from either the console or TPM vendor command, we can
assume that the image is "ok". This commit changes the Cr50 behaviour
to decrement the retry counter when a reboot is issued on the console or
the TPM vendor command is received.
BUG=chrome-os-partner:62687
BRANCH=None
TEST=Flash cr50. Flash an older image in the other slot. Enter the
reboot command on the console over 10 times and verify that retry
counter never exceeds RW_BOOT_MAX_RETRY_COUNT and older image is never
executed.
CQ-DEPEND=CL:444264
Change-Id: Ic35bdc63c4141834584a00a7ecceab2abe8dfc21
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/443330
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Saying that 'flashwp rw' was protecting RW region was not really
accurate: it was actually protecting the whole flash (which,
well, is actually equivalent as the RW can't be protected without
the RO).
Let's fix that in anticipation for adding a new flag that will
_really_ set the RW protection (and only that).
BRANCH=none
BUG=chrome-os-partner:61671
TEST=make buildall -j
Change-Id: Ic1c585622330b4976e71150f3a71b74a031a7694
Reviewed-on: https://chromium-review.googlesource.com/442264
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Wai-Hong Tam <waihong@google.com>
usbpd1 futility image type is deprecated and should not be used for
new designs. This adds proper support for rwsig image type.
Key and signatures are added at linker stage step (futility cannot
directly create such signed images). Thanks to VB21 header, rwsig.c
can now tell how many bytes of the RW image need to be
cryptographically verified, and ensure that the rest is blank (0xff).
BRANCH=none
BUG=chromium:690773
TEST=make BOARD=hammer; flash, RW image is verified correctly.
TEST=make runtests -j
TEST=For the rest of the tests:
Change config option to CONFIG_RWSIG_TYPE_RWSIG
TEST=make BOARD=hammer; flash, hammer still verifies correctly.
TEST=cp build/hammer/ec.RW.bin build/hammer/ec.RW.bin.orig;
futility sign --type rwsig --prikey build/hammer/key.vbprik2 \
build/hammer/ec.RW.bin
diff build/hammer/ec.RW.bin build/hammer/ec.RW.bin.orig
=> Same file
TEST=Add CONFIG_CMD_FLASH, flashwrite 0x1e000, reboot, EC does
not verify anymore.
TEST=dump_fmap build/hammer/ec.bin shows KEY_RO and SIG_RW at
correct locations.
Change-Id: I50ec828284c2d1eca67fa8cbddaf6f3b06606c82
Reviewed-on: https://chromium-review.googlesource.com/441546
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Use the motion sensor to manage ALS as well.
The current interface (via memmap) is preserved, but
we can also access the sensor via cros ec sensor stack and
send the ALS information to ARC++.
BUG=chrome-os-partner:59423
BRANCH=reef
CQ-DEPEND=CL:424217
TEST=Check the sensor is working via ACPI sensor and
cros ec sensor. Check ARC++ sees the sensors.
Change-Id: Iaf608370454ad582691b72b471ea87b511863a78
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424323
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This change adds an option to pdchipinfo command to force ec to get
the version from the chip instead of the cache (if it's available).
This option will be used after firmware update, which makes the cache
value stale.
BUG=chrome-os-partner:62383
BRANCH=none
TEST=Run ectool as follows:
localhost ~ # /tmp/ectool pdchipinfo 0 on
vendor_id: 0xaaaa
product_id: 0x3429
device_id: 0xad
fw_version: 0x15
localhost ~ # /tmp/ectool pdchipinfo 1 on
EC result 2 (ERROR)
Change-Id: Icefe96d7fc1208b991a4caa13aaf4f04052edba7
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441271
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The firmware version formats may vary chip to chip. fw_version field is
changed to a union of a 8 byte string and an 64-bit integer.
BUG=chrome-os-partner:62383
BRANCH=none
TEST=ectool pdchipinfo 0/1 on Electro
Change-Id: Id51e66c44338a09ed897ee61f54cd6a394400e63
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/441270
In preparation for adding the rollback protection block, pass
EC_FLASH_PROTECT_RO/ALL_AT_BOOT to flash_[physical_]protect_at_boot,
instead of an enumeration no protection/RO/ALL.
This will later allow us to protect/unprotect the rollback region only,
by adding a EC_FLASH_PROTECT_ROLLBACK_AT_BOOT flag.
BRANCH=none
BUG=chrome-os-partner:61671
TEST=Build hammer with CONFIG_CMD_FLASH command, so that write protection
can be checked with flasherase/flashwrite.
TEST=On hammer (stm32f072):
flashinfo => RO+RW not protected
flashwp true; reboot => only RO protected
flashwp rw; reboot => RO+RW protected
flashwp norw; reboot => only RO protected
TEST=On reef (npcx):
deassert WP, flashwp false; flashinfo => RO+RW not protected
flashwp true => only RO protected
reboot => only RO protected
flashwp rw => RO+RW protected
reboot => only RO protected
Change-Id: Iec96a7377baabc9100fc59de0a31505095a3499f
Reviewed-on: https://chromium-review.googlesource.com/430518
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Shorten certain long prints and reduce the precision of timestamp prints
when CONFIG_CONSOLE_VERBOSE is undef'd.
BUG=chromium:688743
BRANCH=gru
TEST=On kevin, cold reset the EC, boot to OS, and verify cros_ec.log
contains all data since sysjump and is < 2K bytes (~1500 bytes).
Change-Id: Ia9390867788d0ab3087f827b0296107b4e9d4bca
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/438932
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
If PD is negotiated and the EC is reset, a source partner port will
continue providing its negotiated voltage (eg. 20V in the case of
zinger). Ensure the partner port is in a known state by providing Rp
for a brief period after resetting to RO.
BUG=chrome-os-partner:62281
BRANCH=Reef
TEST=On kevin, attach zinger, wait for 20V negotiation, and press F3 +
power to cause EC reset. Verify VBUS drops to approximately 0V before
going back to 5V / 20V. Verify the same with kevin OEM charger as well.
Also verify kevin boots with no battery.
Change-Id: I1b769a76188d8a9a515388996fbc4cb3d46840a5
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433367
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Current fast charge assumes only one battery voltage threshold range for
charger profile override. However we have multiple battery voltage
threshold ranges for few batteries hence added a code which can consider
multiple battery threshold ranges and choose respective charge profile.
BUG=chrome-os-partner:62653
BRANCH=none
TEST=Manually tested on Electro. Manipulate smp_cos4870 & sonycorp
battery voltage & temperature ranges and observed correct charge
profile is selected.
Change-Id: Icddc047e608cc8f63cd0c19be716e0f7908ca715
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/438804
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch adds a host command to get PD chip info.
For PS8751, tcpci_get_chip_info will fail if the chip is in
low power mode. It can be woken up by reading a random register
first then wait for 10ms.
This code doesn't have the wake-up read to avoid 10ms delay.
Instead, we call this function immediately after the chip is
initialized because it'll gurantee the chip is awake.
Once it's called, the chip info will be stored in cache, which
can be accessed by tcpc_get_chip_info without worrying about
chip states.
localhost ~ # ectool pdchipinfo 0
vendor_id: 0xaaaa
product_id: 0x3429
device_id: 0xad
fw_version: 0x15
localhost ~ # ectool pdchipinfo 1
vendor_id: 0x1da0
product_id: 0x8751
device_id: 0x1
fw_version: 0x37
BUG=chrome-os-partner:62383
BRANCH=none
TEST=ectool pdchipinfo 0/1. make buildall
Change-Id: I3f1667d00ce1826936d90882ada1df6ed6b0ea37
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/433166
Add driver for acc sensor ST lis2dh/lis2dh12
Support interrupt management for FIFO watermark
Starting to share common code with other devices
like lsm6dsm/lsm6dsl (acc/gyro) or new lis2mdl (mag)
TODO: Add all embedded functions support (click,
tap and so on)
BUG=none
BRANCH=master
TEST=Tested on discovery BOARD with sensor connected on
EC i2c master bus. Added motion sense task on discovery
board task list, added gpio info in board configuration
file and tested with motion sense console commands. Data
for acc seems ok: can successfully change ODR and
full scale range. Also FIFO and interrupt tested
Device tested is lis2dh (lis2dh12 simply differs for low
pin count but share the same registers)
Change-Id: I16abeac3f139a604094b38d8d8b857a62c93a242
Signed-off-by: Mario Tesi <mario.tesi@st.com>
Reviewed-on: https://chromium-review.googlesource.com/412700
Commit-Ready: mario tesi <mario.tesi@st.com>
Tested-by: mario tesi <mario.tesi@st.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
If CONFIG_SPI_NOR_SMART_ERASE is defined will read the sector/block
to be erased first and only initiate the erase operation if not
already in an erased state. The read operation (performed in
CONFIG_SPI_NOR_MAX_READ_SIZE chunks) is aborted early if a
non "0xff" byte is encountered.
Reduced erase time of a mostly erased EEPROM from 44s to 20s (16MB
Winbond part) / 1m22s to 40s (32MB Macronix part) @24MHz.
BUG=None
BRANCH=None
TEST=Built all targets. Successfully flashed various EEPROM images.
Change-Id: I369b1fcf72140663b8dbce5a469ebad27f7571ec
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/437988
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
If both nvmem partitions are corrupted, then nvmem_reinitialize() will be
called and commits must be enabled prior to this so that
nvmem_release_cache() succeeds.
BRANCH=none
BUG=chrome-os-partner:62531
TEST=On Reef after a successful boot, corrupt nvmem partitions using
the following console commands:
flasherase 0x7d000 0x3000
flasherase 0x3d000 0x3000
Then reboot via H1 console and verified via the console that the nvmem
partitions were reconfigured.
nvmem_find_partition:302 partiton 0 verification FAILED
nvmem_find_partition:302 partiton 1 verification FAILED
[0.025928 nvmem_find_partition: No Valid Partition found, will
reinitialize!]
[0.127752 Active Nvmem partition set to 1]
Then verfied that TPM was functional and the system booted booted into
the kernel. Without this CL this set of actions would always result in
going in to recovery mode due to TPM failure.
Change-Id: If1691b179e19cb37f0fc6ba893219dd8c02f2cf5
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/439368
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The cr50 needs to be aware of the power state of the system and of the
moment when the AP is reset, because this is when the TPM needs to be
reset too.
Arm and x86 platforms provide different hints in these cases.
In case of x86 there is a single signal cr50 can rely on: PLT_RST_L.
This active low signal is asserted when the system is going into any
power state deeper than s0ix. The cr50 can fall into deep sleep when
PLT_RST_L is asserted, and has to wake up and reset the TPM when this
signal is deasserted. There could be other wake triggers, but the tpm
should not be reset unless PLT_RST_L is inactive. It is also important
not to fall into deep sleep when PLT_RST_L is pulsed to reboot the
system.
In case of ARM there are two separate signals. Deasserting SYS_RST_L
signal is the trigger to reset the TPM, The GPIO_DETECT_AP going low
for a duration of time is the indication of the AP going into some
kind of sleep mode. The ARM case requires more clarification.
This adds run time configuration of the the sleep state control input.
Once the input turns low, the CHIPSET_SHUTDOWN signal is sent and deep
sleep mode is enabled. Again, this will require adjustment for ARM
platforms.
The wake from deep sleep state is controlled by the wake pins as
before, but by level instead of edge. This makes sure that in case the
trigger for deep sleep goes away while deep sleep preparation is under
way, the device resumes immediately instead of getting stuck missing
the edge.
The TPM_RST_ input is now triggering interrupts on deassertion
- this is the moment when the TPM needs to be reset. The ISR is being
renamed accordingly.
The processing previously happening inside the ISR is being moved into
a deferred function running on the hooks task context.
There is no need to invoke TPM reset related functions from the PMU
wake up ISR anymore.
BRANCH=none
BUG=chrome-os-partner:59007
TEST=as follows:
1. make buildall -j succeeds
2. started on Reef, still in progress after 100 iterations, early to
call
suspend_stress_test --suspend_min 40 --suspend_max 45 \
--wake_max 15 wake_min 10
(note that reef does not fall into s3 any more, so the test does not
verify H1 deep sleep)
3. modified the target to fall into s3 during the test and
successfully repeated it for 100 iterations
4. tried battery disconnect a few times and observe successful boot.
Change-Id: Ica06ec0d363b53eede3be327404ff5807fa3a610
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436865
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
All boards have been transitioned to charge_state_v2.c
So charge_state_v1.c, HOOK_CHARGE_STATE_CHANGE, and
CONFIG_CHARGER_TIMEOUT_HOURS can be removed
BUG=chrome-os-partner:36272
TEST=make -j buildall
BRANCH=none
Change-Id: I3f20c5198ea75185f9894deb792575a1be31432a
Reviewed-on: https://chromium-review.googlesource.com/435467
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The INAs are only used for development and testing
purposes. Therefore, the 3.3V rail to the INAs is off by default and
the I2Cm module is not enabled. Enabling INA power and connecting the
I2Cm module was done at the beginning of each USB to I2C request. The
problem with this approach is that INA measurments didn't always
succeed due to not enough time for the INAs to initialize.
Rather than add some arbitrary delay, it is better to tie the INAs to
when rdd is attached/detached. It is only when rdd is attached that
the INAs will be accessed, so there is no need to enable/disable for
each individual I2C transaction.
This CL ties the enabling/disabling of the INA and I2Cm module to the
rdd state. This change makes the previous use of
usb_i2c_board_enable() and usb_i2c_board_disable() obslete.
BRANCH=none
BUG=chrome-os-partner:62375
TEST=manual
Connect servo with suzyq connected:
sudo servod -p 0x5014 -b eve -c eve_r0_inas.xml
Then execute single INA reads dut-control pp3300_dx_edp_mv and verify
that it returns meaningful numbers. Without this CL single reads via
dut-control would always return 0.
Change-Id: I799552bfd0701efd1828a0d720ac2a6cedee5ca1
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/436864
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
