{IDF_TARGET_FLASH_FREQ_F:default="80", esp32c2="60", esp32h2="48"}
{IDF_TARGET_FLASH_FREQ_0:default="40", esp32c2="30", esp32h2="24"}
{IDF_TARGET_FLASH_FREQ_1:default="26", esp32c2="20", esp32h2="16"}
{IDF_TARGET_FLASH_FREQ_2:default="20", esp32c2="15", esp32h2="12"}
{IDF_TARGET_BOOTLOADER_OFFSET:default="0x0", esp32="0x1000", esp32s2="0x1000", esp32p4="0x2000"}
This is technical documentation for the firmware image format used by the ROM bootloader. These are the images created by esptool.py elf2image.
esp8266
The firmware file consists of a header, a variable number of data segments and a footer. Multi-byte fields are little-endian.
not esp8266
The firmware file consists of a header, an extended header, a variable number of data segments and a footer. Multi-byte fields are little-endian.
The image header is 8 bytes long:
esp8266
| Byte | Description |
|---|---|
| 0 | Magic number (always 0xE9) |
| 1 | Number of segments |
| 2 | SPI Flash Mode (0 = QIO, 1 = QOUT, 2 = DIO, 3 = DOUT) |
| 3 | High four bits - Flash size ( Low four bits - Flash frequency ( |
| 4-7 | Entry point address |
esp32s2 or esp32s3 or esp32p4
| Byte | Description |
|---|---|
| 0 | Magic number (always 0xE9) |
| 1 | Number of segments |
| 2 | SPI Flash Mode (0 = QIO, 1 = QOUT, 2 = DIO, 3 = DOUT) |
| 3 | High four bits - Flash size ( Low four bits - Flash frequency ( |
| 4-7 | Entry point address |
esp32c6
| Byte | Description |
|---|---|
| 0 | Magic number (always 0xE9) |
| 1 | Number of segments |
| 2 | SPI Flash Mode (0 = QIO, 1 = QOUT, 2 = DIO, 3 = DOUT) |
| 3 | High four bits - Flash size ( Low four bits - Flash frequency ( |
| 4-7 | Entry point address |
Note
Flash frequency with value 0 can mean either 80MHz or 40MHz based on MSPI clock source mode.
not (esp8266 or esp32c6 or esp32s3 or esp32s2 or esp32p4)
| Byte | Description |
|---|---|
| 0 | Magic number (always 0xE9) |
| 1 | Number of segments |
| 2 | SPI Flash Mode (0 = QIO, 1 = QOUT, 2 = DIO, 3 = DOUT) |
| 3 | High four bits - Flash size ( Low four bits - Flash frequency ( |
| 4-7 | Entry point address |
esptool.py overrides the 2nd and 3rd (counted from 0) bytes according to the SPI flash info provided through the command line option. These bytes are only overridden if this is a bootloader image (an image written to a correct bootloader offset of {IDF_TARGET_BOOTLOADER_OFFSET}), in this case, the appended SHA256 digest is also updated to reflect the header changes. Generating images without SHA256 digest can be achieved by running esptool.py elf2image with the --dont-append-digest argument.
esp8266
Individual segments come right after this header.
not esp8266
The 16-byte long extended header comes right after the image header, individual segments come right after it:
| Byte | Description |
|---|---|
| 0 | WP pin when SPI pins set via efuse (read by ROM bootloader) |
| 1-3 | Drive settings for the SPI flash pins (read by ROM bootloader) |
| 4-5 | Chip ID (which ESP device is this image for) |
| 6 | Minimal chip revision supported by the image (deprecated, use the following field) |
| 7-8 | Minimal chip revision supported by the image (in format: major * 100 + minor) |
| 9-10 | Maximal chip revision supported by the image (in format: major * 100 + minor) |
| 11-14 | Reserved bytes in additional header space, currently unused |
| 15 | Hash appended (If 1, SHA256 digest is appended after the checksum) |
| Byte | Description |
|---|---|
| 0-3 | Memory offset |
| 4-7 | Segment size |
| 8...n | Data |
The file is padded with zeros until its size is one byte less than a multiple of 16 bytes. A last byte (thus making the file size a multiple of 16) is the checksum of the data of all segments. The checksum is defined as the xor-sum of all bytes and the byte 0xEF.
not esp8266
If hash appended in the extended file header is 0x01, a SHA256 digest “simple hash” (of the entire image) is appended after the checksum. This digest is separate to secure boot and only used for detecting corruption. The SPI flash info cannot be changed during flashing if hash is appended after the image.
If secure boot is enabled, a signature is also appended (and the simple hash is included in the signed data). This image signature is Secure Boot V1 and Secure Boot V2 specific.
To analyze a binary image and get a complete summary of its headers and segments, use the image_info <image-info> command with the --version 2 option.