The typical power consumption in sleep mode is 65uA.
IT83xx uses deep doze mode for low power idle task. The typical power
consumption in this state is 280uA (depends on EC tasks, it should be more)
and the wake up time is in microsecond. We are using deep doze mode for
low power idle task instead of sleep mode is because the wake up time
will be 6ms more.
While in system hibernate (EC sleep mode), EC won't wake up frequently so
we can keep the power consumption at 65uA.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=- hibernate 0 [1|999999]
- hibernate [1|5|10|600]
- hibernate then press power button.
- hibernate then lid open.
Change-Id: I94884c010264f01ede4950c6bb1b0a444d7b1e6d
Reviewed-on: https://chromium-review.googlesource.com/383332
Commit-Ready: Dino Li <dino0303@gmail.com>
Tested-by: Dino Li <dino0303@gmail.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
We should clear STASTR to release SCL only after NACK/STOP bits are set.
If an interrupt which priority is higher than i2c's issues at this moment,
i2c hardware might not generate NACK since SCL is already released by
clearing stall's pending bit.
Modified sources:
1. i2c.c: Fixed bug i2c sometime cannot generate NACK during Read Byte.
BRANCH=none
BUG=chrome-os-partner:34346,chrome-os-partner:57452
TEST=make buildall; passed "while(1); do; ectool i2cread 8 0 0x50 0x44;
done;" on reef.
Change-Id: I68ee5bf3d703cbe4fceefcfcc9afab9cb14bc2dc
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/386586
Commit-Ready: Kevin K Wong <kevin.k.wong@intel.com>
Tested-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Kevin K Wong <kevin.k.wong@intel.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
Enable the SHI interrupt only after we have received and begun
processing our host command. Disable the SHI interrupt once our
transaction is complete (with either success or error status). This will
prevent the SHI interrupt from being asserted at the same time as the CS
interrupt, which can lead to the SHI interrupt being serviced first.
Also, it avoids needless, non-useful SHI interrupts during error
transactions.
BUG=chrome-os-partner:55710,chrome-os-partner:55795,chrome-os-partner:56254
BRANCH=None
TEST=Manual on gru. Stress test flashrom w/ unpowered Donette attached
(for host command spam), verify no errors encountered after 100 minutes.
Also verify host command interface functions properly after sysjump.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/384583
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
(cherry picked from commit 668763721aab31a102ead348d7cfe1c72f50cb71)
Change-Id: I7292d1b34d3e1c71628a8b5d663ce9fd865493f4
Reviewed-on: https://chromium-review.googlesource.com/386447
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
On CHIPSET_SHUTDOWN set the idle_action to deep sleep. If sleep is
enabled it will go into deep sleep. If not it will wait until sleep is
sleep is enabled.
This change also sets the idle_action to IDLE_DEFAULT when resuming from
deep sleep or during init. Before cr50 kept track of the previous idle
state in a PWRDN register and then used that state during the next
resume. If we went into deep sleep, on resume we want the idle action to
be reset to sleep and then only enter deep sleep if we have detected the
AP is off.
BUG=chrome-os-partner:56100
BUG=chrome-os-partner:55747
BRANCH=none
TEST=manual
run 'poweroff' on the AP and see that cr50 enables deep sleep
verify that even if the ap is powered off it doesn't prevent ccd
from working and when suzyq is unplugged cr50 will go into deep
sleep
After running poweroff on the AP wait a while and run powerbtn
on the EC. Verify the system can boot up fully without going
into recovery.
Do this on gru and reef.
Change-Id: I07f5a9d85dd0467cd22e499d4261c75caf653563
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/373139
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
We found the api utility in ROM doesn't enable burst mode of GDMA. It
influences the performance of FW download a lot. The CL modified GDMA
for moving the code of the other region from flash to ram. And move a
function that kicks off GMDA transactions to suspend ram in case this
utility is erased by itself. This issue will be fixed in our next
generation.
Modified sources:
1. system.c: Implement GDMA bypass.
2. system_chip.h: Import flash addresses for GDMA bypass code.
3. registers.h: Add GDMA register definitions.
4. cortex-m/ec.lds.S: Add lowpower_ram2 section in linker script.
BRANCH=none
BUG=chrome-os-partner:56794
TEST=make BOARD=npcx_evb; test sysjump and measure download time
Change-Id: I8490f8f2e5a8cdcb6fd10511878c4a4af8073bbf
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/381779
Commit-Ready: Shawn N <shawnn@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We want the default build to be ready for production use, without
any unlocked security features, development-only tests, etc.
Running "make buildall" or "make BOARD=cr50" builds the
default (production) image.
To build a development image, use
CR50_DEV=1 make BOARD=cr50
This CL adds "-DCR50_DEV=$(CR50_DEV)" to the CFLAGS for use in
compiled code.
BUG=chrome-os-partner:55557
BRANCH=none
TEST=make buildall
Verify that
#ifdef CR50_DEV
[stuff]
#endif
works inside C code.
Change-Id: Id5e16e9ba0135828f4365fc1ac4a23384f30ba01
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/385059
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
If the host sends a back to back I2CS write followed by a read of the
access register, then the read IRQ can be missed by FW because it was
clearing this bit at the end of the ISR. This would result in a
following write to have the incorrect number of bytes since the
address register byte from the read that wasn't processed gets left in
the HW write fifo.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
The issue was happening at the beginning of depthcharge. Without this
fix, I would see the Cr50 console message:
'data size mismatch for reg 0x0 rx 2, need 1'
After moving the IRQ clear could not reproduce this message. In
addition, the debug I2CS log showed that there was a read transaction
immediately following the write.
Change-Id: I9854dde6880a789e0acb2b1f6a06b43c73a5a2df
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382687
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
There is no point in waiting for a reset to clear the fallback
counter, it can be cleared as soon as USB update is finished.
BRANCH=none
BUG=chrome-os-partner:56864
TEST=on a kevin-tpm2 device: set the reset counter to 7 by running
> rw 0x40000128 1
> rw 0x4000012c 7
on the cr50 console. Then try uploading a new RW image over Suzy-Q
and verify that it is running after reset.
Then verify that cr50 can still be updated
Change-Id: I098a87c48b2fe864143715b1e90d4bb2409b9eae
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/383077
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Sanity tested by powering up cr50 and checking for correct RBOX
register values.
This patch is mainly to address RBOX debounce issues and key blocking
while EC_RST is asserted. A debounce value less than 4, sometimes
causes initial pin values to be incorrectly detected. The latter is
related to https://chromium-review.googlesource.com/#/c/357590/.
As RBOX controls cannot be selectively bypassed (they have to be
bypassed as a group), all registers are set up in this patch
BUG=chrome-os-partner:54602
BRANCH=None
CQ-DEPEND=CL:377621
TEST=manual on Kevin
Do three-finger salute, enter recovery mode.
Change-Id: Ieb82c94fa33888ead359a77bf77981567998b3fc
Signed-off-by: Timothy Chen <timothytim@google.com>
Reviewed-on: https://chromium-review.googlesource.com/372001
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
TTC must be written twice, otherwise the value will be lost on EC reset,
even if VBAT stays stable.
BUG=chrome-os-partner:57010
BRANCH=None
TEST=On kevin, run 'rtc set 55555' then trigger cold reset through
servo. Run 'rtc' on subsequent boot and verify timing ticks did not
reset to zero.
Change-Id: If05b698e75eece5f8879a109b98886b547eb71a4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/382654
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The CTR was set to 1 less than the max PWM value, so when the DCR
is set to max PWM value, duty goes to zero. The bug is fixed by
setting CTR to PWM max vlaue.
BUG=chrome-os-partner:57052
BRANCH=None
TEST=Manual on terminal.
> pwmduty 1 raw 0
Setting channel 1 to raw 0
1: disabled
> pwmduty 1 raw 65535
Setting channel 1 to raw 65535
verified that screen didn't blank
Change-Id: I10885d382f1bd252a5e7355da99dc00bd876e29f
Reviewed-on: https://chromium-review.googlesource.com/381632
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
In order to improve the performance of sysjump, the CL increases the clock
freq of ec to 50M HZ (The maximum freq rate for SPI flash.). Once ec jumps
into the other region successfully, the clock freq is restored to the
default value (15MHz) in main routine.
Modified sources:
1. clock.c: Add clock_turbo for speed up clock's freq to max.
2. clock_chip.h: The declarartion for clock_turbo.
3. system.c: Speed up clock rate before downloading FW.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make BOARD=npcx_evb; test nuvoton IC specific drivers
Change-Id: I996e35fff336e6292599497feb1ee6c2f95becba
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/381799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
We don't really have the ability to build the latest signer yet, but
this should not stop us from being able to build a properly signed
image using the ec makefiles.
As a stopgap measure the suggestion is to keep the latest signer
binary in ~/bin/codesigner in chroot, then with this patch applied
invoking make with CR50_DEV=1 will cause the proper sighner used and
proper signing procedure followed.
The signed targets need to be built in series to avoid concurrent use
of the signer fob, an addition dependency is being added to enforce
that.
BRANCH=none
BUG=chrome-os-partner:55557
TEST=ran make as follows:
CR50_DEV=1 make BOARD=cr50
touched the fob when requested, uploaded the generated
build/cr50/ec.bin on a kevin-tpm2 using usb_updater, and observed
it boot properly with the new version.
Change-Id: Ia9494bdc60b4bd3b8e5e09cbcbd8b27409c739d2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376885
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reads of the TPM fifo by the Host are done in chunks of up to 63 bytes
at a time. The existing routine used to copy data read from the TPM
layer to the I2CS fifo operates one byte at a time. This method is
fine for single and four byte register reads. However, for larger
buffers the performace can be improved by aligning the the fifo write
pointer to be at a word boundary.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Utilized test code on the host to initiate TPM fifo reads of various
lengths and added timing markers on the Cr50 to compare performance
between the existing byte at a time and the new full buffer write
funciton. Verifed that the fifo reads will still correct and compared
the time consumed copy TPM fifo data to the I2CS HW fifo.
This test processed 1910 bytes over 34 fifo reads.
Byte at a time method:
1910 bytes: 6375 uS: Avg Time = 3.233 uS per byte
Full buffer write:
1910 bytes: 3009 uS: Avg Time = 1.57 uS per byte
Change-Id: I3a47a350ab7af740a452fd115c33117b453b9611
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/377663
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This CL adds support for reading of TPM fifo registers. Since I2C does
not provide means to communicate how many bytes the host wants to read
there must be some handshake involved between the host and Cr50.
The method added by this CL to allow Host reads of the TPM fifo
assumes the following steps:
1. Host reads burstcount from Cr50 (which will be set to default 63)
2. Host reads 1st 10 bytes of the TPM response.
3. Cr50 will copy MIN(burstcount, msg_len) bytes into its I2CS HW fifo
4. Host computes msg_len and calculates amount of data still buffered
5. Host does a TPM fifo read of buffered data only
(The following steps are repeated until the response read is complete)
6. Host reads burstcount from STS register.
7. Host issues read of burscount bytes from TPM fifo
8. I2CS will copy burstcount amount of bytes in to I2CS HW fifo
9. TPM layer sets burstcount to MIN(63, remaining msg bytes)
The version register is treated similar to a fifo access. The data
written or the number of bytes is a don't care, but there must be
at least one byte of data written with the version register write.
In the case of reads, the host must read burstcount bytes of the
version register. If burstcount is longer than the Cr50 version string
there is no issue because the version register read function always
returns the number of bytes requested, stuffing in 0s once the end of
the version string is reached.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Created test code in coreboot that exercises TPM register reads and
writes. In addition, created a means to spoof a TPM cmd send and
response read by Host. For these tests the header length is defined as
10 bytes and used 3 different payload lengths. The results for a
payload length of 256 and 39 (message < 63) are shown below. Note the
0xaa and 0x55 have been inserted by the TPM spoof code on the host to
mark the end of the header.
=================================================
Cr50 TPM Register Read tests
TPM Access = 0x0
TPM2 STS = 0x4003f80
TPM2 DID_VID = 0x281ae0
DID = 0x28, VID = 0x1ae0
Ver segment read 1, ret = 0
Version: B2:0 RO_A:0.0.1/84e2dde7 RW_A:0.0.1/cr50_v1.1.5151-acaef21+
=================================================
TPM Cmd: 266 bytes, Hdr = 10, Payload = 256 (last = ff)
TPM STS: Sending command_ready
fifo wr: burstcount = 63
fifo wr: Sent TPM Cmd: len = 266 bytes
TPM STS: Sending TPM GO
TPM STS: data_avail set
TPM STS: 04 00 3f d0: burst = 63
fifo rd: Msg_len = 266
fifo rd: Hdr Len = 10, fifo_adjust = 53
fifo rd: Drained Cr50 HW fifo of 53 bytes
fifo rd: burst = 63
fifo rd: burst = 63
fifo rd: burst = 63
fifo rd: burst = 14
fifo rd: complete 266 byte msg read
[0000]: 00 00 00 00 01 0a 00 00 aa 55 00 01 02 03 04 05
[0010]: 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
[0020]: 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
[0030]: 26 27 28 29 2a 2b 2c 2d 2e 2f 30 31 32 33 34 35
[0040]: 36 37 38 39 3a 3b 3c 3d 3e 3f 40 41 42 43 44 45
[0050]: 46 47 48 49 4a 4b 4c 4d 4e 4f 50 51 52 53 54 55
[0060]: 56 57 58 59 5a 5b 5c 5d 5e 5f 60 61 62 63 64 65
[0070]: 66 67 68 69 6a 6b 6c 6d 6e 6f 70 71 72 73 74 75
[0080]: 76 77 78 79 7a 7b 7c 7d 7e 7f 80 81 82 83 84 85
[0090]: 86 87 88 89 8a 8b 8c 8d 8e 8f 90 91 92 93 94 95
[00a0]: 96 97 98 99 9a 9b 9c 9d 9e 9f a0 a1 a2 a3 a4 a5
[00b0]: a6 a7 a8 a9 aa ab ac ad ae af b0 b1 b2 b3 b4 b5
[00c0]: b6 b7 b8 b9 ba bb bc bd be bf c0 c1 c2 c3 c4 c5
[00d0]: c6 c7 c8 c9 ca cb cc cd ce cf d0 d1 d2 d3 d4 d5
[00e0]: d6 d7 d8 d9 da db dc dd de df e0 e1 e2 e3 e4 e5
[00f0]: e6 e7 e8 e9 ea eb ec ed ee ef f0 f1 f2 f3 f4 f5
[0100]: f6 f7 f8 f9 fa fb fc fd fe ff 00 00 00 00 00 00
=================================================
TPM Cmd: 49 bytes, Hdr = 10, Payload = 39 (last = 26)
TPM STS: Sending command_ready
fifo wr: burstcount = 63
fifo wr: Sent TPM Cmd: len = 49 bytes
TPM STS: Sending TPM GO
TPM STS: data_avail set
TPM STS: 04 00 3f d0: burst = 63
fifo rd: Msg_len = 49
fifo rd: Hdr Len = 10, fifo_adjust = 39
fifo rd: Drained Cr50 HW fifo of 39 bytes
fifo rd: complete 49 byte msg read
[0000]: 02 00 00 00 00 31 00 00 aa 55 00 01 02 03 04 05
[0010]: 06 07 08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15
[0020]: 16 17 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25
[0030]: 26 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Change-Id: I0e05156d6012c6dc86844e4c0ea80cc04f45734a
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374528
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Removed 3 TPM register definitions which were not used in
tpm_registers.c and added missing entries to the I2CS translation
table for TPM register address lookup.
Moved the SPI specific locality 0 offset from tpm_registers.c to
sps_tpm.c so the register defines in tmp_registers.c can be
common to both the SPS and I2CS interface.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
For I2CS verification on Reef AP console used the command 'i2cget
-y 8 0x50 <addr> b' to read both the TPM access and RID register.
For SPI verifcation updated Cr50 FW on Kevin and verified that the
AP successfully boots. Additionally, issued the command from the
Kevin console 'trunks_client --own' and got the following console
output without any errors being listed.
[INFO:tpm_utility_impl.cc(1692)] CreateStorageRootKeys: Created RSA SRK.
[INFO:tpm_utility_impl.cc(1735)] CreateStorageRootKeys: Created ECC SRK.
Change-Id: Ib0b70e22cd46de2c59bd2e73f3c9aebd661e66c4
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/368621
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This CL includes changes in Cr50 required to support TPM via
the I2CS interface.
BRANCH=none
BUG=chrome-os-partner:40397
TEST=manual
Limited testing so far. Verified that the I2CS interface is
initialized properly and that register reads occur when
initiated on the AP console via command i2cget -y 8 0x50 0x1 w
Change-Id: I16ac17c7c82d420a384908e4b5a9867a3b24bc9e
Reviewed-on: https://chromium-review.googlesource.com/356241
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Remove timeout to avoid fetching unknown instruction from e-flash
and causing exception.
Also fixed:
- To make sure immu(dynamic cache) is reset after a erasing/writing
operation.
- Verify function is in critical section.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=console commands: "flasherase" and "flashwrite".
Change-Id: I0c84282ac4689cd762159071afae3efeea31d281
Reviewed-on: https://chromium-review.googlesource.com/380500
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>
Port USB firmware update to stm32f4 dwc usb from st usb.
This includes usb dwc usb stream inplementation, generic
endpoint interfaces, and the sweetberry test case.
BUG=chromium:608039
TEST=usb update works
BRANCH=None
Change-Id: Ia26e4f7e990ee64991468799c99b036f5f32190f
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/377520
Reviewed-by: Randall Spangler <rspangler@chromium.org>
CONFIG_FLASH_NVMEM_SIZE was set to CFG_TOP_SIZE and then the partition
size was computed by dividing this value by 2. Changed this so that
now the partition size is set to CFG_TOP_SIZE and the total size is
the partition size * 2. Also reduced the CFG_TOP_SIZE to 0x4000 as
that should be plenty for TPM requirements and leaves room for future
gnubby use.
BRANCH=none
CQ-DEPEND=CL:379076
BUG=chrome-os-partner:56798
TEST=manual
Tested on Kevin, erased the existing NvMem area and verified that TPM
was still manufactured and executed the command: trunks_client --own
Erased parition 0 and 1 in the new locations and repeated the tests.
Change-Id: Ie8910bec641d8d1ff390be5b03b430bf39d18404
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/379095
Commit-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Tested-by: Andrey Pronin <apronin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
There is now a call to reset the retry counter before the hard reset
after an update. Cr50 will use the updated image for the next 5 boots,
but on the 6th it sees the retry counter is greater than 5 and then
jumps back to the old image. Cr50 needs to call
system_process_retry_counter to reset the counter and corrupt the old
image header to prevent falling back to the old image.
Normally the reset counter would be processed after it receives a TPM
command. Reef does not have Cr50 TPM support. Until Cr50 has TPM
support for Reef, Cr50 should have a different point to know when the
update is good. This change adds a board property to mark the process
the reset counter once the Cr50 USB controller receives a set address
request from the host. On Reef the controller defaults to the AP PHY
when suzyq is not connected, so it should have a connection to the AP
or through suzyq after boot.
The board property is only added to Reef. Behavior on Kevin and Gru is
unchanged.
BUG=chrome-os-partner:56864
BRANCH=none
TEST=update reef. Wait until Cr50 prints 'SETAD' then run 'rw
0x4000012c' and verify it is reset to 0.
Change-Id: If517202f25a694cd70550e3be047ea502e7c5383
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380354
If both e, and MOD are even, then no modular
inverse exists. This change adds handling
for this set of inputs. Adding this change
for completeness (there are no dcrypto library
call paths that generate both e and N as even).
BRANCH=none
BUG=chrome-os-partner:47524
TEST=bn_test passes
Change-Id: Ide64f980501175e9b6078efff92086d12bc1ae2d
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/376180
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
If the firmware was just updated clear the reset counter before
rebooting. This will ensure that the update can complete even if the TPM
isn't being used.
BUG=chrome-os-partner:56864
BRANCH=none
TEST=Set the reset counter to 7 by running 'rw 0x40000128 1' and
'rw 0x4000012c 7'. Then make sure cr50 can still be updated
Change-Id: Ic304fc7a20a4f2af7792f80e970d28e0eb10967e
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/380235
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
The high speed clock does not run when cr50 is in sleep. The low speed
timers do run in sleep and deep sleep. This change modifies the hwtimer
to use the low speed timers instead of the high speed ones.
With this change the system timer frequency is reduced and will only
tick once every 4 mircoseconds. Now the system will resume from sleep
whenever an event is scheduled, but still wont resume from deep sleep.
BUG=chromium:635620
BRANCH=none
TEST=manual
Disable sleep
add a function that prints something every second.
Verify the rollover works at ~4295s.
Change the system time using force_time.
Re-enable sleep and reduce the sleep delays in
board/cr50/board.c and chip/g/idle.ci so cr50 will go to
sleep more quickly. Verify the rollover and changing system
time works.
check that cr50 can go into deep sleep and that the print
statement wont wake it up.
Put the system into deep sleep. Use a wake pin to make it
resume. Verify it can be put back into deep sleep without the
wakepin interrupt constantly triggering.
Change-Id: I70bbc9312cd172661de53334d256949ebab6b5e9
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376800
stm32f446 uses a synopsys designware USB block
rather than the typical ST one. This change adds driver support
for the new block, including usb console support.
BUG=chromium:608039
TEST=usb console works
BRANCH=None
Change-Id: I0e143758ae0b5285f1c94ea2ec5aee159e22e00c
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/365448
Reviewed-by: Randall Spangler <rspangler@chromium.org>
During removing primary power of CPU, EC also needs to handle VW event
of SUS_WARN# in espi driver. Modify the MIWU trigger mode of it from
EDGE_RISING to EDGE_ANYING to solve it.
Modified sources:
1. espi.c: Handling VW event of SUS_WARN# in both edge.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make BOARD=wheatley; test power sequence on espi POC of wheatley.
Change-Id: I9e45115f3c274d08cdc694911d38599bc8da70c5
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/377780
Reviewed-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
The SHI lines connected from the EC to the AP and the AP might not be
turned on. We should have a pull down on these lines to avoid them
glitching when the AP is in S3 or S5.
BRANCH=None
BUG=chrome-os-partner:56683
TEST=Verify S3/S5 power is decreased, and SHI interface is still
functional in S0 and on sysjump.
Change-Id: I3a9b018e6e8a5eddb1f23e004f1af3da3e503709
Signed-off-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376360
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
UART0 RX only needs to be disabled on reef. This change uses a system
property instead of a #define to disable UART0 RX that way it can just
be done on Reef not Gru or the dev board.
BUG=chrome-os-partner:55510
BRANCH=none
TEST=manual
rw 0x4060000c shows a value of 1 for reef and 3 for gru
gru kevin and reef still boot.
Connect DIOA13 to DIOA1 on the dev board and verify the console
can be used.
Change-Id: I5ee3559c2b35f959c0d67f233d1dfa40743b4064
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/378336
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
There is leakage on SYS_RST_ODL from the internal pullup cr50 has on
DIOM0. This change removes the internal pullup.
Without the internal pull up SYS_RST_ODL is asserted when the EC is off.
This change modifies how sys_rst_asserted is handled so cr50 will ignore
the sys_rst interrupt whenever rbox asserts EC_RST to make sure cr50
doesn't reset itself every time it resets the EC. If the EC resets
itself and sys_rst_l is no longer pulled up, it is fine if cr50 resets.
BUG=chrome-os-partner:53544
CQ-DEPEND=CL:377504
BRANCH=none
TEST=manual
'rw 0x40550010 1' causes the EC to reset but not cr50
On the development board verify DIOM0 is not pulled up.
Test cr50 boots normally on reef, gru and kevin dvt1
Change-Id: Id8e8f6f7bb91741da34bdd6fec89eb841dd94f35
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376886
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
In order to disable the restricted console lock, the user has to
poke the power button repeatedly for some time. This CL
implements the logic to tell when this is happening, and whether
it is successful or not.
With this CL, unlocking only takes 10 seconds. This period will
be extended for production use. Right now we're just testing.
BUG=chrome-os-partner:55322
BUG=chrome-os-partner:55510
BRANCH=none
TEST=make buildall; test on cr50 hardware
At the console, run the "lock" command to see if it's already
disabled. If it is, run "lock enable" to lock it.
To unlock it, run "lock disable". A countdown will appear, after
which you will need to poke the Power button every 2 seconds for
10 seconds. If you do so, the console will be unlocked.
Change-Id: Ib5a94172080e627f3268d50d2587ec58bf8d9473
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/377621
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Even when CONFIG_RESTRICTED_CONSOLE_COMMANDS is enabled, there
are many commands that can't do anything dangerous. This marks
some of those commands as safe to use, even when restrictions are
enforced.
I'm only marking commands that are used by the Cr50, since that's
the only board that has restrictions.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall, test on Cr50 hardware
Change-Id: I6289d332830175b6adcb6b20cb4c21d01d27a25e
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/376188
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Version 4 of the update protocol provides the host with version
numbers of currently running RO and RW.
Another enhancement is that flash erase is postponed til the moment
the first chunk of data for the section arrives. This allows to quiry
running firmware versions in a non-destructive fashion.
BRANCH=none
BUG=chrome-os-partner:49954
TEST=ran usb_update on a Reef with an old cr50 image on it. Observed
it complete once with exit code of 2 (RO could not be updated),
ran it again, observed it succeed, and verified that both RO and
RW on the Reef got updated.
Change-Id: I27841c464cd0a414fa8959b686b59d8f07765387
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374760
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Trying to use usb_updater in the upstart script made its shortcomings
very obvious: it is difficult to tell if the cr50 needs to have both
RO and RW updated, and if so - if it is even capable of updating RW.
Also, it is not clear that the target should erase its backup sections
as soon as it receives the transfer originating PDU. It is not known
in advance if the host has a newer RW section, of if the host is even
going to transfer the RO section.
These issues are addressed by version 4 of the image transfer
protocol.
The target now reports versions of its currently active RO and RW
sections back to the host. The host compares versions running on the
target with the versions retrieved from the image prepared for the
update and decides which sections, if any, need to be transferred.
The host also takes into account protocol version currently running by
the target's RW: versions below 3 do not allow RO updates.
In the development environment USB transfer ends with the target
reset. This is not desirable when the update is happening on a
Chromebook running production code. Also, in the development
environment there could exist multiple versions of the image with the
same signer header version fields, with only difference in the
timestamp. We want to be able to update using these images in
development environment, but in production we want to rely to the
header version fields.
These two mode (dev versus production) are now controlled by the
-u/--upstart command line flag.
The updater now can return four different exit values:
- 0 means that the update was not required, the device is already
running the current code.
- 1 means update was completed, the target must be reset for the
update to kick in.
- 2 means that the RW transfer was completed, but the RO transfer
could bot be attempted, because the target is running an early
protocol version and is not capable of the RO updates.
This exit value is the indicator that the utility needs to be run
again after target restated, so that the new RW version can accept
an RO update.
- 3 means the update failed due to some internal error.
BRANCH=none
BUG=chrome-os-partner:49954
TEST=updates of targets running earlier protocol version still work
fine.
Change-Id: Ia56f63072eaf88dcdefebf621b7341535748c7d7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374759
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Cr50 needs to connect to the AP phy when not in ccd so cr50 can be
updated and used as a gnubby. This change uses the strapping options
to detect when it is on reef and modifies the ccd behavior to
initialize usb on the AP phy when ccd is disabled. On gru the cr50
behavior is unchanged.
In RDD this change removes the checks that the current_map is the
correct one based on the detected debug state. rdd_init calls
rdd_interrupt to set up the usb and ccd state correctly. Having that
check prevents that initial rdd_interrupt from calling rdd_detached.
Before rdd_detached just disabled usb and we knew during init it
would already be disabled. Now we want to make sure it is called if a
debug accessory is not attached to initialize usb on the AP PHY.
BUG=chrome-os-partner:56098
BRANCH=none
TEST=manual
verify ccd still works on gru
disconnect suzyq and reset reef.
run lsusb on the AP and verify it shows cr50 as a device.
connect suzyq and check that the AP no longer sees cr50.
disconnect suzyq and verify the AP sees it again
Change-Id: I3c1ccc54895835bce12302f3ea43fc2e751b4c97
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/372920
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Nothing has used this config option since Spring and Skate, back
in early 2014. There's nothing in ToT that uses it at all. I want
to add something similar for other purposes, and having two
similar-sounding options will just cause confusion.
NOTE: Although the comments in include/system.h said that the two
functions
system_get_console_force_enabled()
system_set_console_force_enabled()
were only useful when CONFIG_CONSOLE_RESTRICTED_INPUT is defined,
they were being used in chip/stm32/system.c. But since the
bkpdata registers are only accessible to the EC, there was no way
to initialize or modify the one relevant bit that those functions
cared about, so they almost certainly had no effect.
BUG=chrome-os-partner:55322
BRANCH=none
TEST=make buildall
Change-Id: Id41541193d4559f5c507bdd0268b049166af4497
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/374525
