• State Resolved
  • Locked Locked
  • Replies 22 replies
  • Subscribers 98 subscribers
  • Views 2452 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.

MV5 video frame buffer bootarg parameters do not work

Tiger Team4268
Intellectual 760 points
Other Parts Discussed in Thread: TEST2, THS8200

We are having problems getting the video buffer kernel bootargs to work on the new MV5 / DVSDK 2.00.00.22  LSP2.0 kernel release. Bootarg parameters that worked fine on the MV4 release no longer work.

We seem to have the same exact problem that was brought up on a previous post two months ago which was never resolved or for which the resolution was never posted in this forum.

http://e2e.ti.com/forums/p/6564/25252.aspx#25252  :  DM6446 - Proper bootargs for video

We have duplicated this on two different DM6446 EVMs. with both virgin SVDSK binaries from the DVSDK 2.0.0.22  code repository page and rebuilt kernels. We have also poured over thecommand syntax shown in SPRUG92 (LSP 2.00 Davinci VPBE Frame Buffer Driver)  and  also the SPRUE66F (DM6446 Getting started guide)  documents. I understand that the bootarg parameters have changed slightly, but in this case I am not sure that it is the "syntax" that is causing the problems.

For those with similar questions, look at this post that provided the documents to start with:

http://e2e.ti.com/forums/p/6767/26214.aspx#26214 :  Is there a document for davincifb in mv5.0

 

We are attempting to "bringup" a target DM6446 platform, but until we can get this controlled on a EVM, we are stuck.

I have tried several different bootargs in an attempt to narrow down what is going on. I will post the results of a series these controlled "tests" below, but the symptoms are:

  1.  Only a 720x480 screen size seems to be suported, bootargs setting up a 720x576 screen do not work anymore, no matter what the syntax is.
  2. The OSD frame buffer is not working on every bootarg tried, even one taken verbatim from a example on page 15 of the SPRUG92 document.

These are most likely completely unrelated issues, but in either case, they are problematic for us.

What are we missing?

