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>
When the EC is running in RO mode (ie for recovery), disable USB PD
communication (just use the type-C resistor to 5V/1.5A or 5V/3A)
in order to minimize the attack surface.
BUG=chrome-os-partner:49744
BRANCH=none
TEST=Manuel
In system.c, initialized static int force_locked to 1
> reboot ap-off
> chgsup
port=1, type=1, cur=3000mA, vtg=5000mV
Change-Id: I1b6bf302d235e9ba2f4c79250c02e97447d564c1
Reviewed-on: https://chromium-review.googlesource.com/391038
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit 360fbde14dd18e19878a3e0021dec537ecccba49)
Reviewed-on: https://chromium-review.googlesource.com/389691
Commit-Ready: Shawn N <shawnn@chromium.org>
This change adds support for signing SHA-384 & 512 hashes
when using PKCS#1 padding (CR50 does not support
SHA-384 & 512 at the moment, the actual hashing is to be
done on the host).
BRANCH=none
BUG=chrome-os-partner:59754
TEST=TCG tests pass
Change-Id: I78e774639a7968cbb50e58cdd0bf479e64123630
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/415218
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
On the bd9995*, back boosting may occur when actual battery voltage
drops below VBAT register setting. Maintain the VBAT register at the
battery-requested charge voltage even when not charging to ensure the
bd9995* doesn't become a back boosted animal.
BUG=chrome-os-partner:56139,chrome-os-partner:54248
BRANCH=gru
TEST=Manual on kevin, unplug AC, run 'charger', verify that 'V_batt' is
maintained at 8688 mV. Attach charger, verify 'V_batt' stays at 8688 mV
and device charges.
Change-Id: Ia0cc7f9279cb460e20a8faf332ad432067dc5482
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400087
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Enabling and disabling sleep in the rdd interrupt is redundant because
USB already takes care of that. When USB is initialized it will disable
sleep. If it is released or suspended then it will re-enable sleep. This
change removes the sleep enable and disable from the rdd interrupt. With
this change now sleep can be enabled while suzyq is still plugged in
using the command 'ccd disable'.
BUG=none
BRANCH=none
TEST=manual
The consoles still work
Updating the EC, AP and Cr50 still works
After running 'reboot ap-off' in the EC console and 'ccd
disable' in the Cr50 console Cr50 will go to sleep.
Change-Id: Ie8e6201e9fd611c514e93bc70d298d3b0d228611
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413606
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch introduces version 6 of the cr50 USB update protocol. This
version allows to multiplex TPM vendor and extension commands over the
same USB endpoint which is used for firmware updates.
When channeling TPM vendor commands the USB update frame looks as follows:
4 bytes 4 bytes 4 bytes 2 bytes variable size
+-----------+--------------+---------------+-----------+------~~~-------+
+ total size| block digest | EXT_CMD | Vend. sub.| data |
+-----------+--------------+---------------+-----------+------~~~-------+
Where 'Vend. sub' is the vendor subcommand, and data field is
subcommand dependent. The target tells between update PDUs and
encapsulated vendor subcommands by looking at the EXT_CMD value - it
is set to 0xbaccd00a and as such is guaranteed not to be a valid
update PDU destination address.
In the previous protocol versions target reset was requested by the
host sending a 4 byte PDU after the target receives the UPGRADE_DONE
message and moves the state machine to the 'awaiting_reset' state.
With the ability to transfer vendor commands, there is no need for the
target to have a special state for reset. The host can send the posted
or immediate reboot request using the appropriate vendor command.
As a result the 'awaiting_reset' state has been removed, the target
accepts vendor commands only when state machine is in the rx_idle
state.
Vendor command response size is not fixed, it is subcommand dependent.
In the current implementation the total size of the vendor command PDU
can not exceed 64 bytes, as there is no reassembly on the target side.
For backwards compatibility in case the target is running protocol
version earlier than 6, the 4 byte PDU is still sent to the target
after UPGRADE_DONE is sent.
BRANCH=none
BUG=chrome-os-partner:60013
TEST=tested updates on Reef and Gru, observed that it is possible to
update earlier versions of firmware, and that it is possible to
request immediate and posted reset (depending on the presence of
the -u flag in the usb_updater invocation).
Change-Id: I6ea9e9f742c96b8ab0670e9cec87a83cd47bb20e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414948
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When usb update errors happen it helps a lot to be able to see the
actual error code returned by the target and where the error was
generated.
This patch adds a few printouts to help with debugging.
BRANCH=none
BUG=none
TEST=observed proper error messages generated while debugging
introduction of extension/vendor commands transfer over USB.
Change-Id: I06c77e7467f7f9547704c88c4b673866fb2e6032
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414947
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Until extension commands using incompatible TPM command code are
phased out, the function sending vendor/extension commands to the TPM
needs to be aware of the subcommand code and use the matching TPM
command code.
BRANCH=none
BUG=chrome-os-partner:60013
TEST=with the rest of the patches applied both posted and immediate
reset commands operate on Gru as expected.
Change-Id: I8977df22e4c2fadfd3427c0b4f70035f7f532e00
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414946
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Let's make sure that both embedded and host side use the same command
definitions. To avoid host compilation problems move the definitions
into a separate file.
BRANCH=none
BUG=none
TEST=compilation still works.
Change-Id: Id0d85a51aebabed0637965b3b19d7ed42c46e75e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414945
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Cr50 updates in development environment should allow resetting the
device immediately after update (without the need for SYS_RST_L to be
toggled).
This patch adds a vendor command to do just that.
BRANCH=none
BUG=chrome-os-partner:60013. chrome-os-partner:60321
TEST=none yet, with the rest of the patches applied the target gets
rebooted immediately after a cr50 code update. Also, observed
that flashing the console does not quite work, opend
crosbug.com/p/60321 to address this.
Change-Id: Ia6f99ad6d22004347ad02aac2cbf4dd6c5594928
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414442
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Some upcoming changes will introduce transfer of vendor and extension
commands over the usb updater endpoint.
This patch exposes a function which allows to verify integrity of
received USB PDUs.
BRANCH=none
BUG=chrome-os-partner:60013
TEST=no functional changes, usb_updater still works fine.
Change-Id: I8d9e6746ef0dfbb17bba618410514ca047a59a45
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414441
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Just for consistency sake, make all normal messages generated by the
utility in the course of firmware update start with lower case letters
and all error messages start with upper case letters.
BRANCH=none
BUG=none
TEST=make buildall -j still succeeds
Change-Id: Ifb0bd8dec4c2bb5cbbb2c93b1918fc699c2f33dd
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414944
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This is just a clean up patch, unifying all cases where endian
conversions are used in the usb updater source code.
BRANCH=none
BUG=none
TEST=usb update of cr50 is still possible on gru (which uses the code
being changed).
Change-Id: I362e9762493854b4fdbb9ec15c2cb363003f258a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414443
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
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.
BUG=chrome-os-partner:58969
BRANCH=none
TEST=Manually tested on reef. Discharge is in the permissible range.
'chgstate' console command prints correct values.
Change-Id: I64afa992e50b6e18daf43edf237fde8cf658a8a2
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/413153
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>
