Hi,

Gesendet: Dienstag, 11. Januar 2022 um 19:17 Uhr
Von: "Alvin Šipraga" [off-list ref]

Luiz, any comments regarding this? I suppose if the chip ID/revision is
the same for both 67S and 67RB, they should work pretty much the same,
right?

my phy driver is same for both devices and afaik only do different RX/TX delays. With the chip-rev-patch 0x0020 i can init the switch, but have no technical documentation except the phy driver code.

Ping working but TCP not working is a bit strange. You could check the
output of ethtool -S and see if that meets your expectations. If you
have a relatively modern ethtool you can also append --all-groups to the
comment to get a more standard output.

as far as i see in tcpdump (suggested by luiz) on target it is a checksum error where checksum is always 0x8382 (maybe some kind of fixed tag).

16:39:07.994825 IP (tos 0x10, ttl 64, id 54002, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.2.43284 > 192.168.1.1.22: Flags [S], cksum 0x8382 (incorrect -> 0xa6f6), seq 3231275121, win 64240, options [mss 1460,sackOK,TS val 1615921214 ecr 0,nop,wscale 7], length 0
16:39:12.154790 IP (tos 0x10, ttl 64, id 54003, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.2.43284 > 192.168.1.1.22: Flags [S], cksum 0x8382 (incorrect -> 0x96b6), seq 3231275121, win 64240, options [mss 1460,sackOK,TS val 1615925374 ecr 0,nop,wscale 7], length 0

You can also try adjusting the RGMII TX/RX delay and pause settings -
that might help for the R2 where you aren't getting any packets
through.

r2pro i got working by setting both delays to 0 as phy-driver does the same (after some calculation).

on r64 this is a bit more tricky, because the phy driver uses  tx=1 and rx=3 with this calculation for reg-value

regData = (regData & 0xFFF0) | ((txDelay << 3) & 0x0008) | (rxDelay & 0x0007);

but in dts i need the values in picosends (?) and here i do not know how to calculate them

regards Frank