There might be more than one place that will use very similar codes in
CL:542716 (usb_i2c.c). To avoid unnecessary duplication of code, we fold
the logic into i2c_xfer(). With config enabled (illustrated in this CL),
i2c_xfer() will support large reading. An early prototype of potential
usage is demostrated in CL:781300.
BRANCH=none
TEST=For CONFIG_I2C_XFER_LARGE_READ:
With proprietary software on slave: ./touchpad_updater -d
TEST=For usb_i2c regression:
./touchpad_updater still works (where the reading is less than 255)
TEST=For generic EC regression test:
On poppy EC (With CONFIG_I2C_XFER_LARGE_READ defined)
(1) Prevent override of update
/usr/share/vboot/bin/set_gbb_flags.sh 0xa39
(2) flashrom -p ec -w ec_binary_contains_this_CL.bin
(3) ectool reboot_ec cold
(4) "ectool version" verified that both RO/RW/Build info is local.
(5) Test with a type-C DP dongle on DELL 2408WFP.
(6) Plug-in type-C charger and external display still works.
(7) Confirmed that battery is charging.
(7) "ectool battery" reads same data (for fixed field) as before.
(8) "ectool usbpdpower", confirmed charger info displayed as before.
(9) "ectool usbpd 0", confirmed content exactly as before.
(10) For Gyro. Verify under Arc++
Using App: com.gamma.bubblelevel, works the same as before.
(11) For Accelerometers. Verify under Arc++
Using App: com.innoventions.sensorkinetics,
small movement's charts looks as expected.
TEST=For generic EC regression test:
On Caroline EC (Without CONFIG_I2C_XFER_LARGE_READ defined).
Details in CL:810332
BUG=b:63993891
Change-Id: I654868945fa535e784800177d54eb2d9803f5249
Signed-off-by: Chun-Ta Lin <itspeter@google.com>
Reviewed-on: https://chromium-review.googlesource.com/788479
Commit-Ready: Chun-ta Lin <itspeter@chromium.org>
Tested-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The SN5S330 has support for detecting when Vbus is present on a port.
This commit simply adds an API to query the PPC.
BUG=None
BRANCH=None
TEST=`make -j buildall`.
TEST=Flash a board with the SN5S330, with some extra code, verify that
Vbus can be detected with this API.
Change-Id: I45bf7ff24bcdc447efe12932f51f8094108e29d5
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/791502
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Unified Host Event Programming Interface (UHEPI) enables a unified host
command EC_CMD_PROGRAM_HOST_EVENT to set/get/clear different host events.
Old host event commands (0x87, 0x88, 0x89, 0x8A, 0x8B, 0x8C, 0x8D, 0x8E,
0x8F) is supported for backward compatibility. But newer version of
BIOS/OS is expected to use UHEPI command (EC_CMD_PROGRAM_HOST_EVENT)
The UHEPI also enables the active and lazy wake masks. Active wake mask
is the mask that is programmed in the LPC driver (i.e. the mask that is
actively used by LPC driver for waking the host during suspended state).
It is same as the current wake mask that is set by the smihandler on host
just before entering sleep state S3/S5. On the other hand, lazy wake masks
are per-sleep masks (S0ix, S3, S5) so that they can be used by EC to set
the active wake mask depending upon the type of sleep that the host has
entered. This allows the host BIOS to perform one-time programming of
the wake masks for each supported sleep type and then EC can take care
of appropriately setting the active mask when host enters a particular
sleep state.
BRANCH=none
BUG=b:63969337
TEST=make buildall -j. And verfieid following scenario
1). Verified wake masks with ec hostevent command on S0,S3,S5 and S0ix
2). suspend_stress_test with S3 and S0ix
3). Verified "mosys eventlog list" in S3 and s0ix resume to confirm
wake sources (Lid, power buttton and Mode change)
4). Verified "mosys eventlog list" in S5 resume to confirm wake sources
(Power Button)
5). Verified above scenarios with combination of Old BIOS + New EC and
New BIOS + Old EC(making get_feature_flags1() return 0)
Change-Id: Idb82ee87fffb475cd3fa9771bf7a5efda67af616
Signed-off-by: Jenny TC <jenny.tc@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/576047
Commit-Ready: Jenny Tc <jenny.tc@intel.com>
Commit-Ready: Jenny Tc <jenny.tc@intel.corp-partner.google.com>
Tested-by: Jenny Tc <jenny.tc@intel.com>
Tested-by: Jenny Tc <jenny.tc@intel.corp-partner.google.com>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
This commit introduces a driver framework for power path controllers.
It provides some common PPC APIs as well as allowing a board to use
multiple different PPCs drivers/parts. This should make it easier to
add PPC drivers in the future.
BUG=None
BRANCH=None
TEST=`make -j buildall`
TEST=Flash zoombini; verify PPC works as expected.
TEST=Flash meowth; verify PPC works as expected.
Change-Id: Icfb99f384610590b431456cfd28d4aff18442cb2
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/807630
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Edward Hill <ecgh@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
After firmware update, cr50 toggles the EC's reset line, expecting
the system will boot. This isn't the case for Chromebox because it
sets AP_OFF flag on a clean shutdown (to restore the previous power
state after power loss & restore).
This patch adds EC_REBOOT_HIBERNATE_CLEAR_AP_OFF to EC reboot
command. It makes EC first clear AP_OFF then hibernate.
BUG=b:69721737
BRANCH=none
TEST=Verify Fizz reboot after cr50 update.
Change-Id: If3207d7284f244ca1adf0d516ef744dbc739a9c1
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/802632
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
CHARGE_MAX_SLEEP_USEC was originally set to 1 minute (i.e. equal to
POLL_PERIOD_VERY_LONG) in CL:191767. However, during re-factoring in
CL:193876 it got changed to 1 second as charge_state_v1 used this
value. Looking at the way CHARGE_MAX_SLEEP_USEC is used, value of 1
minute makes more sense because sleep_usec could be set to
POLL_PERIOD_VERY_LONG when device is off or suspended. With the
current logic in suspend/off state, sleep_usec is set to
POLL_PERIOD_VERY_LONG and immediately gets reset to
CHARGE_MAX_SLEEP_USEC in charger_task.
This change fixes the above behavior by defining CHARGE_MAX_SLEEP_USEC
as 1 minute. As a side-effect of this, we might not wake up early
enough in case of critical battery. Thus, check if we need to shutdown
on critical battery and adjust sleep time accordingly.
BUG=b:69695376
BRANCH=None
TEST=make -j buildall
Change-Id: Ieba7279dc4b02c3d64022c3c5ac09fb869a3632d
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/788181
Reviewed-by: Shawn N <shawnn@chromium.org>
Add a hook for CHIPSET_RESET to allow the EC to indicate if there is
any new panic info present. This helps coreboot to log EC panic info
in eventlog.
Also, update the hook priority for CHIPSET_RESET and HOOK_INIT to
HOOK_PRIO_LAST to allow the EC to first log any software panic before
it is checked.
BUG=b:65732924,b:69334392
BRANCH=None
TEST=Verified following:
1. Force panic_set_reason in EC on CHIPSET_RESET
2. reboot on AP console
3. mosys eventlog list shows "EC Event | Panic Reset in previous boot"
Change-Id: I77b49cd0b3bf05b10efc708e3d81af9ed0e3aa49
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/797911
Reviewed-by: Shawn N <shawnn@chromium.org>
Exitting the recovery insert screen requires pushing the volume up
and volume down keys simultaneously. Modifying the button command
to support multiple buttons.
BUG=b:69390675
BRANCH=None
TEST=button vup vdown 5000
button vdown vup 5000
button vup vdowne
button vdown vup
Make sure that the above command press and release both volume keys.
Make sure that there is a delay added into between presses/releases.
Change-Id: I65817ff6c9da8c422af3345b2d0878b52387b13e
Signed-off-by: Shelley Chen <shchen@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/783515
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
There are two different types of suspend states that are supported on
x86 platforms -- S3 and S0ix. When AP enters S3, the chipset state is
identified as CHIPSET_STATE_SUSPEND. On the other hand, when AP enters
S0ix, the chipset state is identified as CHIPSET_STATE_STANDBY. There
are several components within the EC e.g. charger state machine, usb
pd task, motion sense task that take actions based on the chipset
suspend state (and checked only for CHIPSET_STATE_SUSPEND until
now). In order to ensure that different EC components do not have to
worry about checking for all the different types of suspend states
that are supported, introduce a new combination
CHIPSET_STATE_ANY_SUSPEND which is a combination of
CHIPSET_STATE_SUSPEND(S3) and CHIPSET_STATE_STANDBY(S0ix).
BUG=b:69690699
BRANCH=None
TEST=make -j buildall. Ruben verified that with this change, EC power
consumption in S0ix drops from 7.85mW to 6.59mW on Soraka.
Change-Id: I599a0ea2fe2f39132764a6068fa77c3aea02affa
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/786919
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch lowers the priorities of other chargers so that dedicated
chargers are given the highest priority.
Dedicated chargers are adapters shipped with the device and do nothing
but being the power source. Thus, when they're connected, it should be
always used even if other suppliers offer more power.
BUG=b:38321259
BRANCH=none
TEST=make runtests
Change-Id: Ida862eb31c7f9ede36cade99f53645196b6a3f70
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/762339
Reviewed-by: Shawn N <shawnn@chromium.org>
The new vendor command takes the CCD state machine through necessary
transitions leaving it in the CCD locked state.
It succeeds only if user password is not set and CCD capabilities are
right, which is guaranteed to be the case after an RMA unlock.
BRANCH=cr50
BUG=b:68213540
TEST=tested using the modified gsctool utility.
Change-Id: Ic2cce34e74b1ff476841cfa1a99f50d6a947c315
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/784352
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This CL fixes two issues:
1. Host events are 1-based. So, if event0 is being requested to be set
in host_event_set_bit, nothing needs to be done.
2. To check if event needs to be set in upper 32-bit, check if the
event # is >32 and not >=32. (This issue was identified by coverity ID
179990).
BUG=b:69329196
BRANCH=None
TEST=make -j buildall
Change-Id: I062b82bdd30da28f62556ab4907a0f3bbf6d8126
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/791862
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Usually, the max current and supply voltage of dedicated chargers
are not known to the EC.
This patch adds EC_CMD_OVERRIDE_DEDICATED_CHARGER_LIMIT, which
allows the host to change the max current and supply voltage of the
dedicated charge port.
BUG=b:64442692
BRANCH=none
TEST=make runtests && buildall. Boot Fizz and let coreboot set
the adapter current and voltage.
Change-Id: I29b3f5762f8b316ca363c23e230530cdf4ca207a
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/769152
For now we guard charger-based VBUS voltage measurement
behind CONFIG_USB_PD_VBUS_DETECT_CHARGER.
But we should be able to measure VBUS voltage by charger
while detecting VBUS presence by other methods.
BUG=b:67991345
BRANCH=none
TEST=plug in guppy on Scarlet rev2, 'ectool usbpdpower' on console,
and see VBUS is measured as 4975mV
Change-Id: I94cada81159ea4b097001997e2444873ec2d8763
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/789910
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Originally, i2c passthru is limited to use I2C_XFER_SINGLE flag where
it can only read at most 255 bytes at a time. For application that
requires larger i2c bus reading, we change the flag setting and the
command protocol.
TEST=old ./touchpad_updater still works (previous protocol)
TEST=new ./touchpad_updater can get more than 500 bytes per transaction
TEST=Debug message only print when -d assigned.
./touchpad_updater -d
TEST=Manually change #define CONFIG_USB_I2C_MAX_READ_COUNT (1024 - 6)
to #define CONFIG_USB_I2C_MAX_READ_COUNT (1024 - 4) and trigger
POWER_OF_TWO assertion.
BRANCH=none
BUG=b:35587174, b:63993891
Change-Id: Id75b11ea49ba89bab8e18af24d47219030c778c5
Signed-off-by: Chun-Ta Lin <itspeter@google.com>
Reviewed-on: https://chromium-review.googlesource.com/542716
Commit-Ready: Chun-ta Lin <itspeter@chromium.org>
Tested-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
With the upcoming change to add a new command to get/set/clear host
events and masks, it seems to be the right time to bump up the host
events and masks to 64-bit. We are already out of available host
events. This change opens up at least 32 bits for new host events.
Old EC commands to operate on host events/masks will still deal with
lower 32-bits of the events/mask. On the other hand, the new command
being added will take care of the entire 64-bit events/masks. This
ensures that old BIOS and kernel versions can still work with the
newer EC versions.
BUG=b:69329196
BRANCH=None
TEST=make -j buildall. Verified:
1. hostevent set 0x4000 ==> Sets correct bit in host events
2. hostevent clear 0x4000 ==> Clears correct bit in host events
3. Kernel is able to query and read correct host event bits from
EC. Verified using evtest.
4. Coreboot is able to read correct wake reason from EC. Verified
using mosys eventlog list.
Change-Id: Idcb24ea364ac6c491efc2f8dd9e29a9df6149e07
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/770925
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Nearly every board had a buttons array defined in which its contents had
the standard volume buttons. This commit creates a single common
buttons array that can contain the standard volume buttons and recovery
buttons. If a board has volume up and down buttons, they can simply
define CONFIG_VOLUME_BUTTONS and it will populate the buttons array with
the standard definition. The buttons are active low and have a 30 ms
debounce period. Similiarly, if a board has a dedicated recovery
button, defining CONFIG_DEDICATED_RECOVERY_BUTTON will also populate the
buttons array with a recovery button.
BUG=chromium:783371
BRANCH=None
TEST=make -j buildall.
TEST=Flash a device with CONFIG_VOLUME_BUTTONS, verify pressing volume
buttons still work.
Change-Id: Ie5d63670ca4c6b146ec8ffb64d40ea9ce437b913
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/773794
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
At the end of the sensor initialization, all _init sensor routines set
the range to the default value from board.c file.
Put all the code in a single place, move it from sensor_common.c to
motion_sense.c.
BUG=none
BRANCH=none
TEST=compile
Change-Id: If89cf27c6438e0f215c193d68a480e027110174c
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/767610
Reviewed-by: Shawn N <shawnn@chromium.org>
The host should be able to retrieve proper TPM status and ID registers
while TPM reset is pending.
BRANCH=cr50
BUG=b:68012381
TEST=after appropriate fixes in coreboot the
firmware_Cr50ClearTPMOwner autotest does not fail any more
Change-Id: I245656ccb1c05e46715deb18bd5f8985c4197c52
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/775281
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
EC_IN_RW signal is used to determine if the switch to dev mode can be
safely made. However, EC_IN_RW needs the EC_RST_L line driven low in
order to be reset. In faft tests that utilize crosEcSoftrecPower
method, EC_RST_L is not being driven by servo to fix other test
failures related to keeping EC and AC reboots in sync.
This CL adds a new argument 'wait-ext' to the EC reboot command.
When this option is used, instead of the EC generating a reset via
it's system watchdog, it will wait 10 seconds for EC_RST_L to be
driven.
BUG=b:64603944
BRANCH=coral
CQ-DEPEND=I086687c3dd7591460099267880d56ab8265d2e4b
TEST=Ran "/usr/bin/test_that --board=coral <ip addr> firmware_DevMode"
mutliple times and verified that it passes. Previoulsy, this test
always fails when the EC is in RW before it starts. Also tested
platform_ServoPowerStateController_USBPluggedin and verified it passed.
Change-Id: I614f9156066d5719601ee43e29c7a064f9bba6e2
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/737524
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Support protection of regions that aren't aligned to a power of 2 by
using two MPU entries, and taking advantage of the sub-region feature.
Also protect code RAM from being overwritten, on parts that use external
storage.
BUG=chromium:782244
BRANCH=None
TEST=On kevin, call:
mpu_protect_data_ram();
mpu_protect_code_ram();
mpu_enable();
Verify that first call results in the following update_region params:
addr: 0x200c2000 size: 0xc01d
Decoded: Protect 24K region
Verify that second call results in the following params:
addr: 0x100a8000 size: 0xc021
Decoded: Protect 96K region
addr: 0x100c0000 size: 0xf01b
Decoded: Protect remaining 8K region
Also verify that writes to beginning and end of code ram region trigger
data access violation after enabling protection.
Also verify that sysjump fails.
Change-Id: Ieb7a4ec3a089e8a2d29f231e1e3acf2e78e560a1
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/757721
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We support touchpad-specific debugging feature over the USB update
protocol. This will be used to fetch raw data from the sensor,
without requiring to remove the write-protect screw.
BRANCH=none
BUG=b:63993891
TEST=./usb_updater2 -g 00 -d 18d1:502b
Change-Id: I46dfd97aaa17b73a5893fe1e8c62327a302f829b
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/763574
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This patch allows Fizz to switch the power source from a type-c
charger to a barrel jack adapter if the system is in S5.
BUG=b:38321259
BRANCH=none
TEST=Verify the following with 45W and 60W type-c chargers:
1. Boot Fizz with a type-c charger
2. Go to S5 if not already.
3. Plug in a BJ adapter. Fizz boots to S0 using BJ power.
Also verified other boot modes are not affected:
1. Auto boot on BJ insert
2. Auto boot on Type-C insert
3. Recovery boot on BJ
4. Recovery boot on Type-C
5. Stay off if it's previously S5
Change-Id: I86aa0fe6e403bcbacfe396997d897111ffcf8e74
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/706251
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
keyboard_clear_buffer() should not trash FIFO contents without
synchronization from fifo_add() / fifo_remove(), otherwise a bad
FIFO state may ensue.
BUG=chromium:781554
BRANCH=gru
TEST=Verify KB is functional on kevin through suspend / resume, verify
keyboard functions as S3 wake.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5d28c72359f6e1ce8778725a15c51cdfcd8ab90b
Reviewed-on: https://chromium-review.googlesource.com/761300
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The SET sub-command of EC_CMD_CHARGE_STATE sets charger current /
voltage parameters to arbitrary values and should be locked down.
EC_CMD_CHARGE_CONTROL, on the other hand, switches between several safe
operation modes, and should be allowed.
BUG=None
TEST=On kevin, set force_locked, plug zinger, and verify:
ectool chargestate param 4 3 <-- ACCESS_DENIED
ectool chargestate show <-- prints params
ectool chargecontrol idle <-- stops charging battery
ectool chargecontrol normal <-- battery charges again
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5503f07bb196d023a9bcd2e33f2e247f061f05e5
Reviewed-on: https://chromium-review.googlesource.com/757237
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Events used when TPM task is running are defined in two different
places, one of them shared with other boards running on H1.
Let's avoid collision by redefining Cr50 only events to be different
from shared ones used by dcrypto.
BRANCH=cr50
BUG=b:68729265
TEST=verified that there is no more 'tpm_reset_request: already
scheduled' messages generated when TPM is reset when performing
long dcrypto operation.
Change-Id: Ic9517fa98be21f3ef5f19b82c593d96b0ddbaf6b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756914
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently the Cr50 code resets TPM communications layer at a certain
point during TPM reset process.
It turns out that this is not sufficient - the comms layer keeps
receiving and trying to invoke TPM layer, which does not mesh well
with TPM reset.
Let's provide two callbacks for each comms layer - to shut it down and
to bring it back up. We shut down the comms when starting TPM reset
and bring them back up when reset is completed.
BRANCH=cr50
BUG=b:68012381
TEST=ran AP firmware test suite on both SPI and I2C based devices.
Change-Id: I7caf4a09b9a5c6e5fc6bfe60eae1c0d64ab24904
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754502
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
It's undesirable to do BC1.2 detection on power swap, so add a function
to check if the partner port is known to be PD-capable.
BUG=chromium:780905
BRANCH=gru
TEST=With subsequent CL, attach USB-PD phone capable of role swap.
Verify USB 2.0 device is enumerated on plug, and not re-enumerated
through a series of "pd # swap power" commands on the EC console. Also
verify BC1.2 charging and PD charging are still functional on kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ifa75c94e9758d3e407492bbda6fc52ed7bc378fa
Reviewed-on: https://chromium-review.googlesource.com/755877
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When allowing an unlocked system to automatically power up we
may attempt to boot before the charger is ready to supply enough
power and get stuck in a reset loop.
In addition, if the batttery is not physically present in the system
then delay power-on until the charger is providing at least 15W of
power. (currently defined as LIKELY_PD_USBC_POWER_MW)
By adding a final check to the charge_prevent_power_on() function
to ensure that charge_manager_get_charger_current() is returning
a valid value instead of CHARGE_CURRENT_UNINITIALIZED then the
board is able to reliably boot.
This CL combines 2 CLs made on Eve which addressed the same problem
I'm seeing on Robo devices.
https://chromium-review.googlesource.com/582545https://chromium-review.googlesource.com/709473
BUG=b:68226308
BRANCH=coral
TEST=Used Robo system which was consistently failing when external
power was connected to Port 1. After adding this change was able to
consistently power up the system without going into a reboot loop. In
addition had signal wires attached to VBUS and VSYS so could verify
that VSYS was no longer collapsing.
Change-Id: Iadecf032feaacfda230bfc98a332cd7963fb0afe
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/752755
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Charge port / current selection often needs to be significantly altered
when a battery cannot provide sufficient charge, so have charge_manager
initially enter safe mode. After a battery with sufficient capacity has
been identified, charge manager will leave safe mode, and port / current
selection will return to standard rules.
BUG=chromium:777596
BRANCH=None
TEST=Pass charge_manager unit tests. On kevin, remove battery, attach
Apple PD charger, verify safe mode is not exited and device does not
brown out. Hot-plug battery and verify safe mode is exited. Next,
remove battery, attach to Samus, verify safe mode is not exited and
device doesn't brown out. Hot-plug battery, verify that safe mode is
exited and no active charge port, due to dual-role exclusion.
Change-Id: I7784865750087a037aad8dbbac058b22c77ba6d4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/733954
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Most boards had an identical implementation for this function,
previously known as board_is_consuming_full_charge(). To reduce copy
paste, let's just move it to common code. Boards that charge ramp
without a battery will have to define their own implementation, but
there probably won't be any boards like that in the near future.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: Ic99a378ac26dfd35d7d718bf9376eacfa8609166
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/748919
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
1. Add a new config option to define history buffer length. This
allows boards to override this option if required.
2. Get rid of unused PORT80_POLL_PERIOD macro
BUG=None
BRANCH=None
TEST=Verified that all port80 messages from a boot-up or S3 resume are
present in port80 history buffer.
Change-Id: Ie64680459f58358713a1b1445a0b99fcfe1c1cdc
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745902
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a common hook handler on CHIPSET_RESUME to log port80 resume
message instead of duplicating the same code in all chip lpc_resume.
BUG=b:68669668
BRANCH=None
TEST=Verified that port80 resume is logged on S0ix and S3 resume.
Change-Id: I313692f5499717d0d8f62be2ba3b8566c46e4dde
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745362
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new LPC helper routine lpc_resume_clear_masks that can be used
to clear SCI, SMI and wake masks upon resume from S3. This is done to
mask the events until host explicitly unmasks them.
It also ensures that these masks do not get reset on resume from S0ix
where the host does not re-configure these masks.
BUG=b:68669668
BRANCH=None
TEST=Verified following:
1. make -j buildall
2. On resume from S0ix, SCI mask is not reset.
3. On resume from S3, SCI mask is reset and then set again by host request.
Change-Id: I17a86bd60ef066b3716fb79ecce62f311eb45509
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It is necessary to be able to set password both from the Cr50 console
and through a vendor command.
This patch moves all password management logic to the TPM task context
using the alternative vendor command path.
BRANCH=cr50
BUG=b:62537474
TEST=verified that using Cr50 console CCD password still can be set
and cleared as before.
Change-Id: I0574caf931e3717567fdb270e406643eac47764b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/740914
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Implement the following required features in the USB PD Rev. 3.0
specification.
Not_supported control message: Inform a port partner that a
particular message is not supported.
Battery capabilities extended message: Report battery design
capacity and last full charge capacity.
Battery status data message: Report battery state of charge
Collision avoidance: New scheme to avoid collisions caused when both
source and sink want to send messages.
Cable communication: Only the VCONN source can communicate with the
cable plug. This is NOT implemented because although the drivers have
the capability of communicating with a cable plug, the PD stack doesn't
currently need to talk to a cable plug. This is okay since the current
PD design doesn't source or sink more than 3 amps and all Type-C cables
are required to be 3 amp capable.
BUG=b:64411727
BRANCH=None
TEST=`make -j buildall`
Passed relevant PD Rev 2.0 compliance tests
Successful PD negotiation with PD Rev 2.0 and 3.0 chargers
Tested with low power none PD charger.
Modified a Kevin to operate as a PD 3.0 charger and sent
all required messages and verified the return messages.
Also tested collision avoidance by verifying that a sink only
transmits when the source indicates it's okay.
Used Twinkie to verify that PD was operating as v3.0.
Signed-off-by: Sam Hurst <shurst@chromium.org>
Change-Id: Ifd77e92ec4e9106236f9221393d2bfb97263d979
Reviewed-on: https://chromium-review.googlesource.com/603003
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
TPM reset sequence when TPM wipeout is requested has a side effect of
rebooting the entire device. This is not always desirable, in some
cases other actions need to happen before the device is rebooted.
This patch makes resetting the EC the TPM reset caller's responsibility,
BRANCH=cr50
BUG=none
TEST=verified that RMA reset and WP disable properly wipe out the TPM
and reboot the device.
Change-Id: I6e827ce923a2454ae5b2e2597d1a4c9390bbb8b6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/733813
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When RMA process has been initialized and the user entered the
expected authentication code value, the Cr50 needs to wipe out TPM
memory, open and unlock CCD and reboot the device.
This patch adds a function to accomplish that. User response is
validated on the TPM task context, and TPM reset request also requires
TPM task processing. To decouple response processing from the
following reset, the response processing is handled by a hook task
callback, delayed for 1s to make sure that user receives the response.
After TPM has successfully reset the CCD is reinitialized with RMA
'opened' and the device is rebooted.
Just in case something goes wrong with the unlock and the hook is not
invoked, add a 10s deferred function to take the EC out of reset so
that the device still can reboot.
BRANCH=none
BUG=b:67007905
TEST=on a Bob device:
- on the Cr50 console enter 'ccd lock', verify that ccd is locked
(by examining output of the 'ccd' command)
- at the bash prompt enter gsctool -r -s -t, copy the
authentication code from the Cr50 console and pass it to gsctool.
- observe the device reset TPM wiping out its memory, enable CCD
and reboot.
Change-Id: I6fafb5e642cb2b6f2040507a7f1989607fd31316
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/729983
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
keyboard/button init are responsible for checking if user requested
manual recovery. However, by this time, hook init is not run and hence
host event set operation for manual recovery is dropped. This change
adds a call to lpc_init_mask before keyboard/button init operations
are performed.
BUG=b:68189465
BRANCH=None
TEST=Verified that manual recovery works fine. Recovery using software
command works too:
reboot ap-off
hostevent set 0x4000
powerb
Change-Id: I15cb648d4b253a523293c7ab2cd3e8e08e31a763
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/735799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
tcpm_get_cc() returns TYPEC_CC_VOLT_*, not TYPEC_CC_*. Check for RP
rather than non-open to match USB-C spec (Table B-2 Rp/Rp Charging
Current Values for a DTS Source).
BUG=chromium:775542
BRANCH=servo
TEST=Verify donette and guppy are not detected as DTS, verify suzy-qable
is detected as DTS, on kevin DUT.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I0ff5550e9171ff86b42b489525044bf63827240c
Reviewed-on: https://chromium-review.googlesource.com/733220
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This prevents problematic disabling of the keystrokes by making it
so that 0xAD can't disable keystrokes.
Also cleans up keyboard controller enable/disable code.
BRANCH=none
BUG=none
TEST=keyboard now working in UEFI bootloaders like systemd-boot
(aka gummiboot)
Change-Id: I921834fc418572c9a0f4586039ac1ce05504bf1d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/722124
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Allow other modules to call pd_find_pdo_index() / pd_extract_pdo_power()
in order to get information about current PDOs.
BUG=chromium:775542
TEST=Manual on kevin, verify 20V negotiation with zinger still works.
BRANCH=servo
Change-Id: I1861a0226501bda13e7d576d0971d841da9d2b74
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/724682
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
suzy-qable advertises 1.5A, but its actual capability depends on the
host USB port it is attached to. Since suzy-qable is ubiquitous and
other DTS sources may behave in the same way, ramp the input current
limit in order to find a reasonable maximum.
BUG=chromium:770296
BRANCH=None
TEST=Attach suzy-qable to kevin and reef, verify that neither OCs and EC
console via cr50 is available on reef. Also verify donette chargers
kevin at 3A and does not ramp.
Change-Id: Idd0683ede3a44111a01da6b4faab52f388ee82fd
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/693295
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
According to the USB-C spec, when a debug accessory is identified, we may
optionally establish USB PD communication over CC. Some DTS partners
(eg. servo_v4) expect us to speak PD, so let's make it so. There is no
need for special ACCESSORY states, these do not exist in the PD spec.
BRANCH=servo
BUG=chromium:737755,b:65837068
TEST=On scarlet, attach servo_v4 and verify scarlet charges. Also verify
EC and cr50 consoles are available through servo_v4.
Change-Id: I59d1ca50b4766509eccf38562cdf926578138585
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/693294
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
