Hey everyone, I’m working on a teleoperation robotics system and I need to get two synchronized IMX219 cameras running over GMSL2 on the new NVIDIA Jetson AGX Thor developer kit. I have the Arducam B0549 GMSL2 8MP Camera Extension Kit, and I need to run dual cameras over 2-meter coax cables with hardware sync via FSYNC.
I’ve been digging around but can’t seem to find device tree source files for the imx219_gmsl driver that would work with Thor’s kernel (tegra264 platform). Also, is there a Jetson-compatible GMSL2 deserializer board that plays nice with the Arducam IMX219 serializer modules, or does the B0549 kit cover everything on the hardware side?
Any pointers would be appreciated — I’m kind of stuck at the starting line here.
Thanks for reaching out. Let me take a look at what you’re working with.
So to confirm your setup: NVIDIA Jetson AGX Thor Developer Kit (tegra264), targeting JetPack 6.x whenever it lands for Thor, and the Arducam B0549 GMSL2 8MP Camera Extension Kit with the IMX219 sensor. That sound right?
The short answer is that Jetson AGX Thor is still in early access / active development phase, and our GMSL2 drivers haven’t been ported or validated for the Tegra264 architecture yet. That’s why you’re not finding device tree files that work out of the box — they don’t exist for this platform at this stage.
Yeah, that’s the setup exactly. Bummer about the driver situation, but I figured as much given how new Thor is. Still, I was hoping there’d at least be something I could use as a starting point for porting.
Is there any reference code available from another Jetson platform that I could use as a baseline? I’m willing to do the porting work myself, I just need something to work from. Also — do I actually need a separate deserializer board, or is the B0549 kit self-contained enough?
I’ve put together a reference package with the source code and device tree files from the Jetson Orin Nano (imx219_gmsl driver) and sent it over via private message. That should give you a solid baseline to start porting from. The imx219_gmsl driver on Orin Nano is the closest reference we have — same sensor and GMSL2 pipeline, just a different SoC underneath.
On the hardware side: the B0549 kit already includes everything you need. It comes with the serializer boards for the camera modules and a GMSL2 deserializer HAT. There’s no third-party deserializer required. Once the driver is successfully ported to the Thor kernel, the hardware should physically work. The whole pipeline — serializer, coax, deserializer HAT — is already accounted for in the kit.
Got the PM, thanks — that reference package helps a lot. Just having the Orin Nano imx219_gmsl source and DTS files gives me something concrete to diff against.
Couple of things I’m wondering though: when porting this to Thor’s tegra264, what are the known pain points? I’m guessing the CSI register mappings aren’t going to be a one-to-one match. Any specific areas of the device tree or driver source I should focus on first? I’d rather not waste days on the wrong part of the code.
You’re thinking about this the right way. The main areas that will need attention during the port:
CSI register mappings — These are almost certainly different on Tegra264 compared to Orin. The CSI host controller on Thor may have different register offsets, lane configurations, and PHY settings. You’ll want to cross-reference the Thor Technical Reference Manual (TRM) for the CSI subsystem and map those against what the Orin Nano DTS is doing.
Device tree structure — The overall DTS hierarchy for camera pipelines on Thor may differ. Pay close attention to how the CSI ports, VC (virtual channel) assignments, and I2C buses are laid out. The FSYNC dual-camera sync configuration in particular will need verifying against Thor’s GPIO and camera sync infrastructure.
Clock and power domain trees — Tegra264 may have a different clocking architecture for the camera subsystem, which could affect sensor clock frequencies and MIPI lane rates.
My advice: start with the device tree, because that’s where most of the platform-specific bindings live. Get the camera enumerated on the I2C bus first, then work through the CSI pipeline. The driver source itself (the kernel module) is more about the sensor register sets and GMSL2 ser/des communication, which is less platform-dependent — but you’ll still need to update any Tegra-specific API calls.
That breakdown is super helpful, thanks. I’ll start with the device tree and work through the CSI mappings against the Thor TRM.
One last thing — just to set expectations: has Arducam tested the B0549 hardware at the electrical level with Thor at all? I’m confident the MIPI and I2C signaling should be standard, but I want to make sure I’m not going to hit some weird voltage-domain or pin-mux issue on the Thor’s expansion header that nobody’s seen yet. And for FSYNC over dual cameras, is the sync signal handled entirely through the deserializer HAT, or does it need a dedicated GPIO line back to the Jetson?
To be upfront: no, we haven’t done any electrical validation of the B0549 kit on the Jetson AGX Thor — the platform is too new and still in early access, so it hasn’t been through our hardware qualification pipeline yet.
That said, the B0549 deserializer HAT interfaces over standard MIPI CSI-2 and I2C, so at the physical layer it should be compatible. But you’re right to be cautious — pin-mux differences on the Thor’s expansion connector could absolutely be a thing, and you’ll want to cross-check the HAT pinout against Thor’s carrier board schematic before powering anything up.
Regarding FSYNC: the sync signal for dual-camera operation is handled at the serializer/deserializer level within the B0549 kit. The deserializer HAT manages the synchronization between the two camera streams. However, depending on how you want to trigger sync (hardware-timed vs. software-triggered), you may still want a GPIO line from the Jetson to the deserializer for frame-level triggering. That part would need to be traced through the HAT schematic and mapped to an available GPIO on Thor’s header.
Bottom line: the path forward is self-porting the driver using the Orin Nano reference as your baseline, and doing your own hardware validation on Thor. The B0549 kit has everything you need hardware-wise — it’s just the software that needs to catch up to the new platform.