Need Guidance: Framos FSM:GO Camera w/ Verdin iMX8M Plus on TorizonOS

I’m looking for guidance on the best/fastest way to get up and running with an FSM:Go IMX676 camera module, Verdin iMX8M Plus, and Mallow Carrier Board over CSI.

I found the following documentation: First Steps with FRAMOS FSM:Go… (Torizon), which indicates that I will need to use TorizonCore to generate the device tree overlay, resulting in a new image to flash to the board with Easy Installer.

I just want to make sure this is the correct direction and that these steps are necessary, versus simply setting up the three Docker containers mentioned in those docs.

I have already flashed the latest TorizonOS that shipped with the board, but I’m guessing that this “vanilla” TorizonOS does not include the necessary device tree overlay, so I MUST build a new image before running the containers that get the stream from the camera. Let me know if that is correct and if there are other resources I should look at. Thank you!

Hardware:

  • FRAMOS FSM:GO w/ Sony IMX676 Sensor
  • Verdin iMX8M Plus 8GB WB IT V1.1A
  • Mallow Carrier Board V1.1C

tdx-info:

Software summary
------------------------------------------------------------
Bootloader:               U-Boot
Kernel version:           6.6.84-7.2.0-g87bfb710b6f1 #1-Torizon SMP PREEMPT Mon Mar 31 08:47:48 UTC 2025
Kernel command line:      root=LABEL=otaroot rootfstype=ext4 quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3 ostree=/ostree/boot.1/torizon/157a467dd3b97eaebfbf6e17d0c8859fdd0abc1d397c637c6ecd808f79dc0260/0
Distro name:              NAME="Torizon OS"
Distro version:           VERSION_ID=7.2.0-build.13
Distro variant:           VARIANT="Docker"
Hostname:                 verdin-imx8mp-15601692
------------------------------------------------------------

Hardware info
------------------------------------------------------------
HW model:                 Toradex Verdin iMX8M Plus WB on Verdin Development Board
Toradex version:          0070 V1.1A
Serial number:            15601692
Processor arch:           aarch64
------------------------------------------------------------

Hi, I’m the Toradex AI Assistant. The Toradex Support team will follow up with you shortly!

Did you like my answer?

:+1: :-1:


Hello!

You’re absolutely right. To use the FSM:GO cameras with your setup, you’ll need to generate and apply a device tree overlay using TorizonCore Builder before running the necessary containers. This step is essential because the standard Torizon OS image does not include the required device tree overlays for these cameras.

Your hardware setup is indeed compatible:

  • The Mallow Carrier Board supports the MIPI CSI-2 interface.
  • The Verdin iMX8M Plus 8GB WB IT (0070) is compatible with these cameras.

Here are the steps you should follow:

  1. Generate the Device Tree Overlay: Use TorizonCore Builder to create the necessary device tree overlay. This will configure the system to recognize and work with the FSM:GO cameras.

  2. Flash the Customized Image: Use the Toradex Easy Installer to flash the customized image onto your device. This image will include the device tree overlay you generated.

  3. Launch the Required Containers:

    • Start the Weston container for graphical interface support.
    • Run the isp-imx container for image signal processing.
    • Launch the Gstreamer container for multimedia handling.

For detailed instructions on generating the device tree overlay and customizing the image, please refer to the “First Steps with Framos FSM:GO CSI Optical Sensor Modules (Torizon)” documentation.

I hope this helps you get started with your project!

Best regards, Toradex AI Assistant.

Greetings @nimble-william,

I just want to make sure this is the correct direction and that these steps are necessary, versus simply setting up the three Docker containers mentioned in those docs.

That should be correct. The standard Torizon OS image does not have the drivers and device tree configuration to run that camera. That’s why the documentation has you fetch these missing elements, and create a custom Torizon OS image with these integrated before running the containers.

Best Regards,
Jeremias

Thank you both for confirming the direction.

I’ve followed along with the documentation and I now have the following tcbuild.yaml configuration. torizoncore-builder build and torizoncore-builder deploy ... both complete successfully, but it doesn’t seem like the device tree overlays are being installed properly. I apologize if this is elementary troubleshooting. This is my first time working with TorizonOS.

input:
  easy-installer:
    local: torizon-docker-verdin-imx8mp-Tezi_7.2.0+build.13.tar
