"efuse blk rev" error with new bootloaders on qemu

[SFrijters]

I've read the similar issues that seem to have been resolved, but I'm still a bit out of my depth.

I maintain a "hello world" type example for running Rust code on the Espressif fork of qemu and I've updated to the freshly released espflash v4.0.0.

However, after this update I get the error below, bisected to the commit that updates to the IDF v5.4 bootloaders. In particular boot_comm: Image requires efuse blk rev >= v128.50, but chip is v1.3.

I'm using esp-hal at v1.0.0-beta.1 and the latest release of the espressif/qemu fork.

Currently I'm not sure if this is caused by something I need to update in my code, or if this is expected behaviour until qemu is somehow updated?
I read that a flash side of 64MB would be needed (if I indeed interpreted that correctly), but qemu refuses to allow that: qemu-system-riscv32: Drive size error: only 2, 4, 8, and 16MB images are supported. So if that is a new hard requirement I need to hold back the bootloader updates (things work with 4.0.0 with that single commit reverted).

I saw a proposed migration guide in one of the issues / PRs - something like that would be appreciated.

qemu-check-blinky> ELF 32-bit LSB executable, UCB RISC-V, RVC, soft-float ABI, version 1 (SYSV), statically linked, with debug_info, not stripped
qemu-check-blinky> Chip type:         esp32c3
qemu-check-blinky> Merge:             true
qemu-check-blinky> Skip padding:      false
qemu-check-blinky> App/part. size:    76,880/4,128,768 bytes, 1.86%
qemu-check-blinky> [2025-07-01T21:26:06Z INFO ] Image successfully saved!
qemu-check-blinky> esptool.py v4.8.1
qemu-check-blinky> File size: 4194304 (bytes)
qemu-check-blinky> Detected image type: ESP32-C3
qemu-check-blinky> 
qemu-check-blinky> ESP32-C3 image header
qemu-check-blinky> =====================
qemu-check-blinky> Image version: 1
qemu-check-blinky> Entry point: 0x403cc71a
qemu-check-blinky> Segments: 3
qemu-check-blinky> Flash size: 4MB
qemu-check-blinky> Flash freq: 40m
qemu-check-blinky> Flash mode: DIO
qemu-check-blinky> 
qemu-check-blinky> ESP32-C3 extended image header
qemu-check-blinky> ==============================
qemu-check-blinky> WP pin: 0xee (disabled)
qemu-check-blinky> Flash pins drive settings: clk_drv: 0x0, q_drv: 0x0, d_drv: 0x0, cs0_drv: 0x0, hd_drv: 0x0, wp_drv: 0x0
qemu-check-blinky> Chip ID: 5 (ESP32-C3)
qemu-check-blinky> Minimal chip revision: v0.3, (legacy min_rev = 3)
qemu-check-blinky> Maximal chip revision: v1.99
qemu-check-blinky> 
qemu-check-blinky> Segments information
qemu-check-blinky> ====================
qemu-check-blinky> Segment   Length   Load addr   File offs  Memory types
qemu-check-blinky> -------  -------  ----------  ----------  ------------
qemu-check-blinky>       0  0x01574  0x3fcd5820  0x00000018  DRAM, BYTE_ACCESSIBLE
qemu-check-blinky>       1  0x00c34  0x403cc710  0x00001594  IRAM
qemu-check-blinky>       2  0x02f64  0x403ce710  0x000021d0  IRAM
qemu-check-blinky> 
qemu-check-blinky> ESP32-C3 image footer
qemu-check-blinky> =====================
qemu-check-blinky> Checksum: 0x9c (valid)
qemu-check-blinky> Validation hash: cfab67036e267f185003b22c420398206a22fa2ca97386fe6ae7dbac43f5ce5c (valid)
qemu-check-blinky> 
qemu-check-blinky> Bootloader information
qemu-check-blinky> ======================
qemu-check-blinky> Bootloader version: 1
qemu-check-blinky> ESP-IDF: v5.4.1-426-g3ad36321ea
qemu-check-blinky> Compile time: Apr 24 2025 15:55:47
qemu-check-blinky> Adding SPI flash device
qemu-check-blinky> QEMU 9.2.2-20250228 monitor - type 'help' for more information
qemu-check-blinky> (qemu) q
qemu-check-blinky> ESP-ROM:esp32c3-api1-20210207
qemu-check-blinky> Build:Feb  7 2021
qemu-check-blinky> rst:0x1 (POWERON),boot:0x8 (SPI_FAST_FLASH_BOOT)
qemu-check-blinky> SPIWP:0xee
qemu-check-blinky> mode:DIO, clock div:2
qemu-check-blinky> load:0x3fcd5820,len:0x1574
qemu-check-blinky> load:0x403cc710,len:0xc34
qemu-check-blinky> load:0x403ce710,len:0x2f64
qemu-check-blinky> entry 0x403cc71a
qemu-check-blinky> I (0) boot: ESP-IDF v5.4.1-426-g3ad36321ea 2nd stage bootloader
qemu-check-blinky> I (0) boot: compile time Apr 24 2025 15:55:47
qemu-check-blinky> I (0) boot: chip revision: v0.3
qemu-check-blinky> I (0) boot: efuse block revision: v1.3
qemu-check-blinky> I (0) boot.esp32c3: SPI Speed      : 40MHz
qemu-check-blinky> I (0) boot.esp32c3: SPI Mode       : SLOW READ
qemu-check-blinky> I (0) boot.esp32c3: SPI Flash Size : 4MB
qemu-check-blinky> I (0) boot: Enabling RNG early entropy source...
qemu-check-blinky> I (1) boot: Partition Table:
qemu-check-blinky> I (1) boot: ## Label            Usage          Type ST Offset   Length
qemu-check-blinky> I (1) boot:  0 nvs              WiFi data        01 02 00009000 00006000
qemu-check-blinky> I (1) boot:  1 phy_init         RF data          01 01 0000f000 00001000
qemu-check-blinky> I (1) boot:  2 factory          factory app      00 00 00010000 003f0000
qemu-check-blinky> I (1) boot: End of partition table
qemu-check-blinky> I (1) esp_image: segment 0: paddr=00010020 vaddr=3c000020 size=01114h (  4372) map
qemu-check-blinky> E (2) boot_comm: Image requires efuse blk rev >= v128.50, but chip is v1.3
qemu-check-blinky> E (2) boot: Factory app partition is not bootable
qemu-check-blinky> E (2) boot: No bootable app partitions in the partition table
[... repeat ...]

