DS90UB960-Q1EVM: Cannot receive data from deserializer

Hi Meng-Hung,

Do you have any details on the configuration script which is run on the UB960? Is the goal to bring up pattern generator on the Ub960 CSI TX or bring up multiple serilaizer patgen to show different virtual channel streams on the TDA4? 

Best,

Thomas

Hi Thomas,

We want to bring up multiple cameras by UB960 finally, but we're just currently trying doing this with one camera preliminarily. I believed the only used configuration script is this (and also the device driver provided by TI's Linux SDK). Both deserializer and camera were detected correctly in Linux.

Because we could not get the stream/data from the camera, we tried to enable the patgen to check the failure was on the camera or the deserializer side.

I was told that TI only tested this on Fusion Board 1 Rev.C model on processor forum, but DS90UB960-Q1-EVM is also extented from UB960 deserializer and I think it would work on J722S/TDA4VEN too.

Thank you

Hi Meng-Hung,

Do you know where I can see any log of the I2C writes which are being done here? Looking through the shell script which you liked for setting up cameras this doesn't appear to focus on how the ser/des are being configured (apologies if I'm missing something here). Once we're looking at the SER/DES register level we can diagnose what's going on here.

Best,

Thomas

Hi Thomas,

Sorry for the late reply. This is the message dumped from the kernel driver:

# boot
[	8.739387]: ub960, 0x01, 0x02
[	8.755376]: ub960, 0x0c, 0x00
[	8.768187]: ub960, 0x1f, 0x00
[	8.773175]: ub960, 0x32, 0x01
[	8.791183]: ub960, 0x33, 0x42
[	8.796318]: ub960, 0x4c, 0x12
[	8.802443]: ub960, 0xd8, 0x07
[	8.812318]: ub960, 0xd9, 0x7f
[	8.822440]: ub960, 0x5c, 0x8a
[	8.832005]: ub960, 0x42, 0x71
[	8.836661]: ub960, 0x41, 0xa9
[	8.851169]: ub960, 0xb0, 0x08
[	8.918602]: ub960, 0xb1, 0x08
[	8.944103]: ub960, 0xb2, 0x08
[	8.959283]: ub960, 0xb1, 0x09
[	8.964574]: ub960, 0xb2, 0x08
[	8.969817]: ub960, 0xd5, 0xe0
[	8.977993]: ub960, 0x01, 0x01
[	9.063227]: ub960, 0xb1, 0x08
[	9.081629]: ub960, 0xb1, 0x09
[	9.109095]: ub960, 0x4c, 0x01
[	9.131672]: ub960, 0x4c, 0x12
[	9.146758]: ub960, 0x4c, 0x24
[	9.166955]: ub960, 0x4c, 0x38

[	9.967017]: ub953, 0x0b, 0x13
[	9.976595]: ub953, 0x0c, 0x26
[	9.983738]: ub953, 0x02, 0x52
[	9.988411]: ub953, 0x0d, 0x00
[	9.998244]: ub953, 0x0e, 0x0f
[   10.014810]: ub953, 0x06, 0x41
[   10.023537]: ub953, 0x07, 0x28
[   10.146691]: ub960, 0x4c, 0x12
[   10.162446]: ub960, 0x5d, 0xc0
[   10.171468]: ub960, 0x65, 0x94
[   10.432043]: ub953, 0x06, 0x43
[   10.448541]: ub953, 0x07, 0x7d

# run application
[   48.723034]: ub960, 0x72, 0x04
[   48.728028]: ub960, 0x20, 0xf0

The beginning is the timestamp from the system boot.
I think I already dump all the operations. Please let me know if there's still something missing.

Thank you

Hi Meng-Hung,

Thank you for providing these details. Do you know if we have the ability to do reads/writes to deserializer after the boot? It would be helpful to check diagnostic registers such as ser/des lock, received video line count / length, and more to confirm where the error may be here.

Best,

Thomas

Hi Thomas,

