Our customized Orin carrier board which replaces the Marvell AQR113C 10G PHY to Realtek RTL8211F-CG 1G PHY. It can works well when uses L4T from 35.1 to 35.4.1.
I merge the configurations to L4T 36.3, but the ethernet device does not been created.
Please help to check it, thanks.
8211f_jp6_36_3.zip (76.8 KB)
Looks like even the MGBE node is not enabled.
1.RTL8211F-CG is 1G, and we use RGMII interface instand of MGBE.
2.We also change ODMDATA from #1 to #2 to fit our HW design.
Configuration #2
ODMDATA=“gbe-uphy-config-0,hsstp-lane-map-3,nvhs-uphy-config-0,hsio-uphy-config-16”;
3.The previous attached (Linux_for_Tegra/source/hardware/nvidia/t23x/nv-public/nv-platform/tegra234-p3737-0000.dtsi/tegra234-p3737-0000.dtsi) is incorrect, I attached the new one.
8211f_jp6_36_3_0722.zip (59.8 KB)
Hi,
I don’t need these files. I just need your dmesg…
dmesg log file is in the first zip file.
log_dmesg.txt (62.8 KB)
[ 9.892219] ether_get_mac_address_dtb: bad mac address at /chosen/nvidia,ether-mac0: NULL.
[ 9.892259] nvethernet 2310000.ethernet: No Mac address local DT!
[ 9.892262] nvethernet 2310000.ethernet: failed to get MAC address
[ 9.893486] nvethernet: probe of 2310000.ethernet failed with error -2
Did you disable EQOS driver in your UEFI stage dtb? The mac address node is handled in that stage.
1.Could you give more information about EQOS driver ?
2.When I use key word “eqos” to search in L35.4.1 and L36.3. EQOS related files are found in
source/nvethernetrm folder of L36.3. Some other files in nvidia/drivers/misc/eqos_ape are found of
35.4.1. Are files in nvethernetrm enough for the EQOS driver of 36.3 ?
3.How can I sure the EQOS driver is included in my image ? Does it link with kernel image or a module in ko file ?
4.From the Linux_for_Tegra/source/kernel_src_build_env.sh, the OOT_SOURCE_LIST variant includes nvethernetrm , but I can’t found how to build the nvethernetrm in the Linux_for_Tegra/source/Makefile, may I know how to build the nvethernetrm of 36.3 ?
OOT_SOURCE_LIST=“nvethernetrm nvgpu nvidia-oot hwpm hardware nvdisplay”
麻煩注意一下我們現在在討論UEFI. 你在kernel裡面找東西是沒有意義的…
Please be aware that we are talking about UEFI now. There’s no point to look for something inside the kernel…
UEFI也有自己的device tree設定. 只要你的RGMII 或是 MGBE ethernet node是 status "okay"的狀態, EQOS driver就會執行然後會幫你從cvm eeprom裡面抓出MAC address放進kernel dtb裡面.
UEFI has its own device tree setting. Once the RGMII or MGBE node is set to status “okay”, eqos driver will be enabled and handle the MAC address from cvm eeprom.
I set the cvb_eeprom_read_size to 0 to avoid the EEPROM checking for our customized carrier board.
After I restore cvb_eeprom_read_size to 0x100, and clone EEPROM data of Orin dev-kit to our customized carrier board.
The Realtek RTL8211F-CG 1G PHY works(eth0), but the driver is nvethernet.
Currently, the orange LED is flash, but the green LED is off.
TX/RX data rate can over 900Mbps.
1.How can I set the green LED to on(10/100/1000M) when the network is working by using nvethernet driver?
2.How can I let Orin to use realtek driver(realtek.ko-driver/net/phy/realtek.c) correctly instead of nvethernet driver?
Attached are
1.kernel dmesg ( log_dmesg.txt)
2.network infomation of our carrier board. (log_net.txt)
3.dts is converted form current dtb of device.(kernel_tegra234-p3737-0000+p3701-0004-nv.dtb.txt)
eth0 : realtek phy
eth1: realtek pcie network adapter(driver: r8168)
log_dmesg.txt (63.6 KB)
log_net.txt (4.4 KB)
kernel_tegra234-p3737-0000+p3701-0004-nv.dtb.txt (314.9 KB)
This comment makes no sense. It is something else fixed the issue. Not above.
1.How can I set the green LED to on(10/100/1000M) when the network is working by using nvethernet driver?
2.How can I let Orin to use realtek driver(realtek.ko-driver/net/phy/realtek.c) correctly instead of nvethernet driver?
The phy node in your deivce tree is wrong so that it does not call the realtek driver.
To enable old GPIO sysfs style on r36.3.0, I set two kernel config to “y”
CONFIG_EXPERT=y
CONFIG_GPIO_SYSFS=y
After disable these two configs, the net phy can work correctly, thanks.
Why are these two ever related to etherent phy? This sounds not quite reasonable.
I append the CONFIG_REALTEK_PHY=m to end of our defconfig, and forget to remove the CONFIG_REALTEK_PHY=y.
It causes the LED side effect, after restore the setting, the phy works correctly.