esp8266-01 no network

[drunkscientist]

so im trying to upload the precompiled binaries to an 8266-01, has 1MB flash (8Mbit), and flashing AT firmwares went fine. but when i flash the 0x00 and 0x02 files (extracted from zip archive) to their corresponding locations, no new AP appears after reset. in fact when i reset i get serial output at 75880 baud, which i understand usually comes from the bootloader, it gives some checksums, flash settings, but at the end i get Rom 0 is bad. Rom 1 is bad. No good rom available. user code done
QIO and DIO have the same result. also tried including 0x08 file, no change. am i missing something obvious?

[martin-ger]

I just double checked: the current build work fine on my ESP-01 with the settings:
esptool.py --port /dev/ttyUSB0 --baud 115200 write_flash -ff 40m -fm dio -fs 8m 0x00000 firmware/0x00000.bin 0x02000 firmware/0x02000.bin

Obviously the rboot works fine for you, but something is wrong with 0x02000.bin.

[drunkscientist]

ok so at least it isnt something obvious. ill probably spend tonight or tomorrow repairing my linux partition and try with esptool.py. mega thanks for the quick reply btw!

[martin-ger]

Tried with another ESP-01. Somewhat strange behavior. When I cleared the flash with
esptool.py --port /dev/ttyUSB0 --baud 115200 erase_flash
it worked.

[drunkscientist]

ok so, first i used the windows flash download tool to erase flash, then switched to an old laptop running lubuntu. after some fiddling with python dependencies i got esptool installed. i redownloaded a new zip archive of files, extracted 0x00 and 0x02, and ran
esptool --port /dev/ttyUSB0 --baud 115200 write_flash -ff 80m -fm dio -fs 8m 0x00000 firmware/0x00000.bin 0x02000 firmware/0x02000.bin, which failed: waiting for packet header. so i tried them individually:
esptool --port /dev/ttyUSB0 --baud 115200 write_flash -ff 80m -fm dio -fs 8m 0x00000 firmware/0x00000.bin actually worked, despite having -ff 80m instead of 40m. i realized that after 0x02 file had the same failure, waiting for packet header. at this point i tried to enter esptool.py --port /dev/ttyUSB0 --baud 115200 erase_flash and got an error 'esp8266 ROM does not support function erase_flash'...? the packet error is apparantly usually linked to power issues, but it works for the 0x00 boot file, and its the same usb/ch340g adapter, just plugged into a laptop instead of the 3+feet of usb extension/unpowered hub, where it works for windows flashing. do i need to rebuild it or something? not exactly a linux expert but i know enough to be mad that all these commands needed sudo...

[drunkscientist]

in a tutorial somewhere i found what appear to be files for an older version of this labeled 0x00 and 0x40, i saw something mentioned upstream @rubfi esp-wifi-repeater 'firmware compiled with the V2.0.0 SDK fails to start on some ESP-01 modules.' im not against recompiling with an older SDK, but i would prefer not to. could the issue be related to the issues with 'puya' flash chips mentioned here? i only have the compiled binaries from some random source that i dont really trust, but it does technically work

[martin-ger]

As far as I understand the posting, this is an SPIFFS issue. I don't use SPIFFS, but the rboot and the esp_wifi_repeater use flash writes. Up to now, I was not aware of problems here...

The old firmware was due to different esp_init_data_default sectors. Now I am flashing that data as a first step. Maybe this fails? You might try the latest firmware I compiled without this step (try firmware_sdk_1.5.4) for the ESP-01 from here:

https://github.com/martin-ger/esp_wifi_repeater/tree/e220e19a54f6d286c920623da26ed468e70149d9

[drunkscientist]

the issue is seen with SPIFFS, but is caused by the specific flash chip, there was a manufacturer change or something. I cant help but wonder if that chip isnt the reason it works on your esp-01s but not mine, as it is a more recent thing found only with newer esps. i had an issue with a different project, not using spiffs, but where spiffs was the old method. after the fallback method failed (SPIFFS) i found the thread talking about the puya chips, changed whatever flag to support it and everything started working as expected, so the puya issue definately extends past just SPIFFS, and lies in the flash chip itself. id try rebuilding it, but i dont fully understand the build process.. if i understand things correctly the arduino IDE has an esp SDK(or uses the base one somehow), and i know i changed something in it to properly support the puya chip, can i build this using the arduino IDE? if im exporting compiled binaries and uploading with esp official flash tool, then the rboot is the 0x00 file and esp_wifi_repeater is the 0x20? i get a little confused with the file names

[devyte]

Our Arduino core now has Puya support enabled by default. The change will be in the next core release 2.6.0. We're not sure about a release date yet, though.
Or you can try building against latest master branch, if you're feeling adventurous.

[martin-ger]

The esp_wifi_repeater builds only with the plain NONSDK, not with Arduino. (There are 3 binaries: 0x00000.bin - rboot, 0x02000.bin - the repeater, and 0x82000 - the alternative repeater for OTA update.).

If I understand the PUYA fix, I will try to add it to the build process. Any doc on that?

[devyte]

Ah, for some reason I thought this was built on Arduino (haven't looked at a single line of code yet, I expected to do so at some point :p).
No doc, but the the relevant issue explains the problem and the Proof of Concept solution, and the final PR that was merged is pretty clean.
The original solution caused a rather bad overhead for non PUYA chip boards, but the final solution that was implemented reduced that to an if statement somewhere.

[drunkscientist]

this is as thorough a discussion as i could find, hope it helps

[martin-ger]

Tried to add PUYA support with this thread in this branch https://github.com/martin-ger/esp_wifi_repeater/tree/puya
However, I guess rboot also needs an upgrade, as it also uses flash writes. The problem is, I can't test that as I have no PUYA chips as far as I know.

You might give it a try, I assume, at least OTA will fail, but perhaps it starts normally...

[drunkscientist]

still getting no good rom available from the bootloader, at least from windows. my linux laptop is on loan but i should be able to get that back tomorrow to try from there

[drunkscientist]

so i could not get the new files to run either. im closing the issue because the old build does work, i trust the source, and ultimately the krack vulnerability i was trying to avoid is probably in my old router/modem thing anyway. the more i look at this chip the less confident i am that i have a puya chip, i dont think its origional but i dont know/care enough about the issue to keep fighting with it