UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Adventurer
Adventurer
2,782 Views
Registered: ‎09-02-2018

MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi,

 

I'm trying to build an video pipeline in PetaLinux using a the Ultra96 board (ZU3EG) and  MIPI CSI-2 camera (OV5647). Now, I reached a point when there is a problem, I think, with MIPI CSI-2 Rx setup. More specifically, there are no frames received from the camera. Or at least the csixss_csi_irq is not generated (the Xilinx CSI RX kernel driver should log the interrupts when dynamic debug is enabled) . More details here:

https://forums.xilinx.com/t5/Embedded-Linux/PetaLinux-Video-Pipeline-Device-Tree/td-p/899507

 

I'm not sure if my Vivado design is 100% correct, so I will try to describe is. Maybe you observe the problem.

 

Vivado Design

 

The MIPI CSI-2 Rx Subsystem looks like:

mipi-csi-2-rx-subsystem.png

 

The dphy_clk_200M is a 200 Mhz clock, while the m_axi_s2mm_aclk is a clock running @ 250 MhzThe csixss_csi_irq interrupt signal is connected to pl_ps_irq0 through a AXI Interrupt Controller. The video_out stream feeds the rest of the video pipeline (demosaic, gamma lut, csc, scaler, framebuffer write).

 

The MIPI CSI-2 Rx Sybsystem is configured as follows:

mipi-csi-2-rx-subsystem-config.png

 

 

The I/O Ports for the MIPI D-PHY are configured as:

mipi-io-ports.png

 

I'm not sure if the DIFF_TERM_ADV values are correct or not.

 

Hardware

 

On the hardware side, the clock and the two data lane signal pairs of the MIPI CSI-2 Rx are routed to the N2, M2 and N5 pins of the Bank 65 of the ZU3EG:

ultra-96-ZU3EG-bank-65-2csi.png

 

which are then routed to the High Speed Expansion connector on the Ultra96 board:

ultra-96-high-speed-connector.png

 

The Ultra 96 has a MIPI expansion board connected to it.

 

On the MIPI expansion board side the CSI (0) clock and data signals are connected to a Raspberry PI style camera connector:

mipi-extension-board-high-speed-connector.png

 

mipi-extension-board-rpi-camera-1.png

The OV5647 camera module is connected to this connector.

 

Can somebody take a look on this?

 

Thanks,

Attila

 

Tags (2)
0 Kudos
64 Replies
Xilinx Employee
Xilinx Employee
2,737 Views
Registered: ‎03-30-2016

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hello @bluetiger9

# I hope you are doing fine.

 

1. MIPI CSI-2 RX Clocks

    Please ensure that your free-run clock (dphy_clk_200M)is stable before initializing your MIPI CSI-2 RX SS.

    min frequency of video_aclk = Line-rate * Data-lanes / 32 = 600 * 2 / 32 = 37.5 MHz or higher.

 

2. Reading your ISR (Interrupt Status Register(0x24))

    It seem you have Frame synchronization errors for VC0,VC2,VC3.

    But no SoT/SoT sync error, or ECC/CRC error observed.

    -- So I believe your MIPI signal integrity has no issue,

        but your sensor timing register setting is not good, because our MIPI does not receive either FE or FS short packet.

     -- Your sensor is sending something, but I don't think they are sending Video data because

         Data Type=0x3F (reserved) is received by MIPI CSI-2 RX.

 

    Can you please ensure that your OV5647 camera module setting is okay ? Can you get some help from Omnivision on it ?

  

3. (Low Priority)
    Could you please enable D-PHY register interface and read INIT_DONE register ? (addr offset:0x18 bit[3])

    Please ensure INIT_DONE=1.

 

XF_20181022_TIGER.png

XF_20181022_TIGER_INIT_DONE.png

 

 

Thanks & regards

Leo

 

Adventurer
Adventurer
2,720 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi Leo,

 

1.

 

 

video_aclk is currently running @ 150 Mhz. Before, in the last example, it was @ 250 Mhz.
(I changed it as certain changes made in Vivado, ex. enabling the D-PHY registers, made the PetaLinux unable to boot. As this was the highest freq clock, I though this is causing the problem. See this thread)

 

Currently the video_aresetn and lite_aresetn are driven by the corresponding Processor System Reset-s. Do you thing connecting video_aresetn to a GPIO and letting the kernel driver do the reset to would help?

 

2.

 

It's kind of strange, but with the changed design the register values are different:


MIPI registers:

 

root@Ultra96:~# printf 'Core Configuration Register (0x00): ' && devmem 0x80120000 32 && printf 'Protocol Configuration Register (0x04): ' && devmem 0x80120004 32 && printf 'Core Status Register (0x10): ' && devmem 0x80120010 32 && printf 'Global Interrupt Enable Register (0x20): ' && devmem 0x80120020 32 && printf 'Interrupt Status Register (0x24): ' && devmem 0x80120024 32 && printf 'Interrupt Enable Register (0x28): ' && devmem 0x80120028 32 && printf 'Generic Short Packet Register (0x30): ' && devmem 0x80120030 32 && printf 'Clock Lane Information Register (0x3C): ' && devmem 0x8012003C 32 && printf 'Lane0 Information (0x40): ' && devmem 0x80120040 32 && printf 'Lane1 Information (0x44): ' && devmem 0x80120044 32 && printf 'Lane2 Information (0x48): ' && devmem 0x80120048 32 && printf 'Lane3 Information (0x4C): ' && devmem 0x8012004C 32 && printf 'Image Information 1 for VC0 (0x60): ' && devmem 0x80120060 32 && printf 'Image Information 2 for VC0 (0x64): ' && devmem 0x80120064 32 && printf 'Image Information 1 for VC1 (0x68): ' && devmem 0x80120068 32 && printf 'Image Information 2 for VC1 (0x6C): ' && devmem 0x8012006C 32 && printf 'Image Information 1 for VC2 (0x70): ' && devmem 0x80120070 32 && printf 'Image Information 2 for VC2 (0x74): ' && devmem 0x80120074 32 && printf 'Image Information 1 for VC3 (0x78): ' && devmem 0x80120078 32 && printf 'Image Information 2 for VC3 (0x7C): ' && devmem 0x8012007C 32
Core Configuration Register (0x00): 0x00000001
Protocol Configuration Register (0x04): 0x00000009
Core Status Register (0x10): 0x00000000
Global Interrupt Enable Register (0x20): 0x00000001
Interrupt Status Register (0x24): 0x00000000
Interrupt Enable Register (0x28): 0x803DFFFF
Generic Short Packet Register (0x30): 0x00000000
Clock Lane Information Register (0x3C): 0x00000001
Lane0 Information (0x40): 0x00000000
Lane1 Information (0x44): 0x00000000
Lane2 Information (0x48): 0x00000000
Lane3 Information (0x4C): 0x00000000
Image Information 1 for VC0 (0x60): 0x00000000
Image Information 2 for VC0 (0x64): 0x00000000
Image Information 1 for VC1 (0x68): 0x00000000
Image Information 2 for VC1 (0x6C): 0x00000000
Image Information 1 for VC2 (0x70): 0x00000000
Image Information 2 for VC2 (0x74): 0x00000000
Image Information 1 for VC3 (0x78): 0x00000000
Image Information 2 for VC3 (0x7C): 0x00000000

 

