DM6446 - Proper bootargs for video

Glen Fine said:

 Davici AEW Driver cannot be loaded
 VIDEO PORT is not enabledData Flow path from CCDC is disabled

 Davinci AF driver cannot be loaded
 VIDEO PORT is not enabled
 CCDC needs to be configured

This sounds like something you could ignore for most applications, unless you were using a camera that you were going to setup to use the auto exposure and white balancing driver or the auto focus driver, do you have a digital camera hooked up to the DM6446? I have not used these drivers myself as I lack the hardware to really leverage them, but I suspect there are updated documents on these drivers in the PSP directory that may help to explain why they would be failing now (I don't have an install in front of me at the moment to check).

Glen Fine said:

Is there a document I can refer to that assists in setting up the bootargs for the video portion?

The bootargs that are given in the getting started guide should be valid for the default kernel build, but if the default kernel build is deviated from (such as including the AEW and AF drivers) than you may need different bootargs, unfortunately I do not know what bootargs changes would be necessary, though the PSP documents should be able to help with that.

Bernie, thank you for your reply, but this is not the area that I am concerned with. 

Under MVL v4  the bootargs for setting up the framebuffer worked without a problem.  They were

setenv bootargs 'video=davincifb:vid0=720x576x16,2500K:vid1=720x576x16,2500K:osd0=720x576x16,2025K davinci_enc_mngr.ch0_output=COMPOSITE davinci_enc_mngr.ch0_mode=ntsc mem=120M console=ttyS0,115200n8 ip=dhcp root=/dev/nfs nfsroot=192.199.76.37:/root/workdir/filesys,nolock noinitrd rw'

Under MVL v5 the same u-boot bootargs do not work as the following errors are observed during bootup. 

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.

So the problem is that the same u-boot parameters are being used for MVL v5 as with MVL v4, but the same results are not being seen.

I have poured over the 'get started' docs, and any other documentation I can find via a google search about u-boot params, or how the video= line works, but to no avail.

So something has changed between MVL v4 and MVL v5 that is either not documented (or the document is not obvious) or this is a defect in the new MVL v5 / dvsdk v2_00_00_18 build.

Glen

Glen, did you ever get this resolved? We may be tripping over the same problem. - Gary

I have asked essentially the same question, but with more data, in a new post:

http://e2e.ti.com/forums/p/9036/34944.aspx#34944

No, we never got the problem resolved. 

The only communication I did have was someone in support at TI saying that they had it working on their DVEVM (Ours=dm6446 : Theirs=dm355).  Other than that our regular support tech had left TI for NXP, and we had to make decisions based on our short term prospects. Our main reason for moving to MVL v5 had to do with problems in MVL v4 handling Large Block Nand.  In our move forward to MVL v5 and DVSDK v2_00_00_22 we ran into other showstoppers.  The main showstopper was with our codecs (based on MVL v4) not working properly under MVL v5.

In the end we rolled back to MVL v4 and changed our design to use a supported Small Block Nand.

I'll follow your thread as there is a lot more info than I ever got.

Glen,

FYI, I do have this working with dvsdk_2_00_00_22 and our DM6446 EVM.  I used the bootarg values outlined on the GSG.

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

I am interested to find out more about the codec issues you were experiencing; was this with codec provided by TI?  Normally our codec release notes specify the software compatibility of our codecs against other software components; sometimes when we do major upgrades such as mv4 to mv5, major pieces of the software change, but new DVSDK should still have working codecs.  Maybe we just need to discuss and get you the right codecs..  Any information you can provide to help us improve this would be greatly appreciated.

Hi Juan,

The codec came from a third party (which TI uses for MPEG). It was the MPEG-2 codec with deinterlacing.  The problem, under MVL v5, was that while encoding we were able to 'see' sequence frames, but any other type of frame was invalidated with an ERUNTIME error.  The error did not reproduce under MVL v4.

We had conversations with the vendor of the codec. They had not upgraded to MVL v5 / DVSDK v2_00_00_22, and had no plans (at the time we were talking to them) to do so.

Thanks Glen. I was hoping that you had gotten it resolved on your own or off-line.

We had to move to MV5 because of the BBN issues and have tripped over what looks like the EXACT same issue that you had with the PSP 2.0 davincifb.

While Juan appears to have his setup working, we have two EVMs, each installed/built by two different engineers with the problem of the 720x586 resolution being problematic  and issues with the OSD.  We have also experimented with newer GIT kernels . I am quite sure this is a combination of an incorrect release binaries, new drivers,  and depreciated documentation. But I am scratching my head to find the controlling document that says what and why.

- Gary

Gary,

Have you tried the montavista file-system as opposed to the one on the tar.gz; I simply followed the GSG and got things to work.  bootargs have certainly changed since mv4 as well as demos; also, since you mention BBN, are you using our DM6446 EVM from SD (what the software was written for and tested with)?  If not, can you give this a try?

Juan,  I just updated the newer post with my latest finds. I have sucessfully run the video and OSD demo app using the minimal davincifb bootarg that you provided.

http://e2e.ti.com/forums/p/9036/35140.aspx#35140

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

• 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.

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

We are using the SD 6446EVMs, two of them. My programmer is also targeting a BBN target platform, but using the SD EVM as a parallel reference platform when he runs into a problem.

I am using the second EVM as a control check to duplicate and validate issues that he has. In this case, we both have the same problem, both on the two Generic SD EVM (using NFS) and the Target (using a NAND YAFFS2).

Since Glen had the same problem symptoms when he posted this thread in June, I assume that we do not have a one-off problem and that others have (or will) stumble across this symptom as well.

As I noted in the other post : http://e2e.ti.com/forums/p/9036/35151.aspx#35151; there seems to be confusion with what you are seeing in the GSG versus what I am seeing.  When I search for bootargs in GSG (sprue66F), all instances I find suggests 'video=davincifb:vid0=0,2500K:vid1=0,2500K' which are the settings I used.  It appears you are seeing something 720x576 being suggested for vid0 and vid1; if so can you tell us where in the GSG you are seeing this? 

Things worth noting:  I am using ext3 file system over NFS as opposed to YAFFS2 on NAND, though I suspect this is not the main root cause of the issues we are discussing in this thread.

I also appreciate your concern over Glen's older posts; to be honest, I cannot commit to answering every forum post, but the fact that you were another customer running into this issue did catch my attention and caused me to look into this a bit more.  (We do pay attention and look to resolve recurring issues!!!!).  I thank you for taking the time to point this out.  Now my concern is corraborating the basic GSG steps and software work (we do test dvsdks so I would be surprised if too many bugs fell thru the cracks); unfortunately, we (you and I) still seem to be experiencing different results and I believe this may cuase more confusion for anyone reading this thread.  If we can work together to resolve any differences and provide a consensus, this will likely be more helpful to anyone coming accross this thread.

Glen Fine said:

Hi Juan,

The codec came from a third party (which TI uses for MPEG). It was the MPEG-2 codec with deinterlacing.  The problem, under MVL v5, was that while encoding we were able to 'see' sequence frames, but any other type of frame was invalidated with an ERUNTIME error.  The error did not reproduce under MVL v4.

We had conversations with the vendor of the codec. They had not upgraded to MVL v5 / DVSDK v2_00_00_22, and had no plans (at the time we were talking to them) to do so.

 

Glen,

Is there a reason you used a third party MPEG2 codec instead of what comes with DVSDK?  DVSDK_2_00_00_22 comes with a codec server which includes a compatible MPEG2 codec with it.  Unfortunately, there is not much we can to about forcing third parties to upgrade to newer dvsdks, except maybe reconsider our relationship with that third party, but that will not be much help for you at this point.   Just wondering why you are not using the MPEG2 codec that comes with our DVSDK.

The vendor is the same vendor that TI uses for the same codec, Ittiam.  We desired items beyond the stock MPEG-2 codecs such as deintelacing (stream and live), and 12 mbps encoding speeds. So the diversion from the stock TI codecs was necessary.

I have to agree with Gary, there are bugs, and they need to be addressed.  I was once part of a support org and understand you have to be able to reproduce the problem in order to get someone to work it.  It seems to be unique to the DM6446 DVEVM , it seems to be unique to the video resolution 720x576x16, and it seems to be unique to....

MVL v5 (with the base patches)

DVSDK v2_00_00_22 with

bios_5_33_03
biosutils_1_01_00
framework_components_2_23_01
ceutils_1_06
cg6x_6_0_21
cg_xml_2_12_00
linuxutils_2_23_01
codec_engine_2_23_01
PSP_02_00_00_140
dm6446_dvsdk_combos_2_05
dmai_1_20_00_06
dsplink-1_61_03-prebuilt
dvsdk_demos_2_00_00_07
xdais_6_23
dvtb_4_00_08
xdctools_3_10_03
edma3_lld_1_05_00

If there is a deviation, in the list above from the tools, and binaries you may be using that might help point to the problem.  However, we did roll back to MVL v4 for the short term.  In the long term we would desire to move forward again after the problems we ran into are resolved.

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

I will post this on the other thread also for completeness. But since that thread has more example data, and is newer, I will try to use it

Gary,

It will certainly be weird if we have two versions of GSG with same doc number.  The links you posted above seem to be the release notes and not the GSG.  I did look in the GSG found in both the dvdsk_2_00_00_22/docs/ directory and the http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/S1SDKLNX/DVSDK_2_00/index_FDS.html URL and they both seem to match the GSG I have been using all along  and specify vid0 and vid1 as 'video=davincifb:vid0=0,2500K:vid1=0,2500K'.  I figure that even if our dvsdks installs and corresponding GSGs are different (doubt it), we should both be seeing the same exact GSG for DM6446 found under

http://software-dl.ti.com/dsps/dsps_public_sw/sdo_sb/S1SDKLNX/DVSDK_2_00/index_FDS.html;

I do not see vid0 and vid1 defined as 720x576; if you do, can you tell me which page.  I also want to get to the bottom of this different GSG issue, assuming there is one.  But first lets confirm we are both seeing the same GSG at the URL above.  Then we can proceed to figure out the source of the GSG you are seeing if indeed it is different.  I got the dvsdk installation files from the same link you did so unless someone swtiched the software downloads on us, I do not see why we would be seeing different docs on the same dvsdk install.

Juan is correct.  I am wrong. Follow the SPRUE66F  GSG davincifb example exactly and the demo should work.

I have not figured out the full syntax as specified in SPRUG92, but follow the "Get Started Guide" when first using the demo- Gary

See http://e2e.ti.com/forums/p/9036/35185.aspx#35185

- gary

Glen Fine said:

I have to agree with Gary, there are bugs, and they need to be addressed.  I was once part of a support org and understand you have to be able to reproduce the problem in order to get someone to work it.  It seems to be unique to the DM6446 DVEVM , it seems to be unique to the video resolution 720x576x16, and it seems to be unique to....

MVL v5 (with the base patches)

DVSDK v2_00_00_22 with

bios_5_33_03
biosutils_1_01_00
framework_components_2_23_01
ceutils_1_06
cg6x_6_0_21
cg_xml_2_12_00
linuxutils_2_23_01
codec_engine_2_23_01
PSP_02_00_00_140
dm6446_dvsdk_combos_2_05
dmai_1_20_00_06
dsplink-1_61_03-prebuilt
dvsdk_demos_2_00_00_07
xdais_6_23
dvtb_4_00_08
xdctools_3_10_03
edma3_lld_1_05_00

If there is a deviation, in the list above from the tools, and binaries you may be using that might help point to the problem. 

Hi Glen,

You list above excludes some directories (e.g. docs) but these are minor and should not prevent DVSDK from working.  All the major items you listed above match with the installation I am using. 

Also, as you may have already seen, Gary and I were able to conclude the GSG steps work.  I will have to check other docs to see if they need updating but the GSG should get you up and running... main take away is that things have changed from mv4 releases, hence sticking to GSG is key.  Thank you both for bringing this up. 

Juan:

I am able to get the encodedecode demo app to run on the DM6446EVM when I boot uboot from NOR flash, but not when I boot uboot from NAND flash. I am TFTP'ing uImage and then NFS mounting the FS. Can you verify if you get the same problem when booting from NAND? When booting from NOR, my S3 dip switches are 1010111110 and the CS2 jumper is on FLASH. When booting from NAND, my S3 dip switches are 0000111110 and the CS2 jumper is on NAND. I am using uboot rev 1.1.3.

The DVSDK distro I am using is:

MVL v5

DVSDK v2_00_00_22 with:

bios_5_33_03
biosutils_1_01_00
framework_components_2_23_01
ceutils_1_06
cg6x_6_0_21
cg_xml_2_12_00
linuxutils_2_23_01
codec_engine_2_23_01
PSP_02_00_00_140
dm6446_dvsdk_combos_2_05
dmai_1_20_00_06
dsplink-1_61_03-prebuilt
dvsdk_demos_2_00_00_07
xdais_6_23
dvtb_4_00_08
xdctools_3_10_03
edma3_lld_1_05_00