Create an app to extract relevant information
from the EC code base that's used to create Vendor
Information Files (VIFs) needed for USB Type-C
compliance testing.
BUG=chromium:701852
BRANCH=none
TEST=make -j buildall
Compared generated VIFs to expected values
Change-Id: I600ca78b9fb5d2de78aa65a58264c6f79b36ea17
Reviewed-on: https://chromium-review.googlesource.com/455280
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This patch clears the typematic buffer when disabling keyboard scan.
When the device goes to tablet mode with a key being pressed, this
should prevent keyboard_protocol_task from sending scan codes to the
host.
BUG=b:35585725
BRANCH=none
TEST=make buildall. Tested on Electro.
Change-Id: I73e9d2948b472458814967307412aebeb410ff2e
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/425075
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
When usb_wake is called (key press, trackpad event), pulse
detection pin for 100us. This allows Lid EC to wake the AP
even when it is in deep S3 mode, where normal wake using USB
lines does not work.
BRANCH=none
BUG=b:35775062
TEST=Flash hammer, looks at poppy console: base power is not
disconnected, but events appear in the console.
Change-Id: I7b8ee407046d4caa1ce75190c30d693b71b00d2e
Reviewed-on: https://chromium-review.googlesource.com/448380
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Augmented PDOs are part of the PD3.0 specification. As present USB PD
sinks can't support these PDO types we need to ignore them.
BRANCH=samus,glados,oak,gru,reef
BUG=b:37476637
TEST=manual,
On samus, plug-in blackcat (EVT) charger and see it ignore these
Augmented PDOs when making its PDO request.
Change-Id: I28a0377e1486368f25f37cad640af71244a4c30b
Reviewed-on: https://chromium-review.googlesource.com/484687
Commit-Ready: Todd Broch <tbroch@chromium.org>
Tested-by: Todd Broch <tbroch@chromium.org>
Reviewed-by: Benson Leung <bleung@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Current usb_wake was sleeping between setting and clearing RESUME
bit, which is unprecise.
Instead, we count ESOF interrupts in usb_interrupt to detect when
to clear RESUME.
It is also important that usb_wake does not block, as the calling
task (e.g. keyboard scanning) must continue to service events while
the USB device is resuming.
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
Wait a second, type something quickly, verify that no keys are lost.
Change-Id: I53b46cce5a4adb0ee4c4a7e9f935c00f7f321636
Reviewed-on: https://chromium-review.googlesource.com/490129
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
1. Provide led_control API that can be used by different drivers to
control the state of LED (0=off, 1=on, 2=reset)
2. Add a new LED ID for recovery HW_REINIT indication.
BUG=b:37682514
BRANCH=None
TEST=make -j buildall
Change-Id: I27334bde2b879046746456a610208f3fc2dd68b4
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/487840
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
AP will use that command to tell base EC that it believe the current
FW is functionning correctly, and that the rollback region can
be unlocked for an update on the next reboot.
BRANCH=none
BUG=b:35586219
BUG=b:35587171
TEST=- Flash hammer ToT image with rollback version 0
> flashwp true; reboot
> flashinfo => all flash is protected
- Update CONFIG_ROLLBACK_VERSION to 1
$ make BOARD=hammer -j
- Flash new RW
$ sudo extra/usb_updater/usb_updater2 -w
$ sudo extra/usb_updater/usb_updater2 -r
$ sleep 0.5
$ sudo extra/usb_updater/usb_updater2 -s
$ sudo extra/usb_updater/usb_updater2 build/hammer/ec.bin
> rollbackinfo
rollback minimum version: 0
RW rollback version: 1
- Tell RW to unprotect rollback
$ sudo extra/usb_updater/usb_updater2 -u
$ sudo extra/usb_updater/usb_updater2 -r
> rollbackinfo
rollback minimum version: 1
RW rollback version: 1
Change-Id: Ib52253e9b8bba872688d6f601d9bfad8862be25f
Reviewed-on: https://chromium-review.googlesource.com/489889
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
According to the new MCU secure update model, EC should wait for host if
reset source is reset-pin.
BRANCH=none
BUG=b:37584134
TEST=on rose, toggle reset pin from host. EC should stay in RO, showing
[0.426089 Hard pin-reset detected, disable RW jump]
in console.
Change-Id: Ie1908cb0744773e2e3ca8b3d8c627b8a9ef4567f
Reviewed-on: https://chromium-review.googlesource.com/485199
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Add a new host command EC_CMD_RWSIG_CHECK_STATUS for getting rwsig
status and rw firmware hash. This command is used to check the RW
signature of newly updated RW image.
A new subcommand is also added to ectool.
BRANCH=none
BUG=b:37584134
TEST=on rose board `ectool rwsigstatus` works
Change-Id: I33d8709f5248d3a4b8bedb36ded84a93dc8c971f
Signed-off-by: Wei-Ning Huang <wnhuang@google.com>
Reviewed-on: https://chromium-review.googlesource.com/485079
Commit-Ready: Wei-Ning Huang <wnhuang@chromium.org>
Tested-by: Wei-Ning Huang <wnhuang@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
There is a window where the rollback information in RW could
potentially be updated during RW signature verification. We make
sure this cannot happen by:
- Preventing update over USB while RWSIG is running
- When system is locked, only update rollback information if
RW region is locked: this guarantees that RW cannot be modified
from boot until RW is validated, and then until rollback
information is updated.
Also, remove rollback_lock() in rwsig_check_signature:
rwsig_jump_now() protects all flash, which also protects rollback.
This reduces the number of required reboots on rollback update.
BRANCH=none
BUG=b:35586219
BUG=b:35587171
TEST=Add long delay in rwsig_check_signature, make sure EC cannot
be updated while verification is in progress.
Change-Id: I7a51fad8a64b7e258b3a7e15d75b3dab64ce1c94
Reviewed-on: https://chromium-review.googlesource.com/479176
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add support for 4 extra commands that are required to update
hammer:
- UPDATE_EXTRA_CMD_IMMEDIATE_RESET
- UPDATE_EXTRA_CMD_JUMP_TO_RW: Tells the RWSIG task to jump
to RW as soon as possible (assuming the image verifies)
- UPDATE_EXTRA_CMD_STAY_IN_RO: Tells the RWSIG task to not
jump to RW, and stay in RO, to leave enough time for
AP to update RW.
- UPDATE_EXTRA_CMD_UNLOCK_RW: Tells EC to unlock the RW
section so that it can be updated (on next reboot).
BRANCH=none
BUG=b:35587171
TEST=Test RO+RW update
cd extra/usb_updater; make
# Jump to RW
sudo ./usb_updater2 -j
sleep 0.5
# Update RO, then reboot
sudo ./usb_updater2 ../../build/hammer/ec.bin
sleep 0.5
# Update RW (first tell RO to not jump to RW)
sudo ./usb_updater2 -s
sudo ./usb_updater2 ../../build/hammer/ec.bin
TEST=Test RW update only, with RO protected
On EC console: flashwp true; reboot
cd extra/usb_updater; make
# Tell RW to unprotect RW and jump back to RO
sudo ./usb_updater2 -w
sudo ./usb_updater2 -r
sleep 0.5
# Update RW, then reboot
sudo ./usb_updater2 -s
sudo ./usb_updater2 ../../build/hammer/ec.bin
Change-Id: I5e8df7bdb4f06f2ac7b47de53dcde69c5002f578
Reviewed-on: https://chromium-review.googlesource.com/458470
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
The ec_commands.h header uses types defined in stdint.h. To make the
ec_commands.h header more portable, ensure that includes what it uses.
Running "make -j buildall" worked for all boards except "gru" and "hammer",
which were broken before this change.
BRANCH=none
BUG=none
TEST=make -j buildall
Change-Id: I1ffe41a69b7296736616b9250c45f2749a66f22c
Reviewed-on: https://chromium-review.googlesource.com/483283
Commit-Ready: Carl Hamilton <carlh@chromium.org>
Tested-by: Carl Hamilton <carlh@chromium.org>
Reviewed-by: Jeff Andersen <jeffandersen@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This adds new macros for tasks (_RO and _RW), which allows to
enable a task only for RO or RW section.
We also create a new task_filter.h include file, that helps
pre-filter those tasks, and can be used either from Makefile,
or included from task_id.h.
BRANCH=none
BUG=b:35582031
TEST=make buildall -j; make savesizes
Apply this CL
make buildall -j; make newsizes => No size change
Change-Id: I472bc6d4ab250a0a0e1fa6aeb4b748ba6968bedf
Reviewed-on: https://chromium-review.googlesource.com/479491
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Nick Sanders <nsanders@google.com>
This CL includes:
1. Add gpio_chip-npcx5/7.h files and move all macro functions
related to chip family to them. (Move wui macro func from
gpio_wui.h to them.)
2. Replace alternative and low-voltage mapping table with macro
function NPCX_ALT_TABLE and NPCX_LVOL_TABLE.
3. Add UART wakeup mechanism in __gpio_wk1h_interrupt() ISR.
4. Add gpio register definitions of npcx7 family in registers.h.
5. Add GPIO_LOCKED flag for lock functionality.
BRANCH=none
BUG=none
TEST=No build errors for all boards using npcx5 series (besides gru).
Build poppy board and upload FW to platform. No issues found.
Passed validation for all GPIO functionalities on npcx5m6g
and npcx796f evb.
Change-Id: I60c30ce223629a0d8cb767a54a0a9b02a69de9c5
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/481561
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
cr50 and hammer/common code are such different chips that reusing the
same first_response_pdu does not make much sense.
Instead, we can use 2 different headers, the updater knows which
response to expect based on USB product ID.
In the common code answer, we can reply with the EC version string,
as well as rollback information and key version ID, which will
be required for reliable updating.
BRANCH=none
BUG=b:35587171
BUG=b:36375666
TEST=usb_updater2 can update hammer, and read its version, rollback
version and key version.
Change-Id: I20b04070606767c71df3e6286d53e238e13375c0
Reviewed-on: https://chromium-review.googlesource.com/476452
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
rw_sections is defined in the exact same way on all common code
boards, let's remove it, and hard-code the values in update_fw.c
instead.
Take this as an opportunity to fold set_valid_section in
fw_update_start (this will be useful later on, as we also
want to return the inactive region version).
BRANCH=none
BUG=b:35587171
TEST=make buildall -j
TEST=Can update hammer over USB using usb_updater2
Change-Id: I4dd3224f17f89c1851c379255f1195dc54528b3d
Reviewed-on: https://chromium-review.googlesource.com/476451
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
Let's move to protocol version 6, which provides most of the new features
we want to update generic EC firmware.
Note that this matches chip/g version as of commit 0e5497db6,
plus the following uncommited chip/g patches (CL:458364):
c73af7dd2 chip/g/upgrade: Clarify pdu/frame terminology
baea0a8c7 chip/g/upgrade: Rename SIGNED_TRANSFER_SIZE to UPDATE_PDU_SIZE
d6e41b75c chip/g/upgrade: Remove cr50-specific upgrade subclass and
protocol
3dc0b9a25 chip/g/upgrade: Rename upgrade to update
13436f9b9 chip/g/upgrade: Split rdpu initialization to a separate function
fab9a0936 chip/g/upgrade: Minor formatting fixups
8161ef7c0 chip/g/upgrade: Fix valid_transfer_start logic
bd6d79434 chip/g/upgrade: Fix logic for short USB packets within frames
b09e252ed chip/g/upgrade: Improve error handling
Then:
diff -u include/update_fw.h chip/g/upgrade_fw.h
diff -u common/usb_update.c chip/g/usb_upgrade.c
diff -u common/update_fw.c chip/g/upgrade_fw.c
Only shows chip/g specific differences.
BRANCH=none
BUG=b:36375666
BUG=b:35587171
TEST=make buildall -j
TEST=Can update hammer over USB using usb_updater2
Change-Id: I5b0f0281d844972dab572955d5495f808127e523
Reviewed-on: https://chromium-review.googlesource.com/458321
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
1. PD vender suggests to use chip default address setting (0x16).
2. Clean up board_print_tcpc_fw version function and related define.
BRANCH=None
BUG=None
TEST=Plug in type-c device and check behavior
Change-Id: I44b7156c914b8de67630696e4534147cc3b7f2c3
Reviewed-on: https://chromium-review.googlesource.com/469449
Commit-Ready: Lin Cloud <cloud_lin@compal.com>
Tested-by: Lin Cloud <cloud_lin@compal.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
(Optionally) split rwsig verification into a separate task. This
allows us to initialize other components (e.g. USB) while the
verification is in progress, speeding up the boot process to active
USB in RO case.
After CONFIG_RWSIG_JUMP_TIMEOUT, the EC will jump to the RW section
if no action is taken by the AP (such as a forced request to jump
to RW, or starting an update).
Note: This comes with a ~36ms boot time regression, as other code
gets to run before verification starts.
BRANCH=none
BUG=b:35587171
TEST=Flash, board boots to RW after 1s
TEST=Change jump timeout to 5s, add 5s delay in check_signature,
add console command to manually abort/continue rwsig verification.
'rwsig continue' works => Board jumps to RW after check_signature
is completed (or immediately while waiting for timeout)
'rwsig abort' works => Board does not jump to RW.
Change-Id: Ica5732b9298bb4d3b743cae2ba78df259db915ef
Reviewed-on: https://chromium-review.googlesource.com/468709
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This is done at RO stage. If the rollback region is unprotected, update
it to match the version in the RW image.
If the rollback region is protected, we can't do that update, so we wait
for RW to unlock that region (presumably after AP has verified that image
is somewhat functional) before updating it.
BRANCH=none
BUG=b:35586219
TEST=flashwp true; reboot => hammer reboots twice
flashinfo shows RO+rollback protected:
Flags: wp_gpio_asserted ro_at_boot ro_now rollback_at_boot rollback_now
Protected now:
YYYYYYYY YYYYYYYY Y....... ........
TEST=Hack version.c to add "+1" to rollback_version, check that RO updates
ROLLBACK info block on first boot.
TEST=Use hack above, convert rwsig to separate task, add 5000 ms delay in
rwsig just before rollback information is updated. Then:
Quickly type: flashwp true; reboot; flashwp all; reboot
=> Wait for system to jump to RW
rollbackinfo => minimum version 0
flashwp norb; reboot; wait for jump to RW
rollbackinfo => minimum version 1
Change-Id: I78e502315c611c5edaf34b8d70a12fedd3e57bdf
Reviewed-on: https://chromium-review.googlesource.com/452816
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Follow-up to CL:456520, addressing a few more comments.
BRANCH=none
BUG=b:35775099
TEST=sysrq available in EC console
TEST=sysrq h => help message in AP console
TEST=sysrq b => AP reboots
Change-Id: I692afa7c911882f00d92b8e6d83889c52821e171
Reviewed-on: https://chromium-review.googlesource.com/468506
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Implement actual rollback protection. First, we add a new field
in the version structure, which is an incrementing integer
(we'll start by shipping images with version 0, and gradually
increase the number as required). This allows us to release
new versions of the EC without necessarily bumping the rollback
protection.
For the rollback protection block itself, it contains 2 sub-blocks
of equal size (normally, 2k), that are individually erasable.
The rollback code looks at both, and takes the most restrictive one
to determine the desired rollback minimum version. The blocks
are also allowed to be erased (full of 1's), in which case the
rollback minimum version is assumed to be 0.
We also add an FMAP entry, in case we later decide to allow the
signer to increment the rollback version.
Also note that, like any version_data struct change, this change
breaks compatibility between old and new RO/RW.
Follow-up code will take care of auto-updating the rollback block
as required, and properly manage block protection.
BRANCH=none
BUG=b:35586219
TEST=Flash hammer
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
rollbackupdate 2, 3, 4; rollbackinfo => Writes alternate
between the 2 blocks.
rollbackupdate 2 => Refuses to downgrade version
Change-Id: Ia969afb481a93deb912b9153bdd95ace01ad8fa7
Reviewed-on: https://chromium-review.googlesource.com/452815
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
On keyboard-less design, we will implement a special debug mode,
based on button sequences, to transmit sysrq events to the AP.
This implements the new MKBP event to send sysrq, and a console
command to test it. Later CL will implement debug mode itself.
BRANCH=none
BUG=b:35775099
TEST=sysrq available in EC console
TEST=sysrq h => help message in AP console
TEST=sysrq b => AP reboots
Change-Id: I71d3f77497baf8cc7fac65cd040ce20513b507bc
Reviewed-on: https://chromium-review.googlesource.com/456520
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
The pstate structure is written using the low-level
flash_physical_write() function. As a consequence, it is supposed to
meet the CONFIG_FLASH_WRITE_SIZE alignment constraint.
Add a build-time assertion to avoid silent failures.
Slightly decrease the maximum size of the serial number string, so the
structure has a natural 32-byte alignment which is compatible with a
large number of platforms (including STM32L4 which requires 64-bit
alignment).
Of course, this change is not fully backward-compatible.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chromium:571477 b:35648258
TEST=on STM32L442, build and run 'flashrom --wp-enable' without failure.
Change-Id: Ia8f82790a61a6c7d2cf9bfeb95bfdaf7b8c52d11
Reviewed-on: https://chromium-review.googlesource.com/458201
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Setting PWM IO type in gpio driver seems not a proper way. This
CL moves this functionality to pwm driver and introduces a new
flag PWM_CONFIG_OPEN_DRAIN to achieve it when user declared it
in board driver.
BRANCH=none
BUG=none
TEST=test pwm functionality on npcx_evb.
Change-Id: I90c60445d1fb10902244ddf0f635d8304e72f4ab
Signed-off-by: Mulin Chao <mlchao@nuvoton.com>
Reviewed-on: https://chromium-review.googlesource.com/458043
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The upcoming move of the Cr50 firmware update to the background
requires postponing the activation of the newly uploaded Cr50 image to
a later point in time, when the AP is ready to switch to start using
the new Cr50 image.
The suggested way of achieving it is as follows: when downloading the
new image, the current Cr50 code modifies the header's 'image_size'
field, setting its top bit to 1. This both makes the size invalid and
guarantees that the new image would not verify on the following Cr50
restarts.
When the AP is ready to switch to running the new Cr50 image, it will
send a vendor command, which would trigger the currently running Cr50
image to restore the other image's size field. This vendor command
would also communicate the timeout for the Cr50 to wait before
rebooting, if there has been at least one header (ro or rw) restored.
Rebooting the Cr50 would trigger rebooting the AP, resulting in the
entire system running the updated firmware.
Response sent to the AP will indicate if there has been a header
restored and the reboot is indeed upcoming, this would allow the AP to
quiesce the state of the device to handle the reboot gracefully.
BRANCH=cr50
BUG=b:35580805
TEST=with the rest of the patches applied observed the system properly
after the new header version was restored.
Change-Id: Ia1edee67b6aa8f458810d5dc2931477cfaab1566
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/457676
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
PS8751 does not restore all register contents when resuming
from low power mode. This change makes tcpm call board_init
when it stops auto-toggling so that register contents can be
restored.
BUG=b:35585399
BRACH=none
TEST=On Snappy, the board_init funciton is called every time a device
is plugged in and register contents are restored.
Change-Id: I50c51334f43c02e3c4d8453e1e966bf6eb3ce769
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/454139
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Let's split the usb headers in 3 different parts, instead of having
usb_descriptor.h pull in usb_hw.h and usb_api.h.
- usb_api.h: EC functions related to usb (e.g. connect/disconnect)
- usb_descriptor.h: common USB names and structures
- usb_hw.h: Functions required for interactive with EC's USB HW
BRANCH=none
BUG=b:35587171
TEST=make buildall -j
Change-Id: I37ead61e3be5e7ae464f1c9137cf02eaab0ff92e
Reviewed-on: https://chromium-review.googlesource.com/454861
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Store our image size (known at build time) in our version struct (now
renamed to image_data). This will allow us to more efficiently determine
the size of an image in a follow-up CL.
Note that compatibility is broken for old ROs that do not include this
CL.
BUG=chromium:577915
TEST=Verify on kevin + lars + lars_pd that stored image size matches
output of system_get_image_used() for both RO and RW images.
BRANCH=None
Change-Id: I7b8dc3ac8cf2df3184d0701a0e0ec8032de8d81b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/450858
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add LED types for left and right so they can be addressed
properly with ectool.
BUG=b:36150361
BRANCH=none
TEST=manual testing of 'ectool led <left|right> <color>' behavior
Change-Id: Iea25cc69db2d35416e787dcb5a324d2e2cf5d3a6
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/453126
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Extend the SPI master API to be able to do fancier transactions:
- allow to read the incoming bits while transmitting.
If SPI_READBACK_ALL is set in 'rxlen' when calling spi_transaction(),
then the received data during transmission is recorded in rxdata buffer
and the function assumes that the real 'rxlen' is equal to 'txlen'.
- add spi_transaction_wait() which is similar to spi_transaction_flush()
but without de-asserting the chip select, so we can chain several
transfers in a single transaction.
Implement them for STM32.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=b:35648259
TEST=on Eve, use the FP sensor with the passthru.
Change-Id: Iebff617acd3230277d36a4f565766b7748721a1d
Reviewed-on: https://chromium-review.googlesource.com/452898
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Todd Broch <tbroch@chromium.org>
Without this include, the `watchdog_reload()` function will be compiled
as a noop unless "config.h" is included before "watchdog.h" in whatever
compilation unit requires watchdog functionality.
BUG=none
BRANCH=none
TEST=make buildall -j
Change-Id: I311019753f6d61890be1e475664bd528e5250729
Reviewed-on: https://chromium-review.googlesource.com/449694
Commit-Ready: Jeff Andersen <jeffandersen@google.com>
Tested-by: Jeff Andersen <jeffandersen@google.com>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Allow the board to override the hardcoded 97% value for reporting to
the host (and controlling LED behavior) when the battery is "near full".
When enabling "discharge on ac" with a full battery the battery stops
taking a charge until it reaches ~94% SOC (the actual value is not set
but rather comes from a smart battery status bit) but the user will see
the device as discharging between 97% and 94%.
The host side view can be worked around with a powerd preference.
The LED behavior is all inside the EC, so you end up with the LED showing
discharging when it should not.
If we allow the board to override this to 94% then the LED and host
behavior is consistent.
BUG=b:36024657
BRANCH=none
TEST=make -j buildall
Change-Id: Ie5ab8e41b87101e201073276bf441e25be7daca4
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/450949
Reviewed-by: Scott Collyer <scollyer@chromium.org>
This is required so that the kernel can enable/disable remote wake-up
capabilities, and in particular for the kernel to enable autosuspend.
Also, properly implement GET_STATUS.
BRANCH=none
BUG=b:35579996
TEST=echo auto > /sys/bus/usb/drivers/usb/X-Y/power/control, device
autosuspends after 2 seconds, and wakes on keypress.
Note that this introduces other bugs, where keys are missing,
repeated, see b/35775048.
Change-Id: I7ddd257ac3877d27fb2da813f20583a614a0169b
Reviewed-on: https://chromium-review.googlesource.com/450826
Commit-Ready: Nicolas Boichat <drinkcat@chromium.org>
Tested-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
pdcontrol suspend command will be used to prevent tcpm from putting
the chip into sleep while firmware update is taking place. Currently
the command suspends or resumes port 0. This patch makes the command
apply to ports individually.
pd enable console command now takes a port number:
pd <port> enable/disable.
This patch also replaces CONFIG_USB_PD_COMM_ENABLED with _DISABLED.
When it's defined, PD communication is disabled at startup.
Plankton undefines CONFIG_USB_PD_COMM_ENABLED enable, intending to
disable PD communication at startup. Therefore, this patch defines
CONFIG_USB_PD_COMM_DISABLED in its board.h.
BUG=b:35586859
BRANCH=none
TEST=From AP console:
localhost # /tmp/ectool pdcontrol suspend 1
[600.188013 TCPC p1 suspended!]
> pd 1 state
Port C1 CC1, Dis - Role: SNK-UFP State: SUSPENDED, Flags: 0x0020
localhost # /tmp/ectool pdcontrol resume 1
[678.516613 TCPC p1 resumed!]
> pd 1 state
Port C1 CC1, Ena - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
From ec console:
> pd 1 disable
Port C1 disable
> pd 1 state
Port C1 CC1, Dis - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
> pd 1 enable
Port C1 enabled
> pd 1 state
Port C1 CC1, Ena - Role: SNK-UFP State: DRP_AUTO_TOGGLE, Flags: 0x0020
Change-Id: Ia0cc4904ac52adc4b89de20918968c8df78b9c80
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/447968
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Using -O3 optimization level rather than -Os results in a large speed-up
for a minor code size increase for the RSA code with our current GCC
toolchain.
Add the CONFIG_RSA_OPTIMIZED option to do it on platforms which are not
too size-constrained.
On cortex-M4 based STM32L432, I'm measuring a 37 to 40% speed increase
(depending on CPU frequency) for a 200 bytes code size delta.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=none
TEST=manual: benchmark RSA2048 with F4 exponent on STM32L432:
-Os -O3
@16Mhz 185163 us --> 111942 us
@80Mhz 39286 us --> 24582 us
Change-Id: I8c2e4b757f037f4f645fb73ba0faaaa471b24896
Reviewed-on: https://chromium-review.googlesource.com/445218
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
When battery is fully charged, Reef starts discharging to protect
battery and starts charging again when charge level goes down
around 95%. To prevent the battery LED from showing blue with the
charger plugged in, this patch adds a new state for discharge +
nearly full. Reef shows a color indicating battery is full if
an external charger is present.
BUG=b:35775017
BRANCH=none
TEST=Fully charge Electro. Plug in OEM charger. LED lights blue.
Change-Id: I4c7c62f2c51c1d39188d1b271331984e89d5d7a3
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/448961
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
