TCPM will retry sending of source caps on failure and retrying in TCPC
will cause us to violate PD_T_SEND_SOURCE_CAP.
BUG=None
TEST=Attach servo_v4 to twinkie, verify source caps are sent in ~100ms
intervals and not in bursts of four.
BRANCH=servo_v4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I3264e5578afbde7b9d2c003b6744974329a253d4
Reviewed-on: https://chromium-review.googlesource.com/719729
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The new console command uses the alternative TPM command execution
path to generate the RMA challenge and also allows to verify the RMA
authentication code.
This patch also limits the rma challenge/auth code printouts to images
supporting debug features (built with CR50_DEV=1), and limits the code
included when building test images.
BRANCH=cr50
BUG=b:67008109
TEST=while running TCG tpm test ran the new console command multiple
times, observed all tests pass and the command always succeed.
Change-Id: I9ca3e86040d8adbdbe70f33cf2b317075f823f36
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699524
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The TPM task provides access to various cryptographic functions which
require huge stack size. Some other contexts might require to execute
these functions, but no other task in the system has enough stack.
The suggested solution is to create an alternative TPM task execution
path, where the command comes not from the communications interface
(SPI or I2C), but from another task in the system.
An interface function is created to allow a single task to pass the
command to the TPM task. The task requesting the alternative execution
path creates the command context, sends an event to the TPM task to
alert it to the presence of the command and then polls the flag
indicating that the TPM task has completed execution of the command.
BRANCH=cr50
BUG=b:67008109
TEST=tested after applying the next patch (add console command for
generating RMA auth challenge).
Change-Id: I168489a5fbb4a3e1d718198812019116738b2f61
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699523
The decision on whether to ramp (and how high) depends on the quirks of
charger identification, so move the decision out of board, into the
drivers that implement usb_charger.
Also, rename CONFIG_CHARGE_RAMP to CONFIG_CHARGE_RAMP_SW, to better
contrast with the existing CONFIG_CHARGE_RAMP_HW.
BUG=None
TEST=Manual on kevin, verify ramp occurs when port plugged into Z840
workstation.
BRANCH=None
Change-Id: I5b395274133837a18a4f4ac34b59b623287be175
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/702681
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Boards that use charge_manager have identical implementations of
typec_set_input_current_limit() and pd_set_input_current_limit(), so
move these functions to charge_manager.
BUG=b:67413505
TEST=`make buildall -j`, also verify that fizz continues to power-on and
boot AP, in both protected and unprotected mode, with barrel jack power
and with zinger.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I99a5314d02c4696db944c0f8ac689405f4f1f707
Reviewed-on: https://chromium-review.googlesource.com/701412
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CONFIG_CASE_CLOSED_DEBUG (CCD functionality implemented by EC) is no
longer used in conjunction with CONFIG_USB_POWER_DELIVERY, and the
common routines are only used by one board.
BUG=chromium:737755
BRANCH=None
TEST=`make buildall -j`
Change-Id: Idc3d2fccef6cbec2af786cef634d752a02a0e859
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/656315
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
A couple of bugs have crept in with the latest series of patches:
- the board ID value endianness does not have to be changed
- the test RMA server public key value is wrong
BRANCH=cr50
BUG=b:67007905
TEST=the generated challenge is now accepted by the server, and the
generated auth code matches between the server and the Cr50.
Change-Id: I18f413ab0bcc14d9cc50b115ac3784fdfcd5851c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/700798
Reviewed-by: Michael Tang <ntang@chromium.org>
The new vendor command operates in two modes: when received with a
zero size payload, it triggers the Cr50 to generate a new RMA
authentication challenge and the expected authentication code value.
When receive with the payload, it compares the received payload with
the pre-calculate authentication code, and returns to the host the
comparison result (passed/not passed).
A care is taken not to accept payload until at least there is a valid
calculated auth code present (to avoid reporting a match on a payload
of all zeros).
Test config needed to be modified to allow compiling of the ccprintf
wrapper.
BRANCH=cr50
BUG=b:37952913
TEST=with the rest of the patches applied observed expected behavior
of generating challenge/response and verifying the auth code.
Change-Id: I30638b0ceef68830565f222dd1f4af17cfc8d7ef
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690992
Different devices could have different sized unique device IDs. Let's
just use the IDs as is if they are no larger than the
rma_challenge:device_id field, or the first 8 bytes of the HMAC_sha256
value of the unique device ID, where the unique device ID is used both
as the key and the payload.
The server expects the board ID field in big endian format, let's swap
it before calculating the RMA auth challenge.
The test's server side implementation needs to be also adjusted.
BRANCH=cr50
BUG=b:37952913
TEST=make buildall -j passes. With the rest of the patches applied RMA
authentication process generates sensible values.
Change-Id: Ia1fbf9161e01de30a2da8214258008f6e5f7d915
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690991
Reviewed-by: Michael Tang <ntang@chromium.org>
On Cr50 the crypto library has a slightly different API, as indicated
by the presence of the CONFIG_DCRYPTO configuration option.
This patch provides a wrapper which allows to calculate a SHA256 HMAC
hash using either underlying crypto API.
BRANCH=cr50
BUG=b:37952913
TEST=make buildall -j
Change-Id: Ibb8c60e50139fd5506a4dd5f2ed19653c68af8cb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690440
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Hash command expects second parameter to be either
abort, RO, RW. If not then exit the function by
displaying error message instead of calculating hash.
BUG=NONE
BRANCH=NONE
TEST=On EC console 'hash help' should display error message
with usage info.
Change-Id: I4fcad97ce0da1cd48a458de1c659aa3c6b2a60b9
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/691436
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Fizz EC verifies RW by itself and jumps to RW before AP boots.
If this fails, the system needs recovery. Since EC isn't
capable of showing any info on a display, we use the power
LED to inform the user.
BUG=b:66914368
BRANCH=none
TEST=Make Fizz fail RW verification. Observe LED illuminates
in red.
Change-Id: Ia07de60a316b40e74b1917903996d78750b4ae43
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/683218
This patch makes the LED blink to alert the user when there is
not enough power to boot the system.
This patch also changes minimum boot power to 50W. It's common
for all SKUs.
BUG=b:37646390
BRANCH=none
TEST=Power Fizz with 15W, 45W, 60W chargers. Verify LED blinks as
expected.
Change-Id: If269897f5022f6cba80f37ce03e2315cfb2cf504
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/682876
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For the Host Command vboot hash EC_VBOOT_HASH_GET case,
if the input parameter offset and size is 0 then change
offset to data_offset to obtain the latest hash value.
Else retain the offset to get the hash value at offset.
BUG=b:66957716
BRANCH=NONE
TEST=On Soraka, ectool echash commands
(RO, RW) should result in hash information.
Change-Id: Ife17d35b0dfeecb5ec799c9ed722ae48dbec5b5b
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/685738
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
To implement rtc driver for some ec chips, we
need to convert between calandar date and seconds
(since epoch time, 01-01-1970 00:00:00).
Sicne these functions are HW-independent, let's add
common/rtc.c, include/rtc.h, and unit test for this.
BUG=b:63908519
BRANCH=none
TEST=make buildall test -j
Change-Id: Icb1e768d2b3674d5225b83e09475e984eb104d06
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/666985
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
Currently we are assuming batt_mode would never be zero, but that is not
always true. Some battery do report zero for batt_mode(bob for example).
So everytime the batt_mode_cache been set to zero, the virtual_battery
would consider it uninited, and tries to refresh the next time.
Use -1 as uninited batt_mode_cache to avoid that.
BUG=b:66555246
BRANCH=gru
TEST=Check on bob, the battery level is correct.
Change-Id: Ieb7ec9403f69a6b5bca93c6682ec6117fe95fe1e
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/678135
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The WebUSB specification defines a specific Platform Descriptor in the
Binary Object Store:
https://wicg.github.io/webusb/#webusb-platform-capability-descriptor
This descriptor provides a special 'Landing page' URL to the host
browser and associated privileges for it.
Bump the USB version for BOS descriptors to 2.1 to be compatible with
Chrome implementation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BUG=none
BRANCH=twinkie
TEST=manual: on Twinkie (chip/stm32) and HG proto2 (chip/g), enumerate
WebUSB descriptors with lsusb and connect to a WebUSB page in Chrome
R61+.
Change-Id: I7211ab554f4a6c156c1e8e79a3d9f0d6644217c6
Reviewed-on: https://chromium-review.googlesource.com/664813
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The dump_charge_state (chgstate console command) is quite large,
and may get truncated, let's add 2 cflush at approximately
each third of the output.
BRANCH=none
BUG=b:66575472
TEST=On wand, type chgstate in EC console
Change-Id: Iaa87a6a77b9b6edb0bd8235a87297f8d63fe3085
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/678755
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
update_dynamic/static_battery_info update information in the memmap
shared with the host. When there is not host, these functions
cannot do anything.
The battery information will, eventually, have to be passed to
host (through lid EC), but this will be implemented later.
BRANCH=none
BUG=b:66575472
TEST=make BOARD=wand -j
Change-Id: I1640bb0c5a9eb242183b957ccbef4d4999112160
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/678754
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT Rp is applied when neither port
is a source, so apply it at boot to be consistent.
BUG=chromium:766814
BRANCH=gru
TEST=On kevin, verify 3A Rp is applied to both ports at boot.
Change-Id: Ib62a96063783e8ef9ac9240800f445fa9e5a59af
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/675845
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Chromebox ECs performs EFS: verifying firmware before the AP boots.
This patch updates host commands which are required for the EFS.
When EC_REBOOT_FLAG_SWITCH_RW_SLOT is specified, EC_CMD_REBOOT_EC
changes the active slot before it reboots the system.
BUG=b:65264494
BRANCH=none
TEST=On Fizz, verify:
1. RW_B is old and updated by soft sync. RW_B is activated and
executed after reboot. System continues to boot to OS.
2. RW_A is old and updated by soft sync. RW_A is activated and
executed after reboot. System continues to boot to OS.
Change-Id: I08050c985ce0b27b30cb842e6b5b4660f32e5211
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/648450
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When EFS finds the active slot is invalid, it tries the other slot.
This patch makes the other slot active so that the following boots
will try the other slot first.
This patch also replaces enum flash_rw_slot with system_image_copy_t.
The new APIs are therefore renamed from *_slot to *_copy. Basically,
this makes vboot see slots as a conceptual place instead of physical
spaces bound to flash storage.
BUG=b:65028930
BRANCH=none
TEST=On Fizz, verify:
1. RW_B is old and updated by soft sync. RW_B is activated and
executed after reboot. System continues to boot to OS.
2. RW_A is old and updated by soft sync. RW_A is activated and
executed after reboot. System continues to boot to OS.
Change-Id: Icf97da13e651e7a931b9d507052b9422566eb16c
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/648449
This will be used by the updater to first check that the touchpad
FW on AP side matches the one for which we stored hashes on EC
side.
This guarantee that we do not accidentally try to flash an
incorrect FW, which would render the touchpad non-functional.
BRANCH=none
BUG=b:63993173
TEST=make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \
BOARD=hammer -j
TEST=./usb_updater2 -t
includes output of
sha256sum A459C-1211_ForGoogleHammer_3.0.bin
Change-Id: Id30ab2d7c7d7e2d0f25cc893f685d218c44c022e
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/641736
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Make use of the generated touchpad firmware hashes to validate
the blocks before writing them to the touchpad.
BRANCH=none
BUG=b:63993173
TEST=make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \
BOARD=hammer -j
TEST=./usb_updater2 -p SA459C-1211_ForGoogleHammer_3.0.bin works
TEST=./usb_updater2 -p SA459C-1211_ForGoogleHammer_4.0.bin fails
Change-Id: If5d2be57b63e16ee81aa9acaf840c5084f9b92de
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/616371
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Based on the passed TOUCHPAD_FW parameter to the make command, the
build system generates hashes for the touchpad FW.
To generate the hashes, gen_touchpad_hash splits the touchpad FW
in blocks of CONFIG_UPDATE_PDU_SIZE, that are hashed individually
(SHA-256), and then stored in the EC image.
This will allow the USB updater code to verify the integrity of
the touchpad firmware being flashed.
When no FW is provided, zeros are output, which do not match
any valid data.
BRANCH=none
BUG=b:63993173
TEST=make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \
BOARD=hammer -j
TEST=Using variations of
make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_3.0.bin \
BOARD=hammer -j
make TOUCHPAD_FW=SA459C-1211_ForGoogleHammer_4.0.bin \
BOARD=hammer -j
make BOARD=hammer -j
Check that TPHASH touchpad_fw_hash.h is only regenerated when
the parameter changes.
Change-Id: Ie347270aa9c00342de13489c9422e45e681b94c2
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/615321
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We use rand to get timestamp counter low word and do random test
(test_dev = rand % i2c_test_dev_used).
But we will get a negative index (test_dev) if low word larger than
0x80000000 and cause the array to access the wrong locations and
trigger an exception.
This change also fix following error:
error: i2c_s_test may be used uninitialized in this function
[-Werror=maybe-uninitialized]
BRANCH=none
BUG=none
TEST="forcetime 0 0x80000000" then "i2ctest", no exception triggered.
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Change-Id: Ia2f5a2ff034a6b7b96f7bd4f3b42bf5645a05aed
Reviewed-on: https://chromium-review.googlesource.com/663110
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
This patch adds USB_CHG_TYPE_DEDICATED to enum usb_chg_type. It's
for dedicated AC adapters like a barrel jack adapter used for Fizz.
BUG=b:65591971
BRANCH=none
TEST=make buildall
Change-Id: Ib883c97eb5e468753c73453d7dedd228547ae025
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/665327
Reviewed-by: Shawn N <shawnn@chromium.org>
This patch gives the highest priority to dedicated chargers. It
means if a dedicated power supply is being connected, other power
supplies such as USB-C adapters will not be recognized as a new
charger.
BUG=b:65059574
BRANCH=none
TEST=Boot Fizz on BJ adapter. Verify plugging in Type-C adapter
doesn't shut down the system.
Change-Id: Ie49b128ae64f917a227f9081148565a3f5356212
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/655638
Reviewed-by: Shawn N <shawnn@chromium.org>
1. Add a new config option CONFIG_PORT80_PRINT_IN_INT which is
disabled by default to disable printing of port80 messages in
interrupt context.
2. If CONFIG_BRINGUP is defined, redefine CONFIG_PORT80_PRINT_IN_INT
to enable printing of port80 messages in interrupt context for boards
that are in bringup phase.
3. If print_in_int is disabled, add a deferred call to dump port80
buffer to EC console 4 seconds after the last port80 message is
received.
BUG=b:64196191
BRANCH=None
TEST=Verified following:
1. make -j buildall
2. Port80 messages are not printed by default on Soraka
3. Port80 buffer is dumped 4 seconds after last port80 message, if
BIOS is stuck for 4 seconds, in recovery mode and when reboot from AP
console.
4. Boot time on soraka went down from ~1.59seconds to ~1.45 seconds in
EC reboot case (savings of ~140ms).
Change-Id: I9aee0987765f905b4ac49d04ffc54d71ee3a04f9
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/661880
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Messages generated using the CPRINTS macro include a newline in the
end by design, no need to explicitly include it in the message.
BRANCH=cr50
BUG=none
TEST=verified that the message is printed without the extra newline
Change-Id: I01994bcb95c78e2deaa2dc3617bea9ca8a6d1381
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/663668
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The modified CRC8 implementation didn't detect some errors. For
example, using the modified CRC8: CC5QQLALU and DC5QQLALU calculates
to the same value.
BUG=b:37952913
BRANCH=none
TEST=make buildall
Used online CRC-5-USB calculator to test several values against
this implementation.
Signed-off-by: Sam Hurst <shurst@chromium.org>
Change-Id: I5a17941e25691872a25b41525f65f36e2ed1d4fa
Reviewed-on: https://chromium-review.googlesource.com/660812
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Michael Tang <ntang@chromium.org>
Chromebox ECs performs EFS: verifying firmware before the AP boots.
This patch updates host commands which are required for the EFS.
The change includes:
* Update EC_CMD_FLASH_REGION_INFO to accept EC_FLASH_REGION_UPDATE
* Update EC_CMD_VBOOT_HASH to accept EC_VBOOT_HASH_OFFSET_UPDATE
When EC_FLASHS_REGION_UPDATE is specified, EC_CMD_FLASH_REGION_INFO
returns the slot which currently is not hosting a running RW copy.
When EC_VBOOT_HASH_OFFSET_UPDATE is specified, EC_CMD_VBOOT_HASH
computs the hash of the update slot. This hash covers the entire
region, including the signature at the end.
This patch undefines CONFIG_CMD_USBMUX and CONFIG_CMD_TYPEC
for gru to create space.
BUG=b:65028930
BRANCH=none
CQ-DEPEND=CL:648071
TEST=On Fizz, verify:
1. RW_B is old and updated by soft sync. RW_B is activated and
executed after reboot. System continues to boot to OS.
2. RW_A is old and updated by soft sync. RW_A is activated and
executed after reboot. System continues to boot to OS.
Change-Id: I9ece907b764d07ce94054ba27996e048c665a80a
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/648448
If the PD state machine remains in SRC_DISCOVERY for an extended period
of time, it's likely that a non-PD USB peripheral is attached. In this
case, we don't need to inhibit deep sleep, since we're not likely to
receive PD packets.
This change will cause us to enter deep sleep slightly more
aggressively, not inhibiting deep sleep until source caps are received
or replied with GoodCRC by the port partner. We can accommodate
additional task latency up to this point, since the spec calls for
source caps to be sent up to 50 times before failure.
BUG=b:35582718,chromium:763002
TEST=Test with `sleepmask 1` on kevin.
- Go to S3 with USB-C flash drive plugged, verify `sleepmask` shows 0.
- Go to S3 with zinger + USB C flash drive plugged
- Unplug zinger, verify `sleepmask` shows 0.
- Plug zinger, verify PD negotiates to 20V @ 2A.
- Plug OEM kevin charger, verify same.
BRANCH=gru
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib8e1bc94bdbcfddea004d572edf1ccadc8c8c1ce
Reviewed-on: https://chromium-review.googlesource.com/655919
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>
Reworked suzy-q and suzy-qable all provide Rp, so there is no need for
special detection handling in S5. Also, CONFIG_USB_PD_QUIRK_SLOW_CC_STATUS
is no longer relevant, since we no longer take special action when VBUS
is seen without Rp.
BUG=chromium:737755
BRANCH=None
TEST=On kevin, verify reworked suzy-q and suzy-qable are detected in S5.
Also, verify zinger works in S5 on reef.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I50967bd6415d964a038b2e7d134374132eda11ec
Reviewed-on: https://chromium-review.googlesource.com/656067
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Servo / Suzy-Q related debugging methods is a big challenge
in factory especially after servo debug header is removed.
Expose some information to OS from EC will do a great help
for massive production.
+ expose charge/battery related state to ectool
1. chg_ctl_mode
2. manual_mode
3. battery_seems_to_be_dead
4. battery_seems_to_be_disconnected
5. battery_was_removed
6. disch_on_ac (learn mode state)
BUG=b:65265543
BRANCH=master
TEST=`ectool chargestate param 0x20000~0x20006 get correct state`
Change-Id: Ic2ed38e2eb9def01be29729fa1fe1959eb73fe43
Signed-off-by: Ryan Zhang <ryan.zhang@quanta.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/646412
Reviewed-by: Shawn N <shawnn@chromium.org>
Minor cleanup to the 'ccd help' command.
Add 'ccd get' as a clearer alias to print the config.
Change CONFIG_CMD_CCDDISABLE to CONFIG_CMD_CCD_DISABLE to indicate
that it's a sub-command for 'ccd'.
BUG=b:65407395
BRANCH=cr50
TEST=manual
ccd -> see clue for 'ccd help'
ccd help -> see 'get' command
ccd get -> prints config
ccd disable -> error (config option isn't defined by default)
Change-Id: Icbcaa178171ca948cfaae58ab1a1e73ab3d95243
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/654380
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
For historical reasons, CCD, reset, and power button control were
scattered around several files. Consolidate the code in more sensible
(in retrospect) places.
No functional changes, just moving code.
BUG=none
BRANCH=cr50
TEST=make buildall; boot cr50
Change-Id: Ic381a5a5d0627753cc771189aa377e88b81b155e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/653766
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
SYSTEM_IMAGE_RW_B hasn't been globally treated as a RW copy.
This change makes EC treat it also as a RW copy.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Iae5a9090cdf30f980014daca44cdf8f2a65ea1f2
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/656337
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Somewhere this lost a call to ccd_save_config(). Put that back.
Also, make it so 'ccd testlab' prints the current state.
BUG=b:65407184
BRANCH=cr50
TEST=manual with CR50_DEV=1 image
ccd oops
ccd testlab -> disabled
ccd testlab enable
ppresence (or tap power button)
ppresence
ppresence
ccd testlab -> enabled
reboot
ccd testlab -> enabled
ccd lock
ccd -> state=locked
ccd testlab open
ccd -> state=opened
ccd testlab disable
ppresence (or tap power button)
ppresence
ppresence
ccd testlab -> disabled
reboot
ccd testlab -> disabled
ccd testlab open -> acces denied
Change-Id: Iffdd84e8e0df3222b8762638b8a613f146c15f13
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/653765
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Previously, all CCD config commands were their own distinct commands.
This led to accidental side-effects when someone would type 'ccdlock'
thinking it would print the lock state when it would actually lock the
device.
Make them all sub-commands of 'ccd'. So, 'ccd lock', not 'ccdlock'.
Just 'ccd' by itself will print the current config.
No changes to how the sub-commands themselves work.
BUG=b:65407395
BRANCH=cr50
TEST=manual with CR50_DEV=1 build
gpioget # make sure GPIO_BATT_PRES_L=0
ccd help # prints help
ccd lock # lock, because CR50_DEV=1 builds start unlocked
ccd # locked, flags=0, all capabilities default
ccd pass # access denied (we're locked)
ccd reset # access denied
ccd set flashap always # access denied
ccd unlock
ccd # unlocked
ccd pass foo
ccd # flags=2 (password set when unlocked)
ccd set flashap always # access denied
ccd set uartectx unlesslocked
ccd # yes, uartectx permission changed
ccd lock
ccd unlock # fails without password
ccd unlock bar # wrong password
ccd unlock foo # busy
(wait 3 sec)
ccd unlock foo
ccd reset
ccd # no password, flags 0, capabilities all default
ccd open # requires physical presence; tap power or use 'pp'
ccd set uartgsctxecrx unlesslocked
ccd set batterybypasspp ifopened
ccd pass baz
ccd # password set, flag 0, ccdset changes worked
ccd unlock
ccd reset
ccd # uartgsctxecrx back to ifopened, password still set
ccd open baz # still requires physical presence
ccd set opennolongpp always
ccd lock
ccd open baz # no pp required
ccd set unlocknoshortpp unlesslocked
ccd lock
ccd open baz # short pp sequence required (3 taps)
ccd lock
ccd unlock baz # short pp sequence required
ccd open baz # pp not required
ccd set unlocknoshortpp always
ccd lock
ccd testlab open # access denied
ccd testlab enable # access denied
ccd unlock baz
ccd testlab open # access denied
ccd testlab enable # access denied
ccd open baz
ccd testlab enable # requires short pp
ccd # flags 1
ccd reset
ccd # no password, flags=1, caps all default
ccd lock
ccd testlab open
ccd # opened
ccd testlab disable # requires short pp; let it time out
ccd # still opened, flags=1
ccd lock
ccd oops # backdoor in CR50_DEV images to force-reset CCD
ccd # opened, flags=0, all defaults (yes, oops wipes out testlab)
ccd reset rma
ccd # flags = 0x400000, everything but GscFullConsole always
ccd reset # back to flags=0, all default
Change-Id: Ib2905cb7cbeb79a7f4d0fb44151bfd53af361e2e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/653719
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently, the Cr50 state machines (EC, AP, RDD, bitbang, etc.) manage
their own enabling and disabling of the ports (UART, SPI, etc.) This
is tricky because the rules for when ports should be enabled are
non-trivial and must be applied in the correct order. In additionl
the changes all need to be serialized, so that the hardware ends up in
the correct state even if multiple state machines are changing
simultaneously.
Consolidate all of that into chip/g/rdd.c. The debug command for it
is now 'ccdstate', which just prints the state machines. This will
allow subsequent renaming of the 'ccdopen', etc. commands to 'ccd
open', etc.
Also include UART bit-banging into that state which must be
consistent. Previously, it was possible for bit-banging to leave UART
TX connected, instead of returning it to the previous state.
Use better names for CCD config fields for UART. I'd had them backwards.
BUG=b:62537474
BRANCH=cr50
TEST=manual, with a CR50_DEV=1 image
1) No servo or CCD
Pull SERVO_DETECT low (disconnected)
Pull CCD_MODE_L high (disabled)
Pull EC_DETECT and AP_DETECT high (on)
Reboot. RX is enabled even if cables are disconnected so we buffer.
ccdstate -> UARTAP UARTEC
Pull EC_DETECT low.
ccdstate -> UARTAP
Pull EC_DETECT high and AP_DETECT low.
ccdstate -> UARTEC
Pull AP_DETECT high.
ccdstate -> UARTAP UARTEC
2) Servo only still allows UART RX
Pull SERVO_DETECT high (connected).
ccdstate -> UARTAP UARTEC
3) Both servo and CCD prioritizes servo.
Pull CCD_MODE_L low (enabled).
ccdstate -> UARTAP UARTEC
Reboot, to make sure servo wins at boot time.
ccdstate -> UARTAP UARTEC
Bit-banging doesn't work when servo is connected.
bitbang 2 9600 even -> superseded by servo
bitbang -> disabled
ccdstate -> UARTAP UARTEC
4) CCD only allows more ports and remembers we wanted to bit-bang
Pull SERVO_DETECT low.
ccdstate --> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate --> UARTAP+TX UARTEC+TX I2C SPI
Reboot and see we don't take over servo ports until we're
sure servo isn't present.
ccdstate --> UARTAP UARTEC (for first second)
ccdstate --> UARTAP+TX UARTEC+TX I2C SPI (after that)
5) Bit-banging takes over ECTX
bitbang 2 9600 even
bitbang -> baud rate 9600, parity even
ccdstate -> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate -> UARTAP+TX UARTEC+TX I2C SPI
6) Permissions work. Allow easy access to full console and ccdopen:
ccdset OpenNoTPMWipe always
ccdset OpenNoLongPP always
ccdset GscFullConsole always
Default when locked is full AP UART EC RO, no I2C or SPI
ccdlock
ccdstate -> UARTAP+TX UARTEC
No EC transmit permission means no bit-banging
bitbang 2 9600 even
bitbang -> disabled
ccdstate -> UARTAP+TX UARTEC
But it remembers that we wanted to
ccdopen
ccdstate -> UARTAP+TX UARTEC+BB I2C SPI
bitbang 2 disable
ccdstate -> UARTAP+TX UARTEC+TX I2C SPI
Try turning on/off permissions
ccdset UartGscTxECRx always
ccdlock
ccdstate -> UARTAP+TX UARTEC+TX
No read means no write either
ccdset UartGscRxECTx ifopened
ccdlock
ccdstate -> UARTAP+TX
ccdopen
ccdset UartGscRXAPTx ifopened
ccdlock
ccdstate -> (nothing)
Check AP transmit permissions too
ccdopen
ccdset UartGscRxAPTx always
ccdset UartGscTxAPRx ifopened
ccdlock
ccdstate -> UARTAP
Check I2C
ccdopen
ccdset I2C always
ccdlock
ccdstate -> UARTAP I2C
SPI port is enabled if either EC or AP flash is allowed
ccdopen
ccdset flashap always
ccdlock
ccdstate -> UARTAP I2C SPI
ccdopen
ccdset flashec always
ccdset flashap ifopened
ccdlock
ccdstate -> UARTAP I2C SPI
Back to defaults
ccdoops
Change-Id: I641f7ab2354570812e3fb37b470de32e5bd10db7
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/615928
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently, only usb_pd_protocol.c cares about the actual ccd mode
(disabled/partial/enabled). Everything else just cares whether it's
enabled or not. So promote the boolean ccd_is_connected() from
board/cr50 up to chip/g, and rename it to ccd_ext_is_enabled() to
match the new nomenclature (since 'CCD' itself is now too overloaded).
This will make it easier to handle CCD state directly in board/cr50
after we split it from common/case_closed_debug.c
BUG=none
BRANCH=cr50
TEST=make buildall; boot cr50; make sure USB endpoints still work
Change-Id: Ic3df7467bfe29f1c5d7060cac1309a1f0e090d9e
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/648212
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
