The SET sub-command of EC_CMD_CHARGE_STATE sets charger current /
voltage parameters to arbitrary values and should be locked down.
EC_CMD_CHARGE_CONTROL, on the other hand, switches between several safe
operation modes, and should be allowed.
BUG=None
TEST=On kevin, set force_locked, plug zinger, and verify:
ectool chargestate param 4 3 <-- ACCESS_DENIED
ectool chargestate show <-- prints params
ectool chargecontrol idle <-- stops charging battery
ectool chargecontrol normal <-- battery charges again
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I5503f07bb196d023a9bcd2e33f2e247f061f05e5
Reviewed-on: https://chromium-review.googlesource.com/757237
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Events used when TPM task is running are defined in two different
places, one of them shared with other boards running on H1.
Let's avoid collision by redefining Cr50 only events to be different
from shared ones used by dcrypto.
BRANCH=cr50
BUG=b:68729265
TEST=verified that there is no more 'tpm_reset_request: already
scheduled' messages generated when TPM is reset when performing
long dcrypto operation.
Change-Id: Ic9517fa98be21f3ef5f19b82c593d96b0ddbaf6b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/756914
Reviewed-by: Nagendra Modadugu <ngm@google.com>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
Currently the Cr50 code resets TPM communications layer at a certain
point during TPM reset process.
It turns out that this is not sufficient - the comms layer keeps
receiving and trying to invoke TPM layer, which does not mesh well
with TPM reset.
Let's provide two callbacks for each comms layer - to shut it down and
to bring it back up. We shut down the comms when starting TPM reset
and bring them back up when reset is completed.
BRANCH=cr50
BUG=b:68012381
TEST=ran AP firmware test suite on both SPI and I2C based devices.
Change-Id: I7caf4a09b9a5c6e5fc6bfe60eae1c0d64ab24904
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/754502
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
It's undesirable to do BC1.2 detection on power swap, so add a function
to check if the partner port is known to be PD-capable.
BUG=chromium:780905
BRANCH=gru
TEST=With subsequent CL, attach USB-PD phone capable of role swap.
Verify USB 2.0 device is enumerated on plug, and not re-enumerated
through a series of "pd # swap power" commands on the EC console. Also
verify BC1.2 charging and PD charging are still functional on kevin.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ifa75c94e9758d3e407492bbda6fc52ed7bc378fa
Reviewed-on: https://chromium-review.googlesource.com/755877
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
When allowing an unlocked system to automatically power up we
may attempt to boot before the charger is ready to supply enough
power and get stuck in a reset loop.
In addition, if the batttery is not physically present in the system
then delay power-on until the charger is providing at least 15W of
power. (currently defined as LIKELY_PD_USBC_POWER_MW)
By adding a final check to the charge_prevent_power_on() function
to ensure that charge_manager_get_charger_current() is returning
a valid value instead of CHARGE_CURRENT_UNINITIALIZED then the
board is able to reliably boot.
This CL combines 2 CLs made on Eve which addressed the same problem
I'm seeing on Robo devices.
https://chromium-review.googlesource.com/582545https://chromium-review.googlesource.com/709473
BUG=b:68226308
BRANCH=coral
TEST=Used Robo system which was consistently failing when external
power was connected to Port 1. After adding this change was able to
consistently power up the system without going into a reboot loop. In
addition had signal wires attached to VBUS and VSYS so could verify
that VSYS was no longer collapsing.
Change-Id: Iadecf032feaacfda230bfc98a332cd7963fb0afe
Signed-off-by: Scott Collyer <scollyer@google.com>
Reviewed-on: https://chromium-review.googlesource.com/752755
Commit-Ready: Scott Collyer <scollyer@chromium.org>
Tested-by: Scott Collyer <scollyer@chromium.org>
Reviewed-by: Duncan Laurie <dlaurie@google.com>
Charge port / current selection often needs to be significantly altered
when a battery cannot provide sufficient charge, so have charge_manager
initially enter safe mode. After a battery with sufficient capacity has
been identified, charge manager will leave safe mode, and port / current
selection will return to standard rules.
BUG=chromium:777596
BRANCH=None
TEST=Pass charge_manager unit tests. On kevin, remove battery, attach
Apple PD charger, verify safe mode is not exited and device does not
brown out. Hot-plug battery and verify safe mode is exited. Next,
remove battery, attach to Samus, verify safe mode is not exited and
device doesn't brown out. Hot-plug battery, verify that safe mode is
exited and no active charge port, due to dual-role exclusion.
Change-Id: I7784865750087a037aad8dbbac058b22c77ba6d4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/733954
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Most boards had an identical implementation for this function,
previously known as board_is_consuming_full_charge(). To reduce copy
paste, let's just move it to common code. Boards that charge ramp
without a battery will have to define their own implementation, but
there probably won't be any boards like that in the near future.
BUG=None
BRANCH=None
TEST=make -j buildall
Change-Id: Ic99a378ac26dfd35d7d718bf9376eacfa8609166
Signed-off-by: Aseda Aboagye <aaboagye@google.com>
Reviewed-on: https://chromium-review.googlesource.com/748919
Commit-Ready: Aseda Aboagye <aaboagye@chromium.org>
Tested-by: Aseda Aboagye <aaboagye@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
1. Add a new config option to define history buffer length. This
allows boards to override this option if required.
2. Get rid of unused PORT80_POLL_PERIOD macro
BUG=None
BRANCH=None
TEST=Verified that all port80 messages from a boot-up or S3 resume are
present in port80 history buffer.
Change-Id: Ie64680459f58358713a1b1445a0b99fcfe1c1cdc
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745902
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a common hook handler on CHIPSET_RESUME to log port80 resume
message instead of duplicating the same code in all chip lpc_resume.
BUG=b:68669668
BRANCH=None
TEST=Verified that port80 resume is logged on S0ix and S3 resume.
Change-Id: I313692f5499717d0d8f62be2ba3b8566c46e4dde
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745362
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Add a new LPC helper routine lpc_resume_clear_masks that can be used
to clear SCI, SMI and wake masks upon resume from S3. This is done to
mask the events until host explicitly unmasks them.
It also ensures that these masks do not get reset on resume from S0ix
where the host does not re-configure these masks.
BUG=b:68669668
BRANCH=None
TEST=Verified following:
1. make -j buildall
2. On resume from S0ix, SCI mask is not reset.
3. On resume from S3, SCI mask is reset and then set again by host request.
Change-Id: I17a86bd60ef066b3716fb79ecce62f311eb45509
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/745533
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
It is necessary to be able to set password both from the Cr50 console
and through a vendor command.
This patch moves all password management logic to the TPM task context
using the alternative vendor command path.
BRANCH=cr50
BUG=b:62537474
TEST=verified that using Cr50 console CCD password still can be set
and cleared as before.
Change-Id: I0574caf931e3717567fdb270e406643eac47764b
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/740914
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Implement the following required features in the USB PD Rev. 3.0
specification.
Not_supported control message: Inform a port partner that a
particular message is not supported.
Battery capabilities extended message: Report battery design
capacity and last full charge capacity.
Battery status data message: Report battery state of charge
Collision avoidance: New scheme to avoid collisions caused when both
source and sink want to send messages.
Cable communication: Only the VCONN source can communicate with the
cable plug. This is NOT implemented because although the drivers have
the capability of communicating with a cable plug, the PD stack doesn't
currently need to talk to a cable plug. This is okay since the current
PD design doesn't source or sink more than 3 amps and all Type-C cables
are required to be 3 amp capable.
BUG=b:64411727
BRANCH=None
TEST=`make -j buildall`
Passed relevant PD Rev 2.0 compliance tests
Successful PD negotiation with PD Rev 2.0 and 3.0 chargers
Tested with low power none PD charger.
Modified a Kevin to operate as a PD 3.0 charger and sent
all required messages and verified the return messages.
Also tested collision avoidance by verifying that a sink only
transmits when the source indicates it's okay.
Used Twinkie to verify that PD was operating as v3.0.
Signed-off-by: Sam Hurst <shurst@chromium.org>
Change-Id: Ifd77e92ec4e9106236f9221393d2bfb97263d979
Reviewed-on: https://chromium-review.googlesource.com/603003
Commit-Ready: Sam Hurst <shurst@google.com>
Tested-by: Sam Hurst <shurst@google.com>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
TPM reset sequence when TPM wipeout is requested has a side effect of
rebooting the entire device. This is not always desirable, in some
cases other actions need to happen before the device is rebooted.
This patch makes resetting the EC the TPM reset caller's responsibility,
BRANCH=cr50
BUG=none
TEST=verified that RMA reset and WP disable properly wipe out the TPM
and reboot the device.
Change-Id: I6e827ce923a2454ae5b2e2597d1a4c9390bbb8b6
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/733813
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
When RMA process has been initialized and the user entered the
expected authentication code value, the Cr50 needs to wipe out TPM
memory, open and unlock CCD and reboot the device.
This patch adds a function to accomplish that. User response is
validated on the TPM task context, and TPM reset request also requires
TPM task processing. To decouple response processing from the
following reset, the response processing is handled by a hook task
callback, delayed for 1s to make sure that user receives the response.
After TPM has successfully reset the CCD is reinitialized with RMA
'opened' and the device is rebooted.
Just in case something goes wrong with the unlock and the hook is not
invoked, add a 10s deferred function to take the EC out of reset so
that the device still can reboot.
BRANCH=none
BUG=b:67007905
TEST=on a Bob device:
- on the Cr50 console enter 'ccd lock', verify that ccd is locked
(by examining output of the 'ccd' command)
- at the bash prompt enter gsctool -r -s -t, copy the
authentication code from the Cr50 console and pass it to gsctool.
- observe the device reset TPM wiping out its memory, enable CCD
and reboot.
Change-Id: I6fafb5e642cb2b6f2040507a7f1989607fd31316
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/729983
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Reviewed-by: Mary Ruthven <mruthven@chromium.org>
keyboard/button init are responsible for checking if user requested
manual recovery. However, by this time, hook init is not run and hence
host event set operation for manual recovery is dropped. This change
adds a call to lpc_init_mask before keyboard/button init operations
are performed.
BUG=b:68189465
BRANCH=None
TEST=Verified that manual recovery works fine. Recovery using software
command works too:
reboot ap-off
hostevent set 0x4000
powerb
Change-Id: I15cb648d4b253a523293c7ab2cd3e8e08e31a763
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/735799
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
tcpm_get_cc() returns TYPEC_CC_VOLT_*, not TYPEC_CC_*. Check for RP
rather than non-open to match USB-C spec (Table B-2 Rp/Rp Charging
Current Values for a DTS Source).
BUG=chromium:775542
BRANCH=servo
TEST=Verify donette and guppy are not detected as DTS, verify suzy-qable
is detected as DTS, on kevin DUT.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I0ff5550e9171ff86b42b489525044bf63827240c
Reviewed-on: https://chromium-review.googlesource.com/733220
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
This prevents problematic disabling of the keystrokes by making it
so that 0xAD can't disable keystrokes.
Also cleans up keyboard controller enable/disable code.
BRANCH=none
BUG=none
TEST=keyboard now working in UEFI bootloaders like systemd-boot
(aka gummiboot)
Change-Id: I921834fc418572c9a0f4586039ac1ce05504bf1d
Signed-off-by: Matt DeVillier <matt.devillier@gmail.com>
Signed-off-by: Stefan Reinauer <reinauer@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/722124
Tested-by: Stefan Reinauer <reinauer@google.com>
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Allow other modules to call pd_find_pdo_index() / pd_extract_pdo_power()
in order to get information about current PDOs.
BUG=chromium:775542
TEST=Manual on kevin, verify 20V negotiation with zinger still works.
BRANCH=servo
Change-Id: I1861a0226501bda13e7d576d0971d841da9d2b74
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/724682
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
suzy-qable advertises 1.5A, but its actual capability depends on the
host USB port it is attached to. Since suzy-qable is ubiquitous and
other DTS sources may behave in the same way, ramp the input current
limit in order to find a reasonable maximum.
BUG=chromium:770296
BRANCH=None
TEST=Attach suzy-qable to kevin and reef, verify that neither OCs and EC
console via cr50 is available on reef. Also verify donette chargers
kevin at 3A and does not ramp.
Change-Id: Idd0683ede3a44111a01da6b4faab52f388ee82fd
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/693295
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
According to the USB-C spec, when a debug accessory is identified, we may
optionally establish USB PD communication over CC. Some DTS partners
(eg. servo_v4) expect us to speak PD, so let's make it so. There is no
need for special ACCESSORY states, these do not exist in the PD spec.
BRANCH=servo
BUG=chromium:737755,b:65837068
TEST=On scarlet, attach servo_v4 and verify scarlet charges. Also verify
EC and cr50 consoles are available through servo_v4.
Change-Id: I59d1ca50b4766509eccf38562cdf926578138585
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/693294
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a new DRP policy to "freeze" the power role of each port, never
toggling automatically, though manual role swaps may still occur.
BUG=chromium:769895
BRANCH=servo
TEST=On servo_v4, verify DUT port stays in SRC role and POWER port
stays in SNK role while disconnected.
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: Ibff3cd1ffaf0e884b030c231003763a57acbe02e
Reviewed-on: https://chromium-review.googlesource.com/715276
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
BUG=chromium:769895
BRANCH=servo
TEST=On servo_v4, attach OEM Apple charger to power port and verify
negotiation to 9V and port / ILIM selection from charge_manager. Attach
samus to DUT port and verify 9V charging.
Change-Id: Icf16f6e8c99af4fbb48a83b7a36f550c20f5fd69
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/713944
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Add a new mask type (ALWAYS_REPORT mask) that is set by default to
certain host events that should always be reported to the host
irrespective of the state of SCI, SMI and wake masks. This mask
includes host events like critical events resulting in shutdown or
reboot, events that are consumed by BIOS, etc.
Now that ALWAYS_REPORT mask is added, this change also updates the way
EC manages set/query operations for host events:
1. During set operation, EC will check if the host event is present in
any of the 4 masks - SCI, SMI, wake and always report. If yes, then it
is set in hostevents.
2. During query operation, EC will extract the lowest set event from
hostevents, clear it and return it back to the host.
In order to reflect the above change in EC behavior, a new feature bit
is used EC_FEATURE_UNIFIED_WAKE_MASKS. This allows the host to decide
when wake mask needs to be set before checking for host events.
BUG=None
BRANCH=None
TEST=make -j buildall. Also verified following:
1. Wake from S3 works as expected. Host is able to log correct wake
sources (Verified power button, lid open, base key press and tablet
mode change on soraka).
2. Wake from S5 works as expected. Host is able to log correct wake
sources (Verified power button, lid open on soraka).
3. Wake from S0ix works as expected (Verified power button, lid open
on soraka).
4. Software method to trigger recovery still works fine:
reboot ap-off
hostevent set 0x4000
powerb
Change-Id: I62e5c1f82247c82348cd019e082883d86ec2688f
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/719578
Reviewed-by: Aaron Durbin <adurbin@chromium.org>
Instead of duplicating the handling of host events and host event
masks in chip lpc drivers, add routines in common code to provide
basic functions like setting/getting of masks, setting/getting of
events and handling of masks transitions across sysjump.
BUG=None
BRANCH=None
TEST=make -j buildall. Verified following:
1. Event masks are correctly retained across sysjumps.
2. Wake from S3 works fine.
3. Wake from S0ix works fine.
4. SCI generated correctly.
Change-Id: Ie409f91b12788e4b902b2627e31ba5ce40ff1d27
Signed-off-by: Furquan Shaikh <furquan@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/707771
Reviewed-by: Shawn N <shawnn@chromium.org>
This patch is to enable fan through PWM4 output and TACH feedback
from TA2 GPIOA6, and move EC_PLATFORM_RST to GPIO45.
BUG=b:64915426
BRANCH=None
TEST=emerge-fizz chromeos-ec and use fanduty and faninfo from EC
console to control and check fan status. Probed oscilloscope
on PWM output and checked the duty as expected. Made sure the
fan was stopped when DUT entered S3 and was running when DUT
resumed from S3.
Change-Id: I09f3ac43d2e4170b2aff3830f832bc5fd46a15c0
Signed-off-by: Gaggery Tsai <gaggery.tsai@intel.corp-partner.google.com>
Reviewed-on: https://chromium-review.googlesource.com/627542
Commit-Ready: Daisuke Nojiri <dnojiri@chromium.org>
Tested-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
This patch adds EC_RW_B entry in the FMAP. This allows FAFT to locate
the RW_B image and manipulate it.
BUG=b:64614832,b:67748602
BRANCH=none
TEST=Run futility dump_fmap ec.bin.
Change-Id: I03aec945e0c8c3e08fc629a34ea6e5183bcccb61
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/722024
Reviewed-by: Randall Spangler <rspangler@chromium.org>
In EFS, EC needs to sysjump to the active copy, which is hashed
and validated by the AP.
BUG=b:67748602
BRANCH=none
TEST=Verify Depthcharge makes EC jump to RW.
Change-Id: I2ca893f7691ad776a791f2044dd7a0983d06e3c5
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/717676
TCPM will retry sending of source caps on failure and retrying in TCPC
will cause us to violate PD_T_SEND_SOURCE_CAP.
BUG=None
TEST=Attach servo_v4 to twinkie, verify source caps are sent in ~100ms
intervals and not in bursts of four.
BRANCH=servo_v4
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I3264e5578afbde7b9d2c003b6744974329a253d4
Reviewed-on: https://chromium-review.googlesource.com/719729
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
The new console command uses the alternative TPM command execution
path to generate the RMA challenge and also allows to verify the RMA
authentication code.
This patch also limits the rma challenge/auth code printouts to images
supporting debug features (built with CR50_DEV=1), and limits the code
included when building test images.
BRANCH=cr50
BUG=b:67008109
TEST=while running TCG tpm test ran the new console command multiple
times, observed all tests pass and the command always succeed.
Change-Id: I9ca3e86040d8adbdbe70f33cf2b317075f823f36
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699524
Reviewed-by: Randall Spangler <rspangler@chromium.org>
The TPM task provides access to various cryptographic functions which
require huge stack size. Some other contexts might require to execute
these functions, but no other task in the system has enough stack.
The suggested solution is to create an alternative TPM task execution
path, where the command comes not from the communications interface
(SPI or I2C), but from another task in the system.
An interface function is created to allow a single task to pass the
command to the TPM task. The task requesting the alternative execution
path creates the command context, sends an event to the TPM task to
alert it to the presence of the command and then polls the flag
indicating that the TPM task has completed execution of the command.
BRANCH=cr50
BUG=b:67008109
TEST=tested after applying the next patch (add console command for
generating RMA auth challenge).
Change-Id: I168489a5fbb4a3e1d718198812019116738b2f61
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/699523
The decision on whether to ramp (and how high) depends on the quirks of
charger identification, so move the decision out of board, into the
drivers that implement usb_charger.
Also, rename CONFIG_CHARGE_RAMP to CONFIG_CHARGE_RAMP_SW, to better
contrast with the existing CONFIG_CHARGE_RAMP_HW.
BUG=None
TEST=Manual on kevin, verify ramp occurs when port plugged into Z840
workstation.
BRANCH=None
Change-Id: I5b395274133837a18a4f4ac34b59b623287be175
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/702681
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
Boards that use charge_manager have identical implementations of
typec_set_input_current_limit() and pd_set_input_current_limit(), so
move these functions to charge_manager.
BUG=b:67413505
TEST=`make buildall -j`, also verify that fizz continues to power-on and
boot AP, in both protected and unprotected mode, with barrel jack power
and with zinger.
BRANCH=None
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Change-Id: I99a5314d02c4696db944c0f8ac689405f4f1f707
Reviewed-on: https://chromium-review.googlesource.com/701412
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
CONFIG_CASE_CLOSED_DEBUG (CCD functionality implemented by EC) is no
longer used in conjunction with CONFIG_USB_POWER_DELIVERY, and the
common routines are only used by one board.
BUG=chromium:737755
BRANCH=None
TEST=`make buildall -j`
Change-Id: Idc3d2fccef6cbec2af786cef634d752a02a0e859
Signed-off-by: Shawn Nematbakhsh <shawnn@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/656315
Commit-Ready: Shawn N <shawnn@chromium.org>
Tested-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Nick Sanders <nsanders@chromium.org>
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
A couple of bugs have crept in with the latest series of patches:
- the board ID value endianness does not have to be changed
- the test RMA server public key value is wrong
BRANCH=cr50
BUG=b:67007905
TEST=the generated challenge is now accepted by the server, and the
generated auth code matches between the server and the Cr50.
Change-Id: I18f413ab0bcc14d9cc50b115ac3784fdfcd5851c
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/700798
Reviewed-by: Michael Tang <ntang@chromium.org>
The new vendor command operates in two modes: when received with a
zero size payload, it triggers the Cr50 to generate a new RMA
authentication challenge and the expected authentication code value.
When receive with the payload, it compares the received payload with
the pre-calculate authentication code, and returns to the host the
comparison result (passed/not passed).
A care is taken not to accept payload until at least there is a valid
calculated auth code present (to avoid reporting a match on a payload
of all zeros).
Test config needed to be modified to allow compiling of the ccprintf
wrapper.
BRANCH=cr50
BUG=b:37952913
TEST=with the rest of the patches applied observed expected behavior
of generating challenge/response and verifying the auth code.
Change-Id: I30638b0ceef68830565f222dd1f4af17cfc8d7ef
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690992
Different devices could have different sized unique device IDs. Let's
just use the IDs as is if they are no larger than the
rma_challenge:device_id field, or the first 8 bytes of the HMAC_sha256
value of the unique device ID, where the unique device ID is used both
as the key and the payload.
The server expects the board ID field in big endian format, let's swap
it before calculating the RMA auth challenge.
The test's server side implementation needs to be also adjusted.
BRANCH=cr50
BUG=b:37952913
TEST=make buildall -j passes. With the rest of the patches applied RMA
authentication process generates sensible values.
Change-Id: Ia1fbf9161e01de30a2da8214258008f6e5f7d915
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690991
Reviewed-by: Michael Tang <ntang@chromium.org>
On Cr50 the crypto library has a slightly different API, as indicated
by the presence of the CONFIG_DCRYPTO configuration option.
This patch provides a wrapper which allows to calculate a SHA256 HMAC
hash using either underlying crypto API.
BRANCH=cr50
BUG=b:37952913
TEST=make buildall -j
Change-Id: Ibb8c60e50139fd5506a4dd5f2ed19653c68af8cb
Signed-off-by: Vadim Bendebury <vbendeb@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/690440
Reviewed-by: Randall Spangler <rspangler@chromium.org>
Hash command expects second parameter to be either
abort, RO, RW. If not then exit the function by
displaying error message instead of calculating hash.
BUG=NONE
BRANCH=NONE
TEST=On EC console 'hash help' should display error message
with usage info.
Change-Id: I4fcad97ce0da1cd48a458de1c659aa3c6b2a60b9
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/691436
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
Fizz EC verifies RW by itself and jumps to RW before AP boots.
If this fails, the system needs recovery. Since EC isn't
capable of showing any info on a display, we use the power
LED to inform the user.
BUG=b:66914368
BRANCH=none
TEST=Make Fizz fail RW verification. Observe LED illuminates
in red.
Change-Id: Ia07de60a316b40e74b1917903996d78750b4ae43
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/683218
This patch makes the LED blink to alert the user when there is
not enough power to boot the system.
This patch also changes minimum boot power to 50W. It's common
for all SKUs.
BUG=b:37646390
BRANCH=none
TEST=Power Fizz with 15W, 45W, 60W chargers. Verify LED blinks as
expected.
Change-Id: If269897f5022f6cba80f37ce03e2315cfb2cf504
Signed-off-by: Daisuke Nojiri <dnojiri@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/682876
Reviewed-by: Vincent Palatin <vpalatin@chromium.org>
For the Host Command vboot hash EC_VBOOT_HASH_GET case,
if the input parameter offset and size is 0 then change
offset to data_offset to obtain the latest hash value.
Else retain the offset to get the hash value at offset.
BUG=b:66957716
BRANCH=NONE
TEST=On Soraka, ectool echash commands
(RO, RW) should result in hash information.
Change-Id: Ife17d35b0dfeecb5ec799c9ed722ae48dbec5b5b
Signed-off-by: Jagadish Krishnamoorthy <jagadish.krishnamoorthy@intel.com>
Reviewed-on: https://chromium-review.googlesource.com/685738
Reviewed-by: Daisuke Nojiri <dnojiri@chromium.org>
To implement rtc driver for some ec chips, we
need to convert between calandar date and seconds
(since epoch time, 01-01-1970 00:00:00).
Sicne these functions are HW-independent, let's add
common/rtc.c, include/rtc.h, and unit test for this.
BUG=b:63908519
BRANCH=none
TEST=make buildall test -j
Change-Id: Icb1e768d2b3674d5225b83e09475e984eb104d06
Signed-off-by: Philip Chen <philipchen@google.com>
Reviewed-on: https://chromium-review.googlesource.com/666985
Commit-Ready: Philip Chen <philipchen@chromium.org>
Tested-by: Philip Chen <philipchen@chromium.org>
Reviewed-by: Shawn N <shawnn@chromium.org>
Reviewed-by: Brian Norris <briannorris@chromium.org>
