Migrating from Xavier to Orin, ethernet won't come up

I’m working with a board that was originally developed for a Xavier AGX module, but we’ve built an adapter board to allow us to fit an Orin AGX to it. This means we’re using the same Marvell 88E1512 PHY we used with the Xavier version, and it communicates using RGMII. After reading other posts here, we’ve enabled the ethernet@2310000 and disabled ethernet@6800000. Also, as mentioned in other posts, we’ve reviewed our pinmux spreadsheet and the pinmux dtsi file generated from it and all the signals related to RGMII appear to be configured correctly.

I’m attaching our top-level dts file and all the spreadsheet generated dtsi files, and including a snippet of dmesg output to show how the driver is failing at this time.

One other post recommended checking /sys/bus/mdio_bus/devices/ to see if the ethernet interface appeared there. It does not.

dmesg output:

[   11.301123] nvethernet 2310000.ethernet: Adding to iommu group 52
[   11.301320] nvethernet 2310000.ethernet: failed to read skip mac reset flag, default 0
[   11.301324] nvethernet 2310000.ethernet: failed to read MDIO address
[   11.301328] nvethernet 2310000.ethernet: setting to default DMA bit mask
[   11.688141] nvethernet 2310000.ethernet: Ethernet MAC address: 48:b0:2d:ef:1f:2e
[   11.690171] nvethernet 2310000.ethernet: Macsec not enabled
[   11.690174] nvethernet 2310000.ethernet: Macsec: Reduced MTU: 1466 Max: 8000
[   11.691499] nvethernet 2310000.ethernet: eth0 (HW ver: 53) created with 8 DMA channels
[   13.116801] nvethernet 2310000.ethernet: [poll_check][42][type:0x4][loga-0x0] poll_check: timeout
[   13.116816] nvethernet 2310000.ethernet: ether_open: failed to initialize MAC HW core with reason -1

dt-files.tar.gz (7.2 KB)

The pinmux seems not matching to the document.

We discovered that the six rx pins didn’t have the pullup enabled. I made this modification to the dtsi file, rebuilt the dtb and updated the device, but we are still seeing the same errors.

Looking forward to your next suggestion.

Always share new dmesg after you did any modification.

It is far better than only telling “it does not work”.

My apologies, I thought it was clear that when I said “the same errors” that I meant that the output in dmesg was the same. Here’s the output from the ethernet driver after the pull-up changes were made to the device tree:

[   10.901134] nvethernet 2310000.ethernet: Adding to iommu group 49
[   10.901921] nvethernet 2310000.ethernet: failed to read skip mac reset flag, default 0
[   10.901925] nvethernet 2310000.ethernet: failed to read MDIO address
[   10.901930] nvethernet 2310000.ethernet: setting to default DMA bit mask
[   11.296999] nvethernet 2310000.ethernet: Ethernet MAC address: 48:b0:2d:ef:1f:2e
[   11.301544] nvethernet 2310000.ethernet: Macsec not enabled
[   11.301549] nvethernet 2310000.ethernet: Macsec: Reduced MTU: 1466 Max: 8000
[   11.302961] nvethernet 2310000.ethernet: eth0 (HW ver: 53) created with 8 DMA channels
[   13.378243] nvethernet 2310000.ethernet: [poll_check][42][type:0x4][loga-0x0] poll_check: timeout
[   13.378253] nvethernet 2310000.ethernet: ether_open: failed to initialize MAC HW core with reason -1

As well, I’ve attached the entire dmesg output.
dmesg.gz (15.9 KB)

I notice you directly using jetpack6 to bring up.

Could you test jetpack5 first? You are not the first one bring up 88E1512 on Orin AGX custom board, but most every of such case was based on jetpack5.

please dump the result of these registers.

busybox devmem 0x02434070: 
busybox devmem 0x02434078: 
busybox devmem 0x02445058: 
busybox devmem 0x02445018: 
busybox devmem 0x02445010: 
busybox devmem 0x02445008: 
busybox devmem 0x02445000: 
busybox devmem 0x02445068: 
busybox devmem 0x02445040:
busybox devmem 0x02445030: 
busybox devmem 0x02445028: 
busybox devmem 0x02445020: 
busybox devmem 0x02445070:
busybox devmem 0x02445060: 
busybox devmem 0x02445038: 
busybox devmem 0x02445048: 
busybox devmem 0x02445050:

Sorry for the delay, here is the output:

0x00000414
0x00000014
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002415
0x00002000

0x02434070 is for GPIO G,4 and 0x00000414 indicates bit 10 is 1 which is SFIO but not GPIO.

Which means the pinmux seems still wrong.

I looked at the pinmux dtsi generated by the spreadsheet, and I found this:

      soc_gpio17_pg4 {
        nvidia,pins = "soc_gpio17_pg4";
        nvidia,function = "rsvd0";
        nvidia,pull = <TEGRA_PIN_PULL_UP>;
        nvidia,tristate = <TEGRA_PIN_ENABLE>;
        nvidia,enable-input = <TEGRA_PIN_ENABLE>;
        nvidia,lpdr = <TEGRA_PIN_DISABLE>;
      };

And just to confirm, I decompiled the dtb file and found this:

			soc_gpio17_pg4 {
				nvidia,pins = "soc_gpio17_pg4";
				nvidia,function = "rsvd0";
				nvidia,pull = <0x02>;
				nvidia,tristate = <0x01>;
				nvidia,enable-input = <0x01>;
				nvidia,lpdr = <0x00>;
			};

The first block here seems to match exactly with what’s shown in the adaptation guide. The second section, taken from the decompiled dtb, appears to match the source. And just to be sure, I looked in /proc/device-tree/pinmux@2430000/common/soc_gpio17_pg4 and the entries there also match the values shown above.

Is there some other way for this pin’s function to be changed?

You could try to add this pin to the gpio dts file and it shall force it to be a gpio.

I’m sorry, it seems my last comment was unclear. The first device-tree snippet is taken from Orin-jetson_agx_orin_fe-pinmux.dtsi, a file generated by the pinmux spreadsheet, and it is included in my franken.dts file (see the tar file I uploaded earlier).

My dts file is being compiled into a dtb (franken.dtb) and I then decompiled that file and loaded the result into an editor where I found the second snippet above, which seems to confirm that the pin will be configured correctly.

If the pin description above is not correct (I believe that it is as it matches what I found in the adaptation guide) could you provide the correct description so that I can modify my file accordingly?

Hi,

I’m sorry, it seems my last comment was unclear. The first device-tree snippet is taken from Orin-jetson_agx_orin_fe-pinmux.dtsi, a file generated by the pinmux spreadsheet, and it is included in my franken.dts file (see the tar file I uploaded earlier).
My dts file is being compiled into a dtb (franken.dtb) and I then decompiled that file and loaded the result into an editor where I found the second snippet above, which seems to confirm that the pin will be configured correctly

Unfortunately, this whole comment from you is wrong.

The pinmux dtsi files are not in use in kernel dtb. They should be copied to Linux_for_Tegra/bootloader and Linux_for_Tegra/bootloader/generic directly.

Your franken.dtb is kernel device tree which won’t handle pinmux things.

This is mentioned in below document.
https://docs.nvidia.com/jetson/archives/r36.2/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html#pinmux-changes

This is the missing piece of information that I needed! I’ve read through the adaptation guide to make sure there isn’t anything else that is changed (vs Xavier) that I need to be aware of so get this device working.

Thanks for your help.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.