The provided messages do already contain the operations after booting (see the last two lines). Also, I reconfigured the driver's debug level to show more raw messages:

# it failed because ds90ub960-q1-evm has only one deserializer, the default target is Fusion Daughter Board 2
[    8.058615] ds90ub960 5-0036: supply vddio not found, using dummy regulator
[    8.098152] ds90ub960 5-0036: ub960_write: cannot write register 0x01 (-121)!
[    8.105613] ub960 (ub960_write): 0x01, 0x02
[    8.116453] ds90ub960 5-0036: reset failed: -121
[    8.128725] ds90ub960 5-0036: ub960_read: cannot read register 0x03 (-121)!
[    8.135886] ds90ub960 5-0036: error -EREMOTEIO: Cannot read first register, abort
[    8.150434] ds90ub960: probe of 5-0036 failed with error -121

[    8.157061] ds90ub960 5-003d: supply vddio not found, using dummy regulator
[    8.167950] ub960 (ub960_write): 0x01, 0x02
[    8.173985] ds90ub960 5-003d: Found ub960 (rev/mask 0x40)
[    8.185165] ds90ub960 5-003d: refclk valid 1 freq 28 MHz (clk fw freq 25 MHz)
[    8.185321] ub960 (ub960_write): 0x0c, 0x00
[    8.190764] ub960 (ub960_write): 0x1f, 0x00
[    8.195839] ub960 (ub960_txport_select): 0x32, 0x01
[    8.208530] ub960 (ub960_txport_write): 0x33, 0x42
[    8.214362] ub960 (ub960_rxport_select): 0x4c, 0x12
[    8.229207] ub960 (ub960_rxport_write): 0xd8, 0x07
[    8.239607] ub960 (ub960_rxport_write): 0xd9, 0x7f
[    8.245962] ub960 (ub960_rxport_write): 0x5c, 0x8a
[    8.264005] ub960 (ub960_write): 0x42, 0x71
[    8.268690] ub960 (ub960_write): 0x41, 0xa9
[    8.273303] ub960 (ub960_select_ind_reg_block): 0xb0, 0x08
[    8.279126] ub960 (ub960_write_ind): 0xb1, 0x08
[    8.285189] ub960 (ub960_write_ind): 0xb2, 0x08
[    8.310288] ub960 (ub960_write_ind): 0xb1, 0x09
[    8.316382] ub960 (ub960_write_ind): 0xb2, 0x08
[    8.322316] ub960 (ub960_rxport_write): 0xd5, 0xe0
[    8.328466] ub960 (ub960_write): 0x01, 0x01
[    8.402613] ds90ub960 5-003d: Wait locks done in 2 loops
[    8.410436] ub960 (ub960_read_ind): 0xb1, 0x08
[    8.419264] ub960 (ub960_read_ind): 0xb1, 0x09
[    8.424896] ds90ub960 5-003d:        rx1: locked, SP: 2, EQ: 0, freq 100000000 Hz
[    8.425080] ub960 (ub960_rxport_select): 0x4c, 0x01
[    8.433876] ub960 (ub960_rxport_select): 0x4c, 0x12
[    8.440066] ub960 (ub960_rxport_select): 0x4c, 0x24
[    8.446354] ub960 (ub960_rxport_select): 0x4c, 0x38
[    8.452671] ds90ub960 5-003d: Fixed dependency cycle(s) with /bus@f0000/i2c@20020000/i2c-mux@70/i2c@0/deser@3d/links/link@1/serializer
[    8.519220] ds90ub960 5-003d: rx1: remote serializer at alias 0x45 (5-0045)

