10000 esp8266: Vendor SDK 2.0.0 over clean flash leads to bootloop · Issue #2315 · micropython/micropython · GitHub
[go: up one dir, main page]
Skip to content

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.

Sign up for GitHub

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

Jump to bottom
Closed
pfalcon opened this issue Aug 12, 2016 · 18 comments
Closed

esp8266: Vendor SDK 2.0.0 over clean flash leads to bootloop #2315

pfalcon opened this issue Aug 12, 2016 · 18 comments
Labels
port-esp8266

Comments

@pfalcon
Copy link
Contributor
pfalcon commented Aug 12, 2016

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).
@pfalcon
Copy link
Contributor Author
pfalcon commented Aug 12, 2016

An obvious conclusion from this may be: don't upgrade to 2.0.0+, until this regression is fixed. Other ideas are welcome.

@pfalcon
Copy link
Contributor Author
pfalcon commented Aug 12, 2016

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:

>>> esp.freemem()
1264
>>> sta.connect(...)
E:M 1184
>>> scandone
E:M 1184
state: 0 -> 2 (b0)
state: 2 -> 3 (0)
state: 3 -> 5 (10)
add 0
aid 2
cnt.

connected with XXXXX, channel 11
E:M 1184
dhcp client start...
E:M 432
E:M 432

E:M 1184
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
OSError: Cannot set STA config
>>> E:M 432

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).

@pfalcon
Copy link
Contributor Author
pfalcon commented Aug 12, 2016

Even WebREPL can connect in the latter case and do simple stuff, failing with bigger output:

>>> 123**456
9925006877209885670083146205746963263729594081988690051981629888138286710474939907792112866142614463805542423693627187249280035274164990211814381967260156999810012079049675951763646544589562574160986620990050019840715324460477896801696302805031026141761591446872991824068548787861764597693906346435798616571173097639947850764922868634146696716791012665334E:M 656
dupterm: Exception in write() method, deactivating: OSError: [Errno 12] ENOMEM

@pfalcon
Copy link
Contributor Author
pfalcon commented Sep 2, 2016

This is pretty important ticket, I'm surprised that nobody commented here. Ok, dumping my mind on what can be done here:

  1. Telling users that they should flash esp_init_data_default.bin themselves. I'd strike thru this as not acceptable right away.
  2. Patch esptool.py to add a flag to flash it "automagically". There're many details how to flash this (what to flash, exactly, is that file static across SDK versions?), then whether esptool.py maintainer will take it, or we will need to maintain a fork, then how long it takes to get it into upstream esptool.py. etc.
  3. Patch startup somehow to bring back automatic bootstrapping of that data. It's unclear if that would be possible, and I didn't get to experiment with that so far.

Of all these, 2 is the most plausible choice, but not without many issues still. Opinions?

@deshipu
Copy link
Contributor
deshipu commented Sep 2, 2016

Can't this be merged with the image, so that it gets flashed together with it?

@pfalcon
Copy link
Contributor Author
pfalcon commented Sep 2, 2016

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.

@dpgeorge
Copy link
Member
dpgeorge commented Sep 3, 2016

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?

@pfalcon
Copy link
Contributor Author
pfalcon commented Sep 3, 2016

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.

@dpgeorge
Copy link
Member
dpgeorge commented Sep 3, 2016

Location of this data can't be set by a documented API function.

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?

@pfalcon
Copy link
Contributor Author
pfalcon commented Sep 3, 2016

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)).

@pfalcon
Copy link
Contributor Author
pfalcon commented Sep 4, 2016

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).

@dpgeorge dpgeorge mentioned this issue Oct 7, 2016
Closed
@pfalcon
Copy link
Contributor Author
pfalcon commented Oct 8, 2016

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.

@pfalcon
Copy link
Contributor Author
pfalcon commented Oct 12, 2016

esptool patch above was merged. So, I'm waiting for 1.8.5 to be out to start merging this and other big changes.

@pfalcon
Copy link
Contributor Author
pfalcon commented Oct 18, 2016

This issue was fixed in master now. Testing is welcome. The latest esp-open-sdk should be used.

@pfalcon pfalcon closed this as completed Oct 18, 2016
@dpgeorge
Copy link
Member

I confirm that it (SDK 2.0.0 and new esptool) work for me.

@pfalcon
Copy link
Contributor Author
pfalcon commented Nov 5, 2016

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).

@pfalcon pfalcon reopened this Nov 5, 2016
@pfalcon
Copy link
Contributor Author
pfalcon commented Nov 7, 2016

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.

@pfalcon
Copy link
Contributor Author
pfalcon commented Nov 8, 2016

Still need to update docs.

In 5630778

@pfalcon pfalcon closed this as completed Nov 8, 2016
tannewt added a commit to tannewt/circuitpython that referenced this issue Dec 12, 2019
@tannewt
Merge pull request micropython#2315 from hierophect/stm32-pyb-nano
387ab6c 
STM32: Add PYB Nano support
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
port-esp8266
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@pfalcon @deshipu @dpgeorge
0