Avatar Blogs during GSoC-2025 period at RTEMS for the project - Providing SPARC GRETH Network Drivers for lwIP

Week-13 @RTEMS-GSoC-2025

Overview


This week, I completed the following tasks :

  • Run test for RX mechanism testing for GRETH lwIP Driver
  • Fixing ARP Replies not received by transmitter
  • Begun with TX GBit coding

Work completed this week


  1. Testing RX Test
    • Firstly, I was not able to see any ARP reply from GRETH Receiver in Wireshark as well.
    • The reason ARP replies were not getting generated turned out to be pointing the addr field of RX BDs to p pbuf directly rather than payload field of pbuf p i.e. it should have been p->payload rather than p. I understood it after checking Legacy GRETH Driver’s RX IRQ portion.
    • Hence, now I was able to observe ARP replies from receiver
    • I tried using ucast_client test running on host linux, which sets up a UDP socket transmitting UDP messages every second, which are simple small strings, to the IP address and port number of the receiver. Using this test, GRETH RX shown the proper RX mechanism operation as expected!
  2. ARP Replies not received by transmitter :
    • Transmitter transmits ARP request, and receiver does transmit back ARP reply; however, the ARP replies didn’t seem to reach the transmitter.
    • Further, in dynamic ARP,though ARP resolution occurs correctly, I saw trap 7 errors frequently
    • I also observed that in some cases, if I run a non-existent command and then the actual command rx then the dynamic ARP seems to work for RX. This suggests there might be a race occuring between receiving incoming packet and the ARP reply, causing race condition among ARP and UDP reception.
    • Adding a 1 second delay for ARP resolution in the project helped solve this issue.
  3. Begun with TX GBit coding
    • I further strted working on TX GBit code and completing the corresponding firmware
  4. Errors encountered :

    1. Try tweaking various options for dynamic ARP :
      • I observed that apparently ARP cache was getting stale every 5 seconds,. So I tried using various values for options like ARP_TABLE_SIZE, ARP_MAXAGE, ARP_MAXPENDING, ARP_TMR_INTERVAL etc.
        • ARP_TABLE_SIZE defines the maximum number of entries in the ARP table. I initially set it to 10.
        • ARP_MAXAGE defines the maximum time (in seconds) an ARP entry is kept before being considered stale. I initially set it to 10.
        • ARP_MAXPENDING defines the maximum number of packets queued for an unresolved ARP entry. I initially set it to 50.
        • ARP_TMR_INTERVAL sets the period, in milliseconds, at which the ARP timer function (etharp_tmr()) must be called
    • ![addr2line_on_trap9PC_addr](/GSoC-2025-Blogs-RTEMS/assets/posts/week13/2-trap9-all_addr_chk.png)
    • Apparetly the memory address is out of bounds for the allocated RAM
    • Solved the bug
    • The desc dont seem to wrap
    • ARP requests were possible
    • DOnt call pbuf_free on success
    • getting Bad CRC err recurrently suggesting some mem improperly overwrittenn
    • I observe that ARP reply not gen by RX side, probably that pkt not being passed to lwIP stack. But this is in cotrast to my debug ststaement returning from ntf->input
    • Apparently ethernet_input never called
    • No route to dest, at this lvl ARP is also not done, pkt is discarded
    • Wrong IPs, lxcbr0 woth NO-CARRIER
    • Solved by len_status
    • No UDP pkt tx/rx log, only ARP
    • WHy multiple ARP req-reply, nd only that msgs?
    • Apparently each pkt gives ARP req-rep
    • Tweaing ARP params in lwipbspopts.h I am chking MAXPENDING and TMR_INT ones which now give trap9
    • Static ARP also doesnt help
    • Probably ARP reply arent reaching tap1 (tx_udp.exe) causing multiple ARPs
    • TX RX IRQ en on CTRL (TX only) and BD (TX only)
    • static configuration of arp cache on both sides

    • Used linux tx w/o mac config, and actual ARP not static
    • Probably ARP/UDP rae condition so trap7 at inet_cksum.h
    • Wrong cmd then rt cmd works , suggesting need of delay - but why woth Static ARP?
    • Static ARP just after start_networking helps
    • So I shoul do ARP b4 IRQ get activated so that IRQ’s attempt of ARp wont interfere with ARP/UDP
    • ethernet_output() for b4 IRQ

    • TX TEst Linux listener server :
      1. Bind cannot bind error solved
      2. Make the rx id to be 10.0.3.1
      3. One msg eceived but then trap 9 at ??:0
    • TXGBit
    • getting diferent maxc addr, static arp deosnt seem to work.
    • dynamic arp seems to work
    • type, s/d mac seem to gte corrupted
    • no proper linkoutput fn, fixed to greth_send_gbit
    • wrap issue
    • Apparently after 14th msg (15th BD) I am getting trap7 due to intr after 16 bd
    • i1 : inte_en=TXD_IRQ still trap7, and txbd->enable not on => used logicof txen of bd only from last to first
    • No TX IRQ called, apparently linkoutput fn not set correctly as greth_send also called. so shifting it to greth_init_hw
    • debug logs of gbit/nongbit send fn used as well as other things not printed
    • failed arp static entry addn, no route to 10.0.3.1 => shift stati arp to after start_networking
    • the wrap+going in greth_sed got solved but still tx not occuring
    • I also dnt seee any movement in IRQ.

    • MAybe issue is with 2 irqs, to see
    • Fix infinite while loop
    • Why greth_sen is used even if irq and linkoutput configurd to gbit ones, why tx and rx both shown
    • Apparently SIS supports only 10/100MBit
    • Chk when giving intr and freeing pbufs in tx irq
    • The length alloc seems fine (56=42+14)

    Wk next

    • 31st BD touched, its p->payload considered for next allocateds.

Plans for next week


  1. Complete TX Gbit code
  2. Complete documentation and testing for the project