Forums » Software Development »
DCDevice tree additions for custom camera + DSI/touch
Added by David Cuccia 8 days 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 (2)
DC RE: Device tree additions for custom camera + DSI/touch - Added by David Cuccia 7 days 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.)
GG RE: Device tree additions for custom camera + DSI/touch - Added by Gregory Gluszek about 20 hours ago
Hi David,
We typically lean towards option b in your last reply (having a customer build the full image themselves, making any customization as needed on a fork they maintain). The https://support.criticallink.com/git/meta-mitysom-qc6490-5430-devkit.git repo is primarily intended/customized to support the MitySOM-QC Development Board, while also functioning as an example or starting point for other carrier boards designed for the MitySOM-QC.
- Building and Customizing qcom-multimedia-image with Yocto outlines how we recommend doing a build from source
- Updating Devicetree specifically focuses on devicetree development and how to load new dtbs via fastboot
- Update OS and Firmware via OSTree and Capsule Updates specifies OTA update options for release updates to deployed systems (note that the Capsule Update is what updates dtbs specifically, and we personally have yet to verify the functionality of this methodology).
Let me know if you think this would work for your needs. Additionally Tom will be in your area in the next week or so if you are available to meet face to face and discuss this and other potential options if needed.
Thanks,
Greg