Hello,
I have a LAN driver and I want to take the default MAC address from the EEPROM (Jetson EEPROM Layout — Jetson Linux<br/>Developer Guide 34.1 documentation).
The default MAC address (68-73) is the same that customer MAC address (172-177). The documentation said that:
the boot software builds device tree nodes for these MAC addresses.
Where is this node ?
Thank you
Hi,
There should be a node under /proc/device-tree/chosen
Hi,
I only have this :
drwxr-xr-x 2 root root 0 Sep 5 05:09 ./
drwxr-xr-x 279 root root 0 Sep 8 2022 ../
-r--r--r-- 1 root root 0 Sep 5 05:09 board-has-eeprom
-r--r--r-- 1 root root 215 Sep 5 05:09 bootargs
-r--r--r-- 1 root root 16 Sep 5 05:09 ids
-r--r--r-- 1 root root 8 Sep 5 05:09 kaslr-seed
-r--r--r-- 1 root root 8 Sep 5 05:09 linux,initrd-end
-r--r--r-- 1 root root 8 Sep 5 05:09 linux,initrd-start
-r--r--r-- 1 root root 4 Sep 5 05:09 linux,uefi-mmap-desc-size
-r--r--r-- 1 root root 4 Sep 5 05:09 linux,uefi-mmap-desc-ver
-r--r--r-- 1 root root 4 Sep 5 05:09 linux,uefi-mmap-size
-r--r--r-- 1 root root 8 Sep 5 05:09 linux,uefi-mmap-start
-r--r--r-- 1 root root 8 Sep 5 05:09 linux,uefi-system-table
-r--r--r-- 1 root root 7 Sep 5 05:09 name
-r--r--r-- 1 root root 6 Sep 5 05:09 nvidia,ether-mac
-r--r--r-- 1 root root 31 Sep 5 05:09 nvidia,sku
-r--r--r-- 1 root root 0 Sep 5 05:09 nvidia,tegra-joint_xpu_rail
nvidia,ether-mac
Sorry, it’s something I set in the device tree and it has the dumb value I set in the device tree:
hexdump /proc/device-tree/chosen/nvidia,ether-mac
0000000 cdab 00e5 0100
0000006
If I remove it from the device tree I only have this:
$ ll /proc/device-tree/chosen/
total 0
drwxr-xr-x 2 root root 0 Sep 5 05:42 ./
drwxr-xr-x 279 root root 0 Sep 8 2022 ../
-r--r--r-- 1 root root 0 Sep 5 05:42 board-has-eeprom
-r--r--r-- 1 root root 215 Sep 5 05:42 bootargs
-r--r--r-- 1 root root 16 Sep 5 05:42 ids
-r--r--r-- 1 root root 8 Sep 5 05:42 kaslr-seed
-r--r--r-- 1 root root 8 Sep 5 05:42 linux,initrd-end
-r--r--r-- 1 root root 8 Sep 5 05:42 linux,initrd-start
-r--r--r-- 1 root root 4 Sep 5 05:42 linux,uefi-mmap-desc-size
-r--r--r-- 1 root root 4 Sep 5 05:42 linux,uefi-mmap-desc-ver
-r--r--r-- 1 root root 4 Sep 5 05:42 linux,uefi-mmap-size
-r--r--r-- 1 root root 8 Sep 5 05:42 linux,uefi-mmap-start
-r--r--r-- 1 root root 8 Sep 5 05:42 linux,uefi-system-table
-r--r--r-- 1 root root 7 Sep 5 05:42 name
-r--r--r-- 1 root root 31 Sep 5 05:42 nvidia,sku
-r--r--r-- 1 root root 0 Sep 5 05:42 nvidia,tegra-joint_xpu_rail
Hi,
Just to clarify that. This thing would only appear when the ethernet is using nvidia driver.
However, Orin NX/Orin Nano does not use NVIDIA driver for their etherent. So their mac address is decided by the vendor driver (we use realek phy here).
Hi,
I didn’t use Nvidia driver, so the node wouldn’t happen on Orin NX ? It’s correct ?
Another question, if I want to read the EEPROM in my driver, is a EEPROM driver already exist ? I didn’t find anything. Or I have to write a specific I2C EEPROM to access to the EEPROM ?
Thank you,
I didn’t use Nvidia driver, so the node wouldn’t happen on Orin NX ? It’s correct ?
Yes.
Another question, if I want to read the EEPROM in my driver, is a EEPROM driver already exist ? I didn’t find anything. Or I have to write a specific I2C EEPROM to access to the EEPROM ?
No, you have to write the eeprom driver read from i2c by yourself.
Ok thank you
I’m, using the Jetson Orin Nano 8GB devkit and I can write to the EEPROM after adding below snippet to the dts file (in section i2c@3160000 { … }).
eeprom@50 {
compatible = "atmel,24c02";
reg = <0x50>;
};
Then, I used the tegra-eeprom-tool to write a new serial number and a desired MAC address to the EEPROM, but after booting eth0 does not change it’s MAC address.
Do I understand you correctly that the Jetson Orin Nano 8GB devkit does not support changing the MAC address? If so, which Jetson boards do, so we can switch to another one?
Hi,
The process of how eeprom gets read to etherent on other jetson platform is like below:
If ethernet is based on nvidia driver, then bootloader UEFI will reveal the nvidia,ether-mac node to the device tree. Read the content from eeprom.
After boot up into kernel, each PHY driver has its own method or order to read mac address from somewhere else. For example, Realtek PHY can read mac address from PHY itself or read from device tree. If all of these are not present, then it will use a random number as mac address.
So actually, my previous point was, if you want to read it from eeprom, then you have to go to ethernet PHY driver and probably initiate i2c read from there and let PHY set the mac-address.
I have no idea about why you added a eeprom@50 thing in i2c node. This thing won’t change the behavior in ethernet phy. And as PHY driver is based on each vendor, there is no definite solution from me here.
Hello Wayne
Can you explain precisely what the bootloader UEFI checks to decide it will create a ‘nvidia,ethernet-mac’ node, and where that ‘nvidia,ethernet-mac’ node will be created ?
If either MGBE or RGMII node got enabled in device tree, then UEFI will expose this nvidia,ethernet-mac to the device tree.
As Orin NX/Nano is not using any MGBE or RGMII function on jetson (it is just a PCIe device), this thing didn’t get exposed. Orin NX/Nano NIC is reading the mac directly from the PHY itself.
So, if I put such a node in my device tree (dts file), even if the hardware is not present, will the ‘nvidia,ethernet-mac’ node be created ?
Your system may get crashed during UEFI if the hardware is not present.
Could the creation of the ‘nvidia,ethernet-mac’ in the device-tree ‘chosen’ node become unconditional in a future jetpack ? It seems that many people are interested to get an easy access to those addresses without having to rewrite themselves the decoding of the nvidia eeprom. Adding an access to the ‘/chosen/nvidia,ethernet-mac’ can then simply be added to the used ethernet driver or even to the common ‘of_get_mac_address’ function.
As UEFI are open source, you can check that and create your own driver to enable that node.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.