Callers may not need computation of the public key.
Making this optional speeds this routine up.
Cr50 never passes in NULL for any argument, so is not affected.
BUG=none
TEST=build
BRANCH=none
Change-Id: Ia0077a35064f53b53f51867254aaa51eac6c55d8
Reviewed-on: https://chromium-review.googlesource.com/427058
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
We don't need to loop and waiting ADC's data valid flag
after the change was made.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=1. We build a EC binary for PD EVB (declared two ADC channels
for VBUS measurement of PD task and priority is highest)
2. Use console command "adc" continually to read ADC channels
and check if any error.
Change-Id: I1379e0b4c9ef721c29cb053d7d85e1a8ece9471b
Reviewed-on: https://chromium-review.googlesource.com/421307
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>
We have hard timing requirements once we begin to output our host
command response, and most of the time is spent copying our response to
OBUF. Optimize our copy loops to remove needless increments and to avoid
needless struct dereference.
BUG=chrome-os-partner:61304
BRANCH=gru
TEST=Manual on kevin, verify the following performance metrics:
Time spent in shi_fill_out_status(): Was 40us, now 28us
Time spent in shi_write_half_obuf(): Was 60us, now 31us
Time spent in shi_write_first_pkg_outbuf:
Was 90us, now 37us (bad case)
Was 26us, now 16us (better case / less data copied)
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I04075c92744eeefe8f2be009e6598718c45143c4
Reviewed-on: https://chromium-review.googlesource.com/425330
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
It is not proper to use SET_BIT macro to clear a "write 1 to clear" bit
in a register. It will also clear other bits if they are also set.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make buildall; boot up on gru, run ectool stress test for a while
without problem.
Change-Id: I0c5a850e85e41820515b1a8f15bb43d77397737f
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/425589
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
- Before the change was made, the "__ro_end" was at 00013520h.
We change to 00012760h.
- Rename "CONFIG_IT83XX_ILM_BLOCK_SIZE" to "IT83XX_ILM_BLOCK_SIZE"
this is because we don't support reconfiguration at board-level.
- Put some task functions into "__ram_code" section to
fill the gap and improving performance of code-fetch.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=console commands: flasherase, flashwrite, and flashread.
Change-Id: I2f2906a2a0b6971aadd00120c282801161447808
Reviewed-on: https://chromium-review.googlesource.com/424248
Commit-Ready: Dino Li <Dino.Li@ite.com.tw>
Tested-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Setting HICTRL.FW_OBF clears the HIKMST.OBF and STATUS.OBF flags but it
does not deassert IRQ1 when already asserted. To make sure IRQ1 will
also be deasserted need to emulate a host read.
Modified drivers:
1. lpc.c: emulate a host read to clear OBF and deasserted IRQ1.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make buildall; Run FAFT items related to Power on/off, reboot,
and keyboard on Wheatley.
Change-Id: Ibf0ff3b8a4eeece853916e4e19d67fcc7ae2e989
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/419909
Commit-Ready: Aaron Durbin <adurbin@chromium.org>
Tested-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
The code that referenced these structure definitions was removed
months ago. GCC 6.2 warns about the structures being definte but
not used.
BRANCH=none
BUG=none
TEST=Build tested only
Change-Id: I68de7cc351667b3fb51aa9004dfc86d936f4a9cc
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424432
Reviewed-by: Shawn N <shawnn@chromium.org>
The common/system.c:system_usable_ram_end() function is used to
determine how much room there is available for shared memory. This
assumes that the jdata container is located at the top of SRAM right
below the panic data buffer.
This correct for embedded mode, but when building for host, panic
structure is allocated in a different memory block, not necessarily
adjacent to the __shared_mem_buf array. This leads to incorrect
calculations of the available shared memory amount.
Let's make sure the two memory blocks are adjacent, this way the
available memory calculations are accurate.
BRANCH=none
BUG=none
TEST=verified that
make runtests -j
succeeds, including the new test for malloc/free from shared memory
(coming up in the next patch).
Change-Id: I1fdba0512ac5a85b113a8284216c8b00f1564a94
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/424176
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The function usb_power_map_error() is only called from a single
location, with a fixed value passed in, and the return value, which
is the only reason for the function, is ignored.
The whole thing is useless, so remove the function and call. Since the
sizes of all platforms are unchanged before and after removing this, I
suspect it was getting optimized out anyway.
Fixes coverity warning 157563: Useless call
BUG=None
BRANCH=None
TEST=build tested only.
Change-Id: Ie6572d2f5579819f06a53a567e1a93aabca217db
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/418070
Reviewed-by: Shawn N <shawnn@chromium.org>
With expanding USB interface to processing vendor commands and to
query current version running on the chip, there are now occurrences
of fw_upgrade_complete() invoked at the device startup without actual
data transfer.
This causes clearing rollback counter before it is actually examined.
Let's not invoke fw_upgrade_complete() unless there was actual data
transferred for flash programming.
BRANCH=none
BUG=none
TEST=verified on chromebook reboots that the counter value is not
changed until the rollback condition is checked.
Change-Id: I50bf450882b001ba1c2f38657d27f87f8596b3e2
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/422454
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Perform PKCS1-padding-only signing for RSASSA if hashing algorithm is
TPM_ALG_NULL.
This feature is guarded by SUPPORT_PADDING_ONLY_RSASSA macro in
tpm2/Implementation.h.
BUG=chrome-os-partner:60967
BRANCH=none
TEST=On a unowned machine with TPM2: corp enroll, login, install
a network certificate (gECC or GMC), then:
a) retrieve the public key from the installed certificate
LIBCHAPS=`ls /usr/lib**/libchaps.so`
CERTID=`pkcs11-tool --module=$LIBCHAPS --slot=1 --type=cert \
-O | grep "ID:" | awk '{print $2}'`
pkcs11-tool --module=$LIBCHAPS --slot=1 --id=$CERTID \
--type=cert -r > /tmp/cert
openssl x509 -inform der -pubkey -noout -in /tmp/cert > /tmp/pub.key
b) sign a sample text using the private key for the certificate and
MD5-RSA-PKCS mechanism, not supported by TPM2_Sign command:
echo "ABCDEF" > /tmp/1.txt
pkcs11-tool --module=$LIBCHAPS --slot=1 --id=$CERTID --sign \
-i /tmp/1.txt -o /tmp/1.sig -m MD5-RSA-PKCS
c) verify signature:
openssl dgst -md5 -verify /tmp/pub.key \
-signature /tmp/1.sig /tmp/1.txt
Step (b) should succeed and step (c) should return "Verified OK".
Change-Id: I0d7a11c48cdb04e37748f7255b98e9e023481a96
Signed-off-by: Andrey Pronin <apronin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420854
Reviewed-by: Darren Krahn <dkrahn@chromium.org>
Provide the calling stubs for p256 sign, verify, point mul, etc.
This also drops third_party/cryptoc/p256_ec and p256_ecdsa from the
image. And fewer routines from cryptoc/p256.c remain as well.
BRANCH=none
BUG=none
TEST=tcg_tests pass, test/tpm_test/tpmtest.py pass
Change-Id: Ib6c35f5d34a2c8434e78b44cbef8b69802734c50
Signed-off-by: Marius Schilder <mschilder@google.com>
Reviewed-on: https://chromium-review.googlesource.com/422942
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Commit-Queue: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Trybot-Ready: Marius Schilder <mschilder@chromium.org>
After every reboot, we were resetting the write protect and console
lock states back to default. With this change the wp and lock states
will be preserved through deep sleep. They will still be reset on any
other type of reboot (like Power On reset or panic).
The states are also cleared if the system detects a rollback even when
booting from the deep sleep.
With this patch it is going to be impossible to remove hardware write
protection guarding writes into AP and EC firmware flash, unless the
cr50 console is unlocked.
Locking the console would reinstate hardware write protection
automatically even if it was disabled when the console was unlocked.
Two long life scratch register 1 bits are used to keep the console and
write protect states over resets. To make code cleaner bitmap
assignments of the long life scratch register is put in its own
include file.
BUG=chrome-os-partner:58961
BRANCH=none
TEST=manual
On prod/dev images verify that the default wp and console lock
states are still correct.
change the lock and write protect states from the default and
verify they are preserved through deep sleep.
reboot cr50 and make sure that they are reset.
unlock the console and enable flash writes, then set fallback
counter on cr50 to the value of 6 (rw 0x40000128 1; rw
0x4000012c 6) and put the AP into deep sleep by hitting
Alt-H-VolUp.
In five minutes press the power button on the device to bring
it back from s5. Observe cr50 fall back to an older image and
console lock and wp disabled.
Change-Id: Ie7e62cb0b2eda49b04a592ee1d0903e83246b045
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/420812
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
There are plans to extend use of the LONG_LIFE_SCRATCH1 register for
other purposes than keeping board properties. Just as the board
properties, the new use is also very board specific. This patch moves
the board properties code from chip/g to board/cr50, where it belongs.
Instead of reading board properties bitmap and checking if various
bits are set, api functions are now provided to allow determining
various properties settings without actually looking at the properties
bitmap.
CQ-DEPEND=CL:*313057
BRANCH=none
BUG=chrome-os-partner:58961
TEST=verified that both Gru and Reef boot with the new image,
additionally, on Reef confirmed that it is possible to
communicate with the H1 over USB, and that plt_reset signal is
handled properly.
Change-Id: Id0dd2dc16389f773a149fb01eee1ce7bb99c4547
Reviewed-on: https://chromium-review.googlesource.com/422081
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Since ec doesn't support old-style host command, this CL removes
unsupported parts in npcx's lpc driver and lets the hand-shaking
mechanism between host and ec as easy as possible. It makes sure only
following conditions that ec can clear processing bit of host command.
1. Received LRESET signal.
2. In lpc_init() initialization function caused by sysjump.
3. If command is valid, it will be cleared in lpc_send_response_packet()
called by host command task.
4. If command is invalid, it will be cleared in lpc_send_response()
after the response package is ready.
BRANCH=none
BUG=chrome-os-partner:34346
TEST=make BOARD=wheatley; do stress test on wheatley.
Change-Id: I53d17fd9e09b7fb080e4bf71437392bf43db6258
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/422707
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The idle task on g devices seems to be very close to its stack
capacity. Adding debug code, print statements, etc., causes occasional
stack overflow panics.
Let's increase the stack size to avoid these problems.
BRANCH=none
BUG=none
TEST=the stack overflow panics do not happen anymore when debug
processing on the idle task context is added.
Change-Id: Id259719c1b644e2743f3bb3dbf0d99d667662901
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/422078
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The EC on Eve has VCC1_RST connected to 3.3DSW which drops when
resetting for recovery.
Since I need this to work on current boards treat Eve the same as
Wheatley and use the workaround that always reports reset-pin
instead of power-on status.
BUG=chrome-os-partner:61028
BRANCH=none
TEST=successfully enter recovery mode on eve with the keyboard
Change-Id: Ica583d9a95d78689ee1b21ccfa882fced2a414d9
Signed-off-by: Duncan Laurie <dlaurie@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/421128
Reviewed-by: Shawn N <shawnn@chromium.org>
word_in_value shouldn't be able to be used without being initialized,
so just initialize it to make GCC 5.3 happy. It's configured separately
in the (last_write_pointer & 3) and (!(last_write_pointer & 3)) paths,
so it can't actually slip through uninitialized.
There is probably a way to rwrite this that won't confuse GCC as much,
but I haven't found it yet. The solutions I did try generally ended
up increasing the binary size, so I'm falling back to just initializing
the variable.
chip/g/i2cs.c: In function '_i2cs_write_complete_int':
chip/g/i2cs.c:178:19: error: 'word_in_value' may be used uninitialized
in this function [-Werror=maybe-uninitialized]
This does not change the size of any ec.*.flat file.
BRANCH=none
BUG=none
TEST=build succeeds under GCC 4.9.2, 5.3 and 6.2
Change-Id: Iaf8641b3d252c494ad13fbeb8ad8ece3cdfe6e76
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403504
Reviewed-by: Shawn N <shawnn@chromium.org>
GCC 5.3 and 6.2 complain about the the i2c_irqs array being defined as
static because it's used by a non-static inline function.
Since i2c_handle_sda_irq is only used in the i2c.c file, it makes sense
to make it static.
Additionally, remove the inline keyword for i2c_handle_sda_irq since
it's a huge function, if it were used more than once, we wouldn't want
it to be inlined.
chip/npcx/i2c.c:462:22: error: 'i2c_irqs' is static but used in inline
function 'i2c_handle_sda_irq' which is not static [-Werror]
task_disable_irq(i2c_irqs[controller]);
npcx_evb/RW/ec.RW and npcx_evb_arm/RW/ec.RW.flat each shrank by 20 bytes.
npcx_evb/RO/ec.RO and npcx_evb_arm/RO/ec.RO.flat each shrank by 64 bytes
BUG=none
BRANCH=none
TEST=make buildall passes under GCC 4.9.2, 5.3 and 6.2
Change-Id: I79691bb57083fd925f9c4be06de706f676a1d043
Signed-off-by: Martin Roth <martinroth@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/403502
Reviewed-by: Shawn N <shawnn@chromium.org>
Avoid building and including crypto test code in
prod builds: only define CRYPTO_TEST_SETUP when
CR50_DEV is defined.
At HEAD, this change drops the size of prod ec.RW.bin
from 200704 to 188416.
BRANCH=none
BUG=chrome-os-partner:54104
TEST=build succeeds
Change-Id: I1e6018ec917dbe71cb445206ce232b8ea7a46cb1
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/418489
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
There's a small period between ec cleared EC_LPC_CMDR_BUSY status bit
for sysjump and executed notify hook function to let lpc driver disable
lpc's interrupts. If ec received a new host command in this period,
EC_LPC_CMDR_BUSY status bit has chance not to be cleared since ec
already jumped to the the other region. In case ec and host enter
dead-lock loop, we need to clear it on lpc_init().
Since HIPMnST only can be reset by core domain reset, it's better to
clear EC_LPC_CMDR_BUSY status bit when LRESET asserted. It makes host
can reset host command mechanism if something wrong.
BRANCH=none
BUG=chrome-os-partner:60928
TEST=make BOARD=reef; pass the tests mentioned in issue #60928
Change-Id: I08ac0515cb2cfee277a7c7704d131574d928fb6b
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/419908
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
This change adds the plumbing for SHA-384 & 512.
The actual hash implementation is software only,
and a part of the third_party/cryptoc library.
BRANCH=none
BUG=none
CQ-DEPEND=CL:418263
TEST=TCG tests pass
Change-Id: Iba7e6d420fd7fa0bce4ad9061e00f9275ecf4d72
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/417888
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
It turns out that even when the UART status register returns TX_IDLE
bit set, the transmitter is still active - probably working out the
stop sequence.
So, resetting immediately after TX_EMPTY is asserted causes the last
character to be corrupted on the receiving side.
This patch adds a wait for the duration of transmitting 10 bits at
115200 baud, which should be plenty. Wait loop in capped in case timer
is not running for any reason.
BRANCH=none
BUG=chrome-os-partner:60321
TEST=added code to print out a string and then call cflush() and reset
immediately. The last character is not lost any more, the exact
string is printed.
Change-Id: If386c515d9d9cc63d161fba73e6ed4e70e465136
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/418487
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Deep sleep needs to be considered a normal behavior and should not add
to the rollback count. This change subtracts one from the reset count
when the system sees that it just resumed from deep sleep.
Ideally the rollback counter would be able to verify the TPM
functionality and detect rolling reboots. With this change the rollback
counter will only be able to detect rolling reboots, but it fixes the
false positives for rolling reboots we were seeing before.
BUG=chrome-os-partner:60449
BRANCH=none
TEST=manual
check the reset counter
turn off the AP
wait for cr50 to enter deep sleep
plug in suzyq
check it resumes from deep sleep and that the reset counter
still has the same value
Change-Id: Ie8490c29636403b409b2a3f0912a5b312d23bc24
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/418321
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This change adds a usb clock enable before trying to write to the usb
registers when preparing for deep sleep.
It is possible that usb has not been initialized, so we need to make
sure that the clock is enabled.
BUG=chrome-os-partner:60555
BRANCH=none
TEST=manual, on both dev and prod fused H1
run hibernate on the EC
wait until cr50 enters deep sleep
plug/unplug the charger
verify the AP can boot to the kernel
Change-Id: I26359f4224cd25dc57c32d1508e26b133c43d317
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/417771
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
* Include trng.h from trng.c before any other header to verify that the
header is self-contained.
* Add inclusion of stdint.h to trng.h to provide definition for uint32_t.
BUG=none
BRANCH=none
TEST=make -j buildall
Change-Id: I78fb6d915c357236ca0fed2a57f093f0eec07fe9
Reviewed-on: https://chromium-review.googlesource.com/417424
Commit-Ready: Carl Hamilton <carlh@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Set the default idle action based on whether bus obfuscation is enabled.
BUG=none
BRANCH=none
TEST=verify the idle default is sleep on b1 boards and wfi on b2.
Verify that both types of chips go to sleep and resume
successfully.
Change-Id: Ib5a11c4060aa411ff36c06c7fcadf0bf4c223bf1
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/410167
The original thought of setting LRESET_PLTRST_MODE to 1 is to remove the
need to reinitialize host module registers whenever LRESET# occurs in
order to save time when boot-up.
However, some of these registers will be reset by core domain reset. It
means every time LRESET is de-asserted, we need to initialize the host
setting again. Therefore, setting LRESET_PLTRST_MODE to 1 is unnecessary
and sometimes dangerous. If BIOS believes LRESET will reset ec's host
state machine to default but ec not, it will cause unexpected behavior.
Modified drivers:
1. lpc.c: allow LRESET/PLTRST generate host domain reset
BUG=chrome-os-partner:60211
BRANCH:none
TEST=make buildall. run "dut-control pwr_button:press; sleep 11; dut-control
pwr_button:release; sleep 7; dut-control pwr_button:press; sleep 1;
dut-control pwr_button:release". Verify keyboard works normally.
Change-Id: I94d428cde69f828468547c44844983f25686ea04
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/417745
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
__hw_clock_event_set() is not reentrant and may be called from both our
event timer ISR and our hwtimer ISR when hwtimer is close to wrapping.
Modify the interrupt priority of our hwtimer int to match our event
timer int so that one cannot preempt the other. Originally the priority
was changed to allow the hwtimer ISR to run first in case both are
pending, but this condition can be handled cleanly and isn't a big
concern.
BUG=chrome-os-partner:60470
BRANCH=gru
TEST=Pass 500 S/R cycles on kevin with hwtimer wrap rate sped up 300x
(roughly equivalent to 150,000 real S/R cycles).
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ied466f14661f04c8662b5db709c0e3770a5bb200
Reviewed-on: https://chromium-review.googlesource.com/417060
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(cherry picked from commit ac28ec53b63a02c4d25e8a222d13595bc857fef0)
Reviewed-on: https://chromium-review.googlesource.com/417112
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
The manifest used for signing in dev mode was originally used for
kevin evt 1, but now it is a common dev mode manifest. Rename the fie
appropriately and modify the makefile using it.
BRANCH=none
BUG=chrome-os-partner:57956
TEST=verified that it is still possible to build cr50 with CR50_DEV=1
Change-Id: If744406a83a7045cd34c76c941fdef209bef51ac
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/417220
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
gru has circuitrythat selects the charge LED color based on the
frequency of the PWM.
By adjusting the PWM frequency instead of just the duty, we gain more
control over the brightness of the charge LED.
BUG=chrome-os-partner:54155
BRANCH=gru
TEST=activate each LED in turn and confirm color and brightness
Change-Id: Ie653125a528595c1ec68aea4d02cb70595a1b151
Signed-off-by: David Schneider <dnschneid@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/415517
Reviewed-by: Shawn N <shawnn@chromium.org>
When a WAIT is received in response to a request, wait SinkRequestTime
before resending the request.
BUG=chrome-os-partner:34984
TEST=make -j buildall
BRANCH=none
Change-Id: I5c8429c4a7b9cf06609996f924b8d9d535ab6b5f
Reviewed-on: https://chromium-review.googlesource.com/414533
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Common code is more flexible and supports more parts, so delete the
npcx-only register translation code.
BUG=chrome-os-partner:60029
BRANCH=gru
TEST=Manual on gru, run 'flashrom -p ec --wp-enable' and check that 0x28
gets written to SR1, which matches our desired 'protect botton 128KB',
according to the datasheet. Also run 'flashrom -p ec --erase' then read
back EC SPI contents, verify ROM is erased except for first 128KB
region.
Change-Id: I526401997ff7ec77f2a6047a4a9af74a671ed69a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413228
Reviewed-by: David Hendricks <dhendrix@chromium.org>
(cherry picked from commit 43634d36d273887b1f2349c333a7b4b229a83365)
Reviewed-on: https://chromium-review.googlesource.com/415498
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
If UMA is locked, read and write access to SR* regs will fail, and we'll
be unable to determine or change our write protect state. Save our SR
regs before enabling UMA lock, and bring down UMA lock for a brief
period when writing SR regs.
BUG=chrome-os-partner:60029
BRANCH=gru
TEST=Manual on kevin with SW sync enabled.
flashrom -p ec --wp-enable -> verify success, check flags:
Flags: wp_gpio_asserted ro_at_boot ro_now
Reboot host, check flags:
Flags: wp_gpio_asserted ro_at_boot ro_now all_now
Verify flashrom -p ec --wp-status shows protected, and flashrom -p ec
--wp-disable fails.
Also verify same state after EC reset.
Boot into recovery mode, check flags:
Flags: wp_gpio_asserted ro_at_boot ro_now
Remove WP screw, reboot EC, check flags:
Flags: ro_at_boot ro_now
Verify flashrom WP status shows protected, and flashrom WP disable
succeeds and clears all flags.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I17e32f7305600183e7fcb87f69a3feb88978f94e
Reviewed-on: https://chromium-review.googlesource.com/412977
(cherry picked from commit 6cfc0d0dd030b8b0334f99e99950a52fcf8267af)
Reviewed-on: https://chromium-review.googlesource.com/415497
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
This change adds support for signing SHA-384 & 512 hashes
when using PKCS#1 padding (CR50 does not support
SHA-384 & 512 at the moment, the actual hashing is to be
done on the host).
BRANCH=none
BUG=chrome-os-partner:59754
TEST=TCG tests pass
Change-Id: I78e774639a7968cbb50e58cdd0bf479e64123630
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/415218
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Andrey Pronin <apronin@chromium.org>
Enabling and disabling sleep in the rdd interrupt is redundant because
USB already takes care of that. When USB is initialized it will disable
sleep. If it is released or suspended then it will re-enable sleep. This
change removes the sleep enable and disable from the rdd interrupt. With
this change now sleep can be enabled while suzyq is still plugged in
using the command 'ccd disable'.
BUG=none
BRANCH=none
TEST=manual
The consoles still work
Updating the EC, AP and Cr50 still works
After running 'reboot ap-off' in the EC console and 'ccd
disable' in the Cr50 console Cr50 will go to sleep.
Change-Id: Ie8e6201e9fd611c514e93bc70d298d3b0d228611
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413606
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
This patch introduces version 6 of the cr50 USB update protocol. This
version allows to multiplex TPM vendor and extension commands over the
same USB endpoint which is used for firmware updates.
When channeling TPM vendor commands the USB update frame looks as follows:
4 bytes 4 bytes 4 bytes 2 bytes variable size
+-----------+--------------+---------------+-----------+------~~~-------+
+ total size| block digest | EXT_CMD | Vend. sub.| data |
+-----------+--------------+---------------+-----------+------~~~-------+
Where 'Vend. sub' is the vendor subcommand, and data field is
subcommand dependent. The target tells between update PDUs and
encapsulated vendor subcommands by looking at the EXT_CMD value - it
is set to 0xbaccd00a and as such is guaranteed not to be a valid
update PDU destination address.
In the previous protocol versions target reset was requested by the
host sending a 4 byte PDU after the target receives the UPGRADE_DONE
message and moves the state machine to the 'awaiting_reset' state.
With the ability to transfer vendor commands, there is no need for the
target to have a special state for reset. The host can send the posted
or immediate reboot request using the appropriate vendor command.
As a result the 'awaiting_reset' state has been removed, the target
accepts vendor commands only when state machine is in the rx_idle
state.
Vendor command response size is not fixed, it is subcommand dependent.
In the current implementation the total size of the vendor command PDU
can not exceed 64 bytes, as there is no reassembly on the target side.
For backwards compatibility in case the target is running protocol
version earlier than 6, the 4 byte PDU is still sent to the target
after UPGRADE_DONE is sent.
BRANCH=none
BUG=chrome-os-partner:60013
TEST=tested updates on Reef and Gru, observed that it is possible to
update earlier versions of firmware, and that it is possible to
request immediate and posted reset (depending on the presence of
the -u flag in the usb_updater invocation).
Change-Id: I6ea9e9f742c96b8ab0670e9cec87a83cd47bb20e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414948
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
When usb update errors happen it helps a lot to be able to see the
actual error code returned by the target and where the error was
generated.
This patch adds a few printouts to help with debugging.
BRANCH=none
BUG=none
TEST=observed proper error messages generated while debugging
introduction of extension/vendor commands transfer over USB.
Change-Id: I06c77e7467f7f9547704c88c4b673866fb2e6032
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414947
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Some upcoming changes will introduce transfer of vendor and extension
commands over the usb updater endpoint.
This patch exposes a function which allows to verify integrity of
received USB PDUs.
BRANCH=none
BUG=chrome-os-partner:60013
TEST=no functional changes, usb_updater still works fine.
Change-Id: I8d9e6746ef0dfbb17bba618410514ca047a59a45
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/414441
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This describes a 5-finger touchpad. The physical/logical dimensions
of the trackpad are hardcoded for the time being.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make BOARD=hammer -j && util/flash_ec --board=hammer
Change-Id: I04a0833a28c013395974104ebdd6fcb29e5d6680
Reviewed-on: https://chromium-review.googlesource.com/407742
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For example, when a HID descriptor is longer than 64 bytes, we need
to split it in multiple packets.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make buildall -j
TEST=make BOARD=hammer -j && util/flash_ec --board=hammer
Change-Id: I25a05eabaf9413e332fe3cd70695a0d53639713d
Reviewed-on: https://chromium-review.googlesource.com/409316
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This first cleans up the code:
- Define report as a structure.
- Fix USB interval from 40 ms to 32 ms (Linux kernel complains
otherwise).
Then, this removes the old set_keyboard_report interface, and
replaces it by the interface used by the keyboard scanner
(i.e. keyboard_state_changed and keyboard_clear_buffer).
This also means we need a keycode table to translate from
row/column to USB HID keycode.
BRANCH=none
BUG=chrome-os-partner:59083
TEST=make buildall -j
TEST=make BOARD=hammer -j && util/flash_ec --board=hammer
With evtest and "hid 0-7" in console, check that key are
reported correctly.
Change-Id: I5d526db1568c29c7f28fc5e962e213e44303cc16
Reviewed-on: https://chromium-review.googlesource.com/411571
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When cr50 rollback happens, the newer header's magic field is set to
zero to prevent it from ever running again.
Take this into consideration when displaying versions of the inactive
RW image.
BRANCH=none
BUG=none
TEST=loaded two versions of the new code on a cr50 and then modified
the fallback counter to force it to boot the older version and
reboot a Reef. Once Reef fully boots to chrome os examine CR50
version report:
Before:
> vers
...
RW_A: 0.0.9/DEV/cr50_v1.1.5654-2228b76+
RW_B: * 0.0.11/DEV/cr50_v1.1.5654-2228b76+
...
After:
> vers
...
RW_A: * 0.0.9/DEV/cr50_v1.1.5654-2228b76+
RW_B: Error
Change-Id: I2a9ee13117a0bc91710226cd733c5c484c6d0595
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/413089
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