[    9.917742] ds90ub953 5-0045: mode from strap: 0x0
[    9.917988] ds90ub953 5-0045: Found ub953 rev/mask 0x20
[    9.997022] ds90ub953 5-0045: i2c strap setting 3.3 V
[    9.998593] ub953 (ub953_write): 0x0b, 0x13
[   10.020147] ub953 (ub953_write): 0x0c, 0x26
[   10.042366] ub953 (ub953_write): 0x02, 0x52
[   10.047234] ub953 (ub953_write): 0x0d, 0x00
[   10.055165] ub953 (ub953_write): 0x0e, 0x0f
[   10.069836] ds90ub953 5-0045: ub953_calc_clkout_params 4000000000 / 4 * 1 / 40 = 25000000 (requested 25000000)
[   10.070021] ub953 (ub953_write): 0x06, 0x41
[   10.074556] ub953 (ub953_write): 0x07, 0x28
[   10.084277] ds90ub953 5-0045: clkout: fc rate 4000000000, hs_clk_div 4, mul 1, div 40 = 25000000
[   10.124372] ub960 (ub960_rxport_select): 0x4c, 0x12
[   10.161002] ub960 (ub960_rxport_write): 0x5d, 0xc0
[   10.166390] ub960 (ub960_rxport_write): 0x65, 0x94
[   10.166586] ds90ub960 5-003d: rx1: client 0x60 assigned alias 0x4a at slot 0
[   10.167062] ds90ub953 5-0045: Fixed dependency cycle(s) with /bus@f0000/i2c@20020000/i2c-mux@70/i2c@0/deser@3d/links/link@1/serializer/i2c/sensor@60
[   10.554816] ds90ub953 5-0045: ub953_calc_clkout_params 4000000000 / 4 * 3 / 125 = 24000000 (requested 24000000)
[   10.554852] ds90ub953 5-0045: ub953_calc_clkout_params 4000000000 / 4 * 3 / 125 = 24000000 (requested 24000000)
[   10.554866] ds90ub953 5-0045: ub953_calc_clkout_params 4000000000 / 4 * 3 / 125 = 24000000 (requested 24000000)
[   10.554875] ds90ub953 5-0045: ub953_clkout_set_rate 24000000 (requested 24000000)
[   10.555042] ub953 (ub953_write): 0x06, 0x43
[   10.560002] ub953 (ub953_write): 0x07, 0x7d
[   10.564842] ds90ub953 5-0045: clkout: fc rate 4000000000, hs_clk_div 4, mul 3, div 125 = 24000000
[   14.579330] ds90ub960 5-003d: ub960_get_vc_maps: VC map for port 1 is 0x04
[   14.579360] ds90ub960 5-003d: Mapping sink 1/0 to output VC 0
[   14.579367] ds90ub960 5-003d: Mapping sink 1/1 to output VC 1
[   15.987014] ds90ub960 5-003d: ub960_get_vc_maps: VC map for port 1 is 0x04
[   15.987045] ds90ub960 5-003d: Mapping sink 1/0 to output VC 0
[   15.987052] ds90ub960 5-003d: Mapping sink 1/1 to output VC 1
[   19.462770] ds90ub960 5-003d: ub960_get_vc_maps: VC map for port 1 is 0x04
[   19.462800] ds90ub960 5-003d: Mapping sink 1/0 to output VC 0
[   19.462807] ds90ub960 5-003d: Mapping sink 1/1 to output VC 1

# start the out-of-the-box demo
[   63.084416] ds90ub960 5-003d: ub960_get_vc_maps: VC map for port 1 is 0x04
[   63.084450] ds90ub960 5-003d: Mapping sink 1/0 to output VC 0
[   63.084458] ds90ub960 5-003d: Mapping sink 1/1 to output VC 1
[   63.085103] ds90ub960 5-003d: Prepare for streaming
[   63.085122] ds90ub960 5-003d: ub960_get_vc_maps: VC map for port 1 is 0x04
[   63.085263] ub960 (ub960_rxport_write): 0x72, 0x04
[   63.090242] ub960 (ub960_write): 0x20, 0xf0
[   63.094515] ds90ub960 5-003d: enable TX port 0
[   63.094819] ds90ub960 5-003d: enable RX port 1
[   63.095074] ds90ub960 5-003d: enable RX port 1 streams 0x3
[   63.338641] ds90ub960 5-003d: INTERRUPT_STS 2
[   63.338802] ds90ub960 5-003d: FWD_STS 0x0
[   63.339498] ds90ub960 5-003d: rx1 line len changed: 2000
[   63.339663] ds90ub960 5-003d: rx1 line count changed: 1300

