lwip update

[ourairquality]

• The mdns resolver has been reworked to lower stack and memory usage. It received good feedback from upstream but was unfortunately not accepted as the change uses malloc'ed memory and the upstream lwip wishes to work with pools and without using malloc. The high stack usage was a big problem for esp-open-rtos, so we might have to maintain the differences for now.

• Improved lwip core locking, and lock checking. Upstream improvements, that need some added support from esp-open-rtos specific code. Move core lock is performed when calling from the esp-open-rtos code now, so a little safer. The checking is not enforced, but project might see warning messages and might want to look into them.

• The esp-open-rtos lwip support has been sync'ed with the new freertos port included with lwip. There are still some differences, but both appear to have benefited from this effort and the differences are smaller.

• A few lwip timer bugs have been resolved. This might help resolve some issues.

• Plus it picks up all the other upstream fixes and improvements.

[ourairquality]

The default lwip stack has been lowered from 768 words to 480 words, due to the reduced stack usage by the mdns responder, recovering almost 1k. Hope this does not impact other apps, but memory can be tight.

[jeffsf]

While extras/sntp appears to extract src/apps/sntp/sntp.*, having the current version "in tree" will resolve some of the problems with the present SNTP implementation, such as its failing to measure and take into account RTT. While I'm not sure why the code was replicated in extras/sntp (especially as you need to have LWIP to use it), updating sntp.* is quite welcome (as is updating LWIP, in general!)

_Edit: For the "new" SNTP, this will be required to provide LWIP_ASSERT_CORE_LOCKED()_

[jeffsf]

When I check this out or merge this onto master I get many compile-time warnings about redefinition of [UN}LOCK_TCP_CORE() such as

In file included from /Volumes/esp-build/esp-open-rtos/open_esplibs/libnet80211/ieee80211_hostap.c:8:0:
../../lwip/lwip/src/include/lwip/tcpip.h:56:0: warning: "LOCK_TCPIP_CORE" redefined [enabled by default]
 #define LOCK_TCPIP_CORE()     sys_mutex_lock(&lock_tcpip_core)
 ^
In file included from ../../lwip/lwip/src/include/lwip/opt.h:51:0,
                 from ../../lwip/lwip/src/include/lwip/tcpip.h:40,
                 from /Volumes/esp-build/esp-open-rtos/open_esplibs/libnet80211/ieee80211_hostap.c:8:
../../lwip/include/lwipopts.h:129:0: note: this is the location of the previous definition
 #define LOCK_TCPIP_CORE()          sys_lock_tcpip_core()
 ^

Is there something that I need to do to remove the cause of these warnings that you know of?

(examples/blink used for a relatively "clean" build of LWIP)

[ourairquality]

There are no warnings here when building examples/blink. The patch has been rebased to master and updated to the latest lwip too, and the build check above did not complain, so perhaps you will need to explore the issue locally.

[jeffsf]

Confirm no compiler warnings building blink after git submodule update (not sync -- too much time on Android, apparently)

Tracking down

Warning: ELF binary has undefined symbol sys_mbox_trypost_fromisr

Thanks for the effort on this merge and the response.

[SaimenSays]

After latest update I also get the

Warning: ELF binary has undefined symbol sys_mbox_trypost_fromisr

If it is not related to this update, what can I check to find what cause it has? This symbol is not in my code, so there is something included which uses it. For the blink example this is optimized away and won't generate the warning, or I am wrong?

[flannelhead]

It seems that lwIP now requires a function sys_mbox_trypost_fromisr along with sys_mbox_trypost in sys_arch.c and this implementation is missing somehow.

[ourairquality]

The function sys_mbox_trypost_fromisr is not required for esp-open-rtos and it does not use that path. Missed that this had been added to lwip, and here's a quick patch to quieten linking https://github.com/SuperHouse/esp-open-rtos/pull/567

[flannelhead]

@ourairquality, thank you! I was even getting linker failures for some reason, which seem pretty illogical:

./build/lwip.a(tcpip.o): In function `tcpip_send_msg_wait_sem':
/home/sakari/projektit/espway/esp-open-rtos/lwip/lwip/src/api/tcpip.c:436: undefined reference to `sys_mbox_trypost_fromisr'
/home/sakari/projektit/espway/esp-open-rtos/lwip/lwip/src/api/tcpip.c:436: undefined reference to `sys_mbox_trypost_fromisr'

What baffles me is that tcpip_send_msg_wait_sem doesn't refer to sys_mbox_trypost_fromisr. It is called from tcpip_callbackmsg_trycallback_fromisr though, and probably the linker is just confusing something with the line numbers.

Adding the stub certainly removes the errors.

[SaimenSays]

@ourairquality: Thanks for all your work!

For my project I get multiple "Function called without core lock". After some inspection I need to add multiple LOCK_TCP_IP core to tcp_new(), tcp_bind(), tcp_accept(), ... Now everything seems to be fine, but I think this not the original intention. Are these tcp_ not intended for user code and should I use higher level functions instead? Some time ago I tried to use netconn API, but I find this a bit strange and dropped it.

[ourairquality]

@SaimenSays This was a new check for lwip, and for now it just prints a warning for esp-open-rtos. The intention is not to add LOCK_TCP_IP to these lwip functions rather the caller needs to ensure this lock is held by wrapping the call in LOCK_TCP_IP() and UNLOCK_TCPIP_CORE(). On inspection it might be that the lock also needs to be help between some of these calls.