We need 2 accelerometer for tablet mode. If one of them is not working,
disable tablet mode. We will stay in clamshell mode, lid angle will be
always unreliable.
BUG=chrome-os-partner:61141
TEST=On kevin with a single sensor. Check we are in clamshell mode
when rebooting the EC.
BRANCH=kevin
Change-Id: I7bf6cdc9d85370fce20e5183622b4bc18f4f5f99
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424184
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Fix issue where the block is calculated wrong since the offset that gets
added is wrongly EEPROM_BLOCK_COUNT_PSTORE which is the number of
total blocks rather than the starting block given by
EEPROM_BLOCK_START_PSTORE.
TEST=Build test, ran on board with stubbed out functions.
BUG=none
BRANCH=none
Change-Id: Ide4839845353c2b9f95a37eb689c8d800169bb22
Signed-off-by: Moritz Fischer <moritz.fischer@ettus.com>
Reviewed-on: https://chromium-review.googlesource.com/424182
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added common code for charger profile override for fast charging.
Fast charging configs can be defined in the respective board battery
file and use the common code for imposing the custom data.
BUG=chrome-os-partner:59393
BRANCH=none
TEST=Enabled the config on Reef. Manually overrode the temperature
and voltage. Observed correct charge profile config is selected
for each tests.
Change-Id: I075d271258470b98d38e4d5395d749469d3fd469
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/407928
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>
last_collection is used for sensor in forced mode to be sure we are not
calling the read routine too often. We should update last_collection even
when the reading fails, and not on the interrupt path.
For sensors that support interrupt, the new timing diagram is:
/-------- data rate period ---------\
--------------+------------------------------------+-----------------> t
| /\
read (sample request) |
| Interrupt (sample available)
\/ |
sensor
BUG=chrome-os-partner:59423
BRANCH=reef
TEST=Check the ALS read is not called too often even when the sensor
reports an error because the read value is not changed.
Change-Id: I2def7bbd5227cf373c1f613c9b70bc6215861008
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424222
Reviewed-by: Randall Spangler <rspangler@chromium.org>
CL/385081 was incorrect, MAX should be used instead of MIN when calculating
the oversampling factor, to be sure it can't be 0.
BUG=b:27849483,chrome-os-partner:59423
BRANCH=reef
TEST=Using a special firmware on Reef reporting the ALS in motionsense,
check that oversampling is 1 when requested frequency is 5Hz while the
maximal frequency supported is 1Hz.
Check the ALS sensor reports information to ARC++.
Change-Id: I3c2d447bbc3a9ca0a5963aa86d5a24ee87ca6ab6
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424221
Reviewed-by: Randall Spangler <rspangler@chromium.org>
For oak, set a different list of task (no als, no accel) for compiling
revision 4 or less. Fix GPIO include issue.
BUG=chrome-os-partner:59423,chrome-os-partner:59084
TEST=compile for oak with board 4 and 5, tested on Reef.
BRANCH=kevin,reef
Change-Id: I09051a69cbad6d477a7b3bf9907f4c5c144b5136
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424220
Reviewed-by: Randall Spangler <rspangler@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>
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>
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>
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>
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>
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>
We currently rely on *head == 0 as error condition, which is
fragile and inconsistent across TCPCs implementations.
Instead, let's return a proper return value on all implementations.
BRANCH=none
BUG=chrome-os-partner:60575
TEST=elm FW as of 65fb80d (later version include a fix that would
hide this issue), cherry-pick this patch, connect j5create
adapter, then HDMI, then power => no crash
Change-Id: If7235e0491e9f80fdd50ce2605477ee518f8e1aa
Reviewed-on: https://chromium-review.googlesource.com/417443
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
From TCPC spec:
"""
RECEIVE_BYTE_COUNT: Indicates number of bytes in this register
that are not stale. The TCPM should read the first RECEIVE_BYTE_COUNT
bytes in this register. This is the number of bytes in the
RX_BUFFER_DATA_OBJECTS plus three (for the RX_BUF_FRAME_TYPE and
RX_BUF_HEADER).
"""
We were always reading 3 bytes too many. This is an issue if we
receive a packet followed by a hard reset, as the register value
will be set back to 0, but TCPC_REG_RX_HDR may contain a valid
header, leading to corrupted packets being passed down the stack.
Also update usb_pd_tcpc to match the specification.
BRANCH=none
BUG=chrome-os-partner:60575
TEST=elm FW as of 65fb80d (later version include a fix that would
hide this issue), cherry-pick this patch, connect j5create
adapter, then HDMI, then power => no crash
Change-Id: I9ed8f3b500d5733ec7563e31246505e0b8bd48bb
Reviewed-on: https://chromium-review.googlesource.com/417442
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
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>
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>
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>
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>
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>
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>
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>
This reverts commit c459c8278e
as the fix is not straightforwad, some host command codes in
private repos are expressed using C preprecessor which
breaks the assumption of this patch that all host commands
are expressed as four digit hex numbers.
Change-Id: I922de9ae8dbab6eef048463c5c09b1f338152083
Reviewed-on: https://chromium-review.googlesource.com/414492
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Use binary search in host command lookup dispatcher
BUG=chrome-os-partner:570895
TEST=manual testing on kevin
- Kevin boots
- ectool hello
make buildall -j
Verify *.smap hcmds section is sorted:
100bca94 R __hcmds
100bca94 R __host_cmd_0x0000
100bcaa0 R __host_cmd_0x0001
100bcaac R __host_cmd_0x0002
100bcab8 R __host_cmd_0x0003
100bcac4 R __host_cmd_0x0004
100bcad0 R __host_cmd_0x0005
100bcadc R __host_cmd_0x0006
100bcae8 R __host_cmd_0x0007
100bcaf4 R __host_cmd_0x0008
100bcb00 R __host_cmd_0x0009
100bcb0c R __host_cmd_0x000a
100bcb18 R __host_cmd_0x000b
100bcb24 R __host_cmd_0x000d
100bcb30 R __host_cmd_0x0010
100bcb3c R __host_cmd_0x0011
100bcb48 R __host_cmd_0x0012
100bcb54 R __host_cmd_0x0013
100bcb60 R __host_cmd_0x0015
100bcb6c R __host_cmd_0x0016
100bcb78 R __host_cmd_0x0017
100bcb84 R __host_cmd_0x0025
100bcb90 R __host_cmd_0x0026
100bcb9c R __host_cmd_0x0029
100bcba8 R __host_cmd_0x002a
100bcbb4 R __host_cmd_0x002b
100bcbc0 R __host_cmd_0x002c
100bcbcc R __host_cmd_0x0044
100bcbd8 R __host_cmd_0x0045
100bcbe4 R __host_cmd_0x0046
100bcbf0 R __host_cmd_0x0047
100bcbfc R __host_cmd_0x0061
100bcc08 R __host_cmd_0x0062
100bcc14 R __host_cmd_0x0064
100bcc20 R __host_cmd_0x0065
100bcc2c R __host_cmd_0x0067
100bcc38 R __host_cmd_0x0087
100bcc44 R __host_cmd_0x008c
100bcc50 R __host_cmd_0x008d
100bcc5c R __host_cmd_0x008f
100bcc68 R __host_cmd_0x0092
100bcc74 R __host_cmd_0x0093
100bcc80 R __host_cmd_0x0096
100bcc8c R __host_cmd_0x0097
100bcc98 R __host_cmd_0x0098
100bcca4 R __host_cmd_0x0099
100bccb0 R __host_cmd_0x009e
100bccbc R __host_cmd_0x00a0
100bccc8 R __host_cmd_0x00a1
100bccd4 R __host_cmd_0x00a8
100bcce0 R __host_cmd_0x00a9
100bccec R __host_cmd_0x00b6
100bccf8 R __host_cmd_0x00b7
100bcd04 R __host_cmd_0x00d2
100bcd10 R __host_cmd_0x00d3
100bcd1c R __host_cmd_0x00db
100bcd28 R __host_cmd_0x0101
100bcd34 R __host_cmd_0x0102
100bcd40 R __host_cmd_0x0103
100bcd4c R __host_cmd_0x0104
100bcd58 R __host_cmd_0x0110
100bcd64 R __host_cmd_0x0111
100bcd70 R __host_cmd_0x0112
100bcd7c R __host_cmd_0x0113
100bcd88 R __host_cmd_0x0114
100bcd94 R __host_cmd_0x0115
100bcda0 R __host_cmd_0x0116
100bcdac R __host_cmd_0x0117
100bcdb8 R __host_cmd_0x0118
100bcdc4 R __host_cmd_0x011a
100bcdd0 R __evt_src_EC_MKBP_EVENT_KEY_MATRIX
100bcdd0 R __hcmds_end
BRANCH=none
Change-Id: Ideb9951b318763f71915e2c4e5052f4b4bfab173
Reviewed-on: https://chromium-review.googlesource.com/405528
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
When the console is unlocked, the function nvmem_wipe_or_reboot()
is called. This holds the EC in reset, clears nvmem, resets the
TPM task, then releases the EC. Nothing about that should cause
the Cr50 to reboot, but it was happening anyway.
This CL addresses several subtle problems.
First, holding the EC in reset invoked the sys_rst_asserted()
interrupt handler, triggering extra (and early) calls to
tpm_reset(). That should wait until after nvmem is cleared, and
only be called once.
Second, the intentional call to tpm_reset() caused the current
(HOOKS) task to wait for the operation to finish, but it didn't
wait long enough (recreating the endorsement certs can take over
a second). When the task_wake_event() returned, a timeout was
indicated in addition to the completion event.
Third, because we checked for the timeout first, we reported an
error even though tpm_reset() completed successfully, just slower
than we expected. We didn't get the timeout event before it
completed because the TPM task runs at a higher priority.
This CL addresses all of these cases, and makes wiping nvmem the
responsibility of the TPM task as well, so that it can do it when it's
ready.
Note that the EC (and thus AP too) will be held in reset while nvmem is
erased.
BUG=chrome-os-partner:59902
BRANCH=none
TEST=make buildall, manual tests
From the Cr50 console, run the "lock on" and "lock off" commands.
Try it both with and without the battery present. Observe that
the Cr50 no longer reboots just because the console unlocks.
Change-Id: I65a342502718acc5b9bda8c6f28dcd27e8f027f7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/411379
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
File-scoped variables in common/tpm_registers.c must be handled
specially to avoid unexpected behavior when calling tpm_reset().
Enhance the comments and add a couple of macros to help explain
it better.
BUG=none
BRANCH=none
TEST=make buildall; Run on Reef
This is just commenting and code cleanup. No changes in behavior
are expected; none are observed.
Change-Id: If70e56d00642a11df7b5ceb5d5d32c485236f7a8
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/412407
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The variable last_rx_time shouldn't be able to be used without being
initialized, so initialize it to make GCC 5.x & 6.x happy.
common/btle_ll.c: In function 'bluetooth_ll_task':
common/btle_ll.c:835:25: error: 'last_rx_time' 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: I99f716fcb3c8c871e4f325eca3bf3cd622e727d1
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/411406
Reviewed-by: Shawn N <shawnn@chromium.org>
The variable "offset" gets configured if it's not the first data packet,
but gets used even on the first data packet.
common/btle_ll.c: In function 'connected_communicate':
common/btle_ll.c:729:15: error: 'offset' 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: Ib3882aab3e081afc4b00dc02b002ba4c590cb0f9
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403500
Reviewed-by: Shawn N <shawnn@chromium.org>
Some functions are only defined if CONFIG_HOSTCMD_EVENTS is set,
leading to link-time failures.
In particular, do not call these functions from keyboard_scan,
and do not define PD host event commands if the configuration
option is not set.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make buildall -j
Change-Id: I0da31cdec08f86f148aa883698a44f462de46d8e
Reviewed-on: https://chromium-review.googlesource.com/410923
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This add basics for acc and gyro sensor ST lsm6dsm
Still need to add interrupt management for embedded
functions and FIFO
BUG=none
BRANCH=master
TEST=Tested on discovery BOARD with sensor connected on
EC i2c master bus. Added motion sense task on discovery
board task list, added gpio info in board configuration
file and tested with motion sense console commands. Data
for acc/gyro seems ok, can successfully change ODR and
full scale range for acc and gyro.
Change-Id: Ie50c8c0ee366994ed97f7ff3252633893b813ac2
Signed-off-by: Mario Tesi <mario.tesi@st.com>
Reviewed-on: https://chromium-review.googlesource.com/406947
Commit-Ready: mario tesi <mario.tesi@st.com>
Tested-by: mario tesi <mario.tesi@st.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Chrome seems to pay attention to the tablet mode switch reported by the
EC. However, for some devices that don't actually have a switch and use
the lid angle as a "virtual" switch, it's possible for invalid tablet
mode change events to be reported. This is because a single reading
could flip the switch.
This commit adds some debouncing to the tablet mode event changes.
Instead of having a single event be able to change the tablet mode
switch, we will now perform TABLET_MODE_DEBOUNCE_COUNT number of
calculations of the new tablet mode value. If those calculations all
agree, then we'll flip the switch. This should help mitigate false
tablet mode change events caused by spurious forces.
BUG=chrome-os-partner:59203
BUG=chrome-os-partner:59480
BRANCH=gru
TEST=flash kevin; open lid to pi/2 rad; rotate device counter-clockwise
pi/2 rad; shake device and verify that tablet mode doesn't change
easily.
TEST=verify that tablet mode still works.
Change-Id: Id020f7db28e93e53b276b3f0d28a40251f035f0b
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/410942
Commit-Ready: Gwendal Grignou <gwendal@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
This allows custom TPM commands to be declared using the a
DECLARE_VENDOR_COMMAND macro instead of the original (and still
unchanged) DECLARE_EXTENSION_COMMAND macro.
The new commands are nearly identical, but they are encapsulated
using the vendor-specific protocols described in the TPMv2 spec.
Our original extensions use a non-standard command code, and
return a non-standard struct on completion, which can be
confusing to standard TPM drivers and tools.
Demonstrating the use of the new macros, this adds commands to
obtain the state of the Cr50 restricted console lock, or to set
the lock. There is intentionally no command to unlock the
console.
Note that this CL just adds the commands to the Cr50. We still
need to provide a nice userspace utility for the AP to use.
BUG=chrome-os-partner:58230
BUG=chrome-os-partner:57940
BRANCH=none
TEST=make buildall; load, boot, test, and update again on Reef
On Reef, I can use the trunks_send tool to send the raw TPM bytes
to invoke these commands:
Get the lock state:
# trunks_send 80 01 00 00 00 0C 20 00 00 00 00 10
80010000000D00000000001000
The last byte 00 indicates that the lock is NOT set, so set it:
# trunks_send 80 01 00 00 00 0C 20 00 00 00 00 10
80010000000C000000000011
Success. On the Cr50 console, I see it take effect:
[480.080444 The console is locked]
Query the state again:
# trunks_send 80 01 00 00 00 0C 20 00 00 00 00 10
80010000000D00000000001001
and now the last byte 01 indicates that the console is locked.
And of course the existing extension commands still work as
before. In addition to uploading firmware, I can use the
usb_updater from my build machine to query the running firmware
version:
$ ./extra/usb_updater/usb_updater -f
open_device 18d1:5014
found interface 4 endpoint 5, chunk_len 64
READY
-------
start
Target running protocol version 5
Offsets: backup RO at 0x40000, backup RW at 0x4000
Keyids: RO 0x3716ee6b, RW 0xb93d6539
Current versions:
RO 0.0.10
RW 0.0.9
$
Change-Id: I7fb1d888bf808c2ef0b2b07c782e926063cc2cc4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/409692
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
BUG=chrome-os-partner:55158,chrome-os-partner:55889,chrome-os-partner:55890
BRANCH=none
TEST=on reef use ina (pp3300_pd_a_mw) to check tcpc power consumption
Change-Id: I5a2904f4e549b7da22242848bb3b1887331ecadd
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/399882
Reviewed-by: David Hendricks <dhendrix@chromium.org>
These keys are much quicker to verify (259ms to 51ms on a -M0 at
48 Mhz), so they can be used when timing is critical and
verification needs to be performed on the board.
BRANCH=none
BUG=chromium:663631
TEST=make buildall -j && make run-rsa
TEST=make run-rsa3 (next commit)
Change-Id: I0da4b3e21543bb6f7b18e8b6ddc5e153046a61b8
Reviewed-on: https://chromium-review.googlesource.com/408006
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When kernel get EC_HOST_EVENT_PD_MCU event and query power state, we may
not done refresh here. Delay EC_HOST_EVENT_PD_MCU event to avoid this
race.
BUG=chrome-os-partner:59499
BRANCH=gru
TEST=Manual on kevin, check power state correct after unplug charger
Change-Id: Ib88acf5a39c2780c6e40144ccebfba17cf84f77c
Signed-off-by: Jeffy Chen <jeffy.chen@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/408131
Commit-Ready: Douglas Anderson <dianders@chromium.org>
Tested-by: Wonjoon Lee <woojoo.lee@samsung.com>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This adds new key combination (Left_Shift+Esc+Refresh+Power) that triggers
recovery mode by setting a new host event
EC_HOST_EVENT_KEYBOARD_RECOVERY_HW_REINIT. This host event can be used
whenever user wants to request entry into recovery mode by
reinitializing all the hardware state (e.g. memory retraining).
BUG=chrome-os-partner:56643,chrome-os-partner:59352
BRANCH=None
TEST=Verified that device retrains memory in recovery mode
with (Left_Shift+Esc+Refresh+Power) on reef.
Change-Id: I2e08997acfd9e22270b8ce7a5b589cd5630645f8
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407827
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Simple API to set/get the tablet mode. It can be set via lid angle
calculation or if a board has a dedicated HAL sensor/GPIO.
Merged from glados branch, add MKBP switch support.
BUG=chromium:606718
BRANCH=gru
TEST=Check with Cave that both mode works.
Reviewed-on: https://chromium-review.googlesource.com/402089
Reviewed-by: Shawn N <shawnn@chromium.org>
(cherry picked from commit c940f36ceabcf2425284001298f03ebdb4c3079e)
Change-Id: I2ee5130f3e0a1307ec3ea543f7a32d66bc32b31d
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404915
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
We were getting occasional stack overflow and watchdog timeouts
when clearing NVMEM. Bump up the stack size a bit in the HOOKS
task, and pet the watchdog before invoking the tpm2 init
functions.
BUG=chrome-os-partner:59419
BRANCH=none
TEST=make buildall, manual
Lock the console, then unlock it. This will reboot the EC & AP,
but should never reboot the Cr50.
Before this CL, it did about half the time.
After, it doesn't.
Change-Id: I33adfeb7360bf7d146a55ef16c923a1a0416393d
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/407847
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
