Modify usbpdpower HC return args by adding a new current limit
field, and adding a new charger type (UNKNOWN). Note this
doesn't change the size of the return struct.
BUG=chrome-os-partner:38548
BRANCH=samus
TEST=make -j buildall
Change-Id: I51bb062a7e4fcd9ae6aea15204adb83b19882ac9
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264641
Reviewed-by: Sameer Nanda <snanda@chromium.org>
This replaces a special-purpose python script with futility, to
sign the firmware for those boards that require a signed RW image
instead of using software sync.
Currently, the only boards that do that use a signature scheme
that is somewhat opaque (refer to commit b5a439241f in the
vboot_reference repo for details). Futility calls that scheme
"--type usbpd1".
BUG=chromium:231574
BRANCH=ToT
CQ-DEPEND=CL:*212135
TEST=manual
To test, I obtained a reworked zinger that could be connected to
servo. I first flashed it with a dev-key-signed RO+RW image built
prior to this CL, then I applied this change, built a new image
(with a minor change to the startup message), and updated only
the RW half from Samus using
ectool --name=cros_pd flashpd 0 1 /mnt/stateful_partition/ec.RW.bin
Watching the zinger console when plugging and unplugging, I
confirmed that the RO firmware was still the original and the
verified-by-RO RW firmware was the new version.
Note: I also had to build a custom AP kernel without the cros_pd
driver, to prevent interference with the manual update.
Change-Id: I22d8e75c85dab7701af8fe98287f14ebe77dbbd4
Signed-off-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264508
Reviewed-by: Mike Frysinger <vapier@chromium.org>
I2C ports initialized as per board design. Modules
assigned to its corresponding I2C port numbers
Altered the SPI flash size to match the Braswell Ref Design board
BUG=None
BRANCH=None
TEST=Tested all I2C modules on all ports using i2cscan and i2cxfer
console commands
Change-Id: I4158c1aeb29193b5bd07450ba28cdcdc2413926a
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/264261
Reviewed-by: Shawn N <shawnn@chromium.org>
Create a USB PD device whitelist for allowing charging by default
from dual-role devices that don't set the externally powered bit.
BUG=chrome-os-partner:38785
BRANCH=samus
TEST=modify zinger and modify VID and PID to match white-listed
entry. also modify zinger to remove externally powered bit and
set dual-role power bits so that we treat as a dual-role device
by default. when you plug in this modified zinger into samus,
it still will not charge because the VID and PID are obtained
after deciding to treat it as dual-role, but when you issue
soft reset "pd 1 soft", it starts charging. the white-listed
device will always ask for a power swap if it is a sink, so
we will always get source cap after learning the VID/PID, which
should correctly trigger changing the device to be treated as
a dedicated charger.
Change-Id: Ibe7ec57f842a0b9bfb02447baf5b3327217a9516
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/264015
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Treat externally powered dualrole devices as dedicated chargers.
This allows us to default to consuming power from externally powered
dualrole devices and cancels a charger override when one is attached.
BUG=chrome-os-partner:38785
BRANCH=samus
TEST=tested with third-party dualrole device that can be externally
powered.
also tested with another samus that was hard-coded with externally
powered bit set, and deleted it's policy for power swapping. when
this externally-powered samus is plugged into a samus running this CL,
we always charge from the externally-powered samus.
Change-Id: I850eba668e86d311d9353aa3881fc3a518409630
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263331
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When shutting down the MAX77620 PMIC by asseting its SHDN pin, the
EN_PP3300 output of the PMIC (GPIO3) is not going off keeping the PP3300
rail up. Workaround that issue by removing the pull-up on EN_PP3300 when
we assert SHDN.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38689
TEST=on a P5 board, type "apshutdown" and see the power state machine
going to S5, type "powerbtn" and see it going back to S0.
Change-Id: I0e5fba6da118d931b07fff58088604ee00a6bcdd
Reviewed-on: https://chromium-review.googlesource.com/263958
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Change sink capabilities to account for +/-5% voltage inaccuracy
for variable and battery PDOs.
BUG=none
BRANCH=samus
TEST=test with third party variable power supply and make sure it
see's our sink capabilities as 4.75V-21V.
Change-Id: Id793142c486dfc908c81c4894b2ec48f99c868f4
Signed-off-by: Alec Berg <alecaberg@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/263295
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a USB device driver for the Synopsys DWC USB device controller.
The common USB protocol stack code still need to be de-duplicated with
the STM32 implementation.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:33919
TEST=plug Cr50 to a Linux workstation and see USB descriptors using
"lsusb -v -d 18d1:5014"
Change-Id: I4a367241053de2c2d94aa06f82ea4bee51f9f89a
Reviewed-on: https://chromium-review.googlesource.com/231160
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Update EC board configuration for P5 boards :
- PMIC_THERM_L GPIO used for PMIC shutdown has moved.
- add 5V regulator control (used for VBUS only)
- the Type-C superspeed muxes control changed
- add a temporary pull-up on EN_PP3300
- add new FW_DEBUG_MODE GPIO
Try to be compatible with both P4 and P5 by detecting the board variant at
runtime.
At EC startup, USBC_SS1_USB_MODE_L/USBC_SS2_USB_MODE_L/USBC_SS_EN_L (aka
PD3/PD9/PE0 aka MUX_CONF0/1/2) now default to low level rather than high
(as the new default value on P5), but they are reset to the correct
value when initializing the PD task (high for P4, low for P5+).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38330
TEST=Ran on P4, check board ID on P5 PCB.
Change-Id: Ie9010805a91362c2b4d5eddd825d452d6ccc5b28
Reviewed-on: https://chromium-review.googlesource.com/262310
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Setting up numbers for Battery info like input current limit,
Battery voltage, temperature limits as per the actual battery spec.
BUG=None
TEST=Tested on Braswell Ref Design
BRANCH=None
Change-Id: I66c3dfe6166d03d2cb79d80a887168f08753d22d
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/260631
Reviewed-by: Randall Spangler <rspangler@chromium.org>
I2C Block reads were split into two i2c_xfer() calls. However, i2c_xfer() implementation for MEC
does not maintain state in between calls. This was causing block read failures because the
settings for the Control Register got corrupted. Fix this by calling i2c_xfer() only once. This
retrieves both string size and string. Only return the string back to the user.
BUG=None
TEST=Tested on Braswell Ref Design
BRANCH=None
Change-Id: Ife8fcb66425c6198d0dcf10f74e89c001ccac49a
Signed-off-by: Shamile Khan <shamile.khan@intel.com>
Signed-off-by: Divya Jyothi <divya.jyothi@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/260627
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The 'lightbar params' v1 command has a parameter list that exceeds 120 bytes,
which will not work over i2c. Therefore, I created a params v2 command which
breaks up the existing parameters into logical groups which are less than 120
bytes.
TEST=Tested new lightbar params2 command and ran get/sets on all groups for
samus. Repeated test on ryu as well.
BUG=chromium:467716
BRANCH=none
Change-Id: If0fa92e9a2f373b20257f8ce7eb66b7836d9ac60
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/263106
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Clear curr.batt_is_charging when the battery is not present.
Add a new batt_was_removed flag to track when the battery has been
removed. This causes PWR_STATE_ERROR so the LED shows error state,
and triggers re-reading the static parameters from the battery when
it's reattached.
BUG=chrome-os-partner:38235
TEST=check the LED state on mighty
BRANCH=veyron
Change-Id: I400c22eda4bc0043adf7217166bd9f80c557d991
Signed-off-by: ZhengShunQian <zhengsq@rock-chips.com>
Signed-off-by: Randall Spangler <rspangler@chromium.org>
Signed-off-by: Doug Anderson <dianders@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262007
Commit-Queue: Gediminas Ramanauskas <gedis@chromium.org>
Tested-by: Gediminas Ramanauskas <gedis@chromium.org>
(cherry picked from commit 6727e1dba2aafa81fa9572145413545106ae9626)
Reviewed-on: https://chromium-review.googlesource.com/262140
Not needed with kernel fix:
Commands are currenly limited to 252 bytes. Even if EC support protocol
v3, ectool would only limit the command sizes, never go beyond 252
bytes.
This reverts commit be0bd9b835.
It also remove a TODO.
CQ-DEPEND=CL:262870
TEST=With proper kernel, and firmware supporting commands > 252 bytes,
check that ectool console does not crash anymore.
/usr/sbin/ectool --name cros_sh console
returns more character than before.
Check ectool version as well.
/usr/sbin/ectool --name cros_sh version
BUG=chromium:399057,chromium:454324,chrome-os-partner:31989,chrome-os-partner:23823
BRANCH=none
Change-Id: I058ab0e6df96196a0fae186d1ffedcfa16e5dc3b
Signed-off-by: Gwendal Grignou <gwendal@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262885
Reviewed-by: Puthikorn Voravootivat <puthik@chromium.org>
- Updated arguments to support two sub commands:
- check: check if AC adapter is connect.
- update: trigger battery firmware update.
- All Delay values are from .cfg file.
BUG=chrome-os-partner:36310
BRANCH=none
CQ-DEPEND=CL:260868
TEST=Verified on Glimmer.
crosh> battery_firmware check
crosh> battery_firmware update
Change-Id: I7324e1f329383cf5ee62660f4ac4cb0b1c30c056
Signed-off-by: Sheng-Liang Song <ssl@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/260210
Reviewed-by: Shawn N <shawnn@chromium.org>
We're moving the hardcoded check lists out of the pre-upload script.
BUG=chromium:466264
TEST=uploading a CL w/out a branch line is rejected
BRANCH=None
Change-Id: Ifa0f8c3b4be6a20355babb6f9d8896ac8d1fb2be
Signed-off-by: Mike Frysinger <vapier@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262490
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Contrary to the BQ2751 and BQ27741 it is sharing code with, BQ27742 does
not have a "device name" register. So we need to skip the I2C reads else
the battery_device_name() function returns an I2C error and the charge
code retries until the end-of-time to read it hogging the CPU.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38401
TEST=run on Ryu P4 and verify that we are no longer seeing 20ms of I2C
transactions every 100ms on the battery I2C bus.
Change-Id: I961af54017f661ee928058b346a42b7206ad8217
Reviewed-on: https://chromium-review.googlesource.com/262449
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
When calling problem() with 0 as value, it's never printed on the EC
console since the problem() function is de-duplicating the messages by
checking against the last value (which is initialized at zero).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:38401
TEST=run on the current Ryu code (which has a faulty BQ27742 driver) and
see the "charge problem: static update [...]" message.
Change-Id: Iedfbc95e3751bc5b22452187b404a09b633160d7
Reviewed-on: https://chromium-review.googlesource.com/262448
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Alec Berg <alecaberg@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Some platforms are unable to access the 900h-9ffh region over LPC and
must instead access memmap data through the ACPI CMD / DATA ports. To
avoid racing with data updates, disallow changes to multi-byte memmap
data while in burst mode.
Linux currently enables burst mode when accessing multi-byte data and
disables it immediately afterward, though the ACPI spec defines burst mode
in a more general way.
BUG=chrome-os-partner:38224
TEST=Manual on Samus. Undefine LPC_MEMMAP and modify asl to move memmap
data to ERAM at offset 0x20. Verify system boots cleanly and battery
status is updated immediately on plug / unplug.
BRANCH=None
Change-Id: Ib848bdb491fdfece96ad0cee7a44ba85b4a1a50b
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/262072
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@chromium.org>
This required changing the USB-SPI implementation slightly
so that all work is done within the deferred callback. In
particular, this allows the board specific enable and disable
functions to do things that can only be done from a task
context, like sleeping.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=make buildall -j
Change-Id: I3f6a01ed9d6f31a3259ba0a0f6b4e123d6d2e718
Reviewed-on: https://chromium-review.googlesource.com/260964
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
Previously we defined separate functions to map registers to protect
ranges for each supported SPI ROM. This change instead adds a protect range
table + flags for each supported SPI ROM and adds common functions for
translation between ranges + registers. This makes supporting new parts
easier. Since we will never use most supported protection ranges, we can
even simplfy the tables.
The implementation is now similar to flashrom.
BUG=chrome-os-partner:37688
TEST=Manual on Glower.
flashwp disable + spi_flash_rsr --> 0
flashinfo --> shows no protection
spi_flash_prot 0 0x10000 + spi_flash_rsr --> 0x24
flashinfo --> shows 64KB protected
spi_flash_prot 0 0x20000 + spi_flash_rsr --> 0x28
flashinfo --> shows all 96KB protected
spi_flash_prot 0 0x40000 + spi_flash_rsr --> 0x2c
spi_flash_prot 0 0x80000 + spi_flash_rsr --> 0x10
spi_flash_prot 0 0 + spi_flash_rsr --> 0x00
spi_flash_prot 0 0x1000 --> error
spi_flash_prot 0x10000 0x10000 --> error
BRANCH=None
Change-Id: Ie5908ce687b7ff207b09794c7b001a4fbd9e0f5a
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/259310
Reviewed-by: Randall Spangler <rspangler@chromium.org>
This udev rule creates a directory in /dev/google for each
device attached. The name of the directory is unique to the
device and is prefixed with the device product name. Within
the directory there is a serial directory that contains
symlinks to each USB serial port exposed by the device. The
symlinks are named based on the USB interface name provided
by the EC. Additional subdirectories can be added for I2C,
JTAG, GPIOs, and SPI as needed.
Signed-off-by: Anton Staaf <robotboy@chromium.org>
BRANCH=None
BUG=None
TEST=Verify that two different CCD devices generate uniquely named
entries.
Change-Id: I7e6f2ace29b7302c7c072bcf6aab7c8f060b993a
Reviewed-on: https://chromium-review.googlesource.com/260420
Trybot-Ready: Anton Staaf <robotboy@chromium.org>
Tested-by: Anton Staaf <robotboy@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Anton Staaf <robotboy@chromium.org>
On hard reset / hibernate, RAM will be erased and panic data will
normally be lost. When software panic data saving is enabled, try to
save this data just before hard reset and restore it when we come back
up.
BUG=chrome-os-partner:37380
TEST=Manual on Samus with WP + SW sync enabled. Boot AP, then run "crash
divzero" on console. After hard reset, verify that "panicinfo" dumps
data and shows divzero exception code.
BRANCH=Samus
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I9516dd4b6db12ef35e512cc4710f9b97d7e663cb
Reviewed-on: https://chromium-review.googlesource.com/255912
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The ioctl return status for CROS_EC_DEV_IOCXCMD is inconsistent across
kernel versions:
- In 3.8 kernel, on INVALID_VERSION EC result, -EBADMSG is returned
- In 3.14 kernel, on INVALID_VERSION EC result, success status is
returned
In both cases, the INVALID_VERSION result is written to the
cros_ec_command.result parameter.
The inconsistency here should be fixed with kernel patches. In any case,
there is little harm with trying v0 of GET_VERSIONS on any failure of the v1
command.
BUG=chrome-os-partner:37668,chromium:466896
TEST=Manual on peppy. Verify 'ectool thermalget 0 0' prints threshold info.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ic1eb3f8f2fa95711ec15a5afb740af8f18b88b55
Reviewed-on: https://chromium-review.googlesource.com/260004
Reviewed-by: Bill Richardson <wfrichar@chromium.org>
Commit-Queue: Bill Richardson <wfrichar@chromium.org>
Trybot-Ready: Bill Richardson <wfrichar@chromium.org>
Tested-by: Bill Richardson <wfrichar@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Add the proper checks to be able to compile source-only PD devices with
the common runtime.
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=none
BUG=chrome-os-partner:37078
TEST=make buildall
build honeybuns without CONFIG_USB_PD_DUAL_ROLE defined
Change-Id: I7ad0b39b2e62736117ec2d7b5163502afbf14786
Reviewed-on: https://chromium-review.googlesource.com/259112
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
The Rp resistor on CC1 is set for a 3.0A capability,
so Vnc (no-connection voltage) is 2.45 V.
CC2 is not connected (captive cable), so for a PD source, it's identical
to being always pulled-up to 3.3V (no sink connection).
Signed-off-by: Vincent Palatin <vpalatin@chromium.org>
BRANCH=samus
BUG=chrome-os-partner:37078
TEST=connect to Samus and see PD activity
Change-Id: I8df0561cea59896d65d9be6523d4eed953851129
Reviewed-on: https://chromium-review.googlesource.com/259301
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
Reviewed-by: Scott Collyer <scollyer@chromium.org>
Commit-Queue: Vincent Palatin <vpalatin@chromium.org>
Modified version of /board/fruitpie.
Attempted to capture GPIO definitions. Other changes
consisted of modifying functions to enable compilation.
No real functionality as of yet.
TEST=Serial console and I2C functions have been verified
BUG=chrome-os-partner:37078
BRANCH=samus
Change-Id: Iedfc724a058e4220176193ef0f66e5bf45eabbd9
Signed-off-by: Scott <scollyer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/252426
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Trybot-Ready: Vincent Palatin <vpalatin@chromium.org>
Tested-by: Vincent Palatin <vpalatin@chromium.org>
W25X40 uses a different protection register encoding than our existing
W25Q64 code. Move the SPI ROM option to a config, and add support for
the new part.
BUG=chrome-os-partner:37688
TEST=`make buildall -j`. W25X40 protection code tested in a subsequent
commit.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Iaaeabf42c6c62c20debc91afd2cf8671c14244c8
Reviewed-on: https://chromium-review.googlesource.com/258440
Reviewed-by: Randall Spangler <rspangler@chromium.org>
