JetPack 3.2.1 problem with PCI mux


I have a problem with a new JetPack 3.2.1 (L4T 28.2.1 for Jetson TX2/TX2i ) and a TX2 SoM
I can burn a SoM, I can update the DTP file - it’s all good the same as I had with JetPack 2.3.
But there is one problem - after burn process I can only see 1 Ethernet device.
With my previous JetPack 2.3 I could achieve the same while I had to change the ODMDATA=0x1090000 to ODMDATA=0x0090000 and reburn.

At this JetPack I didn’t changed this value and it’s at default value (ODMDATA=0x1090000)
Interesting thing that if I’m changing the SoM to TX2i and burning it from the same sources I do get to see 2 Ethernet devices(eth0 and eth1).
The difference in 2 burning processes is that tx2 I’m burnig with
#./ -r jetson-tx2 mmcblk0p1
And the second I’m burning with command:
#./ -r jetson-tx2i mmcblk0p1

BTW I tried to pass -o flag to flash script - it didn’t worked at all, the default value was used.

Does anybody already tried the new Jetpack and can verify that this part worked on his side?
Thanks in advance

The dev kit carrier has only one ethernet port, so it sounds like you are using some alternate carrier board, and each carrier has its own device tree. What is the exact hardware you are using with the TX2 and TX2i?

Hi linuxdev,

Thanks for reply.

I’m using our custom board and I just switch the SoM.

The thing is, did you tried the latest JetPack and in case you did, maybe you came across with the same behavior?


Normally I use command line and only use JetPack for extra packages (I have an old tiny laptop with dual atom using Ubuntu, but my host I really work on is Fedora). What you need to know though is that each device being changed/added/removed from the carrier implies a device tree change is required. The original device tree won’t know about the “extra” network device. Regardless, JetPack is just a front end to command line anyway and the end result of command line flash should be no different than having JetPack run command line for you.

You mentioned PCI…is this new device on the PCI bus? Then this would require a kernel driver unless the driver is already there (which is quite possible if you used a popular chipset). On the other hand, if it uses a power rail from the Jetson, then the device tree would need to change for the power rail. If there is some need for the device at some particular stage of boot, then this too might require device tree changes (or even U-Boot changes). Some PCIe devices (namely FPGAs) might be require a delay before booting.

I can’t help much with custom boards, but whoever does help will need to know the specific details of how the device is connected, what driver it would use (or what chipset it is), at which point you need it in boot (e.g., if it can wait till the system is up versus if it is needed as a boot device), and how your carrier board differs (even slight differences are important). Any changes to kernel or device tree are important.

As similar as a TX2i and TX2 are their device tree will differ, so I don’t know if this is why the TX2i worked but the TX2 did not. Maybe the timing of some setup or default kernel config is the reason it worked.

Just something to consider…a full sized PC has a BIOS, and the BIOS acts to announce hardware and acts to set up basic operation (such as clocks and power rails) before the bootloader ever runs. An embedded system has none of that, and so you have to more or less manually account for this. The device tree (along with a more customized bootloader) is normally the method of doing this.