JP6.1 Orin AGX Custom Board ETH Phy 88E1512

Robotics & Edge Computing Jetson & Embedded Systems Jetson AGX Orin
,
1

Hi,

I am trying to make the PHY 88E1512 RGMII work. After studying posts like this and this and the official JP6.1 documentation, I do not see any issues in the configuration.

I can confirm that the correct pinmux configured correctly is in effect as I wrote it in the flashing conf file, the nodes in the device tree are configured correctly, the phy_reset GP5 is High, all the mgbe are disabled.

The PHY and link works only in “serdes” mode with fixed-link node present (so I would exclude any hardware issue), but this is preventing the MDIO configuration of the PHY.

The only strange things by studying the official documentation yielded in some remarks and questions from my side:

  • There is a sintax error ($ instead of &)
  • The documentation specifies tegra_main_gpio, but upon compilation , this is reported as error (reference to non existing node). I used &gpio instead. Question1: Is this OK? Could this be the cause of unfunctionality? I have not seen this change in anywhere in the documentation. Please point me in the right direction.

image
image1162×729 53.3 KB

dmesg.log (60.7 KB)

here is the node:

ethernet@2310000 {
			status = "okay";
			phy-mode = "rgmii-id";
			phy-handle = <&phy>;
			
			nvidia,phy-reset-gpio = <&gpio TEGRA234_MAIN_GPIO(G, 5) 0>;

			nvidia,mac-addr-idx = <0>;
			nvidia,skip_mac_reset = <0>;
			nvidia,mdio_addr = <0>;
			nvidia,pause_frames = <0>;

			mdio {
				compatible = "nvidia,eqos-mdio";
				#address-cells = <1>;
				#size-cells = <0>;

				phy: phy@0 {
					reg = <0>;
					nvidia,phy-rst-pdelay-msec = <224>; /* msec */
					nvidia,phy-rst-duration-usec = <10000>; /* usec */
					interrupt-parent = <&gpio>;
					interrupts = <TEGRA234_MAIN_GPIO(G, 4) IRQ_TYPE_LEVEL_LOW>;
					marvell,copper-mode;
					marvell,reg-init = <0x3 0x12 0x7fff 0x880>;

				};
			};

I based my files (device tree, pinmux etc) on the development kit. Question2: Is there a place where there is some overwriting happening, that is not immediately obvious or not specified in the documentation?

Thank you

2

Hi,
Here are some suggestions for the common issues:

1. Performance

Please run the below command before benchmarking deep learning use case:

$ sudo nvpmodel -m 0
$ sudo jetson_clocks

2. Installation

Installation guide of deep learning frameworks on Jetson:

3. Tutorial

Startup deep learning tutorial:

4. Report issue

If these suggestions don’t help and you want to report an issue to us, please attach the model, command/step, and the customized app (if any) with us to reproduce locally.

Thanks!

3

Did you not understand my questions or this is an automated response?

4

Such thing won’t cause functional issue. It will only cause compile error.

Is there a place where there is some overwriting happening, that is not immediately obvious or not specified in the documentation?

You should check if a overwrite is really happened first by reading /proc/deivce-tree node first. It is basically just the whole device tree running on your board now.

5

Above is just automated response.

6

It seems that the running device tree is the same with what I flashed. There is nothing overwriting, disabling or enabling. Any other suggestions?

7

Have you checked the pinmux setting?

8

Can you please detail how should I check pinmux in the running device tree?

According to the official Documentation of r36.4:

image
image1239×338 38.6 KB

Although running this command gives no output. Could you please explain why this happens?

9

You cannot check pinmux in running device tree because pinmux is not part of device tree at all.

You should go back to check your flash log and see which pinmux file is in use on your board.

10

Yes I know, this is why I though it was a weird thing to ask me since we were talking about the running device-tree.

The flash log suggests that the correct pinmux file is loaded. Here is it attached, maybe I am not understanding it correctly or I misconfigured something.

flash_log.log (564.8 KB)
tegra234-mb1-bct-pinmux-069-649-B-p3701-0000-a04.dtsi.txt (63.8 KB)
tegra234-mb1-bct-gpio-069-649-B-p3701-0000-a04.dtsi.txt (4.8 KB)

11

When you boot up, did you see /proc/interrupts got an increase interrupt for your ethernet interface?

12

Here is what I see. The increase rate is pretty slow though.

emsys@emsys-desktop:~$ cat /proc/interrupts | grep eth
197:          1          0          0          0          0          0          0          0     GICv3 226 Level     eth0.common_irq
198:         14          0          0          0          0          0          0          0     GICv3 218 Level     eth0.vm0
199:          0          0          0          0          0          0          0          0     GICv3 219 Level     eth0.vm1
200:          0          0          0          0          0          0          0          0     GICv3 220 Level     eth0.vm2
201:          0          0          0          0          0          0          0          0     GICv3 221 Level     eth0.vm3
308:          0          0          0          0          0          0          0          0  2200000.gpio  39 Level     2310000.ethernet:00
emsys@emsys-desktop:~$ cat /proc/interrupts | grep eth
197:          1          0          0          0          0          0          0          0     GICv3 226 Level     eth0.common_irq
198:         20          0          0          0          0          0          0          0     GICv3 218 Level     eth0.vm0
199:          0          0          0          0          0          0          0          0     GICv3 219 Level     eth0.vm1
200:          0          0          0          0          0          0          0          0     GICv3 220 Level     eth0.vm2
201:          0          0          0          0          0          0          0          0     GICv3 221 Level     eth0.vm3
308:          0          0          0          0          0          0          0          0  2200000.gpio  39 Level     2310000.ethernet:00
emsys@emsys-desktop:~$
13

Was this board ever validated before?

14

What do you mean by that? I am doing the bring-up now, it is a board made by us.

15

What I mean is the 88e1512 has been validated multiple times by other users before. So basically the software has been validated for like many times.

Sometimes other users would use Xaiver AGX board directly on Orin AGX so I am talking about if any other Xavier AGX has been used on this board before to validate the hardware is correct.

If this didn’t happen before, maybe you should review the hardware too.

16

And are you sure the dmesg you shared to me is the full log?

17

From your answer I draw the conclusion that there is nothing wrong with the configuration I sent you and I should search in the hardware direction.
No, a Xavier AGX was not used on this board, as it was designed for Orin AGX Industrial and I am using with this module.

The dmesg was exported from the target with sudo dmesg > dmesg.log. Does it look incomplete to you? What is missing?

18

There is no error from RGMII interface. More like the phy reset was never happened.

19

Does Reset need to have a pull-up, now it is pull none.

22

There is no pull-up as you can see in the Xavier devkit carrier board design, P2822 schematic.