Intel RealSense D457 GMSL camera doesn't work on JetPack 6.0

We want to porting Intel RealSense D457 GMSL camera to JetPack 6.0 on AGX Orin DevKit.
Intel had provide the D457 mipi driver on GitHub, and it could support to JetPack 6.0 on AGX Orin.

  • I flash the JetPack 6.0 image to AGX Orin DevKit by SDK manager.

  • Accorind to document, I could apply D457 patches and build the kernel image, .dtbo and D457 driver for JetPack 6.0.
    I copy them to the right places on AGX Orin.

  • I enable d4xx overlay with Jetson-IO tool.

But it will get the in bootup log. (see agx-orin-dev-kit_UntrustedFile_log_20241218.txt)
agx-orin-dev-kit_UntrustedFile_log_20241218.txt (49.5 KB)

OpenAndReadUntrustedFileToBuffer: Failed to open \home\nvidia\yuan\dtb\agx-orin-
dev-kit-mp440n4-gmsl-intel-d457x1\boot_dtb\tegra234-p3737-0000+p3701-0000-nv.dtb
: Not Found

Could we copy .dtbo, .ko and jetson-io.py enable it on AGX Orin target only, and it don’t re-flash all system image to AGX Orin?

Hi,

For the camera basic functionality first needs to check the device and driver configuration.
You can reference to below program guide for the detailed information of device tree and driver implementation.
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/CameraDevelopment/SensorSoftwareDriverProgramming.html?highlight=programing#sensor-software-driver-programming

Please refer to Applications Using V4L2 IOCTL Directly by using V4L2 IOCTL to verify basic camera functionality.
https://docs.nvidia.com/jetson/archives/r36.3/DeveloperGuide/SD/CameraDevelopment/SensorSoftwareDriverProgramming.html?highlight=programing#to-run-a-v4l2-ctl-test

Once confirm the configure and still failed below link help to get log and some information and some tips for debug.
https://elinux.org/Jetson/l4t/Camera_BringUp#Steps_to_enable_more_debug_messages

Thanks!

I merge the Intel D457 mipi driver patch to JetPack6.0 source, and re-build, and re-flash image to AGX Orin DevKit.
The D457 driver ko had load, but ds5_probe init fail in max9296_write_reg i2c write failed. (see agx-orin-dev-kit_intel-d457-dmsg-20241220_03.txt)

max9296 2-0048: max9296_write_reg:i2c write failed, 0x10 = 1

agx-orin-dev-kit_intel-d457-dmsg-20241220_03.txt (71.5 KB)

Could you give me more comment?

Hello @sammyb7qw7,

This might be due to Intel using a different version of JetPack 6.0 for their D457 MIPI driver development, likely the JetPack 6.0 DP (Developer Preview) version, which is not the same as the JetPack 6.0 version installed by SDK Manager. One way to verify this is by running the following command on the Jetson (with the JP 6.0 configuration installed by SDK Manager):

echo $(uname -r)

Compare the result with the version generated when using Intel’s patch. You’ll probably see a difference, for example, 5.15.136-tegra vs 5.15.122-tegra.

Please check this and let me know if you have any questions.

Jose Morera
Embedded Software Engineer at RidgeRun
Contact us: support@ridgerun.com
Developers wiki: https://developer.ridgerun.com
Website: www.ridgerun.com

Hi, @jose.morera:

Thanks for your reply information.

  1. There are master branch and v1.0.1.25 tag on Intel D457 realsense mipi platform driver GitHub for Jetpack6.

Intel Realsense mipi platform driver GitHub - master branch
https://github.com/IntelRealSense/realsense_mipi_platform_driver/blob/master/README.md
The master branch is D457 driver patch for Jetpack 6.0 DP(L4T 36.2, Kernel 5.15.122).

Intel Realsense mipi platform driver GitHub - v1.0.1.25 tag
https://github.com/IntelRealSense/realsense_mipi_platform_driver/blob/r/1.0.1.25/README_JP6.md
The v1.0.1.25 tag is D457 driver patch for Jetpack 6.0(L4T 36.3, Kernel 5.15.136).

  1. I use the Intel Realsense mipi platform driver GitHub - v1.0.1.25 tag, and merge this patch to Jetpack 6.0 (L4T 36.3, Kernel 5.15.136).
    It could bootup and load d4xx.ko, but I get the max9296_write_link() initial fail at max9296_write_reg in kernel dmesg log. (see log agx-orin-dev-kit_intel-d457-dmsg-20241220_03.txt )
