Is this an Xavier NX dev kit? Or is this using a third party carrier board? If a third party carrier board, then you need their flash software (which will likely be either an edit to apply to the NVIDIA software, or their own complete flash setup; in some cases, but not smaller DIMM format, they might say to just use NVIDIA’s flash software).
If this is a dev kit, then R35.4.1 should have worked. If this is the case, then I suspect something was wrong with the flash procedure, e.g., an SD card model requires flashing the Jetson itself and not just the SD card.
I don’t think this is really a problem regrading configuration.
Xavier NX on board ethernet is inside the module… there is totally no need to configure anything to make it work…because you totally cannot change this part.
After testing, I found that Jetson Xavier NX can communicate normally on the network on the development kit, but cannot communicate on our company’s board.
However, using the l4t-32.7.3 version, both our company’s boards and development kits can communicate. Is this related to the dts parameter?
Is everything on your company’s carrier board, for the networking, including power rails, exactly the same? Is there a difference in that compared to the dev kit carrier board reference design?
I can’t personally suggest anything based on that design, although NVIDIA might. One thing I will suggest though is to take a good oscilloscope and compare what you see at the points where the design is the same as the reference board, and look at that signal on both the reference board and your board for comparison. Find the first location where the signal/behavior diverges between the two designs.
It will continuously execute the ether_set_rx_mode function and the ether_start_xmit function to retry. At the same time, I found that under normal circumstances, it will print out 5 sets of mc addr values. When it is abnormal, it can only print up to 4 sets of mc addr values.
