The process of checking and verifying that the system clocks of computers are in sync with the time source is known as time synchronization. Nowadays, with a large number of contemporary computers spanning across locations and are performing time-critical operations, it is essential to have the clocks are synchronized and accurate with in the order of few tens of Nano-seconds. Some of the use cases for such a it might be necessary to time stamp event occurrences, co-ordination of media broadcasting, phase corrections in small cell base stations, power generation, air traffic control, timing stock trading. One of the easiest and proven mechanisms is the use the constellations of GPS/GNSS satellites and create a globally acceptable clock with high accuracy. 

The key components of Time synchronization are Grandmaster, Master and slave. 

  • The Grandmaster clock is the major time source in a multi-clock network, sending time downstream to other master clocks. It has exceptionally accurate timing synchronization.
  • There could be options Master clocks acting as distributor aligning Grandmaster and slave clocks.  
  • A slave clock is a device or clock that synchronizes with the master clock but does not provide timing.

In this blog, with the advent of powerful embedded systems, we will discuss in detail about the GPS grandmaster and realizing it with a low-cost ARM based Embedded Linux system and the associated technologies. 

GPS Grandmaster

As mentioned, Grandmaster clock is the primary source of clock in the network. Some of the major features expected of a Grandmaster includes:

  • Accuracy – This is the most important feature of Grandmaster, and it is determined by system design, timestamping accuracy, and many algorithms such as BMCA (Best Master Clock Algorithm) and processes that run in the system (e.g., filtering, servo, etc). 
  • Scalability – It refers to the overall number of physical interfaces a Grandmaster can have as well as the number of clock instances it can handle. 
  • Resiliency– It is the capacity to handle numerous timing inputs that act as alternate time sources.  
  • Portability – Sometimes it is essential to have the Grandmaster mobile. 

Today, every part of the world is practically covered with Global navigation satellite systems (GNSS)such as USA’s NAVSTAR Global Positioning System (GPS), Europe’s Galileo

Today, every part of the world is practically covered with Global navigation satellite systems (GNSS)such as USA’s NAVSTAR Global Positioning System (GPS), Europe’s Galileo, Russia’s Global’naya Navigatsionnaya Sputnikovaya Sistema (GLONASS), Indian Regional Navigation Satellite System (IRNSS), China’s BeiDou Navigation Satellite System. These satellites not only provide navigation data but also are time-transfer systems. Even a low-cost GPS receiver can provide accurate time information with stability very close to one part in ten to the fourteenth over one day (1ns/day).

Grandmasters can be created with such GNSS/GPS based receivers. A typical, GPS Grandmaster architecture looks like as shown in the below diagram 

GPS Grandmaster - Block Diagram
GPS Grandmaster – Block Diagram

GPS-PPS Synchronization 

Typically, GPS receivers provides the time of the day (ToD) information over a serial interface such as RS232/USB Serial as NMEA text. As this is not sufficient to synchronize, the GPS receivers provide a synchronization mechanism called pulse per second (PPS). This pulse, which has a rising edge synchronized with the GPS second, is of high accuracy, and can be used to discipline local clocks in order to keep them in sync with Universal Time (UT).

With a capable timing system inside the embedded Linux, it is possible to maintain the system clock with in few Nano-seconds of UT. With the system clock synchronized, now it has to be transferred to the slaves via a standard mechanism such as PTP or NTP.

NTP Server 

One of the early and widely used Time Synchronization protocols is NTP – Network Time Protocol. The hierarchical architecture of NTP is divided into strata. Atomic clocks, like those in GNSS satellites, and GPS are examples of stratum 0 devices at the very top. Stratum 1 servers, also known as primary time servers, have a one-on-one direct link with a Stratum 0 clock, can achieve microsecond-level synchronization with Stratum 0 clocks, and can connect to other Stratum 1 servers for quick sanity checks and data backup. For tighter synchronization and increased accuracy, Stratum 2 servers can link to numerous primary time servers. NTP can support up to 15 strata, although each one reduces client synchronization by a little amount compared to Stratum 0. 

Because NTP networks are software-based, all timestamp queries must wait for the local operating system, they have more latency and poorer accuracy. NTP provides a precise enough time resolution for most enterprises to settle conflicts quickly, but those requiring a much higher level of synchronization need to go for more precise PTP. 

PTP Server 

