Rock64 v2 network issues
05-30-2019, 06:10 AM
I'm having regular problems netbooting my Rock64 with U-Boot 2017.09-rockchip-ayufan-1035-gd646df03ac (Oct 26 2018 - 08:36:01 +0000)
The symptoms reflecting the problem are that the LED state on the Rock64 RJ45 is wrong (either the green LED or the orange LED is on but not both) and both the U-Boot console and the switch at the other end of the cable[1] indicate GigE/FDX but the TFTP client reports checksum errors and eventually gives up.
This seems to be solely related to the firmware autonegotiation - once the kernel starts, it's rock solid at 1000/FDX. It also gets less reliable as the ambient temperature drops[2]. Whilst the above firmware isn't the latest, the changelogs for the later versions appear solely related to supporting the RK3399.
Has anyone else seen this problem?
Whilst investigating the problem, I discovered that there's a Rock64 v3 and my board is v2.0. According to ROCK64 SBC v3.0 Change Notice, one change is "Improved transmission packet loss on gigabit Ethernet by adjusting LED0/CFG_EXT and LED2/CFG_LDO1 pull up resistor connect to 3.3V instead of 1.8V." This sounds similar enough to my problem that I thought it was worth looking into. Comparing the v2 and v3 schematics, the only relevant difference is that on v2, R3331 is absent and R3332 is present, whilst on v3, R3331 is present and R3332 is absent. VCCIO_PHY is connected to VCC_IO (3.3V via R3352) in both variants. Based on that, it should be possible to implement that fix on a v2 board by moving R3332 to R3331. Whilst there's no publicly available component overlay for the v2 board, the v3 component overlay in that area agrees with the results of my buzzing out that part of the schematic. Has anyone tried making this mod on a v2 board?
[1] I've tried both a NetGear GigE switch and a spare GigE port on my main server with the same behaviour.
[2] Warming the board with my wife's hairdryer will "fix" the problem.
The symptoms reflecting the problem are that the LED state on the Rock64 RJ45 is wrong (either the green LED or the orange LED is on but not both) and both the U-Boot console and the switch at the other end of the cable[1] indicate GigE/FDX but the TFTP client reports checksum errors and eventually gives up.
This seems to be solely related to the firmware autonegotiation - once the kernel starts, it's rock solid at 1000/FDX. It also gets less reliable as the ambient temperature drops[2]. Whilst the above firmware isn't the latest, the changelogs for the later versions appear solely related to supporting the RK3399.
Has anyone else seen this problem?
Whilst investigating the problem, I discovered that there's a Rock64 v3 and my board is v2.0. According to ROCK64 SBC v3.0 Change Notice, one change is "Improved transmission packet loss on gigabit Ethernet by adjusting LED0/CFG_EXT and LED2/CFG_LDO1 pull up resistor connect to 3.3V instead of 1.8V." This sounds similar enough to my problem that I thought it was worth looking into. Comparing the v2 and v3 schematics, the only relevant difference is that on v2, R3331 is absent and R3332 is present, whilst on v3, R3331 is present and R3332 is absent. VCCIO_PHY is connected to VCC_IO (3.3V via R3352) in both variants. Based on that, it should be possible to implement that fix on a v2 board by moving R3332 to R3331. Whilst there's no publicly available component overlay for the v2 board, the v3 component overlay in that area agrees with the results of my buzzing out that part of the schematic. Has anyone tried making this mod on a v2 board?
[1] I've tried both a NetGear GigE switch and a spare GigE port on my main server with the same behaviour.
[2] Warming the board with my wife's hairdryer will "fix" the problem.