ESP32 Forum

Am getting the below error while enabling secure boot in reflashable mode.

I (500) esp_image: !@simple hash: 075071f3
I (515) esp_image: !@Calculated secure boot hash: ec7257cb
W (534) esp_image: start_addr: 0x1000
W (547) esp_image: image_len: 0x7bd0
E (560) secure_boot: image has invalid signature version field 0xffffffff
E (583) esp_image: Secure boot signature verification failed
I (603) esp_image: Calculating simple hash to check for corruption...
I (647) esp_image: !@Calculated hash: 075071f3
W (648) esp_image: image valid, signature bad

Thanks for posting this issue. Are you using the current IDF master branch (V3.0-dev)? We're investigating a similar issue there.

I've gotten the same error while using one-time-flash secure boot as well. I was going to post a separate thread about it until I saw this in a search.

My output: I'm not sure if it's related, but when I enable encryption along with secure boot the issue seems to change, where I then get
I am using IDF 2.1.

Hi Daniel,

Thanks for letting us know about this:

d.cook wrote:

Code: Select all

E (1167) secure_boot: image has invalid signature version field 0xffffffff
E (1213) esp_image: Secure boot signature verification failed

This error matches the bug in the current V3.0-dev master branch. A fix should be available in the next couple of days.

However, I noticed you said you are using V2.1. The code which produces this log message (and the related regression) are not in V2.1, they were introduced after we branched for V3.0. The commit hash in the bootloader log you posted is "v2.0-rc1-1324-g93d228bf-dirty" which suggests maybe some hybrid version of IDF. Can you please check and clarify?

E (222) flash_parts: partition 0 invalid magic number 0x8282
E (280) boot: Failed to verify partition table
E (328) boot: load partition table error!
user code done

This error suggests that either encryption is enabled in efuse and the partition table wasn't correctly encrypted on flash (this can happen if, for example, the initial encrypt-in-place pass is interrupted by a power cycle or a reset), or it can suggest that encryption is not enabled in efuse but the partition table was already encrypted in place (in preparation for encryption to be enabled), before something went wrong.

The second is the most likely explanation I think, but to verify you can run "espefuse.py summary" and look at the value of the FLASH_CRYPT_CNT efuse. If it's still zero (encryption never enabled) then you can erase the flash and re-flash with plaintext data.

Thanks Angus, I'm just getting back around to looking into this again. I've updated the IDF to the latest---I'll report back with the results.

I double-checked the IDF version. I did have the latest version in my last post, however we have a fork of the IDF for integration with our internal build tools. When syncing with upstream I wasn't fetching the tags, so the git describe command to pull the IDF version was seeing the latest tag as only being 2.0. Ours probably isn't a common use case, but is there a more reliable way to build the IDF version string than relying on tags?

I may have some idea why I'm getting the 'invalid magic number' in the partition table.

When compiling the bootloader with secure boot enabled, the resulting binary is 30KB. However, the default offsets for the bootloader (0x1000) and the partition table (0x8000) only leaves ~28KB for the bootloader binary.

If you try and flash them all at once, you get an error about them overlapping. However, the default behaviour from esptool is that the bootloader is flashed separately when secure boot is enabled, thereby overwriting the partition table.

The remaining question is why the bootloader is becoming so large with secure boot enabled.

Hi Daniel,

d.cook wrote: I double-checked the IDF version. I did have the latest version in my last post, however we have a fork of the IDF for integration with our internal build tools. When syncing with upstream I wasn't fetching the tags, so the git describe command to pull the IDF version was seeing the latest tag as only being 2.0. Ours probably isn't a common use case, but is there a more reliable way to build the IDF version string than relying on tags?

We don't right now, although there are many more newer tags on our esp-idf master branch:
https://github.com/espressif/esp-idf/tags
(The current tag being v3.0-dev as this is the development version that master is working towards.)

You may need to review the merge strategy for your fork, to make it easier for you track the upstream. If there are any additional hooks in ESP-IDF that would make it easier to integrate with the tools you have without needing them to be part of the IDF tree itself (so you could have ESP-IDF as a submodule by itself, for example), then please let us know and we'll see if we can add support.

d.cook wrote:I may have some idea why I'm getting the 'invalid magic number' in the partition table.

When compiling the bootloader with secure boot enabled, the resulting binary is 30KB. However, the default offsets for the bootloader (0x1000) and the partition table (0x8000) only leaves ~28KB for the bootloader binary.

If you try and flash them all at once, you get an error about them overlapping. However, the default behaviour from esptool is that the bootloader is flashed separately when secure boot is enabled, thereby overwriting the partition table.

The remaining question is why the bootloader is becoming so large with secure boot enabled.

Yes, sorry for that. We're tracking both these issues (the lack of a proper error message when the bootloader grows too big, and the bootloader growing so big ion the first place.) But we don't have fixes right now.

Extra code is compiled into the bootloader when secure boot (and/or flash encryption) are turned on in menuconfig, and it can get too big. We've only ever seen this happen when the bootloader log level is set to "Debug" or higher. If you turn it back down then the bootloader should shrink.

We're working towards a proper fix for this.