Keep a frozen 1.5.4.1 branch?

[marcelstoer]

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?

[djphoenix]

There are some interesting bugfixes merged after 2.0.0 AFAIK.
So I think this frozen branch will be helpful anyway, but we need to try keep possibility to run latest version on 512k modules anyway. Without some modules, without SSL, but keep it working.
Also I think that we may do some optimisations of firmware layout on flash, and keep consumption lower.

[marcelstoer]

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.

we need to try keep possibility to run latest version on 512k modules anyway. Without some modules, without SSL, but keep it working.

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.

[djphoenix]

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:

$ ls -l bin
-rw-r--r--  1 phoenix  staff   29072  6 мар 00:13 0x00000.bin
-rw-r--r--  1 phoenix  staff  371120  6 мар 00:13 0x10000.bin

Okay, irom only 371k, but it starts at 0x10000 and final image takes (0x10000 + 371120) 436k.

Commit 23dc5ca (my rboot branch), default clean build:

$ ls -l bin
total 800
-rw-r--r--  1 phoenix  staff  401920  6 мар 00:18 eagle.app.v6.bin
-rw-r--r--  1 phoenix  staff    3776  6 мар 00:18 rboot.bin

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 espconn layer, that we (I hope) will strip somewhen.

[jmattsson]

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

[marcelstoer]

there have been a few regressions thanks to SDK 2.0.0

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.

[devsaurus]

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.
But yes, if demand is there, we could offer a pre-2.0.0 version as Marcel pointed out. Though I'm also missing an overview where the firmware is and what could be improved on 2.0.0. E.g. #1390 ate another 4k for an extra sector.

[marcelstoer]

Espressif pulled the plug for 512 kByte modules already with their AT firmware on 1.5.0

Thanks for the hint, didn't know about this.

But yes, if demand is there, we could offer a pre-2.0.0 version...

We can't tell but my main point is that this would be something that'd cost us very little.

I'm also missing an overview where the firmware is and what could be improved on 2.0.0.

What exactly do you mean by that?

[devsaurus]

I'm also missing an overview where the firmware is and what could be improved on 2.0.0.

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.

[marcelstoer]

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.

[jmattsson]

Great, thanks Marcel!