Skip to content

Commit

Permalink
Merge branch 'docs/update_USB-OTG_ESP32S2_ESP32S3' into 'master'
Browse files Browse the repository at this point in the history
updated USB_OTG in dfu.rst, usb_device.rst and secure-boot-v2.rst

Closes DOC-3565

See merge request espressif/esp-idf!20144
  • Loading branch information
Lindazhxy committed Dec 27, 2022
2 parents b043c55 + 9c0d573 commit ae639f6
Show file tree
Hide file tree
Showing 4 changed files with 9 additions and 7 deletions.
2 changes: 1 addition & 1 deletion docs/en/api-guides/dfu.rst
Expand Up @@ -5,7 +5,7 @@ Device Firmware Upgrade via USB

Typically, the firmware of the {IDF_TARGET_NAME} is flashed via the chip's serial port. However, flashing via the serial port requires a USB to serial converter chip (e.g., CP210x or FTDI) to be connected to the {IDF_TARGET_NAME} (see :doc:`Establish Serial Connection with {IDF_TARGET_NAME} <../get-started/establish-serial-connection>` for more details). The {IDF_TARGET_NAME} contains a USB OTG peripheral making it possible to connect the {IDF_TARGET_NAME} to the host directly via USB (thus not requiring a USB to serial converter chip).

Device Firmware Upgrade (DFU) is a mechanism for upgrading the firmware of the {IDF_TARGET_NAME} directly via the Universal Serial Bus (USB).
Device Firmware Upgrade (DFU) is a mechanism for upgrading the firmware of the {IDF_TARGET_NAME} directly via the Universal Serial Bus (USB). However, enabling Secure Boot or flash encryption disables the USB-OTG USB stack in the ROM, disallowing updates via the serial emulation or DFU on that port.

- :ref:`get-started-get-prerequisites` of the Getting Started Guide introduces the software requirements of DFU.
- Section :ref:`api_guide_dfu_build` describes how to build firmware for DFU with ESP-IDF.
Expand Down
4 changes: 2 additions & 2 deletions docs/en/api-reference/peripherals/usb_device.rst
Expand Up @@ -15,7 +15,7 @@ The driver allows you to use {IDF_TARGET_NAME} chips to develop USB devices on a

TinyUSB stack is distributed via `IDF Component Registry <https://components.espressif.com/components/espressif/esp_tinyusb>`_.

Our USB-OTG implementation is limited to {IDF_TARGET_USB_EP_NUM} USB endpoints ({IDF_TARGET_USB_EP_NUM_INOUT} IN/OUT endpoints and {IDF_TARGET_USB_EP_NUM_IN} IN endpoint) - find more information in `technical reference manual <{IDF_TARGET_TRM_EN_URL}>`_.
Our USB-OTG implementation is limited to {IDF_TARGET_USB_EP_NUM} USB endpoints ({IDF_TARGET_USB_EP_NUM_INOUT} IN/OUT endpoints and {IDF_TARGET_USB_EP_NUM_IN} IN endpoint) . Please note that enabling Secure Boot or flash encryption disables the USB-OTG USB stack in the ROM, disallowing updates via the serial emulation or Device Firmware Update (DFU) on that port. For more details, please refer to `technical reference manual <{IDF_TARGET_TRM_EN_URL}>`_.

