fix(pytest-embedded-qemu): Allowed QEMU RISCV flash image sizes (RDT-1177)

[Harshal5]

Description

Running a pytest test case using QEMU for ESP32-C3, produces the following error:

2025-02-27 20:22:56 INFO Executing qemu-system-riscv32 -nographic -machine esp32c3 -qmp tcp:127.0.0.1:53445,server,wait=off -drive file=/Users/harshal/esp/esp-idf/tools/test_apps/security/secure_boot/test/esp32c3_efuses.bin,if=none,format=raw,id=efuse -global driver=nvram.esp32c3.efuse,property=drive,value=efuse -global driver=timer.esp32c3.timg,property=wdt_disable,value=true -drive file=/Users/harshal/esp/esp-idf/tools/test_apps/security/secure_boot/build/flash_image.bin,if=mtd,format=raw
2025-02-27 20:22:56 esptool.py v4.9.dev5
2025-02-27 20:22:56 SHA digest in image updated
2025-02-27 20:22:56 Wrote 0x80000 bytes to file /Users/harshal/esp/esp-idf/tools/test_apps/security/secure_boot/build/flash_image.bin, ready to flash to offset 0x0
2025-02-27 20:22:56 
2025-02-27 20:22:56 Adding SPI flash device
2025-02-27 20:22:56 qemu-system-riscv32: Drive size error: only 2, 4, 8, and 16MB images are supported
2025-02-27 20:22:56 qemu-system-riscv32: -drive file=/Users/harshal/esp/esp-idf/tools/test_apps/security/secure_boot/build/flash_image.bin,if=mtd,format=raw: machine type does not support if=mtd,bus=0,unit=0

ESP32-C3 (riscv) QEMU seems to support only 2, 4, 8, and 16MB flash image sizes reference.

Related

Testing

---

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[hfudev]

LGTM. Thank you for the fix!

[igrr]

At this point, does it make sense to keep the supported flash sizes list different between Xtensa and RISC-V?

In QEMU, support of flash size for the specific machine is anyways implemented in each machine's source file, not once per architecture. So even for the same architecture, the lists could be different... So if we are making the lists different, then one list per target would make more sense than one per architecture.

[Harshal5]

So if we are making the lists different, then one list per target would make more sense than one per architecture.

True!

[hfudev]

@igrr I'll check how to improve this. Thanks for your insights!