On hammer, we do not need the console channels, so we can just
disable them to save flash size.
BRANCH=poppy
BUG=b:35647963
TEST=make newsizes, staff image size shrinks by 704 bytes
Change-Id: I7a493ae57573814b166d45e57f1ad3d885f26086
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1070949
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This makes it easier to add params or flags for vendor commands
without changing all of the command handlers. It also reduces code
size by 56 bytes.
For now, existing command handlers continue to use
DECLARE_VENDOR_COMMAND(). Added DECLARE_VENDOR_COMMAND_P() for
handlers which take the params struct directly. The CCD command will
be the first user of that, since it will have different rules for
'open' based on where the command comes from.
No change to existing command behavior.
BUG=b:79983505
BRANCH=cr50
TEST=gsctool -I still works
Change-Id: I7ed288a9c45e381162e246b50ae88cf76e67490d
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1069538
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Previously, calls to tpm_alt_extension() were treated as if they came
from the AP via the TPM interface, even though they actually
originated from the cr50 console, which is accessible via the USB
interface.
This affects the following console commands:
spi_hash - was already allowed as both a safe console command and via
the USB vendor command interface. No change.
rma_auth - was allowed as a safe console command, but not via the USB
vendor command interface. Now allowed from both. No change in
security, since anyone could already do it via the console.
Unfortunately, getting a challenge fails because commands issued via
the USB vendor command interface have a maximum payload of 32 bytes
and the challenge is bigger than that; that's tracked in b:80098603.
ccd - was already allowed as a safe console command. This directly
called ccd_command_wrapper() for lock, open, and password subcommands.
It made an extra check for password set for the unlock subcommand.
Moved the unlock check to the vendor command handler. Also changed
the order of checks so that FWMP disabling unlock and open supersedes
an existing password; this matches go/ccd-open-simple. (That has no
effect on existing systems, because CCD is disabled at a higher
level.)
Reduces code size by 8 bytes.
BUG=b:79983505
BRANCH=cr50
TEST=manual, on a CR50_DEV=1 build
Compile with DEBUG_EXTENSION defined to print extra debug output
'ccd lock' now shows as coming from USB
'ccd unlock' fails because no password is set
'ccd unlock' and 'ccd open' fail if FWMP disallows unlock
'rma_auth' prints a challenge
'gsctool -t -r' prints a challenge from AP root shell
'gsctool -r 12345678' returns error 6 (incorrect challenge), rather
than error 127 (no such command).
'gsctool -I' works from the host
'gsctool -t -I' still works from AP root shell
Change-Id: I2cd1027f5135b9c336df97ee4b1b1a15354728b4
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068102
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
The values of CROS_EC_VERSION and VERSION variables generated by
getversion.sh are exactly the same. VERSION is used in more places
than CROS_EC_VERSION, let's keep VERSION and use it everywhere.
BRANCH=none
BUG=chromium:632937
TEST=make buildall
Change-Id: Ibec9ecdd4b67789a468dddfbc1c82565f90d48a8
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1069330
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Added flags parameter to extension_route_command(). The caller now
specifies whether the command comes from the USB interface or the AP.
Moved USB-specific shuffling of response to embed result code into
usb_upgrade.c, so extension_route_command() can be more generic.
No change to permissions/behavior for existing commands.
ccd_command_wrapper() still sends vendor commands as if they come from
the AP. That's fixed in the next CL.
Reduces code size by 128 bytes
BUG=b:79983505
BRANCH=cr50
TEST=manual
Build with DEBUG_EXTENSION defined, to turn on printing each command
'ccd lock' comes from AP and works
From host, 'gscutil -I' comes from USB and fails
From AP, 'gscutil -t -I' comes from AP and works
Change-Id: I7136bb54073de9c5951a174c308151b1871c56f3
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1068101
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
We have converted all LPC-only configs to HOSTCMD_LPC so the remaining
CONFIG_LPC defines represent the common case.
BRANCH=none
BUG=chromium:818804
TEST=Full stack builds and works on yorp (espi) and grunt (lpc)
Change-Id: Iba9a48f2cab12fadd0d9ab8eab0d5d5476eab238
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1067503
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Break the ec chip code up with the more granular
CONFIG_HOSTCMD_(X86|LPC|ESPI) options.
BRANCH=none
BUG=chromium:818804
TEST=Full stack builds and works on yorp (espi) and grunt (lpc)
Change-Id: Ie272787b2425175fe36b06fcdeeee90ec5ccbe95
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1067502
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Expose the i2c interface through usb so that we can read power rails
through servod leveraging the work being done there.
BRANCH=none
BUG=chromium:806148
TEST=manual testing
- powerlog still works
- i2c over usb using servod code works (other CLs needed)
Change-Id: I48876bc4839509a397ce77376b337c37c556ae40
Signed-off-by: Ruben Rodriguez Buchillon <coconutruben@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1051136
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Previously manual_mode used the current values of voltage/current to
set the desired values for each charge_request() call. Since manual
mode is entered/exited in the host command task, this can easily lead
to a race condition where the charger gets disabled in the host
command task, the reenabled by the charger task. This in turn makes
the ectool chargecontrol idle command unreliable.
This CL replaces manual mode with two variables, manual_voltage and
manual_current. The default values are -1 which means that they are
inactive. When the ectool command 'chargecontrol idle' is executed, it
sets both variables to 0. This then removes the race condition
possibility as each iteration of the charger loop will use
manual_voltage and/or manual_current if not -1.
BRANCH=coral
BUG=b:68364154
TEST=Manual
Executed 'ectool chargecontrol idle' and 'ectool chargecontrol normal'
numerous times and verified that the charging was disabled/resumed
each time as expected. Without this fix the problem could be
reproduced always in less than 10 attempts, typcially less than
5. With this CL charging is disabled reliably each time and I'm not
able to reproduce the problem.
Change-Id: I1ed9cdb42249cdf72ab34dd95b8f42c09d9a490c
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/851419
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Commit-Queue: Scott Collyer <scollyer@chromium.org>
(cherry picked from commit b7254f38979f274acc66330905399ff5ddf4129b)
Reviewed-on: https://chromium-review.googlesource.com/922069
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
When EC sees voltage drops below BAT_LOW_VOLTAGE_THRESH,
we kick off a timer and ask AP to throttle.
When the timer expires which means EC hasn't seen under-voltage
for BAT_UVP_TIMEOUT_US, we ask AP to stop throttling.
We reset the throttling status and do nothing when AP is off (S5).
BUG=b:73050145, chromium:838754
BRANCH=scarlet
TEST=manually test on scarlet, confirm EC sends
EC_HOST_EVENT_THROTTLE_START and EC_HOST_EVENT_THROTTLE_STOP
host events when entering/exiting UVP.
Change-Id: Ia760989f760f95549f7a8a8acb1d01de23feab5a
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1064983
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: David Schneider <dnschneid@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
sleepmask is really useful for debugging sleep issues. Add a read only
version of sleepmask to non-DBG images. It will only be accessible once
the console is unlocked.
BUG=none
BRANCH=cr50
TEST=make sure sleepmask can be modified in DBG images and can only be
read in prod images.
Change-Id: I31ef966f6302d4a7602a014cb08c9b972d13f41e
Signed-off-by: Mary Ruthven <mruthven@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1062804
Commit-Ready: Mary Ruthven <mruthven@chromium.org>
Tested-by: Mary Ruthven <mruthven@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
When the EC is powered solely by the servo, we do not want to try to
start the AP. If we do, we will watchdog reset in a while loop waiting
for the 3300 and 5000 rails to come up (which won't come up if powering
only on the servo)
BRANCH=none
BUG=b:79606767
TEST=powering bip with servo only does not watchdog reset boot loop
Change-Id: I132312f7f08201dc58d797900df16502240ee98c
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1062502
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-by: Vijay Hiremath <vijay.p.hiremath@intel.corp-partner.google.com>
This will be used as part of the checks for when to allow CCD open.
Add check for firmware space dev mode bit, based on the similar code
which reads the FWMP. Print the state of both bits in 'ccd get'.
BUG=b:79983505
BRANCH=cr50
TEST=With dev mode off, 'ccd get' does not report TPM: dev_mode.
Turn on dev mode via the recovery screen, and it does.
Change-Id: I6af78bb104004323cd377ed996e1db94bc36fc62
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1066391
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Observed VBOOT hash failure for EC_RW. Function
spi_flash_read with size > SPI_FLASH_MAX_READ_LEN
is incorrectly incrementing the offset. For example:
0, 0x100, 0x300, 0x600, all with read size = 256.
BUG=
BRANCH=any EC using SPI flash
TEST=Trigger VBOOT hash re-calculation using EC
console hash rw command. Second test program
SPI flash with known test pattern longer than
SPI_FLASH_MAX_READ_LEN and read using EC
console flashread.
Change-Id: I5fda47f132f64b12044b94663a19d889f1c2b32a
Reviewed-on: https://chromium-review.googlesource.com/1036258
Commit-Ready: ChromeOS CL Exonerator Bot <chromiumos-cl-exonerator@appspot.gserviceaccount.com>
Tested-by: Scott Worley <scott.worley@microchip.corp-partner.google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
gcc 8.1 complains about duplicate const, and while some of these really
are duplicate, others look like they were supposed to tighten the API
contract so that variables are "const pointer to const data", but didn't
have that effect.
BUG=b:65441143
BRANCH=none
TEST=building Chrome EC as part of upstream coreboot's build with a
gcc 8.1 compiler now works (better. there are other issues left)
Change-Id: I6016c5f282516471746f08d5714ea07ebdd10331
Signed-off-by: Patrick Georgi <pgeorgi@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1039812
Commit-Ready: Patrick Georgi <pgeorgi@chromium.org>
Tested-by: Patrick Georgi <pgeorgi@chromium.org>
Reviewed-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Make Esc+Refresh+Power on Grunt enter Recovery Mode.
If Power is released fast:
[0.045303 KB init state: -- 02 08 -- -- -- -- -- -- -- -- -- --]
Add CONFIG_KEYBOARD_IGNORE_REFRESH_BOOT_KEY to handle this case.
If Power is held longer:
[0.045448 KB init state: 08 0a 08 08 08 -- 08 -- 08 08 -- 08 08]
Add CONFIG_KEYBOARD_PWRBTN_ASSERTS_KSI3 to handle this case.
BUG=b:79758966
BRANCH=none
TEST=Esc+Refresh+Power gives recovery screen on Grunt
Change-Id: I43a7d485535ff7b0d9bfce59f28c0049ee989818
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1063032
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Daniel Kurtz <djkurtz@chromium.org>
CPRINTS() macro is already adding the newline character, no need to
include it explicitly.
BRANCH=none
BUG=none
TEST=vefied that Coral EC does not print this newline any more
Change-Id: I1f6b1fcb90818a8d4a2d18cf5060669fc46d38a7
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1062588
Reviewed-by: Jett Rink <jettrink@chromium.org>
The decimal converted value for i2c read does not work.
It just happens to work every other time I have seen it.
BUG=none
BRANCH=none
TEST=bip i2cxfer r works
Change-Id: I7d868e3fc79eea081867634b679120f2da6f9363
Signed-off-by: Jett Rink <jettrink@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1060167
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add the FP_CAPTURE_RESET_TEST capture mode to be able to perform the
reset pixel values test.
Update ectool accordingly and also remove the deprecated 'fpcheckpixels'
command.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=poppy
BUG=b:78597564
TEST=run 'ectool --name=cros_fp fpmode capture test_reset',
then 'ectool --name=cros_fp fpframe > test.pnm'
CQ-DEPEND=CL:*626747
Change-Id: I183f33b1cb9ba4db67219b8f7740d29dc0551f2d
Reviewed-on: https://chromium-review.googlesource.com/1061074
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nicolas Boichat <drinkcat@chromium.org>
charge_manager_fill_power_info can be called to fill the power info
of the dedicated port. This function might call
charge_manager_get_source_current with the dedicated port, we don't
want to use assert in that case, but just fail gracefully by returning
0.
BRANCH=None
BUG=chromium:841944
TEST=Check that the function returns 0 for dedicated and not 0 for USB.
Change-Id: I357c056647e01bdb0e77a08a6c6b492aa3dbb503
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-on: https://chromium-review.googlesource.com/1059248
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The charge_prevent_power_on() function checks for battery presence and
its charge level as a condition to prevent AP power on. In order to
deal with the short (up to a few seconds) time window where the fuel
gauge can be read but the discharge FET is not yet enabled, the
status of battery_get_disconnect_state() has been added as a condition
to many board's battery_is_present() function.
The problem with this approach is that the return value of
battery_is_present() is also used by charge_state_v2 as a condition to
force the charge state to ST_IDLE. Then, if the config option
CONFIG_CHARGER_MAINTAIN_VBAT is not defined, the value of requested
current and voltage will be forced to 0 as long as the state remains
in ST_IDLE. When the battery is dead or has been cutoff its discharge
FET will be disabled. In order to for the discharge FET to be enabled
the charger must provide at least a precharge level of current to the
battery. But, if the FET status is used as a condition for
battery_is_present which in turn forces the charge state to ST_IDLE
which can lead to requested_current being forced to 0.
This CL enables a way to remove battery_get_disconnect_state() as a
condition from battery_is_present and instead call
battery_get_disconnect_state() directly in the function
charge_prevent_power_on. Therefore AP power can still be gated by the
battery FET status, but the charge state will not be stuck in ST_IDLE.
This new check is guarded by CONFIG_BATTERY_REVIVE_DISCONNECT. Boards
which currently condition battery_is_present on the value of
battery_get_disconnect_state() don't change at all, but a board which
needs to remove that condition on battery_is_present can still use the
FET check to prevent AP power on.
BUG=b:79133101
BRANCH=none
TEST=Tested on Yorp and verifed that when using either a dead battery
or a battery that had been cutoff, prevent_power_on was set to 1 until
the FET status was correct for the battery to provide power.
Change-Id: Ic27f42610a7b751394b29a013c4dd17030a3df31
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1053095
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
When the EC sends an interrupt to the AP notifying it of new
accelerometer data we need to make sure the spot we record the timestamp
of the event is virtually identical to the spot the AP records the same
point in time.
Therefore a better spot for that is right next to the gpio toggling of
the interrupt line.
BUG=b:67743747
TEST=In the kernel, fifo_info->info.timestamp still has sane values.
TEST=CTS should still pass
BRANCH=master
Change-Id: Ic77101a045123e779f576c46b401c765304976fd
Signed-off-by: Alexandru M Stan <amstan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/802976
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Instead of fetching incoming CEC messages using a specific read
command, extend the standard mkbp event so the CEC message can
be delivered directly inside the event.
Signed-off-by: Stefan Adolfsson <sadolfsson@chromium.org>
BUG=b:76467407
BRANCH=none
TEST="ectool cec read" still working with a kernel that has support
for the increased mkbp size.
CQ-DEPEND=CL:1046186,CL:1051085
Change-Id: Id9d944be86ba85084b979d1df9057f7f3e7a1fd0
Reviewed-on: https://chromium-review.googlesource.com/1051105
Commit-Ready: Stefan Adolfsson <sadolfsson@chromium.org>
Tested-by: Stefan Adolfsson <sadolfsson@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
the EC should not clear the AC_PRESENT flag in the ACPI flags when we
know that we're on a charger. ACPI rules on the AP side do special
things when they see AC_PRESENT off, like forcing the EC to limit the
charge current to 512mA.
BUG=b:78509594
BRANCH=none
TEST=chargestate current no longer stuck at 512mA
Change-Id: I54ddea6d2661a9d6b1593431a5912a8a60db572d
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1050917
Commit-Ready: Caveh Jalali <caveh@google.com>
Tested-by: Caveh Jalali <caveh@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Jett Rink <jettrink@chromium.org>
This patch promotes board/nami/keyboard_backlight.c to common
directory.
Board customization is done via board_kblight_init callback.
It currently supports two drivers: direct PWM control and lm3509.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b:78360907,b:78141647
BRANCH=none
TEST=On Nami (for lm3509) and Sona (pwm), verify the followings:
1. Alt + brightness up/down works
2. After suspend-resume, brightness is restored
3. Lid close/open
4. After screen is off, keyboard backlight is turned off
Change-Id: I584c06e8702fe7b289999698f277311cfd3400bd
Reviewed-on: https://chromium-review.googlesource.com/1051027
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
The kernel is only able to know the number of USB PD port through
EC_CMD_USB_PD_PORTS, but the kernel needs also to be able to know
that there is a dedicated port. Add a host command that will
return the total number of charge port (USB PD + BJ).
BRANCH=None
BUG=chromium:841944
TEST=Called command from kernel driver and checked that the port count
was the expected value.
Change-Id: I6ccd8a2dee35bbe8bb66dfbe09d1cc09c54b73a0
Signed-off-by: Fabien Parent <fparent@baylibre.com>
Reviewed-on: https://chromium-review.googlesource.com/1046593
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
When EC sees discharge current hit BAT_MAX_DISCHG_CURRENT,
we kick off a timer and ask AP to throttle.
Then EC keeps monitoring discharge current. If the current doesn't
drop below BAT_MAX_DISCHG_CURRENT - BAT_OCP_HYSTERESIS, we restart
the timer and notify AP again, which shouldn't happen unless
AP misses or ignores the first notification.
When the timer expires, which means EC hasn't seen over-current
for BAT_OCP_TIMEOUT_US, we ask AP to stop throttling.
BUG=b:74321682, chromium:838754
BRANCH=scarlet
TEST=manually test on scarlet, confirm EC sends
EC_HOST_EVENT_THROTTLE_START and EC_HOST_EVENT_THROTTLE_STOP
host events when entering/exiting OCP.
Change-Id: I1e55fc23249596d8afec52a3885655ca9c1f2151
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/994188
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Matthias Kaehlcke <mka@chromium.org>
This patch adds an interrupt handler for a tablet switch and an init
hook to enable the interrupt.
The handler does the typical tasks for convertible devices: 1. sets
tablet mode then 2. disables peripherals if tablet mode is on.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b:77298177
BRANCH=none
TEST=buildall. Verify on Nami.
Change-Id: If7fb5ea15f388d2b6084d800d2bc05efafd1945e
Reviewed-on: https://chromium-review.googlesource.com/1043057
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This patch refactors motion_lid so that EC can decide to use lid angles
to set tablet mode at run time.
Then, it implements board_is_lid_angle_tablet_mode to enable the feature
for Nami and Vayne.
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
BUG=b:77298177
BRANCH=none
TEST=Verify on Nami.
Change-Id: Ib717911a16fe031aa6c6ede731e6aa722d32d022
Reviewed-on: https://chromium-review.googlesource.com/1024914
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Port 0:
TCPC: ANX3429
PPC: SN5S330
BC1.2: PI3USB9281
Port 1:
TCPC: PS8751
Power switch (sink): NX5P3290
Power switch (source): NX20P5090
BC1.2: PI3USB9281
Charger: ISL9238
BRANCH=none
BUG=b:74395451
TEST=make buildall -j
TEST=Did "gpioset EN_PP5000_A 1" before the folllowing tests:
* Plugged adapter to port-0/port-1/both and saw charging
* Plugged USB device to port-0/port-1/both and saw sourcing VBUS
* Plugged adapter to one port and USB device to another port
* Plugged USB disk to port-0 and booted into kernel
* When AP off, not sourcing VBUS to USB device
* Rebooting AP still works
Change-Id: Icde5e24c2cda3d0f2046486528a210af84befcca
Signed-off-by: Tom Wai-Hong Tam <waihong@google.com>
Reviewed-on: https://chromium-review.googlesource.com/969701
Commit-Ready: Wai-Hong Tam <waihong@google.com>
Tested-by: Wai-Hong Tam <waihong@google.com>
Reviewed-by: Wai-Hong Tam <waihong@google.com>
Update the fingerprint match event to include the index of the template
which matched.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=poppy
BUG=b:77516790
TEST=on ZerbleBarn, enroll 5 fingers and do matching from the console,
see the proper finger index in the trace.
TEST=on Meowth, check unmodified biod still works for match with the
updated MCU firmware.
CQ-DEPEND=CL:*621808
Change-Id: I5be77ba65ce232989606274aba9a6c20841d533c
Reviewed-on: https://chromium-review.googlesource.com/1047267
Commit-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Nicolas Norvez <norvez@chromium.org>
the isl9238 needs to see a higher PPVAR_SYS voltage than we were using
to avoid tripping Low_VSYS. Low_VSYS is one of the terms causing the
isl9238 to assert PROCHOT. its lowest default voltage threshold is
about 6.1v which is too close to the battery "minimum" that we were
using to set PPVAR_SYS. it's better to use the "normal" battery
voltage so the running-on-AC case is similar to the running-on-battery
case.
BUG=b:78911901
BRANCH=none
TEST=examined isl9238 regs to verify it is no longer tripping Low_VSYS
Change-Id: Iafc39e988a5af668c6cc1b5485841f6d659b1e8b
Signed-off-by: Caveh Jalali <caveh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1043456
Commit-Ready: Caveh Jalali <caveh@google.com>
Tested-by: Caveh Jalali <caveh@google.com>
Tested-by: caveh jalali <caveh@chromium.org>
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Caveh Jalali <caveh@google.com>
We add a configuration option to set the minimum shared memory
size (CONFIG_SHAREDMEM_MINIMUM_SIZE), so that the link will fail
if there is not enough IRAM left.
Also, we add 2 macros around shared_mem_acquire, that check, at
build time, that the shared memory size is sufficient for the
allocation:
- SHARED_MEM_ACQUIRE_CHECK should be used instead of
shared_mem_acquire, when size is known in advance.
- SHARED_MEM_CHECK_SIZE should be used when only a maximum size
is known.
This does not account for "jump tags" that boards often add on
jump from RO to RW. Luckily, RW usually does not do verification,
and does not need as much shared memory.
BRANCH=none
BUG=chromium:739771
TEST=make buildall -j, no error
Change-Id: Ic4c72938affe65fe8f8bc17ee5111c1798fc536f
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1002713
Reviewed-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a state to indicate that a data role is actually disconnected and
notify the board-level data swap function with this state when a cable
is unplugged. This allows the board to clean up and restore any state
that may have been set up with a data role swap.
BUG=b:78308749
BRANCH=eve,poppy
TEST=manual on eve: plug in C-to-C cable, execute data swap on port 0
with 'pd 0 swap data' and ensure the OTG pins are asserted. Then unplug
the cable and ensure OTG pins are now deasserted.
Change-Id: I7d8fff22dd5836b4b5af54f0ede71ee1b6e40b5c
Signed-off-by: Duncan Laurie <dlaurie@google.com>
Reviewed-on: https://chromium-review.googlesource.com/1035423
Reviewed-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Furquan Shaikh <furquan@chromium.org>
Normally on lid open, if chipset is off, we pulse the power button
to wake the AP. If we are in PWRBTN_STATE_INIT_ON, then we are already
waiting to power on the AP so ignore the lid open to avoid turning
on the AP too soon.
BUG=b:77455171
BRANCH=none
TEST=Plug power into Grunt with no battery.
Change-Id: Ie57e998725af0ace525f9f2102a0f5a282382a57
Signed-off-by: Edward Hill <ecgh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1031565
Reviewed-by: Simon Glass <sjg@chromium.org>
Reviewed-by: Martin Roth <martinroth@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
In order to be able to recover from the AP and Cr50 getting out of
sync, this logging functionality gives Cr50 a way to track the
state changes of the merkle tree so that the AP can be updated to
the current state as long as it has a recent enough copy.
This involves packing the important information so it can be stored
efficiently on flash, and adding the necessary messages for the
replay.
CQ-DEPEND=CL:895395,CL:929430
BRANCH=none
BUG=chromium:809729, chromium:809745
TEST=cd ~/src/platform/ec && V=1 make run-weaver_ng -j
Change-Id: I40f98de2c8e9706cccb5b922215699f2132fa121
Signed-off-by: Allen Webb <allenwebb@google.com>
Reviewed-on: https://chromium-review.googlesource.com/963773
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This connects the pinweaver code to the tpm vendor
specific command code.
CQ-DEPEND=CL:895395
BRANCH=none
BUG=chromium:809741
TEST=TBD
Change-Id: I2a6c4bf52ad77b7bf0395095404e925e1dd48dbc
Signed-off-by: Allen Webb <allenwebb@google.com>
Reviewed-on: https://chromium-review.googlesource.com/929430
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This adds some of the ground work for hardware backed brute force
resistance on Cr50. The feature is called Pinweaver. It will
initially be used to enable PIN authentication on CrOS devices
without reducing the security of the platform. A Merkle tree is
used to validate encrypted metadata used to track login attempts.
The metadata tracks counts of failed attempts, a timestamp of the
last failed attempt, the secrets, and any associated parameters.
Instead of storing the metadata on Cr50 an AES-CTR is used with an
HMAC to encrypt the data so it can be stored off-chip and loaded
when needed.
The Merkle tree is used to track the current state of all the
metadata to prevent replay attacks of previously exported copies.
It is a tree of hashes whose root hash is stored on Cr50, and whose
leaves are the HMACs of the encrypted metadata.
BRANCH=none
BUG=chromium:809730, chromium:809741, chromium:809743, chromium:809747
TEST=cd ~/src/platform/ec && V=1 make run-pinweaver -j
Change-Id: Id10bb49d8ebc5a487dd90c6093bc0f51dadbd124
Signed-off-by: Allen Webb <allenwebb@google.com>
Reviewed-on: https://chromium-review.googlesource.com/895395
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
Currently, if a board supports dual role power ports, the EC will
briefly apply Rp resistors on the CC lines upon initializing the PD
tasks. This was put in place such that the partner port is a known
state. In the case of an external PD charger, the presence of the Rp
will cause the charger to stop sourcing VBUS. We only apply the pull up
for reset cases where the EC did not just loose power (e.g. power on
reset or brownout).
This however presents a problem when booting off of AC only. If a user
types 'reboot ap-off', there will be an extra reset because VBUS is
dropped and the "ap-off" flag will be lost.
This commit simply checks to see if there is an explicit contract in
place for a port. If an explicit contract is in place and PD
communications are allowed, we will not apply the Rp resistors. The PD
state machine will then attempt to send a SoftReset to the port partner
in order to reset the PD protocol layer. If an explicit contract is not
in place, or if PD communications are not allowed, the Rp's will be
asserted briefly as before.
BUG=b:72838807,b:35587129,chromium:712746
BRANCH=None
TEST=Flash zoombini; Remove battery and plug in just AC; Enter `reboot
ap-off` and verify that AP remains off in the subsequent boot and there
is no extra reset.
TEST=Make zoombini locked. Have a PD contract in RW, reboot to RO and
verify that VBUS is dropped from a PD charger.
TEST=Repeat test on meowth.
CQ-DEPEND=CL:905922
Change-Id: Ie2e3fe5b6b318e166b2a42dfa3241646369ec571
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/905390
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
According to PD spec:
- Data role shall not be reset on soft reset.
- Data role shall be reset to power-role default on hard reset.
Implement the above. Even if both ports follow spec, it's still possible
for a data role conflict to occur if, for example, data role swap occurs
(data role mismatches power role default) followed by a hardware reset
of one port (such that data role gets reset to power role default).
Handle such cases by taking error recovery actions.
BUG=b:71333840,chromium:805040
TEST=Connect scarlet to powered Apple accessory, verify scarlet comes up
in SNK-DFP after soft reset and issuing "reboot" on EC console. After
issuing a hard reset, the port comes up in SNK-UFP (which is the
power-role default).
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Change-Id: I65139f277d59a0612f8323d711080f52425ff5e7
Reviewed-on: https://chromium-review.googlesource.com/885462
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
In order to re-initialize our PD state variables properly following a
reset, we need to save our current power role. This commit adds a bit
in the BBRAM PD flags for the power role.
BUG=b:71333840,chromium:805040
BRANCH=None
TEST=Add code to save data role and restore both roles, verify that both
are saved accordingly.
Change-Id: I156ae8179c8e12c63322132d1f0078990bd215f8
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/979264
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
pd_get/set_saved_active() made the assumption that there were only two
ports. But now, we have a board that turned that port count all the way
up to 3. This commit adds in that new port BBRAM index. It also turns
the byte where the port information was stored into a byte of flags,
where bit 0 indicates whether there was an explicit contract in place or
not.
BUG=b:72838807
BRANCH=None
TEST=With some code to check for explicit contract state for port 2,
verify it's functional.
Change-Id: I6f062f67bd3c47dd43ea7e24e844a9286fa37af9
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/905923
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Jett Rink <jettrink@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
While troubleshooting why a generic $19.99 Multiport (USB, HDMI, Type-C)
Type-C dongle didn't work on Scarlet, I noticed that Vconn Req and Vbus
Req were both set to zero in the AMA VDO. For a better user experience,
default to Vbus ON if both Vconn and Vbus Req are both zero.
BUG=b:78286905
BRANCH=NONE
TEST=manual
Tested the generic dongle with USB-Keyboard, TypeC power adapter,
and HP monitor.
Change-Id: I170eef1372c3621334de2c457bd4533eea744cc0
Signed-off-by: Sam Hurst <shurst@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/1019611
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
