A common failure condition on the i2c bus is when the master
unexpectedly stops clocking the bus while the slave is driving the SDA
line low. In this case the master is not able to issue Stop or Start
sequences, which makes the bus unusable.
Good slave controllers are able to detect this condition and recover
from it by removing the pull down from the SDA line. This patch adds
this capability to the g chip i2c slave controller.
A new timer function is created which samples the SDA line twice a
second. If it detects that SDA is low in two consecutive invocations
and the number of i2cs read interrupts has not advanced, it decides
that the "hosed slave" condition is happening and reinitializes the
i2c driver, which removes the hold from the SDA line.
Even though the state of the SDA line is supposed to be accessible
through the I2CS_READVAL register, it in fact is not, reads always
return zero in the SDA bit. To work around this a GPIO (port 0, bit
14) is being allocated to allow to monitor the state of the line, it
is multiplexed to the same pin the SDA line uses.
When the AP is in low power modes the SDA line is held low, this state
should not trigger i2c reinitializations.
CQ-DEPEND=CL:616300
BRANCH=none
BUG=b:35648537
TEST=connected H1 on the test board to an I2c master capable of
stopping clocking mid byte. Observed that the existing code would
just sit in the "hosed" state indefinitely. The code with the fix
recovers from the condition (drives the SDA line high) 500ms to
1s after the failure condition is created.
Change-Id: Iafc7433bbae9e49975a72ef032a923274f8aab3b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/614391
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
We previously disabled the USB PHY to the AP. But the BOARD_AP_USB
property lingered on. Remove the property.
Also clean up the idle task deciding when to do utmi wakes. With the
AP USB connection disabled, that's only necessary when the debug cable
is attached, so we can check that explicitly.
BUG=none
BRANCH=cr50
TEST=make buildall; boot CR50_DEV=1 image
Change-Id: If81a7bcfe845d9d70dcc7e16239244a4f5f2427b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/616301
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
A subsequent CL will massively refactor the device state machines.
Add the helper functions which will be used by that CL, so that
the refactoring touches fewer files.
No change in functionality.
BUG=none
BRANCH=cr50
TEST=make buildall; boot cr50 with a CR50_DEV=1 image
Change-Id: I3499d45e93fa15b6de9c04ce398d1c5bfbbc01e9
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/616300
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Printing dots each time device wakes up from sleep causes the terminal
to be overflown with dots, especially in cases when interrupts are
generated at high rate.
Let's replace printing dots with a rotating wheel, the screen is not
going to be wiped out, and one still can tell the rate the wake
interrupts are coming at.
Also, each time the wake source changes, print its hex value.
BRANCH=none
BUG=none
TEST=verified proper printing of the spinning wheel and wake interrupt
sources.
Change-Id: Ic32466234f91b4a19b6186f74296dc6dd765a8fa
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/611962
Tested-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
the ps8xxx family of TCPCs (ps8751, ps8805) have historically used the
generic tcpci_tcpm_drv functions, but we need to override some of
these entry points because the parade parts need to be woken up before
accessing registers.
in most cases, this doesn't matter because we access the chip in quick
succession where we can "safely" assume the chip is awake -- and the
code is structured to implicitly keep the chip awake. the new case we
need to address here is where we need to suspend the pd_task and TCPC
at an arbitrary point in time. the driver's .release method is called
to shut down the chip, and that involves first waking up the chip to
be able to access its regs to mask off interrupts, etc.
BUG=b:35586896
BRANCH=none
TEST=tested from depthcharge - we no longer get errors in the EC
console logs about TCPC "release" failed.
Change-Id: Ic2a90b71050b3f68c697b1cef48d736ed88b3f41
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/616460
Reviewed-by: Shawn N <shawnn@chromium.org>
Some USB interface handlers need to know when USB has been
successfully resumed after a wake event. For example, this is
useful so that HID keyboard can send the events at the right time.
BRANCH=none
BUG=b:35775048
TEST=Using USB HID keyboard patches to queue keys in a FIFO:
After USB autosuspends, press a single key and hold it. Without
this patch the endpoint data only gets reloaded on the _next_
event.
TEST=On hammer, I2C passthrough still works.
Change-Id: I9b52b9de16767c8a66c702a5ae70369334a3d590
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/569547
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The command "hostcmd" in console isn't very useful and will cause
stack overflow in console task when processing some hash commands.
BUG=chromium:755048
BRANCH=none
TEST=make BOARD=elm -j
make BOARD=elm tests
There should be no hostcmd command in the console of elm.
Change-Id: Ifa721a1731bc1ebfb39e12430b6631338bdccd9f
Signed-off-by: Che-yu Wu <cheyuw@google.com>
Reviewed-on: https://chromium-review.googlesource.com/616600
Reviewed-by: Rong Chang <rongchang@chromium.org>
When servo_v4 acts as a debug test system (DTS) its expected use
case is for triggering CCD mode and Faft testing. To that end, its
desired default data role is to be a UFP so that the enet and USB
port are accessible by the DUT. However, when servo is acting a
regular SRC port, it makes more sense for the data role pairing to
be consistent with a normal SRC port device which is SRC/DFP.
BUG=b:64720447
BRANCH=servo
TEST=Tested with Eve using twinkie USB PD analyzer. Verified that when
DTS mode is enabled a data role swap request is sent to the DUT and
when DTS mode is disabled that servo_v4 does not send a data role swap
request.
Change-Id: I071f85fc99f1c877d86ef48ec7fa38d6850d5679
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/615813
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
To enable console with DMA, we need to specifically
remap DMA channels for USART1.
ch2/3 and ch6/7 are already used by SPI1/2 modules.
So we have to remap USART1_TX to ch4 and USART1_RX to ch5.
BUG=b:64575809
BRANCH=none
TEST=confirm ec console works on scarlet rev1
Change-Id: Ie2bb141c72252aee98e4cd4a284a01b4d57605f4
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/611147
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The center supply is fixed to .9V on nefario, it had not the
enable pin for controlling.
Also the Nefario unused the led for battery.
BUG=b:63408169
BRANCH=none
TEST=Tested on nefario, check the gpioget
Change-Id: I339ce2cb2fb530cec393a352d920ea21fd8a8464
Signed-off-by: Caesar Wang <wxt@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/612969
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Philip Chen <philipchen@chromium.org>
There isn't enough flash space after 'repo sync',
so disable one more console command.
BRANCH=none
BUG=none
TEST=build reef_it8320 and all.
Change-Id: I370e06d5de211b7de669f35071c680d28efb7c17
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/612001
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When CONFIG_USB_PD_MAX_SINGLE_SOURCE_CURRENT is defined for a board, as
its name implies, the board can source a higher current if there is
only one port acting as a source.
This commit fixes an issue with selecting the right source capability
message to advertise. charge_manager_get_source_pdo() was simply
checking if there was more than one sink connected, instead of checking
if there were any *other* sinks connected. In the event that a sink
was connected to a different port, we would advertise the max source
PDO.
BUG=b:64037926, b:35577509
BRANCH=gru,eve,reef
TEST=Connect sink to port 1. Connect a AMA to port 0 that claims that
VBUS isn't necessary. Start sending source caps, verify that the max
PDO is not being advertised in the source caps.
Change-Id: Ie4145ecaf98d5b9070ad3e8b139e5653685fa801
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/610479
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
As can be seen in <http://crosreview.com/610449> the IDs of PWMs are
directly referenced by the kernel device tree on gru / kevin / nefario
boards (technically also in bob and scarlet-rev0, but neither of those
is supported by mainline EC code). Because of the kernel reference
it's not a great idea to change the IDs.
Let's add a comment so people don't change the ordering / IDs
accidentally.
NOTE: we can have a big argument here about whether it would be OK to
change numbering _and_ change the numbering in the kernel at the same
time. We can talk about whether the device tree is a binary and about
whether this constitutes an ABI since Chromebooks don't ship the
device tree binary separate from the kernel. We can talk about all
those things. ...but we won't. There's no good reason to change the
ID, so just don't do it.
BRANCH=None
BUG=b:63537905
TEST=None
Change-Id: Iacdedc1c91e583183034d15e99735a470d6e0951
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/610933
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Poppy uses 0x00 reg for manufacturer access and shutdown data 0x10
just like Soraka battery. Fix the macros for poppy.
BUG=b:64460667
BRANCH=None
TEST=Verified that battery cutoff by smb command works on poppy.
Change-Id: I5e568a31a575bc0e403362e48e64a753c094dab1
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/609553
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Now that we have a custom battery presence function, we do not need
the disconnect behavior as it will recover better by letting the state
machine handle it with precharge directly.
Without this change, EC was stuck in "battery found in disconnect
state" after battery cut-off.
(Reference: https://chromium-review.googlesource.com/c/582538)
BUG=b:64370648,b:64460667
BRANCH=None
TEST=manual testing with cut-off batteries shows more consistent
behavior to boot AP after plugging in adapter.
Change-Id: I8d1072d29c42e5b10b133d880897287882bd698b
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/607036
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Just checking for battery present gpio is not sufficient to determine
the state of the battery. On the lines of the changes made by Eve, add
a new battery_is_present function which:
1. Checks hardware gpio signal to determine if battery is present
2. If yes, then checks following if its status just changed to present:
a. Battery is not in cut-off state
b. Battery is not in disconnect state (charging and discharging
disabled)
c. Battery initialization is complete
Only if all the above conditions are true, then battery is considered
as present.
BUG=b:64460667,b:64370648
BRANCH=None
TEST=Verified that with this change recovering system from battery
cut-off is more consistent.
Change-Id: I10abdf603e01f404c9b8e2094e36bc068adf5450
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/607035
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
When battery is cutoff, it might at times require some current to be
applied to it so that it can wake up. Thus, in case where all battery
flags indicate error in charger_profile_override, set
requested_current and requested_voltage to precharge_current and
voltage max. This allows the battery to be woken up.
BUG=b:64370648,b:64460667
BRANCH=None
TEST=Verified that on connecting AC power after battery-cutoff, there
are no "try to wake battery" messages anymore.
Change-Id: Ib88369238b492994d8310655126e19bc7e347a0c
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/607034
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Instead of going to hibernate when the battery is critically low
we should cut off power entirely.
Even with the PMIC shut down the H1 chip consumes more power than
is healthy when the battery is already critically low, depleting it
to dangerously low voltage levels faster than it should.
(Reference: https://chromium-review.googlesource.com/582543)
BUG=b:64460667
BRANCH=None
TEST=Manual testing to ensure that EC cuts off battery when it is
critically low instead of hibernating on soraka.
Change-Id: I3befd583df64c44d43d73cda69a6486219578192
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/605015
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
With a battery that has 1% charge there may not be enough to boot the
AP, resulting in a brown out. Raise this to 2% to get more consistent
behavior to let the battery charge before booting.
(Reference: https://chromium-review.googlesource.com/582540)
BUG=b:64460667
BRANCH=None
TEST=Manual testing to ensure that EC does not attempt to boot the AP
unless the battery charge is >=2%.
Change-Id: I2c3d0e292470d44ffd8fd33e8a58c59a19548513
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/605013
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
These config options change the behavior of charge_prevent_power_on
and ignore the minimum battery percentage for booting. Since we don't
have any AP code to actually handle this state, we don't want it to
always boot the AP or it might brown out with a battery that is
critically low.
(Reference: https://chromium-review.googlesource.com/c/582539)
BUG=b:64460667
BRANCH=None
TEST=manual testing with low battery to ensure it does not attempt to
boot the AP.
Change-Id: I670a2bf7eba4354ae522d1ea2423c90ff07f5ea6
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/605012
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The device_state module is used for debouncing GPIO inputs to
determine device state. It was overkill for managing the battery
present state as forwarded to the write protect pin, and split that
handling between 3 files (board.c, wp.c, device_state.c). Move all of
that logic into wp.c so it's easier to maintain.
BUG=none
BRANCH=cr50
TEST=manual
plug in battery (or ground DIOM2)
wp command reports WP enabled
unplug battery (or pull DIOM2 high)
wp command reports WP disabled
Change-Id: I71ab9ce5766ecddae430c63a8b31388935a46180
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/604500
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The device_state module is used for debouncing GPIO inputs to
determine device sstate. It was overkill for managing the CCD cable
(RDD) attach/detach state, and split that handling between 3 files
(board.c, rdd.c, device_state.c). Move all of that logic into rdd.c
so it's easier to maintain.
BUG=none
BRANCH=cr50
TEST=manual
plug in CCD cable (or ground DIOM1)
ccd command reports cable connected and AP UART TX+RX
unplug CCD cable (or un-ground DIOM1)
ccd command reports cable disconnected and AP UART disabled
Change-Id: Id8fcd3a51605ae7a4843668ea18dd0ef84aceb2c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/604499
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This mostly adds a bunch of comments, but does make a few changes to
the code:
1) The devices console command now prints both the current device
state and the last known state.
2) servo_state_unknown() also checks if we're bit-banging the EC UART,
since that could also cause EC_DETECT to go high.
BUG=none
BRANCH=cr50
TEST=make buildall; use 'devices' command
Change-Id: I73e7524545ef49494eb36155b99f4042c1fd466d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/602695
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This patch defines CONFIG_DATA_RAM_SIZE, which indicates the size
of the RAM used for data, thus can be marked as non-executable.
If it's not defined, it defaults to CONFIG_RAM_SIZE. Thus, other chips
are not affected.
BUG=b:36037354
BRANCH=none
TEST=buildall. Run 'sysjump disable' on Reef and verify mpu_protect_ram
is successful.
Change-Id: I54d74fd1dabff7e1013fff2542fd02c3646803d1
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/596518
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This commit enables the use of the TI BQ24932 charger detector.
Additionally, the charge ramping config option is turned on as the
ISL9238 supports HW based charge ramping.
BUG=none
BRANCH=none
TEST=`make -j buildall`
TEST=Flash modified version on npcx7_evb and verify no panics or asserts
are hit.
CQ-DEPEND=CL:601533
Change-Id: Ia6e132fc86b00b70f5d88894c34565be862f84b1
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/601532
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Especially when PWM is active, base detection pin value can
vary widely: values from 138 mV to 270mV were measured. Let's
increase the detection interval to help with this.
Also, add reverse detection ADC values, for a possible future
implementation.
BRANCH=none
BUG=b:64193554
BUG=b:64370797
TEST=Plug/unplug staff a few times, look at BASE_DET values after
sideband pulse in DS3, check that detection always falls within
120-300 range.
TEST=Plug/unplug staff in reverse, see that value is about ~480 mV.
Change-Id: I226930572dfe583941b772f2037c3c4b7ef54e14
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/601627
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
We need to ensure that the NVMEM variable containing the seed is properly
saved to flash, so we can restore it later whatever happens.
Add a call to writevars() which triggers the NVMEM commit rather than
accidentally waiting for it.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=run twice 'trunks_send --u2f_cert --crt=/tmp/mycert.crt' and
hard-reboot the cr50 in between and see both certificates are
fully identical.
Change-Id: Iea4f9fdede4c0a2eeae1c59633caa16dbf70a66f
Reviewed-on: https://chromium-review.googlesource.com/602241
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This commit adds support for the two board LEDs conforming to the Chrome
OS LED behaviour specification.
BUG=none
BRANCH=none
TEST=Flash a modified image on npcx7_evb with some LEDs connected. Fake
out chipset transitions and charge state states. Verify that LEDs
behave as expected.
Change-Id: If6d7a48cc4a363452fad172fa8efa0c5e603f6d7
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/601428
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Implement the RFC 6979 to get a deterministic integer k when doing the
ECDSA signing of the x.509 certificates used by U2F and particularly
individual attestation mechanism, rather than using the random generator
as per the original ECDSA algorithm.
So the generated certs have bit-for-bit identical signatures when the
content is identical.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=pass U2FTest and manually dump several individual attestation certs,
run the "rfc6779" console command when enabled.
Change-Id: I7b73eee6d5a863aae9a7eec49db884151bad5ab4
Reviewed-on: https://chromium-review.googlesource.com/558073
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This code looks fine either inside or outside of the if clause. I chose
to keep it outside and just re-indent it since the previous test
didn't look at the cnt value, so the previous test could pass, and this
test could fail even if cnt wasn't updated.
BUG=None
TEST=build
Change-Id: I869af54f9093ee8a2f855d7a71ea6acf3d3e16f6
Signed-off-by: Martin Roth <martinroth@google.com>
Reviewed-on: https://chromium-review.googlesource.com/596490
Commit-Ready: Martin Roth <martinroth@chromium.org>
Tested-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We'd like to know touchpad vendor/product id, as well as currently
running FW version. This CL does that by adding a new
UPDATE_EXTRA_CMD_TOUCHPAD_INFO command.
We also make the interface more generic by adding a CONFIG_TOUCHPAD
configuration option, even though we only support Elan touchpads
currently.
BRANCH=none
BUG=b:63418037
TEST=Flash hammer, ./usb_updater -t
Change-Id: Icce3c785eb3235bcc50b2ae7c0227ce11cbc9f2b
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/593000
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Leaving the I2C passthrough to the trackpad open causes security
issues, let's make sure we disable that in the field, whenever
the WP screw is on (and system is locked, which will be synonymous
for production firmwares).
BRANCH=none
BUG=b:37926507
TEST=- In board/hammer/board.h, uncomment CONFIG_SYSTEM_UNLOCKED
- Flash hammer (both RO and RW)
- Trackpad updating still works (touchpad_updater on DUT)
- Make sure WP is on
dut-control -p 9000 fw_wp_vref:pp3300 fw_wp_en:on fw_wp:on
- hammer console: flashwp true; reboot
- Trackpad updating fails (cannot read iap password.)
Change-Id: I247bb9c62ea00d6cb3631c919d27305f4d291d68
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/595290
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
