Enabling DP83867 on Jetson Orin

Autonomous Machines Jetson & Embedded Systems Jetson AGX Orin
1
  1. Device tree update [tegra234-ethernet-3737-000.dtsi] → REFER IMAGE-1 TAG IN ATTACHED IMAGE
/ {
	/* MGBE - A */
    //	ethernet@6810000 {
	/* RGMII - A */
	ethernet@2310000 {
		status = "okay";
		nvidia,mac-addr-idx = <0>;
		nvidia,max-platform-mtu = <8000>;
		nvidia,pause_frames = <0>;
		local-mac-adress = [1a 2b 3c 4d 5e 6f];
		nvidia,phy-reset-gpio = <&tegra_main_gpio TEGRA234_MAIN_GPIO(G, 5) 0>;
		phy-handle = <&phy>;
		phy-mode = "rgmii-id";		

		mdio {
			compatible = "nvidia,eqos-mdio";
			#address-cells = <1>;
			#size-cells = <0>;
		phy: phy@0 {
				reg = <0>;
				compatible = "ethernet-phy-ieee802.3-c22";
				tx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
				rx-fifo-depth = <DP83867_PHYCR_FIFO_DEPTH_4_B_NIB>;
				ti,max-output-impedance;
			//	ti,clk-output-sel = <DP83867_CLK_O_SEL_CHN_A_RCLK>;
				ti,rx-internal-delay = <DP83867_RGMIIDCTL_2_25_NS>;
				ti,tx-internal-delay = <DP83867_RGMIIDCTL_2_75_NS>;
				interrupt-parent = <&tegra_main_gpio>;
				interrupts = <TEGRA234_MAIN_GPIO(G, 4) IRQ_TYPE_LEVEL_LOW>; //<TODO> Need to check
			};			
		};
	};
};
  1. DP83867 is enabled through tegra_defconfig → REFER IMAGE-A TAG IN ATTACHED IMAGE

    CONFIG_DP83867_PHY=m
    We do see DP83867 as part of /sys/bus/mdio_bus/drivers/

  2. Post flashing image, we see following on bootup console [have just copied the ethernet related logs, refer attachment (log_6MArch.log.txt) for complete log]
  3. ifconfig shows eth0
  4. We ascertained that driver is loaded [just tried insmod and its stated as its already in use]
orin@orin-desktop:—$ [11328.592384] Error: Driver 'TI DP83867' is already registered, aborting..

Questions

  1. On console we see errors like these, how do we resolve this
[   12.642162] nvethernet 2310000.ethernet: failed to read skip mac reset flag, default 0
[   12.650317] nvethernet 2310000.ethernet: failed to read MDIO address
[   12.663780] nvethernet 2310000.ethernet: Failed to read DMA Tx ring size, using default [1024]
[   12.672637] nvethernet 2310000.ethernet: Failed to read DMA Tx ring size, using default [1024]
[   12.689292] nvethernet 2310000.ethernet: Ethernet MAC address: 48:b0:2d:94:ac:db
[   12.697342] nvethernet 2310000.ethernet: Macsec not enabled
  1. We do not see any transaction on eth0, plus should we really expect our PHY on eth0 or eth0 is reserved for 10G the one we have should appear on eth1

log_6MArch.log.txt (69.2 KB)

3

Hi,

  1. Have you checked the pinmux? The pinmux won’t enable RGMII in correct state by default.

https://docs.nvidia.com/jetson/archives/r35.5.0/DeveloperGuide/HR/JetsonModuleAdaptationAndBringUp/JetsonAgxOrinSeries.html?highlight=rgmii#for-rgmii

  1. The Failed to read DMA Tx ring size error has been resolved in later jetpack. I would suggest you can just upgrade your BSP.
4
  • We will check and revert on pinmux, probably will share the pin-mux files of ours
  • I think jetpack we are using is latest, shall check exact number but what we see in running image is VERSION as “ubuntu 20.04.6 LTS”

From the dts file we shared where we have mdio node with compatible string as “nvidia,eqos-mdio” we donot see the logs which indicates eqos-mdio probe function being called, any thoughts around this

5

Hi,

  1. You are definitely not using the latest jetpack because your kernel version is not the latest one. Ubuntu version is not kernel version. Every jetpack5 is ubuntu20.04. Not surprise to see that result.

  2. You are not the first user enable RGMII or MGBE and as I remember ,there won’t be a extra thing called “eqos-mdio” in driver log. You can search other posts and you will find out all we are check is the pinmux.

6

it seems we did share the pin mux in earlier thread

Based on that thread and the question from there, I would like to state that we do not see interrupts incrementing for eth0
Shall share output of /proc/interrupts in sometime

7

Hi,

This post seems not having a very effective discussion. Please dump your /proc/interrupts first and then we can discuss it later.

8

We would like to know what is the preferred way of updating JetPack to JetPack6.
Do we need to re-flash everything or we can just update on running image.
Some ref. link would help.
Thanks

9

Hi,

I don’t understand why our discussion here becomes “how to update jetpack to jeptack6”.

There is no point to upgrade BSP to Jetpack6 for this topic. Just upgrade to the latest one in Jeptack5…

Are you sure you understand what my previous post meant?

10

We will be updating to Jetson Linux 35.5.0 is part of [JetPack 5.1.3]
Will build image and revert too

11

Please find attached output of /proc/interrupts
proc-intr.txt (24.0 KB)

12

Hi,

Please clarify all the things first.

  1. Did you upgrade the BSP version already? If it is, which is the interrupt result based on? Old release or new release? What is the dmesg in this situation?

  2. Please dump all the result of below register.

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:
13

This was with older BSP version [We are building image with latest and that would take sometime]
Will share dump of registers tomorrow

14

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

15

pinmux result looks not correct… Are you sure you followed the document?

16

I need to check that with my Hardware Engineer.
You mentioned some document to follow, share link for same.
Apologies if its a novice ask, i hopped on this bit later and am supporting from Linux standpoint.
Also please state what exactly you mean when you say “pinmux result looks not correct”
Would help us to debug where we went wrong.

Thanks

17

Hi,

Please also read the previous post… I don’t know who is that guy in that post but I already posted the document over there.

Looks like all of previous communication in that post is in vain…

Those registers you shared are the setting of the pinmux. Each register represents the pinmux for one pin.
And the result is not matching to what we expected from the document. That is why I said the pinmux is not correct.

If you don’t even know what does pinmux mean, then it is another long story.

18

:) i understand the pin-mux
In past have worked with pin-mux utility from TI for sitara processors. (AM335x,AM437x,AM63x)
Shall check the document as suggest
Thanks

1 Like
19

Hi Wayne,

Please find pinmux details in attachment
Orin-jetson_agx_orin-gpio-default.txt (4.9 KB)
Orin-jetson_agx_orin-pinmux.txt (65.7 KB)
.

Thanks
Sagar

20

Hi,

I don’t really want to review your file as our document already mentioned. Please refer to document , do the update and share the register dump as my previous comment.

22

We continue to analyze the misses we have w.r.t pin-mux.
I spent some time to map the contents of each registers and what we observe from devmem
I am attaching this for reference here.
DetailingRegisters-R1.0.pdf (82.5 KB)

As we populate the expected bits for each register, it would help if you could have a quick look and state few registers/bits in those registers which appears wrong
Thanks
-maheshG