-
-
Notifications
You must be signed in to change notification settings - Fork 8.2k
esp8266: Vendor SDK 2.0.0 over clean flash leads to bootloop #2315
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
An obvious conclusion from this may be: don't upgrade to 2.0.0+, until this regression is fixed. Other ideas are welcome. |
I tried to see if there's at least something good in 2.0.0 (like, for real) and tried the known issue with it segfaulting in connect() when there're too many scan results/too little OS heap. With uPy heap set to 44K:
So, it actually even connected, but didn't get dhcp. But didn't crash. With 42K uPy heap, I can connect (2.5K OS heap free after connect). |
Even WebREPL can connect in the latter case and do simple stuff, failing with bigger output:
|
This is pretty important ticket, I'm surprised that nobody commented here. Ok, dumping my mind on what can be done here:
Of all these, 2 is the most plausible choice, but not without many issues still. Opinions? |
Can't this be merged with the image, so that it gets flashed together with it? |
Nope, I didn't even list that option. That sector needs to be flashed at the end of flash, so that would mean providing complete flash images for different flash sizes, damn slow to flash. |
Crazy idea: can the init_data go at the start of the image (or elsewhere, but not the end), and then its location be set by a system call? |
Location of this data can't be set by a documented API function. The # 3 above is based on the idea to try to use one of the early startup callbacks to write this data to the intended place. It needs testing to see if they are indeed early enough to come before the bootloop happens. |
That's a shame. Is there anyway to write a small wrapper around the boot process so we get a call even before the ESP SDK is called? |
There're couple of official early-init callbacks which can be explored for that (e.g. rf pre-init callback, name suggests it pretty early). Wrapping SDK start function into custom code is higher-hanging fruit, because for many things (e.g. flash access via typical functions), some SDK state should be already initialized, so you need to know which functions use what, and be ready to bypass it (how?). I've made good progress with RE tools this (not yet finished) month, which may help to find answers to these questions, but that's progress with the tools, not the answers. (Essentially, digging WDT way was to show there's some practical outcome already; there're still a lot to do on the tool side though (an alternative is to do manually things which might be done with tools - not too good application of time, and doesn't lead to progress with tools)). |
Well, we definitely can override "startup code" as referenced by firmware header. That code is already read from flash, but otherwise called pretty early in the boot sequence (and so there's opportunity to override a lot, e.g. large part of bootloading at all). |
Based on suggestion in #2485, I looked into this issue, and now have a working solution which needs a lot of cleanup and refactoring. But it's typically an integrational issue, depending on espressif/esptool#131 which needs to be accepted, new version of esptool released on PyPI, etc., so still won't fit in 1.8.5 release. |
esptool patch above was merged. So, I'm waiting for 1.8.5 to be out to start merging this and other big changes. |
This issue was fixed in master now. Testing is welcome. The latest esp-open-sdk should be used. |
I confirm that it (SDK 2.0.0 and new esptool) work for me. |
This was closed by mistake. esptool 1.2 which is required for hassle-free SDK 2.0 based firmware installs was released, but fatal error in it was found: espressif/esptool#140 This is blocker for 1.8.6 (#2592). |
esptool 1.2.1 was released and installs cleanly. Notice on the forum posted: http://forum.micropython.org/viewtopic.php?f=16&t=2625 . Still need to update docs. |
In 5630778 |
STM32: Add PYB Nano support
Now confirmed - flashing a firmware after esptool.py erase_flash leads to a bootloop. That means that Espressif removed automatic initialization of default system params, and now esp_init_data_default.bin needs to be flashed explicitly (at flash_end -0x4000). After it's flashed, it boots ok. Also boots ok after flashing 2.0.0 firmware over 1.5.4 firmware (assuming it already run).
The text was updated successfully, but these errors were encountered: