Deep sleep needs to be considered a normal behavior and should not add
to the rollback count. This change subtracts one from the reset count
when the system sees that it just resumed from deep sleep.
Ideally the rollback counter would be able to verify the TPM
functionality and detect rolling reboots. With this change the rollback
counter will only be able to detect rolling reboots, but it fixes the
false positives for rolling reboots we were seeing before.
BUG=chrome-os-partner:60449
BRANCH=none
TEST=manual
check the reset counter
turn off the AP
wait for cr50 to enter deep sleep
plug in suzyq
check it resumes from deep sleep and that the reset counter
still has the same value
Change-Id: Ie8490c29636403b409b2a3f0912a5b312d23bc24
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/418321
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Having cr50 resume on the falling edge of its uart rx signal is causing
some issues, and wake on low is good enough and works fine. This change
switches uart rx from DIO_WAKE_FALLING to DIO_WAKE_LOW
BUG=chrome-os-partner:60449
BRANCH=none
TEST=cr50 can still resume on uart activity and plugging in the charger
has no impact on cr50 remaining in deep sleep.
Change-Id: If77126cb64cf2fa949a75d53bb40098f037a2aa4
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/418335
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We currently rely on *head == 0 as error condition, which is
fragile and inconsistent across TCPCs implementations.
Instead, let's return a proper return value on all implementations.
BRANCH=none
BUG=chrome-os-partner:60575
TEST=elm FW as of 65fb80d (later version include a fix that would
hide this issue), cherry-pick this patch, connect j5create
adapter, then HDMI, then power => no crash
Change-Id: If7235e0491e9f80fdd50ce2605477ee518f8e1aa
Reviewed-on: https://chromium-review.googlesource.com/417443
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
From TCPC spec:
"""
RECEIVE_BYTE_COUNT: Indicates number of bytes in this register
that are not stale. The TCPM should read the first RECEIVE_BYTE_COUNT
bytes in this register. This is the number of bytes in the
RX_BUFFER_DATA_OBJECTS plus three (for the RX_BUF_FRAME_TYPE and
RX_BUF_HEADER).
"""
We were always reading 3 bytes too many. This is an issue if we
receive a packet followed by a hard reset, as the register value
will be set back to 0, but TCPC_REG_RX_HDR may contain a valid
header, leading to corrupted packets being passed down the stack.
Also update usb_pd_tcpc to match the specification.
BRANCH=none
BUG=chrome-os-partner:60575
TEST=elm FW as of 65fb80d (later version include a fix that would
hide this issue), cherry-pick this patch, connect j5create
adapter, then HDMI, then power => no crash
Change-Id: I9ed8f3b500d5733ec7563e31246505e0b8bd48bb
Reviewed-on: https://chromium-review.googlesource.com/417442
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This change adds a usb clock enable before trying to write to the usb
registers when preparing for deep sleep.
It is possible that usb has not been initialized, so we need to make
sure that the clock is enabled.
BUG=chrome-os-partner:60555
BRANCH=none
TEST=manual, on both dev and prod fused H1
run hibernate on the EC
wait until cr50 enters deep sleep
plug/unplug the charger
verify the AP can boot to the kernel
Change-Id: I26359f4224cd25dc57c32d1508e26b133c43d317
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/417771
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
* Include trng.h from trng.c before any other header to verify that the
header is self-contained.
* Add inclusion of stdint.h to trng.h to provide definition for uint32_t.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I78fb6d915c357236ca0fed2a57f093f0eec07fe9
Reviewed-on: https://chromium-review.googlesource.com/417424
Commit-Ready: Carl Hamilton <carlh@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
(Original CL: https://chromium-review.googlesource.com/#/c/411395/)
Enabling/Dislabling keyboard and touchpad is required to prevent EC
from waking up the system from S3 in tablet mode.
This change disables the keyboard and the trackpad when the lid goes
beyond 180 degree.
Keyboard and touchpad are also enabled/disabled by the tablet switch.
When the lid reaches 360 position, keyboard and touchpad are disabled.
And they stay disabled as long as the lid stays at 360 position.
This prevents keyboard and touchpad from turning on by the (faulty) lid
angle calculation.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I919f44bae4a13aa4d9e6072e96e46bb90c08ec22
Signed-off-by: Bruce.Wan <Bruce.Wan@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/417643
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Set the default idle action based on whether bus obfuscation is enabled.
BUG=none
BRANCH=none
TEST=verify the idle default is sleep on b1 boards and wfi on b2.
Verify that both types of chips go to sleep and resume
successfully.
Change-Id: Ib5a11c4060aa411ff36c06c7fcadf0bf4c223bf1
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/410167
When the battery is fully charged or not charging, upon removal of
the AC, discharge takes long time. To overcome this issue suspend
the DC-DC converter when discharging on AC.
(Refers Reef CL:413153)
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: Iebfcb95d0469be552283d17eb1aea0310eccbcb9
Signed-off-by: Bruce.Wan <Bruce.Wan@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/417428
Commit-Ready: Keith Tzeng <keith.tzeng@quantatw.com>
Tested-by: Keith Tzeng <keith.tzeng@quantatw.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The original thought of setting LRESET_PLTRST_MODE to 1 is to remove the
need to reinitialize host module registers whenever LRESET# occurs in
order to save time when boot-up.
However, some of these registers will be reset by core domain reset. It
means every time LRESET is de-asserted, we need to initialize the host
setting again. Therefore, setting LRESET_PLTRST_MODE to 1 is unnecessary
and sometimes dangerous. If BIOS believes LRESET will reset ec's host
state machine to default but ec not, it will cause unexpected behavior.
Modified drivers:
1. lpc.c: allow LRESET/PLTRST generate host domain reset
BUG=chrome-os-partner:60211
BRANCH:none
TEST=make buildall. run "dut-control pwr_button:press; sleep 11; dut-control
pwr_button:release; sleep 7; dut-control pwr_button:press; sleep 1;
dut-control pwr_button:release". Verify keyboard works normally.
Change-Id: I94d428cde69f828468547c44844983f25686ea04
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/417745
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Apparently, one does not simply remove power from the trackpad and
restore it at will; the kernel needs to be involved and decide if the
device needs to be fully reinitialized, or if it was supposed to keep
some state. Therefore, let's not touch it except from startup and
shutdown and let the higher parts of the stack make the necessary
decisions.
BUG=chrome-os-partner:60478
BRANCH=gru
TEST=Boot in tablet mode and verify trackpad still works.
TEST=Go from clamshell to tablet mode and verify trackpad still works in
both modes.
Change-Id: I7674c5516ce4d237b0d2a15fb94b47e6fbe3ba39
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/417110
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In preparation to a new release let's bump up minor versions of both
prod and dev images to 12.
BRANCH=none
BUG=none
TEST=built images and verified version number
Change-Id: I55979374f5e3e21fedde128410c4861e4c2ad9c4
Reviewed-on: https://chromium-review.googlesource.com/417883
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Charger Operation Control Setting 1 (CHGOP_SET1) has separate bits to
disable input current limitation for DCP, SDP, others. If it is not
disabled, input current is automatically selected, which results in
hard resets on weak chargers hence disable the input current
limitation for all types of chargers.
BUG=chrome-os-partner:60722
BRANCH=none
TEST=Tested on Reef. Input current is not automatically set to all
types of chargers.
Change-Id: Ideb16ac2a40b403c94c28e85f254043ead7415e0
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/417234
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
__hw_clock_event_set() is not reentrant and may be called from both our
event timer ISR and our hwtimer ISR when hwtimer is close to wrapping.
Modify the interrupt priority of our hwtimer int to match our event
timer int so that one cannot preempt the other. Originally the priority
was changed to allow the hwtimer ISR to run first in case both are
pending, but this condition can be handled cleanly and isn't a big
concern.
BUG=chrome-os-partner:60470
BRANCH=gru
TEST=Pass 500 S/R cycles on kevin with hwtimer wrap rate sped up 300x
(roughly equivalent to 150,000 real S/R cycles).
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ied466f14661f04c8662b5db709c0e3770a5bb200
Reviewed-on: https://chromium-review.googlesource.com/417060
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit ac28ec53b63a02c4d25e8a222d13595bc857fef0)
Reviewed-on: https://chromium-review.googlesource.com/417112
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This is a 'semi official' utility script which re-signs previously
generated CR50 RW images.
By default the script uses ec.RW.elf and ec.RW_B.elf in build/cr50/RW
as inputs and util/signer/ec_RW-manifest-dev.json as the manifest, and
places the newly signed images into build/cr50/ec.bin.
The only outside dependency of this script is the signing utility itself,
which is expected to be available as $HOME/bin/codesighner.
The following command line options are accepted:
b1 - generate signature for the b1 version of the H1 chip
elves <elf1> <elf2> - sign the supplied elf files instead of the
default ones. Handy if the builder generated files need to be
signed
help - print this message
hex - generate hex output instead of binary
prod - sign with prod key (no debug image will be signed)
When invoked with 'hex' as a command line parameter, the script just
re-signs the supplied elf files and places them in 0.signed.hex and
1.signed.hex in the current directory.
This script also allows to sign dev images for running on prod RO. To
do that invoke this script as follows:
H1_DEVIDS='<dev id0> <dev id1>" ${progname} [other options, if any]
where <dev id0> <dev id1> are values reported by sysinfo command in the
DEV_ID: line when ran on the CR50 for which the image is built.
BRANCH=none
BUG=chrome-os-partner:57956
TEST=manual
tried signing dev and prod images, including sighing a dev image to
run on a prod device. All cases succeeded.
Change-Id: I879c4a08503a19a0c440b141aa1fd6b29cc70bf7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/417221
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Modified the SPI NOR flash driver to implement
and expose a read JEDEC ID command as well as
support block (64KiB) erase operations.
BUG=None
BRANCH=None
TEST=Built all targets. Tested on two different EEPROMs.
Before:
-------------------------------------------
$ ~/haven_updater$ ./read_jedec_ftdi
[+] JEDEC_ID=0x1940ef
$ ~/haven_updater$ time ./chip_erase_ftdi
[+] Success!
real 4m0.440s
user 0m6.674s
sys 0m11.998s
-------------------------------------------
$ ~/haven_updater$ ./read_jedec_ftdi
[+] JEDEC_ID=0xc21a20c2
$ ~/haven_updater$ time ./chip_erase_ftdi
[+] Success!
real 5m57.291s
user 0m9.964s
sys 0m18.363s
-------------------------------------------
After:
-------------------------------------------
$ ~/haven_updater$ ./read_jedec_ftdi
[+] JEDEC_ID=0x1940ef
$ ~/haven_updater$ time ./chip_erase_ftdi
[+] Success!
real 1m33.176s
user 0m2.327s
sys 0m5.050s
-------------------------------------------
$ ~/haven_updater$ ./read_jedec_ftdi
[+] JEDEC_ID=0xc21a20c2
$ ~/haven_updater$ time ./chip_erase_ftdi
[+] Success!
real 2m41.923s
user 0m4.191s
sys 0m8.576s
-------------------------------------------
Change-Id: Ic20372ca9966499977a52a700d6492d3f648d7b2
Signed-off-by: Nadim Taha <ntaha@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416903
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Some chargers lose VBUS even when ramp is stable and we re-ramp for
those chargers. It continues in loop. To avoid this issue, reduce
the max input current limit if VBUS drops on stable ramp.
BUG=chrome-os-partner:60544
BRANCH=none
TEST=Tested on Reef. Ramp settles to lower current and multiple
re-ramp is not observed.
Change-Id: I6c9ce4720d01b9e8e3215e8122f798076e516c19
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/416349
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Rachel Nancollas <rachelsn@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The manifest used for signing in dev mode was originally used for
kevin evt 1, but now it is a common dev mode manifest. Rename the fie
appropriately and modify the makefile using it.
BRANCH=none
BUG=chrome-os-partner:57956
TEST=verified that it is still possible to build cr50 with CR50_DEV=1
Change-Id: If744406a83a7045cd34c76c941fdef209bef51ac
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/417220
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
It's preferable to print an error when mv = 0, rather than
crashing. Also, do not even select invalid PDO in
pd_find_pdo_index.
This was seen on elm, where ANX7688 appears to send the EC a
corrupted packet during hard reset when connected to j5create
adapter.
BRANCH=none
BUG=chrome-os-partner:60575
TEST=Plug in j5create adapter, then HDMI adapter, then power, elm
does not crash (note that the HDMI output still does not work,
but at least elm charges).
Change-Id: I2150ad6f13465a005444804ec44ec3bdc0ded361
Reviewed-on: https://chromium-review.googlesource.com/416700
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The new reef form-factor, Electro, has the lid accelerometer on the
reversed side. Undo the matrix setting.
BUG=chrome-os-partner:60477
BRANCH=reef
TEST=compile, check on reef the value are incorrect.
This reverts commit 430dd5e644.
Change-Id: I0a0efc89f0fad6cce3720836caf2c52bdb7e2b8d
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416390
Tested-by: Ryan Zhang <ryan.zhang.quanta@gmail.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
gru has circuitrythat selects the charge LED color based on the
frequency of the PWM.
By adjusting the PWM frequency instead of just the duty, we gain more
control over the brightness of the charge LED.
BUG=chrome-os-partner:54155
BRANCH=gru
TEST=activate each LED in turn and confirm color and brightness
Change-Id: Ie653125a528595c1ec68aea4d02cb70595a1b151
Signed-off-by: David Schneider <dnschneid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/415517
Reviewed-by: Shawn N <shawnn@chromium.org>
If battery is not present, input current is set to PD_MAX_CURRENT_MA.
If the input power set is greater than the maximum allowed system power,
system might get damaged. Hence, limit the input current to meet maximum
allowed input system power.
BUG=chrome-os-partner:58498
BRANCH=none
TEST=Manually tested on Reef. Removed the battery & using 'charger'
console command observed the following.
With Zinger charger at 20V - Input current is set to 2.25A
With Type-C & other chargers - Input current is set to 3A
Change-Id: Ife8686f322e095aa74b740a7c469bfe87107fb9a
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/397865
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Upon requesting a PD power contract at a new voltage, keep the input
current limit at 500mA until PD_RDY is received.
BUG=b:30744563,chrome-os-partner:59311,chrome-os-partner:44340
BRANCH=ryu, gru, glados
TEST=Manual on kevin, set ilim to 5V through `chglim` console command,
attach zinger. Set ilim to 20V through `chglim`, verify that ilim goes
from 3A to 500mA to 3A.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I452f183cfb958780e336a9f99dc6398356de17a0
Reviewed-on: https://chromium-review.googlesource.com/399918
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The tablet mode value is set to 1 on each program start (RO power on
reset or any sysjump) in common tablet mode infrastructure. This
results in the tablet mode not ever reflecting current reality at the
beginning of each program. In addition to not being able to order
hook callbacks within a single hook it's the luck of the draw if
the tablet mode is set correctly if it was is being set within a
hook callback. With a lid accelerometer that doesn't work it
results in the input peripherals never being enabled.
To fix all this ensure the tablet mode state reflects the current
hardware input such that there's no ordering issues in addition to
making it reflect reality.
BUG=chrome-os-partner:60481
BRANCH=reef
TEST=With a machine whose accelerometer is unattached. Keyboard
and trackpad continue to work through suspend-resume, EC reboot,
etc.
Change-Id: I3456a7b578c9752344424721858756a33992a37d
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/416348
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
When a WAIT is received in response to a request, wait SinkRequestTime
before resending the request.
BUG=chrome-os-partner:34984
TEST=make -j buildall
BRANCH=none
Change-Id: I5c8429c4a7b9cf06609996f924b8d9d535ab6b5f
Reviewed-on: https://chromium-review.googlesource.com/414533
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The latest released images are 0.0.11, let's update the manifests such
that images built in dev environment can override released images.
BRANCH=none
BUG=none
TEST=verified that new images are built with RW version 0.0.11
Change-Id: I4db82abd3eb725849b656259f675b32a8314942c
Reviewed-on: https://chromium-review.googlesource.com/415601
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When usb_updater is invoked with the '-f' option and without
specifying the binary file to transmit, the cr50 still enters the data
transfer mode, even though the host is not transferring anything.
As a result cr50 stays in the 'rx_outside_block' state until timeout
expires. Another usb_updater invocation fails if attempted before
timeout expiration.
The UPGRADE_DONE PDU sent by the host causes the state machine to
switch to the idle state immediately.
BRANCH=none
BUG=none
TEST=ran the following commands:
usb_updater -f && usb_updater -f
the second invocation used to fail before this change, now it succeeds.
Change-Id: Iceafeb30de6011975fbf47dabc7c6c494177c0f7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/415554
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Common code is more flexible and supports more parts, so delete the
npcx-only register translation code.
BUG=chrome-os-partner:60029
BRANCH=gru
TEST=Manual on gru, run 'flashrom -p ec --wp-enable' and check that 0x28
gets written to SR1, which matches our desired 'protect botton 128KB',
according to the datasheet. Also run 'flashrom -p ec --erase' then read
back EC SPI contents, verify ROM is erased except for first 128KB
region.
Change-Id: I526401997ff7ec77f2a6047a4a9af74a671ed69a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413228
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 43634d36d273887b1f2349c333a7b4b229a83365)
Reviewed-on: https://chromium-review.googlesource.com/415498
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
If UMA is locked, read and write access to SR* regs will fail, and we'll
be unable to determine or change our write protect state. Save our SR
regs before enabling UMA lock, and bring down UMA lock for a brief
period when writing SR regs.
BUG=chrome-os-partner:60029
BRANCH=gru
TEST=Manual on kevin with SW sync enabled.
flashrom -p ec --wp-enable -> verify success, check flags:
Flags: wp_gpio_asserted ro_at_boot ro_now
Reboot host, check flags:
Flags: wp_gpio_asserted ro_at_boot ro_now all_now
Verify flashrom -p ec --wp-status shows protected, and flashrom -p ec
--wp-disable fails.
Also verify same state after EC reset.
Boot into recovery mode, check flags:
Flags: wp_gpio_asserted ro_at_boot ro_now
Remove WP screw, reboot EC, check flags:
Flags: ro_at_boot ro_now
Verify flashrom WP status shows protected, and flashrom WP disable
succeeds and clears all flags.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I17e32f7305600183e7fcb87f69a3feb88978f94e
Reviewed-on: https://chromium-review.googlesource.com/412977
(cherry picked from commit 6cfc0d0dd030b8b0334f99e99950a52fcf8267af)
Reviewed-on: https://chromium-review.googlesource.com/415497
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
- Stop charging when thermal limits are violated.
- Don't start charging if battery percent is above 95% (but continue to
charge if we're already charging).
- Don't allow battery voltage to get too close (10mA) to BD9995X VBAT
setting. If battery voltage exceeds VBAT then back boosting may occur.
BUG=chrome-os-partner:56255
BRANCH=gru
TEST=Manual on kevin, insert charger with battery at 97%, verify battery
doesn't charge and reported current is 0. Discharge down to 95% and
insert charger, verify battery charges. Charge to 100%, verify battery
stops requesting current.
Change-Id: Icc5641e88bfad7d9d8ad4b6840338541fe7ba9a8
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403483
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/415494
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Making dual-role determination after receiving source caps is not
sufficient, since we may not yet have identified the partner port.
BUG=chrome-os-partner:56966
BRANCH=gru
TEST=Attach 'old' Apple USB-C accessory to kevin, attach OEM charger to
accessory, run 'pd X hard', verify device charges from port.
Change-Id: I7333dd2c723e7245d30cf8a6cb1344e60073c063
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403118
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 09691a0e8dd93383fa76b74332d89707bfe16001)
Reviewed-on: https://chromium-review.googlesource.com/415492
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
After sending a hard reset through Control3 SEND_HARD_RESET, packet Tx
will fail until PD_RESET is triggered. Therefore, always do such a reset
when we see an M_HARDSENT interrupt. Previously, it may have been possible
to skip our reset depending on prior Tx packet status, leaving the TCPC
in a wedged state.
BUG=chrome-os-partner:58232
TEST=Manual on kevin, spam 'pd 0 hard' for 10 hours with zinger attached,
verify TCPC is still responsive and negotiating to 20V.
BRANCH=gru.
Change-Id: I42db792a5f51218c58235dc38c2d49795b54986e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/393769
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 811534541c263244d2fe9bdf9465de196e1575da)
Reviewed-on: https://chromium-review.googlesource.com/415486
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
