RE: OSD + V4L2 query
Thank you very much for your comments. Does the same apply for the DM6446? Virginia -Original Message- From: Karicheri, Muralidharan [mailto:[EMAIL PROTECTED] Sent: Fri 3/7/2008 4:53 PM To: [EMAIL PROTECTED]; Faro Maza, Virginia Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: OSD + V4L2 query I agree. DM355 VPFE doesn't have capability to blend text with video before capturing. It can only blend text/graphics with video using the OSD in the VPBE. Murali From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, March 07, 2008 11:46 AM To: [EMAIL PROTECTED] Cc: davinci-linux-open-source@linux.davincidsp.com Subject: RE: OSD + V4L2 query That is not possible (unless someone want to correct me). Your options are: - Put the text in the OSD buffer (/dev/fb/0) and it will be blended before output from VPBE - Draw the text onto the buffer in memory, using software - Add hardware to overlay the text before it goes into the VPFE. Just to note, the hardware (355 anyway) does not support blending OSD graphics before encoding video, if that is what you are trying to do. We have ended up using an external encoder chip to do this. From: [EMAIL PROTECTED] idsp.com [mailto:[EMAIL PROTECTED] x.davincidsp.com] On Behalf Of Faro Maza, Virginia Sent: 07 March 2008 15:43 To: davinci-linux-open-source@linux.davincidsp.com Subject: OSD + V4L2 query Hi all, I have been using the TI encode demo, where the video processing back end is used to display raw video frames (captured with the V4L2 driver) as well as an OSD layer of text in an LCD monitor. In the encode demo, each video frame is captured from /dev/video0 and then copied (using the hardware resizer) into /dev/fb/3. Simultaneously, dynamic data (e.g. CPU load) is written into the OSD window /dev/fb/0. The transparency is set through /dev/fb/2, which is opened as an attribute window. I would like to blend an OSD layer of text with my raw video before it is captured by the V4L2 driver. How can I do that? Many thanks, Virginia Faro-Maza American Dynamics Email: [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] Tyco Safety Products/CEM Systems Ltd. Registered in Northern Ireland: NI 25728. Registered Office: Unit 4 Ravenhill Business Park, Ravenhill Road, Belfast, BT6 8AW.. Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of the company. This email and any attachments are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender immediately and delete any copies in your possession. Racelogic is a limited company registered in England. Registered number 2743719. Registered Office 5 Little Balmer, Buckingham Ind Pk, Buckingham MK18 1TF. The information contained in this electronic mail transmission is intended by Racelogic Ltd for the use of the named individual or entity to which it is directed and may contain information that is confidential or privileged. If you have received this electronic mail transmission in error, please delete it from your system without copying or forwarding it, and notify the sender of the error by reply email so that the sender's address records can be corrected. The views expressed by the sender of this communication do not necessarily represent those of Racelogic Ltd. Please note that Racelogic reserves the right to monitor e-mail communications passing through its network ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: evm does not boot new kernel
Robert W. Kuhn wrote: Am Fri, 7 Mar 2008 18:02:30 +0530 schrieb Subbrathnam, Swaminathan: There seems to be no HDD connected though the bootargs assumed that the rootfs is on HDD. The 'root=/dev/hda1'-option is the same as with kernel 2.6.10?!?! The enviroment: DaVinci EVM # printenv bootdelay=3 bootcmd=setenv setboot setenv bootargs $(bootargs) video=dm64xxfb:output=$(video std);run setboot;bootm 0x205 stdin=serial stdout=serial stderr=serial ethaddr=00:0e:99:02:5c:3e videostd=pal bootargs=mem=64m console=ttyS0,115200n8 rw noinitrd ip=172.16.0.2 root=/dev/hda1 ipaddr=172.16.0.2 serverip=172.16.0.1 bootfile=uImage Robert The whole output while booting: Uncompressing Linux. done, booting the kernel. Linux version 2.6.24-davinci1 (...) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #2 Fri Mar 7 12:36:21 CET 2008 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 Machine: DaVinci EVM Memory policy: ECC disabled, Data cache writeback DaVinci DM6446 variant 0x0 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: mem=64m console=ttyS0,115200n8 rw noinitrd ip=172.16.0.2 ro ot=/dev/hda1 PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 61860KB available (2644K code, 239K data, 120K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok net_namespace: 64 bytes NET: Registered protocol family 16 DaVinci: 71 gpio irqs NET: Registered protocol family 2 Time: timer0_1 clocksource has been installed. IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler anticipatory registered (default) Setting Up Clocks for DM420 OSD Console: switching to colour frame buffer device 90x30 fb0: dm_osd0_fb frame buffer device fb1: dm_vid0_fb frame buffer device fb2: dm_osd1_fb frame buffer device fb3: dm_vid1_fb frame buffer device i2c_davinci i2c_davinci.1: timeout waiting for bus ready .. i2c_davinci i2c_davinci.1: timeout waiting for bus ready Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled serial8250.0: ttyS0 at MMIO 0x1c2 (irq = 40) is a 16550A console [ttyS0] enabled RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize TI DaVinci EMAC: MAC address is deadbeaf TI DaVinci EMAC Linux version updated 4.0 TI DaVinci EMAC: Installed 1 instances. console [netcon0] enabled Linux version 2.6.24-davinci1 (...) (gcc version 4.2.1 (CodeSourcery Sourcery G++ Lite 2007q3-51)) #2 Fri Mar 7 12:36:21 CET 2008 CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=00053177 Machine: DaVinci EVM Memory policy: ECC disabled, Data cache writeback DaVinci DM6446 variant 0x0 CPU0: D VIVT write-back cache CPU0: I cache: 16384 bytes, associativity 4, 32 byte lines, 128 sets CPU0: D cache: 8192 bytes, associativity 4, 32 byte lines, 64 sets Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16256 Kernel command line: mem=64m console=ttyS0,115200n8 rw noinitrd ip=172.16.0.2 ro ot=/dev/hda1 PID hash table entries: 256 (order: 8, 1024 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 8192 (order: 3, 32768 bytes) Inode-cache hash table entries: 4096 (order: 2, 16384 bytes) Memory: 64MB = 64MB total Memory: 61860KB available (2644K code, 239K data, 120K init) Mount-cache hash table entries: 512 CPU: Testing write buffer coherency: ok net_namespace: 64 bytes NET: Registered protocol family 16 DaVinci: 71 gpio irqs NET: Registered protocol family 2 Time: timer0_1 clocksource has been installed. IP route cache hash table entries: 1024 (order: 0, 4096 bytes) TCP established hash table entries: 2048 (order: 2, 16384 bytes) TCP bind hash table entries: 2048 (order: 1, 8192 bytes) TCP: Hash tables configured (established 2048 bind 2048) TCP reno registered JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc. io scheduler noop registered io scheduler anticipatory registered (default) Setting Up Clocks for DM420 OSD Console: switching to colour frame buffer device 90x30 fb0: dm_osd0_fb frame buffer device fb1: dm_vid0_fb frame buffer device fb2: dm_osd1_fb frame buffer device fb3: dm_vid1_fb frame buffer device i2c_davinci i2c_davinci.1: timeout waiting for bus ready . i2c_davinci i2c_davinci.1: timeout waiting for bus
building gstreamer for DM6446
Apologies for the incorrect subject line last time. All, I'm trying to build gstreamer (as provided by TI) for the DM6446. I could not compile check-0.9.3, a lib required by gstreamer. In the log messages during compilation of check, I see the line where a compiler is supposed to run and then the archiver (ar) (to make the lib) runs. The first file the archiver tries archive is check.o. check.c is also the first file that the compiler is supposed to compile. I see something very suspicious where it tries to compile check.c : make[1]: Entering directory `/home/vijay/projects/GStreamer/opensource_build/check-0.9.3/src' source='check.c' object='check.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -c check.c source='check_error.c' object='check_error.o' libtool=no \ DEPDIR=.deps depmode=none /bin/sh ../depcomp \ arm_v5t_le-gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wwrite-strings -c check_error.c From the logs above, it appears that it doesn't even run the compiler. The back-slashes (\) at the end of the (2nd 3rd) lines makes the group of three lines into one line. I would correct the Makefile, but it isn't provided in the package from TI and is probably created by automake. Any ideas, anyone? Why would automake create an incorrect Makefile? How could I fix this? Appreciate any suggestions. Vijay Brian Jeff wrote: Stephen, The package was built for the latest Montavista kernel on the DM6446 DVEVM. Some additional work may be needed to port this to the latest community open source Linux kernel for DaVinci. Which OS version are you using? Thanks for pointing out the difference in the filename - I'll rename the file back to gstreamer_tibuild.tar.gz to be consistent with the docs. We'll also have a plain text or HTML doc up shortly on the Z3 Technology site. They are getting their CVS / GIT ready. Brian Jeff From: Stephen Berry [EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 8:59 AM To: Jeff, Brian Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: TI is releasing Gstreamer for DaVinci DM6446 to open source This is great - but: Well I just tried it. Of course it didn't compile - the glibc configure failed with: checking for growing stack pointer... configure: error: cannot run test program while cross compiling And the package gstreamer_tibuild.tar.gz wasn't on the web site for download. Anyone else have a problem building this? Steve From: Stephen Berry [EMAIL PROTECTED] Sent: Tuesday, January 22, 2008 8:59 AM To: Jeff, Brian Cc: davinci-linux-open-source@linux.davincidsp.com Subject: Re: TI is releasing Gstreamer for DaVinci DM6446 to open source Jeff, Brian wrote: Gstreamer for DaVinci TMS320DM6446 is now available for free download, delivered under LGPL, for the open source community. Several TI business units and engineering teams have been working with Gstreamer as a foundation for application demos and other project work; we want to make that port available to the open source community to enable development and innovation on the DaVinci platform. The completed port for the DaVinci DM6446 DVEVM is available at http://focus.ti.com/dsp/docs/dspsplash.tsp?contentId=3100 and at http://linux.davincidsp.com http://linux.davincidsp.com/ under the 'downloads' link. This Gstreamer port can be used with TI codecs, 3rd party codecs, or your own xDM / xDAIS compliant codecs. A companion package of TI digital media software decoders (licensable object code) is provided along with the Gstreamer open source release; the companion package includes codec engine, and some codec servers supporting video and audio decoding. An application note accompanies the download, and describes the build process and developer entry points. We encourage the use of this framework for projects on the DaVinci-based devices. The download site describes the maintainer for this project, Z3 technologies. Z3 will be hosting the project under GIT version control within the next few weeks. The website above will contain a quarterly snapshot of the project at it evolves. The following group of TI developers contributed their efforts to porting the Gstreamer project to DaVinci for this release: Rishi Bhattacharya (original port) Vasant Kumar Easwaran (Complete revamp and bugfixes, port on Davinci) Pratheesh Gangadhar (Complete revamp and bugfixes + plugins, ports) Yashwant Vijaykumar (Complete revamp and bugfixes + plugins, ports) Prateek Bansal and Isara Indra (port to Montavista Linux, addition of cross-compile functionality, final integration, development of app note) We would also like to thank the community of developers at (http://gstreamer.freedesktop.org/) for creating such a powerful and flexible AV framework; it has been a