Features
--------
Expand All @@ -38,7 +38,7 @@ On {IDF_TARGET_NAME}, connect GPIO {IDF_TARGET_USB_DP_GPIO_NUM} and {IDF_TARGET_

.. figure:: ../../../_static/usb-board-connection.png
:align: center
:alt: Connection of an ESP board to a USB host
:alt: Connection of an ESP board to a USB host
:figclass: align-center

Self-powered devices must also connect VBUS through voltage divider or comparator, more details in :ref:`self-powered-device` subchapter.
Expand Down
8 changes: 5 additions & 3 deletions docs/en/security/secure-boot-v2.rst
Expand Up @@ -72,7 +72,7 @@ Secure Boot V2 Process

This is an overview of the Secure Boot V2 Process. Instructions how to enable Secure Boot are supplied in section :ref:`secure-boot-v2-howto`.

Secure Boot V2 verifies the bootloader image and application binary images using a dedicated *signature block*. Each image has a separately generated signature block which is appended to the end of the image.
Secure Boot V2 verifies the bootloader image and application binary images using a dedicated *signature block*. Each image has a separately generated signature block which is appended to the end of the image.

.. only:: esp32

Expand All @@ -86,13 +86,13 @@ Secure Boot V2 verifies the bootloader image and application binary images using

Up to 3 signature blocks can be appended to the bootloader or application image in {IDF_TARGET_NAME}.

Each signature block contains a signature of the preceding image as well as the corresponding {IDF_TARGET_SBV2_KEY} public key. For more details about the format, refer to :ref:`signature-block-format`. A digest of the {IDF_TARGET_SBV2_KEY} public key is stored in the eFuse.
Each signature block contains a signature of the preceding image as well as the corresponding {IDF_TARGET_SBV2_KEY} public key. For more details about the format, refer to :ref:`signature-block-format`. A digest of the {IDF_TARGET_SBV2_KEY} public key is stored in the eFuse.

The application image is not only verified on every boot but also on each over the air (OTA) update. If the currently selected OTA app image cannot be verified, the bootloader will fall back and look for another correctly signed application image.

The Secure Boot V2 process follows these steps:

1. On startup, the ROM code checks the Secure Boot V2 bit in the eFuse. If Secure Boot is disabled, a normal boot will be executed. If Secure Boot is enabled, the boot will proceed according to the following steps.
1. On startup, the ROM code checks the Secure Boot V2 bit in the eFuse. If Secure Boot is disabled, a normal boot will be executed. If Secure Boot is enabled, the boot will proceed according to the following steps.

2. The ROM code verifies the bootloader's signature block (:ref:`verify_signature-block`). If this fails, the boot process will be aborted.

Expand Down Expand Up @@ -322,6 +322,8 @@ Restrictions after Secure Boot is enabled

- After Secure Boot is enabled, no further eFuses can be read protected. (If :doc:`/security/flash-encryption` is enabled then the bootloader will ensure that any flash encryption key generated on first boot will already be read protected.) If :ref:`CONFIG_SECURE_BOOT_INSECURE` is enabled then this behavior can be disabled, but this is not recommended.

- Please note that enabling Secure Boot or flash encryption disables the USB-OTG USB stack in the ROM, disallowing updates via the serial emulation or Device Firmware Update (DFU) on that port.

.. _secure-boot-v2-generate-key:

Generating Secure Boot Signing Key
Expand Down
2 changes: 1 addition & 1 deletion docs/zh_CN/api-guides/dfu.rst
Expand Up @@ -5,7 +5,7 @@

一般情况下,{IDF_TARGET_NAME} 的固件是通过芯片的串口烧录。但是,通过串口烧录 {IDF_TARGET_NAME} 需要连接 USB 转串口转换器(如 CP210x 或 FTDI),详细信息可参阅 :doc:`与 {IDF_TARGET_NAME} 创建串口连接<../get-started/establish-serial-connection>`。{IDF_TARGET_NAME} 包含一个 USB OTG 外设,使其可以通过 USB 将 {IDF_TARGET_NAME} 直接连接到主机,即不需要 USB 转串口转换器也可完成烧录。

设备固件升级 (DFU) 是一种通过通用串行总线 (USB) 升级设备固件的机制。
设备固件升级 (DFU) 是一种通过通用串行总线 (USB) 升级设备固件的机制。但是,启用安全启动 (Secure Boot) 或 flash 加密会禁用 ROM 中的 USB-OTG USB 堆栈,则无法通过该端口上的模拟串口或 DFU 进行更新。

- 入门指南中的 :ref:`get-started-get-prerequisites` 介绍了 DFU 的软件要求。
- :ref:`api_guide_dfu_build` 章节介绍了如何使用 ESP-IDF 构建固件。
Expand Down

0 comments on commit ae639f6

Please sign in to comment.