Forums » Software Development »
DCDevice tree additions for custom camera + DSI/touch
Added by David Cuccia about 2 hours ago
Hi,
Starting a new thread based on previous success
We're porting our camera sensor (V4L2 subdev, I2C) and DSI panel + touch drivers — modules build fine against your SDK's kernel-devsrc. Curious what your recommended route is for the device-tree additions (sensor nodes on CSI0/CSI1 + CAMSS graph, panel under DSI0, touch on I2C)?
Options we see:
(a) DT overlay support in ABL/boot, if any
(b) a kas/Yocto fragment against your scarthgap layer that we build into a variant dtb and flash to dtb_a/b
(c) you carry a customer-variant dtb in the BSP
Which do you support/prefer, and is the dtb reflashable standalone (capsule?) without a full image flash?
Thanks!
David
related thread here for breadcrumbs: https://support.criticallink.com/redmine/boards/78/topics/7410
Replies (1)
DC RE: Device tree additions for custom camera + DSI/touch - Added by David Cuccia about 2 hours ago
Quick addendum that raises the stakes on this question: we tried sideloading our cross-compiled modules (built against your BSP 1.1 SDK's kernel-devsrc — clean vermagic match) onto a BSP 1.2 device, and they're rejected: the kernel has CONFIG_MODULE_SIG_FORCE=y and trusts only its build-time autogenerated key, which the SDK doesn't ship. So for out-of-tree drivers the realistic options seem to be:
(a) our module recipes + DT carried in your layer (signed by your build),
(b) we build the full image ourselves from your public kas/scarthgap setup (we own the key),
(c) a dev-variant kernel without MODULE_SIG_FORCE for bring-up.
Which flow do you support for customers shipping custom camera/panel drivers? (We noticed the QLI 2.0 prelim build has no module signing — handy for development.)