Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Arducam Multiplexer (B012001) + IMX708 not working with latest Raspberry Pi OS on Raspberry Pi 5 #190

Closed
Dion4cen opened this issue Oct 10, 2024 · 12 comments

Comments

@Dion4cen
Copy link

I'm experiencing an issue with the Arducam Multiplexer (B012001) when used in combination with the IMX708 camera on the latest Raspberry Pi OS image, specifically on a Raspberry Pi 5.

Environment:

  • Hardware: Raspberry Pi 5
  • Camera: IMX708 (Raspberry Pi CM3)
  • Multiplexer: Arducam B012001
  • Latest OS: Raspberry Pi OS (64-bit) with kernel version 6.6.47(not tested on 6.6.51 for now)

Issue:
When using the December 2023 Raspberry Pi OS image (https://downloads.raspberrypi.com/raspios_arm64/images/raspios_arm64-2023-12-06/), the B012001 multiplexer works fine with the IMX708 camera.

However, when I flash the latest Raspberry Pi OS image (https://downloads.raspberrypi.com/raspios_arm64/images/raspios_arm64-2024-07-04/), I encounter the following problem:

  • The camera is detected
  • But libcamera commands time out
    image

I'm not sure what's causing this issue. Has there been any recent changes in kernel 6.6.47 that might affect the compatibility of the Arducam Multiplexer with the latest OS image?

Steps to reproduce:

  1. Flash the latest Raspberry Pi OS image (kernel 6.6.47) on a Raspberry Pi 5
  2. Connect the IMX708 camera to the Arducam B012001 multiplexer
  3. Attempt to use libcamera commands

Expected behavior:
The camera should work as it did with the December 2023 image.

Actual behavior:
libcamera commands time out.

Any assistance or insights would be greatly appreciated. Thank you!

@naushir
Copy link
Collaborator

naushir commented Oct 10, 2024

Can you share the output of dmesg when the timeout occurs please?

@6by9
Copy link
Collaborator

6by9 commented Oct 10, 2024

I think last time I looked at this, CFE was failing to get the link frequency from the source device as it couldn't follow the full path through the mux.

I think I was thinking that i2c-mux needed to forward on the controls of the currently active input, as devices shouldn't really be walking the graph.

@6by9
Copy link
Collaborator

6by9 commented Oct 10, 2024

Thanks to @kbingham raspberrypi/linux#6410 should fix video-mux so that CFE can get the link frequency for any of the sources of the video-mux.

I haven't got an imx708 to hand, but an OV9281 and OV7251 connected to two inputs on an Arducam 2 port mux board do give me the correct link frequency/data rate log messages in the kernel log depending on which one is selected, and both work OK.

If you want to test, then using sudo rpi-update pulls/6410 will get the test kernel when CI completes in about 30mins time. Normal warnings over backing up or otherwise not using rpi-update on a critical system.

@Dion4cen
Copy link
Author

If you want to test, then using sudo rpi-update pulls/6410 will get the test kernel when CI completes in about 30mins time. Normal warnings over backing up or otherwise not using rpi-update on a critical system.

Hi @6by9
Thank you very much for your time and assistance. I plan to test it with the IMX708 camera module today and will share my feedback here.

@Dion4cen
Copy link
Author

Unfortunately, I haven't had any success yet. Let me describe my testing process in detail:

I ran the command sudo rpi-update pulls/6410 and waited several minutes for it to complete. After rebooting my Pi to apply the changes, I executed uname -a. The output (which I'll provide below) suggests that I successfully updated to the specific kernel version you mentioned.
image

I then ran libcamera-still --list. The output (also provided below) shows that the IMX708 camera module is correctly detected by the Raspberry Pi.
image

To monitor system logs in real-time, I opened another terminal and ran dmesg -w.

Finally, I executed libcamera-still -t 0, but unfortunately, the same error persisted.
image

I've recorded all these steps in a video, which I've attached below for reference. Please let me know if you need any additional information or if you have any questions about my testing process. I'm open to any suggestions for further troubleshooting.
https://drive.google.com/file/d/1Tk5hlQCp_jNR-P_Uuo0WBC-1nAL5Wbua/view?usp=sharing

@6by9
Copy link
Collaborator

6by9 commented Oct 11, 2024

Verify that your camera module works without the camera mux board.

I assume you've configured the mux with dtoverlay=camera-mux-4port,cam0-imx708, but you don't say as much.

@Dion4cen
Copy link
Author

Verify that your camera module works without the camera mux board.

I can make sure that this camera module 3 can work without the camera mux board.
image
image

I assume you've configured the mux with dtoverlay=camera-mux-4port,cam0-imx708, but you don't say as much.
I connected the camera mux board to the camera 0 port, so I configured it with dtoverlay=camera-mux-4port,cam0-imx708,cam0.

@6by9
Copy link
Collaborator

6by9 commented Oct 16, 2024

Hmm, replicated.
Both IMX708 and 477 fail, but OV7251 and IMX327 are fine. I've tried OV7251 in both port A and C, so the CSI muxing is working.
(BTW pisp imx290.json is missing from meson.build, so doesn't immediately work)

rpi-update a31776f (Feb 2024 6.6.18-v8+) also fails.

rpi-update ceecdc2 (15th Dec 2023 6.1.68-v8+) IMX477 fails I2C writes. IMX708 still fails with a timeout.

rpi-update 5fb0bf3 (23rd Nov 2023 and in stable rpi-firmware branch, 6.1.63-v8+) doesn't appear to support the cam0 override (added by raspberrypi/linux@c5005ab on Mar 5th 2024), and gives a big WARN on probe

[   11.144835] WARNING: CPU: 1 PID: 774 at drivers/media/mc/mc-entity.c:1024 media_create_pad_link+0x17c/0x1c8 [mc]
...
[   11.144971] Call trace:
[   11.144972]  media_create_pad_link+0x17c/0x1c8 [mc]
[   11.144981]  cfe_async_complete+0x488/0x5b8 [rp1_cfe]
[   11.144986]  v4l2_async_nf_try_complete.part.7+0x5c/0x80 [v4l2_async]
[   11.144993]  v4l2_async_register_subdev+0x108/0x1c8 [v4l2_async]
[   11.144999]  v4l2_async_register_subdev_sensor+0x154/0x1e0 [v4l2_fwnode]
[   11.145005]  imx708_probe+0x6b8/0x7e0 [imx708]
[   11.145014]  i2c_device_probe+0x194/0x2e8
...
[   11.478489] rp1-cfe 1f00128000.csi: Unable to link node pads.
[   11.478691] imx708 15-001a: failed to register sensor sub-device: -22
[   11.478707] cam-dummy-reg: Underflow of regulator enable count
[   11.478710] Failed to disable vddl: -EINVAL
[   11.478714] clk_24mhz already disabled
...
[   11.478951] clk_24mhz already unprepared

So I don't see you can be using the December 2023 with the mux connected to CAM/DISP0 on a Pi5.

@6by9
Copy link
Collaborator

6by9 commented Oct 16, 2024

Transferring the same setup to a Pi4 and I'm seeing occasional significant image corruption.

I wonder if the signal integrity is slightly marginal once it's gone through the CSI2 muxes, particularly as they have 2 2:1 mux chips and are only disabling the output on one set. That leaves a stub of unterminated PCB track, which will introduce reflections. Pi5/RP1 is a totally different CSI2 receiver to Pi0-4, so it may be that it just won't work with that slightly lower signal integrity.

@ppk052
Copy link

ppk052 commented Oct 17, 2024

then why imx708 does not work in raspberry pi 4b with b012001?

@6by9
Copy link
Collaborator

6by9 commented Oct 17, 2024

then why imx708 does not work in raspberry pi 4b with b012001?

I hadn't noticed that the duplicate naushir closed was on Pi4. It says you're using a 6.1.21-v8+ kernel from Apr 2023 which is ancient. If you want support, then you need to be using a current install.

The latest kernel works reasonably with IMX708 on my Pi4 via the mux, but with occasional glitches (once every 4-5secs).
IMX708 runs the data link at 450MHz (900Mbit/s). OV5647 runs it at 218.5MHz (437Mbit/s). Any signal integrity issues get worse with increasing frequency.

The mux board is a third party product, so is not something that is under the control of Raspberry Pi.
Seeing as IMX708 works fine when connected directly to the Pi I see little to say that it is an issue with either IMX708 or Pi.
I don't believe this is a regression either, but if you can provide a kernel install that works reliably with it then I will investigate further.

Please also note that the Arducam boards connect i2c-1 with the camera's I2C bus (typically i2c-10 on a Pi4). Trying to use i2c-1 at the same time will cause issues at the I2C level.

@naushir
Copy link
Collaborator

naushir commented Oct 18, 2024

Closing this now - you are best to get support from Arducam on their hardware.

@naushir naushir closed this as completed Oct 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants