1. 16 Sep, 2021 1 commit
    • Johny Mattsson's avatar
      Fixup LROT_MASKs for all modules. · ea968de6
      Johny Mattsson authored
      Search-and-replace considered harmful. I completely missed the need to
      explicitly declare "fast" tag functions (__xyz) in the mask field to
      LROT_BEGIN()/LROT_END() when I brought over the 5.1+5.3 support.
      Without those flags set properly, the LVM doesn't even bother going
      looking for those methods, which in this case led to garbage collection
      not calling the __gc functions, among other horrible things.
      
      Mea culpa.
      ea968de6
  2. 23 Aug, 2021 2 commits
  3. 21 Aug, 2021 1 commit
    • Johny Mattsson's avatar
      Port Terry's Lua 5.1 + 5.3 work from the esp8266 branch. · 17df207a
      Johny Mattsson authored
      Changes have been kept to a minimum, but a serious chunk of work was
      needed to move from 8266isms to IDFisms.
      
      Some things got refactored into components/lua/common, in particular
      the LFS location awareness.
      
      As part of this work I also evicted our partition table manipulation
      code, as with the current IDF it kept breaking checksums and rendering
      things unbootable, which is the opposite of helpful (which was the
      original intent behind it).
      
      The uart module got relocated from base_nodemcu to the modules component
      properly, after I worked out how to force its inclusion using Kconfig alone.
      17df207a
  4. 21 Jul, 2021 1 commit
  5. 15 Jul, 2021 1 commit
  6. 08 Jul, 2020 1 commit
  7. 22 Jul, 2019 1 commit
  8. 14 Jul, 2019 1 commit
    • Johny Mattsson's avatar
      Fix net module data loss & RTOS task unsafety (#2829) · f44e6e96
      Johny Mattsson authored
      To avoid races between the lwIP callbacks (lwIP RTOS task) and the Lua
      handlers (LVM RTOS task), the data flow and ownership has been simplified
      and cleaned up.
      
      lwIP callbacks now have no visibility of the userdata struct. They are
      limited to creating small event objects and task_post()ing them over
      to the LVM "thread", passing ownership in doing so. The shared identifier
      then becomes the struct netconn*.
      
      On the LVM side, we keep a linked list of active userdata objects. This
      allows us to retrieve the correct userdata when we get an event with
      a netconn pointer. Because this list is only ever used within the LVM
      task, no locking is necessary.
      
      The old approach of stashing a userdata pointer into the 'socket' field
      on the netconn has been removed entirely, as this was both not
      thread/RTOS-task safe, and also interfered with the IDFs internal use
      of the socket field (even when using only the netconn layer). As an
      added benefit, this removed the need for all the SYS_ARCH_PROTECT()
      locking stuff.
      
      The need to track receive events before the corresponding userdata object
      has been established has been removed by virtue of not reordering the
      "accept" and the "recv" events any more (previously accepts were posted
      with medium priority, while the receives where high priority, leading
      to the observed reordering and associated headaches).
      
      The workaround for IDF issue 784 has been removed as it is now not needed
      and is in fact directly harmful as it results in a double-free. Yay for
      getting rid of old workarounds!
      
      DNS resolution code paths were merged for the two instances of "socket"
      initiated resolves (connect/dns functions).
      
      Also fixed an instance of using a stack variable for receiving the resolved
      IP address, with said variable going out of scope before the DNS resolution
      necessarily completed (hello, memory corruption!).
      
      Where possible, moved to use the Lua allocator rather than plain malloc.
      
      Finally, the NodeMCU task posting mechanism got a polish and an adjustment.
      Given all the Bad(tm) that tends to happen if something fails task posting,
      I went through a couple of iterations on how to avoid that. Alas, the
      preferred solution of blocking non-LVM RTOS tasks until a slot is free
      turned out to not be viable, as this easily resulted in deadlocks with the
      lwIP stack. After much deliberation I settled on increasing the number of
      available queue slots for the task_post() mechanism, but in the interest
      of user control also now made it user configurable via Kconfig.
      f44e6e96
  9. 11 Jul, 2019 1 commit
    • Johny Mattsson's avatar
      Fix net module losing TCP data. (#2825) · c0145e03
      Johny Mattsson authored
      The netbuf_data() function only returns data from the first pbuf in the
      chain. We need to use netbuf_first() and netbuf_next() to walk the
      pbuf chain and act on each in turn.
      c0145e03
  10. 20 Oct, 2018 1 commit
  11. 12 Nov, 2017 1 commit
  12. 12 Sep, 2017 1 commit
  13. 14 Aug, 2017 1 commit
  14. 21 Jul, 2017 1 commit
  15. 20 Jul, 2017 2 commits
  16. 18 Jul, 2017 1 commit
  17. 19 Mar, 2017 1 commit
  18. 30 Dec, 2016 2 commits
  19. 06 Oct, 2016 1 commit
    • Johny Mattsson's avatar
      Imported @djphoenix's new native LWIP net module. · be5dafb2
      Johny Mattsson authored
      Based on his revision 2d290a24a0914be88e5ca4ac7b1018392fe75fe2
      (https://github.com/djphoenix/nodemcu-firmware).
      
      All LWIP callback handling changed to use the NodeMCU task interface
      to make it usable on RTOS.
      
      IPv4 assumptions have been removed, and this net module /should/ now
      be IPv6 ready, but aside from compilation no testing has been done
      in this area.
      
      SSL integration points not touched - some work needed there once we
      have an mbedTLS module.
      be5dafb2