forked from espressif/esp-idf
Merge branch 'docs/update_cn_trans_for_2_system_docs' into 'master'
docs: Update CN translation for 2 system docs Closes DOC-9410 See merge request espressif/esp-idf!34845
This commit is contained in:
@@ -51,7 +51,7 @@ Default value of mbedTLS Rx buffer size is set to 16 KB. By using ``partial_http
|
||||
Signature Verification
|
||||
----------------------
|
||||
|
||||
For additional security, signature of OTA firmware images can be verified. For more information, please refer to :ref:`secure-ota-updates`.
|
||||
For additional security, signature of OTA firmware images can be verified. For more information, please refer to :ref:`secure-ota-updates`.
|
||||
|
||||
.. _ota_updates_pre-encrypted-firmware:
|
||||
|
||||
@@ -80,6 +80,7 @@ Design
|
||||
This whole workflow is managed by an external component `esp_encrypted_image <https://github.com/espressif/idf-extra-components/blob/master/esp_encrypted_img>`_ and it gets plugged into the OTA update framework through decryption callback (:cpp:member:`esp_https_ota_config_t::decrypt_cb`) mechanism.
|
||||
|
||||
.. note::
|
||||
|
||||
The supported scheme is based on RSA-3072 and the private key on device side must be protected using platform security features.
|
||||
|
||||
OTA System Events
|
||||
@@ -87,7 +88,7 @@ OTA System Events
|
||||
|
||||
ESP HTTPS OTA has various events for which a handler can be triggered by the :doc:`../system/esp_event` when the particular event occurs. The handler has to be registered using :cpp:func:`esp_event_handler_register`. This helps the event handling for ESP HTTPS OTA.
|
||||
|
||||
:cpp:enum:`esp_https_ota_event_t` has all the events which can happen when performing OTA upgrade using ESP HTTPS OTA.
|
||||
:cpp:enum:`esp_https_ota_event_t` has all possible events that can occur when performing OTA upgrade using ESP HTTPS OTA.
|
||||
|
||||
Event Handler Example
|
||||
^^^^^^^^^^^^^^^^^^^^^
|
||||
|
@@ -18,7 +18,7 @@ The following modes support OTA updates for certain partitions:
|
||||
|
||||
- Bootloader.
|
||||
- Partition table.
|
||||
- other data partitions like nvs, fat, etc.
|
||||
- Other data partitions like NVS, FAT, etc.
|
||||
|
||||
.. _ota_data_partition:
|
||||
|
||||
|
@@ -49,7 +49,7 @@ mbedTLS Rx buffer 的默认大小为 16 KB,但如果将 ``partial_http_downloa
|
||||
|
||||
|
||||
签名验证
|
||||
----------------------
|
||||
-----------------
|
||||
|
||||
要进一步提升安全性,还可以验证 OTA 固件镜像的签名。更多内容请参考 :ref:`secure-ota-updates`。
|
||||
|
||||
@@ -66,7 +66,7 @@ mbedTLS Rx buffer 的默认大小为 16 KB,但如果将 ``partial_http_downloa
|
||||
|
||||
* 即使设备未启用 flash 加密,仍可能要求进行 OTA 的固件镜像保持加密。
|
||||
|
||||
无论底层传输安全性如何,预加密固件的分发都能确保固件镜像在从服务器到设备的**传输过程中**保持加密状态。首先,预加密软件层在设备上通过网络接收并解密固件,然后使用平台 flash 加密(如果已启用)重新加密内容,最后写入 flash。
|
||||
无论底层传输安全性如何,预加密固件的分发都能确保固件镜像在从服务器到设备的 **传输过程中** 保持加密状态。首先,预加密软件层在设备上通过网络接收并解密固件,然后使用平台 flash 加密(如果已启用)重新加密内容,最后写入 flash。
|
||||
|
||||
设计
|
||||
^^^^
|
||||
@@ -80,6 +80,7 @@ mbedTLS Rx buffer 的默认大小为 16 KB,但如果将 ``partial_http_downloa
|
||||
整个工作流程由外部组件 `esp_encrypted_image <https://github.com/espressif/idf-extra-components/blob/master/esp_encrypted_img>`_ 管理,并通过解密回调 (:cpp:member:`esp_https_ota_config_t::decrypt_cb`) 机制插入到 OTA 更新框架中。
|
||||
|
||||
.. note::
|
||||
|
||||
该支持方案基于 RSA-3072,必须使用平台安全功能保护设备端的私钥。
|
||||
|
||||
OTA 系统事件
|
||||
@@ -150,6 +151,8 @@ ESP HTTPS OTA 过程中可能发生各种系统事件。当特定事件发生时
|
||||
|
||||
- :example:`system/ota/advanced_https_ota` 演示了如何在 {IDF_TARGET_NAME} 上使用 `esp_https_ota` 组件的 API 来使用 HTTPS OTA 更新功能。关于该示例适用的芯片,请参考 :example_file:`system/ota/advanced_https_ota/README.md`。
|
||||
|
||||
- :example:`system/ota/partitions_ota` 演示了如何使用 `esp_https_ota` 组件的 API 对多个分区(应用、引导加载程序、分区表、存储)进行 OTA 更新。
|
||||
|
||||
- :example:`system/ota/simple_ota_example` 演示了如何使用 `esp_https_ota` 组件的 API,通过特定的网络接口,如以太网或 Wi-Fi Station,在 {IDF_TARGET_NAME} 上进行固件升级。关于该示例适用的芯片,请参考 :example_file:`system/ota/simple_ota_example/README.md`。
|
||||
|
||||
API 参考
|
||||
|
@@ -8,9 +8,17 @@ OTA 流程概览
|
||||
|
||||
OTA 升级机制可以让设备在固件正常运行时根据接收数据(如通过 Wi-Fi、蓝牙或以太网)进行自我更新。
|
||||
|
||||
要运行 OTA 机制,需配置设备的 :doc:`../../api-guides/partition-tables`,该分区表至少包括两个 OTA 应用程序分区(即 ``ota_0`` 和 ``ota_1``)和一个 OTA 数据分区。
|
||||
以下模式支持对特定分区进行 OTA 更新:
|
||||
|
||||
OTA 功能启动后,向当前未用于启动的 OTA 应用分区写入新的应用固件镜像。镜像验证后,OTA 数据分区更新,指定在下一次启动时使用该镜像。
|
||||
- **安全更新模式**:可靠、稳定的分区更新,即使在更新期间断电,芯片仍能正常运行,并能够启动当前的应用程序。以下分区支持此模式:
|
||||
|
||||
- 应用程序分区。要进行 OTA 更新,需在设备的 :doc:`../../api-guides/partition-tables` 分区表中配置至少两个 OTA 应用程序分区槽(例如 ``ota_0`` 和 ``ota_1``)以及一个 OTA 数据分区。OTA 操作函数会将新的应用程序固件镜像写入当前未被选为启动分区的 OTA 应用程序分区槽。镜像验证通过后,OTA 数据分区将被更新,以指定在下次启动时使用该镜像。
|
||||
|
||||
- **非安全更新模式**:此更新过程容易受到干扰,如果在更新过程中断电,可能会导致当前应用程序无法加载,甚至进入无法恢复的状态。在此模式下,新的镜像会先下载到临时分区,下载完成后复制到最终的目标分区。如果在最终复制过程中发生中断,可能会导致问题。以下分区支持此模式:
|
||||
|
||||
- 引导加载程序
|
||||
- 分区表
|
||||
- 其他数据分区,如 NVS、FAT 等
|
||||
|
||||
.. _ota_data_partition:
|
||||
|
||||
|
Reference in New Issue
Block a user