nic: Fix incorrect wrap handling of RX circular buffer

nic: move other nic functions into the dedicated nic files
uip: alloc buffer multiple of 8 bytes

Signed-off-by: João Silva <jgc3silva@gmail.com>

doc/CpuPort.md

@@ -34,6 +34,21 @@ Next, transfer the actual packet over by repeating the SFR function with a
 pointer to the frame on the ASIC directly after the frame header and a
 length as given by the length in the frame header + 7, again divided by 8.
 
+The RX ring's inclusive last slot is configured as `0x4ff`, giving a byte
+range of `0x0000` through `0x27ff`. If the descriptor occupies the last slot
+at `0x27f8`, its payload starts at `0x0000`, not `0x2800`. The RX copy code
+normalizes that starting address before DMA. It relies on the hardware to
+wrap transfers that start inside the ring and cross its end, as observed
+on SWTGW218AS. Programming an initial address of `0x2800` does not wrap
+and can instead read zeros or stale TX data outside the RX ring.
+
+Frame lengths are checked against `UIP_CONF_BUFFER_SIZE` before copying.
+DMA works in whole eight-byte units. `UIP_CONF_BUFFER_ALLOC_SIZE` rounds
+the backing storage up to the next complete word: 1,560 bytes for the
+1,556-byte logical frame limit. This padding allows a maximum-size frame
+to be transferred directly without a separate tail copy. The logical
+frame limit and advertised MSS are unchanged.
+
 The received frame will have an RTL proprietary Ethernet frame type of
 0x8899 (RRPC) where normally the frame type 0x0800 for IPv4 would be located.
 Further 6 bytes follow describing the frame, before the normal IPv4 data