PTP, or Precision Time Protocol, is a network-based time synchronization standard that aims at nanosecond or even picosecond-level synchronization rather than millisecond-level synchronization of NTP. 

Vis a vis NTP’s software-based approach, PTP timestamping is particularly precise because it uses hardware timestamping. 

A total of four messages are exchanged between the master and slave in every PTP sequence:  

  • The master’s first sync message to the slave 
  • A slave to master sync message is sent as a follow-up
  • A message from the slave to the master requesting a postponement
  • The master sends a final delay response message to the slave

There are four different timestamps produced by this sequence: 

  • T1 is the time when the master sends the first sync message
  • T2 is the time when the slave receives the first sync message
  • T3 is when the slave requests a delay 
  • T4 is when the delay request is received by the master 

During the delay response phase, the master delivers all four timestamps to the slave, and the slave can calculate the network latency between the master and slave in both directions. 

IEEE 1588 enabled Ethernet PHY 

As mentioned earlier, PTP needs a dedicated hardware time stamping mechanism. This is possible with single-chip Ethernet Physical Layer Transceiver (PHY) that are provided with IEEE 1588 based timestamping. While these are very similar to conventional Ethernet PHY’s, they have high precision timer that can timestamp transmission/receive packets in pico-second resolution. Some of the 1588 enabled PHY’s includes are Renesas UPD60611, Microchip KSZ8441, TI DP83869HM, Broadcom BCM81384 etc.

Embedded Linux based Grandmaster  

Earlier days, it called for very powerful dedicated system to achieve time synchronization. Nowadays, even low-cost systems have enough power to act as Grandmasters. It is possible to achieve the high precision with some support from hardware such as IEEE1588 based timestamping. There is a plethora of open-source projects addressing the needs and it is quiet easy to create Embedded Linux based Grandmaster systems.

Some of the utilities that can be used are :


Ptp4l is an IEEE-compliant implementation of the PTP. It implements both network master and slave clocks. For Grandmaster implementation, the master functionality can be used which will consider system clock as reference clock. Typical output of Ptp4l running as master on eth0 port is as follows: 

ptp4l[1760.714]: port 1 (eth0): LISTENING to MASTER on ANNOUNCE_RECEIPT_TIMEOUT_EXPIRES 

ptp4l[1760.715]: selected local clock 0e8a76.fffe.6b8917 as best master 

ptp4l[1760.715]: port 1 (eth0): assuming the grand master role 


Phc2sys is an application that synchronizes the system clock with a PTP hardware clock (PHC). 

PHC follows PTP time in hardware time stamping mode, while the system clock follows UTC time. phc2sys maintains the time difference between these two clocks in nanoseconds 


ts2phc can be used to synchronizes PTP Hardware Clocks (PHC) to external time stamp signals. A single source may be used to distribute time to one or more PHC devices.  

 In addition to above tools, testp2p utility can be used to perform various operations such as driving external signal at PPS, setting/getting PTP time and date etc.,

With the GPS/PPS inputs, it will be possible to synchronize the Realtime clock to globally accepted accurate time. The PTP server can serve this time to other slaves.  

Running phc2sys will produce the following output :

CLOCK_REALTIME phc offset 1635162324159518479 s0 freq +0 delay 160546 

CLOCK_REALTIME phc offset 1635162324159518096 s1 freq –375 delay 160606 

CLOCK_REALTIME phc offset 0 s2 freq -375 delay 160606 

CLOCK_REALTIME phc offset 8 s2 freq -367 delay 160545 

 CLOCK_REALTIME phc offset 12 s2 freq -368 delay 160540 

 CLOCK_REALTIME phc offset -25 s2 freq -365 delay 160541 

As it can be seen the time offset between the PHC and the System clock is shown in the offset information. The System clock is synchronized if the offset is continuously less than 30 ns.  

The offset is kept within a nanosecond range of +/-50 nanoseconds. The clock servo states are indicated by the s0, s1, and s2 strings:  

  • s0- unlocked 
  • s1- clock step 
  • s2- locked 

The clock will not be stepped until the Servo state is locked (s2) (slowly adjusted). The freq value is the frequency adjustment of the clock in parts per billion (ppb). 

NTP servers too, synchronize the NTP client with server time (Stratum 1). 

Other management protocols such as SNMP can be used to monitor various clocks in the system and their characteristics like accuracy, precision, resolution, current synchronization states etc. 

About Embien

Embien Technologies is a high-tech services provider in the embedded systems segment catering to such niche requirements. We have helped customers achieve sub- 30 nanoseconds compliance for PTP and sub-100 microseconds accuracy for NTP with Linux based embedded systems. Our other credentials include GPS anti-jamming system development, MIR-DIAL- Mid-infrared differential absorption LIDAR systems etc.

In any vehicle, the instrument cluster forms a critical part as it is the face of the vehicle that reflects the current state. Apart from providing the basic vehicle information, it can also provide crucial indications of electrical component malfunctions (EFI /ISG related). Clusters can acquire vehicle data over simple mechanisms such as encoders as well as through complex interfaces such as CAN, SAEJ1850 etc.,

Instrument cluster design for electric vehicles may have less system complexity, but they have to be more user friendly, less power hungry, and a cost-effective solution. Careful design and choice of cluster components is necessary to meet the stringent compliance requirements. Of the constituent components, the MCU holds the major stock whereas only a few vendors will be supporting automotive grade with the desired feature sets.

Renesas RL78 is an ultra-low power microcontroller (MCU) that enables customers to build compact, energy efficient instrument clusters for a wide range of two-wheeler and four-wheeler vehicles. It offers highly suitable peripheral interfaces such as: Three Channels of Stepper Motor Controller, LCD controller, Multiple IOs etc.,

In this blog, we will discuss in detail about the various features of an instrument cluster and how RL78 MCU will help simplify the design.

Instrument Cluster Subsystem

The major components and their functionalities are as follows:

  • Gauges: Generally, three gauges namely RPM, Temperature and Fuel Level get indicated by the cluster.
    • Fuel Gauge: The Fuel gauge ranges from Empty (E) to Full (F). Typically, the Fuel sensor unit is a TSR /SMR type realized with components such as float with potentiometer, Adjustable arm and sending unit with two wires (signal & ground wire). The signal received from the fuel sensor is analog. The pointer position depends upon the incoming resistance value and indicates the vehicle’s fuel level.
    • RPM Gauge: The signal received from the RPM sensor from encoder such as tach terminal unit with signal & ground wire, fire wall grommets is treated as frequency input. Based on the type and top speed of the vehicle, the input range varies.
    • Temperature Gauge: The signal received from the temperature sensor is also analog. Realized with sensors such as protective rubber unit, thermistor with two wire. Front end circuit converts the input resistance to corresponding voltage and thereby the voltage value at the microcontroller input indicates the current engine temperature.
    • Seven Segment Displays: Clusters may have different type of segmented display with various resolutions such as 27 X 4, 39 X 4, 48 X 4, 53 X 4 and 54 X 4. These could indicate information such as odometer, trip distance, hour meter etc.,
    • Telltales: Telltales are sort of regulatory indications typically realized with LEDS required to show the state of various components such as low battery, engine faults, high beam etc. They are usually realized via onboard LEDs with mechanical light guide. Graphical overlays will also be placed over the guides with standard Tell tale signs.
    • Switches: Usually a single switch or simple rotatable push-type switches are available to manipulate the information shown in the display such as Trip distance, Time etc.

There could be variations in the offerings and feature set based on the vehicle manufacturer.

RENESAS RL78 for Cluster:

Renesas is a leading semi-conductor company in the automotive space offering cluster solutions for many decades. While there are some architectural differences between all the MCU’s of the Renesas RL78 family, the sub-system remains more or less the same. The high-level design of the RL78 MCU based instrument cluster is captured below:

Instrument Cluster - Block Diagram
Instrument Cluster – Block Diagram

RL78 series of MCU’s help realize vehicle clusters effectively with its feature rich peripherals set:

Microcontroller: The RL78 MCU helps in achieving the highest performance within the low end MCU space. It offers improved efficiency, extensive scalability and reliable safety functions that aid in developing energy efficient instrument clusters. It has an operating voltage that ranges from 2.7V to 5.5V and flashes the program using 80 microcontroller pins.

Stepper Motor Drivers: There are up to three channels of stepper motor controllers / drivers with zero-point detection that can be configured using PORT pins (Sin+, Sin-, Cos+, Cos-). Each channel is controlling a stepper motor dedicated to gauges which commands the motor to move and hold at one of the angles without any position sensor. With the help of software based PID control, it is possible to effectively control the needles.

Segment LCD Controller: Capable of driving up to 200+ segments, the in-built LCD controller is available for controlling the segmented display with various resolutions such as 27 X 4, 39 X 4, 48 X 4, 53 X 4 and 54 X 4 which is directly driven from the RL78 microcontroller. The LCD screen can be controlled by the software to display any kind of data dynamically such as TRPI information, hour meter data etc.

Multiple IOs: There are multiple analogs and digital IOs available for interfacing sensors and Tell-Tale LEDs. RPM, temperature, and fuel level sensors are interfaced via a suitable front-end circuit. If needed, various Tell-Tale LEDs such as turn left, turn right, service, brake, etc. can be driven with dedicated digital outputs.

  • Analog Input Gauges: RL78 series comes with a rich set of ADC inputs that can be used to convert resistance/voltage-based sensor inputs to digital values. Software based processing will increase the accuracy of the acquired value.
  • Encoder inputs: With up to 24 timers, RL78 can be used to measure a variety of encoder inputs such as RPM, perform custom processing and obtain accurate digital values.
  • External connectivity: RL78 can also support I2C/SPI interfaces that can be used to communicate with peripherals such as EEPROM where the accumulated vehicle information such as ODO, TRIP data can be stored. RTC can be interfaces to track real time.  

Variants of RL78 also offers sound generator which can set a volume level and tone frequency, two channels of CAN, and expanded flash memory/RAM up to a maximum of 512 KB/24 KB, suitable for low-end instrument cluster applications.

Embien’s Expertise in the Automotive Industry:

Embien Technologies is a leading embedded systems development company that specializes in high – tech product engineering services. We help clients take competitive lead in their markets. With a unique mix of innovation, technology, and quality, we offer cutting-edge automotive electronics system designs by adapting the latest technologies in clusters, diagnostics, infotainment, connectivity etc., With deep domain expertise, we have assisted several OEMs, Tier 1, and Tier 2 vendors to surge their automotive electronics such as Instrument Clusters (Heavy & Light- Duty Vehicles), Digital Cockpits etc., by integrating sensors & radars, network connectivity, path planning & mapping technologies. Do you have a design idea in mind? Then, get in touch with us today!

Karthick B
29. June 2021 · Write a comment · Categories: Miscellaneous

Nvidia Jetson platforms powered by the Tegra processors have carved themselves a niche in the edge analytics market especially in the field of video analytics, machine vision etc. With a wide range of interfaces like MIPI-CSI, USB, Gigabit Ethernet, it is possible to acquire video data over many different interfaces. Of them, the CSI interface remains the most preferred interface for machine vision applications.

In this blog, we will discuss in detail about the camera interface and data flow in Jetson Tegra platforms and typical configuration and setup of a MIPI CSI driver. For specifics, we will consider Jetson Nano and Onsemi OV5693 camera.

Jetson Camera Subsystem

While there are significant architectural differences between the Tegra TX1, TX2, Xavier and Nano platforms, the camera hardware sub-system remains more or less the same. The high level design of the same is captured below.

Nvidia Tegra Camera Sub System
Nvidia Tegra Camera Sub system

As seen, the major components and their functionalities are:

  • CSI Unit: The MIPI-CSI compatible input sub-system that is responsible for data acquisition from the camera, organize the pixel format and send it to the VI unit. There are 6 Pixel Parser (PP) units, each of which can accept input from a single 2-lane camera. Apart of this 6-camera model, it is also possible to reconfigure the inputs such that 3 Mono or Stereo 4-lane cameras can be connected to PPA, CSI1_PPA and CSI2_PPA pairs.
  • VI: The Video Input unit accepts data from the CSI unit over a 24-bit bus with the positioning of data determined by the input format. Then this data can be routed to any one or 2 of the following interested parties. The VI also has a Host 1x interface with 2 channels – one to control I2C access to cameras and another for VI register programming.
  • Memory: Written to system memory for further consumption by the applications.
  • Image Signal Processor ISP A:For pre-processing the input data and convert/pack it to a different format. ISP A can also acquire data from memory.
  • Image Signal Processor ISP B:For pre-processing the input data and convert/pack it to a different format. ISP A can also acquire data from memory.

VI Unit provides a hardware-software sysncronization mechanism called VI Sync Points (syncpts) that are used to wait for a particular condition to be met and increment a counter or want for the counter to reach a particular value. Multiple predefined indices are available each corresponding to once functionality such as frame start, line end, completion of ISP processing. For example, the software can choose to wait till one frame is receved by the VI indicated via the next counter value corresponding to the index.

With these powerful compoenets, the Tegra Camera sub-system offers options the handle data seamlessly from multiple sources in different formats.

Linux 4 Tegra Camera Driver

With understanding of the hardware sub-system, we will now look into the software architecture of Tegra camera interface. Nvidia supports Linux OS with its Linux4Tegra (L4T) software. The camera drivers configures and read the data from camera sensors over the CSI bus in the sensor’s native format and optionally convert them to a different format.

Nvidia provides two types of camera access paths, that can be chosen depending on the camera and application use case:

  • Direct V4L2 Interface

Primarily for capturing RAW data from camera, this is a minimal path where no processing are done  and the data is directly consumed by the user application.

  • Camera Core Library Interface

In this model, the camera data is consumed via few Nvidia libraries such as Camera Core, libArgus. In this case, various data processing can be done on the input data efficiently leveraging the GPU available in the core.

In either case, the application can be a Gstreamer plugin or a custom one.

OV5693 Camera for Jetson

To take a deep-dive, let us consider the 5MP(2592 x 1944, Bayer sensor)Omnivision CSI camera module OV5693 that comes with the Tegra TX1 and TX2 carrier board by default. High level software architecture is captured below:

L4T Camera Driver Architecture
L4T Camera Driver Architecture

The OV5693 camera connected to I2C bus 0x06 (default \I2C address as 0x36) via TCA9548 I2C expander chip. This can be changed to 0x40 by adding a pull up resistor on SID pin.

The OV5693 driver is triggered using I2C bus driver and registers itself with the Tegra V4L2 camera framework. This in turn exposes /dev/videoX device that can be used by the application to consume the data.

To bring up the OV5693 driver, following must be handled and are further explained in the next sections:

  • Appropriate node in the Device Tree
  • V4L2 compatible sensor driver

In the next section, we will see how to set up the device tree for OV5693 camera.

Device Tree Changes for Tegra Camera

The  tegra194-camera-e3333-a00.dtsi file is located  in /hardware/nvidia/platform/t19x/common/kernel-dts/t19x-common-modules/ folder.


tegra-camera-platform consist of one or more modules which defines the basic information of the camera/sensor connected to the Tegra SoC. While the common part in the top, contains consolidated information about all the connected, each of the module sub section defines them individually. In this case, single OV5693 camera is connected over two MIPI lanes.

