Added commands to autodetect flash size mimicking what esptool.py does. It is called automatically after the stub is run.
Added bootloader patching on the fly of the flash parameters in the header bytes of the bootloader. In this iteration Flash Mode is always set to DIO and Flash Frequency to 40m. Flash Size is set to the autodetected value, if any, otherwise 4MB. The code checks for a magic bytes that indicate the image being flashed is a bootloader.
Replaced chip detection with reading form CHIP_DETECT_MAGIC_REG_ADDR register which is the way esptool.py does it currently.
To be added in the future:
Being able to pass FlashMode and FlashFrequency to flashData so that defaults DIO and 40m can be overridden. ESP-Web-tools would have to be able to pass these in some sort advanced mode? Otherwise there might be boards that cannot be flashed because those settings must be in the bootloader.
Esptool.py does one additional check to make sure the image being flashed is in fact a boot loader, just in case by chance a normal user image starts with the "magic header". This is pretty complex code and according to their comments it is a rare occurrence anyway, only more frequent when flashing encrypted images which eep-web-flasher does not support (yet, maybe ever).
Added commands to autodetect flash size mimicking what esptool.py does. It is called automatically after the stub is run.
Added bootloader patching on the fly of the flash parameters in the header bytes of the bootloader. In this iteration Flash Mode is always set to DIO and Flash Frequency to 40m. Flash Size is set to the autodetected value, if any, otherwise 4MB. The code checks for a magic bytes that indicate the image being flashed is a bootloader.
Replaced chip detection with reading form CHIP_DETECT_MAGIC_REG_ADDR register which is the way esptool.py does it currently.
To be added in the future:
Being able to pass FlashMode and FlashFrequency to flashData so that defaults DIO and 40m can be overridden. ESP-Web-tools would have to be able to pass these in some sort advanced mode? Otherwise there might be boards that cannot be flashed because those settings must be in the bootloader.
Esptool.py does one additional check to make sure the image being flashed is in fact a boot loader, just in case by chance a normal user image starts with the "magic header". This is pretty complex code and according to their comments it is a rare occurrence anyway, only more frequent when flashing encrypted images which eep-web-flasher does not support (yet, maybe ever).