Re: [PATCH] ARM: Davinci: port video resizer driver from kernel 2.6.10 to kernel 2.6.23
On Tue, 2008-03-18 at 18:00 +0100, Dirk Behme wrote:
> steven.zhang wrote:
> > Thanks so much. I have fixed things as your suggestion before and
> > resubmit .
> >
> > patches apply to git://source.mvista.com/git/linux-davinci-2.6
> > TAG: pre-2.6.24-merge
> > git apply 01-resizer-driver-supported-by-TI.patch
> > git apply 02-port-resize-driver.patch
>
> Many thanks! Some comments though ;)
>
> - You created the patches with strip level 2 (as I already mentioned,
> this "a/" and "b/" directory level stuff). Standard is 1. I had to
> find out how to switch my patch tool (quilt) to strip level 2 to be
> able to apply your patches. But yes, if I did this, both patches
> apply cleanly. Thanks!
>
> - 01-resizer-driver-supported-by-TI.patch isn't checkpatch fixed.
> Seems that you tried to fix 02-port-resize-driver.patch, but now there is
>
> ERROR: need a space before the open brace '{'
> #318: FILE: linux-2.6.23/drivers/char/davinci_resizer.c:1549:
> + if (misc_register(&resizer_device)){
>
> You really should try ./scripts/checkpatch.pl
> /02-port-resize-driver.patch in Linux kernel main directory.
> It's quite easy.
>
> Regarding sending patches:
>
> - Don't forget a Signed-off-by
>
> - If you send more than one patch (as it is the case for this), you
> should send three separate mails (for two patches ;) ). The first
> (0/2) with a general description what the patches are about. Here you
> can write everything you like. Then two mails with the two patches
> (1/2 and 2/2) with the signed of by and the exact description of this
> patch. This text then goes into git. E.g.
>
> [PATCH 0/2] ARM: DAVINCI: port video resizer driver from kernel 2.6.10
> to kernel 2.6.23
>
> This patch series
>
> [PATCH 1/2] ARM: DAVINCI:
>
>
>
> Signed-off-by: ...
>
> Attachment: 01-resizer-driver-supported-by-TI.patch
>
> PATCH 2/2] ARM: DAVINCI:
>
>
>
> Signed-off-by: ...
>
> Attachment: 02-port-resize-driver.patch
>
> (Attachments should have *no* checkpatch complains any more and should
> have strip level 1)
>
> Regards
>
> Dirk
>
> Btw: I did this in private mail. Normally it is better to do such
> stuff publically on the list. Would this be okay for you? Or is it
> better to discuss this in private?
>
Dirk,
Thanks for the detailed description on the steps, and thanks for even
presenting this private conversation. ;-)
In general, I think it is better to discuss publicly (I see people are
asking these same questions and/or making these same mistakes over and
over), it benefits everyone by publicly going over the mistakes or
deficiencies. I wonder if these steps have been posted centrally
somewhere (digging up the ML is no fun).
Speaking of the patch itself, Steven was helping to push the original
patch I did, so I am the one who should take the blame. ;-)
Steven, please continue to follow Dirk's suggestions above to revise the
patch in order to push it upstream. Feel free to ask questions on this
list.
Thanks all,
/MG
___
Davinci-linux-open-source mailing list
Davinci-linux-open-source@linux.davincidsp.com
http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Git intro
Philip Balister <[EMAIL PROTECTED]> writes: > I have done some work for the Lyrtech Small Factor SDR board that I > would like to submit to this list. Does anyone have a good git intro > to take me through the process? I have it in a git repo in a branch I > made several months ago from the linux-davinci repo. > > So I need to update to match the current repo and work out what the > patch is. For starting points, I highly recommend the git tutorial[1]. And for a day to day manual, I regularily consult the 'Git User's Manual' which is linked to from the tutorial page. Kevin [1] http://www.kernel.org/pub/software/scm/git/docs/tutorial.html ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Displayed Live Camera Latency
Tim, We have tested gstreamer pipelines from the video source to the frame buffer sink without enconding/decoding on the middle and the latency is unnoticeable. You can probably modify the encode/decode demo to do not perform the encoding/decoding part and will get a lower latency. Depending on the product requirements you can achieve zero-copy behavior by modifying the V4L2 driver to capture the CCD data straight to the memory address of the frame buffer, but that may complicate things for the recording process. Diego On Mar 18, 2008, at 2:36 PM, [EMAIL PROTECTED] wrote: I am showing a viewing a live camera through the EncodeDecode demo and there seems to be ~1/3 second latency between live movement and screen display. This will be annoying to the user for my product. Has anyone found a way to reduce the perceived latency by displaying the incoming video directly without having to encode and decode it first, while still having overlay function? -- Tim Taylor Electrical Engineer L-3 Communications Linkabit-Florida ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Git intro
I have done some work for the Lyrtech Small Factor SDR board that I would like to submit to this list. Does anyone have a good git intro to take me through the process? I have it in a git repo in a branch I made several months ago from the linux-davinci repo. So I need to update to match the current repo and work out what the patch is. Philip smime.p7s Description: S/MIME Cryptographic Signature ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Displayed Live Camera Latency
I am showing a viewing a live camera through the EncodeDecode demo and there seems to be ~1/3 second latency between live movement and screen display. This will be annoying to the user for my product. Has anyone found a way to reduce the perceived latency by displaying the incoming video directly without having to encode and decode it first, while still having overlay function? -- Tim Taylor Electrical Engineer L-3 Communications Linkabit-Florida ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Yaffs2 boot times
Dirk Behme wrote: > Stephen Berry wrote: >> Ok - first let me say thanks! >> >> Second, there was a slight issue with the patch, but it did compile more >> or less cleanly. >> >> Thirdly, it appears that there is some incompatibility between the old >> and new yaffs filesystems - since it gaak'd all over the existing one. >> >> So after jumping through a few hoops, I was able to integrate the latest >> into the kernel and mount the partition. BUT, when I tried to replace >> the filesystem in NAND, I started seeing some errors (ok lots of errors) >> >> **>> Block 2427 retired >> Block 2427 is in state 9 after gc, should be erased >> yaffs: Block struck out >> nand_update_bbt: Out of memory >> >> Doesn't look like it will work out of the box > > I supposed something like this. There is a lot of time between the > yaffs2 in 2.6.10 and the recent one. So most probably some > incompatible changes. > > This is why I proposed to use a new board (or at least a low level > formatted NAND) and establish a complete new yaffs2 fs, i.e. starting > from scratch with the new yaffs2 code. Then put your original content > into the new yaffs2 fs and try if it behaves better. > > Dirk > I have no problem trashing the image that was originally there - so I *did* erase the partition before mounting it and un-tarring my filesystem image. I used flash_eraseall /dev/mtd4 to do this... is there a better way? >> Dirk Behme wrote: >> >>> Narnakaje, Snehaprabha wrote: >>> Steve, Unfortunately, this is a known issue in the 2.6.10 Kernel. YAFFS2 in the 2.6.10 kernel does not have "checkpoint" support. >>> >>> I'm really not sure about the features of a more recent YAFFS2. But if >>> you like you could try to update the old yaffs2 to a recent one. In >>> attachment is a yaffs2 patch containing yaffs2 CVS snapshot from today. >>> >>> If you like, you could try to exchange your exisiting yaffs2 with this >>> most recent version. To apply this patch, back up your existing >>> fs/yaffs2 directory (e.g "mv fs/yaffs2 fs/yaffs2_original"), >>> fs/Kconfig and fs/Makefile. Then manually remove existing entries >>> >>> # Patched by YAFFS >>> obj-$(CONFIG_YAFFS_FS) += yaffs2/ >>> >>> from Makefile and >>> >>> # Patched by YAFFS >>> source "fs/yaffs2/Kconfig" >>> >>> from Kconfig. >>> >>> Now you should be able to apply patch in attachment. >>> >>> Not sure if it compiles with a 2.6.10 or works, though. Just try it. >>> >>> Btw.: A backup of the exisiting target yaffs2 file system or using an >>> other board where you can establish a new and fresh yaffs2 would be a >>> good idea as well ;) >>> >>> Does it work? >>> >>> Dirk >>> >>> On each reboot, it assumes to be starting from an "unclean shutdown" system, thus spending time doing the house keeping stuff for all the files. The mount time is proportional to the number of files (as well as the large size) in the YAFFS2 filesystem. Is your "minimal" filesystem busybox-based? You might have to update the busybox application in this filesystem. Thanks Sneha -Original Message- From: [EMAIL PROTECTED] om [mailto:[EMAIL PROTECTED] ncidsp.com] On Behalf Of Stephen Berry Sent: Sunday, March 16, 2008 9:22 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Yaffs2 boot times I've noticed some odd behavior with booting from nand, specifically that the time it takes to boot (or mount) the partition is directly related to the number of files in the filesystem. I have two partitions, one with the same minimal filesystem of 50mB in size and the other of ~400mB. Both nand partitions are the same physical size. The minimal filesystem boots fairly quickly, under 10 seconds or so, while the *big* filesystem takes several minutes. If it weren't for the fact the the minimal filesystem is a pain in the butt to work with (control-c, telnet, ftp, seem to NOT work among other things) I'd just stick with it. Does anyone have any ideas as to what is going on with mounting yaffs2 ? Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >>> >> >> > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Yaffs2 boot times
Stephen Berry wrote: Ok - first let me say thanks! Second, there was a slight issue with the patch, but it did compile more or less cleanly. Thirdly, it appears that there is some incompatibility between the old and new yaffs filesystems - since it gaak'd all over the existing one. So after jumping through a few hoops, I was able to integrate the latest into the kernel and mount the partition. BUT, when I tried to replace the filesystem in NAND, I started seeing some errors (ok lots of errors) **>> Block 2427 retired Block 2427 is in state 9 after gc, should be erased yaffs: Block struck out nand_update_bbt: Out of memory Doesn't look like it will work out of the box I supposed something like this. There is a lot of time between the yaffs2 in 2.6.10 and the recent one. So most probably some incompatible changes. This is why I proposed to use a new board (or at least a low level formatted NAND) and establish a complete new yaffs2 fs, i.e. starting from scratch with the new yaffs2 code. Then put your original content into the new yaffs2 fs and try if it behaves better. Dirk Dirk Behme wrote: Narnakaje, Snehaprabha wrote: Steve, Unfortunately, this is a known issue in the 2.6.10 Kernel. YAFFS2 in the 2.6.10 kernel does not have "checkpoint" support. I'm really not sure about the features of a more recent YAFFS2. But if you like you could try to update the old yaffs2 to a recent one. In attachment is a yaffs2 patch containing yaffs2 CVS snapshot from today. If you like, you could try to exchange your exisiting yaffs2 with this most recent version. To apply this patch, back up your existing fs/yaffs2 directory (e.g "mv fs/yaffs2 fs/yaffs2_original"), fs/Kconfig and fs/Makefile. Then manually remove existing entries # Patched by YAFFS obj-$(CONFIG_YAFFS_FS) += yaffs2/ from Makefile and # Patched by YAFFS source "fs/yaffs2/Kconfig" from Kconfig. Now you should be able to apply patch in attachment. Not sure if it compiles with a 2.6.10 or works, though. Just try it. Btw.: A backup of the exisiting target yaffs2 file system or using an other board where you can establish a new and fresh yaffs2 would be a good idea as well ;) Does it work? Dirk On each reboot, it assumes to be starting from an "unclean shutdown" system, thus spending time doing the house keeping stuff for all the files. The mount time is proportional to the number of files (as well as the large size) in the YAFFS2 filesystem. Is your "minimal" filesystem busybox-based? You might have to update the busybox application in this filesystem. Thanks Sneha -Original Message- From: [EMAIL PROTECTED] om [mailto:[EMAIL PROTECTED] ncidsp.com] On Behalf Of Stephen Berry Sent: Sunday, March 16, 2008 9:22 AM To: davinci-linux-open-source@linux.davincidsp.com Subject: Yaffs2 boot times I've noticed some odd behavior with booting from nand, specifically that the time it takes to boot (or mount) the partition is directly related to the number of files in the filesystem. I have two partitions, one with the same minimal filesystem of 50mB in size and the other of ~400mB. Both nand partitions are the same physical size. The minimal filesystem boots fairly quickly, under 10 seconds or so, while the *big* filesystem takes several minutes. If it weren't for the fact the the minimal filesystem is a pain in the butt to work with (control-c, telnet, ftp, seem to NOT work among other things) I'd just stick with it. Does anyone have any ideas as to what is going on with mounting yaffs2 ? Steve ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: Yaffs2 boot times
Ok - first let me say thanks! Second, there was a slight issue with the patch, but it did compile more or less cleanly. Thirdly, it appears that there is some incompatibility between the old and new yaffs filesystems - since it gaak'd all over the existing one. So after jumping through a few hoops, I was able to integrate the latest into the kernel and mount the partition. BUT, when I tried to replace the filesystem in NAND, I started seeing some errors (ok lots of errors) **>> Block 2427 retired Block 2427 is in state 9 after gc, should be erased yaffs: Block struck out nand_update_bbt: Out of memory Doesn't look like it will work out of the box Steve Dirk Behme wrote: > Narnakaje, Snehaprabha wrote: >> Steve, >> >> Unfortunately, this is a known issue in the 2.6.10 Kernel. YAFFS2 in the >> 2.6.10 kernel does not have "checkpoint" support. > > I'm really not sure about the features of a more recent YAFFS2. But if > you like you could try to update the old yaffs2 to a recent one. In > attachment is a yaffs2 patch containing yaffs2 CVS snapshot from today. > > If you like, you could try to exchange your exisiting yaffs2 with this > most recent version. To apply this patch, back up your existing > fs/yaffs2 directory (e.g "mv fs/yaffs2 fs/yaffs2_original"), > fs/Kconfig and fs/Makefile. Then manually remove existing entries > > # Patched by YAFFS > obj-$(CONFIG_YAFFS_FS) += yaffs2/ > > from Makefile and > > # Patched by YAFFS > source "fs/yaffs2/Kconfig" > > from Kconfig. > > Now you should be able to apply patch in attachment. > > Not sure if it compiles with a 2.6.10 or works, though. Just try it. > > Btw.: A backup of the exisiting target yaffs2 file system or using an > other board where you can establish a new and fresh yaffs2 would be a > good idea as well ;) > > Does it work? > > Dirk > >> On each reboot, it >> assumes to be starting from an "unclean shutdown" system, thus spending >> time doing the house keeping stuff for all the files. The mount time is >> proportional to the number of files (as well as the large size) in the >> YAFFS2 filesystem. >> >> Is your "minimal" filesystem busybox-based? You might have to update the >> busybox application in this filesystem. >> >> Thanks >> Sneha >> >> -Original Message- >> From: >> [EMAIL PROTECTED] >> om >> [mailto:[EMAIL PROTECTED] >> ncidsp.com] On Behalf Of Stephen Berry >> Sent: Sunday, March 16, 2008 9:22 AM >> To: davinci-linux-open-source@linux.davincidsp.com >> Subject: Yaffs2 boot times >> >> I've noticed some odd behavior with booting from nand, specifically that >> the time it takes to boot (or mount) the partition is directly related >> to the number of files in the filesystem. >> >> I have two partitions, one with the same minimal filesystem of 50mB in >> size and the other of ~400mB. Both nand partitions are the same physical >> size. The minimal filesystem boots fairly quickly, under 10 seconds or >> so, while the *big* filesystem takes several minutes. If it weren't for >> the fact the the minimal filesystem is a pain in the butt to work with >> (control-c, telnet, ftp, seem to NOT work among other things) I'd just >> stick with it. >> >> Does anyone have any ideas as to what is going on with mounting yaffs2 ? >> >> Steve >> ___ >> Davinci-linux-open-source mailing list >> Davinci-linux-open-source@linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> ___ >> Davinci-linux-open-source mailing list >> Davinci-linux-open-source@linux.davincidsp.com >> http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source >> > ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
No NAND device found!!!
Hi All, My u-boot is u-boot-1.1.4, and the version of kernel is 2.6.10. Both of them can boot from NAND Flash normally, but there are some messages that puzzle me when my kernel is booting from NAND. The messages are as follows. DaVinci NAND Controller rev. 2.1 No NAND device found!!! Chip Select is not set for NAND I has selected nand boot mode(jumper J4 jump to NAND CS2, set S3 to 10) The process of my kernel booting from NAND is like that, DaVinci EVM # setenv bootargs console=ttyS0,115200n8 noinitrd rw root=/dev/nfs n fsroot=192.168.136.151:/root/rootfs,nolock mem=120M eth=00:0E:FF:FF:FF:80 ip=192 .168.136.229::192.168.136.39 DaVinci EVM # save Saving Environment to NAND... Erasing Nand...Writing to Nand... done DaVinci EVM # print bootdelay=3 baudrate=115200 ethaddr=00:0E:99:EF:EF:22 bootfile=uImage_nfs filesize=1616f4 fileaddr=8070 ipaddr=192.168.136.229 serverip=192.168.136.151 bootcmd=nboot 8070 0 205;bootm stdin=serial stdout=serial stderr=serial videostd=pal bootarg?console=ttyS0,115200n8 noinitrd rw root=/dev/nfs nfsroot=192.168.136.15 1:/root/rootfs,nolock mem=120M eth=00:0E:FF:FF:FF:80 ip=192.168.136.229::192.168 .136.39 Environment size: 417/16380 bytes DaVinci EVM # boot Loading from device 0: at 0x200 (offset 0x205) Image Name: Linux-2.6.10_mvl401-davinci_evm Image Type: ARM Linux Kernel Image (uncompres骵d) Data Size:1447604 Bytes = 1.4 MB Load Address: 80008000 Entry Point: 80008000 ## Booting image at 8070 ... Image Name: Linux-2.6.10_mvl401-davinci_evm Image Type: ARM Linux Kernel Image (uncompressed) Data Size:1447604 Bytes = 1.4 MB Load Address: 80008000 Entry Point: 80008000 Verifying Checksum ... OK OK Starting kernel ... Uncompressing Linux. Linux version 2.6.10_mvl401-davinci_evm ([EMAIL PROTECTED]) (gcc versio n 3.4.3 (MontaVista 3.4.3-25.0.30.0501131 2005-07-23)) #1 Sun Jan 20 13:21:44 ES T 2008 CPU: ARM926EJ-Sid(wb) [41069265] revision 5 (ARMv5TEJ) 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 Machine: DaVinci EVM Memory policy: ECC disabled, Data cache writeback Built 1 zonelists Kernel command line: console=ttyS0,115200n8 noinitrd rw root=/dev/nfs nfsroot=19 2.168.136.151:/root/rootfs,nolock mem=120M eth=00:0E:FF:FF:FF:80 ip=192.168.136. 229::192.168.136.39 TI DaVinci EMAC: Kernel Boot params Eth address: 00:0E:FF:FF:FF:80 PID hash table entries: 512 (order: 9, 8192 bytes) Console: colour dummy device 80x30 Dentry cache hash table entries: 16384 (order: 4, 65536 bytes) Inode-cache hash table entries: 8192 (order: 3, 32768 bytes) Memory: 120MB = 120MB total Memory: 118400KB available (2317K code, 453K data, 468K init) Mount-cache hash table entries: 512 (order: 0, 4096 bytes) CPU: Testing write buffer coherency: ok spawn_desched_task() desched cpu_callback 3/ ksoftirqd started up. desched cpu_callback 2/ desched thread 0 started up. NET: Registered protocol family 16 Registering platform device 'musb_hdrc'. Parent at platform DaVinci I2C DEBUG: 13:16:16 Jan 20 2008 Registering platform device 'i2c'. Parent at platform SCSI subsystem initialized usbcore: registered new driver usbfs usbcore: registered new driver hub devfs: 2004-01-31 Richard Gooch ([EMAIL PROTECTED]) devfs: boot_options: 0x1 JFFS2 version 2.2. (NAND) (C) 2001-2003 Red Hat, Inc. Registering platform device 'davincifb.0'. Parent at platform Console: switching to colour frame buffer device 90x30 Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing disabled Registering platform device 'serial8250'. Parent at platform ttyS0 at MMIO 0x1c2 (irq = 40) is a 16550A io scheduler noop registered io scheduler anticipatory registered RAMDISK driver initialized: 1 RAM disks of 32768K size 1024 blocksize ub: sizeof ub_scsi_cmd 64 ub_dev 2476 usbcore: registered new driver ub Registering platform device 'ti_davinci_emac'. Parent at platform TI DaVinci EMAC: MAC address is 00:0E:FF:FF:FF:80 TI DaVinci EMAC Linux version updated 4.0 TI DaVinci EMAC: Installed 1 instances. netconsole: not configured, aborting i2c /dev entries driver Linux video capture interface: v1.00 Registering platform device 'vpfe.1'. Parent at platform DaVinci v4l2 capture driver V1.0 loaded elevator: using anticipatory as default io scheduler NFTL driver: nftlcore.c $Revision: 1.96 $, nftlmount.c $Revision: 1.39 $ INFTL: inftlcore.c $Revision: 1.17 $, inftlmount.c $Revision: 1.15 $ DaVinci NAND Controller rev. 2.1 No NAND device found!!! Chip Select is not set for NAND Initializing USB Mass Storage driver... usbcore: registered new driver usb-storage USB Mass Storage support registered. mice: PS/2 mouse d
CE: Server_redefineHeap
I've had success with getting eVRU and codec engine up and running... although eVRU requires a considerable amount of CMEM. I read about the Server_redefineHeap api call and thought that it would be most flexible for our situtation. According to the wiki, if you're going to use this api, you can just merge CMEM and DDRALGHEAP together and get the buffers from CMEM only. My question is how should the memory map look for the CMEM and DDRALGHEAP entries? Should I merge the CMEM and DDRALGHEAP but still keep a dummy DDRALGHEAP section to keep everything from complaining about missing segments or just get rid of DDRALGHEAP? DAVID A. KONDRAD Software Design Engineer On-Q/Legrand www.onqlegrand.com ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
Re: [PATCH] ARM: Davinci: port video previewer driver to kernel 2.6.23
On Mon, 2008-03-17 at 23:36 +0530, Trilok Soni wrote: > Hi Michael, > > On Mon, Mar 17, 2008 at 8:27 PM, Michael Gao <[EMAIL PROTECTED]> wrote: > > > > On Mon, 2008-03-17 at 12:15 +0530, Trilok Soni wrote: > > > > For those who do not know, as part of the effort to build OSD > > > > (www.neurostechnology.com) with Davinci 6446, Neuros cloned the 2.6.23 > > > > kernel tree (git.neurostechnology.com/git/kernels) and are in the > > > > process of porting existing TI video patches to it, thought it makes > > > > sense to upstream the patches here. Comments are welcome, especially > > if > > > > someone knows that the effort has been done somewhere else already, > > > > > > > > > > This looks good, so you mean Neuros is building next OSD product with > > > DM6446? If this is true, then it would be great if you can > > > periodically send the generic patches to this ML for review and > > > inclusion. > > Indeed that is the plan. In the mean while, it is a waste of time and we > > don't really want to reinvent the wheel if some of the up-porting work > > has been done for version 2.6.23 or newer kernel, it would be great if > > anyone knows any of the following (list may go on as we move forward) > > has been done and post pointers here, > > > > 1. resizer, previewer, capture (Steven has done most of them, but > > doesn't make sense to push if they are already done somewhere else, as > > Steven's work is based on my limited understanding of udev, in fact I > > brutally hacked the resizer driver without really knowing what I was > > doing, although test shows it works. ;)) > > > > 2. USB host performance and USB Hub support (which Frank is currently > > working on, it is not a trivial system as we all know.) > > > > 3. HD framebuffer support (720p/1080i?) > > > > 4. HD V4L2 support (720p/1080i?) > > > > 5. Davinci Open Embedded build system integration > >One of the Neuros community member ported this to DM320 platform, > > while we are planning to reuse his effort with Davinci, it would be > > great to know if someone has already taken care of this. > > We might want to add scratchbox based development environment instead. > And as Dirk suggested, Neuros should better move towards using > codesourcery based toolchains. My understanding is that scratchbox is not a mutual exclusive approach with OE, in fact, IIRC, there is a scratchbox based dev-env for dm320 based first generation OSD. > I have personally setup scratchbox based environment with > gtk+/x-server, lighttpd, perl, php etc. pacakges using foreign > toolchain in sbox for dm644x based custom boards and it works well. Tom, you set the scratchbox evn up, and you seem inclined to moving toward to OE as well with 6446, you might want to shed some lights here on this? Thanks, /MG ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
u boot and netconsole
Hi, does anyone of you use netconsole with u-boot? If I add #define CONFIG_NETCONSOLE 1 to the config file, I'm not able to compile u-boot any more, I get a lot of multiple definition of functions. do you have any hint? Thanks, Ottavio This message was sent using IMP, the Internet Messaging Program. ___ Davinci-linux-open-source mailing list Davinci-linux-open-source@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source
