Build broken if using -DOPEN_ESPLIBS=0

[Governa]

Trying to debug my power consumption problem, I've tried to compile my program without open esplibs but some symbols are not found.

Flags: EXTRA_CXXFLAGS=-std=c++11 -DOPEN_ESPLIBS=0 EXTRA_CFLAGS=-DOPEN_ESPLIBS=0

Log: xtensa-lx106-elf-gcc -nostdlib -Wl,--no-check-sections -L./build/sdklib -L../../lib -u call_user_start -Wl,-static -Wl,-Map=./build/blink.map -Wl,-gc-sections -g -O2 -T../../ld/program.ld -T../../ld/rom.ld -L../../libc/xtensa-lx106-elf/lib -u _printf_float -u _scanf_float -Wl,--whole-archive ./build/open_esplibs_libmain.a ./build/open_esplibs_libnet80211.a ./build/open_esplibs_libphy.a ./build/open_esplibs_libpp.a ./build/open_esplibs_libwpa.a -Wl,--no-whole-archive -Wl,--start-group ./build/program.a ./build/freertos.a ./build/lwip.a ./build/core.a ./build/open_esplibs.a -lhal -lgcc -lc -lmain -lnet80211 -lphy -lpp -lwpa -Wl,--end-group -o build/blink.out ./build/sdklib/libwpa.a(wpa_auth.o): In function sdk_wpa_auth_for_each_sta': (.irom0.text+0x1c0): undefined reference tosdk_os_get_random' ./build/sdklib/libwpa.a(wpa_auth.o): In function sdk_wpa_auth_for_each_sta': (.irom0.text+0x1d9): undefined reference tosdk_os_get_random' ./build/sdklib/libwpa.a(wpa_auth.o): In function sdk_wpa_auth_for_each_sta': (.irom0.text+0x20f): undefined reference tosdk_os_get_random' ./build/sdklib/libwpa.a(wpa_auth.o): In function sdk_wpa_receive': (.irom0.text+0x919): undefined reference tosdk_os_get_random' ./build/sdklib/libwpa.a(wpa_auth.o): In function sdk_wpa_auth_sm_event': (.irom0.text+0x10ee): undefined reference tosdk_os_get_random' ./build/sdklib/libwpa.a(wpa_auth.o):(.irom0.text+0x1473): more undefined references to sdk_os_get_random' follow ./build/sdklib/libwpa.a(common.o): In functionsdk_hexstr2bin': (.irom0.text+0xd4): undefined reference to sdk_os_get_time' ./build/sdklib/libwpa.a(common.o): In functionsdk_hexstr2bin': (.irom0.text+0xe3): undefined reference to `sdk_os_get_time'

[ourairquality]

I think this raises an important issue, one that I have been pondering and it might be about the viability of this framework. There is still a substantial amount of code in binary form. Even if we could convert it to source, there have been a lot of improvements since, and who would want to fix all the problems again and maintain it. It's not like the code would be shared with other projects and leverage shared development, it's specific to the device. Yet, we can make some fixes and improvements around the edges.

Is the framework enough reason to try to make a branch that works with the latest sdk binaries, tainted but perhaps still usable?

I think it is way past the point of being able to build without the open sdk libraries. Changes have had to be made around the edges and these are only in source code.

What would need to be done to give the option to build with the latest sdk? There is a lot of low level code in the 'core' that would probably need to be converted to source too, lots of libmain to update, and the sdk_internals structures. Also FreeRTOS port support to update, and some lwip support too. I guess this could be done, but two questions: is the framework worth this effort; and where would that leave the licensing problems and would it be better a separate project?

[projectgus]

where would that leave the licensing problems

I'm no longer involved with this project, and this decison is clearly up to the current maintainers and not me.

That said, one option I wanted to note is that it would be possible to have the binary wifi libraries under Espressif MIT and the rest of the project under 3 clause BSD, provided that no source code or reverse engineered parts of the binary libraries are reproduced in the BSD licensed parts. There's no "virality" to either license, they can link together just fine (the resulting binary can only be used on Espressif hardware, but that's kind of a given anyhow.)

Regarding how much the ESP8266 RTOS SDK internal structure has changed: I think quite a bit. But I imagine it would be possible to make it work.

Although I don't work on ESP8266 at all, I may also be able to give some small amount of help from the Espressif side - if it turns out there's a major sticking point to moving across that could be changed in the Espressif RTOS SDK with minimal effort. Possibly.

[Governa]

If it is not a huge amount of work and you are willing to help a bit, I'd be willing to do that.

[ourairquality]

@projectgus Thank you for the offer of help. A quick proof of concept, updating to the latest sdk libraries and patching things up has the http_get example working, but with only the FreeRTOS compiled from source (the latest). Shall look into getting lwip v2 building and integrated next. Practically it was necessary to convert app_main to source code to even debug the problems. The existing exception handling code needed only minor changes to work. We would probably want to eventually have source code for libmain, and it would save us some time if the source code were released for libmain. Still using rboot which works but probably does not support some of the enhancements. Lots of issues to explore.

An odd one: the second function in app_main was beyond my understanding. It seems to accept a string pointer, then adds and big constant to it and passes that pointer to SPIRead. Might that be a typo.

[ourairquality]

@projectgus Got it running barely, a start. The changes required for lwip2 were similar. The biggest problem for lwip was in wl_cnx:sta_leave where it checks the netif->flags for dhcp being enabled. That logic needs to change for lwip v2, and you can see what was necessary in this projects lwip v2 support. It required patching the binary library (I am loath to convert all of wl_cnx to source). Would you consider abstracting out that logic to help here?

The other changes for lwip v2 were to smaller functions and I have source code for them all now. Some could be factored out too, such as the size of the struct netif when allocating it in ieee80211_sta and hostap. Doing so would also help people who just wanted to add to the end of this structure without changing it.

The FreeRTOS code is asserting. I think you could reproduce this by defining configASSERT. It seems to be with pp_post adding to a queue, and this is called from pp_ptpkt for the beacon from the hostap code, which in turn seems to be call from and ets timer. Looking a the ets timer code is appears to suspend all tasks while calling the callbacks. Perhaps this assertion is harmless, or perhaps it is a warning that this could deadlock. Might be something to look into.

There is other code that looks a little suspect, such a entering a critical region in on thread and exiting in another - in app_main. And entering a critical region and queuing events within, e.g. system_station_got_ip_set. Are these things all ok? Did FreeRTOS have to be patched up to support this?

There seems some interesting changes to the wdev interrupt handling too. Critical regions do not appear to disable the wdev interrupt now. This broke our flash code, the wdev interrupt was still running when reading and writing the flash. I noticed it might be necessary to use some dance with register 0x3ff20c18, and is that something you could explain? Also I don't see the library spi_flash code disabling the wdev interrupt, and could that be broken too, or is there some strategy to manage it - have not converted that all to source yet, so perhaps I missed something.

[projectgus]

I'm really sorry if I misrepresented the situation above. I don't work on ESP8266 at all, so although I'd like to help you with some of this information I literally can't. If it comes down to one particular sticking point then I can relay a request to the relevant people, but that's about all I can do.

[Governa]

@ourairquality Have you pushed this code anywhere?

[ourairquality]

@Governa Code tainted by the restrictive license has not been released, and no strategy has been settled on that. It was an interesting proof of concept, but my focus turned quickly back to the current code we have, and compiling without the open esplibs is not possible if lwip is separated from the sdk libs - reminds me these options need to be removed from the lwip v2 patch. My quick impression was that the current sdk is even more 'optimized', the iram seems really tight, and it suspends all tasks more often perhaps adopting strategies that we might choose to do differently. Btw if people are jumping to other platforms then perhaps they could drop me an email so I can rethink resource allocation, but I am deploying a prototype at least with the current sdk, and putting effort into lwip and might look at an open wpa library etc.