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)

docs/en/api-reference/system/chip_revision.rst

@@ -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
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^