customization:
  splash-screen: splash.png
  device-tree:
    include-dirs:
      - linux/include/
    # >> Custom device tree source:
    custom: linux/arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-mallow.dts
    overlays:
      add:
        - device-trees/overlays/verdin-imx8mp_imx676_overlay.dts
        - device-trees/overlays/verdin-imx8mp_hdmi_overlay.dts
  kernel:
    modules:
      - source-dir: imx676-driver/
        autoload: false
output:
  easy-installer:
    # >> Output directory of the customized image (REQUIRED):
    local: torizon-docker-verdin-imx8mp-Tezi_7.2.0+build.13.CUSTOM
    name: "CUSTOM IMAGE"

Output of the build command:

$ torizoncore-builder build
Building image as per configuration file 'tcbuild.yaml'...

=>> Handling input section
Unpacking Toradex Easy Installer image.
Unpacking TorizonCore Toradex Easy Installer image.
Importing OSTree revision 789c47c5e2f5cd8d1aa177ed9db1da6ae097ea69188980e51bf534e463966269 from local repository...
1271 metadata, 9767 content objects imported; 650.0 MB content written
0 metadata, 0 content objects imported; 0 bytes content written
Unpacked OSTree from Toradex Easy Installer image:
  Commit checksum: 789c47c5e2f5cd8d1aa177ed9db1da6ae097ea69188980e51bf534e463966269
  TorizonCore Version: 7.2.0+build.13

=>> Handling customization section

=> Setting splash screen
splash screen merged to initramfs

=> Handling device-tree subsection

=> Selecting custom device-tree 'linux/arch/arm64/boot/dts/freescale/imx8mp-verdin-wifi-mallow.dts'
'imx8mp-verdin-wifi-mallow.dts' compiles successfully.
warning: removing currently applied device tree overlays
Device tree imx8mp-verdin-wifi-mallow.dtb successfully applied.

=> Adding device-tree overlay 'device-trees/overlays/verdin-imx8mp_imx676_overlay.dts'
'verdin-imx8mp_imx676_overlay.dts' compiles successfully.
/tmp/tmpisk45d6p: Device Tree Blob version 17, size=88668, boot CPU=0, string block size=6708, DT structure block size=81904
'verdin-imx8mp_imx676_overlay.dtbo' can successfully modify the device tree 'imx8mp-verdin-wifi-mallow.dtb'.
Overlay verdin-imx8mp_imx676_overlay.dtbo successfully applied.

=> Adding device-tree overlay 'device-trees/overlays/verdin-imx8mp_hdmi_overlay.dts'
'verdin-imx8mp_hdmi_overlay.dts' compiles successfully.
/tmp/tmpb6nk6o5k: Device Tree Blob version 17, size=88652, boot CPU=0, string block size=6708, DT structure block size=81888
'verdin-imx8mp_hdmi_overlay.dtbo' can successfully modify the device tree 'imx8mp-verdin-wifi-mallow.dtb'.
Overlay verdin-imx8mp_hdmi_overlay.dtbo successfully applied.

=> Building module located at 'imx676-driver/'
make: Entering directory '/workdir/imx676-driver'
make -C /storage/linux M=/workdir/imx676-driver
make[1]: Entering directory '/storage/linux'
  CC [M]  /workdir/imx676-driver/imx676_mipi.o
  LD [M]  /workdir/imx676-driver/imx676.o
  MODPOST /workdir/imx676-driver/Module.symvers
  CC [M]  /workdir/imx676-driver/imx676.mod.o
  LD [M]  /workdir/imx676-driver/imx676.ko
make[1]: Leaving directory '/storage/linux'
make: Leaving directory '/workdir/imx676-driver'

Kernel module(s) successfully built and ready to deploy.
All kernel module(s) have been built and prepared.

=>> Handling output section
Applying changes from STORAGE/kernel.
Applying changes from STORAGE/splash.
Applying changes from STORAGE/dt.
Commit f4e46505ce406f84e102323ffbb15971c08b63fcef59e168e7c0213ca7ae2f13 has been generated for changes and is ready to be deployed.
Deploying commit ref: tcbuilder-20250502173729
Pulling OSTree with ref tcbuilder-20250502173729 from local archive repository...
  Commit checksum: f4e46505ce406f84e102323ffbb15971c08b63fcef59e168e7c0213ca7ae2f13
  TorizonCore Version: 7.2.0+build.13-tcbuilder.20250502173732
  Default kernel arguments: quiet logo.nologo vt.global_cursor_default=0 plymouth.ignore-serial-consoles splash fbcon=map:3

