We are making a Jetson orin custom board and using AQR113C.
However, there is one issue regarding the ethernet connection.
When I used marvell’s AQR113C firmware, ethernet did not work, so I read and used devkit’s AQR113C firmware according to below link.
Then two strange phenomena occurred.
When connecting ethernet to another ethernet device during booting, booting does not proceed.
There was a delay in the UEFI firmware part before, but booting proceeded after about 2 minutes, even when the AQR113C firmware was not written to flash, .
After use devkit’s AQR113C firmware, booting does not proceed at all on that part.
If it is not connected to another ethernet device, booting proceeds normally.
When connected to another ethernet device after booting, the ethernet connector connection is recognized by the other device.
However, ethernet is not recognized on the orin side of the custom board.
At the same time, the following log appears in the kernel.
[ 38.333041] nvethernet 6810000.ethernet: [xpcs_lane_bring_up][type:0x4][loga-0x0] Failed to get PCS block lock
When checking the status with mdio, it appears that link up has been recognized in AQR113C.
Our custom board has an EEPROM, but no data has been written. Could this be the cause?
We are using Jetpack 5.1.2 BSP.
What causes it?
I would like to inquire further about other things we have tried.
On another custom board we made, we confirmed that AQR113C operates normally with the AQR113C firmware from nvidia devkit.
So, to check if it was a module problem, I tried switching modules on a board that was operating normally.
However, the same [Failed to get PCS block lock] error occurred in the module that was operating normally.
The module that had an error on the first custom board worked normally when moved to the second custom board.
So I thought it was a problem with AQR113C, so I replaced the IC with another one, but [Failed to get PCS block lock] still occurred.
When I reset phy by executing 0x1e/0x2681 0x1 with MDIO, the connection returned normally as shown in the capture below, but then an error occurred again.
The corresponding kernel log is as follows.