- Gary

 

 

 

 

 

  • 0
    Intellectual 760 points

    Additional information:

     

    The following “test” boots were all made on a DM6446 EVM with the MV5/DVSDK2-00-00-22  default kernel as it is provided in the 2.00.00.22 recovery tar images

     

    They show two “issues”

     

    1.       A  720x576 Screen size is not permitted and will result in a demo runtime error (this worked on other versions)

     

    2.       The OSD0 window is not  “happy” with any arguments, even the example ones in the SPRUG92 doc

     

     

    I listed only the parameters that changed between each test. Common to all the tests is the following bootarg:

     

    console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=192.168.1.20:/home/gwebb/workdir/filesys,nolock mem=118M davinci_enc_mngr.ch0_mode=ntsc davinci_enc_mgr.ch0=COMPOSITE

     

     

     

    TEST1: original video bootargs parameters from previous MV4 builds:

     

    ------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=720x576x16,2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K

    ------------------------------------------------------------------------------------------------------------------------------

     

    boot time:

    davincifb davincifb: dm_osd0_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 2025KB

    davincifb davincifb: dm_vid0_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_vid0_fb: 720x576x16@0,0 with framebuffer size 2500KB

    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 675KB

    davincifb davincifb: dm_vid1_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_vid1_fb: 720x576x16@0,0 with framebuffer size 2500KB

    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

     

    (runtime:)

    Decode demo started.

    DavinciDisplay DavinciDisplay.1: Display Manager failed to allocate layer

    DavinciDisplay DavinciDisplay.1: Unable to configure video layer for id = 0

    Error: Failed to create display device

     

     

     

    TEST2:  removed frame buffer dimensions

     

    ------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=0,2500K:vid1=0,2500K:osd0=720x576x16,2025K

    ------------------------------------------------------------------------------------------------------------------------------

    davincifb davincifb: dm_osd0_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 2025KB

    davincifb davincifb: dm_vid0_fb: 0x0x16@0,0 with framebuffer size 2500KB

    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 675KB

    davincifb davincifb: dm_vid1_fb: 0x0x16@0,0 with framebuffer size 2500KB

    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

     

     

     

    TEST3:  reinstated frame buffer dimensions, but added starting coordinate syntax

     

    ------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=720x576x16,2500K@0,0:vid1=720x576x16,2500K@0,0:osd0=720x576x16,2025K@0,0

    ------------------------------------------------------------------------------------------------------------------------------

    davincifb davincifb: dm_osd0_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 2025KB

    davincifb davincifb: dm_vid0_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_vid0_fb: 720x576x16@0,0 with framebuffer size 2500KB

    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 675KB

    davincifb davincifb: dm_vid1_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_vid1_fb: 720x576x16@0,0 with framebuffer size 2500KB

    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

     

     

    TEST4:  removed all frame buffer arguments  (defaulted to 720x480)

     

    ------------------------------------------------------------------------------------------------------------------------------

    video=davincifb

    ------------------------------------------------------------------------------------------------------------------------------

    davincifb davincifb: dm_osd0_fb: 720x480x16@0,0 with framebuffer size 675KB

    davincifb davincifb: dm_vid0_fb: 0x0x16@0,0 with framebuffer size 1020KB

    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 675KB

    davincifb davincifb: dm_vid1_fb: 0x0x16@0,0 with framebuffer size 1020KB

    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

     

     

     

    TEST5:  explicitly reinstated default buffer arguments (with 720x480)

     

    ------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=720x480x16,2025K@0,0:vid1=720x480x16,2025K@0,0:osd0=720x480x16,1350K@0,0:osd1=720x480x4,1350K@0,0

    ------------------------------------------------------------------------------------------------------------------------------

    davincifb davincifb: dm_osd0_fb: 720x480x16@0,0 with framebuffer size 1350KB

    davincifb davincifb: dm_vid0_fb: 720x480x16@0,0 with framebuffer size 2025KB

    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 1350KB

    davincifb davincifb: dm_vid1_fb: 720x480x16@0,0 with framebuffer size 2025KB

    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

     

     

     

    TEST6:  used buffer arguments verbatim from SPRUG92 page 16

     

    ------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=720x480x16,2025K:vid1=720x480x16,2025K:osd0=720x480x16,1350K:osd1=720x480x4,1350K

    ------------------------------------------------------------------------------------------------------------------------------

    davincifb davincifb: dm_osd0_fb: 720x480x16@0,0 with framebuffer size 1350KB

    davincifb davincifb: dm_vid0_fb: 720x480x16@0,0 with framebuffer size 2025KB

    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 1350KB

    davincifb davincifb: dm_vid1_fb: 720x480x16@0,0 with framebuffer size 2025KB

    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

     

     

     

    TEST7:  reinstated larger 720x576 screen, but calculated exact max buffer sizes

     

    ------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=720x576x16,2430K:vid1=720x576x16,2430K:osd0=720x576x16,1620K:osd1=720x576x16,1620K

    ------------------------------------------------------------------------------------------------------------------------------

    davincifb davincifb: dm_osd0_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 1620KB

    davincifb davincifb: dm_vid0_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_vid0_fb: 720x576x16@0,0 with framebuffer size 2430KB

    davincifb davincifb: dm_osd1_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_osd1_fb: 720x576x16@0,0 with framebuffer size 1620KB

    davincifb davincifb: dm_vid1_fb: Initial window configuration is invalid.

    davincifb davincifb: dm_vid1_fb: 720x576x16@0,0 with framebuffer size 2430KB

    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

     

    (runtime:)

    Decode demo started.

    DavinciDisplay DavinciDisplay.1: Display Manager failed to allocate layer

    DavinciDisplay DavinciDisplay.1: Unable to configure video layer for id = 0

    Error: Failed to create display device

  • 0 in reply to Tiger Team4268
    Intellectual 760 points

    The above was "cut and pasted" from a Mw word document. The leading columns were cut off, but I think they are still readible. I can post an ascii text version if needed. - gary

  • 0 in reply to Tiger Team4268
    TI__Mastermind 37340 points

    Tiger Team said:
    console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=192.168.1.20:/home/gwebb/workdir/filesys,nolock mem=118M davinci_enc_mngr.ch0_mode=ntsc davinci_enc_mgr.ch0=COMPOSITE
     
    TEST2:  removed frame buffer dimensions
     
    ------------------------------------------------------------------------------------------------------------------------------
    video=davincifb:vid0=0,2500K:vid1=0,2500K:osd0=720x576x16,2025K
    ------------------------------------------------------------------------------------------------------------------------------
    davincifb davincifb: dm_osd0_fb: Initial window configuration is invalid.
    davincifb davincifb: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 2025KB
    davincifb davincifb: dm_vid0_fb: 0x0x16@0,0 with framebuffer size 2500KB
    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 675KB
    davincifb davincifb: dm_vid1_fb: 0x0x16@0,0 with framebuffer size 2500KB
    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window. 

    I tried your case #2 (what is suggested in GSG) and can confirm I get the same messages in my boot log, but this does not prevent me from running the demos; I was able to run encodedecode demo successfully (including OSD and blending).  I am guessing the results of the messages is a bit of conflict about which driver (V4L2 or FBDev ) owns the video back end OSD hardware as both of these Linux Standards support display capabilities.  I would disregard the messages for now. 

    Also, if you see 720x480 working and not really want to see 720x576, you may want to change davinci_enc_mngr.ch0_mode= to 'pal' instead of 'ntsc', which implies you have a pal camera and display.  Otherwise, even though some of the frame buffers may support 720x576, the demos (and probrably drivers) will make the system default to 720x480.  Just my two cents; this release is pretty new and I am also learning as I go.

  • 0 in reply to Juan Gonzales
    Intellectual 760 points

    Juan,Thanks for the response.

     

    yes, only the scenarios that impact the vid0 or vid1 buffers will stop the demo from working.  But I did not see the OSD overlay on the demo like I used to. Has the demo changed, or is the OSD not working, even on test #2. Can you check it on your setup?

    What is preventing us from selecting our own screen size? Is it being error checked now? where is the list of "allowed" sizes. I can not find any restrictions other than the 40Mb max and three-deep limitations documented.

    Yes, I had just suggested that our programmer try changing to 720x480 on our target hardware for bringup. ( I am not quite sure why it had ended up at 720x576 because we are not PAL, but I noticed the other related post had the exact same dimensions).

     

     

     

  • 0 in reply to Tiger Team4268
    Intellectual 760 points

    BTW, it was suggested that I follow the "Get Started Guide" to the letter...  I did.

    The 720x576 bootarg that does not work at all is DIRECTLY from the GSG sprue66f document on the follwing pages.
    The 720x480 bootarg is not listed a single time!!!

    Page 44: 4-12 : Section 4.3.8    Testing the shared File system
    Page 45: 4-13 : Section 4.3.9    Configuring the Boot Setup for PAL Video Users
    Page 51: 4-19 : Section 4.7       Booting the New Linux Kernel
    Page 65: A-9 :   Section A.4.1    Booting from Flash Using the EVM's Hard Drive File System
    Page 65: A-9 :   Section A.4.2    Booting via TFTP Using the EVM's Hard Drive File System
    Page 66: A-10 : Section A.4.3    Booting from Flash Using NFS File System
    Page 66: A-10 : Section A.4.4    Booting via TFTP Using NFS File System
    Page 76: A-13 : Section A.6.2    Configure EVM for NFS Root Mount

    In addition to the 720x576 resolution fatlly keeping the demo from running, even the default bootargs and the example on page 15, section 3.4.1, "Configure FBDev Display Windows"  of the SPRUG92 Video Driver Users Guide  will result in the OSD not being displayed. Surely someone has gotten the OSD to display.

    This question was asked in this forum on June 5th, but never answered satisfactorily. I assume someone helped the person out. How was it resolved? and When?  and how was it communicated to the field and customers?

    Now that I see the 720x480 mode works, we are not blocked, but both these problems need a resolution.



  • 0 in reply to Tiger Team4268
    TI__Mastermind 37340 points

    As I noted in my previous post, I did test OSD and blending as well while running encodedecode demo.  BTW, it had been a while since I ran this demo on DM6446 so I read the encodedecode.txt file which accompanies the demo.  There you can see that in the current dvsdk demos, you need to use '-o' option to turn ON OSD; otherwise demos display statistics via printf to standard output; this was not required in the previous DVSDK demos...Ideally, you would expect the demos and the bootargs to be backward compatible and believe me, I have given this feedback to our internal teams in the past; unfortunately, sometimes when making major moves (e.g. mv4 to mv5), this may prove challenging and sometimes backward compatibility is broken.  This is why when things do not work, the first thing I do is read accompanying docs (GSG, encodedecode.txt...).  I am happy to share what I know, and I am sure there are lots of stuff I have yet to learn about this dvsdk release

    That said, I want to attempt and set proper expectations.  Forums are a community supported model; there are lots of TIers participating here (FAEs, factory engineers, marketing folks...),  but please note that most if not all have their current role to tend to.  This means that although we dedicate much time and resources to these forums, it is not the end-all process of making sure all support questions are answered.  If you need more immediate support, you need to work with your local sales representative.  To my knowledge there is no guarantee forum questions will be answered within a particular time-frame or even be answered at all, we all pitch in and try to answer as much as possible.  But you also have www.ti.com/support for submitting trackable support questions as well as your local sales representative if you need more immediate support.

     

  • 0 in reply to Juan Gonzales
    Intellectual 760 points

    Juan, 

    There is NO mention of the  "-o" option in the most current sprue66f GSG. I thought that the lack of the default OSD may have been intentional, but did not think to go looking for the txt file ( I had read them on the previous release and was not thinking)

    The OSD display is still not resolved. I have not found an environment combination yet that supports the "-o" option.

    root@192.168.1.108:/opt/dvsdk/dm6446# ./decode -v data/videos/vette2.mpeg4  -s d
    ata//sounds/vette2.g711  -O component -o
    Decode demo started.
    Error: Failed to create osd window device
    Error: Failed to create UI
    root@192.168.1.108:/opt/dvsdk/dm6446#

    I have also discovered that setting up a osd1 buffer in the bootargs will cause the demo not to run. ... sigh

    I would also like to know where the screen resolution restrictions in the bootarg davincifb parameters is documented, got any ideas? It is not SPRUG92 or SPRUE99F.

    Regarding the E2E forum, a customer can not "search" your internal support issue tracking system. The closest tool given is the E2E forum. I had tried to use the support@ti.com before and found replies to take days or weeks and then to be dismissed without closure. I was told to use the E2E forum and the Wiki.  Something like this will cost the Davinci development community hundreds if not thousands of lost manhours simply because there is a not a TI-controlled issue tracking system available to developers. We found this problem on saturday morning with a deadline looming. I knew it was a long-shot, but I was hoping that someone who had tripped over this would offer a suggestion. It wsnt until I went back to a virgin build on a EVM, that we could put our arms around the problem (not that we understand the extent yet)

    If we had this problem and the user in June post had this problem, I would have expected someone at TI to have at least duplicated the defect and then offered a work-around. ... you have a lot of people trained to at least try to search the forum. It would have personally saved you work months later when the same problem resurfaces over and over. ..  and then I was told to follow the OSG exactly without someone at TI understanding what the problems were ... heck, THE "GSG BIBLE" says to use 720x576, so imagine anyone actually follows the dpocumentation will have this problem and lose hours because of it. ... or perhaps they will find this forum post :)

    We do not have this resolved, especially since we do not know the restrictions and allowed bootarg parameters. but I will move the discussion out of this forum into a different support mechanism.

     

  • 0 in reply to Tiger Team4268
    TI__Mastermind 37340 points

    I completely understand your frusturation and I am not suggesting our system is perfect; just trying to manage expectations to hopefully help avoid future frusturations for you.  I am ramping up on this new release myself and will certainly help answer anything I can, but I also have other tasks on my plate that do not always allow me to spend the time I need to become really familiar with this release yet.  In my experience, the GSG is a good starting point and seems to have worked for me thus far.... if you want to know more specifics, the PSP docs should provide more detailed driver supported features/constraints, including resolutions supported.  At this moment, I have not corroborated if these docs are broken or not (I would hope not), but if they are we will certainly take action to correct this.  Unfortunately, I know my comments to not do much to alleviate your situation; but hopefully it helps point you to the right path to get more immediate support. 

  • 0 in reply to Tiger Team4268
    TI__Mastermind 37340 points

    I just tried enabling OSD on decode demo and it worked for me

    u-boot variables:

    U-Boot 1.2.0 (Feb  2 2008 - 23:52:55)

    DRAM:  256 MB
    MY AMD Flash: 16 MB
    In:    serial
    Out:   serial
    Err:   serial
    ARM Clock :- 297MHz
    DDR Clock :- 162MHz
    MSP430 Firmware does not support AM/PM Feature
    Hit any key to stop autoboot:  0
    DaVinci EVM # printenv
    bootdelay=3
    baudrate=115200
    serverip=156.117.95.15
    nfspath=/home/user/dvsdk_2_00_00_22/filesys
    ipaddr=dhcp
    myip=dhcp
    bootcmd_tftp=dhcp;bootm
    bootcmd=dhcp;bootm
    bootfile=uImage-dm6446
    bootargs=console=ttyS0,115200n8 noinitrd rw ip=dhcp root=/dev/nfs nfsroot=156.11
    7.95.15:/home/user/dvsdk_2_00_00_22/filesys,nolock video=davincifb:vid0=0,2500K:
    vid1=0,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_mode=ntsc davinci_enc_mn
    gr.ch0_output=COMPOSITE mem=118M
    stdin=serial
    stdout=serial
    stderr=serial
    ethaddr=00:0e:99:02:51:f4
    videostd=ntsc

    Environment size: 537/131068 bytes

    once I got my linux prompt:

    oot@156.117.95.149:~# cd /opt/dvsdk/dm6446/
    root@156.117.95.149:/opt/dvsdk/dm6446# ./loadmodules.sh
    CMEMK module: built on Jul 14 2009 at 19:13:55
      Reference Linux version 2.6.18
      File /home/user/dvsdk_2_00_00_22/dvsdk/linuxutils_2_23_01/packages/ti/sdo/linu
    xutils/cmem/src/module/cmemk.c
    ioremap_nocache(0x87600000, 10485760)=0xc8000000
    allocated heap buffer 0xc8000000 of size 0x2c000
    cmem initialized 5 pools between 0x87600000 and 0x88000000
    dsplinkk: no version for "struct_module" found: kernel tainted.
    DSPLINK Module (1.61.03) created on Date: Apr 16 2009 Time: 18:22:23
    root@156.117.95.149:/opt/dvsdk/dm6446# ./decode -v data/videos/davincieffect_ntsc.mpeg4 -a data/sounds/davincieffect.aac -o
    Decode demo started.

    FYI, I did not try COMPONENT output on demo because by default, our DM6446 EVM does not have component connectors; you would need a daughter card in order to support this.

  • 0 in reply to Juan Gonzales
    Intellectual 760 points

    Juan, thanks for the followup. I noticed that you even were using the "720x576" bootarg without issue. (?)  I will try yours in a few minutes and see what happens. Now that you helped with the demo "-o" parameter, I know how to check.

    ------------------

    Did you rebuild your kernel, or is this "as shipped"?  I carefully followed the instructions of how to install/upgrade to the MV5 release up until it had me rebuilding the kernel and SVDSK. The instructions were clear and I had no problem getting a MV5 bootable system on the EVM.  The intructions seemed to stop short of the final step getting the demos themselves loaded and I did not  want to add a variable by rebuilding, so I used the overlay.tar.gz  and  mvltarget5_0_0801921_update.tar.gz  packages that I found at   http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_00/latest/index_FDS.html.  My understanding was that these would have been the same demos that were on the 2.0 hard disk.  With the exception of the davincifb bootargs, things went well.  I mentioned this in the chance that it provides you with a clue of what is going on.

    My linux programmer did rebuild his kernels (he has tried both the MV5 2.6.18 as well has several other GIT releases) and had the same problem with the 720x576 and OSD issues. He found it first. I was simply trying to recreate and duplicate with a "fresh" 2.00 release. Which I did.

    The customer in the related post had the exact same symptoms. Do you have a way of checking with him or his support resource to see how he resolved this.

    ----------------

    When you used my "test2" bootargs earlier, were you able to invoke the OSD in the demo?

    ---------------

    BTW.  Our SD EVM has both composite and component video. Both video buffers work as long as I specifically state 720x480. So the COMPOSITE vs COMPONENT appears immaterial.  I will try the THS8200 daughter card later, but one step at a time.

     

    - Gary

     

     

  • 0 in reply to Tiger Team4268
    Intellectual 760 points

    Juan,  dont think this has any relevance, but I noticed that your loadsh path is completely different than mine.

     

    root@192.168.1.108:/opt/dvsdk/dm6446# ./loadmodules.sh
    CMEMK module: built on May 26 2009 at 09:30:32
      Reference Linux version 2.6.18
      File /db/atree/library/trees/linuxdemos/linuxdemos-d28x/imports/DEMO_common/linuxutils_2_23_01/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.c
    ioremap_nocache(0x87600000, 10485760)=0xc8000000
    allocated heap buffer 0xc8000000 of size 0x2c000
    cmem initialized 5 pools between 0x87600000 and 0x88000000
    dsplinkk: no version for "struct_module" found: kernel tainted.
    DSPLINK Module (1.61.03) created on Date: May 26 2009 Time: 09:35:23

     

  • 0 in reply to Tiger Team4268
    TI__Mastermind 37340 points

    Tiger Team said:

    Did you rebuild your kernel, or is this "as shipped"?  I carefully followed the instructions of how to install/upgrade to the MV5 release up until it had me rebuilding the kernel and SVDSK. The instructions were clear and I had no problem getting a MV5 bootable system on the EVM.  The intructions seemed to stop short of the final step getting the demos themselves loaded and I did not  want to add a variable by rebuilding, so I used the overlay.tar.gz  and  mvltarget5_0_0801921_update.tar.gz  packages that I found at   http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_00/latest/index_FDS.html.  My understanding was that these would have been the same demos that were on the 2.0 hard disk.  With the exception of the davincifb bootargs, things went well.  I mentioned this in the chance that it provides you with a clue of what is going on.

    The customer in the related post had the exact same symptoms. Do you have a way of checking with him or his support resource to see how he resolved this.

    ----------------

    When you used my "test2" bootargs earlier, were you able to invoke the OSD in the demo?

    --------------- 

    Gary,

    Originally, I tried it with the pre-built binaries found under dvsdk_2_00_00_22/PSP_02_00_00_140/bin directory.  But since then, I have also tried it with the uImage (Linux kernel) I re-built myself per GSG.  Both work fine for me.  I did not use the overlay.tar.gz or mvltarget5_0_0801921_update.tar.gz  as I do not believe this are mentioned in GSG (or at least I did not make it that far). 

    I have not tried GIT kernel, but only kernel which comes with DVSDK trying to stick as close as possible to GSG.

    Unfortunately, I have the same access to other external customers in the forums as you do.  This customer replied to your query suggesting he went back to mv4; I have followed up with this customer to find out more details of the issues he was having.  Hopefully we will find out more.

    with regards to your test2 scenerio, I think I may have read it too quickly.  What I actually tried were the setting in my previous post which should match GSG.  I just noticed that your test 2 scenerio uses 720x480 instead of 720x576; I have been using 576 all this time

     

  • 0 in reply to Tiger Team4268
    TI__Mastermind 37340 points

    Tiger Team said:

    Juan,  dont think this has any relevance, but I noticed that your loadsh path is completely different than mine.

     

    root@192.168.1.108:/opt/dvsdk/dm6446# ./loadmodules.sh
    CMEMK module: built on May 26 2009 at 09:30:32
      Reference Linux version 2.6.18
      File /db/atree/library/trees/linuxdemos/linuxdemos-d28x/imports/DEMO_common/linuxutils_2_23_01/packages/ti/sdo/linuxutils/cmem/src/module/cmemk.c
    ioremap_nocache(0x87600000, 10485760)=0xc8000000
    allocated heap buffer 0xc8000000 of size 0x2c000
    cmem initialized 5 pools between 0x87600000 and 0x88000000
    dsplinkk: no version for "struct_module" found: kernel tainted.
    DSPLINK Module (1.61.03) created on Date: May 26 2009 Time: 09:35:23

    I suspect this may have to do with the file system you are using; I would suggest using the one found under montavista/pro/devkit/arm/v5t_letarget instead of the one under mvltarget5_0_0801921_update.tar.gz 

     

     

  • 0 in reply to Juan Gonzales
    Intellectual 760 points

    [:D]

    Juan,  bottom line ... I have both video, sound, and OSD ... your davincifb bootarg works for me (although there is still an OSD warning at boot time)

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=0,2500K:vid1=0,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_mode=ntsc davinci_enc_mngr.ch0_output=COMPOSITE

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    davincifb davincifb: dm_osd0_fb: Initial window configuration is invalid.
    davincifb davincifb: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 2025KB
    davincifb davincifb: dm_vid0_fb: 0x0x16@0,0 with framebuffer size 2500KB
    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 675KB
    davincifb davincifb: dm_vid1_fb: 0x0x16@0,0 with framebuffer size 2500KB
    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

     

    If I change your OSD argument to 720x480, then one of the two boot warnings goes away and the video and OSD still works:

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=0,2500K:vid1=0,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_mode=ntsc davinci_enc_mngr.ch0_output=COMPOSITE

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    davincifb davincifb: dm_osd0_fb: 720x480x16@0,0 with framebuffer size 2025KB
    davincifb davincifb: dm_vid0_fb: 0x0x16@0,0 with framebuffer size 2500KB
    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 675KB
    davincifb davincifb: dm_vid1_fb: 0x0x16@0,0 with framebuffer size 2500KB
    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

     

    If , however, I explictly specify the vid0 and vid1 arguments to be 720x576 as specified in the GSG , then the video demo does NOT work, though the OSD is displayed

    -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=720x576x16,2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_mode=ntsc davinci_enc_mngr.ch0_output=COMPOSITE

    -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    (boot time:)

    davincifb davincifb: dm_osd0_fb: Initial window configuration is invalid.
    davincifb davincifb: dm_osd0_fb: 720x576x16@0,0 with framebuffer size 2025KB
    davincifb davincifb: dm_vid0_fb: Initial window configuration is invalid.
    davincifb davincifb: dm_vid0_fb: 720x576x16@0,0 with framebuffer size 2500KB
    davincifb davincifb: dm_osd1_fb: 720x480x4@0,0 with framebuffer size 675KB
    davincifb davincifb: dm_vid1_fb: Initial window configuration is invalid.
    davincifb davincifb: dm_vid1_fb: 720x576x16@0,0 with framebuffer size 2500KB
    davincifb davincifb.0: dm_osd0_fb: Failed to obtain ownership of OSD window.

    (run time:)

    root@192.168.1.108:/opt/dvsdk/dm6446# ./decode -v data/videos/vette2.mpeg4 -s data/sounds/vette2.g711 -o
    Decode demo started.
    DavinciDisplay DavinciDisplay.1: Display Manager failed to allocate layer
    DavinciDisplay DavinciDisplay.1: Unable to configure video layer for id = 0
    Error: Failed to create display device
    root@192.168.1.108:/opt/dvsdk/dm6446#

     

    =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

    • It appears that explictly specifying a 720x576 resolution in theMV5  bootargs for vid0/vid1 is problematic.(contrary to the SPRUE66F and SPRUG92 documents)
      •  perhaps while the boot warnings are a MV5 symptom, the runtime failure is actiually a symptom the new  demo application version
      •  either way, the documentation(s) needs correction
    • It also appears that specifying a 720x576 OSD resolution will result in a boot error, but the demo still works.
    • It also appears that the davincifb bootargs are "touchy" and warrant a closer look at why these explicit arguments worked on MV4  but not MV5.

    =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

     

  • 0 in reply to Tiger Team4268
    TI__Mastermind 37340 points

    Tiger Team said:

    Juan,  bottom line ... I have both video, sound, and OSD ... your davincifb bootarg works for me (although there is still an OSD warning at boot time)

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    video=davincifb:vid0=0,2500K:vid1=0,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_mode=ntsc davinci_enc_mngr.ch0_output=COMPOSITE

    --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    If , however, I explictly specify the vid0 and vid1 arguments to be 720x576 as specified in the GSG , then the video demo does NOT work, though the OSD is displayed

    I am glad to hear you made some progress; however, I am still confused about what you claim the GSG says and what I am seeing and would like to clear this up for the benefit of future readers.  If our GSG does indeed suggest faulty values, this is something we definitely want to correct.  I have done a search thru the GSG corresponding to dvsdk release 2.00.00.22 (sprue66f.pdf) and I cannot find any instance of bootargs that suggests any other values for vid0 and vid1 than the ones I used (video=davincifb:vid0=0,2500K:vid1=0,2500K) which I copied and pasted from GSG.  You can see my confusion as I keep referring readers of the post to GSG, and you keep suggesting GSG is not working. 

    Can you help clear this up?  Maybe pointing me to where in the GSG you are seeing vid0 and vid1 being set to 720x576?  Is it possible you are looking at an old GSG?  It is entirely possible I am overlooking something and I would like to clear this up for future readers of this post.

  • 0 in reply to Juan Gonzales
    Intellectual 760 points

    Juan, this is a duplicate from a response from the other thread, but made here also for completeness.

    I dont think I have your email anymore. if you provide it or send it to me, I can forward you the document version that I have if you can not find it with the links below.

    -----------------------------------------------------------------------------------------------------------------------------------------------

    Juan, this is really weird, your sprue66f  and mine are different????   I just picked up on that possibility .  I had run into a case on the THS8200 where there were different datasheets in distribution with the exact same document control number (which is an ISO compliance no-no)

    Mine is named :TMS320DM6446 DVEVM v2.0 Getting started Guide dated May 2009. Is yours? It was last modified on May 29, 2009 and  can be found both in the  dvdsk_2_00_00_22/docs/spruef22.pdf  directory and at http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_00/latest/exports//dm6446_2_00_00_22_release_notes.pdf


    The 720x576 bootarg that does not work at all is DIRECTLY from the GSG sprue66f document on the follwing pages.
    The 720x480 bootarg is not listed a single time!!!

    Page 44: 4-12 : Section 4.3.8    Testing the shared File system
    Page 45: 4-13 : Section 4.3.9    Configuring the Boot Setup for PAL Video Users
    Page 51: 4-19 : Section 4.7       Booting the New Linux Kernel
    Page 65: A-9 :   Section A.4.1    Booting from Flash Using the EVM's Hard Drive File System
    Page 65: A-9 :   Section A.4.2    Booting via TFTP Using the EVM's Hard Drive File System
    Page 66: A-10 : Section A.4.3    Booting from Flash Using NFS File System
    Page 66: A-10 : Section A.4.4    Booting via TFTP Using NFS File System
    Page 76: A-13 : Section A.6.2    Configure EVM for NFS Root Mount

    BTW, we can not run NFS on the target system. There is no ethernet on that board. That is a completely unrelated topic.  What we are seeing in this thread is found on two different good ole Spectrum digital DM6446 EVMs, with MV5 DVSDK 2.0 code found at http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/targetcontent/dvsdk/DVSDK_2_00/latest/index_FDS.html




  • 0 in reply to Tiger Team4268
    Intellectual 760 points

    I also see a Spectrum Digital Document number 508168-0001D on the very last page(76) of the sprue66f document.

  • 0 in reply to Tiger Team4268
    TI__Mastermind 37340 points

    Looks like we are both looking at the same exact doc but somehow seeing different bootarg recommendations; perhaps a third or fourth opinion may help.  Also, in an effort to reduce e-mail spam, we should probrably continue our discussion in one thread and post a final message on all the rest that refer to the thread where we will continue our discussion.  I will let you pick which thread you want to continue working on.

  • 0 in reply to Tiger Team4268
    Intellectual 760 points

    Juan, I am going to have to apologize and eat crow ... you are correct, the spruef66F document includes the 720x576 resolution for the OSD, but removed it from the vid0 and vid1 arguments. The older spruef66D (1.30) does have the explicit resolution included, but it had been removed in the newer "F" release. I had both documents pulled up and all the parameters blurred in my mind on more than one occasion.

    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    So the new (2.0) GSG video bootarg is as you stated ..   video=davincifb:vi0=0,2500K:vid1=0,2500K:osd0=720x576x16,2025K  and if used and typed

    correctly, will permit the default TI demo to run fine.

    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    That said..

    • I would argue that the OSD resolution should be removed also as it gives a boot warning, but it is a nit and not fatal as is the other OSD boot time warning.
    • The "command.txt" example file in the dvsdk_2_00_00_22/PSP_02_00_00_140/docs/commands.txt is now depreciated and should be corrected
    • The basic structure of the bootarg though is documented in SPRUG92 which is contained in the dvsdk_2_00_00_22/PSP_02_00_00_140/docs/SPRUG92.pdf document
      • It specifically states on page 15 that the resolution is part of the syntax, but I can not get its example to work with the demo. I am assuming this is not the driver, but the app now checking (?)
      • I would like to see the full davincifb bootarg as defined in SPRUG92 configured to support the demo, but that is beyond the GSG,  its demo, and this post thread..
      • This is a work issue for me to figure out ... down the road. 

    Bottom line ... follow the GSG ... user error .... mine

     

  • 0 in reply to Tiger Team4268
    TI__Mastermind 37340 points

    Gary,

    Thank you for the update; I was beginning to think my eyes were decieving me ... :).  I am glad we straightened this out primarily for the benefit of others who may read this post. 

    So far, I have only verified the GSG, I will look at the command.txt and sprug92.pdf as time permits and will provide feedback to our internal teams if necessary if any fixes are needed. 

    Please keep the constructive feedback coming; I will help with what I can.  As you noted, it is on our best interest to correct these basic docs as others are likely to stumble across the same issues.  Hopefully, we can maintain better backward compatibility with our software going forward that should eliminate having to read new revs of docs, I have provided this feedback today based on another customer's feedback.  Believe it or not, we care about your feedback and ways in which we can improve.  Thank you for your patience.

  • 0 in reply to Juan Gonzales
    Intellectual 760 points

    I continue to see related posts to this one. I have also seen weird fbdev behaviour on other demo/apps/examplesathat seems related to the new bootargs

    The bottom line for anyone having similar problems is to follow the sprue66f GSG exactly when first starting out with the EVM demo.

    The bootargs required to run the new DVSDK2 demo have changed from the previous DVSDK1 demos. It has bothered me that I have not understood why.

    ... Not knowing finally bit me this past week:

    The vid0 and vid1 bootargs need to be reserved (for v4l use), but not claimed by the fbdev driver. The new dvevmdemo application uses DMAI and V4L2 (Video For Linux)

    A newer thread that may help explain can be found at

    http://e2e.ti.com/forums/p/9927/39465.aspx#39465