mirror of
https://github.com/espressif/esp-idf.git
synced 2026-10-01 18:50:34 +03:00
feat(bootloader): support to check efuse block revision
change(bootloader): remove ignore efuse check flag (temp) change(bootloader): use int for the minimum efuse blk rev (temp)
This commit is contained in:
laokaiyao
@@ -89,8 +89,8 @@ These APIs helps to get eFuse block revision from eFuses:
|
||||
|
||||
The following Kconfig definitions (in ``major * 100 + minor`` format) that can help add the eFuse block revision dependency to the code:
|
||||
|
||||
- :ref:`CONFIG_ESP_EFUSE_BLOCK_REV_MIN_FULL`
|
||||
- :ref:`CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL`
|
||||
- ``CONFIG_ESP_EFUSE_BLOCK_REV_MIN_FULL``
|
||||
- ``CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL``
|
||||
|
||||
.. _revision_limitation:
|
||||
|
||||
@@ -103,7 +103,7 @@ The minimum chip revision can be configured via the :ref:`CONFIG_{IDF_TARGET_CFG
|
||||
|
||||
The maximum chip revision cannot be configured and is automatically determined by the current ESP-IDF version being used. ESP-IDF will refuse to boot any chip revision exceeding the maximum chip revision. Given that it is impossible for a particular ESP-IDF version to foresee all future chip revisions, the maximum chip revision is usually set to ``maximum supported MAJOR version + 99``. The "Ignore Maximum Revision" eFuse can be set to bypass the maximum revision limitation. However, the software is not guaranteed to work if the maximum revision is ignored.
|
||||
|
||||
The eFuse block revision is similar to the chip revision, but it mainly affects the coefficients that are specified in the eFuse (e.g. ADC calibration coefficients). If eFuse block revision is not important in your application, you can also ignore this check by enabling :ref:`CONFIG_ESP_IGNORE_EFUSE_BLOCK_REV_CHECK`
|
||||
The eFuse block revision is similar to the chip revision, but it mainly affects the coefficients that are specified in the eFuse (e.g. ADC calibration coefficients).
|
||||
|
||||
Below is the information about troubleshooting when the chip revision fails the compatibility check. Then there are technical details of the checking and software behavior on earlier version of ESP-IDF.
|
||||
|
||||
@@ -141,7 +141,7 @@ For the chip revision, the 2nd stage bootloader and the application binary image
|
||||
For the eFuse revision, the requirements are stored in :cpp:type:`esp_app_desc_t`, which is contained in the application binary image. We only check the application image because the eFuse block revision mostly affects the ADC calibration, which does not really matter in the bootloader. There are 2 fields related to eFuse block revisions:
|
||||
|
||||
- ``min_efuse_blk_rev_full`` - Minimum eFuse block MINOR revision required by image in format: ``major * 100 + minor``. Its value is determined by ``CONFIG_ESP_EFUSE_BLOCK_REV_MIN_FULL``.
|
||||
- ``max_efuse_blk_rev_full`` - Maximum eFuse block MINOR revision required by image in format: ``major * 100 + minor``. Its value is determined by ``CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL``. Since it is a hardware specific value, it should not be changed by user. Espressif shall update it appropriately when a new eFuse block version is supported in ESP-IDF.
|
||||
- ``max_efuse_blk_rev_full`` - Maximum eFuse block MINOR revision required by image in format: ``major * 100 + minor``. Its value is determined by ``CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL``. It reflects whether the current IDF version supports this efuse block format or not, and should not be changed by the user.
|
||||
|
||||
Maximum And Minimum Revision Restrictions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@@ -154,12 +154,7 @@ The order for checking the minimum and maximum revisions during application boot
|
||||
|
||||
3. Then the 2nd stage bootloader checks the revision requirements of the application. It extracts the minimum and maximum revisions of the chip from the application image header, and the eFuse block from the segment header. Then the bootloader checks these versions against the chip and eFuse block revision from eFuses. If the these revisions are less than their minimum revision or higher than the maximum revision, the bootloader refuses to boot up and aborts. However, if the ignore maximum revision bit is set, the maximum revision constraint can be ignored. The ignore bits are set by the customer themselves when there is confirmation that the software is able to work with this chip revision or eFuse block revision.
|
||||
|
||||
4. Then at the start-up stage of the application image, the efuse block revision will be checked. The minimum and maximum requirements of the eFuse block revision come from the following Kconfig macros,
|
||||
|
||||
* :ref:`CONFIG_ESP_EFUSE_BLOCK_REV_MIN_FULL`
|
||||
* :ref:`CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL`
|
||||
|
||||
5. Furthermore, at the OTA update stage, the running application checks if the new software matches the chip revision and eFuse block revision. It extracts the minimum and maximum chip revisions from the header of the new application image and the eFuse block constraints from the application description to check against the these revisions from eFuses. It checks for revisions matching in the same way that the bootloader does, so that the chip and eFuse block revisions are between their min and max revisions (logic of ignoring max revision also applies).
|
||||
4. Furthermore, at the OTA update stage, the running application checks if the new software matches the chip revision and eFuse block revision. It extracts the minimum and maximum chip revisions from the header of the new application image and the eFuse block constraints from the application description to check against the these revisions from eFuses. It checks for revisions matching in the same way that the bootloader does, so that the chip and eFuse block revisions are between their min and max revisions (logic of ignoring max revision also applies).
|
||||
|
||||
Backward Compatibility with Bootloaders Built by Older ESP-IDF Versions
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
@@ -89,8 +89,8 @@ EFuse 块版本 API
|
||||
|
||||
下列 Kconfig 选项（格式为 ``major * 100 + minor``）可以将 eFuse 块版本依赖添加到代码中：
|
||||
|
||||
- :ref:`CONFIG_ESP_EFUSE_BLOCK_REV_MIN_FULL`
|
||||
- :ref:`CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL`
|
||||
- ``CONFIG_ESP_EFUSE_BLOCK_REV_MIN_FULL``
|
||||
- ``CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL``
|
||||
|
||||
.. _revision_limitation:
|
||||
|
||||
@@ -103,7 +103,7 @@ ESP-IDF 兼容性检查
|
||||
|
||||
最大芯片版本号无法指定，只能由当前使用的 ESP-IDF 版本自动决定。ESP-IDF 会拒绝启动任何超过最大芯片版本号的芯片版本。由于特定版本的 ESP-IDF 无法预知未来的芯片版本更新，因此最大芯片版本号通常设置为 ``maximum supported MAJOR version + 99``。可以设置 “忽略最大版本” eFuse 来绕过最大版本限制，但这不能确保软件正常工作。
|
||||
|
||||
EFuse 块版本号与芯片版本号类似，但是它主要影响在 eFuse 中指定的参数（如 ADC 校正参数等）。如果 eFuse 块版本号在您的应用中并不重要，你可以通过使能 Kconfig 选项 :ref:`CONFIG_ESP_IGNORE_EFUSE_BLOCK_REV_CHECK` 来禁用 eFuse 块版本号检查。
|
||||
EFuse 块版本号与芯片版本号类似，但是它主要影响在 eFuse 中指定的参数（如 ADC 校正参数等）。
|
||||
|
||||
下文介绍了芯片版本未通过兼容性检查时显示的故障排除信息及解决方法，并描述了在早期 ESP-IDF 版本中与软件行为和兼容性检查相关的技术细节。
|
||||
|
||||
@@ -141,7 +141,7 @@ EFuse 块版本号与芯片版本号类似，但是它主要影响在 eFuse 中
|
||||
而 eFuse 块版本的要求则存储在 :cpp:type:`esp_app_desc_t` 结构体中。该结构体对象位于应用程序的二进制进项文件中。由于 eFuse 块版本信息主要影响 ADC 校准，而二级引导程序的镜像不涉及 ADC，因此我们只需要检查应用程序镜像的 eFuse 块版本信息。有 2 个与 eFuse 块版本相关的字段：
|
||||
|
||||
- ``min_efuse_blk_rev_full`` - 镜像所需 eFuse 块的最小版本号，格式为 ``major * 100 + minor``。其值由 ``CONFIG_ESP_EFUSE_BLOCK_REV_MIN_FULL`` 确定。
|
||||
- ``max_efuse_blk_rev_full`` - 镜像所需 eFuse 块的最大版本号，格式为 ``major * 100 + minor``。其值由 ``CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL`` 确定。这个值由硬件决定，用户不应对其进行修改，仅当 ESP-IDF 支持新版本时由乐鑫官方进行更改。
|
||||
- ``max_efuse_blk_rev_full`` - 镜像所需 eFuse 块的最大版本号，格式为 ``major * 100 + minor``。其值由 ``CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL`` 确定。它反映了当前 ESP-IDF 版本能支持的最大 eFuse 块版本号，不应由用户修改。
|
||||
|
||||
最大和最小版本限制
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
@@ -154,12 +154,7 @@ EFuse 块版本号与芯片版本号类似，但是它主要影响在 eFuse 中
|
||||
|
||||
3. 然后，第 2 阶段引导启动程序会检查应用程序的版本要求。它从应用程序镜像的标头中读取支持的芯片最小和最大版本，以及从段的标头中读取 eFuse 块版本信息，并与 eFuse 中的芯片版本进行比较。如果该芯片版本或 eFuse 块版本低于各自的最小版本或高于最大版本，引导程序会拒绝启动并中止。然而，如果设置了忽略最大版本位，则可以忽略最大版本限制。软件确定可以使用此芯片版本时，用户可以自行设置忽略位。
|
||||
|
||||
4. 接着在应用程序的启动阶段将会检查 eFuse 块版本信息。允许的 eFuse 块最大和最小版本由以下 Kconfig 宏指定：
|
||||
|
||||
* :ref:`CONFIG_ESP_EFUSE_BLOCK_REV_MIN_FULL`
|
||||
* :ref:`CONFIG_ESP_EFUSE_BLOCK_REV_MAX_FULL`
|
||||
|
||||
5. 在空中升级 (OTA) 阶段，运行中的应用程序会检查新软件是否与芯片版本及 eFuse 块版本相匹配。它会从新应用程序镜像的标头中提取最小和最大芯片版本，以及应用程序描述中提取最大和最小 eFuse 块版本，并与 eFuse 中的芯片版本和块版本进行比较。应用程序检查版本匹配的方式与引导启动程序相同，即芯片版本和 eFuse 块版本须处在最小和最大版本之间（忽略最大版本的逻辑也相同）。
|
||||
4. 在空中升级 (OTA) 阶段，运行中的应用程序会检查新软件是否与芯片版本及 eFuse 块版本相匹配。它会从新应用程序镜像的标头中提取最小和最大芯片版本，以及应用程序描述中提取最大和最小 eFuse 块版本，并与 eFuse 中的芯片版本和块版本进行比较。应用程序检查版本匹配的方式与引导启动程序相同，即芯片版本和 eFuse 块版本须处在最小和最大版本之间（忽略最大版本的逻辑也相同）。
|
||||
|
||||
向后兼容旧版 ESP-IDF 构建的引导启动程序
|
||||
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
||||
|
||||
Reference in New Issue
Block a user