Added necessary CONFIG options and board specific info to enable the
following sensors:
1. KXCJ9 Lid motion sensor
2. BMI160 motion sensor
3. BMI160 gyro sensor
4. BMM150 magnetometer sensor
BRANCH=none
BUG=chrome-os-partner:58894
TEST=manual
accelrate 2 10000 -> enable gyro
accelrate 3 10000 -> enable magnetometer
accelinfo on 1000 -> display sensor outputs once per second
See outputs like the following:
Base Accel=3022 , 1685 , -15925
Base Gyro=188 , -1404, -300
Base Mag=-253 , 218 , 1004
Moved eve board around and saw the readings change accordingly.
Have not tested lid motion sensor at this stage.
Change-Id: Ia658de4cbf441759482a053358230793550ef5ab
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404987
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@google.com>
The check for hard reset complete was missing. Because of this, the
USB PD protocol state machine would get stuck in state 36
PD_STATE_HARD_RESET_SEND waiting for the pd_task to be woken following
the tx_complete. Instead it would always trip the 100 msec timeout.
BRANCH=none
BUG=chrome-os-partner:58738
TEST=manual
Without this CL, connect to a Guppy TypeC charger and observe:
> C0 st3
[101.946607 event set 0x00200000]
C0 st15
C0 st3
C0 st6
C0 st36
[102.466846 New chg p0]
[102.470376 Ramp reset: st1]
[102.470905 CL: p0 s2 i2000 v5000]
[103.543623 AC on]
After adding the fix for checking hard reset done:
> C0 st3
[32.880946 event set 0x00200000]
C0 st15
C0 st3
C0 st6
C0 st36
[33.410038 New chg p0]
C0 st37
[33.415641 Ramp reset: st1]
[33.416160 CL: p0 s2 i2000 v5000]
C0 HARD RST TX
C0 st5
C0 st36
C0 st37
C0 HARD RST TX
C0 st5
[34.489611 AC on]
[34.489965 event set 0x00000008]
[34.520457 event set 0x00400000]
[34.520876 charge_request(8688mV, 4608mA)]
C0 st6
[35.419391 Ramp p0 st2 500mA 0mA]
Change-Id: I6822983002fa387c85f7e55af5fe1e142c7b88e2
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404878
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
When sourcing current on the type-C port, set the OCP limit on the VBUS
load switch according to current dynamic capability.
(3.0A when only one port is a power source, 1.5A else)
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=gru
BUG=chrome-os-partner:56110
TEST=manual: connect Caroline to Kevin with Twinkie in between,
ask Caroline to sink current through the UI.
without anything else connected on Kevin, see 3A flowing when measuring
with Twinkie ('tw vbus'), plug a dangling C-to-A receptacle dongle on
the other Kevin port and see 1.5A flowing through Twinkie.
Force the input current limit on Caroline to 3.0A and see Kevin cutting
VBUS.
Change-Id: Ib879b1ed720b20aa702c5f3643948ba0575d1193
Reviewed-on: https://chromium-review.googlesource.com/403869
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Turn off the charger BGATE when the system is hibernated to
save maximum power.
BUG=chrome-os-partner:59001
BRANCH=none
TEST=Manually verified on the Reef.
System can boot from hibernate wake sources.
Following are the power measurement values at Battery
voltage = 8.3V & temperature = 23 deg C.
a. Normal operation 540uA, 3.500mW
b. BGATE OFF 80uA, 0.592mW
Change-Id: Ia30655ccefbf0dded623246150d53b2a815df2de
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/404685
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>
The RESETDET and USBRST USB interrupt status bits are often set
together. There is no point in resetting USB twice.
BRANCH=none
BUG=none
TEST=verified that cr50 still operates fine of Reef and ec and ap
consoles are available (still intermittently).
Change-Id: I467d975a3a5955b6072a2a3376de7a1501e7c6c5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/404910
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
PD alternate mode is covered in tcpc interface. So tcpci_tcpm_init()
doesn't reset HPD. If keeping HDMI/DP type-C cable connected, doing
sysjump sets HPD signal to high while it's already high(this high comes
from previous state), then OS doesn't output to HDMI/DP monitor.
Reef Type-C port 1 follows TCPCI and has this issue.
BUG=chrome-os-partner:57689
BRANCH=none
TEST=Connect HDMI/DP type-C dongle, boot up system, OS detects HDMI/DP
monitor and extends screen to it; in console doing "sysjump RO"
or "sysjump RW", display goes out then comes back.
Change-Id: I12239a86490f29d0123fe8bad1b813d3be28d041
Signed-off-by: li feng <li1.feng@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/398444
Commit-Ready: Li1 Feng <li1.feng@intel.com>
Tested-by: Li1 Feng <li1.feng@intel.com>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
POR has both VCC & VBUS enabled. If the port is sourcing VBUS it will
also act as sync and AC_OK pin gets enabled. Hence disable the input
to the port when sourcing.
BUG=chrome-os-partner:59020
BRANCH=none
TEST=Manually verified on Reef. Connected HoHo and AC_OK is not
enabled.
Change-Id: Ic51b81f45759d7dddb2c9744d1c24dbafd1e1293
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/404168
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>
Turn on CONFIG_HOSTCMD_ALIGNED and
CONFIG_COMMON_GPIO_SHORTNAMES to squeeze more
space for the upcoming sensor code.
BUG=chrome-os-partner:59084
BRANCH=gru, kevin
TEST=Check the map to confirm the size reduction
Change-Id: I7a9ca8fccf6d57a797c391dc76cacb0b929e14df
Reviewed-on: https://chromium-review.googlesource.com/403485
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This duplicates the macro definition that exists in compile_time_macros.h.
Adding it is okay since they are both guarded by a #ifndef #endif check.
This is needed by code being pulled in from google3 which expects the
macro to be defined in the standard place.
BUG=none
BRANCH=none
TEST=make BOARD=haven_dev
Change-Id: Ibddefcd8bbfe0d121b3ce65950ce979e65778761
Reviewed-on: https://chromium-review.googlesource.com/403573
Commit-Ready: Johnnie Chan <johnniec@google.com>
Tested-by: Johnnie Chan <johnniec@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The tpm is supposed to report its firmware version when
TPM_PT_FIRMWARE_VERSION_1 and TPM_PT_FIRMWARE_VERSION_2 capabilities
are requested.
This patch retrieves form the build info string SHA1s of the ec and
tpm2 repositories and returns them to the caller.
BRANCH=none
BUG=chrome-os-partner:58177
TEST=with the appropriate tpm2 source tree changes the ec and tpm
SHA1s are now reported:
localhost ~ # tpm_version
TPM 2.0 Version Info:
Chip Version: 2.0.0.0
....
Firmware Version: 0a92ec7c01b9c924
(the first half is the zero prepended 7 characters of the ec SHA1,
and the second half is the zero prepended 7 characters of the tpm2
SHA1).
Change-Id: I01e4fffdafbbdc4668342ea511ca9c4a555e20a9
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403115
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Previously, sleep was being reenabled only after tpm fifo reads as
that would typcially be near the end of a host driven TPM
command. However, in the case the host reads or writes to the STS
register, then sleep would not be re-enabled. Moved the re-enable
point to at the end of every i2cs interrupt. Since sleep is delayed by
1 second prior to being reenabled then Cr50 will not go to sleep in
the middle of TPM command since the host is either writing or reading
STS at a much faster rate when a TPM command is being executed.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Added a debug counter in idle.c and shortened sleep delays from 3
minutes to 5 seconds. Unplugged suzyq and verified that when
reconnected, the counter was incrementing to verify that Reef would
go to sleep. Also verified that TPM worked successfully and kernel
was launched.
Change-Id: I03ad33ed3591bbba24b5c56445c06d0e11368019
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/401808
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
In __wait_evt(), if a timer expiration occurs after we read event
status, before the timer is canceled, then TASK_EVENT_TIMER will be
propagated to the next task wait, likely leading to premature timeout.
Prevent this by clearing TASK_EVENT_TIMER after canceling our timer.
BUG=chrome-os-partner:58658
BRANCH=gru
TEST=Manual on gru, run 'pd # hard' for 12 hours with charger attached,
verify no TCPC I2C read errors occur.
Change-Id: Iac2f05a768b4ef29f82e7c3eb899f4c7dd5c3744
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400968
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When the board is using dynamic source PDOs, we need to ensure that we
are checking the incoming sink power request against the right set of
PDOs else we might reject a valid request (e.g. with high-power source,
we need to check against the 3.0A limit if we only have one port
connected).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=gru
BUG=chrome-os-partner:56110
TEST=Connect Kevin to Caroline, ask Caroline to charge from the other
side and see it negotiating successfully a 5V/3A contract.
Change-Id: Ie1aa5746776be5946422bf07c08ae0f22faddd8c
Reviewed-on: https://chromium-review.googlesource.com/403088
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Enable write protect based on the type of image being built. Write
protect will be enabled on production images and disabled on dev images.
BUG=chrome-os-partner:49959
BUG=chrome-os-partner:55604
BUG=chrome-os-partner:58961
BRANCH=none
TEST=verify wp is enabled unless the image is built with CR50_DEV=1
Change-Id: Ibcd7f35fb4b33142c94e59e8c103624fce4e0b10
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403308
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When GPIOC6/GPIO76 are not selected as SMI/SCI function(ie. selected
as GPIO), the reading of SMIB/SCIB will be a fixed value. This means
it cannot reflect the actul SMI/SCI status. As a reault, use SET_BIT/
CLEAR_BIT macro to toggle SMIB/SCIB is not feasible. Firmware should
read the SMI/SCI status from VWEVSM(2) register before setting it.
This CL defines some macros to achieve it.
In the previous CL, SMI/SCI negative polarity is conditionally
disabled. However, the negative polarity is not used in current
firmware design. Set the SMI/SCI polarity as postive unconditionly by
default.
Modified drivers:
1. lpc.c: use macro NPCX_VW_SMI/NPCX_VW_SCI to generate Virtual wire.
use SMI/SCI postive polarity uncontionally by default.
2. register.h : define macro to handle SMI/SCI virtual wire.
BUG=chrome-os-partner:34346
BRANCH=none
TEST=make buildall; try hostevent on Wheatley and check virtual wire
signal is correct on logical analyzer.
Change-Id: Id4a7748addeaa3b35f280ff29f6fcd8a08b9894b
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/400161
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Tested-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
Prior x86 boards have had GPIO for toggling RCIN directly on the PCH,
although many likely had HW-assisted methods as well.
With eve we need to generate an eSPI Virtual Wire for RCIN, but in reality
software control over RCIN Virtual Wire is not available with the npcx EC,
so the legacy LPC interface for pulsing KBRST must be used instead as this
is the only way to generate RCIN.
This method will likely vary on different EC chips, but for skylake it
can just be abstracted into the LPC module.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=successful 'apreset warm' on eve EC console
Change-Id: I7f9e7544a72877f75d05593b5e41f2f09a50e1c9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400037
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
This board function allows workarounds to be applied to a board after all
power rails are up but before the AP is out of reset.
Most workarounds for power sequencing can go in board init hooks, but for
devices where the power sequencing is driven by external PMIC the EC may
not get interrupts in time to handle workarounds.
For x86 platforms and boards which support RSMRST# passthrough this board
callback will allow workarounds to be applied despite the PMIC sequencing
by ensuring that the function is executed before RSMRST# deassertion.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=test IMVP8 workaround on multiple eve boards
Change-Id: I0569494084000a4b1738ee18aafce5c96900dc4b
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/402591
Reviewed-by: Shawn N <shawnn@chromium.org>
Till the charger task is initialized port is not set for the BD9995X
users and a false battery critical message is printed. Removed the
false message printed for BD9995X users to avoid confusion.
BUG=chrome-os-partner:58972
BRANCH=none
TEST=Manually tested on Reef.
False battery critical message is not printed on the EC console.
Change-Id: Iec8d0f354c4f6dc17efa9da8db38b125e57addab
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/402668
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>
Enable the chipset_reset_hook by adding interrupt trigger on
pltrst assertion and fix the compilation when built with
CONFIG_CHIPSET_RESET_HOOK enabled.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=build with CONFIG_ESPI and CONFIG_CHIPSET_RESET_HOOK
Change-Id: I64eb7a1acc58c07beba0d28f94d95ef33d7220fb
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400035
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The check for whether or not to send an SMI needs to check the
same status bit that it is using to indicate that it is going
to send an SMI. The SMIE bit is enabled in lpc_init() so it is
always set.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=shutdown with lid close event at developer screen
Change-Id: I9a0f34025c4fa11175fca7be34224ec680bffbef
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400033
Reviewed-by: Shawn N <shawnn@chromium.org>
Add the default undefined state for CONFIG_ESPI and rename
CONFIG_VW_SIGNALS to CONFIG_ESPI_VW_SIGNALS.
BUG=chrome-os-partner:58666
BRANCH=none
TEST=pass presubmit checks
Change-Id: I45242d545915c16bb46f751532a01ab937cee5f0
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/400032
Reviewed-by: Shawn N <shawnn@chromium.org>
This change introduces a 'fixed' endorsement seed,
and corresponding certificates. This fixed seed
is used in the endorsement process when a production
mode chip is running dev-signed firmware (or vice-versa).
The fixed certificates are untrusted by production
services, and are suitable for use in a development
environment.
BRANCH=none
BUG=none
TEST=build succeeds
Change-Id: Ifad0b361413a10f88c4977b03033a30a750cd536
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/401634
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This fixes a build failure using gcc 5.3 where opcode and max_attempts
are used before being initialized.
BUG=None
BRANCH=None
TEST=Build all boards successfully.
Change-Id: Ia7c4273f8812cca9f127fcd71101ce3a4e4ad4c7
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/370662
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
When the kernel reads sensor data via LPC, it expects the order to be:
- ACCEL
- ACCEL
- GYRO
(other sensors data are read through EC commands)
BMI160 expects ACCEL, GYRO and MAG to be next to each other.
Reorganize motion_sensor array to fit these 2 requirements:
If BMI160 in the lid:
- BASE_ACCEL
- LID_ACCEL
- LID_GYRO
...
If BMI160 in the base:
- LID_ACCEL
- BASE_ACCEL
- BASE_GRYO
...
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: If89cf29d28b70e9a46dde8a3301a1942b3a1dd8b
Signed-off-by: Bruce.Wan <Bruce.Wan@quantatw.com>
Reviewed-on: https://chromium-review.googlesource.com/401206
Commit-Ready: Keith Tzeng <keith.tzeng@quantatw.com>
Tested-by: Keith Tzeng <keith.tzeng@quantatw.com>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This isn't supposed to be static. And with CL:401421, we noticed that
clang doesn't like this form. So fix this one too.
BRANCH=none
BUG=chromium:658436
TEST=build
Change-Id: Ibd0c5724d5178c5ce8fc8c1b74382aeddd8f744d
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/402068
Reviewed-by: Shawn N <shawnn@chromium.org>
clang doesn't like the array here:
ec-utils-0.0.1-r3361: x86_64-cros-linux-gnu-clang -std=gnu99 -g -Wall -Werror -Wpointer-arith -Wcast-align -Wcast-qual -Wundef -Wsign-compare -Wredundant-decls -Wmissing-declarations -O0 -I/build/reef/usr/include/libusb-1.0 -I../../include -I../../board/cr50 -I ../../chip/g -I../../util usb_updater.c -lusb-1.0 -lcrypto -o usb_updater
ec-utils-0.0.1-r3361: In file included from usb_updater.c:32:
ec-utils-0.0.1-r3361: In file included from ../../include/usb_descriptor.h:14:
ec-utils-0.0.1-r3361: ../../chip/g/usb_hw.h:29:14: error: tentative array definition assumed to have
ec-utils-0.0.1-r3361: one element [-Werror]
ec-utils-0.0.1-r3361: static int (*usb_iface_request[]) (struct usb_setup_packet *req);
ec-utils-0.0.1-r3361: ^
ec-utils-0.0.1-r3361: 1 error generated.
But it's willing to forgive if this is extern. It should be extern
anyway.
BRANCH=none
BUG=chromium:658436
TEST=reef pre-cq passes (building ec-utils)
Change-Id: I5b5f8eb8dcdc3340487b118b30469c8cee73e182
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/401421
Reviewed-by: Shawn N <shawnn@chromium.org>
