-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Keep a frozen 1.5.4.1 branch? #1833
Comments
There are some interesting bugfixes merged after 2.0.0 AFAIK. |
Yes, there are. However, we just don't have enough maintainers to look after yet another branch. That's why I proposed to freeze it.
Well, it does run but you can select fewer modules than with 1.5.4.1 before your system runs out of memory. I have no idea how serious an issue that is (i.e. how many people it affects) but I think if we could help improve the situation with very little effort we should do that. |
As one of flash-keeping improvement: use bootloader. Seriously. For example, rBoot keeps some flash space that now cannot be used at all. For example: Commit d0622c3, default clean build:
Okay, Commit 23dc5ca (my
Now we have bootloader (and its config sector), but final image (starts at 0x2000) takes only 410k. 26k of free space + OTA support? But this is another thread... Also we have two 4K "mapped" sectors with certificates (used in tls.cert.verify). Legacy |
I'm not yet caught up on all my NodeMCU github notifications, but it seems there have been a few regressions thanks to SDK 2.0.0 as well. I could see it being useful to offer a "1.5-final" type branch for that reason too, with the sort of disclaimers you suggest. I'm not currently in a position to help out with it though... |
Not sure I understand (language issue I guess)...you don't mean 2.0 fixed regression issues, do you? Rather, there are new regression bugs due to 2.0, no? The most notable in that category is #1707 affecting the by far most popular non-default module. Pity we didn't manage to fix it in due time even though it was reported long before the last master drop. |
Well, Espressif pulled the plug for 512 kByte modules already with their AT firmware on 1.5.0 (see current NONOS SDK release notes). This was probably the trigger for these ESP-01S with 1 MByte. |
Thanks for the hint, didn't know about this.
We can't tell but my main point is that this would be something that'd cost us very little.
What exactly do you mean by that? |
Personally, I've picked up several bits from here and there about how tight the situation is for 512 kB modules but never used one myself for a long time. And it seems that there's still potential for current FW to reduce flash usage like Yuri pointed out. But that's kind of off-topic for the question regarding a frozen 1.5.4.1 branch. |
I created that branch, added hints to README and documentation and made the branch available on RTD: https://github.com/nodemcu/nodemcu-firmware/tree/1.5.4.1-final Cloud builder will follow later. |
Great, thanks Marcel! |
http://www.esp8266.com/viewtopic.php?f=23&t=13791 discusses a topic that briefly crossed my mind as well before we upgraded the SDK with the last master drop: it became a challenge to fit NodeMCU 2.x onto 512KB modules.
An easy fix would be to retroactively create a 1.5.4.1 branch from https://github.com/nodemcu/nodemcu-firmware/tree/017b4637c2d9ff74f131b8e8bcf5f40cb8e3a475 (last revision before SDK upgrade) and freeze it. We'd add a fat warning to the README and the docs in that branch and I could very easily offer support for it in the cloud builder.
Thoughts?
The text was updated successfully, but these errors were encountered: