A common failure condition on the i2c bus is when the master
unexpectedly stops clocking the bus while the slave is driving the SDA
line low. In this case the master is not able to issue Stop or Start
sequences, which makes the bus unusable.
Good slave controllers are able to detect this condition and recover
from it by removing the pull down from the SDA line. This patch adds
this capability to the g chip i2c slave controller.
A new timer function is created which samples the SDA line twice a
second. If it detects that SDA is low in two consecutive invocations
and the number of i2cs read interrupts has not advanced, it decides
that the "hosed slave" condition is happening and reinitializes the
i2c driver, which removes the hold from the SDA line.
Even though the state of the SDA line is supposed to be accessible
through the I2CS_READVAL register, it in fact is not, reads always
return zero in the SDA bit. To work around this a GPIO (port 0, bit
14) is being allocated to allow to monitor the state of the line, it
is multiplexed to the same pin the SDA line uses.
When the AP is in low power modes the SDA line is held low, this state
should not trigger i2c reinitializations.
CQ-DEPEND=CL:616300
BRANCH=none
BUG=b:35648537
TEST=connected H1 on the test board to an I2c master capable of
stopping clocking mid byte. Observed that the existing code would
just sit in the "hosed" state indefinitely. The code with the fix
recovers from the condition (drives the SDA line high) 500ms to
1s after the failure condition is created.
Change-Id: Iafc7433bbae9e49975a72ef032a923274f8aab3b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/614391
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Add a delay to allow the clocks and usb signals to settle.
BUG=b:63767046,b:63867566
BRANCH=cr50
TEST=put the eve ec into hibernate, wait until cr50 enters deep sleep,
use the uart to wake it up, and verify that it eventually reenters deep
sleep
Change-Id: I26463ce3e00996368a791a245b0f9de01737478c
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/598448
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
In npcx7, we introduce an enhanced version of Serial Host Interface
(SHI) module. This CL adds the support for it.
It includes:
1. Increase the size of IBF/OBF from 64 bytes to 128 bytes.
2. Add IBULVL/IBFLVL2 in SHICFG4/SHICFG5 which can configure at which
level the IBF pointer reaches to trigger an interrupt to core.
The current setting of these two register fields are:
IBFLVL - 64 (half full)
IBFLVL2 - 8 (the size of host command protocol V3 header)
3. Dedicated CS high/low interrupts.
In old SHI module, the way to generate CS high interrupt event is via
EOR bit. However, it has a defect that EOR won't be set to 1 when CS
is de-asserted if there is no SHI CLK generated. It makes the
handling of glitch condition more complicated.
In the new SHI module, we introduce the CS high/low interrupts
(by enabling the CSnFEN/CSnREEN) to make it easier to handle the
glitch.
The new SHI module is enabled during SHI initialization when the chip
family is npcx7.
BRANCH=none
BUG=none
TEST=No build errors for "make buildall". Test host command
communication is ok between npcx7 EVB and a host emulator.
Make sure the glitch condition can be detected and handled.
Also test the driver on gru, make sure it won't break the operation of
old SHI module.
Change-Id: If297fd32a0ec2c9e340c60c8f1942868fa978fbc
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/607812
Commit-Ready: CH Lin <chlin56@nuvoton.com>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
We previously disabled the USB PHY to the AP. But the BOARD_AP_USB
property lingered on. Remove the property.
Also clean up the idle task deciding when to do utmi wakes. With the
AP USB connection disabled, that's only necessary when the debug cable
is attached, so we can check that explicitly.
BUG=none
BRANCH=cr50
TEST=make buildall; boot CR50_DEV=1 image
Change-Id: If81a7bcfe845d9d70dcc7e16239244a4f5f2427b
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/616301
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This reverts commit ddbfe690e2.
Reason for revert: Causes move cursor movements to be choppy, and device
to be very unresponsive during flashrom EC operations.
Original change's description:
> npcx: workaround the bug that SHM data read via eSPI may be corrupted
>
> In eSPI systems, when the Host performs a data read from the Shared
> Memory space, the returned data may be corrupted. This is a result of
> the Core-to-Host access enable bit being toggled (by toggling CSAE bit
> in SIBCTRL register) during an eSPI transaction.
>
> The workaround in this CL is to set CSAE bit to 1 during initialization
> and remove the toggling of CSAE bit from other EC firmware code.
> (i.e., let the CSAE bit be always 1.)
>
> BRANCH=none
> BUG=none
> TEST=No build errors for make buildall. Flash poppy ec image, make sure
> it can boot to OS. Run "ectool version" over 100000 times, no error
> occurs.
>
> Change-Id: I7aac6805ece64e8f77964d4acb026d9871cd2ebe
> Signed-off-by: CHLin <CHLIN56@nuvoton.com>
> Reviewed-on: https://chromium-review.googlesource.com/590396
> Commit-Ready: Shawn N <shawnn@chromium.org>
> Tested-by: CH Lin <chlin56@nuvoton.com>
> Reviewed-by: Shawn N <shawnn@chromium.org>
BUG=b:64730183
TEST=flashrom -p ec -r ecr.bin, device still responsive.
Change-Id: Idaeef2707df990b2441a77a15807698d41018449
Reviewed-on: https://chromium-review.googlesource.com/618366
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Similarly to what we have done with keyboard events, we put touch
events in a FIFO. The AP will need to interpret the timestamp
in the events to be able to process the events correctly tough.
Resume should typically take about 50ms, so a 8-event long FIFO
should be good enough. Also, we bypass the FIFO altogether in most
cases, when the USB interface is not suspended.
BRANCH=none
BUG=b:35775048
TEST=Connect hammer, force autosuspend using:
DEVICE=$(dirname $(grep 5022 /sys/bus/usb/devices/*/idProduct))
echo 500 > $DEVICE/power/autosuspend_delay_ms
echo auto > $DEVICE/power/control
Look at evtest output.
Wait a second, make a swipe, see that events are received in
a very short amount of time after resume (every EP interval/2ms),
but the event timestamps show that some of them are older.
Change-Id: If6ab56396f7d564b19e6c3c528847196ffa4d849
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/612221
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
We use the unofficial, Windows 8, Relative Scan time HID usage
(Digitizer page, 0x56) to add timestamps to our HID touchpad
events.
The timestamps is a rolling, unsigned, 16-bit integer, with a
resolution of 100us (so it wraps around every 6.5s).
The host will be able to synchronize to that timestamp, resetting
an offset every time the touchpad is quiet a certain amount of
time (e.g. 1 second).
BRANCH=none
BUG=b:63685117
TEST=Flash hammer, timestamps are reported in HID descriptor.
Change-Id: Ie5d56a9df14e464d2cdcd559f550d6e3cc81961f
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/603041
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Put key events in a FIFO. This is especially useful when USB is
suspended, so that we can replay the events on resume. This makes
sure that no key strokes are lost on resume from USB autosuspend.
We coallesce events happening within some interval (18 ms), greater
than EP interval (16 ms) to ensure we cannot have a backlog of keys.
The interval must also be short enough to ensure that the intended
order of key presses is passed to AP, and that we do not coallesce
press and release events (which would result in lost keys).
We also discard key events in the FIFO buffer that are older than
1 second. Note that we do not fully drop them, we still update
the report, but we do not send the events individually anymore
(so an old key press and release will be dropped altogether, but
a single press/release will still be reported correctly).
BRANCH=none
BUG=b:35775048
TEST=Connect hammer, force autosuspend using:
DEVICE=$(dirname $(grep 5022 /sys/bus/usb/devices/*/idProduct))
echo 500 > $DEVICE/power/autosuspend_delay_ms
echo auto > $DEVICE/power/control
Wait a second, type something quickly, verify that no keys are lost.
Change-Id: I64d33c15a39ae33af42039fba62cf4ed3abef462
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/471188
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
As suggested in CL:411741, makes the follow-up CL that buffers
key strokes much simpler.
We can revisit later if we can still sneak it that change, but,
all in all, we can guarantee the same key latency by halving the
USB endpoint interval.
BRANCH=none
BUG=b:35775048
TEST=Connect hammer, keyboard works.
Change-Id: I6624fde9bd5561ddceb7ce195470d7af7cca7140
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/471187
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Some USB interface handlers need to know when USB has been
successfully resumed after a wake event. For example, this is
useful so that HID keyboard can send the events at the right time.
BRANCH=none
BUG=b:35775048
TEST=Using USB HID keyboard patches to queue keys in a FIFO:
After USB autosuspends, press a single key and hold it. Without
this patch the endpoint data only gets reloaded on the _next_
event.
TEST=On hammer, I2C passthrough still works.
Change-Id: I9b52b9de16767c8a66c702a5ae70369334a3d590
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/569547
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
To enable console with DMA, we need to specifically
remap DMA channels for USART1.
ch2/3 and ch6/7 are already used by SPI1/2 modules.
So we have to remap USART1_TX to ch4 and USART1_RX to ch5.
BUG=b:64575809
BRANCH=none
TEST=confirm ec console works on scarlet rev1
Change-Id: Ie2bb141c72252aee98e4cd4a284a01b4d57605f4
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/611147
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Indentation is growing out of control, let's move to a separate
function so that we can return early.
BRANCH=none
BUG=b:35775048
TEST=Flash hammer, usb_wake works.
Change-Id: I9abf99ff55b3977dfc307fc99aac6f1ab7dd1f6a
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/612922
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The device_state module is used for debouncing GPIO inputs to
determine device sstate. It was overkill for managing the CCD cable
(RDD) attach/detach state, and split that handling between 3 files
(board.c, rdd.c, device_state.c). Move all of that logic into rdd.c
so it's easier to maintain.
BUG=none
BRANCH=cr50
TEST=manual
plug in CCD cable (or ground DIOM1)
ccd command reports cable connected and AP UART TX+RX
unplug CCD cable (or un-ground DIOM1)
ccd command reports cable disconnected and AP UART disabled
Change-Id: Id8fcd3a51605ae7a4843668ea18dd0ef84aceb2c
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/604499
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This patch defines CONFIG_DATA_RAM_SIZE, which indicates the size
of the RAM used for data, thus can be marked as non-executable.
If it's not defined, it defaults to CONFIG_RAM_SIZE. Thus, other chips
are not affected.
BUG=b:36037354
BRANCH=none
TEST=buildall. Run 'sysjump disable' on Reef and verify mpu_protect_ram
is successful.
Change-Id: I54d74fd1dabff7e1013fff2542fd02c3646803d1
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/596518
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When resuming from S3, it may take a while for the bus to become
alive again, so let's increase the timeout. 3 seconds is probably
a bit too long, but should work for our purpose: we just do not
want to be stuck in that state forever.
BRANCH=none
BUG=b:35587173
TEST=Use powerd_dbus_suspend to put poppy in S3. Press key, see
that hosts sometimes takes ~90ms, but sometimes up to 1.5s
to resume.
Change-Id: Ic800481b2b500fb68a8d1de16b11cbe77a4013d4
Reviewed-on: https://chromium-review.googlesource.com/569523
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In the previous version of the code, we were counting ESOF (every
ms) to figure out when to clear the resume bit, and then using ESOF
counts again to wait for the USB interface to resume.
This missed the fact that ESOF (expected SOF) interrupts are not
triggered when SOF are actually received.
Somehow, this worked fine in most cases, except that sometimes the
last ESOF would race with the RXDP/RXDM going to state 2, and we
would not know that the resume completed successfully.
Let's also count SOF interrupts, and also take a received SOF as an
indicator of a successful resume.
While we're at it, trim down USB debugging messages, and add a line
when resume is successful.
BRANCH=none
BUG=b:35587173
TEST=Connect hammer, force autosuspend using:
DEVICE=$(dirname $(grep 5022 /sys/bus/usb/devices/*/idProduct))
echo 500 > $DEVICE/power/autosuspend_delay_ms
echo auto > $DEVICE/power/control
Add debugging in hammer code, make sure that usb_wake_done goes
back to 1 after resume succeeds.
Change-Id: I206c9c6b3066a3a337b6bd2370c9d0c6a9e2396c
Reviewed-on: https://chromium-review.googlesource.com/569522
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Implement the RFC 6979 to get a deterministic integer k when doing the
ECDSA signing of the x.509 certificates used by U2F and particularly
individual attestation mechanism, rather than using the random generator
as per the original ECDSA algorithm.
So the generated certs have bit-for-bit identical signatures when the
content is identical.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=pass U2FTest and manually dump several individual attestation certs,
run the "rfc6779" console command when enabled.
Change-Id: I7b73eee6d5a863aae9a7eec49db884151bad5ab4
Reviewed-on: https://chromium-review.googlesource.com/558073
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The new signer (version: 1.2 00840c1b6) allows hex values in the
manifest, which means there is no need to explicitly convert the
values before adding them to the manifest.
A nice side effect of this is the fact that there is no need to care
about the sign of the values any more, the signer does the right
thing.
BRANCH=none
BUG=none
TEST=built an image using the following invocation:
$ make BOARD=cr50 H1_DEVIDS='0x12009015 0x90e95664' -j
and successfully ran it on a device. Note that the old signer was
chocking on hex values exceeding 0x7fffffff, the new one handles
them properly.
Change-Id: I08c0339f922d287c82d56fb51570bfbf7107531e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/598728
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Save a small amount of time when the USB resume is making the chip boot
from deep-sleep by removing the verbose serial traces in main and
increasing the usb initialization priority.
This brings us from borderline timings wrt the USB specification to a
reasonable margin.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:38160821
TEST=run on hotelgolf, go to deep-sleep on USB-suspend.
On USB resume, measure the time from CPU boot to the end of usb_init
using the CPU cycle count. We are shaving 1.3ms.
Change-Id: Ia5bf69c0ca26748dec59a87f3908a5fe68296b36
Reviewed-on: https://chromium-review.googlesource.com/563206
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Remove the code switching between PHY0 and PHY1. We now only use the CCD
PHY on all boards.
BUG=b:36488273
BRANCH=cr50
TEST=ccd works fine. cr50 usb doesn't show up on the AP. You cannot
switch the PHY on cr50.
Change-Id: I6ff641af9d7129daa8592f952f9df97c3862395b
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/595201
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
AP and EC UART now use the CCD V1 capabilities to determine when
access is allowed. Transmit to AP and EC can be toggled independently
from read access to output from those UARTs.
Note that disabling read access disables both transmit and receive.
That is, it's not possible to set a UART where transmit is allowed but
receive isn't. Why would you want to do that, anyway?
See go/cr50-ccd-wp for more information.
BUG=b:62537474
BRANCH=cr50
TEST=manual with CR50_DEV=1
ccdoops
ccdset cr50fullconsole always -> so we can use ccd command for testing
ccd -> AP RX+TX, EC RX+TX
ccdset uartecrx unlesslocked
ccdset uartectx ifopened
ccdset uartaprx always
ccdset uartaptx unlesslocked
ccdunlock
ccd -> AP RX+TX, EC RX
ccdlock
ccd -> AP RX, EC disabled
ccdoops
ccdset cr50fullconsole always
ccd -> AP RX+TX, EC RX+TX
ccdset uartaprx ifopened
ccdlock
ccd -> AP disabled, EC RX
Change-Id: I55db5897bb52cd60658ab221eadf5c59fc86744a
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/595196
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
In eSPI systems, when the Host performs a data read from the Shared
Memory space, the returned data may be corrupted. This is a result of
the Core-to-Host access enable bit being toggled (by toggling CSAE bit
in SIBCTRL register) during an eSPI transaction.
The workaround in this CL is to set CSAE bit to 1 during initialization
and remove the toggling of CSAE bit from other EC firmware code.
(i.e., let the CSAE bit be always 1.)
BRANCH=none
BUG=none
TEST=No build errors for make buildall. Flash poppy ec image, make sure
it can boot to OS. Run "ectool version" over 100000 times, no error
occurs.
Change-Id: I7aac6805ece64e8f77964d4acb026d9871cd2ebe
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/590396
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: CH Lin <chlin56@nuvoton.com>
Reviewed-by: Shawn N <shawnn@chromium.org>
id only really needs 4 bits (16 touch events should be more than
enough), so we can steal 2 bits from that field.
We also reorder the fields to make sure that width/x are aligned
on 8-bit boundary.
BRANCH=none
BUG=b:63936194
TEST=Flash hammer, touchpad works, ABS_PRESSURE > 255 is reported
when a palm is pressed on the touchpad.
Change-Id: I1abf1bf53cc9dd998082cea5dc7cd3be17f99ec6
Reviewed-on: https://chromium-review.googlesource.com/583297
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: KT Liao <kt.liao@emc.com.tw>
When in factory mode, we should not be trying to figure out board
strapping options, just enable SPI interface so that the tester can
communicate with the chip.
Also, to close the loop with the tester, let's add indication of the
cert installation result, by setting the two top bits of the DUMMY
(aka underrun) character to 1 and the lower bits to the endorsement
operation result (0 means success, nonzero values communicate
different failure modes) and by preventing the TPM driver from sending
anything but underrun chars on the SPI interface.
BRANCH=cr50
BUG=b:63686091
TEST=pending
Change-Id: I1a22ed6988ad87dd929a393359c4604e6ecd3b58
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/578651
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Because that's what it means. That is, it reports the state of
uartn_tx_connect(), not uartn_enable().
No functional changes; just a rename.
BUG=none
BRANCH=cr50
TEST=make buildall -j
Change-Id: Ie2273b277bd73a40307be7ec215417c1225cd567
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/590859
SPI access now depends on CCD_CAP_AP_FLASH and CCD_CAP_EC_FLASH.
usb_spi_state.enabled_host and .enabled_device are now bitfields which
depend on which SPI interface is enabled. This was implied before by
a single & comparing enabled_host to enabled_device, but is now
explicit so that the device can decide to enable just a subset of
buses.
BUG=b:62537474
BRANCH=cr50
BRANCH=cr50
TEST=manual with CR50_DEV=1
Connect host PC to dev board USB port
On host PC:
sudo servod -c ccd_cr50.xml -c reef_r1_inas.xml
In test protocol below, (test EC) means this command:
sudo flashrom -p raiden_debug_spi:target=EC --wp-status
And (test AP) means this command:
sudo flashrom -p raiden_debug_spi:target=AP --wp-status
"pass" means no console warning about "SPI access denied"
"fail" means console warnings about "SPI access denied"
To get even more confirmation, in chip/g/usb_spi.c temporarily
put this debug statement at the end of usb_spi_deferred():
CPRINTS("SPI res=%d", (int)res);
Pass is res=0, fail is res=5.
ccdoops
(test AP) --> pass
(test EC) --> pass
ccdunlock
(test AP) --> fail
(test EC) --> fail
ccdoops
ccdset flashap unlesslocked
ccdunlock
(test AP) --> pass
(test EC) --> fail
ccdoops
ccdset flashec unlesslocked
ccdunlock
(test AP) --> fail
(test EC) --> pass
Change-Id: I3d37d088b748832f164f2ca0ff29a93d6532ebed
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/590858
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Add support for OTP memory: if needed store serial number in first bank.
BUG=chromium:746471
BRANCH=none
TEST=On sweetberry, check we can write serial number with serialno
command. Check serial number survive a firmware update.
First, check without write protect, check we can write 0s (but not 1s)
serialno
Serial number: NNNNNNNNNNNNNNNNNNNNNN
>
> serial set MMMMMMMMMMMMMMMMMMMMMMMMMMMMM
Saving serial number
Serial number: LLLLLLLLLLLLLLLLLLLLLL
After lock enabled, check we can not overwrite.
> serial set AMMMMMMMMMMMMMMMMMMMMMMMMMMMM
Saving serial number
Serial number: LLLLLLLLLLLLLLLLLLLLLL
Access Denied
Check that serialno returns "Uninitialized" if it was never set.
Change-Id: I9ab08486a7c3e1958e964649640d69b5b70947e3
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/580290
Reviewed-by: Nick Sanders <nsanders@chromium.org>
One Time Programmable memory can be used to store permanent data like
serial numbers.
Reorganize the code to support writing serial number to OTP, in
addition to pstate (if using its own memory bank) or autogenerate from
unique id (hammer).
+ Add CONFIG_OTP to enable OTP code
+ Add CONFIG_SERIALNO_LEN to indicate the size of the serial number
string. Currently set to 28, when USB serial number is needed.
+ Expose flash_read|write_pstate_serial and add otp_read|write_serail,
remove more generic flash_read|write_serial.
+ Make board_read|write_serial generic, declared outside of USB subsystem.
Priority order to read|write serial string:
- board definition (like hammer)
- pstate location, if stored in its private memory bank
- otp area
If none of these methods are available, a compilation error is raised.
BUG=chromium:746471
BRANCH=none
TEST=compile
Change-Id: I3d16125a6c0f424fb30e38123e63cf074b3cb2d3
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/580289
Reviewed-by: Nick Sanders <nsanders@chromium.org>
gpio_interrupt_type_sel() is guaranteed to be called with at least one
GPIO_INT_ANY bit set, but our new toolchain doesn't seem to realize it.
BUG=chromium:747553
BRANCH=None
TEST=`make BOARD=gru -j` with next_gcc, also verify kevin boots to OS.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ice2a9963983dca2ee9c0c543bf55c27753c42933
Reviewed-on: https://chromium-review.googlesource.com/584820
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
If we have no ISR for an enabled GPIO interrupt (eg. for a UART GPIO
interrupt that wakes from low-power idle) then clear it, to avoid
interrupt storm.
BUG=b:63958831
BRANCH=eve
TEST=Verify we can repeatedly wake from low-power idle on eve by hitting
'enter' on the EC console.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I6a01cae33e3bf1a3b5b42c0389c4613dc1cb9b7d
Reviewed-on: https://chromium-review.googlesource.com/584011
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
Currently sweetberry hits an integer truncation issue
at 2.4 ohm when uA per div goes below 1. We can use 100ths
of a uA as the current per div scale.
BRANCH=None
BUG=chromium:608039
TEST=log from sweetberry with 10 ohm config.
Signed-off-by: Nick Sanders <nsanders@chromium.org>
Change-Id: I9e9216230329483fd0bfcb44ce23cd15bae864b3
Reviewed-on: https://chromium-review.googlesource.com/577051
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
hwtimer ticks at 8 * 32768 Hz rather than 250 KHz, so adjust our timing
appropriately. Also ensure that udelay() will delay for at least the
requested time, taking into account our timer precision.
BUG=b:63858553
TEST=Generate square wave with 1000us udelay between GPIO edge toggle,
verify period is 1000us + code overhead. Also verify timer behavior on
overflow with 'forcetime' command. Also verify accuracy of system clock
to 0.2% with `timerinfo` and a stopwatch.
BRANCH=None
Change-Id: I5da41bd7250db87de5143cc54ebd0bb750fb7003
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/578551
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Unique device ID register (96 bits) is at a different place on STM32F4
compared to other STM32.
BUG=none
BRANCH=none
TEST=Using board_read_serial() from hammer/board.c in
sweetberry/board.c, confirmed that we can extract and assign a unique
USB serial number.
Change-Id: Idb257f0f20422482c729a2b97b4b16ee231ca4d9
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/579575
Commit-Ready: Gwendal Grignou <gwendal@google.com>
Tested-by: Gwendal Grignou <gwendal@google.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
This CL adds CHIP_VARIANT_NPCX7M6G to support another npcx7 ec SKU.
Please note that the default setting in npcx7_evb is npcx7m6f.
For the EVB using the 128-pins EC package, please change CHIP_VARIANT
from npcx7m6f to npcx7m6g in build.mk.
BRANCH=none
BUG=none
TEST=No build errors for make buildall; Set CHIP_VARIANT=npcx7m6g in
board/npcx7_evb/build.mk; Build the image and test on EVB.
Change-Id: I2f857e4f6524eab45930bac3cc209409d4a53ee8
Signed-off-by: CHLin <CHLIN56@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/569320
Commit-Ready: Jun Lin <riverq@gmail.com>
Tested-by: Jun Lin <riverq@gmail.com>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mulin Chao <mlchao@nuvoton.com>
STM32 I2C frequency can be computed as such:
tSCL = tSYNC1 + tSYNC2 + { [(SCLH+1) + (SCLL+1)] x
(PRESC+1) x tI2CCLK }
The default values we use come from the datasheet, which assume,
for 400 kHz setting, that tSYNC1 + tSYNC2 = 750 ns, and therefore
set tSCLH as 500 ns and tSCLL as 1250ns.
On hammer, we measured a total tSCL of ~2150 ns (465 kHz) with
these settings, so we can easily slow it down to ~2500 ns (400 kHz)
by increasing tSCLH to 750 ns (SCLH = 0x5).
As highlighted in 48b2edf031
"stm32f0/i2c: adjust the 100kHz setting to never go above 100kHz"
this has the disadvantage of slowing down other boards where
the RC value on the I2C bus are different, but slowing down should
always be safe, and is the best we can do without adding config
defines for the fall/rise time.
BRANCH=none
BUG=b:36172041
TEST=Flash hammer, measure SCL frequency to be about 400 kHz
Change-Id: Ia2cac9fb09228abd8a318d57335855be529485c2
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/563219
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Before
72afc55bd9 "stm32: cleanup flash-f by using constant from register.h"
lock() function would simply do:
STM32_FLASH_CR = FLASH_CR_LOCK;
which would clear all other bits in STM32_FLASH_CR, including
FLASH_CR_OPTER and FLASH_CR_OPTWRE.
This allow preserve_optb to work, as it does:
1. erase_optb
a. unlock()
b. Set FLASH_CR_OPTER
c. lock() (clears FLASH_CR_OPTER!)
2. write_optb
a. unlock()
b. Set FLASH_CR_OPTPG
c. Write option byte
d. Clear FLASH_CR_OPTPG
e. lock()
After the patch, we now have:
STM32_FLASH_CR |= FLASH_CR_LOCK;
which seems more correct. However, 1.c. does not clear FLASH_CR_OPTER,
and 2.b. ends up with both FLASH_CR_OPTPG and FLASH_CR_OPTER set,
and the programming operation does not do anything.
This patches does 3 things:
- Rename FLASH_CR_OPTSTRT to FLASH_CR_OPTER, as that's the correct
register name for STM32F0 and STM32F3.
- Fix the above by clearing FLASH_CR_OPTER in erase_optb
- Also clear FLASH_CR_OPTWRE in lock(). Not strictly necessary,
but this seems to be the right thing to do.
BRANCH=none
BUG=chromium:739608
TEST=On hammer, type flashwp true; reboot; flashwp all; reboot
flashinfo => All flash is protected
Change-Id: Ic276545ae3c0bdb685c7b117a7f896ec341731bb
Reviewed-on: https://chromium-review.googlesource.com/562839
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Split bn_modexp() into three variants:
bn_modexp() for large exponents (as before)
bn_modexp_word() for single word public exponents
bn_modexp_blinded() for large exponents w/ randomization
We randomize bn_modexp_blinded() with:
1) pick 64 bit random R1 and compute R1 ** -1 and R1 ** pubexp, mod N.
2) multiply input by R1 ** pubexp
3) pick 64 bit random R2 and add (e*d*R2 - R2) to private exponent (i.e.
a random multiple of phi(N))
4) exponentiate
5) multiply output w/ R1 ** -1 to obtain expected result
Since we enlarge the exponent, bn_modexp_blinded() is slower than
bn_modexp(). We only use bn_modexp_blinded() when private exponents are
in play and we have phi(N) available.
Also refactored the combined p256 and rsa dcrypto binary blob into two
parts. And added unique first word to each dcrypto blob to make code
caching reliable.
The TPM task stack maxes out at 8040/8192 in tcg_test due to increased
stack usage of bn_modexp_blinded() but is still within safe bounds,
with 88 byte redzone.
BRANCH=cr50
BUG=b:35587382,b:35587381
TEST=buildall, tcg_test (200+)
Change-Id: Ied1f908418f31f8025363179537aa4ebd2c80420
Reviewed-on: https://chromium-review.googlesource.com/540684
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
PSTATE is already included in WP_BANK_OFFSET + WP_BANK_COUNT,
so this change is not only unnecessary, but also harmful.
BRANCH=none
BUG=chromium:739608
TEST=Flash hammer, flashwp true; reboot; flashinfo
=> RO is protected
Change-Id: I31048c0156eff354fbcc6ae5828a6ef313b56b97
Reviewed-on: https://chromium-review.googlesource.com/561037
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
