ESP8266 Community Forum

The binary blob of esptool.py is unnecessary for flashing, it's only there to speed up the upload.

That being said, there still is the other esptool around, which is written in C.
I haven't looked at the source, but in theory it should be possible to port the code to run on an ESP with a reasonable amount of work by replacing the serial & file access code.

lethe wrote:The binary blob of esptool.py is unnecessary for flashing, it's only there to speed up the upload.

Tell me more!

What binary blob are you exactly referring to, the code that is uploaded to the esp8266 (to be programmed)? You say that part is actually not required?

What is the impact if you leave it out?

In fact uploading the binary blob isn't the biggest challenge I'm seeing. It's more the reverse engineering of the whole protocol. Which may or may not be complex, I am not sure yet. Maybe someone has documented that more or less somewhere?

Porting existing code will be next to impossible anyway, as code on the esp8266 needs to run non-blocking, something host-side tools mostly don't need and don't implement. Also the code needs to be integrated in my existing firmware.

eriksl wrote:What binary blob are you exactly referring to, the code that is uploaded to the esp8266 (to be programmed)? You say that part is actually not required?

Yes, see: https://github.com/espressif/esptool/bl ... /README.md

What is the impact if you leave it out?

Dunno, I never compared the two methods. All I know is, that older esptool.py versions don't have that code.

Hmmm, that makes it even more complex, because now I have to find out what was the original protocol and if that supports e.g. reading the mac address or verifying after flasing, checksumming...