-
Notifications
You must be signed in to change notification settings - Fork 622
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
Migrate to upstream lwIP + ESP8266 patchset instead of sloppy vendor code-drop #263
Comments
@dpgeorge: FYI. |
That's definitely a noticeable issue:
|
Suspicion lies on packet retransmission issues, e.g. vendor codedrop has pretty magic code like pfalcon/lwip-esp8266@79dc343 |
@pfalcon, ack, nice work! It's a shame thought that it's not possible to use lwip "out of the box". Are there plans to upgrade to lwip v2? |
Well, the idea is that it will make it possible, but I don't have any specific plans to got that far, more realistic idea is to upgrade minor release by minor release (and even that requires better testing process than we have now). |
Ok. lwip v2 had some changes to how netif's are added/initialised so that makes it difficult to upgrade if Espressif have hidden that initialisation code in a binary blob. |
@pfalcon: Great work. I unfortunately never had time to maintain the code I've made. I'm glad you did the work. Our methodology was very similar, I remember spending a lot of time looking at the disassembly of the Esperssif binary blobs too, though :) |
Hi @pfalcon, Are they missing intentionally or am I doing something wrong? |
@LongHairedHacker : I don't have time to look into that issue now (or soon), but feel free to provide exact steps on how you got to that issue so it can be investigated later. |
Doesn't seem to be any way to create an issue on the /esp-lwip repo directly so I've had to comment here. Compiled this last night and got some warnings/errors:
|
@kadamski : Thanks for ping-back ;-).
Well, I've been spending enough time looking at the disassembly too. And if you look e.g. at https://pfalcon.github.io/xtensa-subjects/2.0.0-p20160809/out.html#esf_buf_alloc , you'll see that it allocates different buffer structures than you saw when you looked at that, and there likely were number of changes across SDK evolution. So, for the above particular work I actually didn't look at the disasm, instead following more black-boxish idea that while there're many changes across SDK versions, only some of them would affect lwIP integration. That's still heuristic and I'm not sure whether to continue digging your version, or stick with 1.4.0-rc2 with more or less complete vendor patchset I did initially. |
Github by default disables issue tracker in forked projects, considering that any communication should happen upstream. I've enabled it now.
There're various conflicts between lwIP headers and SDK headers. I definitely worked that around for it to be able not just compile, but also run, but it's not fully clean/correct, and might have left in my git stash.
I used dhcpserver from SDK2.0 even for kadamski's upgraded repo. Bits and pieces might have left in git stash too. Generally, the situation with dhcpserver isn't clear - it's unclear what it's licensing is, etc. I'd have an idea to replace Espressif's proprietary version e.g. with one from esp-open-rtos, but that's written with threaded style, so needs conversion to native lwIP API, and then long testing for any possible regressions comparing to proprietary server. But the current situation is, to remind, that version upgraded from kadamski's work has obvious regressions. So, I'm not sure which version to work with, there're 2 ways:
Both ways are long and boring, but only no.2 is sustainable. |
To xref other work:
|
What i was saying is that if you clone the repo and do the make like in your instructions it breaks. You get warnings (interpreted as errors) about implicit declarations for vPortMalloc etc. and you get an error about not being able to find dhcpserver.h. If you fix the implicit declaration error by adding mem.h before your define, you then get errors about too few parameters. These are fixed if you use os_malloc instead of vPortMalloc because that expands and supplies values for the extra parameters, and the code is still the same. If you go looking to fix the missing include, it is there in the tree but is not in the right place. Either it needs to be moved, or the reference in dhcpserver.c needs to be changed to suit. If you are not expecting the current repo to build then that's fine, but right now it won't complete the build. The one other thing I did in the makefile was to make it suitable for a non-standalone toolchain by putting in $(SDK_BASE) and pointing to my SDK. I figure it's easier to play with a modified libmain that way while keeping your toolchain operational |
@pfalcon have you seen the latest lwIP related commits in ESP_NONOS_SDK from Espressif? Does this start to make life easier for us? BTW I am trying to get some code out right now but as soon as I am done I'll be jumping into the lwIP2 stuff d-a-v has been working on - this is really good. |
@davydnorris: I didn't, I'm still in "reduced performance" mode. If you have any specific links, those would be welcome. |
espressif/ESP8266_NONOS_SDK@cf83aba I don't ever remember lwIP source being a part of the SDK, and now it's also in a third party folder of its own with separate build instructions. Is this just what we already know or does this give us some more hints? |
There is https://github.com/espressif/esp-lwip now with lwip 2.1.2. |
Maybe you should try @someburner 's fork note: lwIP-2.x is not usable with nonos-sdk firmware (any version) without an adaptation layer |
https://github.com/kadamski/esp-lwip existed for a long time, but had following issues:
That's why I went for partial solution of https://github.com/pfalcon/esp-open-lwip/ , though rebasing onto upstream was always the goal.
I finally went for that, making followed steps:
Results of this work:
The plan remains to use @kadamski's work, but with my extracted patchset around to investigate any issues.
The text was updated successfully, but these errors were encountered: