how are device tree overlays applied ?

Robotics & Edge Computing Jetson & Embedded Systems Jetson TX2
1

Hello,

we have developed a carrier-board for TX1/TX2 modules that can accept many different camera sensor daughter boards. Those daughter boards always use the same hardware slot and signals so they are mutually exclusive. In my v4l2 driver, using always the same device tree, I can recognize them and do the right things, but nvcamera-daemon needs additional info in the device tree, that should be linked-in at boot time. I suspect I must use device tree overlays for that.

How are device-tree overlays programmed and used in l4t 28.2 (jetpack 3.3) ?

2

If your camera modules and/or daughter boards have eeproms on them you may be able to utlize Nvidia’s “plugin manager” which manages device tree overlays for this sort of purpose.

See “Using Plugin Manager” in the L4T documentation for more details to determine if this will work for you.

3

Our camera modules don’t have eeprom, only the sensor, but the driver can read registers in the sensor to identify the sensor type. Those registers are not really accessible outside of the sensor driver because the sensor needs to be powered-up and put in a special mode before one can read the sensor_type registers, so I surmise I’ll need to do something in the driver to activate the overlay part, probably based on one or more properties (e.g. a phandle to overlay fragments for each possible sensor type) found in the sensor entry of the main device tree.

I looked at “Using Plugin Manager” in the L4T documentation, but that seems to rely on the bootloader to discover the installed camera modules(s). I hope that linux can do that all by itself, but I have found no example in the kernel sources.

4

Many of our camera modules do not contain an EEPROM and, even if they did, there’d be a fair amount of code needed to read it via a serdes link. We’ve developed a solution that we’re adding to our code base that uses a string to configure overlays early in the boot process. The code isn’t ready to share publicly yet but it you PM me I could send you a patch that might give you some ideas for your own implementation (or possibly use our technique).

5

Our approach relies on pre-configuration though – it’s not 100% dynamic.

6

Actually, it turned out to be very simple in the end for my case. I only needed in my driver to have the mode0, mode1 … nodes populated in the device-tree node of my sensor at the moment I call ‘camera_common_initialize’. As my driver works for multiple sensors (lets call them typeA, typeB and typeC) I have added the following in the device-tree node of my sensor

overlays {
 typeA_overlays {
  fragment0 {
   target_path = "/path/to/my-sensor-node"
   __overlay__ { /* note that there are two '_'s before and after 'overlay' */
    mode0 {
     ...
    };
    mode1 {
     ...
    };
   }; /* end of __overlay */
  }; /* end of fragment0 */
  /* there could be a fragment1 here to overlay another target node */
 }; /* end of typeA_overlays */
 typeB_overlays {
  ...
 };
 typeC_overlays {
  ...
 };
}; /* end of overlays */

and in my driver, where ‘node’ is my sensor’s node, I only need to call

overlays_node = of_get_child_by_name(node, "overlays");
sprintf(modes_name, "type%c_modes", sensor_type);
modes_node = of_get_child_by_name(overlays_node, modes_name);

of_overlay_create(modes_node); /* does the real work */
of_detach_node(overlays_node); /* not required, but makes a cleaner device-tree */

For that to work, one must have enabled ‘CONFIG_OF_OVERLAY=y’ in linux’s .config file.

That’s all, folks