#define MAX9296_CTRL0_ADDR 0x10

max9296_write_link () {
  .
  max9296_write_reg(dev, MAX9296_CTRL0_ADDR, 0x01);
  max9296_write_reg(dev, MAX9296_CTRL0_ADDR, 0x21);
  .
}

static int max9296_write_reg(struct device *dev, u16 addr, u8 val)
{
	struct max9296 *priv;
	int err;

	priv = dev_get_drvdata(dev);

	err = regmap_write(priv->regmap, addr, val);
	if (err)
		dev_err(dev, "%s:i2c write failed, 0x%x = %x\n", __func__, addr, val);

	/* delay before next i2c command as required for SERDES link */
	usleep_range(100, 110);

	return err;
}

It is remap_write fail issue in Jetpack6, but the remap_write is working in Jetpack5.
I also see others get same issue on IntelRealSense GitHub Issue:

[ IntelRealSense GitHub Issue ] max9295 12-0044: max9295_write_reg:i2c write failed, 0x10 = 21
https://github.com/IntelRealSense/realsense_mipi_platform_driver/issues/246

Hi, @carolyuu :
Could you help to solve the remap_write fail issue in Jetpack6?

I would suspect the problem could be power/down/rest pin didn’t in correct state.
The imx219 use the same API didn’t hear the problem.

Thanks

Hi @ShaneCCC :

I try to I2C read/write in ds5_probe().
By regmap_raw_read API, ds5_read() fail.
By i2c_transfer API, I2C read/write are success.

So I think power/down/reset pin status are correct.
Are there any regmap parameter settings that I should to check it in JP6?

[ /nvidia-oot/drivers/media/i2c/d4xx.c ]

int i2c_write_reg_read_bytes(struct i2c_client *client, unsigned int devaddr, unsigned int reg_addr, unsigned char * rxbuf, unsigned int rxcount);
int i2c_write_bytes(struct i2c_client *client, unsigned int devaddr,  unsigned char * txbuf, unsigned int txcount);

static const struct regmap_config ds5_regmap_config = {
	.reg_bits = 16,
	.val_bits = 8,
	.reg_format_endian = REGMAP_ENDIAN_NATIVE,
	.val_format_endian = REGMAP_ENDIAN_NATIVE,
};


static int ds5_probe(struct i2c_client *c, const struct i2c_device_id *id)
{

	state->regmap = devm_regmap_init_i2c(c, &ds5_regmap_config);
	if (IS_ERR(state->regmap)) {
		ret = PTR_ERR(state->regmap);
		dev_err(&c->dev, "regmap init failed: %d\n", ret);
		goto e_regulator;
	}

	i2c_write_reg_read_bytes(c, 0x48, 0x1D, rxbuf, 1);	/* I2C read OK */
	
	txbuf[0]=0x10;	 // reg=MAX9296_CTRL0_ADDR
	txbuf[1]=0x01;
	i2c_write_bytes(c, 0x48, txbuf, 2);	/* MAX9296_CTRL0_ADDR(0x10)=0x01, I2C write OK */
	
	txbuf[0]=0x10;  // reg=MAX9296_CTRL0_ADDR
	txbuf[1]=0x21;
	i2c_write_bytes(c, 0x48, txbuf, 2);	/* MAX9296_CTRL0_ADDR(0x10)=0x21, I2C write OK  */

	ds5_read(state, 0x5020, &rec_state); /*  regmap_raw_read 0x5020 fail */


}  // end of ds5_probe


int i2c_write_reg_read_bytes(struct i2c_client *client, unsigned int devaddr, unsigned int reg_addr, unsigned char * rxbuf, unsigned int rxcount)
{
	int ret=0;
	unsigned char buf[4]={0};
	struct i2c_msg msg[2] = {0};
	
	buf[0]=reg_addr & 0xFF;
	msg[0].addr = devaddr;
	msg[0].flags = 0;
	msg[0].len = 1;
	msg[0].buf = buf;

	msg[1].addr = devaddr;
	msg[1].flags = I2C_M_RD;
	msg[1].len = rxcount;
	msg[1].buf = rxbuf;
	
	ret = i2c_transfer(client->adapter, &msg[0], 2);
	if (ret < 0)
		goto err;

	return 0;

 err:
	dev_err(&client->dev, "%s(), Failed  I2C writeing register and reading data, ret = %d!\n", __func__, ret);
	return ret;
}


