Hello,
We’re flashing an Industrial Xavier Module and running into issues modifying the device tree. Is there someone or an organization that provides consulting for this work.
v/r
Tod
Please provide mode information of the issue you met?
Then we can provide the suggestion.
Hi thagan,
Are you using “AGX Xavier” or “AGX Xavier Industrial” module?
Are you developing the custom board?
What’s your exact issue about modifying the device tree?
And what’s the L4T release in use?
We are using the AGX Xavier Industrial.
Developing custom board.
Using Jetpack 4.6.1
We have changed the Ethernet PHY IC from the original device on the dev kit to the KSZ9021. It seems as though we need to change or add a device located in /sys/bus/mdio_bus/devices from the default that works with the new Ethernet IC. The KSZ9021 driver does live in the /sys/bus/mdio_bus/drivers location once flashed (along with the list of other drivers), but the Xavier AGXi does not see it physically. We are looking to create a modification to the device to specifically tell the Xavier what chip to look for on the Ethernet bus so it can handshake and be used. Currently, our schematic mirrors that from the design guide with the exception of high speed voltage translators to lift the 1.8V from the Xavier to the 3.3V required by the KSZ9021. The TX lines, RX lines and MDIO/MDC are grouped on 3 separate voltage translators. TX and RX line groups are each on 1 directional translator (SN74AXC8T245-Q1) set to their proper direction and the MDIO/MDC lines are on a third translator (TXS0102-Q1) setup for bidirectional operation. The assumption here being that we need to have a device specific setting for our Ethernet chip in the Device Tree to get it functioning correctly.
Can you please share a diagram of your Ethernet design?
I’ve found several topics about using and configuring KSZ ethernet phy.
Please refer to them to check if they could help:
how to replace net PHY of Xavier - #10 by JiaZW
RGMII doesn't work with ksz9031 - #3 by _YonMeen
Xavier eth0 don't work after changing phy chip - #4 by bwp2012
Use KSZ9896 as PHY on Jetson AGX Xavier · Issue #89 · Microchip-Ethernet/EVB-KSZ9477 · GitHub
Hello Trumany and KevinFFF,
I am currently working with thagen on this project at the board level. Our schematic for the Ethernet portion is as follows:
NVIDIA Design Guide Figure 8-1 for reference:
The MDIO and MDC nets coming from the Xavier are on the left side and the KSZ9021 on the right. The TXS0102-Q1 is specifically recommended by TI as a high speed, bidirectional voltage translator for MDIO and MDC lines. The Design Guide shows an internal 1.5K pull-up on the MDIO line to 1.8V along with an external 2.2k pull up to 1.8V that results in ~891 Ohm parallel resistive pull up to 1.8V. The TXS0102-Q1 has an internal 10K pull-up to 1.8V aswell so I placed R85 as 2.84k (in place of the 2.2k in the Design Guide) to match the desired ~891 Ohm parallel resistive pull up to 1.8V. On the MDIO 3.3V side (right side) the manufacturers of the KSZ9021 requires an external 1k to 4.7k pull up to 3.3V. Since the TSX0102-Q1 has in internal 10K pull up to 3.3V I placed R65 as a 4.7k so that the parallel resistive pull up to 3.3V is in the 1k - 4.7k range, ~3.2k The MDC line is internally pulled up to 1.8V and 3.3V by the TSX0102-Q1, 10K internal pull up on each side.
Here at U32, SN74AXC8T245-Q1, we have all RX lines from the KSZ9021 going into the voltage translator with the direction set from A to B (3.3V to 1.8V). Not shown on the schematic is a 10k pull-up on ENET_INT added to the physical board. Again the SN74AXC8T245-Q1 was chosen for voltage translation here refencing TI’s Ethernet Translation app notes.
Here at U30, SN74AXC8T245-Q1, we have all TX lines from the Xavier going into the voltage translator with the direction set from A to B (1.8V to 3.3V). Including the ENET_RST_N. This is the same IC used in the RX translation.
And here is U27, the KSZ9021 PHY. This schematic includes my hand drawn changes on it. The pull-up/down on the RGMII_RXC, RGMII_RD0, RGMII_RD1, RGMII_RD2, and RGMII_RD3 all relate to strapping conditions for the KSZ9021. Strapping for RGMII_RD0, RGMII_RD1, RGMII_RD2, and RGMII_RD3 as 0, 1, 1, 1, respectively, set the PHY to the following mode: RGMII Mode - advertise all capabilities (10/100/1000 speed half/full duplex), except 1000Base-T halfduplex. Strapping on the RGMII_RXC and two other pins not going to the Xavier (E_LED1 and E_LED2) set the PHY address. This is current set to PHY address of 3 but could easily be changed at anytime to suit the needs of the Xavier.
Have you validated such design in previous project? The level shift to RGMII is not usual since RGMII is 1.8V port. Does it follow the reference design of PHY chip? Maybe you need to check the INT and RESET signals to make sure if any communication built.
Specifically using voltage translation for RGMII has not been previously validated here, but we have successfully used the KSZ9021 in the past communicating with an FPGA. In this current design we are following the design guidance from the KSZ9021 datasheet in a similar manner that was used on the FPGA the only difference here is voltage translation.
The reason the 1.8V signals are being shifted to 3.3V is due to the KSZ9021 PHY only being a 2.5V/3.3V signal device and unable to Transmit or Receive 1.8V. Because of this we followed an application guide from TI for voltage translation between the two devices specifically for RGMII.
I did have a few more questions about how the Xavier AGXi functions when it comes to creating a device in /sys/bus/mdio_bus/devices. Does the device in that location get generated as a result of the flashing process or is it generated each time the Xavier AGXi is booted and the Xavier finds a device it can talk to?
I will check the INT and RESET lines again.
Pseudo files in “/sys” (and “/proc”, and mostly in “/dev”) are not real files and don’t exist on the filesystem. These are drivers “pretending” to be files in RAM. They are a direct result of the driver existing with the right arguments. Should the driver not load, then the files will be missing. Note that it is possible for a driver to fail to load or to not have proper arguments passed to it at the time of loading, which would cause a problem with those files showing up. Having found an actual device is usually part of the argument passing requirement. Plug-n-play devices, which can self-identify, often make this easier (such devices have a helper layer to broadcast devices found and specs). This includes PCIe devices. Many other devices, which are not plug-n-play, must have their existence and parameters included in the device tree.
The configurations in device tree would be used by the driver at probe function while the board boot up.
Have you refer to the previous topics I shared to porting KSZ9021 on your board?
Is there any serial console log could be shared for further check?
Below is a boot log from the debug port. Nothing shows up when the looking in the /sys/bus/mdio_bus/devices directory. At the moment the only portion of our custom carrier board we have worked on is the Ethernet so I2C, HDMI and other things are showing errors but we are not yet addressing those.
Ethertest6_Debug Uart Boot Log.log (45.7 KB)
Can you post a copy of “/proc/config.gz”? Also, which driver configuration within that file identifies the one you are looking at (is this integrated or is it a module)? Or is this a third party module not from the stock kernel source? If and only if the driver is in the form of a module, what do you see from:
lsmodfind /lib/modules/$(uname -r)/kernel -type f
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.