IMX274 no /dev/video0 or nvargus source on TX2

I’ve been trying to bring up an IMX274 on a custom board. Currently I have based my kernel and dts modifications off the Nvidia Sensor guide and the Leopard Imaging LI-TX1-CB patches. Skipping regulator and eeprom check in imx274.c driver and removing tegra186-quill-camera-modules and tegra186-quill-camera-plugin-manager (replaced with tegra186-quill-camera-imx274-a00 with appropriate modifications to ports etc). I have done other auxilary things like disable HDMI (we do not have HDMI and it won’t boot if I don’t disable it), and changed usb2-2 and vbus-2-supply to &battery_reg.

The current process is to build is:
make O=$TEGRA_KERNEL_OUT tegra_defconfig
with the same toolchain LI have used, I have been working with Jetpack 4.2.2 (L4T 32.2), I have briefly tried just flashing Jetpack 4.4, however it always gets stuck at the end… that can be a later problem…

I am able to probe the I2C bus between the TX2-mux and between mux-IMX274 and seems to be signaling fine during the boot sequence (no activity after that).

After using the custom Image, the wifi does not work anymore. The modules and Image are both have matching versions (4.9.140-tegra), so i would think they should be loading correctly? However, I think this could be an indication to why the camera is not working? But I’m not sure why this is the case.

On the occasion, the TX2 will refuse to boot (crashing at during tegra camera module initialisation, iso manager also fails to initialize with no clock). Reflasting the dtb ususally resolves this (…for some reason).

I’ve uploaded my dmesg output for good measure, I can provide additional information as appropriate; tia.

dmesg.txt (51.4 KB)

Didn’t find any message about imx274 in the dmesg? The dtb may not correct.
Did you get the camera board from Leopard?

We have a board from leopard, but I am currently trying to bring up an inhouse one. dmesg between our board and the LI board are pretty much the same except for the lack of camera probing. I have tried spamming status = “okay”; everywhere to no avail. I hhave also used i2cdetect to make sure that the the camera is connected and I get a response from 0x24 (PCA9570) and 0x54 (no idea) and from what I see from other device trees, the camera is reg 0x1a.

tegra186-quill-p3310-1000-c03-00-base.dts.txt (332.6 KB)

Dump the dtb at run time to check the context is correct.

sudo dtc -I fs -O dts -o extracted_proc.dts /proc/device-tree

Check the extracted_proc.dts with your source code.

Diff between the two is garbage because the entries are out of order relative to each other. However it seems the content is the same when looking at the vi, nvcsi, imx274 and tegra-camera-platform.

Again the kernel changes are pretty minor, however I’m thinking its the way I compile them for some reason that may be off?

extracted_proc.dts.txt (360.6 KB)

What’s your uname -a shows
Looks like imx274 build as module have a try to inmod

uname -a
Linux tx2-0 4.9.140-tegra #1 SMP PREEMPT [date/time] aarch64 aarch64 aarch64 GNU/Linux

Last I remember, the modules and kernel were both 4.9.140-tegra. I was under the impression that the IMX274 driver was in the kernel (no need for modules), given that the instructions for using the LI-TX1-CB is to just reflash dtb and copy paste new Image.

I will reset the envronment again tomorrow, the TX2 wifi isn’t working at the moment, so it is hard to move files around (No USB-A or Ethernet on the board I am using).

Hi frenzi,

Does the IMX274 camera have the similar issues on LI-TX1-CB board? You can contact to get the latest driver (should be R32.2.1) if needed.

The IMX274 was fine on the LI-TX1-CB last I checked (I can test this again tomorrow morning, I’m in AEST). I have been basing my modifications off the R32.2.1 patches that I have recieved from you before (my email is not too dissimilar to my name here).

Points of difference is that instead of using #if 0 for the preprocessor to remove the regulator checks, I have the driver check for null values and remove those values in the device tree. I also only have one camera at the moment that I want to get working, so I do not add the other two cameras into the tree (which you can see from the dts I have provided, I can forward the original dtsi(s) if you like).

Hi frenzi,

Our carrier board LI-TX1-CB includes an I2C switch (TCA9546APWR), and the I2C address of this chip is 0x70. If your carrier board doesn’t have this chip, you may need to remove it from the device tree.

Thank you Simon and Shane for helping me out. As I suspect, it must be some way in which I am compiling the kernel incorrectly.

If I used a device tree that I have compiled myself and the the kernel from the LI-TX1-CB, it looks for the camera correctly and I can capture an image.

There is a minor concern in that I cannot manipulate the IR switcher, however that can be added to the tech debt (i.e. debug that later, probably stilll a tree issue). The main thing is images are being captured which is great.

Hi frenzi,

Good to know you can capture the images. Please refer to the instruction in our driver guide for how to re-compile the kernel code (make sure use the same Tool chain).
Our current driver supports the IR cut switch function, so please also refer to our source code to debug it. We normally need to modify both kernel and device tree to add this function.

One thing that is of concen, which I guess will require a separate topic and I’m not sure if it is related to the camera, is that after a while the TX2 gets stuck in a boot loop from the kernel crashing.
The calltrace is similar to Jetson TX2 bootup failure after reach 142F / 61C , and can only be resolved by reflashing. I’m not sure what is happening other than some memory corruption or something as it doesn’t seem to be determinsitic to me as to when it happens.

Hi frenzi,
If you didn’t see the same issue on LI-TX1-CB + IMX274 kit, the issue is most likely not caused by the camera.