In the field, we want to update touchpad FW using the same USB
update protocol as the main EC FW.
To distinguish between EC FW update and touchpad FW update, we
use a virtual address, defined by CONFIG_TOUCHPAD_VIRTUAL_OFF,
that does not map to anything on the EC chip.
Also, this will allow us to verify hashes of each block of the
flashed touchpad firmware, so that we can ensure its integrity
before flashing it into the touchpad. A stub is implemented in
update_fw.c:contents_allowed.
BRANCH=none
BUG=b:63993173
TEST=With follow-up CLs, ./usb_updater2 -p 144.0_2.0.bin
Change-Id: I4de1d7d138fc01fe1552a4173c8ef208ecb834a7
Signed-off-by: Nicolas Boichat <drinkcat@google.com>
Reviewed-on: https://chromium-review.googlesource.com/593373
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@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>
If board selects both CONFIG_BATTERY_CRITICAL_SHUTDOWN_CUT_OFF and
CONFIG_HIBERNATE, then CONFIG_BATTERY_CRITICAL_SHUTDOWN_CUT_OFF should
be given higher preference when deciding what action to take in case
of critical battery.
This is necessary on boards where components like H1 chip could be
consuming more power than is healthy when the battery is already
critically low, depleting it to dangeriously 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: I6efacd7206199ca19f1073296b113b6cf18ec655
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/605014
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 board ID fields are displayed by the Cr50 console command 'bid' as
follows: <board id>:<board id mask>:<board id flags>.
Make sure the user passes them in the same order when invoking the signer
to sign a board locked image.
BRANCH=none
BUG=none
TEST=verified proper order of the fields when generating and using a
prod signed image.
Change-Id: Ia4569c5e9e663b26edaa591bae881c719c4f199c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/604218
Reviewed-by: Mary Ruthven <mruthven@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>
There are none cros_ec devices running EC codebase connected to
chromebook, which can be accessed by ectool with
`cros_ec --name=SOME_DEV ...`.
In the case when SOME_DEV is not found, do not fallback to other
communication methods such as LPC or I2C, since ectool will instead get
the reply of real cros_ec device.
BRANCH=none
BUG=b:64468324
TEST=on poppy, `ectool --name=cros_tp version` should show:
`Unable to establish host communication
Couldn't find EC`
Change-Id: I2ac232122e0f928703f7607da365d5c1dc6f7194
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/604977
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Recent signer improvements allow to include hex values into the
manifest, this also makes it easier to process values with bid D31
set, let's use strings instead of ints.
BRANCH=none
BUG=none
TEST=verified signing of a prod release
Change-Id: Ia05198991bfdd8dfd831545a9edf70f1e06f24f4
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/604217
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>
In all states other than STATE_NONE, ensure that there is a deferred
call set after DEBUG_TIMEOUT so that debug mode exits if there is no
user activity.
BUG=b:64436180
BRANCH=None
TEST=make -j buildall. Also, verified following:
1. All combos still work fine
2. No user input for 10 seconds after entering debug mode:
++[42.318691 DEBUG MODE: Active!]
++[53.288057 DEBUG MODE: Exit!]
3. No user input for 10 seconds on sysrq path:
++[95.675863 DEBUG MODE: Active!]
+[97.200743 Button 'Volume Down' was pressed]
[97.526162 Button 'Volume Down' was released]
[107.528069 DEBUG MODE: Exit!]
4. No user input for 10 seconds on warm reset path:
+[149.374805 DEBUG MODE: Active!]
[150.863902 Button 'Volume Up' was pressed]
[151.193353 Button 'Volume Up' was released]
[161.199244 DEBUG MODE: Exit!]
5. Volup+Voldn still held down 10 seconds after entering debug mode:
+[213.704770 DEBUG MODE: Active!]
[223.705368 DEBUG MODE: Exit!]
Change-Id: I8a0aa448d31b4a746c7af2519ac6f61838bc9b99
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/603991
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When resuming from S3, it may take a while for the bus to become
alive again, so let's increase the timeout. 3 seconds is probably
a bit too long, but should work for our purpose: we just do not
want to be stuck in that state forever.
BRANCH=none
BUG=b:35587173
TEST=Use powerd_dbus_suspend to put poppy in S3. Press key, see
that hosts sometimes takes ~90ms, but sometimes up to 1.5s
to resume.
Change-Id: Ic800481b2b500fb68a8d1de16b11cbe77a4013d4
Reviewed-on: https://chromium-review.googlesource.com/569523
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the previous version of the code, we were counting ESOF (every
ms) to figure out when to clear the resume bit, and then using ESOF
counts again to wait for the USB interface to resume.
This missed the fact that ESOF (expected SOF) interrupts are not
triggered when SOF are actually received.
Somehow, this worked fine in most cases, except that sometimes the
last ESOF would race with the RXDP/RXDM going to state 2, and we
would not know that the resume completed successfully.
Let's also count SOF interrupts, and also take a received SOF as an
indicator of a successful resume.
While we're at it, trim down USB debugging messages, and add a line
when resume is successful.
BRANCH=none
BUG=b:35587173
TEST=Connect hammer, force autosuspend using:
DEVICE=$(dirname $(grep 5022 /sys/bus/usb/devices/*/idProduct))
echo 500 > $DEVICE/power/autosuspend_delay_ms
echo auto > $DEVICE/power/control
Add debugging in hammer code, make sure that usb_wake_done goes
back to 1 after resume succeeds.
Change-Id: I206c9c6b3066a3a337b6bd2370c9d0c6a9e2396c
Reviewed-on: https://chromium-review.googlesource.com/569522
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@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>
The variable is_high_power was only used if a board was using charge
ramping. However, we can get rid of the variable entirely.
Additionally some of the intermediate gpio_signal variables can be
removed as well.
BUG=none
BRANCH=none
TEST=Build a board that uses the bq24392 but does not charge ramp.
Verify that there are no compliation errors.
Change-Id: I7edaa74f5029c08662d8c4a15c973beae9729fdf
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/601533
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@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>
In the function bd9995x_battery_charging_profile_settings, the current
values for trickle, precharge, and fastcharge were being set. Fastcharge
current level was being set via
charger_set_current(PD_MAX_CURRENT_MA). By calling this function with
a non-zero parameter, charging will always be enabled. In addition,
PD_MAX_CURRENT_MA is an input current limit and doesn't neceassrily
apply to the fastcharge current level which would be read from the
fuel gauge. The other side effect is that by enabling charging, VSYS
is being set to battery->voltage_min which reverts VSYS being set to
battery->voltage_max in the init routine.
Per Rohm, all charging profile registers should be set prior to
enabling charging. On Coral, enabling charging at this point was
leading to VSYS collapse when no battery was connected or a fully
depleted battery case. I also believe that enabling charging here
exacerbates other issues we've been running into with low battery
startup cases.
BUG=b:64388515
BRANCH=eve
TEST=On Coral tested both no battery a fully depleted battery
cases. Verified that without the call to charger_set_current() that
VSYS consistently collapses and that after removing this call, the
start up was stable and the battery begins charging.
Change-Id: Ice20ed5d8147fe9ad8faa754286a2ec8a784f8d8
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/602493
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@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>
If flash_ec was run without `servod` running and servod is needed, an
error message is printed out.
ERROR: Cannot communicate with servo. is servod running ?
However, in the case of flashing an stm32 without servod running,
execution would continue and would lead to claim_pty freezing and
thawing a bunch of unrelated processes. I believe the reason is that
the "die" was run in a subshell and therefore execution continued.
This commit now changes the way that servo_ec_uart_pty() works. If no
PTY is found, then flash_ec exits printing out the error message.
Additonally, claim_pty() will now warn if no arguments are passed to it
instead of finding random victims.
BUG=chromium:751386
BRANCH=maybe some fw branches.
TEST=Without servod running, try `./util/flash_ec --board hammer`;
Verify that flash_ec exists after the call to die.
Change-Id: I50784e0c43bbf0e32d408261cb83029377b576a0
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/598506
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
this adds CLI support for the new PD_CHIP_ON subcommand of
ec_pd_control_cmd.
TEST=rebuilt ectool to see if "ectool pdcontrol on" does something useful.
copied new build to electro:
ec> i2cxfer rlen 0 0x50 1 0x10
Unknown error
Usage: i2cxfer r/r16/rlen/w/w16 port addr offset [value | len]
ec>
ap$ /tmp/ectool pdcontrol on 0
ec> i2cxfer rlen 0 0x50 1 0x10
Data: aa2934ad000000000000010000050500
ec>
so, "pdcontrol on" had the desired effect of bringing the chip
out of sleep mode.
BRANCH=none
BUG=b:35586895
Change-Id: I5275254fe797dda921a352b72f1683e1967efe58
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/599361
Reviewed-by: Shawn N <shawnn@chromium.org>
add a subcommand to the PD_CONTROL message to power up a specific
TCPC. in practice, this typically just takes the TCPC out of sleep
mode for cases where sleep mode is controlled by the EC.
under the covers, board_set_tcpc_power_mode() gets a weak function
definition so we don't need to special case this everywhere.
TEST="make buildall" passes; "make tests" passes for reef.
BRANCH=none
BUG=b:35586895
Change-Id: Ib50e265d11eca10c3714049d8cfdf2657eff48c1
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/596796
Reviewed-by: Shawn N <shawnn@chromium.org>
One of the items that the presubmit check checks is that if any source
file has been modified, the unit tests are run again. However, flash_ec
is included in the list of files. This commit removes flash_ec from the
candidates because it's not run in any unit tests anyways and it's a
shell script that is not compiled.
Additionally, ignore changes to the presubmit_check.sh itself.
BUG=None
BRANCH=None
TEST=modify flash_ec, verify that presubmit check doesn't complain about
not running make buildall.
Change-Id: I473f269c7f0bba9be3216fcec39f266d896fb908
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/598505
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@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>
When an image with non-default board ID fields is released, the
generated tarball name should include the Board ID values to allow to
tell between images of the same version locked for different boards.
BRANCH=none
BUG=none
TEST=ran create_released_image.sh with and without specifying Board ID
fields, observed properly named file generated in both cases
Change-Id: I5f60a0e547d93c78caee34a9c307fc93f824b2ae
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/597121
Reviewed-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Nick Sanders <nsanders@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>
The new signer (version: 1.2 00840c1b6) allows hex values in the
manifest, which means there is no need to explicitly convert the
values before adding them to the manifest.
A nice side effect of this is the fact that there is no need to care
about the sign of the values any more, the signer does the right
thing.
BRANCH=none
BUG=none
TEST=built an image using the following invocation:
$ make BOARD=cr50 H1_DEVIDS='0x12009015 0x90e95664' -j
and successfully ran it on a device. Note that the old signer was
chocking on hex values exceeding 0x7fffffff, the new one handles
them properly.
Change-Id: I08c0339f922d287c82d56fb51570bfbf7107531e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/598728
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Save a small amount of time when the USB resume is making the chip boot
from deep-sleep by removing the verbose serial traces in main and
increasing the usb initialization priority.
This brings us from borderline timings wrt the USB specification to a
reasonable margin.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:38160821
TEST=run on hotelgolf, go to deep-sleep on USB-suspend.
On USB resume, measure the time from CPU boot to the end of usb_init
using the CPU cycle count. We are shaving 1.3ms.
Change-Id: Ia5bf69c0ca26748dec59a87f3908a5fe68296b36
Reviewed-on: https://chromium-review.googlesource.com/563206
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
