The only place where two separate buffers for the RO version strings
is required is the tpm_registers.c:set_version_string() function.
In preparation of reporting the build string along with the version
string, let's rearrange the function not to require separate buffers
for the RO versions.
BRANCH=none
BUG=chrome-os-partner:55558
TEST=verified that version reported by the TPM driver on Kevin is
still correct:
localhost ~ # grep cr50 /sys/firmware/log
Firmware version: RO_A: 0.0.1/84e2dde7 RO_B:* 0.0.2/13eda43f RW_A:*...
Change-Id: I8924ac48bd838851670f0d659e95aa92a8524665
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364587
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
As a temp measure until a proper solution is implemented, reset the
restart counter when the PCR_Read command is issued by the host.
This is a good indication that Chrome OS is through the boot process,
as PCR value is used to determine the boot mode.
BRANCH=none
BUG=chrome-os-partner:55667
TEST=installed the new image on a Kevin cr50 and rebooted it in normal
and recovery modes, observed on the cr50 console the message like
> system_process_retry_counter:retry counter 1
Change-Id: Ib55e161d5edbf8f6e2d387fd756b94aa53c20ed8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364311
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
- Pass-thru to IBF handler code in case both IBHF and IBF interrupts are
pending, in order to properly keep track our Tx byte count.
- Don't disable the SHI IRQ in our host command handler callback since
system-wide interrupts are already disabled.
BUG=chrome-os-partner:55711,chrome-os-partner:55721
BRANCH=None
TEST=Manual on gru with subsequent commit. Verify `flashrom -p ec -r
file.bin` passes 100x with no errors or warnings.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6225ffde1fe0127c7484933fe4a151d22f42415c
Reviewed-on: https://chromium-review.googlesource.com/364234
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Whether the bootrom locks the bootloader or not is deteremined by
fuses and/or flags in the bootloader's signed header. This CL
locks the active bootloader, just case those aren't configured to
do so.
BUG=chrome-os-partner:55261
BRANCH=none
TEST=manual
On an unlocked bootloader, I see this after booting:
> rw 0x40090100
read 0x40090100 = 0x00000001
With this CL applied, I see this instead:
> rw 0x40090100
read 0x40090100 = 0x00000000
Change-Id: I2e1396b7d7e71c8633d97d3cb573e9468eeb51e7
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/364280
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
It has rare chance for FW to get a unexpected value when reading
IBUFSTAT. This is because the clock source of SHI and CPU are
asynchronous. The reading value is invalid if IBUFSTAT is during
transition state. Use two consecutive equal reading can make sure
the value is valid.
BUG=chrome-os-partner:34346
TEST=run "while true; do ectool version; done" on gru, verify each
failure happens about 50000 host commands
BRANCH=none
Change-Id: Ie246561d201dd87d89cb2424c23d016dcdcd47c9
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/362734
Commit-Ready: Randall Spangler <rspangler@chromium.org>
Tested-by: CH Lin <chlin56@nuvoton.com>
Tested-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Primes generated for RSA keys need to hold the following
property (public_exponent mod p) > 1 in order for the
private exponent to exist. This change adds this check
for the public exponent RSA_F4 (65537).
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/360662
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@google.com>
(cherry picked from commit 1c37f84ae7fae9f5841421447c7f235790ab6a93)
(cherry picked from commit b2c1678b27c79a2c93f5519e00161243fa0a5d88)
Change-Id: I87bd898cc3750bf1e492bc263edb6eac1edf2a17
Reviewed-on: https://chromium-review.googlesource.com/362115
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The modinv logic shouldn't reduce modulo MOD
on a carry condition. Instead, just use more
space to hold the carry bit.
Also use full size buffers for all variables.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524,chrome-os-partner:50115
TEST=unit tested
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360248
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit 3f4e131daef04db5c990bb4532bb67ee9e58c02b)
(cherry picked from commit 485b02a17ecdd3c52210fd90ff29b4f1b829a47a)
Change-Id: I8d4f78966bfe15f0739c9de23f5a12685a65aabb
Reviewed-on: https://chromium-review.googlesource.com/362113
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
The name BIGNUM collides with a namesake struct
in openssl. It would be convenient to write
test code that compares results between openssl
and dcrypto, hence this rename.
Also rename some #defines that conflict with
openssl names.
CQ-DEPEND=CL:*270476
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524,chrome-os-partner:50115
TEST=build succeeds
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/360346
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
(cherry picked from commit a15b495497728a6b212bd87e92f6ba5ba463f985)
Change-Id: Ic53ce805cfcc591c68fbc1ef90ff2f92cec973a6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362112
Reviewed-by: Nagendra Modadugu <ngm@google.com>
The SHA config register should be cleared, so that
only required bits are set on init().
Doing so ensures that previous settings that used
the engine in a different mode, e.g HMAC, do not
survive.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=build succeeds; tpmtest.py tests pass; manufacture works
(cherry picked from commit 9b3619ddd7304359ee17e243923f1e47c925cb21)
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/359418
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Change-Id: If5a79af06ea7512f19775a2f34d741b144f211f7
Reviewed-on: https://chromium-review.googlesource.com/358982
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Different actions need to be taken on PLTRST_L depending on
if it is asserted or deasserted. The vstore module needs to
reset its locks when PLTRST_L is asserted (host is in reset).
The interrupt was previously on occurring on a deassertion of
PLTRST_L (rising edge). That's not conducive for handling
actions which are required for assertion (falling edge).
Lastly, fix the CONFIG_CHIPSET_RESET_HOOK logic to be
called when PLTRST_L is asserted.
BUG=chrome-os-partner:55471
BRANCH=None
TEST=Able to boot and reboot without getting vboot hash saving
errors. Also am able to see the assertion/deassertion messages
on the console.
Change-Id: I70eac3309a5876de775ec5c34dab2e9aa8bbb42c
Signed-off-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/362000
Reviewed-by: Shawn N <shawnn@chromium.org>
usb-stream is used by USB updater as well as uart
forwarding. Add parameter for custom USB class define.
BUG=chromium:571476
TEST=builds
BRANCH=none
Change-Id: Id6294709de0c5408b10ed366b261be1bc7da7767
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361832
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
MODULE_SHI is used for the SPI master interface pins, so don't
reconfigure those. Instead manually configure the SHI pins using the
appropriate DEVALT bit.
BUG=chrome-os-partner:54328
BRANCH=None
TEST=Manual on kevin. Verify SHI continues to function on cold boot,
sysjump and resume from S3. Verify SPI sensors now function on resume
from S3 - `accelinit 0` succeeds.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I63f028968f3d0dbc9d7ca7dacc70c9c399f7a180
Reviewed-on: https://chromium-review.googlesource.com/362061
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Caesar Wang <wxt@rock-chips.com>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Having uart0 RX enabled can cause serious issues. This change adds a
config option to disable uart0 rx no matter what.
BUG=none
BRANCH=none
TEST=On B2 check that the ultradebug console is now read only
Change-Id: Icaec6954ffd3cbf0fda3f53581f6e4020d555267
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361976
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Programmable Peripheral Interconnect is a shared resource.
This CL adds code for allocating PPIs to devices.
BUG=None
BRANCH=None
TEST=Modify the I2C code to use this PPI allocation code and test
I2C communication (using experimental MXT touch controller code)
Change-Id: I8ec27867d041982ef18e8515d6434c5de2c189c5
Signed-off-by: Myles Watson <mylesgw@google.com>
Reviewed-on: https://chromium-review.googlesource.com/361405
Commit-Ready: Myles Watson <mylesgw@chromium.org>
Tested-by: Myles Watson <mylesgw@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Levi Oliver <levio@google.com>
Remove "task_disable_irq()" function call in EC_RTC_ALARM_CLEAR case.
Host command "RTC_SET_ALARM" with 0 second does not disable volume key interrupt.
BUG=chrome-os-partner:55401
BRANCH=none
TEST=check EC UART log message.
If you press volume up/down button
- Before HC 0x47 (RTC_SET_ALARM Command with 0 second)
Log : Button 'Volume Up/Down' was released.
- After HC0x47
Log : Button 'Volume Up/Down' was released.
GPIO volume key is still enable.
Change-Id: I8d8a4fa4927046b76a49ac4833b6a710db2e05be
Signed-off-by: younghun kim <young-h.kim@samsung.com>
Reviewed-on: https://chromium-review.googlesource.com/361670
Commit-Ready: Wonjoon Lee <woojoo.lee@samsung.com>
Tested-by: Younghun Kim <young-h.kim@samsung.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
This workaround ensure that we can successfully get
register latch.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=chrome-os-partner:55044
TEST=We simulate the delay time between first and second read,
and prove this method can avoid latch fail.
Change-Id: I7cafb53a8efbb2eee09af29d7365806dc0deb762
Reviewed-on: https://chromium-review.googlesource.com/358730
Commit-Ready: Dino Li <Dino.Li@ite.com.tw>
Tested-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
USB is only used for CCD. USB should not be enabled as a wakeup source
unless a debug accessory is detected, because that is the only USB
traffic we care about. The rest may be from other sources like the HID
interface or something else using those signals. This change disables
the utmi wake source when the debug accessory is attached and enables it
when it is connected.
BUG=chrome-os-partner:54796
BRANCH=none
TEST=manual
The SPI_CS_L pin still gets triggered and will wake up cr50
before usb so disable wake up pins as a wakeup source.
Verify Cr50 goes to sleep and plugging in a SuzyQ will wake it
up and after removing it Cr50 will go back to sleep.
Change-Id: Ib97244016b0af244c340259915def9f4d8f97569
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360693
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Call rdd_attach or detach based on the current CC state and initialize
the debug map to the proper state.
BUG=none
BRANCH=none
TEST=reboot cr50 with suzyq plugged in and check ccd is initialized.
reboot cr50 with suzyq disconnected and verify ccd is disabled.
Change-Id: I61eb9f357ee4309030b06225502add4f5e43ac31
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/361596
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
RDD is working reliably and defaulting to CCD makes it difficult to
display port functionality.
BUG=chrome-os-partner:52281
BRANCH=none
TEST=manual
run 'reboot ap-off' on the EC. Plug in a unreworked suzyq and
verify 'lsusb | grep 5014' doesn't show any devices
run 'powerbtn' on the EC and verify 'lsusb | grep 5014' now
shows a device.
Check that this works on gru, kevin, and reef.
Change-Id: If4a9fc2f8f874e602c28f8e397c9bf8ea6184b59
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360914
Reviewed-by: Bill Richardson <wfrichar@google.com>
Having DIO A4, A8, and A14 connected to the spi master output pads
prevents reef from booting. We need to tristate those pins when spi ccd
is not in use.
This change disconnects those pins from the spi peripheral when spi is
disabled and reconnects them when spi is enabled.
BUG=chrome-os-partner:53582
BRANCH=none
TEST=manual
use 'pinmux' to verify DIOA4, DIOA8, and DIOA14 are set have
GPIO 7, 8, and 9 as their output sources when not using the usb
spi interface.
Check the usb spi interface still works.
Enable usb spi then disable ccd and check that the pins are
connected back to the non-peripheral gpios.
Verify the AP on kevin and reef can be flashed using servo.
Verify the AP boots successfully on both.
Change-Id: I85d70422a30da445076432d2bfc81960aeba8578
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357883
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When the debug cable is disconnected the a USB suspend interrupt is
triggered and puts the chip to sleep before rdd can detect a change on
the cc lines and disconnect from CCD. This prevents the DEBUG_STATE_MAP
from being reset to detect the debug connect and is left detecting the
disconnect. Since the debug accessory is already disconnected the RDD
interrupt will wake up the chip right after it goes to sleep.
The UTMI and PIN wake source still cause the chip to wake up before the
RDD interrupt, so disable those to test this change.
BUG=chrome-os-partner:54796
BRANCH=none
TEST=Disable wake pin and utmi wake sources. Put cr50 to sleep. Attach a
reworked suzy q and make sure cr50 wakes up. Detach it and check that it
goes back to sleep. Do that a couple of times. Check CCD is still
enabled when the debug accessory is detected and disabled on
disconnect.
Change-Id: I58a012895bc874dcdd512aa84de9a917469f3139
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360234
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
When the uart rx signal is not externally pulled high by the EC or AP,
the low rx signal triggers thousands of uart interrupts. At
initialization Cr50 does not know the state of those devices. If the
uart is initialized when the device is off these interrupts may prevent
Cr50 from booting on certain boards. This change does not enable the
uart until the device state is know. When the device state monitoring
detects that the AP or EC is powered on it will enable uart 1
or 2 and when it detects that it is powered off then the uart will be
disabled.
BUG=none
BRANCH=none
TEST=UART_CTRL registers are set to 0 for uart 1 and 2, and are changed
to 3 when the device state is on.
Change-Id: I43e847c6abb8507a86de92a5c226a79f3add7f97
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/360026
Reviewed-by: Scott Collyer <scollyer@chromium.org>
The bit IRQ11B of register HIIRQC is meaningful only when PM Channel 1
is in PC87570-Compatible. In previous commit, we deprecate use of
PC87570 mode but set the bit unintentionally. This will not cause any
bug but may make confused when reading the code.
Modified sources:
1. lpc.c: CLear IRQ11B in register HIIRQC.
BUG=chrome-os-partner:34346
TEST=make buildall -j; verify on Wheatley
BRANCH=none
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Change-Id: I594222c29557add847a1f689859fdf558d64fdd3
Reviewed-on: https://chromium-review.googlesource.com/358536
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Amit Maoz <Amit.Maoz@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
If the UART0 RX pad is not pulled up, cr50 will get held up on all of
the interrupts triggered by the low signal. This causes cr50 to reboot
continuously. UART0 RX was moved to DIOA13, which does not have an
internal pull up. This means we have to rely on an external pull up.
Because not having an external pull up on DIOA13 could prevent the
system from booting and UART0 RX is only used as an alternate debugging
mechanism from suzyq, we decided it is best for UART0 RX to be disabled
by default.
BUG=none
BRANCH=none
TEST=Connect UART1_RX to DIOA1 and test that it still accepts input.
Disconnect it from any pads. Verify the system boots normally and
console input from DIOA1 no longer works but the suzyq shell still does.
Change-Id: I68988c59cfce610cc6c360bf8dd9685e98ab12ff
Reviewed-on: https://chromium-review.googlesource.com/357881
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Board initialization function configures certain RBOX registers, but
RBOX initialization runs at the same priority as board initialization,
and as such is not guaranteed to run in time.
Reducing RBOX initialization priority guarantees that RBOX is
initialized by the time board init function needs to access it.
BRANCH=none
BUG=chrome-os-partner:49959
TEST=the AP_WP_L signal now reports the expected value:
> gpioget AP_WP_L
1 AP_WP_L
>
Change-Id: I9c29451a08fc47d3409031bda1a936de243c0c70
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/358169
Tested-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This patch replaces a long standing stub. When the EC asserts this
signal, the CR50 must reset.
But this signal could be driven by CR50 itself as well, and in that
case the signal's assertion should not be causing the CR50 reset.
Ideally it should be possible to tell if the pin is configured as
output and ignore its assertion in that case. But there is no API for
checking the pin configuration settings at this time. An API function
is added to check if the AP Flash is being programmed, the GPIO
configuration access API is left for future enhancements.
BRANCH=none
BUG=chrome-os-partner:52366, chrome-os-partner:54982
TEST=issue 'reboot' command from the bash command line.
- verify on the cr50 console that it reboots along with the rest of
the device
- observe that reading of the NVRam spaces is still fully
functional, and Kevin can boot all the way up to the login
screen.
- try flashing AP firmware through CR50, verify that it succeed.
Change-Id: Ie4506238dc8b158b32121719a2db7fd232fd7d6c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/357967
Reviewed-by: Shawn N <shawnn@chromium.org>
In NPCX5m5g/NPCX5m6g, PM channel 1 can support both
PC87570-Compatible and enhcnced mode. In next generation of chip,
only enhanced mode will be supported. Set the enhanced mode as
default in the firmware to support all gereration of chips.
BUG=chrome-os-partner:34346
TEST=make buildall -j; verify on Wheatley
BRANCH=none
Change-Id: Ide9e17a1fe8a0d2bfdc33efe2336a10702660679
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/357752
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
The modexp implementation occasionally produces
a result larger than the modulus, in which case a
single final reduce is required. The software
based implementation already has this check.
BRANCH=none
BUG=chrome-os-partner:43025,chrome-os-partner:47524
TEST=tpmtest.py passes
Change-Id: I0a830781e2a109963394d0702cbc2ca6457c410c
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/357010
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
SHI_OBUF_VALID_OFFSET may wrap on buffer full, leaving us with an
incorrect tally of bytes transmitted. Always assume the worst case, that
SHI_OBUF_VALID_OFFSET is at maximum, when deciding to apply 256B bypass.
BUG=chrome-os-partner:54566
BRANCH=None
TEST=Manual on gru. Verify 'flashrom -p ec -r read.bin' does not produce
CRC errors.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I7c0ccc1b555838854584a3be8ced50057eaea961
Reviewed-on: https://chromium-review.googlesource.com/356771
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shelley Chen <shchen@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
