Using Framos FSM:GO with GMSL Serializer/Deserializer on Toradex i.MX8

Hello,

we are currently evaluating the use of a Framos camera for a new project.

We have seen that the Framos FSM:GO series camera modules are supported out of the box on Toradex i.MX8 platforms, both from a hardware and software perspective, when using the FPA-A/P24-V0X adapter board to connect the camera to the MIPI CSI interface of Toradex carrier boards.

Given the requirement to place the camera module at a remote distance from the SoM, we would like to understand whether it is possible to use Framos GMSL serializer and deserializer modules while maintaining software compatibility with the Toradex ecosystem.

Specifically, we are considering a configuration such as the following:

FSM:GO IMX678 (PixelMate) → Framos FFA-GMSL-Ser-V2 → FAKRA coaxial cable → Framos FFA-GMSL-Des-V2 → FPA-A/P24-V0X → FMA-CBL-FFC24-0.2 m → Toradex carrier board

The key question is whether, by introducing the Framos GMSL serializer and deserializer between the camera module and the MIPI CSI interface, the existing Toradex BSP and camera software support can be preserved, or whether additional driver or device tree modifications would be required.

Best regards,

Fra

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.


I’d be glad to help you evaluate the GMSL serializer/deserializer configuration! To provide you with the most accurate guidance, could you let me know which hardware platform and OS version you’re planning to use?

Please run the tdx-info command on your system to get the complete hardware and software information. You can find more details about this command at https://developer.toradex.com/software/development-resources/tdx-info/.

This will help me understand your specific setup and provide targeted guidance regarding:

  • Your specific SoM (Verdin iMX8M Plus, Apalis iMX8, etc.)
  • Your carrier board configuration
  • The OS version you’re running (Torizon OS, Yocto BSP, specific version numbers)

The compatibility and software requirements can vary significantly depending on your exact platform configuration, so confirming these details first will ensure I can give you the most relevant information about GMSL integration with the Toradex ecosystem.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hello,

We do not have the hardware yet, but the planned setup is as follows:

SoM: Verdin i.MX8M Plus Quad 4GB IT

Carrier Board: Mallow or Dahlia

OS: Toradex Linux BSP 7.0.0 or later

The intended camera configuration is:

FSM:GO IMX678 (PixelMate) → Framos FFA-GMSL-Ser-V2 → FAKRA coaxial cable → Framos FFA-GMSL-Des-V2 → FPA-A/P24-V0X → FMA-CBL-FFC24-0.2 m → Toradex carrier board

Additionally, we are considering the Verdin i.MX8 Plus 1G (PN: 0065), which according to thedocumentation is not officially listed as supported. Could this module work with the same setup?

Fra

Based on the documentation, I can provide you with specific information about your planned configuration.

FSM:GO Camera Support on Verdin iMX8M Plus

The FSM:GO IMX678 camera is supported on the Verdin iMX8M Plus with BSP 7.0.0 and later versions(1). The following Verdin iMX8M Plus versions are officially supported with FSM:GO cameras(1):

  • 0070 - Verdin iMX8M Plus Quad 8GB WB IT
  • 0058 - Verdin iMX8M Plus Quad 4GB WB IT
  • 0063 - Verdin iMX8M Plus Quad 4GB IT
  • 0064 - Verdin iMX8M Plus Quad 2GB WB IT

Your planned Verdin iMX8M Plus Quad 4GB IT is included in this supported list(1).

Carrier Board Compatibility

Both the Mallow Carrier Board and Dahlia Carrier Board support the MIPI CSI-2 interface and connect to the camera kits out-of-the-box, hardware-wise(1).

Regarding the 1GB Module (0065)

The documentation specifically notes that “The Verdin iMX8M Plus QuadLite 1GB IT (0065) is not compatible with the Framos camera”(2). This incompatibility would likely extend to your GMSL configuration as well.

GMSL Serializer/Deserializer Considerations

While the documentation covers the standard FSM:GO camera setup using the FPA-A/P24-V0X adapter board directly connected to the MIPI CSI interface(1), it doesn’t specifically address GMSL serializer/deserializer integration.

The standard supported configuration is(1):

  • FSM:GO camera → FPA-A/P24-V0X adapter → FMA-CBL-FFC24-0.2m cable → Toradex carrier board

Your proposed GMSL configuration introduces additional components in the signal path that would require evaluation for:

  1. Signal integrity - The GMSL serializer/deserializer chain needs to maintain the MIPI CSI-2 signal characteristics
  2. Timing requirements - Additional latency introduced by the GMSL components
  3. Power requirements - The serializer/deserializer modules need appropriate power supplies
  4. Device tree configuration - Potential modifications may be needed for the extended signal path