tegra-camera-platform {
    compatible = "nvidia, tegra-camera-platform";
    num_csi_lanes = <2>;        //Number of lanes
    max_lane_speed = <1500000>; //Maximum lane speed
    min_bits_per_pixel = <12>;  //bits per pixel
    vi_peak_byte_per_pixel = <2>;   //byte per pixel
    vi_bw_margin_pct = <25>;    //Don't care
    max_pixel_rate = <160000>;  //Don't care
    isp_peak_byte_per_pixel = <5>;//Don't care
    isp_bw_margin_pct = <25>;   //Don't care

    modules {
        module0 { //OV5693 basic details
            badge = "ov5693_right_iicov5693";
            position = "right";
            orientation = "1";
            drivernode0 {
                pcl_id = "v4l2_sensor";
                devname = "ov5693 06-0036";
                proc-device-tree = "/proc/device-tree/i2c@31c0000/tca9548@77/i2c@6/ov5693_a@36"; //Device tree node path

Device tree node

In device tree node, all the camera properties (output resolution, FPS, Mipi clock…etc) must be added for proper operation of the device.

I2c@31c0000 {   //I2C-6 base address
	tca9548@77 { //I2C expander IC
		i2c@6 {
			ov5693_a@36 {
				compatible = nvidia,ov5693";
				reg = <0x36>; //I2C slave address
				devnode = "video0";//device name

				/* Physical dimensions of sensor */
				physical_w = "3.674";	//physical width of the sensor
				physical_h = "2.738";	//physical height of the sensor

				/* Enable EEPROM support */
				has-eeprom = "1";

				/* Define any required hw resources needed by driver */
				/* ie. clocks, io pins, power sources */
				avdd-reg = "vana";	//Power Regulator 
				iovdd-reg = "vif";	//Power Regulator
				mode0 { // OV5693_MODE_2592X1944
					mclk_khz = "24000";		//MIPI driving clock
					num_lanes = "2";		//Number of lanes
					tegra_sinterface = "serial_a"; //Serial interface
					phy_mode = "DPHY";		//physical connection mode
					discontinuous_clk = "yes";
					dpcm_enable = "false";		//Don't care
					cil_settletime = "0";		//Don't care

					active_w = "2592";		//active width
					active_h = "1944";		//active height
					mode_type = "bayer";		//sensor type
					pixel_phase = "bggr";		//output format
					csi_pixel_bit_depth = "10";	//bit per pixel
					readout_orientation = "0";	//Don't care
					line_length = "2688";		//Total width
					inherent_gain = "1";		//Don't care
					mclk_multiplier = "6.67";	//pix_clk_hz/mclk_khz
					pix_clk_hz = "160000000";	//Pixel clock HTotal*VTotal*FPS 
					gain_factor = "10";		//Don't care
					min_gain_val = "10";/* 1DB*/	//Don't care
					max_gain_val = "160";/* 16DB*/ //Don't care
					step_gain_val = "1";		//Don't care
					default_gain = "10";		//Don't care
					min_hdr_ratio = "1";		//Don't care
					max_hdr_ratio = "1";		//Don't care
					framerate_factor = "1000000";	//Don't care
					min_framerate = "1816577";	//Don't care
					max_framerate = "30000000";
					step_framerate = "1";
					default_framerate = "30000000";
					exposure_factor = "1000000";	//Don't care
					min_exp_time = "34";		//Don't care
					max_exp_time = "550385";	//Don't care
					step_exp_time = "1";		//Don't care
					default_exp_time = "33334";	//Don't care
					embedded_metadata_height = "0";//Don't care

In this example, the pixel clock is calculated as below:

pix_clk_hz = HTotal*VTotal*FPS

For OV5693:- 2592×1944@30fps

Total height and Total width for 2592×1944 is 2688×1984

pix_clk_hz = 2688 x 1984 x 30 = 159989760

pix_clk_hz is ~160000000

And the mclk multiplier is

mclk_multiplier = pix_clk_hz / mclk_khz
mclk_multiplier = 160000000 / 24000000 = 6.66

DTS binding

As seen earlier, the camera data flow is as follows:

Sensor OutputCSI InputCSI outputVI Input
Hardware – Device Tree Nodes Data flow mapping

The binding between internal ports is done by using the below settings.

ports {
	#address-cells = <1>;
	#size-cells = <0>;
port@0 {
	reg = <0>;
	ov5693_ov5693_out0: endpoint {
		port-index = <0>;
		bus-width = <2>;
		remote-endpoint = <&ov5693_csi_in0>;

nvcsi@15a00000 {
	num-channels = <1>;
	#address-cells = <1>;
	#size-cells = <0>;
	status = "okay";
	channel@0 {
		reg = <0>;
		ports {
			#address-cells = <1>;
			#size-cells = <0>;
			port@0 {
				reg = <0>;
				ov5693_csi_in0: endpoint@0 {
					port-index = <0>;
					bus-width = <2>;
					remote-endpoint = <&ov5693_ov5693_out0>;
			port@1 {
				reg = <1>;
				ov5693_csi_out0: endpoint@1 {
					remote-endpoint = <&ov5693_vi_in0>;
host1x {
	vi@15c10000 {
		num-channels = <1>;
		ports {
			#address-cells = <1>;
			#size-cells = <0>;
			port@0 {
				reg = <0>;
				ov5693_vi_in0: endpoint {
				port-index = <0>;
				bus-width = <2>;
				remote-endpoint = <&ov5693_csi_out0>;

The driver get the data from VI output via Host1x DMA engine module.


L4T employs a mechanism of DTB overlays’ to enable/disable to drivers. The ov5693 driver can be enabled in the DTS by setting its status field to “okay”.

fragment-ov5693@0 {
    ids = "2180-*";
    override@0 {
        target = <&ov5693_cam0>;
        _overlay_ {
            status = "okay";


During boot up, if the proper camera module is detected, then the overlay added to the device tree node and further driver and device registration is done by camera driver(ov5693.c) as described in the next blog.

About Embien: Embien is a leading product engineering service provided with specialised expertise on Nvidia Tegra and Jetson platform. We have been interfacing various types of cameras over different interfaces with the Nvidia platforms and enabling them with libargus framework as well as customised Gstreamer plugins and applications. Our customers include Fortune 500 companies in the field of defence, avionics, industrial automation, medical, automotive and semi-conductors.