Regarding to the OV5647 settings. These are handled by the OV5647 driver. Are there any special setting needed on the MIPI part for the Xilinx MIPI CSI-2 RX Subsystem or it should work the standard / default values?

 

3.

 

Enabled the D-PHY registers. Most of the values seems to be the default ones. 

D-PHY registers:

 

 

root@Ultra96:~# printf 'CONTROL (0x00): ' && devmem 0x80130000 32 &&
> printf 'INIT (0x08): ' && devmem 0x80130008 32 &&
> printf 'HS_TIMEOUT (0x10): ' && devmem 0x80130010 32 &&
> printf 'ESC_TIMEOUT (0x14): ' && devmem 0x80130014 32 &&
> printf 'CL_STATUS (0x18): ' && devmem 0x80130018 32 &&
> printf 'DL0_STATUS (0x1C): ' && devmem 0x8013001C 32 &&
> printf 'DL1_STATUS (0x20): ' && devmem 0x80130020 32 &&
> printf 'DL2_STATUS (0x24): ' && devmem 0x80130024 32 &&
> printf 'DL3_STATUS (0x28): ' && devmem 0x80130028 32 &&
> printf 'HS_SETTLE (0x30): ' && devmem 0x80130030 32
CONTROL (0x00): 0x00000002
INIT (0x08): 0x000186A0
HS_TIMEOUT (0x10): 0x00000000
ESC_TIMEOUT (0x14): 0x00000000
CL_STATUS (0x18): 0x00000000
DL0_STATUS (0x1C): 0x00000000
DL1_STATUS (0x20): 0x00000000
DL2_STATUS (0x24): 0x00000000
DL3_STATUS (0x28): 0x00000000
HS_SETTLE (0x30): 0x00000097

 

Thanks,

Attila

 

Xilinx Employee
Xilinx Employee
2,711 Views
Registered: ‎03-30-2016

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hello Attila @bluetiger9

3. "Enabled the D-PHY registers. Most of the values seems to be the default ones."

This is not good. Your MIPI D-PHY IP shows that INIT_DONE=0 (see 0x18 bit[3] for clock lanes)(0x1C to 0x20 bit[3] for data lanes)
It means that D-PHY IP cannot complete its initialization process.
So let's focus on this one to solve your problem.

4. Could you please check that your OV5647 sensor is sending LP-11, before you start initialization process of your MIPI CSI-2 RX SS ?
   Also please ensure your OV5647 sensor is holding LP-11 for a period longer than INIT_TIME (register name is INIT_VAL with 100us as default value).
   
   Can you share your oscilloscope screenshot with us too ?
   
Many thanks
Leo

Adventurer
Adventurer
2,687 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi Leo,

 

Unfortunately, I don't have the necessary equipment to test the D-PHY.

 

But meanwhile, I did yet an another change to the design. Replaced the video_aresetn of the MIPI CSI-2 RX to a GPIO reset. Before it was generated by a Processor System Reset.

 

Now the D-PHY seems to get initialized for both the clock and data lanes:

  • CL_STATUS = 0x18 = INIT_DONE (3) | STOP_STATE (4)
  • DL0_STATUS = 0x4C = INIT DONE (3) | ULPS (2) | STOP_STATE (6)
  • DL1_STATUS = 0x48 = INIT_DONE (3) | STOP_STATE (6)
root@Ultra96:~# printf 'CONTROL (0x00): ' && devmem 0x80130000 32 && printf 'INIT (0x08): ' && devmem 0x80130008 32 && printf 'HS_TIMEOUT (0x10): ' && devmem 0x80130010 32 && printf 'ESC_TIMEOUT (0x14): ' && devmem 0x80130014 32 && printf 'CL_STATUS (0x18): ' && devmem 0x80130018 32 && printf 'DL0_STATUS (0x1C): ' && devmem 0x8013001C 32 && printf 'DL1_STATUS (0x20): ' && devmem 0x80130020 32 && printf 'DL2_STATUS (0x24): ' && devmem 0x80130024 32 && printf 'DL3_STATUS (0x28): ' && devmem 0x80130028 32 && printf 'HS_SETTLE (0x30): ' && devmem 0x80130030 32
CONTROL (0x00): 0x00000002
INIT (0x08): 0x000186A0
HS_TIMEOUT (0x10): 0x00000000
ESC_TIMEOUT (0x14): 0x00000000
CL_STATUS (0x18): 0x00000018
DL0_STATUS (0x1C): 0x0000004C
DL1_STATUS (0x20): 0x00000048
DL2_STATUS (0x24): 0x0000000A
DL3_STATUS (0x28): 0x0000000A
HS_SETTLE (0x30): 0x00000097

The Core Registers looks like:

