Closed brilthor closed 3 years ago
tried building under a linux environment and got identical binaries:
[<redacted>@<redacted> bootstrap-firmware]$ md5sum .pio/build/app/*
1788b814616db014e04a148e09258c04 .pio/build/app/firmware.elf
md5sum: .pio/build/app/src: Is a directory
2cf8620c715fd44ee4ac6afaf3ece17d .pio/build/app/user1.bin
1788b814616db014e04a148e09258c04 .pio/build/app/user1.elf
89d9279b199f20c57b6f5f874247e9d9 .pio/build/app/user2.bin
1788b814616db014e04a148e09258c04 .pio/build/app/user2.elf
Thanks. Took a look and the image's CRC aren't matching up:
flash_crc = 2746132336
img_crc = 1548834960
upgrade_check
cs_switch_on_upgrade_completed, result:1
These should match.
I'm also able to reproduce this locally; where new build today have a mismatched CRC, so it seems likely that my original images got "lucky" with the CRC calc. Just had another look at the ESP8266's SDK and tweaked the CRC algorithm accordingly (SDK's is framework-esp8266-rtos-sdk/tools/gen_appbin.py) to get them to match up.
Unfortunately this just raises a second more severe problem where the device hangs after jumping into the new bootstrap image. Let me debug that a bit more before pushing the CRC stuff. I'm guessing the layout has probably been changed with the latest SDKs.
Ah, pio won't let me inject the linker script via LDSCRIPT_PATH any more, so added a quick hack to user_bins.py to replaces the linker scripts. This results in the bootstrap firmware being built with the correct memory addresses. Also added a couple of asserts in the script in case this happens again.
Have pushed these changes (CRC + linker script + other tweaks) to master and I'm now able to hijack my ESP8266 1.89 FW in either user1 or user2.
rebuilt with updates and that did it for me, thanks for the fix!
I'm halfway through debugging an issue similar to the behaviour seen here: https://github.com/adapt0/smartplug/issues/4#issuecomment-577898643
Specifically that the image download finishes and then nothing seems to happen after that. Unlike the above mentioned comment though these switches are one of the original ones and contain a firmware version (1.89) that has been known to work previously.
Known relevant details:
Log from the hijack server:
Log from the serial interface:
build log: