Allow the host to self-report its sleep state through
EC_CMD_HOST_SLEEP_EVENT, which will typically be sent with SUSPEND
param when the host begins its sleep process. While the host has
self-reported that it is in SUSPEND, don't assert the interrupt
line, except for designated wake events.
BUG=chrome-os-partner:56156
BRANCH=None
TEST=On kevin, run 'ectool hostsleepstate suspend', verify that
interrupt assertion is skipped for battery host event. Run 'ectool
hostsleepstate resume' and verify interrupt is again asserted by the
battery host event.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I74288465587ccf7185cec717f7c1810602361b8c
Reviewed-on: https://chromium-review.googlesource.com/368391
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Modified board level drivers for eSPI POC on wheatley. By adding CONFIG_ESPI
definition, ec can support espi protocols for host interface on x86 based
platform such as skylake and so on. CONFIG_VW_SIGNALS will be used in the
future for saving GPIOs during power sequence.
Modified sources:
1. wheatley/board.h: Enable/disable espi driver.
2, wheatley/board.c: Add VW signals in power signal list.
3. wheatley/gpio.inc: Save GPIOs if CONFIG_VW_SIGNALS is defined.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make BOARD=wheatley; test nuvoton IC specific drivers
Change-Id: I0e8a951de6eacd4f8be65ffaac242f38079375d5
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/366520
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If an HPD IRQ event is seen, make note of it and keep the status set
until informing the host.
BUG=chrome-os-partner:55925
BRANCH=None
TEST=Manual on kevin, trigger HPD event, verify that event bit is set in
reply to first host command and not subsequent host commands.
Change-Id: I0900a683dcb344d5d4d03a1fa6e3d8de913597b2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366990
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Chris Zhong <zyw@rock-chips.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
The nvmem space defined in the ec code base for the cr50 board is used
by the TPM2 library, which has its own nvram size definition. The two
definitions must match.
On top of the fact that the definitions are not locked to each other,
there is a third completely unrelated nvram size definition in
board/cr50/board.c.
This patch unifies nvmem size definitions between cr50 and tpm2
repositories by adding a compile time check for the size to be the
same on both sides.
Also, it turns out that two certificates (RSA and ECC) together do not
quite fit into the cr50 TPM nvram. Hence the total allocated nvmem
space is being increased to 20K (note that the actual nvram size
available to the TPM is less than half of this).
BRANCH=none
BUG=chrome-os-partner:55898
TEST=tpm does not lock up any more when 'tpm_client --own' is ran on the
Kevin-tpm2 command line
CQ-DEPEND=CL:367010
Change-Id: I20b4f54118bd2fa12e5bd5741d6c58fbe91f65d1
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366796
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
While SPI routing on servo is not great, this is still fine
and asn't as painfully slow.
BUG=chromium:571477
TEST=flash some firmware
BRANCH=None
Change-Id: I26d67ed6cd1ba62a892388e96a21acc708265fc4
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366670
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Servo_micro sets usb config maxpower to 100mA.
Servo_v4 is set to self powered as it's powered by a
shared vbus and not be the bub it's connected to.
cr50 is self powered as no power is transmitted as part of CCD.
* Add CONFIG_USB_MAXPOWER_MA to define USB maximum power draw requested
per board.
* Add CONFIG_USB_SELF_POWERED to indicate that a device is not
powered by allocated USB power.
BUG=chromium:631302
TEST=lsusb reports 100mA bMaxPower (micro), Self powered (v4)
BRANCH=None
Change-Id: I79b8ce46f32d94f16104a4a8080104e30dce7f2c
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363153
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a case statement to handle HCI commands.
Add a test commands.
Try to match the hcitool syntax, so the same commands
can be executed on a Linux host.
Added lcmd (long cmd) to pass more parameters in fewer arguments
BUG=None
BRANCH=None
TEST=Use HCI commands to configure an advertiser and listen for
it using `hcitool lescan` on the host.
Change-Id: Ie28038847c9549eb1c27a605aa0fbad5efd3b2c7
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362145
Commit-Ready: Dan Shi <dshi@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I keep thinking this refers to "Embedded Controller" instead of
"Elliptic Curve Cryptography". Make it clearer.
There's no functional change, I'm just renaming a constant.
BUG=none
BRANCH=none
TEST=make buildall; run tests on Cr50 dev board
make -C test/tpm_test && sudo ./test/tpm_test/tpmtest.py
Change-Id: Iaf2e2839e88fdbbcb1a712934be56a0dd47e4a70
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366752
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
KSI2 get stuck when Refresh+Pwrbtn is used to reset EC,
so it was not able to detect the Esc key if it is also
pressed to enter recovery mode.
BUG=chrome-os-partner:55548
BRANCH=none
TEST=Reef EVT is able to enter recovery mode with Esc+Refresh+Pwrbtn
Change-Id: I0539e8fad9980cb563de94417079fe763c311887
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/366411
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Previously, the strapping configuration pins were only being
read following a POR reset event. In all other cases, the
strapping configuration was presumed to be stored in a long
life register. An issue with this method is that when Cr50
FW is upgraded (via Suzyq), there is no POR reset event until
either the battery becomes fully discharged, or the battery
is manually disconnected. Without a POR, following a FW upgrade,
the long life register will contain 0 and so neither the SPI
interface (on Kevin/Gru) or I2C interface (on Reef) will be
properly initialized.
Come to think of it, the contents of the scratch register should never
be zero unless this is a power on event, or a restart after migration
from the version not setting the scratch register.
Let's read the scratch register always if its contents are zero.
BRANCH=none
BUG=chrome-os-partner:50728
TEST=manual
Via the Cr50 console, cleared the long life register with
temp console command. Then executed a FW upgrade with Suzyq
and verified that the strapping pins are read and the correct
value is stored in the long life register. Note that 'reboot'
commands from either the Cr50 or EC console do not cause
a hard reboot.
Change-Id: I1b3aa92552b14bde9bda848aa3dc4c8221ce73a9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366390
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The input should be active low, not active high.
BUG=chrome-os-partner:49959
BRANCH=none
TEST=manual
Remove and reattach the battery. "gpioget BATT_PRES_L" shows the
GPIO value changing appropriately.
Change-Id: I7d513471f6ab5e7e8cd0e601148915697fa9162a
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/366134
Reviewed-by: Vadim Bendebury <vbendeb@google.com>
when the daughter board is not connected, TCPC1 INT# (USB_C1_PD_INT_ODL)
will be floating since the external pull-up is located on the daughter
board as well, and this floating signal will cause an interrupt storm
and eventually cause a watchdog.
BUG=chrome-os-partner:55488
BRANCH=none
TEST=verify board no longer has watchdog reset when daughter baord
is not connected.
Change-Id: If1d73fa7d90f6ac52fd1ab0ac563a6bf5fd10dc0
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/365499
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Reef doesn't have the battery temperature sense pin connected to
the charger, hence reading the battery temperature from the battery
registers.
BUG=chrome-os-partner:55834
BRANCH=none
TEST=Using 'battery' & 'temps' console command verified,
temperature readings are same from both the commands.
Change-Id: I897e453296151f31344f3e0434202baa67c7025d
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/365970
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
There is just one version of Cr50 firmware for all boards
that it's used on. However, on some boards the AP communicates
to the TPM via a SPI interface (i.e. Kevin) and on others, the
AP communicates via an I2C interface (i.e. Reef). In order to
dynamically discover which interface to configure, there are
strapping resistors added to the board which enables the Cr50
to detect which configuration to implement.
This CL is a first pass and is only looking at DIOA1 which is
pulled high for SPI and pulled low for I2C configurations.
The strapping resistor should be read when the AP is in reset
prior to it attempting to drive any of the lines used for
strapping. To ensure this condition is met, Cr50 will only
check the strapping options following a POR (power on reset).
Once the configuration type is discovered, a 'long_life'
register is used to hold the result so that the result can
always be available. The long_life register contents remain
unchanged until a subsequent power down event.
BRANCH=none
BUG=chrome-os-partner:50728
TEST=manual
Tested on Kevin and Reef. Verfifed by reading the stored value
that the SPI configuraiton is detected for Kevin and the I2C
interface is detected on Reef. In addition, verified on Kevin
that the Cr50 FW version is correctly reported to the AP which
means that TPM register reads via the slave SPI are functioning.
Change-Id: Ibd7624ad8e3b4126f6346dce0bc72f62a3cc6d18
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363014
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This adds a hook that will run every second and complain if the EC
firmware was built for the wrong board.
BUG=chrome-os-partner:54947
BRANCH=none
TEST=tested on proto and EVT units
Change-Id: I9799249f74f3cea9a3f6b66b2441af8f16be7e01
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365505
Reviewed-by: Martin Roth <martinroth@chromium.org>
ESC+F3+Power+AC removal puts the battery into a soft-disconnect state
where is stops supplying current. Revive batteries in this state by
supplying a precharge current.
BUG=chrome-os-partner:55858
BRANCH=None
TEST=Manual on reef. Put battery into soft-disconnect state. Attach
charger and verify EC doesn't lose power and battery again supplies
current.
Change-Id: I9a772bf02a8bd40edc1db51de66de135f7299212
Signed-off-by: Rachel Nancollas <rachelsn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365495
Commit-Ready: Rachel Nancollas <rachelsn@google.com>
Tested-by: Rachel Nancollas <rachelsn@google.com>
Reviewed-by: David Hendricks <dhendrix@chromium.org>
Default to set DUT_CC1 to RD to enable USB and indicate
USB SS orientation. Add ADC entries for SBU detect.
BUG=chromium:571476
TEST=check that ADC maps to the right pins, check that usb3 initializes.
BRANCH=None
Change-Id: Ic9f7c6d1506b9ef83ed3b93a98516ab10b1a471c
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364301
Reviewed-by: Todd Broch <tbroch@chromium.org>
Only report alert status if the PD chip is not being held in reset.
(idea borrowed from Amenia's implementation)
BUG=none
BRANCH=none
TEST=built and booted on reef
Change-Id: Ic637b1ab4e20527c806311a45c149b9ea5f64362
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360020
Reviewed-by: Martin Roth <martinroth@chromium.org>
Proto brought up 5V, 3.3V, and PMIC very early in the EC boot process
due to dependencies in the power topology. This had some other side-
effects, for example, a lot of the power rails would already be up by
the time the EC got around to processing the power state machine thus
leaving it waiting for signal changes that were supposed to come
later but had already occurred instead.
This patch updates the nominal codepath for rail and PMIC init on EVT
while using IS_PROTO to retain the Proto sequence if desired.
BUG=chrome-os-partner:54962
BRANCH=none
TEST=built and booted on proto and evt boards with subsequent patches
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Change-Id: If9ddd41044f132e719b0b7f0ab80ed908ddb1d9b
Reviewed-on: https://chromium-review.googlesource.com/358913
Reviewed-by: Martin Roth <martinroth@chromium.org>
The kernel DP driver do not support hpd gpio detect, it use
EXTCON_DISP_DP cable state to decide power on/off DP PHY. Hence, do not
change GPIO_USB_DP_HPD level, but set or clear the TYPEC_MUX_DP when hpd
level changing in attention.
BUG=chrome-os-partner:52872
BRANCH=none
TEST=keep Type-C Dock inserted
1. plug HDMI cable, check with "ectool usbpdmuxinfo"
Port 0: USB DP
2. unplug HDMI cable, check with "ectool usbpdmuxinfo"
Port 0: USB
Change-Id: I369a92135bf0ca177e81eab6385980d51d863172
Signed-off-by: Chris Zhong <zyw@rock-chips.com>
Reviewed-on: https://chromium-review.googlesource.com/364401
Commit-Ready: Guenter Roeck <groeck@chromium.org>
Tested-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Image sizes must be aligned to block erase size to ensure that the host
can erase the entire image and nothing but the image.
BUG=chrome-os-partner:55828
BRANCH=None
TEST=Manual on kevin, rebuild FW with new EC, rebuild + flash EC once
again, verify that SW sync completes and unit boots to OS.
Change-Id: If6110f39869d6421038a3fe7afdc7d918323249e
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365142
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The timer test checks the accuracy of the internal timer. After sync,
DUT and TH start counting down one second. After one second, DUT raises
GPIO level. TH determines whether the test passes or not based on how
much more or less time elapsed than one second, assuming its clock is
calibrated.
This test takes advantage of TH running on a bare chip. If the host
were measuring (instead of TH), the timing would be affected by many
software and hardware layers (e.g. UART drivers on DUT and host,
python interpreter, etc.).
BUG=chromium:624520
BRANCH=none
TEST=cts.py --module timer && cts.py --module gpio && make buildall
Change-Id: I535e7772b4d93f1f5d248506f7ea167429a50174
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361384
Updates for EVT:
- TCPC0 interrupt polarity is now low, define GPIO_INT and set ANX74xx
internal polarity control based on IS_PROTO.
- Swapped pin assignments for USB_C1_PD_INT_ODL and EN_USB_C1_5V_OUT.
- Rename USB_PD_RST_ODL to USB_C0_PD_RST_L and make it push-pull.
- Add USB_C1_PD_RST_ODL
BUG=chrome-os-partner:54958,chrome-os-partner:54952,chrome-os-partner:55165
BRANCH=none
TEST=needs testing
Change-Id: I075934cced532d656f942841c30e3640a6f42568
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358944
Reviewed-by: Duncan Laurie <dlaurie@google.com>
This ensures that we're only checking the reset signal for the
corresponding interrupt. Otherwise we can hit a race condition
when both TCPC chips are taken out of reset.
(This is also how it's done on Amenia)
BUG=none
BRANCH=none
TEST=needs testing
Change-Id: I47513b3b47e947c8b4644f4d837ddc3fb1ee7a30
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361061
Reviewed-by: Shawn N <shawnn@chromium.org>
This makes board_set_tcpc_power_mode() a noop since that's controlled
by anx74xx code and we have another TCPC chip onboard. Instead, we'll
reset the TCPC chips in a hook that will run after board and I2C init.
This is more like what Amenia code does.
BUG=chrome-os-partner:54952
BRANCH=none
TEST=needs testing.
Change-Id: Id3af4af1014432235b699a9568ee19df63601b2c
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361060
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
We need to ignore sys_rst_l right now when we use the usb spi endpoint
to update the AP or EC. We hold the EC and AP in reset and this causes
sys_rst_l to be asserted at the start of updating the AP and when the EC
comes out of reset.
Using the USB SPI endpoint may require doing a bunch of transactions
back to back. Cr50 should not reset itself between each one.
This change postpones the reset until we're done using the usb spi
endpoint. Once sys_rst_l just resets the TPM we can remove all of this.
BUG=chrome-os-partner:52366
BUG=chrome-os-partner:54982
BRANCH=none
TEST=manual
verify 'util/flash_ec --board=kevin --raiden' updates the EC
'sudo flashrom -p raiden_debug_spi:target=AP -w $IMG' updates
the AP
The AP and cr50 reset after usb_spi is disabled.
Change-Id: I68a76012bc7bf6d3abd073a70f0b90e440d72c49
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364051
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We have the lid and base sensors correct in relation to each other.
e.g., when at 90 degree lid angle, this reports correctly:
# ectool motionsense lid_angle
Lid angle: 90
But it appears that our axes are opposite from (e.g.) what Chrome
expects. With the lid angle at 180 degrees flat on a desk, I see:
# ectool motionsense
Motion sensing inactive
Sensor 0: -571 1018 -16302
Sensor 1: 0 0 0
Sensor 2: 896 -3424 -16208
but the Z-axis should be positive. After this patch, I see:
# ectool motionsense
Motion sensing inactive
Sensor 0: 580 -1000 16289
Sensor 1: 0 0 0
Sensor 2: -832 16368 1008
Which looks more accurate, and actually gets Chrome to rotate properly.
All tested on kevin rev3.
BRANCH=none
BUG=chrome-os-partner:55717
TEST=`ectool motionsense`, `ectool motionsense lid_angle`; also test
rotation in Chrome
Change-Id: Ie1bffe27989c893d6037e251499f235ef10d4578
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364161
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@google.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Cr50 was not waking up long enough after SPS_CS_L was asserted for the
spi slave transactions to start and disable sleep. It also was not
handling SYS_RST_L properly when it was asleep.
This change sets SPS_CS_L to be an edge triggered wake up source instead
of level triggered, because cr50 should just wake up on the edge and
disable sleep until the spi transaction is done.
It also adds sys_rst_l as a wakeup source. The sys_rst_asserted
interrupt cannot be triggered while cr50 is asleep, so the
pmu_wakeup_interrupt will call sys_rst_asserted if SYS_RST_L is low at
resume. This change relies on the EC extending the delay in
chipset_reset to be long enough for SYS_RST_L to still be asserted when
cr50 resumes.
BUG=chrome-os-partner:54331
BRANCH=none
TEST=manual
make sure suzyq is disconnected.
verify ap boots up to the kernel after running
'gpioset SYS_RST_L 0' then 'gpioset SYS_RST_L 1' on the ec
console.
Check that cr50 goes to sleep when the AP is not trying to use
the TPM.
When cr50 is asleep pwrbtn + refresh still resets the system.
Disable SYS_RST_L_IN as a wake source and verify the system
verification fails and requests a recovery image.
Change-Id: I807b1918842d96c9d2922aa33404d87ab28b9906
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363606
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The case close debug (CCD) feature is provided by the external security
chip. We add CONFIG_CASE_CLOSED_DEBUG_EXTERNAL to be able to detect debug
accessory with Rd/Rd (by setting Rp/Rp when VBUS is detected without
seeing Rp).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:55410
TEST=manual:on Kevin, plug a SuzyQ (with Rd/Rd) either in S5 or
transition the device to S5 afterwards and see the debug USB endpoint
works.
Change-Id: Icef4209470463be77d43f4a46e32769ebf58f558
Reviewed-on: https://chromium-review.googlesource.com/363401
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
ESC+F3+Power+AC removal puts the battery into a soft-disconnect state
where is stops supplying current. Revive batteries in this state by
supplying a precharge current.
BUG=chrome-os-partner:55617
BRANCH=None
TEST=Manual on kevin. Put battery into soft-disconnect state. Attach
charger and verify EC doesn't lose power and battery again supplies
current.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I8dfcfa90c723d627636d9bebca48429b9f1106f7
Reviewed-on: https://chromium-review.googlesource.com/363004
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reduce size of UART Tx buffer to 1024 bytes on all npcx platforms and
increase size of code memory by 6K bytes on Kevin.
BUG=chrome-os-partner:52876
BRANCH=None
TEST=`make buildall -j` with subsequent commit.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ib9e52a4406f84cfc434984f8819d7ef02b70beb4
Reviewed-on: https://chromium-review.googlesource.com/363591
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This change implements logic for installing
endorsement certificates in the RW section.
The endorsement certificates are initially
provisioned in a fixed RO flash region and
are copied in the RW TPM data region (once
this region has been initialized).
Also add code for reading from the info bank,
which is where the endorsement seed is
initially stored.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115
TEST=TCG tests running
Change-Id: Id8c16d399202eee4ac0c4e397bdd29641ff9d2f3
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/362402
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Old kevin / gru boards are no longer supported by our current GPIO
configuration and must revert a CL to boot properly. Detect if old
boards are used with an incompatible config and warn users of this fact
by spamming the EC console and blinking the LED red.
BUG=chrome-os-partner:55561
BRANCH=None
TEST=Boot new kevin, verify no console spam or LED blinkage is seen. Verify
old kevin + old gru spam the console and blink LED.
Change-Id: I6d49720f760a6bef2bb3db6872857a5f61259e06
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362653
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We had been putting the NVMEM flash where the boot rom would
expect to find RO_B, preventing us from ever being able to update
the bootloader.
With this CL, we're rearranging the flash to support both RO_A
and RO_B. The current flash layout now looks like this:
0x40000 RO_A
0x44000 RW_A
0x7c000 TOP_A
0x80000 RO_B
0x84000 RW_B
0xbc000 NVMEM
0xbffff <end of flash>
BUG=chrome-os-partner:44803
BRANCH=none
TEST=make buildall, also manual tests on Cr50 boards
First, check that our current process still works:
make BOARD=cr50 CR50_RO_KEY=cr50_rom0-dev-blsign.pem.pub
spiflash -i -v build/cr50/ec.hex
Yep, it does, but that only produces RO_A, not RO_B.
To test the dual RO behavior, I used prebuilt RO_A and RO_B blobs
for the bootloaders, signed using Marius' new scheme.
Build the unsigned image, then sign it using Vadim's scripts:
make BOARD=cr50 -j30
~/bin/bs hex
We'll garble various bits of the full image to invalidate each of
the four RO/RW/A/B parts.
Find lines common to both ROs and common to both RWs:
sort B1*.hex | uniq -c | grep ' 2 ' | \
awk '{print $2}' | sort > tmp.ro2
sort build/cr50/RW/ec.RW*.signed.hex | uniq -c | grep ' 2 ' | \
awk '{print $2}' | sort > tmp.rw2
ro=$(diff tmp.ro2 tmp.rw2 | grep '<' | head -1 | awk '{print $2}')
rw=$(diff tmp.ro2 tmp.rw2 | grep '>' | head -1 | awk '{print $2}')
Double-check to be sure we don't have any false matches:
grep -l $ro build/cr50/RW/ec.RW*.signed.hex B1_*.hex
grep -l $rw build/cr50/RW/ec.RW*.signed.hex B1_*.hex
The pre-signed RO_A image is older than RO_B, but both have the
same epoch/major/minor, which is all that the bootrom checks for.
It doesn't look at the timestamp.
The RW_A is older than RW_B because of the sequential signing
process. The RO bootloaders will check their timestamp, so RW_B
should be preferred.
RO_A RO_B RW_A RW_B
good good good good
cat build/cr50/RW/ec.RW*.signed.hex B1_*.hex > foo.hex
spiflash -v -i foo.hex
jump @00040400
jump @00084000
=> boots RO_A -> RW_B
RO_A RO_B RW_A RW_B
good good good bad
cat build/cr50/RW/ec.RW*.signed.hex B1_*.hex > foo.hex
ln=$(grep -n $rw foo.hex | awk -F: 'NR==2 {print $1}')
sed -i "${ln}d" foo.hex
spiflash -v -i foo.hex
jump @00040400
jump @00044000
=> boots RO_A -> RW_A
RO_A RO_B RW_A RW_B
bad good good good
cat build/cr50/RW/ec.RW*.signed.hex B1_*.hex > foo.hex
ln=$(grep -n $ro foo.hex | awk -F: 'NR==1 {print $1}')
sed -i "${ln}d" foo.hex
spiflash -v -i foo.hex
jump @00080400
jump @00084000
=> boots RO_B -> RW_B
RO_A RO_B RW_A RW_B
bad good good bad
cat build/cr50/RW/ec.RW*.signed.hex B1_*.hex > foo.hex
ln=$(grep -n $ro foo.hex | awk -F: 'NR==1 {print $1}')
sed -i "${ln}d" foo.hex
ln=$(grep -n $rw foo.hex | awk -F: 'NR==2 {print $1}')
sed -i "${ln}d" foo.hex
spiflash -v -i foo.hex
jump @00080400
jump @00044000
=> boots RO_B -> RW_A
Yay.
Now make sure RW_A and RW_B can be updated using usb_updater.
\rm -rf build
make BOARD=cr50 -j30
~/bin/bs
./extra/usb_updater/usb_updater build/cr50/ec.bin
I'm running RW_A, it updates and reboots into RW_B. Good.
reboot 5 times, and it reverts to RW_A.
Power cycle and it goes to RW_B again.
Update to RW_A.
\rm -rf build
make BOARD=cr50 -j30
~/bin/bs
./extra/usb_updater/usb_updater build/cr50/ec.bin
I'm running RW_B, it updates and reboots into RW_A. Good.
reboot 5 times, and it reverts to RW_B.
Power cycle and it goes to RW_A again.
Cool.
Change-Id: I6c1689920de06c72c69f58ad2ef1059d9ee0d75f
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362521
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This will be used to hack around code that only works on proto.
The earlier method of attempting to use board ID to determine
codepath worked to a limited extent, but fell short due to pin
swappings. So the dream of having a single binary that would work
on multiple board revisions died, and now if someone wants to build
for an old proto board they need to set this #define to 1.
BUG=chrome-os-partner:54947
BRANCH=none
TEST=tested with upcoming patches in this series
Change-Id: I5468c252e5401d69b108c75fa00b3dfbbcf77c22
Signed-off-by: David Hendricks <dhendrix@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360949
Reviewed-by: Shawn N <shawnn@chromium.org>
For now the presence of both RSA and EC certificates at fixed NVRAM
indices is considered evidence of TPM being through manufacturing.
BRANCH=none
BUG=chrome-os-partner:50645
TEST=with the rest of the patches applied TPM manufacturing status is
properly detected at startup.
Change-Id: Iff3861603272cdfb58ebc523458c114685b2429f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362351
Reviewed-by: Marius Schilder <mschilder@chromium.org>
