Merge branch 'bugfix/minor_doc_formatting_sbv2' into 'master'

docs: secure_boot_v2: fix minor formatting for target based note

See merge request espressif/esp-idf!14470
This commit is contained in:
Mahavir Jain 2021-07-23 13:47:42 +00:00
commit f017d6b89a
2 changed files with 2 additions and 2 deletions

View File

@ -895,7 +895,7 @@ For example, these are the steps to encrypt the file ``build/my-app.bin`` to fla
.. code-block:: bash
espsecure.py encrypt_flash_data --aes-xts --keyfile /path/to/key.bin --address 0x10000 --output my-app-ciphertext.bin build/my-app.bin
espsecure.py encrypt_flash_data --aes_xts --keyfile /path/to/key.bin --address 0x10000 --output my-app-ciphertext.bin build/my-app.bin
The file ``my-app-ciphertext.bin`` can then be flashed to offset 0x10000 using ``esptool.py``. To see all of the command line options recommended for ``esptool.py``, see the output printed when ``idf.py build`` succeeds.

View File

@ -348,7 +348,7 @@ In this mode, the public key which is present in the signature block of the curr
For this reason, it's essential that the initial app flashed to the device is also signed. A check is run on app startup and the app will abort if no signatures are found. This is to try and prevent a situation where no update is possible. The app should have only one valid signature block in the first position. Note again that, unlike hardware Secure Boot V2, the signature of the running app isn't verified on boot. The system only verifies a signature block in the first position and ignores any other appended signatures.
only:: not esp32
.. only:: not esp32
Although multiple trusted keys are supported when using hardware Secure Boot, only the first public key in the signature block is used to verify updates if signature checking without Secure Boot is configured. If multiple trusted public keys are required, it's necessary to enable the full Secure Boot feature instead.