Add touchpad related host commands:
1) EC_CMD_TP_SELF_TEST: run open short test.
2) EC_CMD_TP_FRAME_INFO: get number of frame and frame size.
3) EC_CMD_TP_FRAME_SNAPSHOT: make a snapshot of the frame.
4) EC_CMD_TP_FRAME_GET: get frame data.
BRANCH=none
BUG=b:62077098
TEST=`make BOARD=rose -j`
`ectool --name=cros_tp tpselftest` and
`ectool --name=cros_tp tpframeget` works
Change-Id: I43db82278e556b1e6f6301fe88233fe7c4a18a14
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/515282
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Rong Chang <rongchang@chromium.org>
This patch enhances the Cr50 usb_updater to allow to get and set Board
ID value saved in the Cr50's INFO1 space using the earlier introduced
dedicated vendor commands.
Getting or Setting the board ID does not require establishing a
connection with the Cr50, the new option is --board_id/-i. When
specified without a parameter, the new option will cause the Board ID
to be read. When specified with a parameter, the board ID value will
be set. The parameter includes one or two values in a single string,
the values separated by a colon.
The first value is a 4 byte board ID, and the second value is the
flags field. The default flags field is set to 0xff00.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=verified that it is possible to get and set the board ID value
using usb_updater, both over USB and TPM.
verified that it is not possible to set a new board ID value is
the INFO1 space has been already programmed.
verified that it is not possible to set a board ID value which
would not allow the currently running image to start (even
though there is no run time check yet).
Change-Id: Ief175d8b2ef3177db13fa86f831914088d9447b0
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/525096
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Initial version of battery.c for coral is just a straight copy from
Reef. Updated this file to include the battery being used for the
first HW build. Removed the profile override config for the starting
point as well.
BUG=b:62272260
BRANCH=none
TEST=Run 'make BOARD=coral' and verify it builds. Can't test on actual
HW yet as the boards aren't build yet.
Change-Id: I15fcf438918c03bf1d459f5806dff04c82fe8b46
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/521756
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add nucleo-f411re for testing STM32F411.
Fix registers.h to include F411 specific features.
TEST=Check uart,gpio works. Check BMI160 accel/gyro sensor works over
i2c
Install firmware with "make BOARD=nucleo-f411re flash"
BUG=b:38018926
BRANCH=none
Change-Id: I8514d1aa48e06708053e72f8d4be15738eda6cf4
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/249994
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
There are only two usb_updater actions which require establishing a
connection with the Cr50: transferring the firmware image during
update and reporting the version of the running image (because the
version is reported when the connection is established).
This patch refactors usb_updater code to establish the connection only
when necessary.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=verified that 'usb_updater -c' succeeds both issued over USB and
TPM
Change-Id: I6a0c82eb440c092263d4802f124f458f148a8ab5
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/525095
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The upcoming changes in usb_updater will allow to issue vendor
commands to set and get board ID value. It is also useful to be able
to corrupt the alternative RW header over Suzy-Q when Cr50 is running
a debug image.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=not yet.
Change-Id: I54ac6eb4cebd85f97407211c5212b868d61e560f
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/524894
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
So far vendor command processing has been a second class citizen in
the Cr50 usb_updater: return codes were mostly ignored even when using
TPM, when using USB there was no way to communicate return codes at
all.
This patch refactors the source code to use a single function to
process vendor commands over both USB and TPM, adding proper passing
of the result codes back to the caller in both cases, retrieving the
return code from the response header when using TPM and from the first
byte of the response payload when using USB.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=verified that it is possible to update rw13, rw18 and rw20 both
over TPM and USB, which indicates that vendor commands are
properly handled.
Change-Id: I837e17b29d3b025fbca5b1ef49463cfb1729fe6c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/525094
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
To port Scarlet from firmware-gru-8785.B to master, we need
some change in naming/definition of variables/functions.
BUG=b:62307687
CQ-DEPEND=CL:524034, CL:524973, CL:524981
BRANCH=gru
TEST=build image and boot Scarlet
Change-Id: I20c1a4f311c9250a3bf1a2a5b0c70dd0f7c7e45b
Reviewed-on: https://chromium-review.googlesource.com/524987
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Set the VCCIO rail to 0.85V where it should be for Y-series parts
instead of forcing it to 1.0V. The EDS is pretty clear that pushing
this voltage higher on Y-series parts will have significant power penalty.
(up to 250mW at 0.95V)
We also don't want this rail dropping in low power mode, which shoudln't
be happening as S0ix is disabled so SLP_S0 shouldn't assert, but just in
case disable this as well.
BUG=b:35587084
BRANCH=eve
TEST=stress testing on Eve EVT units
Change-Id: I5535fe0d894f283a8d453d61101dfeb6b9287b7c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/525836
Reviewed-by: Todd Broch <tbroch@chromium.org>
When vendor commands are processed by the TPM device, the result of
the command execution is communicated through the TPM response header.
When vendor commands are sent through USB the command execution result
value is lost, as the USB reply includes only the response payload,
(if any), but not the result value.
With this patch the single byte result value is prepended to the USB
response payload. The recipient will always look for the value in the
first byte of the response to find the vendor command execution
status.
The corresponding change to the Cr50 usb_updater will remove the
response code from the payload before considering the command's return
data.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=verified proper existing extension commands processing (post
reset, turn update on) by the new version of usb_updater and
backwards compatibility with earlier Cr50 RW version (down to
0.0.13).
Change-Id: I5c8b3ea71d3cbbaccc06c909754944b3ab04675d
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/525093
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
When invoking vendor command handlers in try_vendor_command(), the
buffer containing the command is passed to the handler to communicate
the command contents and to hold the command execution return data. It
was fine when invoking vendor command handlers from the TPM stack, as
the receive buffer is 4K in size and is large enough for any expected
vendor command response.
It is different in case of USB: the command is in the receive buffer
of the USB queue, and the response data could easily exceed the
command size, which would cause corruption of the USB receive queue
contents when the response data is placed into the same buffer where
the command is.
Let's introduce a local storage to pass the command and receive the
response data from the handler. 32 bytes is enough for the foreseeable
future, should a need arise for a larger buffer, testing would result
in an error (a new error type is added to indicate insufficient buffer
space for command processing).
BRANCH=none
BUG=b:35587387,b:35587053
TEST=with the rest of the patches applied verified proper processing
of the 'Get Board ID' command for which response size exceeds the
request size.
Change-Id: I2131496f3a99c7f3a1869905120a453d75efbdce
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/525092
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Mix in board-generated entropy with the externally provided one,
which should help make the per-device secret stronger.
BRANCH=none
BUG=b:38486828
TEST=reboot; rollbackaddent Hello => works fine when USB is connected,
fails otherwise, as board-generated entropy relies on USB timing.
Change-Id: I314f44759c5f8b859913a748db95e9d42b5cdd11
Reviewed-on: https://chromium-review.googlesource.com/518609
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Mattias Nissler <mnissler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This function will be used to generate some entropy using the
Clock Recovery System.
BRANCH=none
BUG=b:38486828
TEST=make BOARD=hammer -j tests
./util/flash_ec --board=hammer --image=build/hammer/test-entropy.bin
EC console: runtest
TEST=Test fails when no USB connection is active
TEST=Test passes when USB connection is active
TEST=Pasting the values into:
tr ';' '\n' | awk 'BEGIN { e = 0; tot=16384.0 }
{ p = $1/tot; if (p > 0) { e -= p*log(p)/log(2) } }
END { print e }'
shows an entropy > 4 bits per sample.
Change-Id: I2363c7bce42c72c33ef0bf3f099d709ee9c13d13
Reviewed-on: https://chromium-review.googlesource.com/518608
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The system power monitor function, aka. PSYS, of the ISL9238 chip
is disabled by default, this patch enables PSYS monitor in the
EC driver.
BUG=b:62041842
BRANCH=none
TEST=Able to read non-zero value at the MSR of
MSR_PLATFORM_ENERGY_STATUS (0x64D) by iotools;
Also, kernel powercap driver probes PSYS domain correctly;
Such that the kernel exports the sysfs node of intel-rapl:1
Change-Id: I7a533032815e873ae74dca42ec07041be0d0f975
Signed-off-by: Harry Pan <harry.pan@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/520549
Tested-by: Kane Chen <kane.chen@intel.com>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Cr50 has different gpio configurations for different boards. They cannot
be determined until board_init. We want a way to delay enabling the gpio
interrupts until the board type can be determined.
This change adds a gpio flag, GPIO_INT_DISABLE. When set gpio_pre_init
will setup the interrupt, but not enable it. board_init then enables all
of the interrupts with init_interrupts.
BUG=b:35587228
BRANCH=cr50
TEST=use 'gpiocfg' to verify the setup hasn't changed. Add print
statements to verify that gpio_pre_init skips enabling the interrupt on
any gpio that has GPIO_INT_DISABLE set
Change-Id: I91f73297ab80781b99aa82eda479ae311c13cb77
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/523808
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The UART block on the g chip has no functionality to adjust the parity.
Unfortunately, this feature is needed for certain applications.
This commit adds a UART bit bang driver with support for configuring the
baud rate and parity. It currently only supports 8 data bits.
BUG=b:35648297
BRANCH=cr50
TEST=make -j buildall
TEST=With some other patches, successfully flash rowan EC at 9600 baud.
Change-Id: I86a160c0960e46b3a8bb1057518f625aefb7d81f
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/503473
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Board version 5+ has BD99954 charger which does not have audible
noise when battery is full and charger is at 20V. Disable the
discharge-on-ac workaround for these boards.
BUG=b:37228827
BRANCH=none
TEST=tested on board version 5 that discharge-on-ac is not enabled
when the battery is full.
Change-Id: I72e6870e06328d84a802c2f736659677de1f9a08
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/524222
Reviewed-by: Scott Collyer <scollyer@chromium.org>
pinmux only prints uart and gpio information. This change makes pinmux
print i2c and spi connections too.
This does not handle the direct pin to peripheral mappings, so the spi0
and sps0 peripheral pins still won't show up.
BUG=none
BRANCH=cr50
TEST=run pinmux on reef
Change-Id: Iaa6204e2af7f018569b92280bd1367aef201cc28
Signed-off-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/501172
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The previous LED implementation was modelled on Kevin and enhanced to
give developer feedback. This CL implements the Eve specific LED
operation.
BUG=b:35584895
BRANCH=none
TEST=Manual
Used EC console command 'battfake' to force different charge levels
and verified that the expected LED patterns were generated.
Change-Id: I46bc2889540f320e8aadf3d9d634c36dbc38c161
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/516548
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Add primitives to build x.509 certificates encoded in ASN.1 DER,
as a building block for the U2F feature.
Mostly copied over from the cr52 code-base.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve
and manually verify the individual attestation certificate with an ASN.1
parser.
Change-Id: Ie90730d8c401c661c8ab3b1b19631337b7390e9c
Reviewed-on: https://chromium-review.googlesource.com/518134
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The default USB packet has a maximum size of 64 bytes, however, we need
to support some USB over I2C write transaction that exceed this default.
To support so with protocol backwards-compatible in mind, we enable a
config option CONFIG_USB_I2C_MAX_WRITE_COUNT that will enlarge the USB
RX queue.
BRANCH=none
BUG=b:35587174
TEST=Complete presubmit test.
TEST=Manually update elan trackpad firmware with interrupt disabled.
Change-Id: Ia8983b036b7297f7ca673459ae34b7e5ecd2ee01
Reviewed-on: https://chromium-review.googlesource.com/513642
Commit-Ready: Chun-ta Lin <itspeter@chromium.org>
Tested-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Chun-ta Lin <itspeter@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The initial value for input current limit is set to
CONFIG_CHARGER_INPUT_CURRENT which is typically 512 mA. In deeply
discharged battery cases (Vbat < 5.8V), the 512 mA input current limit
can cause VSYS to collapse which in turn causes the EC to
reset. Depending on how discharged the battery is, the EC may remain
off until the external charger is disconnected and reconnected again,
or it may undergo a number of reset cycles, each time charging the
battery just a little, until Vbat becomes > ~5.8V and the charger is
able to stabilize. When the charger type is determined, either from
BCD detection, or Type C/USB PD, the input current limit is set to the
appropriate level.
In order to avoid the issue described above, this CL sets a bit in the
VIN_CTRL_SET register which will disable the input current limit in cases
Where the VBAT is less than the VSYSREG_SET value.
BUG=b:35648317
BRANCH=none
TEST=Manually tested on Electro.
a. With Zinger attached DUT boots without the battery after
plugging in AC
b. DUT boots from cut-off battery
c. With Zinger attached DUT boots from cold-reset without the
battery
d. With no battery & DCP charger, anti-collapse occurs,
input current is limited to 512mA & the DUT is
power-up inhibited.
Tested also on Eve with signal wires attached to both PPVAR_VSYS,
PP3300_DSW, and Vbat. Verified that on certain boards (some board to
board variation) that PPVAT_VSYS would collapse when the input current
limit was set to CONFIG_CHARGER_INPUT_CURRENT. Then after adding this
CL, verifed on the scope that the collapse of PPVAR_VSYS no longer
occurred.
Change-Id: Ief9960550f988e69ab4637db85450e91c70d3b51
Signed-off-by: Vijay Hiremath <vijay.p.hiremath@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/456049
Commit-Ready: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
Add support to write and erase all flash with flashrom.
Add support to use all the memory.
Note that PSTATE must not used its own page, as the STM32F4 use big pages.
BUG=b:38018926
BRANCH=none
TEST=With flashrom, write all, RO, RW regions.
Use flash command on the console, including flashwp
Change-Id: I4f0aee1b3a4f342bdf4ca97bf5d8e8bcc153fd9c
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264032
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
There is a new keyboard matrix layout:
- We can map the search key to both KSO1, KSI0 and KSO0, KSI3
(old layout will only use the former, new layout will use the latter).
- There is a new key on KSO0, KSI5, which we can map to HID page 0xffd1
code 0x0018.
BRANCH=none
BUG=b:62004286
TEST=Flash hammer
kbpress 0 3 1; kbpress 0 3 0 reports KEY_LEFTMETA as expected
kbpress 0 5 1; kbpress 0 5 0 reports "BTN_0", which is probably
incorrect, and needs to be fixed.
Change-Id: I9fb428805ff756b6d63f50cc5b061c6a0e1defbc
Reviewed-on: https://chromium-review.googlesource.com/512502
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Add support for i2c boot protocol 1.1 and erase non-strech erase
command.
Add option to specify i2c slave address.
TEST=Read, Erase and Write SH on Ryu P4.
BUG=chrome-os-partner:36018
BRANCH=none
Change-Id: Ib0649323fd8879fef6e2dc5e62001c891afe128a
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/250101
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
Use constants from registers.h, to easily support other ECs.
Fix indentation in registers.h
BRANCH=none
TEST=compile + following patches tested on STM32F411
BUG=None
Change-Id: Iecb3ce759a5c4ff13463e7df1cb7e03fc1ce6f69
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264030
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
Some device has large pages that take up to 2s to erase.
Add support to send a deferred erase command, that willi
be processed on HOOK task.
It can leave the other tasks (HOST_CMD) responsive.
If the whole EC can stall on flash erase, like the STM32F4 do,
at least the command FLASH_ERASE_GET_RESULT can be retried when it times
out.
BRANCH=none
TEST=Check with flashrom doing a loop of overwrites.
BUG=b:38018926
Change-Id: I8ce8e901172843d00aac0d8d59a84cbd13f58a10
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/510012
Reviewed-by: Alexandru M Stan <amstan@chromium.org>
The code invoking vendor commands callbacks rightly passes the pointer
to the command payload as the address right after the subcommand
field, but does not deduct the size of the subcommand field from the
size of the payload passed to the handler.
This patch fixes the issue, the command handlers do not see two extra
bytes at the tail of the command any more.
BRANCH=cr50
BUG=b:62294740, b:35545754
TEST=verified that vendor commands sent over USB and TPM still work
properly (in particular the TURN_UPDATE_ON command).
Change-Id: I11a45f65163044f808a82b214f9c5faf775f9020
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/522943
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
This patch adds vendor and console commands to read and write the
board ID space in the INFO1 block.
Current image's board ID settings are saved in the image header by the
latest codesigner.
Board ID write attempts are rejected if the board ID space is already
initialized, or if the currently running image will not be allowed to
run with the new board ID space settings.
Error codes are returned to the caller as a single byte value.
Successful read command returns 12 bytes of the board ID space
contents.
The console command always allows to read the board ID value, and
allows to write it if the image was built with debug enabled.
BUG=b:35586335
BRANCH=cr50
TEST=as follows:
- verified that board ID can be read by any image and set by debug
images.
- with the upcoming patches verified the ability to set and read
board ID values using vendor commands.
Change-Id: I35a3e2db92175a29de8011172b80091065b27414
Signed-off-by: Philip Chen <philipchen@google.com>
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/522234
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The buton behavior is inverted if we follow the schematic, so swap the
GPIO on these inputs so they match the expected behavior.
BUG=b:62120390
BRANCH=none
TEST=manual test of side volume button behavior
Change-Id: I0ad18b4a15fcc2832d97dfad3b03186180e4517a
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/522410
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Enable permanently the power button interrupt and discard the unneeded
presses, rather than enabling the interrupt on demand.
This is a preparatory work for the U2F feature which is using the power
button as the user physical presence sensing. It will need to be able to
detect all the button touches.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve.
Change-Id: Ifd90970932684d31ad7687db260bafa65a56e854
Reviewed-on: https://chromium-review.googlesource.com/518138
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add the robust non-volatile counter provided by CONFIG_FLASH_NVCOUNTER
in order to support the U2F implementation.
The counter implementation needs 2 (raw) pages of flash for its
underlying storage.
In order to try to avoid disrupting the existing machines by
invalidating the nvmem if we touch its mapping, those pages are placed
in each RW between the code/read-only and the read-write nvmem area by
shrinking the code/read-only by one page, so the nvmem mapping should be
untouched.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve.
Change-Id: Ib3d7dcb9a1b13cff74b56461332937e3a4cc9ae1
Reviewed-on: https://chromium-review.googlesource.com/518137
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Add the implementation of a robust non-volatile incrementing counter
using 2 pages from the underlying flash.
It is used to implement the U2F functionality.
The main goal of the counter is providing a strictly incrementing value
whatever adverse events (malicious or not) happen as it is used to
prevent rollback attacks in the U2F protocol.
Given the limitation of the flash process: ie wear-out endurance and
2kB-page erase granularity only and possible isolated bit-flips
(accentuated by power losses), the counting is done by pulling down
several bits at a time from their erased state (1) to 0.
The counting is implemented this way with 2 pages called LOW and HIGH:
The LOW page is implemented in a strike style, with each "strike" zero-ing
out 4 bits at a time, meaning each word can be struck a total of 8
times.
Once the LOW page is completely struck, the HIGH page is incremented by 2.
The even increment is for the value, the odd increment is a guard signal
that the LOW page must be erased. So as an example:
If HIGH is 2, the LOW page would increment to 3, erase itself, and then
increment to 4. If this process is interrupted for some reason (power loss
or user intervention) and the HIGH left at 3, on next resume, the HI page
will recognize something was left pending and erase again.
For a platform with 2-kB flash pages, it can count up to 8388608, then
it is stuck at 0xFFFFFFF indefinitely.
Mostly copied over from Marius code in cr52 code-base.
Signed-off-by: Marius Schilder <mschilder@google.com>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=cr50
BUG=b:35545754
TEST=with follow-up CLs, run U2FTest on Eve
Change-Id: Idd0756078e3641c4a24f9c4ccf6611909bd5f00f
Reviewed-on: https://chromium-review.googlesource.com/518135
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
max_response_packet_size was incorrectly set to
response_size + SPI header/footer,
leading to the command handler to return EC_RES_OVERFLOW when the
response buffer size was set by the host to a larger size then
response_size.
It is happening since flashrom does not limit itself to 128 bytes
command since cl/264034.
The SHI repsone buffer is laid out as follow:
,.... out_msg_padded
/
|
|< SHI_OUT_START_PAD >|< SHI_MAX_RESPONSE_SIZE >|< SHI_OUT_END_PAD >|
+---+-----------------+-------------------------+-------------------+
| | | | |
+---+-----------------+-------------------------+-------------------+
| \
| -------
| \
| EC_SPI_FRAME_START_LENGTH
|
\..... out_msg
BUG=b:35571522,chromium:725580
BRANCH=gru
TEST=Before flashrom would fail:
cros_ec_set_max_size: sending protoinfo command
cros_ec_set_max_size: rc:12
cros_ec_set_max_size: max_write:536 max_read:163
...
Reading flash... __cros_ec_command_dev_v2(): Command 0x11 returned
result: 11
Ater, flashrom works:
cros_ec_set_max_size: sending protoinfo command
cros_ec_set_max_size: rc:12
cros_ec_set_max_size: max_write:536 max_read:160
...
Reading flash... done.SUCCESS
Verified that cros_ec.c/cros_ec_spi.c set some space for header and
footer in addition to max_response_packet_size.
Change-Id: I0de7ee5e8109e9277692113f2bb1d4a4758be9f6
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/520585
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Nominal eve ALS config is 0.3088 scale.
The default bias for sensor of -256 is a good nominal value so leave
it alone.
BUG=b:37179776
TEST=manual,
boot to linux prompt,
localhost ~ # cat /sys/bus/iio/devices/*/in_illuminance_calibscale
0.308800
localhost ~ # cat /sys/bus/iio/devices/*/in_illuminance_calibbias
-256
Change-Id: I7c8425a38b1af094a39b37b464f812f5ac875083
Reviewed-on: https://chromium-review.googlesource.com/510809
Commit-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@google.com>
If CCD was set to the "keepalive" mode, removing the debug accessory
would cause the CCD_MODE_L pin to be pulled high, ignoring the keepalive
state. CCD was still kept alive, but the state reflected on the pin
didn't indicate so.
This commit changes the behaviour such that the CCD_MODE_L pin is set up
as an input only when CCD keepalive is not enabled.
BUG=None
BRANCH=cr50
TEST=Plug in debug accessory and remove debug accessory. Verify that
CCD_MODE_L is high after removal.
TEST=Enable ccd keepalive. Remove debug accessory. Verify that
CCD_MODE_L is still low.
Change-Id: I407994d5c394a717d6e1a87f283f6441bd26bf55
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/520603
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
The LED spec requires a double tap gesture. This CL adds the
appropriate CONFIG options to enable double tap gesture for Eve and
enables the interrupt for the bmi160. The board specific function in
this CL is just a placeholder.
BUG=b:35584895
BRANCH=none
TEST=Manual Verifed double tap is detected by seeing the console print
that's generated each time a double tap event occurs.
Change-Id: If3506cf1fbcfc2b380ac36c9d3039e0a8823eba1
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/516547
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
The config option to use interrupts for this sensor was defined,
however, the gpio interrupt for the interrupt from this sensor was not
being enabled.
BUG=b:35584895
BRANCH=none
TEST=Added a wire to the interrupt line on an Eve. Verified that when
the interrupt was triggered (verified by scope) that ISR for this gpio
was being called.
Change-Id: I9d9f6b5e6efa47665aba9a9d024b30aa10528002
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/518523
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The previous boards that used double tap both used lightbar
sequence. Eve, also needs double tap, but doens't have lightbar. Added
a board specific call when processing the double tap event to allow
more flexibility.
BUG=b:35584895
BRANCH=none
TEST=Manual tested double tap and verified it was detected based on
the console print.
Change-Id: I73d8669803e7dcbbbac00de09822f4a286965fce
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/516546
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The line to convert the desired double tap window time to its
register value was using the incorrect macro. Have corrected this to
use the intended one.
BUG=b:62202895
BRANCH=none
TEST=On Eve verified that double tap events are properly detected.
Change-Id: I70d810c93a8e27a3f61f3175e1ea95d0e59554ac
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/518522
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
The upcoming "real" signer update will introduce a version which is
not backwards compatible with the existing one wrt the command line
flags: the command line flag '-b' will have to be present.
To keep the default "dummy" signer in sync let's make it accept and
ignore the '-b' command line flag.
BRANCH=none
BUG=none
TEST=verified that the updated signer and the dummy signer both work.
Change-Id: Ia8ab6d7ae01d249046f267608b5971a7a7c95e29
Signed-off-by: Vadim Bendebury <vbendeb@google.com>
Reviewed-on: https://chromium-review.googlesource.com/517678
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
