If multiple modules all hit same issue in UEFI, then we need to check why below line gets failure.
I know what you mean,
Just now I checked the circuit and found that there was indeed a problem on our custom carrier board. The output voltage of the power chip was wrong, but I don’t know whether this anomaly will affect the invalidation of the cvm eeprom.
I can test it on the original factory board,
Ok, if you have devkit board, then you can either put the debug UEFI to it and flash or just flash with sdkmanager.
If mac address appears in device-tree/chosen, then it means the module is fine. Need to check the custom board.
Hi Wayne,
I remember one thing, the configuration inside my bootloader/tegra234-mb2-bct-common.dtsi and it has been, cvm_eeprom_read_size = < 0x0> .
You need to set it back to default value…
I set the cvm eeprom to the default value,
This is flash on my custom pad,
tegra234-mb2-bct-common.dtsi (31.7 KB)
log.txt (216.0 KB)
Looks like eeprom value is back and so does the mac adderss. So the module is fine. Please go back and use your dtb and pinmux for RGMII now.
I have now successfully completed flash on a custom pad.
The configuration information about the device tree is displayed：
tegra234-p3701-0000-p3737-0000.dts (525.8 KB)
tegra234-mb1-bct-gpio-p3701-0000-yc8.dtsi (2.7 KB)
tegra234-mb1-bct-padvoltage-p3701-0000.dtsi (1.4 KB)
tegra234-mb1-bct-pinmux-p3701-0000-yc8.dtsi (64.6 KB)
tegra234-ethernet-3737-0000.dtsi (1.9 KB)
p3737-0000+p3701-0000.conf (3.7 KB)
Hi,
You need to try to learn how to check some log by yourself… It is really not hard to do this…
For example, your customized device tree totally not gets in use on the board…
I am so sorry, because I am also in the learning stage, please bear with me…
I built the kernel with “$./nvbuild.sh -o $PWD/kernel_out” and successfully replaced the relevant files.
According to Kernel Customization — Jetson Linux Developer Guide documentation The kernel construction documentation for Kernel successfully replaced the old nvgpu. Linux_for_Tegra/kernel/dtb/, Image. ko, and Linux_for_Tegra/kernel/dtb/.
Hi,
I don’t quite understand… it seems you knew how to update dtb yesterday… why you asked such question today again?
I did not replace the old dtb just now, which was caused by my negligence.
Now I have replaced the dtb again, and I see that the MAC address already exists in the log message
[ 12.532202] nvethernet 2310000.ethernet: Adding to iommu group 51
[ 12.538626] nvethernet 2310000.ethernet: failed to read skip mac reset flag, default 0
[ 12.546811] nvethernet 2310000.ethernet: failed to read MDIO address
[ 12.553361] nvethernet 2310000.ethernet: setting to default DMA bit mask
[ 12.560274] nvethernet 2310000.ethernet: max-platform-mtu DT entry missing, setting default 1500
[ 12.569306] nvethernet 2310000.ethernet: Failed to read DMA Tx ring size, using default [1024]
[ 12.578173] nvethernet 2310000.ethernet: Failed to read DMA Tx ring size, using default [1024]
[ 12.637167] mmc1: new ultra high speed SDR104 SDXC card at address 1388
[ 12.644466] mmcblk1: mmc1:1388 Stora 58.9 GiB
[ 12.806087] mmcblk1: p1
[ 12.830558] nvethernet 2310000.ethernet: Ethernet MAC address: 48:b0:2d:7d:d5:4e
[ 12.838596] nvethernet 2310000.ethernet: Macsec not enabled
[ 12.844330] nvethernet 2310000.ethernet: Macsec: Reduced MTU: 1466 Max: 1500
[ 12.852772] nvethernet 2310000.ethernet: eth0 (HW ver: 53) created with 8 DMA channels
Here are the ifconfig & ethtool command results below:
eth0 does not appear to have been successfully established
nvidia@nvidia-agx-orin:~$ ifconfig
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 790 bytes 50636 (50.6 KB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 790 bytes 50636 (50.6 KB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
rndis0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether ee:59:2c:98:7b:49 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
ether ee:59:2c:98:7b:4b txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
nvidia@nvidia-agx-orin:~$ sudo ethtool eth0
Settings for eth0:
Cannot get device settings: No such device
[ 198.583455] nvethernet 2310000.ethernet eth0: ether_get_wol: phydev is null check iface up status
Supports Wake-on: d
Wake-on: d
Link detected: no
Great, we can go back and check RGMII issue now. Please attach full dmesg too.
Could you check if /proc/interrupt |grep eth has any increasing when ifconfig up/down eth0 interface?
Hi,
- When I use ifconfig up/down eth0, “No such device” appears,And describe the MDIO device address disappeared，
root@nvidia-agx-orin:/# ifconfig eth0 up
[ 511.543468] mdio_bus 2310000.ethernet: MDIO device at address 1 is missing.
[ 511.550695] nvethernet 2310000.ethernet: failed to connect PHY
[ 511.556730] net eth0: ether_open: Cannot attach to PHY (error: -19)
SIOCSIFFLAGS: No such device
2.I checked the/proc/interrupts | grep eth have increased, but it is empty, no response.
3.This is the dmesg information after I used ifconfig eth0 up，
dmesg.txt (64.9 KB)
Currently, there is a problem with the network chip on my carrier board. The problem is being solved. I can update the debugging progress with you later.
I still need other configuration on my pad, I need to configure “For PHY” to use 10G network to connect to the switch. But I was in "Page Not Found Series.html?highlight=rgmii#for-switch "does not see how to configure pinmux accordingly.
Use this page …
https://docs.nvidia.com/jetson/archives/r35.2.1/DeveloperGuide/index.html
Not only ODMDATA, you need to configure the pinmux and device tree too…
HI Wayne,
Thank you very much for your help. I have finished the configuration of RGMII.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.