ESP8266 Community Forum

From "what we know so far"

Squonk wrote:From the cited document, the available bootstraps are:

• GPIO15=1 => SDCard startup
• GPIO15=0 + GPIO2=1 + GPIO0=0 => UART download
• GPIO15=0 + GPIO2=1 + GPIO0=1 => Flash startup

if this is correct we should see the Flash startup configuration on all common boards, right?

To give you some guidance on my thoughts:
from the "esp_iot_sdk_v0.6 / include / eagle_soc.h" file we know:
GPIO15 = TDO, other pins are obvious from the (not so good) schematic.

by the looks of it, no pulling resistors on GPIOs 15, 2 and 0 are present --> internal pulling resitors are used to trigger this configuration without external components.

To boot from UART:
GPIO0 must be pulled low. ... so soldering is required here. But this should be it (besides guessing the correct baudrate for the bootloader, but the variations are finite)!

Once one has accomplished this soldering, the XTCOM_UTILITY from the VM can be used to:

• program the SPI flash
• read from arbitrary adress (dumping internal ROM for later using in QEMU )*
• load application binary to ram and run it
• other options shown in the XTCOM_UTILITY

*does some one know a trick to automate the writing and reading to/from windows forms like the one used in XTCOM_UTIL? would be nice to dump the internal ROM contents address by address

all this is pure speculation based on some experiences i've made so far with other ICs. feel free to correct me

That's great. Update via UART is a very convenient feature.
I'm wondering if one could write the firmware directly to the Flash IC. It appears to be a standard serial flash IC whose interface is very well known. I am not sure how ESP8266 uses external Flash. Does it simply write the firmware starting from the first flash block, does it write additional data other than the firmware, etc. If it is simply writing a firmware blob starting from a fixed address, it would be very easy to directly program the flash without having to solder anything to the tiny QFN pads.