Recommendation

For your specific GMSL configuration, I’d recommend reaching out to both Framos and our technical support team to validate the complete signal chain compatibility, as this goes beyond the standard documented configuration.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

@ToradexAI

After reverting to the default configuration, I started performing initial tests. The camera is not detected / not streaming correctly.

Hardware Setup:

SoM: Verdin iMX8M Plus Quad 2GB Wi-Fi / Bluetooth IT(PN 0064, V1.1A);

Carrier Board: Dahlia Development Board;

Camera: IMX678 (FSM:GO 678);

Adapter: FPA-A/P24-V0X;

Cable: FMA-CBL-FFC24-0.2m. C

Procedure Followed: I followed the Toradex documentation for FRAMOS FSM:GO CSI modules: https://developer.toradex.com/linux-bsp/application-development/multimedia/first-steps-with-framos-fsm-go-csi-optical-sensor-modules-linux/#hardware-setup

Device tree overlays applied: fdt_overlays=verdin-imx8mp_hdmi_overlay.dtbo verdin-imx8mp_dsi-to-hdmi_overlay.dtbo verdin-imx8mp_spidev_overlay.dtbo verdin-imx8mp_imx678_overlay.dtbo

tdx-info
Bootloader: U-Boot
Kernel version: 6.6.23-7.0.0-devel-g558ba3740880
Distro name: NAME=“TDX Wayland with XWayland”
Distro version: VERSION_ID=7.0.0-devel-20260225072901-build.0
Hostname: verdin-imx8mp-08739939
HW model: Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version: 0064 V1.1A
Serial number: 08739939
Processor arch: aarch64

v4l2-ctl -d2 -D
Driver Info:
Driver name : viv_v4l2_device
Card type : VIV
Bus info : platform:viv0
Driver version : 6.6.23
Capabilities : 0x84200001
Video Capture
Streaming
Extended Pix Format
Device Capabilities
Device Caps : 0x04200001
Video Capture
Streaming
Extended Pix Format

dmesg | grep imx
[0.036503] imx mu driver is registered.
[0.036534] imx rpmsg driver is registered.
[0.049473] imx8mp-pinctrl 30330000.pinctrl: initialized IMX pinctrl driver
[0.063203] platform 32e40000.csi: Fixed dependency cycle(s) with /soc@0/bus@30800000/i2c@30a40000/imx678_mipi@1a

[9.059096] enter imx678_probe
[9.062272] enter imx678_power_on
[9.114330] enter imx678_set_exp exposure received: 1000
[9.119668] enter imx678_set_exp exposure register: 2184 integration_time_line: 67
[9.128509] imx678 2-001a: Write reg error: reg=3001, val=1, error= -6
[9.151192] imx678 2-001a: Write reg error: reg=3052, val=0, error= -6
[9.156072] imx678 2-001a: Write reg error: reg=3051, val=8, error= -6
[9.177465] imx678 2-001a: Write reg error: reg=3050, val=88, error= -6
[9.180570] imx678 2-001a: Error -6 setup default controls
[9.180584] enter imx678_power_off
[9.182586] imx678_power_off: failed to set XVS XHS to Hi-Z

From the messages, the overlay seems to be loaded, but then I2C register writes appear to fail

The I2C write errors in your dmesg output indicate communication issues between the SoM and the IMX678 camera module. Let’s troubleshoot this systematically.

Hardware Verification

First, verify your hardware connections match the documentation. The Dahlia Carrier Board supports the MIPI CSI-2 interface and connects to the camera kits out-of-the-box, hardware-wise(1).

I2C Communication Testing

The error messages show I2C register write failures with error code -6 (typically ENXIO - No such device or address). Let’s check the I2C communication:

  1. Identify the I2C bus: According to the Verdin iMX8M Plus datasheet, the camera I2C interface uses I2C3(2). On your system, this should appear as a symbolic link.

  2. Test I2C communication: Run a container with I2C tools to scan for the camera:

# docker run -it --rm -v /dev:/dev --device-cgroup-rule='c 89:* rmw' torizon/debian:${CT_TAG_DEBIAN}

(3)

  1. Scan for the camera: Inside the container, scan the I2C bus:
## ls -l /dev | grep verdin-i2c

(3)

Look for the camera I2C interface and scan it:

## i2cdetect -y <bus_number>