# stop after something went wrong in demo
[   68.299546] ds90ub960 5-003d: disable RX port 1 streams 0x3
[   68.319890] ds90ub960 5-003d: disable RX port 1
[   68.320355] ds90ub960 5-003d: disable TX port 0
[   68.458654] ds90ub960 5-003d: INTERRUPT_STS 2
[   68.458817] ds90ub960 5-003d: FWD_STS 0x0

# Processor support said this is not matter
[   68.459356] ds90ub960 5-003d: rx1 CSI error: 0xc
[   68.463999] ds90ub960 5-003d: rx1 CSI checksum error
[   68.469000] ds90ub960 5-003d: rx1 CSI length error

I noticed the line length is 2000 that driver detected. However, this camera says the resolution should be 1600 * 1300. Is it correct?

Regards

Hi Meng-Hung,

In this case, the line length will show up in bytes, do you know what data type is used here? This latest log is helpful, it looks like there was an interrupt which triggered based on change in line count and line length. One important item would be to confirm if we're clearing these flags after power-up and sensor streaming. When the sensor starts streaming, these flags will be triggered as the line count is updating to a stable state while the sensor is streaming. Could you check if these errors continue to occur after power-up or if they are cleared by the first read?

Best,

Thomas

Hi Thomas,

In this case, the line length will show up in bytes, do you know what data type is used here?

I think it is using RAW10 (bggi10) format, so the line length (2000 * 8 / 10 = 1600) seems to be right. But how the line count is still 1300 here?

One important item would be to confirm if we're clearing these flags after power-up and sensor streaming.

Do you mean "UB960_RR_RX_PORT_STS2_LINE_LEN_CHG (in register 0x4e)" flag (Line 89~90 in latest logs)?

Could you check if these errors continue to occur after power-up or if they are cleared by the first read?

I'm not sure I really get your mind correctly. I've tried running the demo multiple times, and the line len/count changing (Line 89~90 in latest logs) didn't occur multiply and only once there.

Thank you

Hi Meng-Hung,

In this case where the data type is RAW10 the report in line 89/90 seems to have the correct resolution. My theory is that when the sensor starts streaming, the line count / length goes from 0 to the correct line length / line count. At this time the "line count change" and "line length change" flags would be set high in register 0x4E.

Do you have the output of the other logs that show different error types if this log is not representative of the situation which occurs?

Best,

Thomas

Hi Thomas,

I believe these cover all the I2C operations. Wouldn't these log messages be sufficient to help identify the issue or determine whether there's a hardware failure?

Thank you

Hi Meng-Hung,

Do you have details on the other types of failures which are seen in these logs?

Meng-Hung Chen said:

I'm not sure I really get your mind correctly. I've tried running the demo multiple times, and the line len/count changing (Line 89~90 in latest logs) didn't occur multiply and only once there.

From the provided log it seems that the streaming may be okay, we just need to clear the error flags. But I understand that this may not be the case in every log.

Best,

Thomas

Hi Thomas,

We are merely speculating whether this issue is caused by a hardware failure.

Theoretically, we should be able to receive the stream from the deserializer after enabling the stream.

We also tried using the pattern generator in TI's ALP to bypass the sensor and focus on the deserializer, but we still couldn't receive any data.

Thank you 

Hi Meng-Hung,

From the deserializer perspective it seems that we are receiving the correct line count & line length. One other check you could do is to verify the CSI-2 output in register 0x90 - 0x91 for the frame count on the CSI-2 output port. From the hardware side, do you have additional details about the connection to the TDA4?

Best,

Thomas