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>
The code clearly indends to sleep on the second time the loop
is taken, but the variable first_exchange is reset to 1 inside
the loop. If, for whatever reason, PD alert status cannot be
cleared, the code will then loop forever, and lead to a watchdog
reset.
BRANCH=none
BUG=chrome-os-partner:58750
TEST=Flash EC RO using ec_util
Run fwupdatetest with charger unplugged for 10 iterations.
Change-Id: I9e13f2523111853fdc5c45e75886c11f1c8006eb
Reviewed-on: https://chromium-review.googlesource.com/401238
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The lengths were previously specified as end offsets and were
thus off by 1.
Fortunately it seems these chips were never used with an EC where we
actually utilize this table. Still, it would be nice if we actually
tested this on real hardware to check that there aren't any other
silly errors.
BUG=none
BRANCH=none
TEST=needs testing
Signed off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: I0a5315808c756797940436a10cd4f6df7313ab8c
Reviewed-on: https://chromium-review.googlesource.com/400642
Commit-Ready: Dan Shi <dshi@google.com>
Tested-by: David Hendricks <dhendrix@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The host command parameter and response buffers should be explicitly
aligned by the LPC/SPI/I2C drivers. But the host command handlers don't
know that, and the structs are all __packed, so the compiler generates
horribly inefficient ARM Cortex-M code to cope with unaligned accesses.
Add __ec_align{1,2,4} to force the param / response structs to be
aligned. Use it in a few structs now which were straightforward to
test. It should be added to more structs as space is needed, but that
would make this change unwieldy to review and test.
Add CONFIG_HOSTCMD_ALIGNED to enable the additional alignment.
Currently, this is enabled only for LM4 and samus_pd, so that EC code
can be tested without affecting other non-samus ToT development (none of
which uses LM4).
Fix the two handlers that weren't actually aligned (despite one of
them having comments to the contrary).
Also, add a CHROMIUM_EC define that can be used to determine if a file
is being compiled for an EC target. We need that so that we only force
structure alignment for EC binaries. On the AP side, buffers may not be
aligned, so we should not force alignment.
BUG=chromium:647727
BRANCH=none
TEST=Flash samus and samus_pd. Boot samus and run a bunch of ectool
commands (with and without --dev=1, so it tests both EC and PD).
System boots and all commands return expected results.
Change-Id: I4537d61a75cf087647e24281288392eb85f22eba
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/387126
Shifted pd_task debug level by 1 so that debug level 1 will
enable printing the pd state name.
Added a CONFIG flag to remove ability to change debug_level
during runtime and debug print level will be fixed.
BUG=none
BRANCH=none
TEST=make buildall
Change-Id: I545813bafa8084355cedc2d8334c3aec5a2b6739
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/339935
Tested-by: Divya S Sasidharan <divya.s.sasidharan@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The two types added, bool and uint_least8_t, are needed by the nanopb
common header file "pb.h".
The file added and the file modified are EC versions of files that are
normally provided by the compiler. This change follows the approach
already take to provide our own, mimimalist versions of these files.
BUG=none
BRANCH=none
TEST=make buildall -j
Change-Id: I892e25b14f7cbe3ecca6f60d6a2955d4d628e3a9
Reviewed-on: https://chromium-review.googlesource.com/398921
Commit-Ready: Carl Hamilton <carlh@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Don't call into tcpm_*() functions from HOOKs since these functions may
manipulate common sets of TCPC registers.
BUG=chrome-os-partner:57691
BRANCH=gru
TEST=On kevin, boot to S0, verify 5V is sourced to legacy peripheral.
Drop to G3, verify role is back to sink and charging is functional. Back
to S0, verify 5V is sourced.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9ade9de068589dce6995cda6b106217aa85aa793
Reviewed-on: https://chromium-review.googlesource.com/394809
(cherry picked from commit 18e9e3870722d57efd232bd7f0a0300003b46ad6)
Reviewed-on: https://chromium-review.googlesource.com/396137
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This allows a servo_v4 to export case closed debugging
automatically, if it detects that it's been plugged into
a ccd device.
BUG=chromium:571476
TEST=Connect to reef in both orientations.
BRANCH=None
Change-Id: I8e2781056b22e834132bc4bb839ef2763fa0b4b8
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/375359
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Currently eCTS suites share the same directory (e.g. build/stm32l476g
-eval) to put build artifacts even though some files (e.g. board.c)
compile differently suite to suite. So, if cts-i2c-stm32l476g-eval is
built, followed by cts-gpio-stm32l476g-eval, build fails or produces
incorrect binary.
This patch makes eCTS create different directories for each suite.
As a bonus, we can now builds eCTS suites in parallel.
BUG=chromium:654549
BRANCH=none
TEST=make buildall -j (with uncommitted change)
Change-Id: I4abedc917787be5f79b97e0e50d0d08e01bd5f9d
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/398281
make build=lucid fails if there is an uncommitted change in the tree
because '-dirty' is appended to version strings, which causes the image
to exceed the flash size limit.
BUG=chromium:654549
BRANCH=none
TEST=make buildall -j
Change-Id: Ie4a7b4c7dc70846108aed953215f79dc30a10fca
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/396617
Reviewed-by: Randall Spangler <rspangler@chromium.org>
