diff options
Diffstat (limited to 'board')
| -rw-r--r-- | board/nucleo-f412zg/README.md | 62 | ||||
| -rw-r--r-- | board/nucleo-h743zi/README.md | 62 | ||||
| -rw-r--r-- | board/pdeval-stm32f072/PD_evaluation.md | 158 | ||||
| -rw-r--r-- | board/servo_micro/ccd.md | 100 |
4 files changed, 198 insertions, 184 deletions
diff --git a/board/nucleo-f412zg/README.md b/board/nucleo-f412zg/README.md index fcdd5e40df..f2fa682e6f 100644 --- a/board/nucleo-f412zg/README.md +++ b/board/nucleo-f412zg/README.md @@ -1,22 +1,19 @@ # Nucleo F412ZG -This is a simpler EC example for the ST Nucleo F412ZG -development board. +This is a simpler EC example for the ST Nucleo F412ZG development board. # Quick Start -The Nucleo dev boards have lots of developer friendly features, -like an in-circuit debugger/programmer/UART-bridge, programmable -LEDs, and a button, to name a few. +The Nucleo dev boards have lots of developer friendly features, like an +in-circuit debugger/programmer/UART-bridge, programmable LEDs, and a button, to +name a few. -The built-in debugger can be connected to using a Micro USB cable. -It provides three great interfaces to the host. -1. Mass storage interface for drag-drop programming -2. Full ST-Link in-circuit debugger -3. UART bridge for logs/consoles +The built-in debugger can be connected to using a Micro USB cable. It provides +three great interfaces to the host. 1. Mass storage interface for drag-drop +programming 2. Full ST-Link in-circuit debugger 3. UART bridge for logs/consoles -We will use a few of these interfaces below to program and interact -with out Nucleo dev board. +We will use a few of these interfaces below to program and interact with out +Nucleo dev board. ## Build @@ -26,17 +23,17 @@ make BOARD=nucleo-f412zg -j ## Program -The easiest way to flash the Nucleo board is to Copy-Paste/Drag-Drop -the firmware image onto the exposed mass storage drive. +The easiest way to flash the Nucleo board is to Copy-Paste/Drag-Drop the +firmware image onto the exposed mass storage drive. -Open a file browser and `Copy` the file in `build/nucleo-f412zg/ec.bin`. -Now, find the removable storage that the Nucleo device has presented, -and `Paste` the file into the directory. +Open a file browser and `Copy` the file in `build/nucleo-f412zg/ec.bin`. Now, +find the removable storage that the Nucleo device has presented, and `Paste` the +file into the directory. ## Interact -After the Nucelo finishes programming, you can open the EC console. -On GNU/Linux, this is mapped to `/dev/ttyACM0`. +After the Nucleo finishes programming, you can open the EC console. On +GNU/Linux, this is mapped to `/dev/ttyACM0`. Install `minicom` and issue the following command: @@ -48,9 +45,9 @@ minicom -D/dev/ttyACM0 A fun EC feature is that unit tests can be run on-device. -This is made possible by an alternative build rule that generates a -test image per unit test. These test images use a unit test specific taskset -and console command to trigger them. +This is made possible by an alternative build rule that generates a test image +per unit test. These test images use a unit test specific taskset and console +command to trigger them. ## Create @@ -67,19 +64,20 @@ To build all unit test images for this board, run the following command: make BOARD=nucleo-f412zg tests ``` -You can build a specific unit test image by changing `tests` to `test-aes`, -for the `aes` unit test. +You can build a specific unit test image by changing `tests` to `test-aes`, for +the `aes` unit test. ## Flash -Copy/paste the `build/nucleo-f412zg/${TEST}/${TEST}.bin` file to the -Nucleo's mass storage drive, where `${TEST}` is the name of the unit test, -like `aes`. +Copy/paste the `build/nucleo-f412zg/${TEST}/${TEST}.bin` file to the Nucleo's +mass storage drive, where `${TEST}` is the name of the unit test, like `aes`. ## Run -1. Connect to UART console - ```bash - minicom -D/dev/ttyACM0 - ``` -2. Run the `runtest` command
\ No newline at end of file +1. Connect to UART console + +```bash +minicom -D/dev/ttyACM0 +``` + +1. Run the `runtest` command diff --git a/board/nucleo-h743zi/README.md b/board/nucleo-h743zi/README.md index 58d47219da..7ba8a143a3 100644 --- a/board/nucleo-h743zi/README.md +++ b/board/nucleo-h743zi/README.md @@ -1,22 +1,19 @@ # Nucleo H743ZI -This is a simpler EC example for the ST Nucleo H743ZI -development board. +This is a simpler EC example for the ST Nucleo H743ZI development board. # Quick Start -The Nucleo dev boards have lots of developer friendly features, -like an in-circuit debugger/programmer/UART-bridge, programmable -LEDs, and a button, to name a few. +The Nucleo dev boards have lots of developer friendly features, like an +in-circuit debugger/programmer/UART-bridge, programmable LEDs, and a button, to +name a few. -The built-in debugger can be connected to using a Micro USB cable. -It provides three great interfaces to the host. -1. Mass storage interface for drag-drop programming -2. Full ST-Link in-circuit debugger -3. UART bridge for logs/consoles +The built-in debugger can be connected to using a Micro USB cable. It provides +three great interfaces to the host. 1. Mass storage interface for drag-drop +programming 2. Full ST-Link in-circuit debugger 3. UART bridge for logs/consoles -We will use a few of these interfaces below to program and interact -with out Nucleo dev board. +We will use a few of these interfaces below to program and interact with out +Nucleo dev board. ## Build @@ -26,17 +23,17 @@ make BOARD=nucleo-h743zi -j ## Program -The easiest way to flash the Nucleo board is to Copy-Paste/Drag-Drop -the firmware image onto the exposed mass storage drive. +The easiest way to flash the Nucleo board is to Copy-Paste/Drag-Drop the +firmware image onto the exposed mass storage drive. -Open a file browser and `Copy` the file in `build/nucleo-h743zi/ec.bin`. -Now, find the removable storage that the Nucleo device has presented, -and `Paste` the file into the directory. +Open a file browser and `Copy` the file in `build/nucleo-h743zi/ec.bin`. Now, +find the removable storage that the Nucleo device has presented, and `Paste` the +file into the directory. ## Interact -After the Nucelo finishes programming, you can open the EC console. -On GNU/Linux, this is mapped to `/dev/ttyACM0`. +After the Nucleo finishes programming, you can open the EC console. On +GNU/Linux, this is mapped to `/dev/ttyACM0`. Install `minicom` and issue the following command: @@ -48,9 +45,9 @@ minicom -D/dev/ttyACM0 A fun EC feature is that unit tests can be run on-device. -This is made possible by an alternative build rule that generates a -test image per unit test. These test images use a unit test specific taskset -and console command to trigger them. +This is made possible by an alternative build rule that generates a test image +per unit test. These test images use a unit test specific taskset and console +command to trigger them. ## Create @@ -67,19 +64,20 @@ To build all unit test images for this board, run the following command: make BOARD=nucleo-h743zi tests ``` -You can build a specific unit test image by changing `tests` to `test-aes`, -for the `aes` unit test. +You can build a specific unit test image by changing `tests` to `test-aes`, for +the `aes` unit test. ## Flash -Copy/paste the `build/nucleo-h743zi/${TEST}/${TEST}.bin` file to the -Nucleo's mass storage drive, where `${TEST}` is the name of the unit test, -like `aes`. +Copy/paste the `build/nucleo-h743zi/${TEST}/${TEST}.bin` file to the Nucleo's +mass storage drive, where `${TEST}` is the name of the unit test, like `aes`. ## Run -1. Connect to UART console - ```bash - minicom -D/dev/ttyACM0 - ``` -2. Run the `runtest` command
\ No newline at end of file +1. Connect to UART console + +```bash +minicom -D/dev/ttyACM0 +``` + +1. Run the `runtest` command diff --git a/board/pdeval-stm32f072/PD_evaluation.md b/board/pdeval-stm32f072/PD_evaluation.md index 95e31996fc..4f1c8636c6 100644 --- a/board/pdeval-stm32f072/PD_evaluation.md +++ b/board/pdeval-stm32f072/PD_evaluation.md @@ -1,17 +1,17 @@ -USB PD chip evaluation configuration -==================================== +# USB PD chip evaluation configuration -This board configuration implements a USB Power Delivery TCPM -in order to evaluate various TCPC chips. -The code tries to follow the preliminary USB PD interface standard but for TCPC chip implementing proprietary I2C protocol, a new TCPM file can be implemented as explained in the [Updating the code](#Updating-the-code) section below. +This board configuration implements a USB Power Delivery TCPM in order to +evaluate various TCPC chips. The code tries to follow the preliminary USB PD +interface standard but for TCPC chip implementing proprietary I2C protocol, a +new TCPM file can be implemented as explained in the +[Updating the code](#Updating-the-code) section below. -Building --------- +## Building -### ChromiumOS chroot +### Chromium OS chroot -All the following instructions have been verified in a ChromiumOS chroot. -You can find how to set one up on the Chromium development wiki: +All the following instructions have been verified in a ChromiumOS chroot. You +can find how to set one up on the Chromium development: [http://dev.chromium.org/chromium-os/quick-start-guide](http://dev.chromium.org/chromium-os/quick-start-guide) ### Build the TCPM code @@ -20,34 +20,52 @@ You can find how to set one up on the Chromium development wiki: `make BOARD=pdeval-stm32f072` - -Updating the code ------------------ +## Updating the code ### TCPC Communication code -Please duplicate [driver/tcpm/tcpci.c](../../driver/tcpm/tcpci.c) into **driver/tcpm/##chip#name##.c**. -Then update the control logic through I2C there. +Please duplicate [driver/tcpm/tcpci.c](../../driver/tcpm/tcpci.c) into +**driver/tcpm/##chip#name##.c**. Then update the control logic through I2C +there. -In order for your new code to compile, you need to update [driver/build.mk](../../driver/build.mk) with the new file : -`driver-$(CONFIG_USB_PD_TCPM_##CHIP#NAME##)+=tcpm/##chip#name##.o` -then document the new `CONFIG_USB_PD_TCPM_` variable in the [include/config.h](../../include/config.h) file and define it in the board configuration in [board/pdeval-stm32f072/board.h](board.h). +In order for your new code to compile, you need to update +[driver/build.mk](../../driver/build.mk) with the new file : +`driver-$(CONFIG_USB_PD_TCPM_##CHIP#NAME##)+=tcpm/##chip#name##.o` then document +the new `CONFIG_USB_PD_TCPM_` variable in the +[include/config.h](../../include/config.h) file and define it in the board +configuration in [board/pdeval-stm32f072/board.h](board.h). ### Board configuration -In [board/pdeval-stm32f072/board.h](board.h), you can update `CONFIG_USB_PD_PORT_MAX_COUNT` to the actual number of ports on your board. -You also need to create/delete the corresponding `PD_Cx` tasks in [board/pdeval-stm32f072/ec.tasklist](ec.tasklist). - -By default, the firmware is using I2C1 with SCL/SDA on pins PB6 and PB7, running with a 100kHz clock, and tries to talk to TCPCs at i2c slave addresses 0x9c and 0x9e. -To change the pins or speed, you need to edit `i2c_ports` in [board/pdeval-stm32f072/board.c](board.c), update `I2C_PORT_TCPC` in [board/pdeval-stm32f072/board.h](board.h) with the right controller number, and change the pin mux in [board/pdeval-stm32f072/gpio.inc](gpio.inc). To change TCPC i2c slave addresses, update `TCPC1_I2C_ADDR` and `TCPC2_I2C_ADDR` in [board/pdeval-stm32f072/board.h](board.h). - -The I2C bus needs pull-up resistors on SCL/SDA. If your setup doesn't have external pull-ups on those lines, you can activate the chip internal pull-ups (but they are a bit weak for I2C) by editing [board/pdeval-stm32f072/gpio.inc](gpio.inc) and updating the alternate mode configuration flags with `GPIO_PULL_UP` e.g. : -`ALTERNATE(PIN_MASK(B, 0x00c0), 1, MODULE_I2C, GPIO_PULL_UP) /* I2C MASTER:PB6/7 */` - -An interrupt line, PA1, is configured to be used for the TCPC to get the attention of the TCPM. The GPIO is configured to trigger an interrupt on the falling edge and will call `tcpc_alert()`, which must be implemented in **driver/tcpm/<vendor>.c**, and should determine the cause of the interrupt and take action. The GPIO can be changed in [board/pdeval-stm32f072/gpio.inc](gpio.inc). - -Flashing and Running --------------------- +In [board/pdeval-stm32f072/board.h](board.h), you can update +`CONFIG_USB_PD_PORT_MAX_COUNT` to the actual number of ports on your board. You +also need to create/delete the corresponding `PD_Cx` tasks in +[board/pdeval-stm32f072/ec.tasklist](ec.tasklist). + +By default, the firmware is using I2C1 with SCL/SDA on pins PB6 and PB7, running +with a 100kHz clock, and tries to talk to TCPCs at i2c slave addresses 0x9c and +0x9e. To change the pins or speed, you need to edit `i2c_ports` in +[board/pdeval-stm32f072/board.c](board.c), update `I2C_PORT_TCPC` in +[board/pdeval-stm32f072/board.h](board.h) with the right controller number, and +change the pin mux in [board/pdeval-stm32f072/gpio.inc](gpio.inc). To change +TCPC i2c slave addresses, update `TCPC1_I2C_ADDR` and `TCPC2_I2C_ADDR` in +[board/pdeval-stm32f072/board.h](board.h). + +The I2C bus needs pull-up resistors on SCL/SDA. If your setup doesn't have +external pull-ups on those lines, you can activate the chip internal pull-ups +(but they are a bit weak for I2C) by editing +[board/pdeval-stm32f072/gpio.inc](gpio.inc) and updating the alternate mode +configuration flags with `GPIO_PULL_UP` e.g. : `ALTERNATE(PIN_MASK(B, 0x00c0), +1, MODULE_I2C, GPIO_PULL_UP) /* I2C MASTER:PB6/7 */` + +An interrupt line, PA1, is configured to be used for the TCPC to get the +attention of the TCPM. The GPIO is configured to trigger an interrupt on the +falling edge and will call `tcpc_alert()`, which must be implemented in +**driver/tcpm/<vendor>.c**, and should determine the cause of the interrupt and +take action. The GPIO can be changed in +[board/pdeval-stm32f072/gpio.inc](gpio.inc). + +## Flashing and Running ### Flashing the firmware binary @@ -55,37 +73,46 @@ To flash through JTAG with OpenOCD, you can just run: `sudo make flash BOARD=pdeval-stm32f072` -Note: you need to do that with your USB mini-B cable is connected to the **USB ST-LINK** plug on the discovery board. +Note: you need to do that with your USB mini-B cable is connected to the **USB +ST-LINK** plug on the discovery board. ### Connecting to the firmware console -Connect a USB cable to the **USB USER** mini-B receptacle on the board. -`lsusb` should show you a device with the following ID : 18d1:500f +Connect a USB cable to the **USB USER** mini-B receptacle on the board. `lsusb` +should show you a device with the following ID : 18d1:500f -You can get a console over USB by issuing the following command on a Linux computer: +You can get a console over USB by issuing the following command on a Linux +computer: `echo '18d1 500f' | sudo tee /sys/bus/usb-serial/drivers/generic/new_id` -Testing -------- +## Testing -Currently, the TCPM is expecting to have a GPIO to detect VBUS, but to minimize the HW setup with the discovery board the alternative is to fake VBUS detection using either the **USER** button on the discovery board, or the `vbus` console command, both of which toggle the state of VBUS detected. For example, to make get a PD contract with a power adapter, plug in the adapter and then toggle VBUS on. When a PD contract above 6V is made, LED5 on the discovery board will light. To disconnect, toggle VBUS off. +Currently, the TCPM is expecting to have a GPIO to detect VBUS, but to minimize +the HW setup with the discovery board the alternative is to fake VBUS detection +using either the **USER** button on the discovery board, or the `vbus` console +command, both of which toggle the state of VBUS detected. For example, to make +get a PD contract with a power adapter, plug in the adapter and then toggle VBUS +on. When a PD contract above 6V is made, LED5 on the discovery board will light. +To disconnect, toggle VBUS off. EC command line commands -- `help` List all available EC console commands -- `vbus` Toggle VBUS on/off -- `pd <port> state` Print PD protocol state information -- `pd <port> swap data` Request data role swap on port -- `pd <port> swap power` Request power role swap on port -- `i2cscan` Scan i2c bus for any responsive devices -- `i2cxfer` Perform an i2c transaction - -On the console, you will the PD state machine transitioning through its states with traces like `C0 st5`. -You can always the human readable name of the current state by doing `pd 0 state` returning something like : -`Port C0 CC1, Ena - Role: SNK-UFP State: SNK_DISCOVERY, Flags: 0x0608` -else the numbering of the state is defined in [include/usb_pd.h](../../include/us_pd.h) by the `PD_STATE_` constants. -It should be by default : +- `help` List all available EC console commands +- `vbus` Toggle VBUS on/off +- `pd <port> state` Print PD protocol state information +- `pd <port> swap data` Request data role swap on port +- `pd <port> swap power` Request power role swap on port +- `i2cscan` Scan i2c bus for any responsive devices +- `i2cxfer` Perform an i2c transaction + +On the console, you will the PD state machine transitioning through its states +with traces like `C0 st5`. You can always the human readable name of the current +state by doing `pd 0 state` returning something like : `Port C0 CC1, Ena - Role: +SNK-UFP State: SNK_DISCOVERY, Flags: 0x0608` else the numbering of the state is +defined in [include/usb_pd.h](../../include/us_pd.h) by the `PD_STATE_` +constants. It should be by default : + ``` [0] DISABLED [1] SUSPENDED @@ -125,27 +152,26 @@ It should be by default : [35] BIST_TX ``` -Known Issues ------------- - -1. This doc is not finished yet ... +## Known Issues -2. You might need a ChromeOS chroot ... +1. This doc is not finished yet ... -Troubleshooting ---------------- +2. You might need a ChromeOS chroot ... -1. OpenOCD is not finding the device. +## Troubleshooting - 1. Check that your USB mini-B cable is connected to the **USB ST-LINK** plug on the discovery board. - 2. What color is the LD1 LED on the board ? +1. OpenOCD is not finding the device. -1. On the I2C bus, SDA/SCL lines are staying always low + 1. Check that your USB mini-B cable is connected to the **USB ST-LINK** + plug on the discovery board. + 2. What color is the LD1 LED on the board ? - 1. You might be missing some pull-up resistors on the bus. - 1. Check the [Board configuration](#Board-configuration) section if you cannot add external pull-ups. +1. On the I2C bus, SDA/SCL lines are staying always low -1. You got black smoke + 1. You might be missing some pull-up resistors on the bus. + 1. Check the [Board configuration](#Board-configuration) section if you + cannot add external pull-ups. - 1. Time to buy a new one. +1. You got black smoke + 1. Time to buy a new one. diff --git a/board/servo_micro/ccd.md b/board/servo_micro/ccd.md index acb82adb94..d05fa726fd 100644 --- a/board/servo_micro/ccd.md +++ b/board/servo_micro/ccd.md @@ -6,30 +6,31 @@ # Case-Closed Debug in Chromebooks and Servo Micro -The Servo debug/test-automation connector has been required on all -chromebooks. It has proved essential to performing the required testing to meet -the six week OS release cycle, for bringing up new systems and qualifying new -components. In newer form-factors it is becoming hard to fit the Servo connector -(and related flex) and in some designs the thermal solution stops working when -the connector is used. The secure Case-Closed Debugging solution provides the -same capabilities and can take advantage of the Debug Mode detection available -on the USB-C connector. This application note gives an overview of Case-Closed -Debug (CCD) but does not address the related security issues. - +The Servo debug/test-automation connector has been required on all chromebooks. +It has proved essential to performing the required testing to meet the six week +OS release cycle, for bringing up new systems and qualifying new components. In +newer form-factors it is becoming hard to fit the Servo connector (and related +flex) and in some designs the thermal solution stops working when the connector +is used. The secure Case-Closed Debugging solution provides the same +capabilities and can take advantage of the Debug Mode detection available on the +USB-C connector. This application note gives an overview of Case-Closed Debug +(CCD) but does not address the related security issues. ## Introduction to Case-Closed Debug -Case-Closed Debug provides the same set of features as are available on the Servo connector: +Case-Closed Debug provides the same set of features as are available on the +Servo connector: * Access to console UART connections to AP, EC and on some systems a third MCU * Ability to reprogram firmware/BIOS SPI flash used by the AP * Ability to reprogram SPI flash used by the EC or use a firmware update mode to reprogram the internal flash on the EC (using UART or I2C) * GPIOs for holding the EC (and thus entire system) or AP in reset -* Act as master on a debug I2C that is primarily used for power - measurements. This bus normally contains INA voltage/current monitors and - temperature monitors that will not be populated on final MP systems. -* JTAG/SWD could be provided but has not been implemented on any existing system. +* Act as master on a debug I2C that is primarily used for power measurements. + This bus normally contains INA voltage/current monitors and temperature + monitors that will not be populated on final MP systems. +* JTAG/SWD could be provided but has not been implemented on any existing + system. When the Servo connector is used these interfaces are presented on well defined pins of the board-to-board connector and a flex is used to attach to the @@ -43,7 +44,6 @@ be used for the debug USB while the main link on the connector continues to be available. (The SBU pins are also used by some Alternate Modes, so the connector cannot be used for video out at the same time as debugging.) - ## Servo Micro: Using CCD with existing boards The Servo Micro implements the CCD functions in a way that can connect to @@ -60,8 +60,8 @@ original Servo connector, but on some designs) can be connected to either the JTAG pins or the SPI pins. It is capable of providing the SPI flash supply voltages. -The schematics for Servo Micro are available [as a -pdf](servo_micro_sch_20180404.pdf). +The schematics for Servo Micro are available +[as a pdf](servo_micro_sch_20180404.pdf). Servo Micro has a USB micro-B connector and acts as a USB device. @@ -75,8 +75,8 @@ UART connection on CN2. Schematic sheet 3 shows the I2C GPIO expander and the buffers for JTAG/SWD. The buffers adapt to the voltage needed on the DUT that is provided on -`PPDUT_JTAG_VREF`. In the SWD case the TDI becomes the bidirectional SWDIO but the -STM32 continues to use a discrete input and output pin. The DUT signal is +`PPDUT_JTAG_VREF`. In the SWD case the TDI becomes the bidirectional SWDIO but +the STM32 continues to use a discrete input and output pin. The DUT signal is received through U55 and a selection made with U1 to determine if to forward TDO from the DUT or the TDI/SWDIO. Because of the shared pins on the STM32 the JTAG interface can alternatively be used to connect UART3 to the DUT for a few @@ -103,26 +103,23 @@ load switches are carefully selected to have reverse blocking (protecting against a DUT providing a voltage or both being enabled). The code for the STM32 in Servo Micro is open source as the -[`servo_micro`](../../board/servo_micro) -board in the [Chromium EC -codebase](https://chromium.googlesource.com/chromiumos/platform/ec/). Essentially -it is a USB device that provides the standard control endpoint and 7 function -endpoints defined in -[`board.h`](board.h). +[`servo_micro`](../../board/servo_micro) board in the +[Chromium EC codebase](https://chromium.googlesource.com/chromiumos/platform/ec/). +Essentially it is a USB device that provides the standard control endpoint and 7 +function endpoints defined in [`board.h`](board.h). <!-- does not work in emacs/markdown preview but should in gitlies --> -``` c - #define USB_EP_USART4_STREAM 1 - #define USB_EP_UPDATE 2 - #define USB_EP_SPI 3 - #define USB_EP_CONSOLE 4 - #define USB_EP_I2C 5 - #define USB_EP_USART3_STREAM 6 - #define USB_EP_USART2_STREAM 7 +```c +#define USB_EP_USART4_STREAM 1 +#define USB_EP_UPDATE 2 +#define USB_EP_SPI 3 +#define USB_EP_CONSOLE 4 +#define USB_EP_I2C 5 +#define USB_EP_USART3_STREAM 6 +#define USB_EP_USART2_STREAM 7 ``` - The USART endpoints use the simple `GOOGLE_SERIAL` vendor class to connect the STM32 UARTs. The CONSOLE endpoint also uses `GOOGLE_STREAM` to connect to the console of the code running on the STM32. `GOOGLE_STREAM` provides simple byte @@ -131,32 +128,27 @@ standard Linux `drivers/usb/serial/usb-serial-simple.c` The SPI endpoint is described in [`chip/stm32/usb_spi.h`](../../chip/stm32/usb_spi.h) and provides a simple -connection to the SPI port. The host support is provided as a [driver in -flashrom](https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/master/raiden_debug_spi.c). +connection to the SPI port. The host support is provided as a +[driver in flashrom](https://chromium.googlesource.com/chromiumos/third_party/flashrom/+/master/raiden_debug_spi.c). The I2C endpoint is described in [`include/usb_i2c.h`](../../include/usb_i2c.h) and provides a simple connection to the I2C bus. The host support is provided in -the [hdctools servo -support](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/servo/stm32i2c.py). +the +[hdctools servo support](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/servo/stm32i2c.py). The GPIO endpoint is cryptically described in -[`chip/stm32/usb_gpio.h`](../../chip/stm32/usb_gpio.h) and provides simple access -to set/clear and read the GPIO pins. The host support is provided in the -[hdctools servo -support](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/servo/stm32gpio.py). +[`chip/stm32/usb_gpio.h`](../../chip/stm32/usb_gpio.h) and provides simple +access to set/clear and read the GPIO pins. The host support is provided in the +[hdctools servo support](https://chromium.googlesource.com/chromiumos/third_party/hdctools/+/master/servo/stm32gpio.py). The UPDATE endpoint is not part of CCD. It provides a method for updating the -STM32 without needing the special boot modes. This uses the [Chromium EC update -over -USB](../../docs/usb_updater.md) -method. The STM32 runs the code in -[`common/usb_update.c`](../../common/usb_update.c). -The host side code is in -[`extra/usb_updater/usb_updater2.c`](../../extra/usb_updater/usb_updater2.c) -and the -[`extra/usb_updater`](../../extra/usb_updater/) -directory contains additional scripts. - +STM32 without needing the special boot modes. This uses the +[Chromium EC update over USB](../../docs/usb_updater.md) method. The STM32 runs +the code in [`common/usb_update.c`](../../common/usb_update.c). The host side +code is in +[`extra/usb_updater/usb_updater2.c`](../../extra/usb_updater/usb_updater2.c) and +the [`extra/usb_updater`](../../extra/usb_updater/) directory contains +additional scripts. ## Using CCD on new designs |