int i2c_write_bytes(struct i2c_client *client, unsigned int devaddr,  unsigned char * txbuf, unsigned int txcount)
{
	int ret=0;
	struct i2c_msg msg = {
		.addr = devaddr,
		.flags = 0,
		.len = txcount,
		.buf = txbuf,
	};
	
	ret = i2c_transfer(client->adapter, &msg, 1);
	if (ret < 0) {
		dev_err(&client->dev, "%s(devaddr=0x%02X, txbuf[0]=0x%02X, txcount=%d), Failed I2C writing register, ret = %d!\n",__func__, devaddr,txbuf[0], txcount, ret);
		return ret;
	}
	return 0;
}


static int ds5_read(struct ds5 *state, u16 reg, u16 *val)
{
	int ret = regmap_raw_read(state->regmap, reg, val, 2);

	if (ret < 0)
		dev_err(&state->client->dev, "%s(): i2c read failed %d, 0x%04x\n",
				__func__, ret, reg);
	else {
		if (state->dfu_dev.dfu_state_flag == DS5_DFU_IDLE)
			dev_dbg(&state->client->dev, "%s(): i2c read 0x%04x: 0x%x\n",
					__func__, reg, *val);
	}

	return ret;
}

Hi, @ShaneCCC :

We could enable the Boost the clock for debug:

echo 1 > /sys/kernel/debug/bpmp/debug/clk/vi/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/isp/mrq_rate_locked
echo 1 > /sys/kernel/debug/bpmp/debug/clk/nvcsi/mrq_rate_locked
cat /sys/kernel/debug/bpmp/debug/clk/vi/max_rate |tee /sys/kernel/debug/bpmp/debug/clk/vi/rate
cat /sys/kernel/debug/bpmp/debug/clk/isp/max_rate | tee  /sys/kernel/debug/bpmp/debug/clk/isp/rate
cat /sys/kernel/debug/bpmp/debug/clk/nvcsi/max_rate | tee /sys/kernel/debug/bpmp/debug/clk/nvcsi/rate

and enable trace for more information:

echo 1 > /sys/kernel/debug/tracing/tracing_on
echo 30720 > /sys/kernel/debug/tracing/buffer_size_kb
echo 1 > /sys/kernel/debug/tracing/events/tegra_rtcpu/enable
echo 1 > /sys/kernel/debug/tracing/events/freertos/enable
echo 2 > /sys/kernel/debug/camrtc/log-level
echo 1 > /sys/kernel/debug/tracing/events/camera_common/enable
echo > /sys/kernel/debug/tracing/trace
cat /sys/kernel/debug/tracing/trace

But I got the “No such files or directory” error in L4T R36.3.0:

# echo 2 > /sys/kernel/debug/camrtc/log-level
bash: /sys/kernel/debug/camrtc/log-level: No such files or directory

How to get more debug trace message in L4T R36.3.0?

Need below command before the commands to enable the trace log in JP6.

modprobe rtcpu_debug

We set GPIO PH.03 to HIGH in gpio@2200000 device tree.
We see GPIO PH.03 status is HIGH after system bootup in /sys/kernel/debug/gpio.

root@agx-orin-devkit-02:/home/nvidia # cat /sys/kernel/debug/gpio
gpiochip1: GPIOs 316-347, parent: platform/c2f0000.gpio, tegra234-gpio-aon:
 gpio-391 (PH.00               )
 gpio-392 (PH.01               )
 gpio-393 (PH.02               )
 gpio-394 (PH.03               |camera-control-outpu) out hi
 gpio-395 (PH.04               |regulator-vdd-3v3-pc) out lo
 gpio-396 (PH.05               )
 gpio-397 (PH.06               |camera-control-outpu) out hi
 gpio-398 (PH.07               )

We don’t control GPIO PH.03 in Intel D457 driver, but oscilloscope see the GPIO PH.03 will pull down to LOW after regmap_read().
How to find out why GPIO PH.03 is pulled LOW after regmap_read()?

Could you confirm by PH.06 if the same behavior.

Thanks

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.