125 lines
4.5 KiB
125 lines
4.5 KiB
# PD FAFT
|
|
|
|
PD FAFT is another set of firmware tests (FAFT), which targets testing USB-C and
|
|
PD (Power Delivery) functionalities.
|
|
|
|
[TOC]
|
|
|
|
## Overview {#overview}
|
|
|
|
The USB-C and PD stack is complex that involves multiple hardware/firmware:
|
|
|
|
* TCPM (USB Type-C Port Manager),
|
|
[integrated in EC, using Chrome EC firmware](https://chromium.googlesource.com/chromiumos/platform/ec/+/master/docs/usb-c.md)
|
|
* TCPC (USB Type-C Port Controller), usually using proprietary firmware, in
|
|
the form of
|
|
* dedicated chip, like ANX74xx, PS8xxx,
|
|
* integrated in EC, like IT83xx, or
|
|
* integrated in PMIC, like MT6370.
|
|
|
|
The USB-C path also has other functions, like:
|
|
|
|
* DisplayPort, which shares the SuperSpeed lanes and the SBU channel;
|
|
* CCD, which shares the SBU channel and has special CC terminations.
|
|
|
|
Many USB-C bugs are mysterious or flaky, like CCD not being detected, USB
|
|
Ethernet connection being lost, or external monitors not showing up, etc. This
|
|
kind of issue blocks BIOS/EC FAFT running. Some bugs may be even more serious
|
|
that brick the hardware, negotiating a wrong voltage/current.
|
|
|
|
PD FAFT was proposed to uncover any regression on the PD stack in an automated
|
|
way.
|
|
|
|
PD FAFT requires hardware to emulate the PD port partner, e.g. a PD-capable
|
|
power adapter, a USB-C hub, a USB-C debug accessory, a USB-C protocol converter,
|
|
a USB-C monitor, etc. The first version of PD FAFT uses
|
|
[Plankton](https://www.chromium.org/chromium-os/plankton) as PDTester. The
|
|
latest version uses
|
|
[ServoV4](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/docs/servo_v4.md)
|
|
as PDTester.
|
|
|
|
## Test details {#test-details}
|
|
|
|
The PD FAFT tests are located in the Autotest tree as directories, usually with
|
|
the prefix firmware\_PD.
|
|
|
|
firmware\_PDConnect, checks:
|
|
|
|
* Ability to disconnect, then reconnect establishing a successful PD contract
|
|
* If PD Dual role mode is operational in the DUT
|
|
|
|
firmware\_PDPowerSwap, checks:
|
|
|
|
* If the DUT advertises support for dualrole operation
|
|
* If the DUT can receive power swap requests
|
|
* If the DUT can initiate power swap requests
|
|
|
|
firmware\_PDDataSwap, checks:
|
|
|
|
* If the DUT advertises support for data role swaps
|
|
* If the DUT can receive data swap requests
|
|
* If the DUT can initiate data swap requests
|
|
|
|
firmware\_PDResetHard, checks:
|
|
|
|
* Ability of DUT to initiate hard resets
|
|
* Ability of DUT to receive hard resets
|
|
* If DUT is dualrole capable, hard resets are done with the DUT in each power
|
|
role
|
|
|
|
firmware\_PDResetSoft, checks:
|
|
|
|
* Ability of DUT to initiate soft resets
|
|
* Ability of DUT to receive soft reset requests from Plankton
|
|
* If DUT is dualrole capable, soft resets are done with the DUT in each power
|
|
role
|
|
|
|
firmware\_PDTrySrc, checks:
|
|
|
|
* If the DUT advertises support for dualrole and Try.SRC operation
|
|
* A series of disconnects/connects with Try.SRC on
|
|
* A series of disconnects/connects with Try.SRC off
|
|
* Try.SRC on the DUT connects in SRC mode
|
|
|
|
firmware\_PDVbusRequest, checks:
|
|
|
|
* Ability to initiate a new PD contract with different VBUS value, according
|
|
to the attached charger capability, like 5V, 9V, 12V, 15V, 20V, etc.
|
|
* Receiving Source Capability messages from PDTester
|
|
* If PD Dual role mode is operational in the DUT
|
|
|
|
The above tests may have multiple subtests, the same test body but different
|
|
prerequisite.
|
|
|
|
.flip subtest, checks
|
|
|
|
* If DUT passes the same test on the flipped plug direction, which is
|
|
implemented by electrically flipping the CC signals on PDTester
|
|
|
|
.dts subtest, checks
|
|
|
|
* If DUT passes the same test on a USB-C debug accessory
|
|
* No behavior difference between the normal scenarios and the CCD scenarios
|
|
(it is important as BIOS/EC FAFT uses the CCD setup)
|
|
|
|
## How to run PD FAFT {#how-to-run-pd-faft}
|
|
|
|
Hardware setup, check this
|
|
[ServoV4 Type-C with servo micro setup](https://chromium.googlesource.com/chromiumos/third_party/autotest/+/refs/heads/master/docs/faft-how-to-run-doc.md#servov4-typec-micro).
|
|
|
|
Software setup, check this
|
|
[Running Tests instructions](https://chromium.googlesource.com/chromiumos/third_party/autotest/+/refs/heads/master/docs/faft-how-to-run-doc.md#faft-running-tests).
|
|
|
|
## Known issues {#known-issues}
|
|
|
|
### TCPMv2 {#tcpmv2}
|
|
|
|
PD FAFT by far only supports testing DUT using TCPMv1. Porting to TCPMv2 is in
|
|
progress.
|
|
|
|
### Multiple USB-C ports {#multiple-usb-c-ports}
|
|
|
|
Due to the hardware limitation, that PDTester (ServoV4) only supports testing
|
|
one DUT-facing USB-C port at a time. If a DUT has two USB-C ports, you have to
|
|
run PD FAFT twice -- once for each port under test.
|