The difference of Jetson TX1's compability between J90 and J100 to connect with camera Hitachi DI-SC233?

Hi guys,
I and my dude is trying to setup Jetson TX1 with two types of carrier board are J90-Lc and J100 which mainly aim to able to connect to camera Hitachi.
We’ve already connected successfully TX1 with camera Hitachi with J100 board.
And then, we kept all the config, setups and tried to connect camera again but with J90 board. All we got is the disappointment.The camera didn’t display correctly as we expected. We still got images but with the noisy, seemly its type isn’t correct. we were lacking some other configs or drivers, weren’t we?
Any suggestions for me to handle with this case?
Thanks so much. !

It is highly likely the different carrier board requires a different BSP (mostly device tree). Do the two boards come with different board support packages? Specifically, does each come with a different device tree?

Hi Mr/Mrs,
Thanks for your response.
Im newbie in this field really. I haven’t change the device tree and packages set on Jetson TX1 for both boards yet.
I just went to menuconfig and navigated to Device Drivers -> USB Support -> USB Serial Converter Support and choose USB 3.0 for camera Hitachi (
I saved all the changes and rebuild the kernel.
After then, I restarted Jetson TX1 attach with carrier board (in order: the first try, I attached TX1 with J100, and the second try I attached TX1 with J90-LC). Both case, I all got the /dev/video0 source.
But when i tried to test it with gstreamer-1.0, I only got correct images with the first try (with J100).
About J100 and J90-LC. You can take a look at
for more detail about its components.
Looking forwards any suggestions from you guy.
Thanks so much!

I’ve never actually had one of the alternate carrier boards to work with, so it is hard to be specific. Here is some general information.

The Linux kernel has drivers for hardware. This implies that for the case of hardware which can be set up in multiple ways the driver must still set up specifically for that driver or software which uses the hardware. If you were writing a C++ program, you might consider the device tree something like a templatized constructor. Set it up wrong and the hardware driver will try to use the hardware in the wrong way (unlike C++ which can detect an invalid signature hardware drivers will blindly do what they are told). One of the most typical setups is to route a given processor pin to the function required, e.g., some pins might have the ability to be an interrupt for some special purose, and in other cases that same pin might be a GPIO for custom software.

The device tree takes custom setups for specific hardware and gets it out of the Linux kernel. It is best if the kernel does not include every combination and permutation of setting up individual devices…it would be an insanely large and complex kernel. You will find that a device tree gives names and values to things which are customizable in hardware while drivers and protocols can remain generic.

The hardware surrounding the Tegra SoC often needs setup. So too the SoC itself needs different setup depending on that hardware around it. A typical real world example is that often wireless hardware has different legal settings depending on what country in the world you are in…this is the case of firmware plus device tree setup perhaps being different depending on where you are (this is a case of custom setup on the host side plus custom setup within the device creating what is essentially a final function signature). Ignoring where you are, each Board Support Package (BSP) by definition is different…some boards have USB3 connectors, others only have USB2 connectors; some have a camera connector, some don’t…when both have a camera connector some might implement features that the other boards do not implement. The driver is probably the same, but the device tree to make those connectors visible will differ even if it is nothing more than routing to different pins on the Jetson module.

You need a different device tree for each board. Some of that device tree might be set up in U-Boot for the use of U-Boot, but other parts U-Boot sets up merely for handing off to the Linux kernel. The DTB file is how the boot loader installs that device tree, and this occurs prior to the Linux kernel taking over. The difference in installing the DTB is that on some releases this is just a file the extlinux.conf boot load setup file names. In other cases the DTB file has to be flashed to a hidden partition.

In the case of L4T R28.1 the DTB is intended to run from a hidden partition, and there is a command to flash just the DTB file. In other cases this is the FDT entry in extlinux.conf. Even in R28.1 there may be an effect from adding an FDT entry into extlinux.conf, but this is not supported (success using this may just be a case of good luck if using L4T R28.1).

For a custom carrier board you will need to get the procedure for setting up and flashing that DTB file (or file copy in some cases) from the manufacturer of the board…this is custom to each board. Hardware may not work (or may cause a crash) until the device tree is set up specifically for that carrier board.

Ya. I see. Big thanks for really useful infos you give.
Linux is beautiful and magic as well. Im trying to get into it.
Do you have some detail refs links or instructions for this subject, this issue like create device tree for J90 connecting to camera through USB3.0 port or CSI2 port (J100 already connected successfully with both ports)?
I don’t have that much experiences on this field really.
By the way, do you have some books or tut to get familiar with linux as fast as possible?
Thanks so much for your enthusiasm. !


The information on what to use for the specific board (such as J90) will come from the manufacturer of the board. Depending on how the board is arranged the manufacturer might also offer information on how to update the device tree (the manufacturer will provide a file to download).

The Jetson modules, when using the developer board, are tied to flash over the micro-B USB port (the port is actually “On The Go” or OTG port…which can switch function depending on whether the cable used is type-A or type-B, and if in recovery mode or not). I do not know how USB is arranged on the J90 or J100…I imagine you would either have to flash it from the dev carrier board, or else those boards may provide a type-B USB connector (a micro OTG connector qualifies since it can use a type-B cable). Flash might or might not be the same with the alternate carrier board…that’s something else I’ve never looked at since I don’t have one of those carrier boards.

If you are talking about flash and device tree information on the dev carrier board, there is information in the “Documentation” download for each L4T release. There were changes in how device tree is flashed or used in the R28.1 release (versus older releases). Here is a useful URL on that topic of flashing once you have your dtb file when using R28.1:

Note that a TX1 and TX2 can both use R28.1, and that the URL above notes specifics when there is a difference between the two…but generally speaking there is very little difference between those two boards other than a name or two.