[MabezDev]

You can build an custom bootloader with more relaxed efuse min versions, and pass it via the --bootloader flag.

[jessebraham]

You can build an custom bootloader with more relaxed efuse min versions, and pass it via the --bootloader flag.

I am almost certain that this is a red herring, the error relating to eFuse block version is likely caused from a missing app descriptor. I thought that we detected this, but I guess something is not working correctly.

[SFrijters]

Is this referring to 18a4e38 ? I did see that commit and tried to apply the suggestion but it didn't help, although I can't rule out that I messed that up while experimenting - I'll try it again.

In my emulation setup I never use the flash subcommand, only save-image. Maybe the warning should also be added for that situation?

[SFrijters]

Ok, the problem was on my end, probably mixed up some combination of probably "fixes": after only adding esp_bootloader_esp_idf::esp_app_desc!(); things now work.

However, I also did try to run the flash command without the fix to my code and since I don't have an actual device attached it errors out on that before getting to the app descriptor check. It would be nice to change the order there? To me it feels like as many checks as possible should be done before even trying to connect to the hardware.

Thanks for the assistance, and apologies for the noise.

[SergioGasquez]

I think we should still check if the app descriptor is there in save-image, can you give a try to https://github.com/SergioGasquez/espflash/tree/fix/app-descriptor-check (cargo install espflash --git https://github.com/SergioGasquez/espflash --branch fix/app-descriptor-check) and run the save-image command without the esp_bootloader_esp_idf::esp_app_desc!(); in your project:

You should now get:

Error:   × The app descriptor is not present in the `esp-hal` based project.
  │ You need to add the https://crates.io/crates/esp-bootloader-esp-idf to your project.

Instead of the misleading initial error you posted

[SFrijters]

You should now get:

Error:   × The app descriptor is not present in the `esp-hal` based project.
  │ You need to add the https://crates.io/crates/esp-bootloader-esp-idf to your project.

Instead of the misleading initial error you posted

Confirmed!

Although I must say (and this may be my ignorance showing), maybe it would be good to mention the esp_app_desc macro explicitly? That was not clear to me, were it not for the GitHub comment I linked above.