• State Resolved
  • Locked Locked
  • Replies 40 replies
  • Answers 2 answers
  • Subscribers 97 subscribers
  • Views 16596 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/PROCESSOR-SDK-AM57X: Stream fails in subdev

Rahul Sharma
Expert 2725 points

Part Number: PROCESSOR-SDK-AM57X
Other Parts Discussed in Thread: TMDSEVM572X

Tool/software: Linux

Hi all,

I am using latest processor sdk with TMDSEVM572x camera module.

As i previously posted about my hardware changes. All changes are done. No issue with GPIOs and all.

After running the command-

yavta -c60 -fYUYV -Fvout_640x480_yuyv.yuv -s640x480 /dev/video1

I am getting error- 

[ 90.323169] vip2-s0: stream on failed in subdev
[ 90.323177] vb2: vb2_start_streaming: driver refused to start streaming.

Please find the attached dmesg log file.

Please suggest what is wrong i am doing.

dmesglog4.txt

  • 0
    Guru 13660 points

    Hi Rahul,

    [ 90.310034] mt9t11x 4-003c: PS-SE Enter mt9t11x_reg_write: command 98e
    [ 90.316765] mt9t11x 4-003c: PS-SE Exit mt9t11x_reg_write:, ret -121

    Looks like the Camera sensor has stopped responding ACK, it is giving NACK. Does it happen every time ? Can you check if it is happening at the same time and place and you are getting similar logs.

  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    Hi Dwarakesh,
    Yes, Its happening at the same time and every time. Sometime in between the logs also "I2c controller time out and remote I/O error" are there. But this error exist every time at last.
    Need to know what is the cause of this error.
    Thanks.
  • 0 in reply to Rahul Sharma
    Expert 2725 points

    Hi,

    Any suggestion?

  • 0 in reply to Rahul Sharma
    Guru 13660 points
    Hi Rahul,

    The Camera sensor has stopped giving ACK. It could be for many reason like sensor got powered off, not getting clock, sensor reset, i2c lanes are not proper.

    Few suggestions to check to see what is happening. Not a fix. Try one and revert back.
    1. Comment out mt9t11x_set_power(0) in probe function, where it is disabled at the bottom. Check then from userspace i2c utils whether you can access and how long you can access.
    2. Try commenting out init_camea_optimized() instead try calling init_camera() and see the behaviour.
    3. Confirm by checking the pinmux and by probing through Oscilloscope that i2c, GPIO , clock states/pinmuxing are not changed, after you see the above failure.
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points

    Hi Dwarakesh,

     1)Comment out mt9t11x_set_power(0) in probe function, where it is disabled at the bottom. Check then from userspace i2c utils whether you can access and how long you can access.


    After commenting mt9t11x_set_power(0), The result for following commands are-

    i2cdetect -r 4

    0 1 2 3 4 5 6 7 8 9 a b c d e f
    00: -- -- -- -- -- -- -- -- -- -- -- -- --
    10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    30: -- -- -- -- -- -- -- -- -- -- -- -- UU -- -- --
    40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
    70: -- -- -- -- -- -- -- --

    And for gst-launch-1.0 -v --gst-debug=2 -e v4l2src device=/dev/video1 num-buffers=900 io-mode=4 ! 'video/x-raw, format=(string)YUY2, width=(int)1280, height=(int)720' ! vpe num-input-buffers=8 ! queue ! kmssink

    Setting pipeline to PAUSED ...
    Pipeline is live and does not need PREROLL ...
    Setting pipeline to PLAYING ...
    New clock: GstSystemClock
    /GstPipeline:pipeline0/GstV4l2Src:v4l2src0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)YUY2\,\ width\=\(int\)1280\,\ height\=\(int\)720\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ interlace-mode\=\(string\)progressive\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)100/1"
    /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)YUY2\,\ width\=\(int\)1280\,\ height\=\(int\)720\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ interlace-mode\=\(string\)progressive\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)100/1"
    /GstPipeline:pipeline0/GstVpe:vpe0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)NV12\,\ width\=\(int\)1280\,\ height\=\(int\)720\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ framerate\=\(fraction\)100/1"
    /GstPipeline:pipeline0/GstQueue:queue0.GstPad:src: caps = "video/x-raw\,\ format\=\(string\)NV12\,\ width\=\(int\)1280\,\ height\=\(int\)720\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ framerate\=\(fraction\)100/1"
    /GstPipeline:pipeline0/GstKMSSink:kmssink0.GstPad:sink: caps = "video/x-raw\,\ format\=\(string\)NV12\,\ width\=\(int\)1280\,\ height\=\(int\)720\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ framerate\=\(fraction\)100/1"
    /GstPipeline:pipeline0/GstQueue:queue0.GstPad:sink: caps = "video/x-raw\,\ format\=\(string\)NV12\,\ width\=\(int\)1280\,\ height\=\(int\)720\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ framerate\=\(fraction\)100/1"
    /GstPipeline:pipeline0/GstVpe:vpe0.GstPad:sink: caps = "video/x-raw\,\ format\=\(string\)YUY2\,\ width\=\(int\)1280\,\ height\=\(int\)720\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ interlace-mode\=\(string\)progressive\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)100/1"
    /GstPipeline:pipeline0/GstCapsFilter:capsfilter0.GstPad:sink: caps = "video/x-raw\,\ format\=\(string\)YUY2\,\ width\=\(int\)1280\,\ height\=\(int\)720\,\ pixel-aspect-ratio\=\(fraction\)1/1\,\ interlace-mode\=\(string\)progressive\,\ colorimetry\=\(string\)bt601\,\ framerate\=\(fraction\)100/1"
    0:00:00.316308843 1380 0x143c30 WARN v4l2bufferpool gstv4l2bufferpool.c:749:gst_v4l2_buffer_pool_start:<v4l2src0:pool:src> Uncertain or not enough buffers, enabling copy threshold
    0:00:00.716084682 1380 0x143c30 ERROR v4l2bufferpool gstv4l2bufferpool.c:636:gst_v4l2_buffer_pool_streamon:<v4l2src0:pool:src> error with STREAMON 121 (Remote I/O error)
    0:00:00.716301839 1380 0x143c30 WARN v4l2bufferpool gstv4l2bufferpool.c:1055:gst_v4l2_buffer_pool_poll:<v4l2src0> error: poll error 1: Remote I/O error (121)
    ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Could not read from resource.
    Additional debug info:
    ../../../gst-plugins-good-1.6.3/sys/v4l2/gstv4l2bufferpool.c(1055): gst_v4l2_buffer_pool_poll (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
    poll error 1: Remote I/O error (121)
    EOS on shutdown enabled -- waiting for EOS after Error
    Waiting for EOS...
    0:00:00.716969902 1380 0x143c30 WARN v4l2src gstv4l2src.c:848:gst_v4l2src_create:<v4l2src0> error: Failed to allocate a buffer
    ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Failed to allocate a buffer
    Additional debug info:
    ../../../gst-plugins-good-1.6.3/sys/v4l2/gstv4l2src.c(848): gst_v4l2src_create (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0
    0:00:00.717208530 1380 0x143c30 WARN basesrc gstbasesrc.c:2943:gst_base_src_loop:<v4l2src0> error: Internal data flow error.
    0:00:00.717236183 1380 0x143c30 WARN basesrc gstbasesrc.c:2943:gst_base_src_loop:<v4l2src0> error: streaming task paused, reason error (-5)
    ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data flow error.
    Additional debug info:
    ../../../../gstreamer-1.6.3/libs/gst/base/gstbasesrc.c(2943): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
    streaming task paused, reason error (-5)

    And gets hang.

    2)Try commenting out init_camea_optimized() instead try calling init_camera() and see the behaviour.

    I tried that and it gives 

    Setting pipeline to PAUSED ...
    Pipeline is live and does not need PREROLL ...
    Setting pipeline to PLAYING ...
    New clock: GstSystemClock
    0:00:00.392760366 1338 0x143c30 WARN basesrc gstbasesrc.c:2943:gst_base_src_loop:<v4l2src0> error: Internal data flow error.
    0:00:00.392823805 1338 0x143c30 WARN basesrc gstbasesrc.c:2943:gst_base_src_loop:<v4l2src0> error: streaming task paused, reason not-negotiated (-4)
    ERROR: from element /GstPipeline:pipeline0/GstV4l2Src:v4l2src0: Internal data flow error.
    Additional debug info:
    ../../../../gstreamer-1.6.3/libs/gst/base/gstbasesrc.c(2943): gst_base_src_loop (): /GstPipeline:pipeline0/GstV4l2Src:v4l2src0:
    streaming task paused, reason not-negotiated (-4)
    EOS on shutdown enabled -- waiting for EOS after Error
    Waiting for EOS...

    I guess "not-negotiated (-4)" means that format is not supported.

    3)I also confirmed probing the hardware pins.

    Can you please guide me in above logs?

  • 0 in reply to Rahul Sharma
    Guru 13660 points
    Hi Rahul,

    1. Please run the same Yavta App. Which seems to be a impler file dump, instead of gstreamer.
    2. Use i2c-read and i2c write for point 1. Instead of running any multimedia App.
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    Hello,
    I ran yavta command and it gives -
    Device /dev/video1 opened.
    Device `vip' on `platform:vip' is a video output (without mplanes) device.
    Video format set: YUYV (56595559) 640x480 (stride 1280) field none buffer size 614400
    Video format: YUYV (56595559) 640x480 (stride 1280) field none buffer size 614400
    8 buffers requested.
    length: 614400 offset: 0 timestamp type/source: mono/EoF
    Buffer 0/0 mapped at address 0xb6d4f000.
    length: 614400 offset: 614400 timestamp type/source: mono/EoF
    Buffer 1/0 mapped at address 0xb6cb9000.
    length: 614400 offset: 1228800 timestamp type/source: mono/EoF
    Buffer 2/0 mapped at address 0xb6c23000.
    length: 614400 offset: 1843200 timestamp type/source: mono/EoF
    Buffer 3/0 mapped at address 0xb6b8d000.
    length: 614400 offset: 2457600 timestamp type/source: mono/EoF
    Buffer 4/0 mapped at address 0xb6af7000.
    length: 614400 offset: 3072000 timestamp type/source: mono/EoF
    Buffer 5/0 mapped at address 0xb6a61000.
    length: 614400 offset: 3686400 timestamp type/source: mono/EoF
    Buffer 6/0 mapped at address 0xb69cb000.
    length: 614400 offset: 4300800 timestamp type/source: mono/EoF
    Buffer 7/0 mapped at address 0xb6935000.
    Unable to start streaming: Remote I/O error (121).
    8 buffers released.

    And for i2c-read and write,
    its showing device or resource is busy. I tried rmmod to unload the module and after reloading the result was same.
  • 0 in reply to Rahul Sharma
    Guru 13660 points
    i2cget and i2cset, you need to force by -f to read/write.

    Can you enable Yavta in point2, when you have enabled the camera_init. Also do increase the debugging logs as you have done before.
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    I tried i2cget and i2cset by -f then its showing read failed.


    And i am running yavta with camera_init enabled. It shows-
    Device /dev/video1 opened.
    Device `vip' on `platform:vip' is a video output (without mplanes) device.
    Video format set: YUYV (56595559) 640x480 (stride 1280) field none buffer size 614400
    Video format: YUYV (56595559) 640x480 (stride 1280) field none buffer size 614400
    8 buffers requested.
    length: 614400 offset: 0 timestamp type/source: mono/EoF
    Buffer 0/0 mapped at address 0xb6e29000.
    length: 614400 offset: 614400 timestamp type/source: mono/EoF
    Buffer 1/0 mapped at address 0xb6d93000.
    length: 614400 offset: 1228800 timestamp type/source: mono/EoF
    Buffer 2/0 mapped at address 0xb6cfd000.
    length: 614400 offset: 1843200 timestamp type/source: mono/EoF
    Buffer 3/0 mapped at address 0xb6c67000.
    length: 614400 offset: 2457600 timestamp type/source: mono/EoF
    Buffer 4/0 mapped at address 0xb6bd1000.
    length: 614400 offset: 3072000 timestamp type/source: mono/EoF
    Buffer 5/0 mapped at address 0xb6b3b000.
    length: 614400 offset: 3686400 timestamp type/source: mono/EoF
    Buffer 6/0 mapped at address 0xb6aa5000.
    length: 614400 offset: 4300800 timestamp type/source: mono/EoF
    Buffer 7/0 mapped at address 0xb6a0f000.
    Unable to start streaming: Remote I/O error (121).
    8 buffers released.
  • 0 in reply to Rahul Sharma
    Guru 13660 points
    When u are accessing i2c, as suggested have you made sure disabling power is not done in probe ?
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    Oh my bad,
    I re-enabled that for later points.
    Now i disabled that and got i2cget result - 0x00.
    Can you please suggest me for i2cset command? I am having confusion while providing the addresses such as in stream function, there is reg write as "mt9t11x_reg_write(client, 0x3C20, 0)". So what will be the i2cset command would be.
    My chip-address is 0x3c and i2cbus - 4
  • 0 in reply to Dwarakesh Radhakrishnan
    Guru 13660 points

    As done in probe, first try to get the chip ID. Refer : linux.die.net/.../i2cget

    The whole idea is to check, when trying to use from i2c utils, do we see the failure -121(Remote error).

  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    Oh, looking great... but unfortunately I m just out of my workspace.. I will do that tomorrow as soon as possible and will share the results.
    Thanks very much.
  • 0 in reply to Rahul Sharma
    Expert 2725 points

    Hi,

    I checked i2cget to read the chip ID at 0x0000 (i2cget -f 4 0x3C 0x0000 w).

    Its showing 0x0000 value and if i try for 3,4 times it just get changed - (0x0290, 0x0100, 0xb000, 0x0f00).

    Also there is range of data address - (0x03 - 0x77), so i also checked with (i2cget -f 4 0x3C 0x00 w).

    It must read 0x2680. Also its showing the correct chip id in logs. But not in userspace i2c utils.

  • 0 in reply to Rahul Sharma
    Expert 2725 points
    Also I found through logs, The error (-121) is coming in -
    static int mt9t11x_mcu_powerup_stop_enable(const struct i2c_client *client)
    {
    int ret;

    /* set powerup stop bit */
    ret = mt9t11x_reg_mask_set(client, 0x0018, 0x0004, 1);
    return ret;

    }
    and get stops saying vip2-s0: stream on failed in subdev
    vb2: vb2_start_streaming: driver refused to start streaming
  • 0 in reply to Rahul Sharma
    Guru 13660 points
    Hi,
    1. For i2cget command looks fine, but not sure why it is sending wrong values. Can you confirm by printing at drivers/i2c/busses/i2c-omap.c and check in function omap_i2c_xfer_msg() add logs and check the difference between what is coming in probe and what is coming when you try from i2cget

    2. Does it every time fail in mt9t11x_mcu_powerup_stop_enable consistently ? Check if you can go through the MT9T11x datasheet and understand what is the purpose and check if you can skip it(without understanding dont try to skip this powerup_stop_enable and other functions in init()).
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    Hi,
    I am trying this.
    Just to add that , while loading the driver
    chip ID is correctly detected by the API, chipid = mt9t11x_reg_read(client, 0x0000) and shows the correct value.
  • 0 in reply to Rahul Sharma
    Guru 13660 points
    I could see in the logs shared before. So only we need to compare at that probe time to what we send in i2cget in the function i mentioned above.
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    Hi, I enabled the log in i2c-omap.c with omap_i2c_read_reg(omap, 0x00). Just wanted to read the chip ID.
    It gives- 20544
  • 0 in reply to Rahul Sharma
    Guru 13660 points
    I am not understanding. I wanted to just enable a debug log and read addr, len and flags.
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    After enabling the log, it gives repeatedly
    [ 36.029117] omap_i2c 48070000.i2c: addr: 0x0048, len: 1, flags: 0x0, stop: 0
    [ 36.029140] omap_i2c 48070000.i2c: IRQ (ISR = 0x0010)
    [ 36.029191] omap_i2c 48070000.i2c: IRQ (ISR = 0x0004)
    [ 36.029213] omap_i2c 48070000.i2c: addr: 0x0048, len: 2, flags: 0x1, stop: 1
    [ 36.029306] omap_i2c 48070000.i2c: IRQ (ISR = 0x0008)
    [ 36.029316] omap_i2c 48070000.i2c: IRQ (ISR = 0x0004)
  • 0 in reply to Rahul Sharma
    Guru 13660 points
    Put a filter for i2c4 and check.
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    Can you please tell me how to apply filter for 12c4?
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    Hi,
    i am just applying a check for adap->nr ==4 before dev_dbg(omap->dev, "addr: 0x%04x, len: %d, flags: 0x%x, stop: %d\n",
    msg->addr, msg->len, msg->flags, stop)

    Please correct me if i am doing wrong. Because i am getting the same result as before.
  • 0 in reply to Rahul Sharma
    Expert 2725 points

    Want to add, After running yavta, I got the result.

    i also printed the nr value.

    Please find the log file.

    dmesglogs.txt

  • 0 in reply to Rahul Sharma
    Guru 13660 points
    I am able to see adap->nr=4 So if add proper checking it should not print other logs for other i2c buses. Please do not run yavta. Just try inserting the module alone, check the way probe reads the chipId and do the same in user space.
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    I commented the debug log apart from the main one. In between the logs i got -
    [ 9.598718] adap->nr: 4
    [ 9.601233] omap_i2c 4807c000.i2c: addr: 0x003c, len: 2, flags: 0x0, stop: 0
    [ 9.601331] adap->nr: 4
    [ 9.618953] omap_i2c 4807c000.i2c: addr: 0x003c, len: 2, flags: 0x1, stop: 1
    [ 9.620079] mt9t11x 4-003c: PS-SE Exit mt9t11x_reg_read:, ret 32806
    [ 9.627659] remoteproc5: registered virtio3 (type 7)
    [ 9.633615] pru-rproc 4b238000.pru1: PRU rproc node /ocp/pruss@4b200000/pru1@4b238000 probed successfully
    [ 9.650032] remoteproc6: 4b2b4000.pru0 is available
    [ 9.655404] rtc-ds1307 2-006f: write secs=48, mins=39, hours=8, mday=1, mon=5, year=117, wday=4
    [ 9.655419] rtc-ds1307 2-006f: write: c8 39 08 0d 01 06 17
    [ 9.655429] adap->nr:
    [ 9.657729] mt9t11x 4-003c: mt9t111 chip ID 2680
    [ 9.661591] 2
    [ 9.665329] adap->nr: 2
    [ 9.667788] adap->nr:
    [ 9.667790] 2
    [ 9.668018] rtc-ds1307 2-006f: read: c8 39 08 2d 01 06 17
    [ 9.668024] rtc-ds1307 2-006f: read secs=48, mins=39, hours=8, mday=1, mon=5, year=117, wday=4
    [ 9.668029] adap->nr:
    [ 9.668030] 2
  • 0 in reply to Rahul Sharma
    Expert 2725 points
    Hi,
    Is it what you are requiring in logs?
  • 0 in reply to Rahul Sharma
    Guru 13660 points
    Please read our previous posts to understand what we are trying to do.
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    I found these are same, but differ with len
    dmesg log gave-
    [ 9.752288] omap_i2c 4807c000.i2c: addr: 0x003c, len: 2, flags: 0x0, stop: 0
    [ 9.754852] omap_i2c 4807c000.i2c: addr: 0x003c, len: 2, flags: 0x1, stop: 1

    when i run i2cget in userspace, it gave-
    [ 230.453536] omap_i2c 4807c000.i2c: addr: 0x003c, len: 1, flags: 0x0, stop: 0
    [ 230.456211] omap_i2c 4807c000.i2c: addr: 0x003c, len: 2, flags: 0x1, stop: 1
  • 0 in reply to Rahul Sharma
    Guru 13660 points
    figure out the len is different. thats the clue
  • 0 in reply to Dwarakesh Radhakrishnan
    Expert 2725 points
    Hi, can you please tell me why there are always two calls such as-
    [ 230.453536] omap_i2c 4807c000.i2c: addr: 0x003c, len: 1, flags: 0x0, stop: 0
    [ 230.456211] omap_i2c 4807c000.i2c: addr: 0x003c, len: 2, flags: 0x1, stop: 1
  • 0 in reply to Rahul Sharma
    Expert 2725 points
    Also please suggest me some approaches to figure it out why len is different?
  • 0 in reply to Rahul Sharma
    Expert 2725 points

    Hi,

    I would like to share that the camera is up. And i am able to get data in yuv format. It was majorly issue with the length of cable i was using. Thanks for the support.

    Just want to add that while using "yavta -c60 -fYUYV -Fvout_640x480_yuyv.yuv -s640x480 /dev/video1", i am storing the data but is there any similar yavta command for live streaming?

    Thanks.

  • 0 in reply to Rahul Sharma
    Expert 2725 points
    Hi
    I would like to share that the camera is up. It was majorly issue with the length of cable. Thanks TI member and TI employees for the support. I got a lot of information.
  • 0 in reply to Rahul Sharma
    Guru 13660 points
    Hi Rahul.

    Yavta is a simple application for v4l2 capture and does not provide flexibility like gstreamer. Can you try using gstreamer pipeline? You need to use udpsink for streaming. May be somebody else can elaborate on it.
  • 0 in reply to Rahul Sharma
    TI__Guru* 80190 points
    Hello,

    I would recommend you to check this wiki page regarding gstreamer:
    processors.wiki.ti.com/.../Processor_Training:_Multimedia
    Here is also example for streaming:
    gst-launch-1.0 -v -e videotestsrc ! 'video/x-raw,width=1280,height=720' ! queue ! ducatimpeg4enc ! mpeg4videoparse ! queue ! mpegtsmux ! queue ! udpsink host=192.168.0.1 port=5000 sync=false

    BR
    Margarita