1271 metadata, 9768 content objects imported; 650.1 MB content written
Pulling done.
Deploying OSTree with checksum f4e46505ce406f84e102323ffbb15971c08b63fcef59e168e7c0213ca7ae2f13
Bootloader found in unpacked image: U-Boot
Deploying done.
Copy files not under OSTree control from original deployment.
Packing rootfs...
Packing rootfs done.

=>> Build command successfully executed!

Output of the deploy command (SSH):

$ torizoncore-builder deploy --remote-host 10.4.7.10 --remote-username torizon --remote-password ####### --reboot

Pulling OSTree with ref base (checksum 789c47c5e2f5cd8d1aa177ed9db1da6ae097ea69188980e51bf534e463966269) from local archive repository...
Starting http server to serve OSTree.
OSTree server listening on "localhost:32981".
Starting OSTree pull on the device...
Deploying new OSTree on the device...
Deploying successfully finished.
Device reboot initiated...

The board seems to receive these new builds, but I don’t see any changes:

$ sudo ostree admin status
Password: 
* torizon 789c47c5e2f5cd8d1aa177ed9db1da6ae097ea69188980e51bf534e463966269.5
    Version: 7.2.0+build.13
    origin refspec: tcbuilder:789c47c5e2f5cd8d1aa177ed9db1da6ae097ea69188980e51bf534e463966269
  torizon 789c47c5e2f5cd8d1aa177ed9db1da6ae097ea69188980e51bf534e463966269.4 (rollback)
    Version: 7.2.0+build.13
    origin refspec: tcbuilder:789c47c5e2f5cd8d1aa177ed9db1da6ae097ea69188980e51bf534e463966269

Please let me know if the output of any other commands would be helpful to see.

1 Like

If you look at the logs from the build command notice the commit checksum hash:

...
Unpacked OSTree from Toradex Easy Installer image:
  Commit checksum: 789c47c5e2f5cd8d1aa177ed9db1da6ae097ea69188980e51bf534e463966269
  TorizonCore Version: 7.2.0+build.13
...

Compare to the checksum hash that you deployed to the device:

...
Pulling OSTree with ref base (checksum 789c47c5e2f5cd8d1aa177ed9db1da6ae097ea69188980e51bf534e463966269) from local archive repository...
...

You deployed your input image to the device not the output image.

To deploy your output image add the optional branch field to the output section of your tcbuild.yaml like so:

...
output:
  easy-installer:
    # >> Output directory of the customized image (REQUIRED):
    local: torizon-docker-verdin-imx8mp-Tezi_7.2.0+build.13.CUSTOM
    name: "CUSTOM IMAGE"
  ostree:
    branch: <whatever name you want here>
...

Then after running the build command supply the name you used, to the deploy command.

Alternatively, just install the output image via Toradex Easy Installer, as documented in the documentation.

Best Regards,
Jeremias

Thank you @jeriamias.tx – that is exactly what I was missing.

I naively assumed the deploy command would automatically look at the output config. I understand the role of a SHA, but I don’t entirely comprehend where it’s coming from in this case. Is TCB creating an actual Git branch? Why does it treat the input as the default? How does it “see” and track these “branches”? Just wondering.

At any rate, this was very helpful and I am good to go: I’ve successfully deployed my custom image with the IMX676 overlays. I connected the camera, and the board found it without any trouble. Finally, I added the example docker configs from the documentation and I have an image on the screen. It’ll be all software dev from here on out.

Thanks again,
William

1 Like

Is TCB creating an actual Git branch? Why does it treat the input as the default? How does it “see” and track these “branches”? Just wondering.

So for management of the OS version we use a 3rd-party library called OSTree: OSTree | Toradex Developer Center

It can be loosely described as a “git for filesystems” which is why you noticed similarities like hashes, commits, and branches.

Finally, I added the example docker configs from the documentation and I have an image on the screen. It’ll be all software dev from here on out.

Perfect that’s good to hear. Do you have any other questions/issues related to this topic?

Best Regards,
Jeremias