root@Ultra96:~# printf 'Core Configuration Register (0x00): ' && devmem 0x80120000 32 && printf 'Protocol Configuration Register (0x04): ' && devmem 0x80120004 32 && printf 'Core Status Register (0x10): ' && devmem 0x80120010 32 && printf 'Global Interrupt Enable Register (0x20): ' && devmem 0x80120020 32 && printf 'Interrupt Status Register (0x24): ' && devmem 0x80120024 32 && printf 'Interrupt Enable Register (0x28): ' && devmem 0x80120028 32 && printf 'Generic Short Packet Register (0x30): ' && devmem 0x80120030 32 && printf 'Clock Lane Information Register (0x3C): ' && devmem 0x8012003C 32 && printf 'Lane0 Information (0x40): ' && devmem 0x80120040 32 && printf 'Lane1 Information (0x44): ' && devmem 0x80120044 32 && printf 'Lane2 Information (0x48): ' && devmem 0x80120048 32 && printf 'Lane3 Information (0x4C): ' && devmem 0x8012004C 32 && printf 'Image Information 1 for VC0 (0x60): ' && devmem 0x80120060 32 && printf 'Image Information 2 for VC0 (0x64): ' && devmem 0x80120064 32 && printf 'Image Information 1 for VC1 (0x68): ' && devmem 0x80120068 32 && printf 'Image Information 2 for VC1 (0x6C): ' && devmem 0x8012006C 32 && printf 'Image Information 1 for VC2 (0x70): ' && devmem 0x80120070 32 && printf 'Image Information 2 for VC2 (0x74): ' && devmem 0x80120074 32 && printf 'Image Information 1 for VC3 (0x78): ' && devmem 0x80120078 32 && printf 'Image Information 2 for VC3 (0x7C): ' && devmem 0x8012007C 32
Core Configuration Register (0x00): 0x803B0001
Protocol Configuration Register (0x04): 0x803B0009
Core Status Register (0x10): 0x803B0000
Global Interrupt Enable Register (0x20): 0x803B0001
Interrupt Status Register (0x24): 0x803B0000
Interrupt Enable Register (0x28): 0x803BC03F
Generic Short Packet Register (0x30): 0x803B0000
Clock Lane Information Register (0x3C): 0x803B0001
Lane0 Information (0x40): 0x803B0020
Lane1 Information (0x44): 0x803B0020
Lane2 Information (0x48): 0x803B0000
Lane3 Information (0x4C): 0x803B0000
Image Information 1 for VC0 (0x60): 0x803B0000
Image Information 2 for VC0 (0x64): 0x803B0000
Image Information 1 for VC1 (0x68): 0x807B0000
Image Information 2 for VC1 (0x6C): 0x803B0000
Image Information 1 for VC2 (0x70): 0x803B0000
Image Information 2 for VC2 (0x74): 0x803B0000
Image Information 1 for VC3 (0x78): 0x803B0000
Image Information 2 for VC3 (0x7C): 0x803B0000
  • the Interrupt Status Register (0x24) look a little bit strange
    0c803B0000 = Stop state (17) | Short packet FIFO not empty (19) | Short packet FIFO full (20) | Incorrect lane configuration (21) | Frame Received (31)

    especially the Incorrect lane configuration (21) part:
    > Asserted when Active lanes is greater than Maximum lanes in the protocol configuration register

    In the Protocol Configuration Register both the Maximum and Active lanes are set to 2

Thanks,

Attila

 

Xilinx Employee
Xilinx Employee
2,661 Views
Registered: ‎03-30-2016

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hello Attila @bluetiger9

# Thank you for updating your status.

 

    All clock and data lanes have been successfully initialized.

    Congratulation you have reached the start point !

 

    But, it seems your data lane0 is in ULPS mode. This is not expected.

    To help you on this, I do need to see your waveform (oscilloscope srceen capture).

    You do not need an expensive oscilloscope at this point.

 

    You need to ensure that  MIPI CSI-2 RX start initialization with clock/data lanes at LP-11.

    Your sensors need to hold this LP-11 condition more than INIT_TIME ( or at least until MIPI CSI-2 RX clock/data lanes asserted INIT_DONE )
    Please let me know if your hardware can meet this condition.

 

    For now, I suspected that your sensor is sending non-LP-11 ( perhaps Hi-Z  or some noise ) condition,

    that might trigger our MIPI CSI-2 RX to enter ULPS condition.

 

Many thanks

Leo

0 Kudos
Explorer
Explorer
2,642 Views
Registered: ‎10-21-2015

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi 

The bank(BANK65) voltage for ultra96 csi pins  is 1.2V.

Is there no problem in  level shifting to camera signals ?

I doubt whether the adapter board supports 1.2V level shifting.

The other 96 boards, which the adapter board support, seems to use 1.5V for mipi csi

 

Adventurer
Adventurer
2,626 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi @hokim,


The OV5647 module works with the standard D-PHY voltage levels (1.2V in LP mode). The I2C interface uses with 3.3V signals, but there is a level shifter on the expansion board that does the shifting between the 1.8V and 3.3V voltage levels.

Thanks,
Attila

Explorer
Explorer
2,522 Views
Registered: ‎10-21-2015

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

0 Kudos
2,496 Views
Registered: ‎09-30-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Have you tried Leopard Imaging IMX274 with I-PEX connector?  Xilinx MIPI reference design for ZCU102 uses Leopard Imaging IMX274 with FMC connector, but IMX274 driver should be similar.

Many users of Nvidia Jetson TX1/TX2 reported the OV5647 driver in Linux kernel did not work and they had to make changes to the OV5647 driver to make it work.

I got the 96board MIPI adapter for OV5647 and IMX274 and will start to port ZCU102 MIPI design to Ultra96.  If you could share your Ultra96 design, I could try it using my IMX274 cameras.     

0 Kudos
Adventurer
Adventurer
2,408 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi Eric,

 

Did not tried IMX274 module. I want to use two cameras, so the $249 unit price would be a little bit too much :D.

 

Meantime, I did some more investigation and I found that that the Xilinx Video pipeline Linux driver did not called the s_power function of the V4L2 sub-device drivers. This function should be called from the file handler of the /dev/video0 on file open and close. In the OV5647 driver, this does some initialization and sets the output enable registers.

 

I patched the kernel to call s_power method, but this caused the system to reboot when the s_power of OV5647 is called. After some debugging it turned out, that reboot happens when the bits from the io_y_oen[11:8] and io_y_oen[7:0] registers of the OV5647 are set. The OV5647 datasheet does not specifies exactly what these registers exactly are, but I believe this are output enable registers for the MIPI CSI-2 + data pins.

 

I tried to set the registers bit by bit and I identified the bits that can be set without crash / reboot and the bits which causes crash / reboot. I patched the OV5647 driver to do not set the bits (there are 5 them I think) that causes reboot.

 

The current behaviour is that, I have LP11 on the two data lanes, but the clock lane is LP00 or not enabled. I not sure if it is not enabled (as we don't know which bits of io_y_oen[11:0] correspond to the MIPI clock lanes) or is some other register that is not correctly set.

 

I will try to check with an oscilloscope if there any activity on the clock lane when setting the problematic io_y_oen bits. Maybe it's some weird signal that causes the ZYNQ+ to crash.

 

Thanks,

Attila

 

 

0 Kudos
2,399 Views
Registered: ‎09-30-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

All GPIOs and I2Cs for OV5647 could be done in user space without kernel driver. I have tried when I got the 96board MIPI adapter.

0 Kudos
Adventurer
Adventurer
2,389 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Why do you want to do the I2C part from user space?

I thinks it is OK for debugging, but for normal use the sensor should be added in the Device Tree and then we should let the driver do its job:

&i2csw_2 {
    ov5647_0: camera@36 {
        compatible = "ovti,ov5647";
        reg = <0x36>;
        clocks = <&cam_clk>;
        status = "okay";

        port {
            ov5647_0_to_mipi_csi2_rx_0: endpoint {
                remote-endpoint = <&mipi_csi2_rx_0_from_ov5647_0>;
                clock-lanes = <0>;
                data-lanes = <1 2>;
            };
        };
    };
};

 

 

0 Kudos
2,379 Views
Registered: ‎09-30-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

I understand that.  The kernel driver needs to send register table to camera, there are many registers and many bits, it'd need to rebuild kernel every time for register bit change during debug.  The same table could be modified and sent from user space without rebuild kernel.

The same for GPIOs, I tried different GPIO numbers to verify which GPIO number are for OV5647.  Wrong GPIO number in kernel could crash CPU.

0 Kudos
Adventurer
Adventurer
2,372 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi,

eric.liu@baesystems.com, I understood it now. Thanks!

@hokim, thanks for the links. At the first glance the OV5647 kernel drivers are based on that work. I will take a closer look on the discussions too a little bit later. Maybe we found some relevant info there.

 

@karnanl, as I mentioned in the previous post, there a problem in the XIlinx Video Pipeline driver. I fixed it, but after this the system keeps rebooting.

Basically, there are two io_y_oen[11:8] (addr 0x3000) and io_y[7:0] (addr 0x3001) I2C registers. The OV5647 datasheet is unclear on what these exactly does, but I think these are output enable register for the MIPI + data pins. The kernel driver sets these registers on power on (when /dev/video0 is opened). The original version sets all the bits: 0x3000=0x0f, 0x3001=0xff, but this configuration causes the Ultra96 to immediately reboot after the 1st register is set.

 

I tried to set the bits one-by-one and I ended up with a relatively stable configuration: 0x3000=0x0c, 0x3001=0x1f (7 pins from 12). (sometimes, the 5th bit, the 0x1 part, from 0x3001 also causes instability)

 

I modified the kernel driver to use the new values. After this the system (usually) boots successfully. 

 

I tried to capture some signal with an oscilloscope. When the V4L2 streaming is turned ON, I see this:

 

Data Lane 0:

  • neg:

dl0-n.png

  • pos:

dl0-p.png

 

Data Lane 1:

  • neg

dl1-n.png

  • pos

dl1-p.png

 

Clock Lane:

  • pos

clk-n.png

  • neg

clk-p.png

 

On the Data Lanes there is some communication (~0-1.5V, so it's low power mode, I think). The Clock Lane is ~0.25V on both the negative an positive wires. Is this LP-00?

 

The MIPI and D-PHY registers look like:

 

root@Ultra96:~# printf 'Core Configuration Register (0x00): ' && devmem 0x80120000 32 && printf 'Protocol Configuration Register (0x04): ' && devmem 0x80120004 32 && printf 'Core Status Register (0x10): ' && devmem 0x80120010 32 && printf 'Global Interrupt Enable Register (0x20): ' && devmem 0x80120020 32 && printf 'Interrupt Status Register (0x24): ' && devmem 0x80120024 32 && printf 'Interrupt Enable Register (0x28): ' && devmem 0x80120028 32 && printf 'Generic Short Packet Register (0x30): ' && devmem 0x80120030 32 && printf 'Clock Lane Information Register (0x3C): ' && devmem 0x8012003C 32 && printf 'Lane0 Information (0x40): ' && devmem 0x80120040 32 && printf 'Lane1 Information (0x44): ' && devmem 0x80120044 32 && printf 'Lane2 Information (0x48): ' && devmem 0x80120048 32 && printf 'Lane3 Information (0x4C): ' && devmem 0x8012004C 32 && printf 'Image Information 1 for VC0 (0x60): ' && devmem 0x80120060 32 && printf 'Image Information 2 for VC0 (0x64): ' && devmem 0x80120064 32 && printf 'Image Information 1 for VC1 (0x68): ' && devmem 0x80120068 32 && printf 'Image Information 2 for VC1 (0x6C): ' && devmem 0x8012006C 32 && printf 'Image Information 1 for VC2 (0x70): ' && devmem 0x80120070 32 && printf 'Image Information 2 for VC2 (0x74): ' && devmem 0x80120074 32 && printf 'Image Information 1 for VC3 (0x78): ' && devmem 0x80120078 32 && printf 'Image Information 2 for VC3 (0x7C): ' && devmem 0x8012007C 32
Core Configuration Register (0x00): 0x803B0001
Protocol Configuration Register (0x04): 0x803B0009
Core Status Register (0x10): 0x807B0000
Global Interrupt Enable Register (0x20): 0x803B0001
Interrupt Status Register (0x24): 0x803B0000
Interrupt Enable Register (0x28): 0x803BC03F
Generic Short Packet Register (0x30): 0x803B0000
Clock Lane Information Register (0x3C): 0x803B0001
Lane0 Information (0x40): 0x803B0000
Lane1 Information (0x44): 0x803B0020
Lane2 Information (0x48): 0x803B0000
Lane3 Information (0x4C): 0x803B0000
Image Information 1 for VC0 (0x60): 0x803B0000
Image Information 2 for VC0 (0x64): 0x803B0000
Image Information 1 for VC1 (0x68): 0x807B0000
Image Information 2 for VC1 (0x6C): 0x803B0000
Image Information 1 for VC2 (0x70): 0x803B0000
Image Information 2 for VC2 (0x74): 0x803B0000
Image Information 1 for VC3 (0x78): 0x803B0000
Image Information 2 for VC3 (0x7C): 0x803B0000


root@Ultra96:~# printf 'CONTROL (0x00): ' && devmem 0x80130000 32 && printf 'INIT (0x08): ' && devmem 0x80130008 32 && printf 'HS_TIMEOUT (0x10): ' && devmem 0x80130010 32 && printf 'ESC_TIMEOUT (0x14): ' && devmem 0x80130014 32 && printf 'CL_STATUS (0x18): ' && devmem 0x80130018 32 && printf 'DL0_STATUS (0x1C): ' && devmem 0x8013001C 32 && printf 'DL1_STATUS (0x20): ' && devmem 0x80130020 32 && printf 'DL2_STATUS (0x24): ' && devmem 0x80130024 32 && printf 'DL3_STATUS (0x28): ' && devmem 0x80130028 32 && printf 'HS_SETTLE (0x30): ' && devmem 0x80130030 32
CONTROL (0x00): 0x00000002
INIT (0x08): 0x000186A0
HS_TIMEOUT (0x10): 0x00000000
ESC_TIMEOUT (0x14): 0x00000000
CL_STATUS (0x18): 0x00000009
DL0_STATUS (0x1C): 0xC6C1000D
DL1_STATUS (0x20): 0xC7020048
DL2_STATUS (0x24): 0x0000000A
DL3_STATUS (0x28): 0x0000000A
HS_SETTLE (0x30): 0x00000097

(note: the packet count from DL0_STATUS and DL1_STATUS is increasing, so I think communication on the data lanes works)

 

 

Also, tried so see if there is any activity (which could cause the reboot) on the clock lane, when setting the problematic bits. I did no observed anything strange (just 0.25V -> high-z, when the system reboots).

 

I think, first we should figure out what causes this reboots. It does not seems to be a kernel panic. I think the SoC detects some hardware problem and resets itself. What do you think?

 

Thanks,

Attila

2,364 Views
Registered: ‎09-30-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Attached are OV5647 driver files from Nvidia L4T kernel source.  There are commends in register table about enable MIPI lanes.

2,363 Views
Registered: ‎09-30-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Attached are I2C transactions between Raspberry Pi and OV5647 captured using I2C analyzer for reference.  

Adventurer
Adventurer
2,352 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

These will be usefully, I think. The 0x3000 and 0x3001 are both set to 0x00. The are some comments that suggests that these are just for parallel communication:

//Pad Control
{0x3000, 0x00}, /* Disable Parallel Pads */
{0x3001, 0x00}, /* Disable Parallel Pads */
{0x3002, 0x00}, /* PAD Enables... all disabled */

so probably they are not needed for MIPI. I will try disabling them tomorrow. Hopefully, we will get rid of the instability and still get some communication on the 2 data lanes.

 

There seems to be other differences too. I will take a closer look tomorrow.

Thanks!

Explorer
Explorer
2,338 Views
Registered: ‎10-21-2015

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Alternatively, how about using digilent's pcam5c?

https://store.digilentinc.com/pcam-5c-5-mp-fixed-focus-color-camera-module/

 

These are vivado project and devicetree

https://github.com/Digilent/Zybo-Z7-20-base-linux

https://github.com/Digilent/Petalinux-Zybo-Z7-20/blob/master/Zybo-Z7-20/project-spec/meta-user/recipes-bsp/device-tree/files/system-user.dtsi

 

They use their own kernel for driver.

Yesterday, I wrote patches for xilinx kernel v2018.2

They are attached

They work well in zybo z7 

 

I will try them with  ultra96 board after the adapter board arrives

 

 

Xilinx Employee
Xilinx Employee
2,326 Views
Registered: ‎03-30-2016

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hello all, Hello Attila @bluetiger9

- Looking at your MIPI IPs register dump.
It seems that all Clock & data lanes indicated INIT_DONE. This is good.
Your data lanes packet counter is increased. It means you received something
But I do not have any clue at this point if this is a correct packet or not.
Please note that data lane0 in the ULPS (Ultra Low Power State) , which is not an expected state.

- Looking at your oscilloscope capture.
(a) Data lanes output swing is 1.5V !!
     So I think your sensor output I/F is not in MIPI mode. Even in LP mode typical output swing should be 1.2V
      EC_for_Bhushan.png
This sensor has two modes of output I/F. (DVP I/F & MIPI I/F). I believe you are using DVP I/F right now.
Could you please fix this ? Did you set the register address (0x4800--0x4865)  of your OV5647 sensor correctly ?

(b) Both clock P/N lanes are less than 50mV so MIPI CSI-2 RX could interpret it as LP-00.
    But the Clock lane is fixed at LP-00. Xilinx MIPI CSI-2 RX IP will not work.

Thanks & regards
Leo

0 Kudos
Xilinx Employee
Xilinx Employee
2,475 Views
Registered: ‎03-30-2016

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hello @bluetiger9

 

You might also need to set address (0x3016~0x3022) OV5647 register correctly to use sensor MIPI output mode.

 

XF_OMNI_SENSOR.png

Thanks
Leo

Adventurer
Adventurer
2,444 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi @karnanl,

 

The double checked and the voltage levels are 1.2V (measured in LP-11 mode).

 

The OV5647 register are:

  • SC_CMMN_MIPI_PHY (0x3016) is 0x08, bit[3]: mipi_pad_enable
  • SC_CMMN_MIPI_PHY (0x3017) is 0xE0, bit[7:6]: high speed mode common voltage, bit[5:4] driving stregth of low speed transmitter
    • default value is 0x10, setting this reduces by ~0.125V the voltages on the data / clock lanes
  • SC_CMNN_MIPI_SC_CTRL (0x3018) is 0x44, bit[2] - mipi_en, bit[7:5]

  • MIPI CTRL 00 (0x4800) is 0x04 when streaming - bit[2]: LP11 when no packets to transmit
  • MIPI CTRL 00 (0x4800) is 0x25 when the streaming is turned off - bit[0]: manually set LP mode, bit[2]: LP11 when no packets to transmit, bit[5]: gate clock lane when no packets to transmit
    • LP11 is visible on the clock lane in this state
  • PCLK_PERIOD (0x4837) is 0x24

Please, note that when the OV5647 sensor is not used (/dev/video0 is not used), the sensor is put in stand by mode (0x0100 = 0x00). This disables all the outputs, until the next use. Could this be a problem for the MIPI RX Subsystem.

 

Thanks,

Attila

 

 

Xilinx Employee
Xilinx Employee
2,432 Views
Registered: ‎03-30-2016

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hello Attila @bluetiger9

I've never use OV5647 sensor myself.
Could you please contact Omnivision support for sensor setting confirmation ? I cannot help you much on this.

>MIPI CTRL 00 (0x4800) is 0x04 when streaming - bit[2]: LP11 when no packets to transmit

I think it should be okay.
But your oscilloscope screenshot reported that clock lanes is LP-00, when you send video data streaming.
Is it still the same behavior ?

>MIPI CTRL 00 (0x4800) is 0x25 when the streaming is turned off - bit[0]: manually set LP mode, bit[2]: LP11 when no packets to transmit,
>bit[5]: gate clock lane when no packets to transmit. LP11 is visible on the clock lane in this state

Clock lane == LP-11 is okay.
Is your data lane showing the same behavior ?

>Please, note that when the OV5647 sensor is not used (/dev/video0 is not used), the sensor is put in stand by mode (0x0100 = 0x00).
>This disables all the outputs, until the next use. Could this be a problem for the MIPI RX Subsystem.

When you put sensor in Standby mode, what is the status of MIPI clock/data lanes ??
Is it LP-11 ?, Hi-Z (electrical idle) ?? or LP-00 ?

Could you please confirm that you start Xilinx MIPI CSI-2 RX IP initizalition , only after you see LP-11 on both clock/data lanes ?
If you are not sure about sensor output behavior during standby mode, please re-initialize MIPI CSI-2 RX IP.

Thanks & regards
Leo

0 Kudos
Adventurer
Adventurer
2,402 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi @karnanl

 

In stand by mode the outputs of the OV5647 are disabled (high-Z).

 

Checked the MIPI CSI-2 Rx kernel driver code and there is a soft reset issued at stream ON. When this happens the OV5647 is powered, and the clock lane is LP-11 (0x4800 is 0x25) . Only after this the streaming is turned on the OV5647. The 0x4800 register is set to 0x04 and this causes causes that ~0.2V signals on the clock lane. However the 0x04 register value seems to be incorrect. Setting it to 0x34 produces this:

Screenshot from 2018-11-01 20-39-15.png

which is about the same waveform as with the OV5647 module connected to a Raspberry Pi. I will update the kernel driver and come back with more details.

---

Update:

 

Recompiled the kernel and on D-PHY level, I think, we have what we need. These are the D-PHY Registers (took multiple samples):

 

CONTROL (0x00): 0x00000002
INIT (0x08): 0x000186A0
HS_TIMEOUT (0x10): 0x00000000
ESC_TIMEOUT (0x14): 0x00000000
CL_STATUS (0x18): 0x00000018 (stop state), sometimes 0x00000009 (HS mode)
DL0_STATUS (0x1C): 0xF8D0004C (ULPS mode + stop state), sometimes 0x_____00C (ULPS mode) and 0x_____00D (Escape mode)
DL1_STATUS (0x20): 0xF8D10048 (LP mode + stop state), sometimes 0x_____009 (HS mode)
DL2_STATUS (0x24): 0x0000000A
DL3_STATUS (0x28): 0x0000000A
HS_SETTLE (0x30): 0x00000097

 

(looks like the lanes are hopping between the states, which I think is expected as if I understood correctly there should be LP traffic between the HS mode images frames)

 

On the other hand the MIPI part looks very strange:

  • registers
    Core Configuration Register (0x00): 0x803B0001
    Protocol Configuration Register (0x04): 0x803B0009
    Core Status Register (0x10): 0x803B0000
    Global Interrupt Enable Register (0x20): 0x803B0001
    Interrupt Status Register (0x24): 0x803B0000  
    Interrupt Enable Register (0x28): 0x803BC03F
    Generic Short Packet Register (0x30): 0x803B0000
    Clock Lane Information Register (0x3C): 0x803B0001
    Lane0 Information (0x40): 0x803B0020
    Lane1 Information (0x44): 0x803B0020
    Lane2 Information (0x48): 0x803B0000
    Lane3 Information (0x4C): 0x803B0000
    Image Information 1 for VC0 (0x60): 0x803B0000
    Image Information 2 for VC0 (0x64): 0x803B0000
    Image Information 1 for VC1 (0x68): 0x807B0000
    Image Information 2 for VC1 (0x6C): 0x803B0000
    Image Information 1 for VC2 (0x70): 0x803B0000
    Image Information 2 for VC2 (0x74): 0x803B0000
    Image Information 1 for VC3 (0x78): 0x807B0000
    Image Information 2 for VC3 (0x7C): 0x803B0000
    (note that there are inconsistencies between the register)

  • V4L2 driver status log:
Status Log:

   [ 3053.356094] 80120000.mipi_csi2_rx_subsystem: =================  START STATUS  =================
(event counters > 0 should be printed here !) [ 3053.364727] 80120000.mipi_csi2_rx_subsystem: ***** Core Status ***** [ 3053.371060] 80120000.mipi_csi2_rx_subsystem: Short Packet FIFO Full = false [ 3053.377996] 80120000.mipi_csi2_rx_subsystem: Short Packet FIFO Not Empty = false [ 3053.385375] 80120000.mipi_csi2_rx_subsystem: Stream line buffer full = false [ 3053.392405] 80120000.mipi_csi2_rx_subsystem: Soft reset/Core disable in progress = false [ 3053.400479] 80120000.mipi_csi2_rx_subsystem: ******** Clock Lane Info ********* [ 3053.407767] 80120000.mipi_csi2_rx_subsystem: Clock Lane in Stop State = false [ 3053.414886] 80120000.mipi_csi2_rx_subsystem: ******** Data Lane Info ********* [ 3053.422089] 80120000.mipi_csi2_rx_subsystem: Lane SoT Error SoT Sync Error Stop State [ 3053.429904] 80120000.mipi_csi2_rx_subsystem: 0 false false true [ 3053.435979] 80120000.mipi_csi2_rx_subsystem: 1 false false true [ 3053.442056] 80120000.mipi_csi2_rx_subsystem: 2 false false false [ 3053.448217] 80120000.mipi_csi2_rx_subsystem: 3 false false false [ 3053.454386] 80120000.mipi_csi2_rx_subsystem: ********** Virtual Channel Info ************ [ 3053.462540] 80120000.mipi_csi2_rx_subsystem: VC Line Count Byte Count Data Type [ 3053.469836] 80120000.mipi_csi2_rx_subsystem: 0 32827 0 (null) [ 3053.475735] 80120000.mipi_csi2_rx_subsystem: 1 32891 0 (null) [ 3053.481640] 80120000.mipi_csi2_rx_subsystem: 2 32891 0 (null) [ 3053.487539] 80120000.mipi_csi2_rx_subsystem: 3 32891 0 (null) [ 3053.493441] 80120000.mipi_csi2_rx_subsystem: ================== END STATUS ==================

 

  •  note that the event counters are all 0 - this none of the following events was triggered:

 

static struct xcsi2rxss_event xcsi2rxss_events[] = {
	{ XCSI_ISR_FR_MASK, "Frame Received", 0 },
	{ XCSI_ISR_ILC_MASK, "Invalid Lane Count Error", 0 },
	{ XCSI_ISR_SPFIFOF_MASK, "Short Packet FIFO OverFlow Error", 0 },
	{ XCSI_ISR_SPFIFONE_MASK, "Short Packet FIFO Not Empty", 0 },
	{ XCSI_ISR_SLBF_MASK, "Streamline Buffer Full Error", 0 },
	{ XCSI_ISR_STOP_MASK, "Lane Stop State", 0 },
	{ XCSI_ISR_SOTERR_MASK, "SOT Error", 0 },
	{ XCSI_ISR_SOTSYNCERR_MASK, "SOT Sync Error", 0 },
	{ XCSI_ISR_ECC2BERR_MASK, "2 Bit ECC Unrecoverable Error", 0 },
	{ XCSI_ISR_ECC1BERR_MASK, "1 Bit ECC Recoverable Error", 0 },
	{ XCSI_ISR_CRCERR_MASK,	"CRC Error", 0 },
	{ XCSI_ISR_DATAIDERR_MASK, "Data Id Error", 0 },
	{ XCSI_ISR_VC3FSYNCERR_MASK, "Virtual Channel 3 Frame Sync Error", 0 },
	{ XCSI_ISR_VC3FLVLERR_MASK, "Virtual Channel 3 Frame Level Error", 0 },
	{ XCSI_ISR_VC2FSYNCERR_MASK, "Virtual Channel 2 Frame Sync Error", 0 },
	{ XCSI_ISR_VC2FLVLERR_MASK, "Virtual Channel 2 Frame Level Error", 0 },
	{ XCSI_ISR_VC1FSYNCERR_MASK, "Virtual Channel 1 Frame Sync Error", 0 },
	{ XCSI_ISR_VC1FLVLERR_MASK, "Virtual Channel 1 Frame Level Error", 0 },
	{ XCSI_ISR_VC0FSYNCERR_MASK, "Virtual Channel 0 Frame Sync Error", 0 },
	{ XCSI_ISR_VC0FLVLERR_MASK, "Virtual Channel 0 Frame Level Error", 0 }
};

 

The MIPI CSI-2 Rx Subsystem seems to be in an inconsistent state. What could cause this?

 

Thanks,

Attila

0 Kudos
Xilinx Employee
Xilinx Employee
2,390 Views
Registered: ‎03-30-2016

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hello Attila @bluetiger9

Thanks for fixing the OV5647 sensor setting.

>CL_STATUS (0x18): 0x00000018 (stop state), sometimes 0x00000009 (HS mode)

MIPI D-PHY IP has received the clock. This is good.

>DL1_STATUS (0x20): 0xF8D10048 (LP mode + stop state), sometimes 0x_____009 (HS mode)

No issue on this. Expected behavior.

>DL0_STATUS (0x1C): 0xF8D0004C (ULPS mode + stop state), sometimes 0x_____00C (ULPS mode) and 0x_____00D (Escape mode)

It is jumping between Escape mode & ULPS, which is not good. Something wrong here.

>Lane0 Information (0x40): 0x803B0020
>Lane1 Information (0x44): 0x803B0020

Your MIPI CSI-2 Rx Subsystem register dump shows that lane0 & lane1 is in Stop-state.
I believe 0x40 always shows (0x******20) but, (0x44) is toggling between ( 0x******00) <--> (0x******20)


>The MIPI CSI-2 Rx Subsystem seems to be in an inconsistent state. What could cause this?

Because data_lane[0] is not working correctly.
At his point, I suspected something wrong on data_lane[0] connectivity. So, could you please
   (a) check physical connectivity on your board.
   (b) compare lane[0] & lane[1] signal behavior. (More high-precision oscilloscope might help)

Thanks & regards
Leo

0 Kudos
Adventurer
Adventurer
2,378 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi @karnanl,

 

I'm not yet sure if the the data lane [0] is not working or I just not caught enough register samples to see the lane in HS mode:

d-phy-slave-states.png

 

My Tuesday post shows 0x40 = 0x803B0000 for Lane 0:

Lane0 Information (0x40): 0x803B0000
Lane1 Information (0x44): 0x803B0020

I will make a script to record much more register samples (both d-phy and mipi). After this, we should see more clearly what happens.

 

Regarding to the MIPI registers, there are some inconsistencies which does not really makes sense:

  • Interrupt Status Register (0x24) = 803B0000
    (binary 1000 0000 0011 1011 0000 0000 0000 0000)

    Bits set:
    16 - reserved
    17 - Stop state
    19 - Short packet FIFO not empty
    20 - Short packet FIFO full
    21 - Incorrect lane configuration - Asserted when Active lanes is greater than Maximum lanes in the protocol configuration register
    31 - Frame Received

  • Core Status Register (0x10)0x803B0000
    (binary 1000 0000 0011 1011 0000 0000 0000 0000)

    Bits NOT set, but should be:
    2 - Short packet FIFO not empty
    3 - Short packet FIFO Full

  • Protocol Configuration Register (0x04) = 0x803B0009
    (binary 1000 0000 0011 1011 0000 0000 0000 1001)

    Values:
    1-0 - Active Lanes - 0x1 = 2 Lanes
    4-3 - Maximum Lanes - 0x1 = 2 Lanes

What do you think?

Thanks,

Attila

Adventurer
Adventurer
2,356 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Hi @karnanl,

 

Yesterday, looking at the kernel driver xilinx-csi2rxss.cs, I observed that the reset-gpio DT property is not used. So, today I moved back the reset of the MIPI CSI-2 RX Subsystem to use the Processor System Reset.

 

Also, I made the script to collect more register samples. Bellow are the unique values from about ~350 samples:

 

MIPI registers:

 

Core Configuration Register (0x00): 0x00000001
Protocol Configuration Register (0x04): 0x00000009
Core Status Register (0x10): 0x00600000, 0x00800000, 0x00B50000, 0x02110000, ...
Global Interrupt Enable Register (0x20): 0x00000001
Interrupt Status Register (0x24): 0x80020000
Interrupt Enable Register (0x28): 0x803DFFFF
Generic Short Packet Register (0x30): 0x00000000
Clock Lane Information Register (0x3C): 0x00000001, 0x00000003
Lane0 Information (0x40): 0x00000000, 0x00000020
Lane1 Information (0x44): 0x00000000, 0x00000020
Lane2 Information (0x48): 0x00000000
Lane3 Information (0x4C): 0x00000000
Image Information 1 for VC0 (0x60): 0x00B10280, 0x01200280, 0x01590280, ...
Image Information 2 for VC0 (0x64): 0x0000002A
Image Information 1 for VC1 (0x68): 0x00000000
Image Information 2 for VC1 (0x6C): 0x00000000
Image Information 1 for VC2 (0x70): 0x00000000
Image Information 2 for VC2 (0x74): 0x00000000
Image Information 1 for VC3 (0x78): 0x00000000
Image Information 2 for VC3 (0x7C): 0x00000000

 

 

D-PHY registers:

 

CONTROL (0x00): 0x00000002
INIT (0x08): 0x000186A0
HS_TIMEOUT (0x10): 0x00000000
ESC_TIMEOUT (0x14): 0x00000000
CL_STATUS (0x18): 0x00000018, 0x00000009, 0x00000008
DL0_STATUS (0x1C): = 0x____0048, 0x____0009, 0x____0008
DL1_STATUS (0x20): = 0x____0048, 0x____0009, 0x____0008 
DL2_STATUS (0x24): 0x00000008
DL3_STATUS (0x28): 0x00000008

 

What we can observe from these is:

  • both the data lanes (0 & 1) have the same behaviour and seems to work correctly
  • the inconsistencies from the MIPI registers are gone - I think the culprit here was the (unused) GPIO reset
  • according to the Image Information, there is image data received
  • the Interrupt Status Register are not cleared - the kernel driver does not receives interrupts, so doesn't tries to clear the status registers. This is confirmed by the kernel log too.

The driver debug log looks like:

root@Ultra96:~# v4l2-dbg -d /dev/v4l-subdev1 --log-status

Status Log:

   [ 4870.437967] 80120000.mipi_csi2_rx_subsystem: =================  START STATUS  =================
   [ 4870.446598] 80120000.mipi_csi2_rx_subsystem: ***** Core Status *****
   [ 4870.452934] 80120000.mipi_csi2_rx_subsystem: Short Packet FIFO Full = false
   [ 4870.459868] 80120000.mipi_csi2_rx_subsystem: Short Packet FIFO Not Empty = false
   [ 4870.467247] 80120000.mipi_csi2_rx_subsystem: Stream line buffer full = false
   [ 4870.474277] 80120000.mipi_csi2_rx_subsystem: Soft reset/Core disable in progress = false
   [ 4870.482350] 80120000.mipi_csi2_rx_subsystem: ******** Clock Lane Info *********
   [ 4870.489640] 80120000.mipi_csi2_rx_subsystem: Clock Lane in Stop State = true
   [ 4870.496672] 80120000.mipi_csi2_rx_subsystem: ******** Data Lane Info *********
   [ 4870.503875] 80120000.mipi_csi2_rx_subsystem: Lane SoT Error       SoT Sync Error  Stop State
   [ 4870.511689] 80120000.mipi_csi2_rx_subsystem: 0    false           false           true
   [ 4870.517764] 80120000.mipi_csi2_rx_subsystem: 1    false           false           true
   [ 4870.523841] 80120000.mipi_csi2_rx_subsystem: 2    false           false           false
   [ 4870.530003] 80120000.mipi_csi2_rx_subsystem: 3    false           false           false
   [ 4870.536166] 80120000.mipi_csi2_rx_subsystem: ********** Virtual Channel Info ************
   [ 4870.544328] 80120000.mipi_csi2_rx_subsystem: VC   Line Count      Byte Count      Data Type
   [ 4870.551622] 80120000.mipi_csi2_rx_subsystem: 0    36161           640             RAW8
   [ 4870.557522] 80120000.mipi_csi2_rx_subsystem: 1    0               0               (null)
   [ 4870.563079] 80120000.mipi_csi2_rx_subsystem: 2    0               0               (null)
   [ 4870.568630] 80120000.mipi_csi2_rx_subsystem: 3    0               0               (null)
   [ 4870.574186] 80120000.mipi_csi2_rx_subsystem: ==================  END STATUS  ==================

and shows NO events.

 


My interrupt setup looks like:

 

intr.png

Screenshot from 2018-11-02 21-55-09.png

 

In the device tree we have:

                interrupt-controller@80010000 {
                        #interrupt-cells = <0x2>;
                        compatible = "xlnx,xps-intc-1.00.a";
                        interrupt-controller;
                        reg = <0x0 0x80010000 0x0 0x1000>;
                        xlnx,kind-of-intr = <0x0>;
                        xlnx,num-intr-inputs = <0x2>;
                        linux,phandle = <0x45>;
                        phandle = <0x45>;
                };

The kernel log show the that the interrupts are successfully enabled:

[    0.000000] irq-xilinx: /amba_pl@0/interrupt-controller@80010000: num_irq=2, edge=0x0
...
[    1.433484] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: DPHY present property = Present
[    1.433503] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: IIC present property = Absent
[    1.433527] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: Enable active lanes property = Absent
[    1.433550] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: Video Format Bridge property = Present
[    1.433583] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: xcsi2rxss_parse_of : port 0 bus type = 1
[    1.433598] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: xcsi2rxss_parse_of : Not a CSI2 bus
[    1.433620] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: xcsi2rxss_parse_of : port 1 bus type = 4
[    1.433636] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: xcsi2rxss_parse_of : base.port = 1 base.id = 0
[    1.433650] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: xcsi2rxss_parse_of : mipi number lanes = 2
[    1.433703] irq_xilinx_intc: irq-xilinx: enable_or_unmask: 0
[    1.433750] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: # of ctrls = 2
[    1.433765] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: Skip active lane control
[    1.433780] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: 1 ctrl = 0x98c982
[    1.433808] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: 2 ctrl = 0x98c983
[    1.433824] xilinx_csi2rxss: xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: # v4l2 ctrls registered = 2
[    1.433839] xilinx-csi2rxss 80120000.mipi_csi2_rx_subsystem: Xilinx CSI2 Rx Subsystem device found!
...
[    6.964407] irq_xilinx_intc: irq-xilinx: enable_or_unmask: 1
[    6.970024] xilinx-frmbuf b0060000.v_frmbuf_wr: Xilinx AXI frmbuf DMA_DEV_TO_MEM
[    6.977453] xilinx-frmbuf b0060000.v_frmbuf_wr: Xilinx AXI FrameBuffer Engine Driver Probed!!

So, the interrupt setup seems to be correct.

 

Is there any to why to check if the MIPI CSI-2 RX Subsystem tried to trigger the interrupt?

 

Thank,

Attila

 

Adventurer
Adventurer
2,343 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

I don't really understand what happens...

 

Yesterday, I changed the AXI Interrupt Controller's Interrupt Output Connection from Bus to Single. I rebuilt the project, and guess what, the D-PHY signals are NO longer detected. Checked with the oscilloscope that they are there. Why this happens???

 

Today morning, I tried again and got the same result. Then, I tried to boot up the previous design (with the rst fix) and the D-PHY signals are again NOT detected. Whaat? This worked yesterday!

 

The Thursday's design is still working. So, the hardware is NOT damaged.

 

The only suspicious thing I see is:

Screenshot from 2018-11-03 10-23-14.png

but I have seen this on the previous design too.

 

Could this cause the problem? If yes how to fix it ?

 

Attila

Adventurer
Adventurer
2,315 Views
Registered: ‎09-02-2018

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Update:

 

Yet an another change, changing the video_clk to 125Mhz, solved the no D-PHY issue.

 

The next step was to check the AXI Interrupt Controller registers:

(00h) Interrupt Status Register (ISR)       =  0x00000003
(04h) Interrupt Pending Register (IPR)      =  0x00000003
(08h) Interrupt Enable Register (IER)       =  0x00000003
(0Ch) Interrupt Acknowledge Register (IAR)  =  0x00000000
(10h) Set Interrupt Enables (SIE)           =  0x00000000
(14h) Clear Interrupt Enables (CIE)         =  0x00000000
(18h) Interrupt Vector Register (IVR)       =  0x00000000
(1Ch) Master Enable Register (MER)          =  0x00000003
(20h) Interrupt Mode Register (IMR)         =  0x00000000
(24h) Interrupt Level Register (ILR)        =  0xFFFFFFFF

So, the interrupts are triggered, but not reaching by the device drivers.

 

The cause of this was that the Interrupt Output Connection was set to Bus to Single. This causes some Device Tree properties not to be generated. The hardware connection is present, so I decided just to update Device Tree with the missing properties:

&axi_intc_0 {
    interrupt-names = "irq";
    interrupt-parent = <0x4>;
    interrupts = <0x0 0x59 0x4>;
};

After this the interrupts reached the device drivers.

 

Tried to capture some frames and  IT'S WORKING !!!

 

Screenshot from 2018-11-03 17-10-01.jpg

Thanks,
Attila

Explorer
Explorer
2,305 Views
Registered: ‎10-21-2015

Re: MIPI CSI-2 RX Subsystem + OV5647 problem on Ultra96 (ZU3EG)

Congratulation!!!

 

Could you share your work(vivdo project tcl, devicetree and driver patches)?