It is useful to be able to see which pins are set as wake pins and what
type they are. This change adds prints to show_pinmux to describe the
wake pins.
BUG=none
BRANCH=none
TEST='pinmux' should show DIOA12 as a wake_low source.
Change-Id: I2a0ccdbf9b07abb627c3d52c7dd28433a2beff3c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363494
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>
The ancient native tests can't deal with board-specific
configurations, don't build them. We run generic changes with
host tests and board-specific cases by running on real hardware.
BUG=chrome-os-partner:55705
BRANCH=none
TEST=make BOARD=cr50 tests; make buildall; test on Cr50 hardware
Change-Id: I5eb7229ca9df16293d6f0f84b474d4c992277baf
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363942
Reviewed-by: Vadim Bendebury <vbendeb@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>
Cr50 has sys_rst_l as a wake source, but it can't tell which pin woke it
on resume. To know the source it has to check the value of the pin on
resume. This change makes the delay long enough for Cr50 to resume and
check that sys_rst_is asserted.
BUG=chrome-os-partner:55674
BUG=b:30308276
BRANCH=none
TEST=enable sleep on cr50 and verify apreset still reset it
Change-Id: I8e088c5f13a4222142161d8b79550dfc6eb529d6
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364170
Reviewed-by: Shawn N <shawnn@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>
When the case close debug (CCD) feature is provided by an external chip
(e.g security chip or TCPC), we still need to be able to detect debug
accessory with Rd/Rd (by setting Rp/Rp when VBUS is detected without
seeing Rp).
Add a CONFIG_CASE_CLOSED_DEBUG_EXTERNAL configuration parameter for this
case.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:55410
TEST=manual:on Kevin, enable CONFIG_CASE_CLOSED_DEBUG_EXTERNAL,
plug a SuzyQ (with Rd/Rd) and verify that the device in debug mode
when transitioning to S5.
Change-Id: Ie04a000a7b0eb670e3808f7bca1180298dfcd9db
Reviewed-on: https://chromium-review.googlesource.com/363400
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>
On a power press that will bring the system to S0, start our 8 sec
timeout in case the power button is never released.
BUG=chrome-os-partner:55666
BRANCH=None
TEST=Press and hold power button on kevin to bring device to S0, verify
device boots in normal mode and powers down ~8 seconds after initial
press.
Change-Id: I1cbb52974bcc09d23a130df13815cee07968467a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363592
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added test recording when calling reset from command
line. These results are printed on the screen and
saved in /tmp/results/<board>/<module>.txt
BRANCH=None
BUG=None
TEST=Manual
- Connect, build and flash boards
- Navigate to ec/cts
- ./cts.py --run
- Find test results /tmp/results/<board>/<module>.txt
- Tests names should be left aligned in one column
and their results right aligned in a 2nd column
Change-Id: I3429d6092f2bd5d5f6825245f5439ace3f47f1fa
Reviewed-on: https://chromium-review.googlesource.com/360653
Commit-Ready: Chris Chen <twothreecc@google.com>
Tested-by: Chris Chen <twothreecc@google.com>
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>
The FUSB302A had silicon limitation that required using its
autodetect logic when presenting as a SRC. While testing on
Kevin/Gru and connecting PD dongles, observed issues where
following successful connects, the USB PD state machine would
remain in SRC_DISCONNECTED state after removing the dongle.
Flipping the connector (to reverse polarity) will recover from
this stuck state.
In order to resolve this problem and to make the tcpm_get_cc()
FUSB302 driver function more consistent with the USB PD protocol
state machine while acting as a source, the autodetect feature
is now only used when a revA silicon device is detected.
If it's not revA, then full manual mode is utilized for tcpm_get_cc.
In addition, a new measure_cc_pin_source funciton was added
that consolidates the operations that are shared between both
autodetect and manual modes.
BUG=chrome-os-partner:55429
BRANCH=None
TEST=Manual
Connected display adapter dongles and TypeC hub dongle repeatedly
and verified that each connect attempt resulted in the USB PD
state machine getting to SRC_READY state. Never observed the
error state described above which previously could be repeated
within ~ < 10 connection attempts.
Change-Id: I3c8c6990129e0f1555a6698574adc603d6b7b45b
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361617
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Reviewed-by: Joe Bauman <joe.bauman@fairchildsemi.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
A recent cr50 loader modification introduced a counter in a scratch
register which is incremented on every startup. The idea is that valid
RW would decrement the counter, signaling that the start was
successful.
Should the counter exceed the value of 5, the loader assumes that the
RW being started is not fit to run, and picks the older RW to run, if
available.
This patch adds a function to process the startup retry counter.
First of all the counter is zeroed, as this function is supposed to be
called only once the RW run is considered successful and reliable.
Then the current situation is examined. If the counter value read from
the scratch register exceeds 5 AND running image is not the newer of A
and B, it is considered an indication of a fallback from a bad newer
image.
To prevent the newer image from being considered a contender on the
following startups, its header is corrupted.
BRANCH=none
BUG=chrome-os-partner:55151, chrome-os-partner:55667
TEST=modified code for testing purposes, by adding a call to
system_process_retry_counter() to tpm_task() after line 534, which
would cause the new function to be called soon after boot.
built a new image and installed it on the debug board. Then
modified the image to throw an exception early in the boot up
sequence, and installed it as a newer image on the debug board.
Observed the debug board restart the new image several time and
then fall back to the older image, printing the following on the
console:
system_process_retry_counter:retry counter 7
corrupt_other_header: RW fallback must have happened, magic at 44000 before: ffffffff
corrupt_other_header: magic after: 0
The following restarts start the older image without trying to run
the failing newer image.
Change-Id: Ia7497401e38fe2c3957af910cf745e45da985245
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362776
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The SoC looks for two RO images at reset, and is typically
configured for two RW images as well. This CL reports version
strings for all those images, as well as identifying the active
RO and RW copies.
Since the RO image doesn't contain a version string, we create
one using the epoch_, major_, minor_, and img_chk_ members of its
signed header.
BUG=chrome-os-partner:55558
BRANCH=none
TEST=make buildall; run on Cr50 hardware
The "version" command now includes information like this:
RO_A: * 0.0.2/a3c3d5ea
RO_B: 0.0.2/8895c9eb
RW_A: cr50_v1.1.4965-a6c1c73-dirty
RW_B: * cr50_v1.1.4959-2f49d5c
The '*' indicates the active image.
The test/tpm_test/tpmtest.py program has been updated to request
the version information at startup, and it also now reports
similar information, just all on one line:
RO_A:* 0.0.2/a3c3d5ea RO_B: 0.0.2/8895c9eb RW_A: cr50_v1.1 ...
The active images are marked with a '*' following the ':', so
that the same regexp can match either format:
($ro, $rw) = m/RO_[AB]:\s*\*\s+(\S+).*RW_[AB]:\s*\*\s+(\S+)/s;
Change-Id: Ic27e295d9122045b2ec5a638933924b65ecc8e43
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362861
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
For the purpose of spoofing dual-role capability, treat
soft-disconnected batteries as not present, since they are not capable
of supplying a current until they are revived.
BUG=chrome-os-partner:55617
BRANCH=None
TEST=Manual on kevin w/ subsequent CL. Put battery into soft-disconnect
state. Attach charger and verify EC doesn't lose power and battery again
supplies current.
Change-Id: Ie6b83b3d4e1e33c4bbbd1a90450506e7dcd1dfb2
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/363003
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Stephen Barber <smbarber@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BD99955 charger auto exits from the battery learn mode if the charge
is inhibited. Hence, do not inhibit the charger in battery learn mode.
BUG=chrome-os-partner:55491
BRANCH=none
TEST=Manually tested on Reef using 'ectool chargecontrol' command.
Able to enter/exit battery learn mode safely.
Change-Id: If05f9a9451842b77619e0a8c5db5e54fec24f399
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/362123
Commit-Ready: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Tested-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
VSYSVAL_THL / THH are high / low hysteresis values below which dead
battery condition is triggered, which doesn't match our register
configuration. Leave these regs at default for now until we better
understand the effect of dead battery detection.
BUG=chrome-os-partner:55626
BRANCH=None
TEST=Manual on kevin with other pending changes, verify dead battery
successfully charges.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I35a44dd0005f165f17073e8b0f2fd5dca1eda856
Reviewed-on: https://chromium-review.googlesource.com/363030
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Rohm suggests setting VSYS to the higher value during precharge and only
setting it to the lower voltage after we have crossed the lower voltage.
Note that the VSYS register also controls the pre vs fastcharge
threshold, so setting VSYS to the lower voltage essentially enables
fastcharge.
BUG=chrome-os-partner:55524
BRANCH=None
TEST=Manual on kevin, verify dead battery is able to charge through
precharge to fastcharge.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ia5b953c8dfbb25970ab329d5487a317ad37ba609
Reviewed-on: https://chromium-review.googlesource.com/362442
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: David Schneider <dnschneid@chromium.org>
Reviewed-by: Vijay P Hiremath <vijay.p.hiremath@intel.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
There are two g chip versions in circulation currently, B1 and B2.
Make the 'version' command properly report it.
BRANCH=none
BUG=none
TEST=verified that both B1 and B2 report versions properly
Change-Id: I1c5b9f0da0170cda2c636b857e92b9d3de165422
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362643
Reviewed-by: Bill Richardson <wfrichar@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>
There are three timers, each with four capture/compare (CC)
registers. The timer code uses 3 CC registers from one timer.
Use macros for the defines, so that it is more obvious which
timer and which register are being used.
TEST=make BOARD=hadoken
BRANCH=NONE
BUG=None
Change-Id: Icb058d9717800a87b394270eef38a3a744a13b7d
Signed-off-by: Myles Watson <mylesgw@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361793
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Levi Oliver <levio@google.com>
Flush our UART buffer to ensure that we don't miss prints when we reboot
the EC.
BUG=chrome-os-partner:55539
BRANCH=None
TEST=Manual on kevin, issue cold reboot host command, verify that
"Executing host reboot command" is seen on console.
Change-Id: I96d5687b413ba4f603e3e7845b5cbba1c2d65efa
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362681
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@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>
The tpm firmware version register should report the current RW image's
version, not the RW_A.
BRANCH=none
BUG=chrome-os-partner:55145
TEST=verified that tpm firmware version reported by coreboot on the AP
console matches the version running on the device, for both RW_A
and RW_B.
From coreboot console log on two different runs:
Firmware version: RO: 84e2dde7 RW: cr50_v1.1.4943-f81a901
Firmware version: RO: 84e2dde7 RW_B: cr50_v1.1.4943-f81a901
Change-Id: I43f5432e44e38dbf9b42750dd2042a0f005bcbfb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362612
Reviewed-by: Bill Richardson <wfrichar@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>
When a kevin, gru, or reef are attached to the host machine using a
suzyQ, they can use CCD to update the AP or EC using flashrom. To use
suzyQ you have to specify raiden_debug_spi as the flashrom programmer.
This change adds support to flash_ec for using the right programmer to
update with CCD over suzyQ instead of servo.
BUG=chrome-os-partner:50701, chrome-os-partner:50712
BRANCH=none
TEST=make sure "util/flash_ec --BOARD=kevin --raiden" updates the EC
when CCD is enabled
Change-Id: Ie63337b9689c68aa60163d7e54c5ebefa97b4e21
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/344427
Reviewed-by: Randall Spangler <rspangler@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>
During initialization the NvMem module looks for either a valid
partition or that the NvMem area is fully erased. If neither of
these two conditions were found, then it was only returning an
error code and logging a message to the console.
This CL modifies nvmem_init() so that if the error case as described
above is detected, then it will call nvmem_setup() which will
create two valid partitions. In addition, the setup function
erases all of the existing data in the NvMem space.
Enhanced the unit test that deals with both partitions being
corrupted so that it verifies the version numbers are correct
and that all user buffer data is set to 0xff.
BUG=chrome-os-partner:55536
BRANCH=None
TEST=Manual
Executed make runtests TEST_LIST_HOST=nvmem and verifed that all
tests passed.
Change-Id: Ib932e02f15bd1aad7811032a12d826c76476e53f
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362448
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The USB controller should disable the PHY itself when usb is released,
but from the power tests I ran it does not. This change adds a call in
usb_release to deactivate the PHY.
It looks like having the AP on vs off also makes a difference in power
consumption. I am looking into that now, but until that is resolved turn
of the AP off while testing this USB change to see the effects on power.
BUG=chrome-os-partner:54331
BRANCH=none
TEST=manual
Without deactivating the PHY put cr50 into deep sleep on gru.
run 'reboot ap-off'
measure pp3300_haven_mw and it is around 4.5mW
Add deactivating the PHY during usb_release.
Put cr50 into deep sleep
run 'reboot ap-off'
measure the power and the average should be around 2mW
Change-Id: I16e6885a4e40c78e81d9bbc42c9af79e5f55047e
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362159
Commit-Ready: Dan Shi <dshi@google.com>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This script is more flexible for updating multiple targets,
including servo_v4, servo_micro, and sweetberry.
The command takes a json config file that specifies
flash layout, USB ID, and size.
BUG=chromium:571476
TEST=./fw_update.py -b servo_v4.json -f ec.bin; both RW, RO
BRANCH=none
Change-Id: Ic9dcee2c23484bb28c8bfaf1882c578314534116
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361835
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The clock() function was introduced to provide free running clock for
the TPM2 library, which expects this clock to run with a millisecond
resolution.
This patch fixes the bug where the function in fact was returning the
clock running at a microsecond resolution.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115
TEST=with the appropriate modification of the user of this function
all lockout related TCG tests pass.
Signed-off-by: nagendra modadugu <ngm@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361180
(cherry picked from commit b4e78b309900402499b8742199fb4536570d3000)
(cherry picked from commit fefaa02a4f2c807a3ad50137bd7dba7f5f081c31)
Change-Id: Ic02fffca610426d22e58609eb8c3693aec96ad5c
Reviewed-on: https://chromium-review.googlesource.com/362118
TCG test CPCTPM_TC2_2_22_02_08 installs an RSA key
for which p does not divide the modulus, and subsequently
the test is expected to fail accordingly.
This change adds the check necessary to pass this test --
a check that p divides N.
Also removed dangling function declaration for bn_mul().
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115
TEST=TCG test CPCTPM_TC2_2_22_02_08 passes consistently
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360968
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit c4430ecac8f77a05ac4071679de1535e0da2779e)
(cherry picked from commit 832d04b5b8cebf702d2ec00051615f827d2d16e1)
Change-Id: If2ffc6260ae848d75e93263a37e84f0ed7d301a0
Reviewed-on: https://chromium-review.googlesource.com/362117
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
The manufacturing status check verifies if the proper certificates are
found in the device NV RAM. This check can not succeed unless NV RAM
metadata is initialized by calling _TPM_Init().
If the check shows that the device has not been through manufacturing
sequence yet, TPM_Manufacture() needs to be invoked to make sure that
all relevant TPM structures are initialized and properly stored in NV
RAM. _TPM_Init() needs to be invoked again after that.
BRANCH=ToT
BUG=chrome-os-partner:43025
TEST=restarting Kevin device with pre-manufactured CR50 takes it
through factory initialization on every reboot. Restarting Kevin
once TPM is through manufacturing process shows that the
previously saved rollback counters are preserved.
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361093
Reviewed-by: Nagendra Modadugu <ngm@google.com>
(cherry picked from commit 61a0fe734e808d1dbdf56fb6023e04adf66553b3)
(cherry picked from commit 3207a57fb2f5957b6e833d9ab1f9ea46021c5e1e)
Change-Id: I80b69f2c4b8d0e4cca154db510867df39c707ce2
Reviewed-on: https://chromium-review.googlesource.com/362084
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>
This change updates the ecc and rsa key generation templates.
Due to crosbug.com/p/55260 in which the TPMT_PUBLIC template is
truncated during personalization, ecc generation requires a
workaround.
For RSA, allow the standard template to be used even on development
builds.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
BUG=chrome-os-partner:50115,chrome-os-partner:55260
TEST=test full personalize + cros_ack verify cert flow
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360441
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit db5a1ca8a40be9bf7e741637cd8d7f15f520ab11)
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit b6620239bb7c4f5900051677f40f161c0a853a94)
Change-Id: I1af83f1ec86e7ee4d325a4b7aabe03ce08c4108b
Reviewed-on: https://chromium-review.googlesource.com/362142
Reviewed-by: Nagendra Modadugu <ngm@google.com>
