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>
The newly generated file is now showing up in 'git status' output,
let's hide it.
BRANCH=none
BUG=none
TEST='git status' output is now clean even after running 'make -C
extra/usb_updater'.
Change-Id: I6f7e93b303cfff89ec8ae7b3a74286a743e9c27e
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/517677
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
All extension and vendor commands' payloads need to be passed to the
processing functions the same way, whether they arrive over /dev/tpm0
or over USB. The upgrade PDUs sent over USB need to include two
additional fields which are stripped off by the reassembly layer on
the Cr50.
This patch makes sure that none of other than EXTENSION_FW_UPGRADE
commands sent over /dev/tpm0 by usb_updater have the extra
encapsulation.
BRANCH=cr50
BUG=b:62106898
TEST=verified that updates work the same way over TPM and USB (which
includes sending the 'turn_update_on' commands. Before this patch
the turn_update_on command sent by usb_updater over TPM was not
processed properly (the timeout value was wrong).
Change-Id: I3f4ab7330037f6eb1ce8bac7c63faa5d7c309c94
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/517416
Reviewed-by: Andrey Pronin <apronin@chromium.org>
It needs to be possible to prevent unlocking of CCD on enterprise
enrolled devices, in particular to prevent users from moving into dev
mode.
A bit in the FWMP structure flags field was allocated for the purposes
of preventing console unlock in those cases.
This patch adds code to read the FWMP structure from the TPM NVMEM,
verify it and determine if it should be possible to unlock the
console. The restriction is not honored by Cr50 DBG images.
The FWMP value is read only once per TPM reset, this means each time
the admin console changes the relevant flag bit, the Chrome OS device
has to be rebooted to pick up the new flag value.
BRANCH=cr50
BUG=b:35587387,b:35587053
TEST=verified that FWMP is properly read and acted upon.
Change-Id: I17e15ea2b2293a0c096858fba3ccc389452caede
Reviewed-on: https://chromium-review.googlesource.com/457824
Commit-Ready: Vadim Bendebury <vbendeb@chromium.org>
Tested-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This patch sets the initial power button state to on if recovery
mode is requested.
BUG=b:37274183
BRANCH=none
TEST=Verify EC boots AP immediately in recovery mode on Fizz.
Verify EC doesn't boot AP immediately in normal mode.
Change-Id: Ib24eb6c6b7e9200cf7ba6af3e486337da3c68355
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/514209
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Because N8 CPU doesn't have floating point unit,
so we implement an extra floating point engine
(single-precision addition, subtraction, multiplication,
and division) into it8320 to improve performance of
floating point operation.
To make CPU's instruction compatible, we use register (DLMB)
to switch ALU (Arithmetic Logic Unit). eg:
Instruction 'ADD45' adds the contents of two registers then
writes the result to the source register.
But if we switch ALU to floating point operation mode,
this instruction will do a floating-point addition instead.
For the other FPU that we don't support as far,
we have to use soft float library routines of nds32.
Signed-off-by: Dino Li <dino.li@ite.com.tw>
BRANCH=none
BUG=none
TEST=add the following console command and test different
scenarios by changing variable a and b.
#define PRINTF_FLOAT(x) ((int)((x) * 1000.0f))
static int it83xx_fpu_test(int argc, char **argv)
{
volatile float a = 1.23f;
volatile float b = 4.56f;
volatile float c;
c = a + b;
ccprintf("__addsf3: (%d)\n", PRINTF_FLOAT(c));
c = a - b;
ccprintf("__subsf3: (%d)\n", PRINTF_FLOAT(c));
c = a * b;
ccprintf("__mulsf3: (%d)\n", PRINTF_FLOAT(c));
c = a / b;
ccprintf("__divsf3: (%d)\n", PRINTF_FLOAT(c));
return EC_SUCCESS;
}
DECLARE_CONSOLE_COMMAND(fpu, it83xx_fpu_test, "", "");
Change-Id: I4fc1c08d8c2376156bec9f098491187675c4a88f
Reviewed-on: https://chromium-review.googlesource.com/427640
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>
This change configures the SHA engine to
a) enable random stalls at 12% during regular
operation through SHA API's, and b) enables
random stalls at 25% when doing key-ladder
operations.
TCG tests continue to complete in ~20 minutes
(i.e. no noticeable slowdown).
BRANCH=none
BUG=b:38315169
TEST=TCG tests pass
Change-Id: Id4b541cdd3d51c57979a93f71a6291cca8eb1844
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/508172
Commit-Ready: Nagendra Modadugu <ngm@google.com>
Tested-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
In order to ensure we are always meeting the deadlines for the IRQ_HPD
pulse, increase the priority of the processing by moving the rising edge
from the low-priority HOOK task (in a deferred function) to the caller
task (which is the high-priority PD task).
The downside is we are now sleeping in the PD task blocking the
processing of the PD messages during this time.
Changed HPD_DSTREAM_DEBOUNCE_IRQ to 500us instead of 750us. According
to DP spec, the IRQ_HPD pulse width is between 500us and 1000us.
Ensure there is a minimum of 2ms delay in between each IRQ_HPD as specified
by the DP spec, by sleeping before sending the next pulse if needed.
(in practice, this should not wait if we are not too off processing the
messages)
BUG=chromium:711334
BRANCH=glados strago reef oak
TEST=manual, on SKL platform with kernel 3.18 and MST, verify display is
functional on USB-C dock.
Change-Id: Ib2e9dd608c5f1c671cc5a0fd979a5742101375ff
Signed-off-by: Kevin K Wong <kevin.k.wong@intel.com>
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/508629
Reviewed-by: Todd Broch <tbroch@chromium.org>
It is useful for the updater to be able to determine which region
is active without having to use the update interface.
BRANCH=none
BUG=b:35587171
TEST=lsusb -d 18d1:5022 -v -v | grep hammer shows either:
RO:hammer_v1.1.6441-e58472daf+ or
RW:hammer_v1.1.6441-e58472daf+
depending on the image used
Change-Id: I8e1acfbc546330e10ba650b743e3a4c9986b0c30
Reviewed-on: https://chromium-review.googlesource.com/515242
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
As part of the pairing process, AP needs to be able to inject
some entropy into the base.
Let's also define PAIR_CHALLENGE, which will be implemented in
a later CL.
BRANCH=none
BUG=b:38487027
TEST=Flash hammer. On host, reboot hammer to RO:
usb_updater2 -r; sleep 0.5; usb_updater2 -s
usb_updater2 -e (adds entropy)
EC console: check that rollbackinfo shows secret is updated
Change-Id: I964bb578c6bfbb1ab5105a70b43682d51df4ed47
Reviewed-on: https://chromium-review.googlesource.com/513807
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Newer Eve boards will lose VBAT on power cycle and therefore cannot
successfully save the reset flag state.
Implement the workaround that will allow these boards to continue to
work for FAFT testing by indicating to the skylake chipset power code
that it should skip the PMIC reset when doing 'reboot ap-off'.
BUG=b:35585876
BRANCH=none
TEST=manual testing on Eve: execute 'reboot ap-off' and ensure that the
AP does not power on. Also ensure that 'dut-control power_state:rec' works
as expected and does not power off at the recovery screen due to a power
button press.
Change-Id: Ida1563593d802c00280a55a0d24a504c25fab532
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/514504
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Some hardware has an issue where the reset flags are lost on power cycle
because the EC backup ram loses power. This causes the flag to not power
on the AP (ap-off) to be lost.
In order to pass FAFT it is required that boards support this flag, so
this commit adds a workaround where the skylake chipset code will call into
the board to ask if it has working reset flags and if not it will skip the
PMIC reset if the "ap-off" flag has been set.
The "ap-off" flag is purely for testing, it is not possible for users to
do this without having access to the EC console. (which is currently not
possible at all with CCD unless you can also build a debug cr50 image)
BUG=b:38187362,b:35585876
BRANCH=none
TEST=manual testing on Eve: execute 'reboot ap-off' and ensure that the
AP does not power on. Also ensure that 'dut-control power_state:rec' works
as expected and does not power off at the recovery screen due to a power
button press.
Change-Id: If11e17179e9173509b9a6ae1ef0d94a50ba181d0
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/514503
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
With the updated scancode matrix the keymask needs to be adjusted to
not mask off these particular keys.
BUG=b:36735408
BRANCH=none
TEST=build and boot on Eve
TEST=kbpress 0 3 1; kbpress 0 3 0 reports KEY_LEFTMETA as expected
TEST=kbpress 0 5 1; kbpress 0 5 0 reports MSC_SCAN but no key yet
(as expected because the kernel does not handle it yet)
Change-Id: Iba78741b8a0cd1248a799cf5219cee59ea6630ec
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/514502
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The trimmed value of CC parameter setting registers
(port0: ff3760h ~ ff3763h, port1: ff3860h ~ ff3863h)
will be reset to default after a soft reset (system_reset()).
BRANCH=none
BUG=none
TEST=Console command 'reboot' and checking if the value of
cc parameter setting registers are correct (trimmed).
Change-Id: Ibf9c72e8aeef36701d72bcb64529735295295cdf
Signed-off-by: Dino Li <Dino.Li@ite.com.tw>
Reviewed-on: https://chromium-review.googlesource.com/513744
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Previously, result codes were being stored as `enum ec_status` values.
The compiler was forcing this value to only be one byte large, since
that's all that was necessary to represent all the values of that
enum.
This change fixes this bug by switching result code variable types from
`enum ec_status` to `uint16_t`.
BRANCH=none
BUG=none
TEST=make buildall -j
Change-Id: Iacdca51dc6c1de677d2fbb59ad6dd2572d21ea7f
Reviewed-on: https://chromium-review.googlesource.com/513609
Commit-Ready: Jeff Andersen <jeffandersen@google.com>
Tested-by: Jeff Andersen <jeffandersen@google.com>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
For pairing purpose, we want to store some secret random number in
the base. The most convenient location for this is the rollback
region.
Since the rollback region can now be updated without incrementing
rollback_min_version (when we add entropy to the secret), we need
to add an increasing id to tell the code which rollback region is
the latest.
We also add console commands to manually add entropy.
BRANCH=none
BUG=b:38486828
TEST=Flash hammer (with or without CONFIG_ROLLBACK_ENTROPY_SIZE set)
rollbackinfo => 1 version 0 block, 1 empty block, RW verifies
correctly.
rollbackupdate 0; rollbackinfo => No change
rollbackupdate 1; reboot => RO refuses to jump to RW
only when CONFIG_ROLLBACK_ENTROPY_SIZE is set:
rollbackinfo => Secret is [00..00] on both blocks (so the data
was copied correctly)
rollbackupdate 2, 3, 4; rollbackinfo => Writes alternate
between the 2 blocks.
rollbackupdate 2 => Refuses to downgrade version
TEST=From blank secret [00..00], 'rollbackaddent Hello' updates it
to [ba..fa], which matches the output of:
(dd if=/dev/zero bs=1 count=32; echo -n Hello) | sha256sum
Change-Id: I79c3e790e56e21958cc1b4ba05bd4e5f359d3090
Reviewed-on: https://chromium-review.googlesource.com/511985
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
utils test is a little too large for hammer's small RO, so we split
it in 2 test: utils and utils_str. Instead of one test that requires
about 8kb extra flash, we have 2 tests that take respectively
3.4kb (utils_str) and 4.6kb (utils) of extra flash.
BRANCH=none
BUG=chromium:726113
TEST=make BOARD=hammer tests -j
util/flash_ec --board=hammer --image=build/hammer/test-utils.bin
runtest => pass
Repeat with test-utils_str.bin
TEST=Before this change:
make runtests -j
./util/run_host_test utils | grep Running | sort > old
Apply this change:
make runtests -j
(./util/run_host_test utils; ./util/run_host_test utils_str) \
| grep Running | sort > new
diff old new => No difference (except timing)
Change-Id: I917d572e671d6ce0a8799508761f55de7bd83133
Reviewed-on: https://chromium-review.googlesource.com/514604
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Add console and usb_spi commands to enable or disable IOs
to the socket, so that it will not be powered if a chip is inserted,
and control reset and boot_cfg.
BUG=b:36910757
BRANCH=None
TEST=Check no voltage when socket is disabled. Full spiflash compatibility.
Change-Id: Ie4ce0613a868030833abfdccd827acce2753dc6f
Reviewed-on: https://chromium-review.googlesource.com/509072
Commit-Ready: Nick Sanders <nsanders@chromium.org>
Tested-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
This patch sets GPIO_LAN_PWR_EN to output/high to power on
the ethernet port at start.
BUG=b:37646105
BRANCH=none
TEST=Measured V3P3A_LAN is 3.3V.
Change-Id: I9629a72d1ffefd1ca2aeb8d2d1f5d74a953d7e58
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/514622
Reviewed-by: Duncan Laurie <dlaurie@google.com>
