Useful when we need to write eFuses with several different commands,
the BURN operation will be done once at the end.
espefuse.py -c esp32c2 --virt --do-not-confirm \
burn_key_digest secure_images/ecdsa256_secure_boot_signing_key_v2.pem \
burn_key BLOCK_KEY0 images/efuse/128bit_key XTS_AES_128_KEY_DERIVED_FROM_128_EFUSE_BITS
Refactors the espefuse.py and adds support ESP32-S2 chip.
CMDs|ESP32|ESP32-S2|Batch burn mode|
dump|+|+|
summary|+|+|
read_protect_efuse|+|+|+|
write_protect_efuse|+|+|+|
burn_efuse|+|+|+|
burn_key|+|+|+|
burn_block_data|+|+|+|
burn_key_digest|+|+|+|
get_custom_mac|+|-|not support|
burn_custom_mac|+|-|not support|
set_flash_voltage|+|+|
adc_info|+|+|
burn_bit|+|+|
- Refactored corresponding with the new structure (see picture above)
- Using the bitstring lib to operate fields and blocks easy.
- Reading only once all blocks at init time. (No need to read each field separately)
- Burning through burn_all(). It analyzes errors and the possibility to write the new value of blocks. This approach allows us to save necessary efuses or blocks and burn them in once time. Applying the coding scheme is done in burn_all(). Not necessary to do the special conversion as it was for burn_custom_mac.
- To burn the new value of efuses/blocks need to call: efuse1.save(new_value1) ... efuseN.save(new_valueN) efuses.burn_all().
- Added the new command - set_bit. ./espefuse.py set_bit BLOCK10 0 1 2 4 8 16 32 64 96 128 160 192 224 255
- Unlike the previous !40 (closed) MR this MR has support set_flash_voltage and adc_info commands. Need to check format with esp32_s2_calibration.pdf
- Added a check of the burn values of blocks and fields. The burn is going from HI_num block to LOW_num block. It allows to read back burn block/field and compare it with expected writing value.
- Improved the description of messages to give the user understanding of what is going on.
- Added the new feature to save the whole dump of blocks to files, and after to burn those files with burn_block_data. Useful for testing.
- Added debug mode: flag -d, --debug. Prints more msgs.
- Implemented the approach if we need to hid some fields from the user depend on another. (see MAC_VERSION, BLOCK2_VERSION - calibration ADC)
- read_protect_efuse, write_protect_efuse, burn_efuse, burn_key, burn_block_data, burn_key_digest support the batch burn mode.
- Updated test_espefuse.py (ESP32, ESP32-S2)
Closes: ESPTOOL-4, ESPTOOL-10
* Add support for `burn_key` with 192-bit keys (3/4 Coding Scheme) and 256-bit (standard Coding
Scheme)
Also fix some inconsistency in key data representation:
* The order of bytes used by hardware AES is reversed compared to conventional byte order
in EFUSE registers. (This is true for both 256-bit and 192-bit keys.)
* So when flashing via `burn_key`, the byte order is automatically reversed before the key is
written.
* Previously, "espefuse.py summary" would reverse the byte order when displaying block contents, for
consistency with the original key file, but it now shows the "real" byte order (ie reversed
bytes).
* EfuseKeyblockField class now has burn_key() & get_key() methods (work with a standard AES key
format, ie swap bytes when reading/writing efuse). The original burn() and get() methods return
the "real" byte order.
* For most users this won't make a difference as the key in efuse is read protected anyhow.
This additional command requires an external entity to already have
modified the baud rate of the ESP32 to match, or this has to be
against a "pass through" entity which runs at this higher baud rate.
Signed-off-by: Tim Nordell <tim.nordell@nimbelink.com>
We have a board designed which has the UART to the ESP32 as a passthrough from
another microcontroller. As such, it's easier to send the sync sequence and
change the baud rate on the microcontroller side of things than to pass this
change through from the PC. Adding this new option allows the intermediate
microcontroller to run the sync sequence and to set the appropriate baud rate
on the ESP32 side of things. For this use case, we need to avoid sending the
change baud rate sequence (the PC baud rate is not necessarily the same as
the microcontroller <-> ESP32) and avoid sending the sync sequence.
Signed-off-by: Tim Nordell <tim.nordell@nimbelink.com>
