With expanding USB interface to processing vendor commands and to
query current version running on the chip, there are now occurrences
of fw_upgrade_complete() invoked at the device startup without actual
data transfer.
This causes clearing rollback counter before it is actually examined.
Let's not invoke fw_upgrade_complete() unless there was actual data
transferred for flash programming.
BRANCH=none
BUG=none
TEST=verified on chromebook reboots that the counter value is not
changed until the rollback condition is checked.
Change-Id: I50bf450882b001ba1c2f38657d27f87f8596b3e2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/422454
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Perform PKCS1-padding-only signing for RSASSA if hashing algorithm is
TPM_ALG_NULL.
This feature is guarded by SUPPORT_PADDING_ONLY_RSASSA macro in
tpm2/Implementation.h.
BUG=chrome-os-partner:60967
BRANCH=none
TEST=On a unowned machine with TPM2: corp enroll, login, install
a network certificate (gECC or GMC), then:
a) retrieve the public key from the installed certificate
LIBCHAPS=`ls /usr/lib**/libchaps.so`
CERTID=`pkcs11-tool --module=$LIBCHAPS --slot=1 --type=cert \
-O | grep "ID:" | awk '{print $2}'`
pkcs11-tool --module=$LIBCHAPS --slot=1 --id=$CERTID \
--type=cert -r > /tmp/cert
openssl x509 -inform der -pubkey -noout -in /tmp/cert > /tmp/pub.key
b) sign a sample text using the private key for the certificate and
MD5-RSA-PKCS mechanism, not supported by TPM2_Sign command:
echo "ABCDEF" > /tmp/1.txt
pkcs11-tool --module=$LIBCHAPS --slot=1 --id=$CERTID --sign \
-i /tmp/1.txt -o /tmp/1.sig -m MD5-RSA-PKCS
c) verify signature:
openssl dgst -md5 -verify /tmp/pub.key \
-signature /tmp/1.sig /tmp/1.txt
Step (b) should succeed and step (c) should return "Verified OK".
Change-Id: I0d7a11c48cdb04e37748f7255b98e9e023481a96
Signed-off-by: Andrey Pronin <apronin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420854
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
This change takes away control of trackpad from EC entirely. This will
prevent EC from interfering with the OS's interaction with the trackpad
for firmware update, device detection at boot, or entering S3.
Disadvantages are the trackpad will stay on (thus can wake up the system
unintentionally) when the system enters S3 in laptop mode then
transitions to tablet mode, or vice versa: the trackpad will stay off
(thus cannot wake up the system) when the system enters S3 in tablet mode
then transitions to laptop mode.
However, these corner cases can be handled by waking up the system upon
mode transition. The OS can then disable or enable the trackpad depending
on the transition direction (laptop <-> tablet) and re-enters S3. Or the
OS can leave the system running because mode transition implies a user's
intention to start interacting with the device.
The keyboard will continue to be managed by EC and disabled or enabled
upon mode transition.
BUG=chrome-os-partner:61058
BRANCH=reef
TEST=Put device into S3 in tablet mode. Wake it up.
Change-Id: I2f4aa72d704c6562dd861b105225b1995226a09a
Reviewed-on: https://chromium-review.googlesource.com/421275
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This patch enables accels in S3. Accels are required to calculate a
lid angle. EC enables/disables keyboard based on lid angles. EC
needs to be able to control it because the kernel is in sleep state
in S3.
BUG=chrome-os-partner:58792
BRANCH=reef
TEST=lid angles are calculated correctly in S0 and S3.
Change-Id: I13c69a47da2c6521cd0c03c66cf061deb3f4fabd
Reviewed-on: https://chromium-review.googlesource.com/421276
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The CONFIG_FLASH_NVMEM option implements persistent, reliable storage
regions in flash. This adds CONFIG_FLASH_NVMEM_VARS, which uses one of
those storage regions for free-form variables.
Refer to the comments in include/nvmem_vars.h and common/nvmem_vars.c
for usage and implementation details.
BUG=chrome-os-partner:61107
BRANCH=none
TEST=make runtests
This CL includes a number of new tests, specifically for this feature.
No target boards use this feature yet so there's nothing to test on
actual hardware, but the test/nvmem_vars executable includes console
commands ("get", "set", "print") to try it out.
Change-Id: I8597415dc3b00a1462f5b164eeb5073129030525
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414194
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Provide the calling stubs for p256 sign, verify, point mul, etc.
This also drops third_party/cryptoc/p256_ec and p256_ecdsa from the
image. And fewer routines from cryptoc/p256.c remain as well.
BRANCH=none
BUG=none
TEST=tcg_tests pass, test/tpm_test/tpmtest.py pass
Change-Id: Ib6c35f5d34a2c8434e78b44cbef8b69802734c50
Signed-off-by: Marius Schilder <mschilder@google.com>
Reviewed-on: https://chromium-review.googlesource.com/422942
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Trybot-Ready: Marius Schilder <mschilder@chromium.org>
After every reboot, we were resetting the write protect and console
lock states back to default. With this change the wp and lock states
will be preserved through deep sleep. They will still be reset on any
other type of reboot (like Power On reset or panic).
The states are also cleared if the system detects a rollback even when
booting from the deep sleep.
With this patch it is going to be impossible to remove hardware write
protection guarding writes into AP and EC firmware flash, unless the
cr50 console is unlocked.
Locking the console would reinstate hardware write protection
automatically even if it was disabled when the console was unlocked.
Two long life scratch register 1 bits are used to keep the console and
write protect states over resets. To make code cleaner bitmap
assignments of the long life scratch register is put in its own
include file.
BUG=chrome-os-partner:58961
BRANCH=none
TEST=manual
On prod/dev images verify that the default wp and console lock
states are still correct.
change the lock and write protect states from the default and
verify they are preserved through deep sleep.
reboot cr50 and make sure that they are reset.
unlock the console and enable flash writes, then set fallback
counter on cr50 to the value of 6 (rw 0x40000128 1; rw
0x4000012c 6) and put the AP into deep sleep by hitting
Alt-H-VolUp.
In five minutes press the power button on the device to bring
it back from s5. Observe cr50 fall back to an older image and
console lock and wp disabled.
Change-Id: Ie7e62cb0b2eda49b04a592ee1d0903e83246b045
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420812
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
- CHG port can connect as SNK at different voltage levels
- DUT port presents as SNK only
- DUT port uses fixed polarity since it has a fixed cable
- Not supporting ALT or ALT_DP modes in terms of svdm messages at
this point.
- No support yet for USB mux.
BUG=chromium:571476
BRANCH=None
TEST=Manual
CHG port: Tested with Zinger and Plankton and 5/12/20V VBUS levels.
DUT port: Tested against Reef and verified that port reached SNK_READY.
Change-Id: Idbdc963ba077a14efad9eea3b047f35a5a605bd6
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/419117
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
When including USB PD support, the image won't fit in the default RO
size of 0xf000, but does fit in the 0x10000 RW. This change removes
PSTATE and increases the RO to 0x10000.
BRANCH=none
BUG=chrome-os-partner:61170
TEST=manual
Verfied the image still builds and can run after updating via
util/flash_ec and via /usb_updater/fw_update.py -b servo_v4.json
Change-Id: I8f60bb1f107060e26390e6c8292a3add58703c0d
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/422450
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Auto-role toggle on the anx74xx does not function correctly with
e-marked cables and cannot be used.
Also check for TCPC support for auto-toggle at runtime, to allow
auto-toggle supported TCPC to be used alongside an unsupported part.
(from CL:420405)
BUG=chrome-os-partner:60890
BRANCH=reef
TEST=Manual on reef, boot to S0:
`pd 0 state`: Toggling between SRC_DISCONNECTED / SNK_DISCONNECTED
`pd 1 state`: DRP_AUTO_TOGGLE
Also verify port 0 can become sink + source correctly in S0.
Change-Id: Iafdedf31773feef23923cefe1f4fb02fcffda120
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420866
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
There are plans to extend use of the LONG_LIFE_SCRATCH1 register for
other purposes than keeping board properties. Just as the board
properties, the new use is also very board specific. This patch moves
the board properties code from chip/g to board/cr50, where it belongs.
Instead of reading board properties bitmap and checking if various
bits are set, api functions are now provided to allow determining
various properties settings without actually looking at the properties
bitmap.
CQ-DEPEND=CL:*313057
BRANCH=none
BUG=chrome-os-partner:58961
TEST=verified that both Gru and Reef boot with the new image,
additionally, on Reef confirmed that it is possible to
communicate with the H1 over USB, and that plt_reset signal is
handled properly.
Change-Id: Id0dd2dc16389f773a149fb01eee1ce7bb99c4547
Reviewed-on: https://chromium-review.googlesource.com/422081
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Since ec doesn't support old-style host command, this CL removes
unsupported parts in npcx's lpc driver and lets the hand-shaking
mechanism between host and ec as easy as possible. It makes sure only
following conditions that ec can clear processing bit of host command.
1. Received LRESET signal.
2. In lpc_init() initialization function caused by sysjump.
3. If command is valid, it will be cleared in lpc_send_response_packet()
called by host command task.
4. If command is invalid, it will be cleared in lpc_send_response()
after the response package is ready.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make BOARD=wheatley; do stress test on wheatley.
Change-Id: I53d17fd9e09b7fb080e4bf71437392bf43db6258
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/422707
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We use the latest nde32 official toolchain to verify the bug of
GP-related instruction was fixed (we can remove "-mno-gp-direct" flag to
save code space), and code optimization.
We got some error on official toolchain, so we fix them as well:
- "break" instead of "trap".
N8 CPU does not support "trap" instruction to generate an unconditional
trap exception, but no error occurred while compiling by using current
GCC toolchain (this will trigger a reserved instruction exception,
so "ASSERT()" still work).
We use "break" to generate a exception in this change.
- "li" instead of "la".
To fix the error: "Error: la must use with symbol".
Also fix:
- The "_bss_start" has to be word-aligned because we use "lwi" instruction
to load a word from the memory into the general register.
BRANCH=none
BUG=none
TEST=1. console command "crash assert".
2. check registers settings: f02030h, f0203eh, and f02044h.
Change-Id: I33404a1d60eeebfa135bf43d3a7d5e73ab35c678
Reviewed-on: https://chromium-review.googlesource.com/422608
Commit-Ready: Dino Li <Dino.Li@ite.com.tw>
Tested-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The earlier change introduced the uninitialized variable bug, which
was not caught by the compiler.
Let's make sure the variable is always initialized, and also let's add
a message informing the user that the binary image is ignored when -f
or -c command line options are given.
BRANCH=none
BUG=chrome-os-partner:55667
TEST=there is no accidental attempts to erase the inactive firmware
any more. The message is printed when the binary image is ignored.
Change-Id: If67841fa3933e7c2df772348ed5308ff722a6e3a
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/421498
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The idle task on g devices seems to be very close to its stack
capacity. Adding debug code, print statements, etc., causes occasional
stack overflow panics.
Let's increase the stack size to avoid these problems.
BRANCH=none
BUG=none
TEST=the stack overflow panics do not happen anymore when debug
processing on the idle task context is added.
Change-Id: Id259719c1b644e2743f3bb3dbf0d99d667662901
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/422078
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Battery need some time to provide power when releases
shipping mode or plug in battery at first time.
BUG=chrome-os-partner:60921, 59904
BRANCH=master
TEST=remove battery & AC, then insert battery & AC,
system can boot up.
Change-Id: I33ca4df54e0b02e68ade9426864561dae8c57851
Signed-off-by: Ryan Zhang <Ryan.Zhang@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/419881
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If VBUS is lost and then quickly recovers, we may detect the re-presence
of the charger before charge_ramp has been informed about the loss. In
this case, charge manager's supplier registration time will precede our
ACTIVE_OC_INFO timestamp. Fix our timestamp comparison to correctly
detect OC in this case.
In addition, correctly mark all OC events stale once we have encountered
a disconnect / reconnect that we determine not to be related to OC.
BUG=chrome-os-partner:56367
TEST=Manual on reef, verify Motorola 800mA DCP charger settles at ~800mA
after OC.
BRANCH=reef
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I3fdfd3929d07c60b82655999dd5aa731c1c7bc9b
Reviewed-on: https://chromium-review.googlesource.com/419775
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 19ba4a053027486ca415c4d703944b38e3c5e652)
Reviewed-on: https://chromium-review.googlesource.com/421208
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds a option to use the vendor command
VENDOR_CC_INVALIDATE_INACTIVE_RW to invalidate the inactive rw image.
BUG=chrome-os-partner:55667
BRANCH=none
TEST=run 'usb_updater -c' use the cr50 console to verify the inactive rw
image version is 'Error'
Change-Id: Id460f7ac9f20146902da7596613bee566f473dd2
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/421141
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
powerlog.py can access sweetberry and log power data.
Also included are marlin and kevin example board configs.
BUG=chromium:608039
TEST=log power data
BRANCH=None
Change-Id: I0f868d95d17d86522dca045a227a824563f93cd0
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413293
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This adds a vendor command to invalidate the old rw. It should be used
when the tpm has been validated.
BUG=chrome-os-partner:55667
BRANCH=none
TEST=manual
run the vendor command
run 'ver' on the cr50 console and verify the inactive RW version
is Error
reboot cr50 10 times and make sure there is no rollback.
Change-Id: Ibec3dde77d6b1ab921e43613d54638b7318f3f57
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420407
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The EC on Eve has VCC1_RST connected to 3.3DSW which drops when
resetting for recovery.
Since I need this to work on current boards treat Eve the same as
Wheatley and use the workaround that always reports reset-pin
instead of power-on status.
BUG=chrome-os-partner:61028
BRANCH=none
TEST=successfully enter recovery mode on eve with the keyboard
Change-Id: Ica583d9a95d78689ee1b21ccfa882fced2a414d9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/421128
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously, an assert was checking the port value after the
port value had been converted to the controller. Instead, verify
that the value is not negative, and return if it is.
The if sequence generates much less code than the ASSERT, and protects
both paths.
Fixes coverity warning 141748: Negative array index read
42 files changed.
Total size change: -1248 bytes.
Average size change: -29 bytes.
These platforms increased in size:
lucid/RO/ec.RO.flat grew by 4 bytes: (64404 to 64408)
lucid/RW/ec.RW.flat grew by 20 bytes: (63996 to 64016)
pyro/RO/ec.RO.flat grew by 120 bytes: (131212 to 131332)
pyro/RW/ec.RW.flat grew by 144 bytes: (130764 to 130908)
TEST=Build
BUG=None
BRANCH=None
Change-Id: I8d39db04c4ca3194f99e17840365429ed2d39390
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/371401
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The previous code split the initialization of digest_len
out into a separate area than were it was used. This confused gcc
into thinking that the variable might be uninitialized when it was
used later. By putting it all in one area, we save a couple of bytes
and make things more plain for the compiler.
This does not change the size of any ec.*.flat file.
BRANCH=none
BUG=none
TEST=build succeeds under GCC 4.9.2, 5.3 and 6.2
Change-Id: I1e21a13e3d7f9dc296296db6465ec975187a1cc0
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/411407
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Looking at these warnings, none of these are real issues, so just
initialize the variables to make GCC happy. There might be a way to
rewrite the functions to make GCC be less confused, but I haven't
figured it out yet, and the solutions I tried generally ended up
increasing the binary size.
The function spi_nor_read_jedec_id() will initialize the variables or
return an error, so there isn't a path where they would be used without
initialization.
common/spi_nor.c: In function 'command_spi_nor_info':
common/spi_nor.c:771:3: error: 'mfn_id' may be used uninitialized in
this function [-Werror=maybe-uninitialized]
common/spi_nor.c:771:3: error: 'mfn_bank' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
The function spi_nor_device_discover_sfdp_page_size() will either set
these variables or return an error, so these should never actually be
uninitialized when they get used.
common/spi_nor.c: In function 'spi_nor_init':
common/spi_nor.c:449:30: error: 'capacity' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
common/spi_nor.c:450:31: error: 'page_size' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
This does not change the size of any ec.*.flat file.
BRANCH=none
BUG=none
TEST=build succeeds under GCC 4.9.2, 5.3, and 6.2
Change-Id: I6bbe73b4acf3dcbbaa03d9cbf1dcdfeb883c0a6d
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403503
Reviewed-by: Shawn N <shawnn@chromium.org>
word_in_value shouldn't be able to be used without being initialized,
so just initialize it to make GCC 5.3 happy. It's configured separately
in the (last_write_pointer & 3) and (!(last_write_pointer & 3)) paths,
so it can't actually slip through uninitialized.
There is probably a way to rwrite this that won't confuse GCC as much,
but I haven't found it yet. The solutions I did try generally ended
up increasing the binary size, so I'm falling back to just initializing
the variable.
chip/g/i2cs.c: In function '_i2cs_write_complete_int':
chip/g/i2cs.c:178:19: error: 'word_in_value' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
This does not change the size of any ec.*.flat file.
BRANCH=none
BUG=none
TEST=build succeeds under GCC 4.9.2, 5.3 and 6.2
Change-Id: Iaf8641b3d252c494ad13fbeb8ad8ece3cdfe6e76
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403504
Reviewed-by: Shawn N <shawnn@chromium.org>
GCC 5.3 and 6.2 complain about the the i2c_irqs array being defined as
static because it's used by a non-static inline function.
Since i2c_handle_sda_irq is only used in the i2c.c file, it makes sense
to make it static.
Additionally, remove the inline keyword for i2c_handle_sda_irq since
it's a huge function, if it were used more than once, we wouldn't want
it to be inlined.
chip/npcx/i2c.c:462:22: error: 'i2c_irqs' is static but used in inline
function 'i2c_handle_sda_irq' which is not static [-Werror]
task_disable_irq(i2c_irqs[controller]);
npcx_evb/RW/ec.RW and npcx_evb_arm/RW/ec.RW.flat each shrank by 20 bytes.
npcx_evb/RO/ec.RO and npcx_evb_arm/RO/ec.RO.flat each shrank by 64 bytes
BUG=none
BRANCH=none
TEST=make buildall passes under GCC 4.9.2, 5.3 and 6.2
Change-Id: I79691bb57083fd925f9c4be06de706f676a1d043
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403502
Reviewed-by: Shawn N <shawnn@chromium.org>
Avoid building and including crypto test code in
prod builds: only define CRYPTO_TEST_SETUP when
CR50_DEV is defined.
At HEAD, this change drops the size of prod ec.RW.bin
from 200704 to 188416.
BRANCH=none
BUG=chrome-os-partner:54104
TEST=build succeeds
Change-Id: I1e6018ec917dbe71cb445206ce232b8ea7a46cb1
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/418489
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Reef discharges on AC till the charger is detected and settled but
when booting from the cut-off mode this will kill the power hence
do not discharge on AC when battery is still waking up and settled.
BUG=chrome-os-partner:60974
BRANCH=none
TEST=Reef can boot from cut-off mode to S0.
Change-Id: I34c5fd8df03a1e60736541c85627fbb18a6d56f7
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/420467
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There's a small period between ec cleared EC_LPC_CMDR_BUSY status bit
for sysjump and executed notify hook function to let lpc driver disable
lpc's interrupts. If ec received a new host command in this period,
EC_LPC_CMDR_BUSY status bit has chance not to be cleared since ec
already jumped to the the other region. In case ec and host enter
dead-lock loop, we need to clear it on lpc_init().
Since HIPMnST only can be reset by core domain reset, it's better to
clear EC_LPC_CMDR_BUSY status bit when LRESET asserted. It makes host
can reset host command mechanism if something wrong.
BRANCH=none
BUG=chrome-os-partner:60928
TEST=make BOARD=reef; pass the tests mentioned in issue #60928
Change-Id: I08ac0515cb2cfee277a7c7704d131574d928fb6b
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/419908
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
If a partner port sends a packet at approximately the same time as we
send a packet, we may end up with the initial packet followed by the
GOOD_CRC reply in our HW FIFO. Don't automatically discard the first
packet in the FIFO. Instead, discard the packet only if it's a GOOD_CRC
packet. And, modify our get_message function to automatically discard
GOOD_CRC in search of a meaningful packet.
In addition, due to interrupt latency, we can't rely on receiving one
interrupt per incoming packet. If our Rx FIFO is non-empty, assume that
it contains at least one packet.
BUG=chrome-os-partner:60242
BRANCH=gru
TEST=Manual on kevin, attach Apple dongle with no inputs. Attach zinger,
verify we negotiate to ~20V. Repeat 10x and verify negotiation is
successful each time.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I7e4430fc2b7ed44b1aa4b561d72c8e1e964b245a
Reviewed-on: https://chromium-review.googlesource.com/414927
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit 373f5dfd75e8ea5074d26fc6392eafe83de4f905)
Reviewed-on: https://chromium-review.googlesource.com/419186
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
In some cases, the virtual battery code creates
transactions that violate SB spec.
One example:
If the host command is structured as two messages -
a write to 0x03 (reg addr), followed by two bytes of write data,
the first byte of the second message (write data) will be sent to
virtual_battery_read(), as if it were a reg read request.
Let's do the following change for virtual battery:
1. Parse the command more carefully with state machines.
2. Support write caching for some critical registers.
3. Cache more attributes (0x03 and 0x0f).
BUG=chrome-os-partner:59239, chromium:659819
BRANCH=none
TEST='power_supply_info' works on kevin
Change-Id: Icdeb12b21f0dc3c329f29b206b7b9395ca4c9998
Reviewed-on: https://chromium-review.googlesource.com/407987
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This is useful with Apple's HDMI adapter, as the code that sends
the discovery message will also swap vconn as required.
BRANCH=none
BUG=chromium:644663
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
display works.
Change-Id: I21d47c69e2c7153a5d808dedcb1abe360ce3f5c0
Reviewed-on: https://chromium-review.googlesource.com/415698
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
During discovery, if adapter requests vconn power in the AMA flags,
make sure that we provide vconn.
This, for example, is necessary for the Apple HDMI adapter to work
on boot, when connected in S5. In that case, adapter does request
vconn swap, but we reject that as the system is off, and, therefore
5V supply is off. On boot, we send another discovery request, which
will detect this case and swap the power.
BRANCH=none
BUG=chromium:644663
TEST=On elm, S5. Plug adapter with power+HDMI. Switch on elm,
type "pd 0 vdm ident" in console, display works.
Change-Id: I55b6658c2bc0574b8427ae086f61daf03730a725
Reviewed-on: https://chromium-review.googlesource.com/415697
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Rename the variable to actually tell us what it does (it sends a
Discover Identity command), instead of littering the code with
comments explaining why we set DATA_SWAPPED when the data roles
have not really been swapped.
BRANCH=none
BUG=chromium:644663
TEST=make buildall -j
Change-Id: Idbad38e48a55d6518ef82b32a4d96fee65264aae
Reviewed-on: https://chromium-review.googlesource.com/415696
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
To avoid inrush current from the external charger, enable discharge
on AC till the new charger is detected and charge detect delay has
passed.
BUG=chrome-os-partner:60547
BRANCH=none
TEST=Multiple Ramp Resets and inrush current is not observed.
Change-Id: Ie3317fa6e6c2e8f00d4ce7cb9c6bee81c50d7bb2
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/417168
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>
(from CL:415672)
Slow the keyboard scan rate from 50 us to 80 us. This compensates the
additional delay added to the KBO line by Silego / H1.
BUG=chrome-os-partner:60335,chrome-os-partner:60615
BRANCH=reef
TEST=check press key "f3" then system only output "f3" scan code.
Change-Id: Icaa8f040c20f72b1fa1c9260f86b29da8c69ec2b
Reviewed-on: https://chromium-review.googlesource.com/419577
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The Eve board version will use Hi-Z to get 3 values out of
each bit in the version. In order to support this read each
strap and determine the ternary encoding.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=ensure P0 reports 0 and P1 reports 1, test with an unused
GPIO to ensure that a tristate pin will also be read properly.
Change-Id: Ib1f569e2b06bed0995eb70f24c90533cbccb0fb8
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/418978
Reviewed-by: Scott Collyer <scollyer@chromium.org>
cr50 has an internal pull-down on this pin so the EC should match it
to prevent leakage.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=build and boot on eve and verify hibernate enter/exit
Change-Id: I3eba0661211d356783c0c710f0d7d5fe11fd6c26
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/415225
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Turn off the charger BGATE when the system is hibernated to
save maximum power.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=build and boot on eve P0 and enter hibernate
Change-Id: I8c694789276cf4e50e32e6fe0956a3743380ca3a
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414542
Reviewed-by: Scott Collyer <scollyer@chromium.org>
If keeping HDMI/DP Type-C cable connected doing sysjump sets
HPD signal to high while it is already high from previous state,
so the SOC does not see a pulse. Manually set it low so it will
be asserted high again to send a pulse to the SOC.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=connect HDMI dongle, boot with EC SW sync enabled and see
that the display is still working in the OS.
Change-Id: I7b6ea24880bf4a0c44f7c92d9173372404d3fc4b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414541
Reviewed-by: Scott Collyer <scollyer@chromium.org>
