The INFO1 mask field contents serves as input for the rollback
protection mechanism, when the RO decides if an RW is allowed to run
on the device.
The existing code updates INFO1 mask to match the lowest rollback
priority of the two images (RW_A and RW_B) present on the device.
INFO1 mask should be also updated when the current image is endorsed
by the host. In this case the alternative RW is destroyed, so the
INFO1 mask could be set based solely on the currently running image.
This patch refactors the code to allow setting INFO1 mask based on one
or both RW headers' contents.
BRANCH=cr50
BUG=b:62138152
TEST=verified that "normal" INFO1 mask updates still work as before,
the mask is modified to match the image with the lowest rollback
priority.
Also verified that when the VENDOR_CC_INVALIDATE_INACTIVE_RW
command is received the INFO1 mask is updated based on the
currently running image.
Change-Id: I23172388674e1f3a4c2489e139dd197a84029f54
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/541738
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This change will configure camera PMIC to low power mode
in S3 and S0ix sleep state and resumes it in S0 state.
BUG=b:62779726
BRANCH=None
TEST=`Build/Flash EC and verify the PP3300_DX_CAM signal is
toggling during S3/S0ix cycle.`
Change-Id: I9f376762100ac9b208df4a39160e4acd3b7b925e
Signed-off-by: Divagar Mohandass <divagar.mohandass@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/539316
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
the 1ms reset hold time isn't in the ps8751 datasheets (yet), but
that's what our parade support contact recommended. i'm applying this
fix to reef (electro) and coral as these two boards were missing any
sort of reset hold time. other boards using the ps8751 seem to
already have a 1ms or 10ms delay.
TEST=rebuilt, reload EC image on electro... no ill effects noted.
BUG=b:62642003
BRANCH=reef
Change-Id: I39a989375e789118d062f82e9baaa041e5e6b033
Signed-off-by: Caveh Jalali <caveh@google.com>
Reviewed-on: https://chromium-review.googlesource.com/540742
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This patch adds wait between DSW_PWROK and PWRBTN assert. It is
required to be 95 msec or longer for Kaby Lake and Sky Lake.
Refer to the timing diagram for G3 to S0 on Sky Lake or Kaby Lake
platform design guide for details.
BUG=b:62584658
BRANCH=none
TEST=On Fizz, measured time between DSW_PWROK high and PWRBTN assert
for 1:AC plug-in, 2:recovery+power press, 3: reboot ec command.
Change-Id: I89a14ac9a49e20a332bd662d90be62f8ea23b003
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/534901
If Cr50 happens to start on a chip where Board ID programmed in INFO1
does not match the contents of the RW header, it means that for some
reason the other RW is not operational and the current image is the
only viable one.
In this case the Cr50 starts but operates in limited mode (only
commands for updating the image and reporting state are handled). In
this case the reason for recovery could be seen on the Recovery
screen, and the update could be done once Chrome OS boots in recovery
mode.
BRANCH=none
BUG=b:35586335
TEST=verified the following:
- if an image with wrong board ID is started, it tries to fall back
(sets the counter to a value above threshold and reboots)
- if the fallback fails, the image keeps running in the limited
capabilities mode but the update is possible, observed that the
new image took over worked after powercycling the device.
- observed proper error message on the recovery screen showing where
the error comes from
Change-Id: I46ba75392f8e891bb8503fb15aea2c56b5805e83
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535978
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Add support for update related vendor commands in mn50 by relocating
relevant code from board/cr50 to chip/g.
BUG=b:36910757
BRANCH=None
TEST=./extra/usb_updater/usb_updater -d 18d1:502a build/mn50/ec.bin
Change-Id: Iec0fe5585b5b6eb099f9254dfb0e5b02d5106abc
Reviewed-on: https://chromium-review.googlesource.com/537999
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When an external charger is connected, only the LED on the side the
charger is connected should be on, the other side should be off. The
existing LED behavior was incorrect in that only the side that was
charging was being updated and the other side would remain in its
previous state.
This CL adds a fix so that if only one LED is being controlled, the
other side is always turned off. In addition, the logic for double tap
events was changed slightly so that if a double tap event is in
progress and a charger is connected, the new state will be updated as
soon as the charge state is changed instead of waiting for the double
tap event to complete.
BUG=b:62481906
BRANCH=eve
TEST=Manual With battery level < 15% so that both LEDs are red when
the charger isn't connected, connect charger and verified that the LED
on the side the charger is connected turns white and the LED on the
other side turns off.
Change-Id: I7462629409496383adb43445e732dd6ca2f9f589
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/537960
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
When starting up the Cr50 should check if this image is supposed to
run on a chip with the board ID value read from INFO1.
If it is not supposed to run on this chip, and there is no rollback
counter overflow, set the rollback counter to a value which will
trigger a rollback and reboot.
If rollback counter has already exceeded the threshold - set a flag
indicating that the image is running in the "mismatch" mode and
continue.
BRANCH=cr50
BUG=b:35586335
TEST=with the rest of the patches applied verified both falling back
to an older image and continuing running with the flag set if
rollback is not possible.
Change-Id: I58d97de61dc446aaf1dd06b6e2b6bb426c14a172
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/535977
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
rev1 (Soraka) was using proto settings. Instead use the settings described
in fuel gauge specification.
BRANCH=none
BUG=b:62552007
TEST=On soraka, check that the system goes to ship mode and no error
messages appear, using "ectool batterycutoff" from OS or "cutoff"
from EC console.
Change-Id: I04e6b08265d20395d13e28e93cb14c1d49b376df
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/531736
Reviewed-by: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
x25519 requires quite a bit more stack size (1696/2048), so
increase its size.
BRANCH=none
BUG=b:38486828
TEST=Flash hammer, ./usb_updater2 -c always reports the same
device public key, and authenticator is correct.
Change-Id: I51dff9f10167d654561ef7f199b9b9206511b7e9
Reviewed-on: https://chromium-review.googlesource.com/532476
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The contents of the board ID fields of the Cr50 image headers is an
important piece of information which determines if an image can run on
a particular H1 chip.
This patch adds this information to the output of the 'version'
command, printing both the contents of the fields of the RW images and
if the image would run with the current INFO1 board ID contents (Yes
or NO).
The board_id feature is in fact g chipset specific, this is why
board_id support files are being moved from the cr50 board scope to
the g chip scope.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=observed expected output in the version command:
> bid
Board ID: 000000fa, flags 000000ff
> vers
Chip: g cr50 B2-C
Board: 0
RO_A: * 0.0.10/29d77172
RO_B: 0.0.10/c2a3f8f9
RW_A: * 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
RW_B: 0.0.20/DBG/cr50_v1.1.6543-2c68a2630+
BID A: 00000000:00000000:00000000 Yes
BID B: 000000ea:0000fffc:000000ff No
Build: 0.0.20/DBG/cr50_v1.1.6542-856c3aff4
tpm2:v0.0.289-cb2de5a
cryptoc:v0.0.8-6283eee
2017-06-09 15:34:19 vbendeb@eskimo.mtv.corp.google.com
>
Change-Id: I5b283abf304a7408ca8f424407044fca238185e1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/530033
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Since Reef was the starting point for /board/coral, coral inherited
support for both the BMI150 magnetometer and BMI280 barometer
sensors. Coral does not need to support either of these sensors.
This CL removes support for both of these sensors.
BUG=b:62519010
BRANCH=none
TEST=Manual Run 'make BOARD=coral' and verify it builds. Used
accelinfo EC console command to verify that other sensor readings are
working. My test setup does not have ALS sensor so couldn't confirm
that operation.
Change-Id: I75abe2f10c8f0ff318f4795e6b88c9aff3d8a9ad
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/530448
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Check that added entropy is at least somewhat acceptable.
BRANCH=none
BUG=b:38486828
TEST=make BOARD=hammer -j tests
./util/flash_ec --board=hammer --image=build/hammer/test-entropy.bin
EC console: runtest, get around 4000/1000 (=4) bits of entropy, value
matches (roughly) the value obtained using the awk script.
TEST=make run-entropy
Change-Id: I88d0e9ec0e38ab3ec70d3e8163b8ac1556df978d
Reviewed-on: https://chromium-review.googlesource.com/523482
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Coral has 16 voltage levels utilized for board ID. Compared to 8 for
Reef. This CL updates the board_version table to account for 16 board
version entries. In addition, insted of using a fixed error percentage
upper error bar, the table entries have been set to be the mid point
between two consecutive voltage levels.
MOdified the existing board_get_version() function so that it calls a
common function since this needs to be repeated for both board ID and
board SKUs. Modified gpio enable signal name to match the
schematic. Coral uses an active high enable.
Added an EC console command with options id|sku0|sku1 to test each
option. This CL does not include the function which will be used with
the host command interface so the AP can retrieve the sku 0|1 values.
BUG=b:62519010
BRANCH=none
TEST=MANUAL
Using the console command board_id shows the following:
> board_id
Wrong number of params
Usage: board_id <id | sku0 | sku1>
> board_id id
[44.484516 ID/SKU ADC 2 = 123 mV]
Board id|sku: chan 2 = 0
> board_id sku0
[56.850566 ID/SKU ADC 4 = 123 mV]
Board id|sku: chan 4 = 0
> board_id sku1
[65.547598 ID/SKU ADC 3 = 123 mV]
Board id|sku: chan 3 = 0
Change-Id: Iaba146c12c6d9d2c57973569d51c1b7ad3212455
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/530907
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Patrick Georgi <pgeorgi@chromium.org>
Boards Rev1 and Rev2 will lose VBAT on power cycle and therefore
cannot successfully save the reset flag state.
Implement workaround that will allow these boards to continue to
work for FAFT testing by indicating to the skylake chipset power code
that it should skip the PMIC reset when doing 'reboot ap-off'.
BUG=b:62504451
BRANCH=None
TEST=Verified that "reboot ap-off" works fine on Rev1.
Change-Id: I97ee346c0e8796375dc295cfa7a86cd0d57d4e4f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/530515
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This patch makes a few changes to gpio.inc.
- When pre-initialize GPIOs, set default level to low:
ENTERING_RW and USB2_OTG_VBUSSENSE.
- Disable internal pull-up (not necessary if
output type is push-pull):
USB_Cx_5V_EN.
- Set output type to open-drain:
EN_USB_Cx_3A and USB_C0_CCx_VCONN_EN.
The USB_C0_CCx_VCONN_EN is externally pulled up to PP3300_PD_A.
The EN_USB_Cx_3A is pulled to EN_USB_Cx_5V_OUT and connected
to base of BJT directly. The output current will be huge
if it is set as push-pull.
BRANCH=none
BUG=none
TEST=1. built and booted on reef_it8320.
2. plug-in a device on one port and add load current
on vbus to check if current limit sit at 3A.
Change-Id: I71fec59cd1696fff417d9cddc287e993988aea33
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/528034
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In this CL, we add selecting LFCLK sources functionality for npcx7 ec
series. (Please notice not all of npcx7 ec series support this feature.)
Beside internal LFCLK source, ec also can choose the external 32kHz
crystal oscillator as LFCLK source for the specific application. We also
introduce a new definition, CONFIG_CLOCK_SRC_EXTERNAL, to switch this
feature in the board level driver.
This CL also adds:
1. LFCG register definitions in registers.h.
2. Change the order of each npcx modules by memory address.
BRANCH=none
BUG=none
TEST=Output LFCLK source through GPIO75. Compare with external 32kHz
crystal osc. on npcx7_evb and make sure the sources are the same.
Change-Id: I137146bf51ccb51266b9aac1e2e28bcea87dc4f5
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/520745
Reviewed-by: Randall Spangler <rspangler@chromium.org>
poppy uses an ISL charger, which, unlike bd9995* charger based
systems, cannot provide an interrupt when VBUS falls below/rises
above a certain threshold.
On poppy rev2 onwards, we have a precise VBUS detection pin coming
from BC1.2 detection chip (PI3USB9281C), we a threshold between
3.1-3.7 V (3.5V typical) so we can use that to
enable discharge, according to this logic:
- When VBUS voltage falls below ~3.5V, and we're not sourcing 5V
to the port, enable discharge.
- When VBUS voltage rises above ~3.5V, disable discharge.
- When we source 5V to the port, disable discharge.
BRANCH=none
BUG=b:37525769
TEST=Charge out to device (Galaxy S8), and verify that VBUS
drops to 0.8V much faster than without this patch.
TEST=pd 0 swap power: 28ms (vs 496ms)
TEST=pd 1 swap power: 24ms to 0.875v, 202ms to 0.8v (vs 410ms)
TEST=Disconnect cable (port 0): 65ms (vs 721ms)
TEST=Disconnect cable (port 1): 13ms (vs 515ms)
Change-Id: Ibf2dcf5de31514fa0ce0ebd0c6db53d421a586fe
Reviewed-on: https://chromium-review.googlesource.com/481562
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Cr50 needs to be able to bit bang the EC UART in order to flash certain
ECs such as the STM32 family. This is because the UART block on the
chip has no provision to change the parity which is necessary for the
STM32 bootloader protocol.
This commit adds a configuration to bit bang the EC UART. It's been
tested at 9600 baud.
BUG=b:35648297
BRANCH=cr50
TEST=With a logic analyzer, verify that TX to the EC can be bit banged
with no issues at 9600.
TEST=With some other changes, verify that cr50 is able to flash an EC
image to an STM32 EC.
Change-Id: Ice72aff133f268b5b7f0868aeec590a21404d1af
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/503474
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This reverts commit 9565b8ba06.
Reason for revert: This is causing memory test failure under specific
reset conditions that is triggered by a specific FAFT test.
BUG=b:35581264
BRANCH=eve
TEST=pass FAFT test firmware_FwScreenPressPower
Original change's description:
> eve: Set VCCIO rail to 0.85 and disable low power
>
> Set the VCCIO rail to 0.85V where it should be for Y-series parts
> instead of forcing it to 1.0V. The EDS is pretty clear that pushing
> this voltage higher on Y-series parts will have significant power penalty.
> (up to 250mW at 0.95V)
>
> We also don't want this rail dropping in low power mode, which shoudln't
> be happening as S0ix is disabled so SLP_S0 shouldn't assert, but just in
> case disable this as well.
>
> BUG=b:35587084
> BRANCH=eve
> TEST=stress testing on Eve EVT units
>
> Change-Id: I5535fe0d894f283a8d453d61101dfeb6b9287b7c
> Signed-off-by: Duncan Laurie <dlaurie@google.com>
> Reviewed-on: https://chromium-review.googlesource.com/525836
> Reviewed-by: Todd Broch <tbroch@chromium.org>
Change-Id: Ie60ad319421c00df5bf41b9eca03047a37defb88
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/527513
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Initial version of battery.c for coral is just a straight copy from
Reef. Updated this file to include the battery being used for the
first HW build. Removed the profile override config for the starting
point as well.
BUG=b:62272260
BRANCH=none
TEST=Run 'make BOARD=coral' and verify it builds. Can't test on actual
HW yet as the boards aren't build yet.
Change-Id: I15fcf438918c03bf1d459f5806dff04c82fe8b46
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/521756
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add nucleo-f411re for testing STM32F411.
Fix registers.h to include F411 specific features.
TEST=Check uart,gpio works. Check BMI160 accel/gyro sensor works over
i2c
Install firmware with "make BOARD=nucleo-f411re flash"
BUG=b:38018926
BRANCH=none
Change-Id: I8514d1aa48e06708053e72f8d4be15738eda6cf4
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249994
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
To port Scarlet from firmware-gru-8785.B to master, we need
some change in naming/definition of variables/functions.
BUG=b:62307687
CQ-DEPEND=CL:524034, CL:524973, CL:524981
BRANCH=gru
TEST=build image and boot Scarlet
Change-Id: I20c1a4f311c9250a3bf1a2a5b0c70dd0f7c7e45b
Reviewed-on: https://chromium-review.googlesource.com/524987
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