(3)

The IMX678 camera should appear at address 0x1a (as indicated in your dmesg: imx678 2-001a).

Common Issues and Solutions

Based on similar CSI interface issues documented in the community, here are potential causes:

Power Supply Issues

Ensure stable power supply to both the SoM and camera module. Power supply fluctuations can cause inconsistent I2C communication(4).

Cable and Connection Integrity

The flat ribbon cable used to connect the carrier board and camera adapter is fragile(1). Verify:

  • Cable connections are secure on both ends
  • Cable is not damaged or bent excessively
  • Contacts are properly aligned

Hardware Batch Variations

Some users have reported that certain SoM units may have hardware variations affecting CSI functionality(4). If I2C scanning shows the device is not detected, this could indicate a hardware-level issue.

Diagnostic Steps

  1. Check I2C bus availability:
# ls -l /dev | grep verdin-i2c

(3)

  1. Verify camera detection:
# i2cdetect -y <camera_i2c_bus>

(3)

  1. Check overlay application: Your boot log should show:
Applying Overlay: verdin-imx8mp_imx678_overlay.dtbo

(1)

Expected Behavior

When working correctly, you should see the camera device detected during I2C scanning, and the GStreamer pipeline should function:

# gst-launch-1.0 -v v4l2src device=/dev/video2 ! video/x-raw ! videoconvert ! waylandsink

(1)

If the I2C device is not detected during scanning, this indicates a hardware connectivity issue rather than a software configuration problem.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

@ToradexAI

ls /sys/bus/i2c/devices/
0-0025  0-0048  0-0050  3-001a  3-0040  3-0049  3-0050  i2c-0  i2c-2  i2c-6
0-0032  0-0049  2-001a  3-0021  3-0048  3-004f  3-0057  i2c-1  i2c-3

cat /sys/bus/i2c/devices/2-001a/name
imx678



i2cdetect -y 2
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:                         -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

All components are new and intact, including the cable (connected as indicated in the documentation)

The I2C device detection shows an interesting situation. The camera device 2-001a is detected and shows up in the device tree as imx678(1), but the i2cdetect scan on bus 2 shows no devices responding.

Analysis of the Issue

This pattern indicates that:

  1. Device Tree Overlay Applied Successfully: The presence of /sys/bus/i2c/devices/2-001a/name showing imx678 confirms the overlay is loaded correctly(2)
  2. I2C Communication Failure: The empty i2cdetect output suggests the physical I2C communication is not working(1)

When a device appears as UU in i2cdetect, it means kernel drivers are managing the device and blocking direct access(1). However, your scan shows -- which indicates no device response at all.

Hardware Connection Verification

Since you’re using the Dahlia Carrier Board, verify the camera connection to the correct MIPI-CSI connector. The Dahlia Carrier Board supports the MIPI CSI-2 interface and connects to the camera kits out-of-the-box, hardware-wise(2).

Troubleshooting Steps

  1. Check Power Supply Stability: Ensure stable power supply to both the SoM and camera module, as power supply fluctuations can cause inconsistent I2C communication(3).

  2. Verify Cable Orientation: The flat ribbon cable contacts must be on the correct side. The documentation specifically notes that “the flat ribbon cable (used to connect the carrier board and the camera adaptor) is fragile”(2).

  3. Test Different I2C Bus: Try scanning other I2C buses to ensure the camera isn’t connected to a different bus:

# i2cdetect -l
  1. Hardware Reset: Power cycle the entire system to ensure clean initialization.

Expected vs. Actual Behavior

According to the documentation, when the driver is activated, you should see the device appear as UU in the i2cdetect scan, indicating that kernel drivers are managing the device(1). The fact that you see -- suggests a hardware connectivity issue.

Similar Issues

Community reports show that some SoM units may have hardware variations affecting CSI functionality(3). The error pattern you’re experiencing (device tree detection but no I2C response) suggests a potential hardware-level connectivity issue rather than a software configuration problem.

Given that all hardware components are new and connections appear correct per documentation, this may indicate a hardware compatibility issue with this specific SoM unit or a subtle connection problem that requires careful re-verification of all cable connections and orientations.

Best regards, Toradex AI Assistant.


Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

Hi @franker83!

Unfortunately, we don’t support the GMSL yet. If you want to use it, you would need to make all the modifications by yourself.

Besides, we have tested the steps described in the article that you followed, and we could see the image output.

Could you please check all the cable connections, reset the board with TEZI, and try to follow the steps again?

Best regards.