Open erhankur opened 1 year ago
The current test shows that this scheme supports the ESP32-C series and ESP32-S3 chips. When this scheme is applied to ESP32, the volume of the corresponding bootloader.bin
will increase a lot, resulting in the inability to use secure boot.
Secure boot is an optional feature. I did not enable it but it still doesn't work on ESP32. Probably I miss something.
Also, I tried to build for ESP32-S3 but got iram overflow error. I am using idf master.
python $IDF_PATH/tools/idf_size.py build/bootloader/bootloader.map
Total sizes:
Used stat D/IRAM: 29968 bytes ( -1296 remain, 104.5% used) Overflow detected! You can run idf.py size-files for more information.
.data size: 28 bytes
.bss size: 472 bytes
.text size: 23312 bytes
.rodata size: 6156 bytes
Total image size: 29496 bytes (.bin may be padded larger)
Do we need a custom linker like ESP32-Cx chips?
When using ESP32S3, please compile it on the v4.4 version of IDF. There is no official stable version of the master branch.
Thanks @WangYuxin-esp .
Really good work. I think, this is hidden repo and deserves more attention. I believe most of the users will like it, especially those who have a connection via the gsm modem.
And my last question; What is the status of ESP32? Again should I test it with v4.4?
@erhankur Yes, for ESP32, you can use this scheme with v4.4 IDF.
I could compile and start the bootloader w/ ESP32.. No further tests done though. The real neccessety is to simply extend the space for the bootloader
I tried differential OTA on ESP32 but didn't work. ESP32-C3 is OK.
Can we clarify exactly which targets are supported for which features?