A bug in UTHER2.AI.DRV.S.txt?

[audetto]

So I have written a Uthernet II emulator and was trying it on A2osX.

I have an issue with the AI offload which I eventually tracked down to a data address wrap.

This is a log of what happens when I ping an address

// get reader pointer
U2: f09b: WRITE  c095[0428] 04 = 00, . [4 = 0]
U2: f0a0: WRITE  c096[0428] 28 = 00, . [40 = 0]
U2: f0a3: READ   c097[0428] 00 = 07, . [0 = 7]
U2: f0a8: READ   c097[0429] 00 = f2, . [0 = 242]
// set data address to reader pointer
U2: f0b1: WRITE  c095[042a] 67 = 00, . [103 = 0]
U2: f0b5: WRITE  c096[672a] f2 = 00, . [242 = 0]
// start reading
U2: f0b8: READ   c097[67f2] 00 = 00, . [0 = 0]
U2: f0bd: READ   c097[67f3] 00 = 4c, L [0 = 76]
U2: f105: READ   c097[67f4] 00 = 00, . [0 = 0]
U2: f105: READ   c097[67f5] 00 = 08, . [0 = 8]
U2: f105: READ   c097[67f6] 00 = dc, . [0 = 220]
U2: f105: READ   c097[67f7] 00 = 12, . [0 = 18]
U2: f105: READ   c097[67f8] 00 = 34, 4 [0 = 52]
U2: f105: READ   c097[67f9] 00 = 56, V [0 = 86]
U2: f105: READ   c097[67fa] 00 = 52, R [0 = 82]
U2: f105: READ   c097[67fb] 00 = 55, U [0 = 85]
U2: f105: READ   c097[67fc] 00 = 0a, . [0 = 10]
U2: f105: READ   c097[67fd] 00 = 00, . [0 = 0]
U2: f105: READ   c097[67fe] 00 = 00, . [0 = 0]
U2: f105: READ   c097[67ff] 00 = 01, . [0 = 1]
// end of receive buffer?
// who should reset it to 0x6000?
U2: f105: READ   c097[6800] 00 = 00, . [0 = 0]
U2: f105: READ   c097[6801] 00 = 00, . [0 = 0]
U2: f105: READ   c097[6802] 00 = 00, . [0 = 0]

This happens after about 25 ping messages.

I have no idea what the real w5100 does. Documentation is not very precise.
Only thing I found is here http://dserver.macgui.com/Uthernet%20II%20manual%2017%20Nov%2018.pdf
Bottom of Page 12.

It clearly states that it only ever automatically wraps at 0x6000 and 0x8000, which seems to imply it does not wrap at the end of each RX or TX socket buffer.

DRV/UTHERNET2.DRV.S.txt does not have this issue because it sets a socket size to 0x2000 which means the auto wrap is enough. But with a size of 0x0800, it is not enough.

So

• either this works on a real Uthernet II card (and I can fix the emulation)
• or it doesn't and this explains why

Goes without saying I have no Uthernet II card to try.

[audetto]

Forgot to say what the symptoms are.

After 25 successful pings, there is a timeout. Because the imcoming packet is discarded (bad data). After the timeout, the next packet is good again (RECV fixes the pointers).

Looking at other A2 code I can see they have code to handle this

https://github.com/a2retrosystems/uthernet2/blob/master/test/stream3.c#L258
https://github.com/oliverschmidt/contiki/blob/master/cpu/6502/net/w5100.S#L506
https://github.com/cc65/ip65/blob/master/apps/w5100.c#L303-L316

but I am not very good at reading assembly code.

[burniouf]

UTHER2.AI.DRV development is stopped because it uses IPRAW mode.
W5100 chip has a HW bug in this mode preventing retrieving proper frame IP header....it discards something like 9 bytes when reading data from buffer

[audetto]

That is a bit sad.

My immediate comments on this are

1. the buffer overrun described above happens (as well) on the MACRAW socket, which is where the ICMP packets are read from, not just IPRAW
2. with the randomness of a real network and card, and the buffer overrun, it will be extremely hard to tell what is a HW bug from a SW bug. In the emulator I was always hitting the overrun at packet 25, so it was easy to reproduce and diagnose

[burniouf]

agree, but you are not supposed to reach this step of execution, as the REAL hardware bug prevents you getting at this step....
typical scenario is first using UDP socket to get DHCP lease, then you could be able to use ICMP socket to ping...
so something to do may be to start by setting static IP...then pinging......this should work on real HW....in this state, yes we could check if automatic buffer roll stuff is only applicable to SINGLE socket config....and of course i could update UTHER2.AI.DRV code to handle that

[patrickbst]

I am moving this to 0.95 (at the earliest) and to "enhancement" as the AI driver is not critical to A2osX (its a new nice have). We will need to reevaluate after 94 release the priority of this enhancement.