How can I use a cmos sensor with DM355EVM?

You will need to write the driver for your CMOS sensor first.  We actually have support for a couple of micron sensors (drivers included in DM355 Linux kernel), hence you can use these drivers as an example to start from.  I would refer to the PSP_XX_XX_XX_XXX folder under DVSDK root directory (assuming you have installed the software per Getting Started Guide) and look over the documents there; they will offer insights into the driver architecture.

I did some work this weekend,and from this website(http://www.mail-archive.com/davinci-linux-open-source@linux.davincidsp.com/msg06383.html),I have known what to do next now.But there still  something confusing me .

Now,I know that the drivers are at this directory /home/brdsp/workdir/lsp/ti-davinci/drivers/media/video,and they are dm355_vpfe.c tvp5146.c mt9t001.c .what I need to is to modify some of them .But from  what the Website said ,I still don't know the relatinship of dm355_vpfe.c tvp5146.c and mt9t001.c. Would you please give me some instructions about them(espically dm355_vpfe.c and tvp5146.c)? Thanks.

Hello Tony,

It is my understanding that dm355_vpfe.c sits on top of both, tvp5146.c and mt9001.c; both TVP5146 and MT9xxxx parts are a means to get digital video input to DM355 and only one can be connected to DM355 at any one time.  From a hardware point of view, our EVM muxes TVP5146 with J30-J31 connectos (used to plug in various CCD sensors such as MT9XXXX) at the video input interface to DM355; you can only select one video input at a time (TVP5146 or J30-J31 connector) via software; user selects which device by setting the u-boot environment variables according to CCD User Guide (spruep7.pdf in the directory I mentioned in my previous post).  The linux drivers take care of everything else underneath; I beleive dm355_vpfe.c processes the options passed in via u-boot and initializes the corresponding video input device (TVP5146 or MT9XXXX).

Let me know if this helps clear things up.

Thanks for your guide.

I have read the CCD User Guuide you reccommeded,and I think it's very helpful to me .My cmos sensor is ov7620(from ominivison company),and it has many output formats.I think what I need to do is modify dm355_vpfe.c and tvp5146.c to make these drivers suite to my applicaton,and I right?

If this is right,I think what I have to concern about is the run-time codes. The pdf you reccommeded has some guides about how to develop run-time codes. But I think if there's some demo codes about that would be better.Is there any I can get? I have found some codes at the directory /home/brdsp/dvsdk_1_30_00_23/demos/encode,and I have looked over it .But I don't know if this can be the reference I need.

Tony said:

I have read the CCD User Guuide you reccommeded,and I think it's very helpful to me .My cmos sensor is ov7620(from ominivison company),and it has many output formats.I think what I need to do is modify dm355_vpfe.c and tvp5146.c to make these drivers suite to my applicaton,and I right?

You can certainly follow this approach; although I would probrably create a new file (ov7620.c) so you will always have yor original tvp5146.c to go back to ans use as reference.

Tony said:

If this is right,I think what I have to concern about is the run-time codes. The pdf you reccommeded has some guides about how to develop run-time codes. But I think if there's some demo codes about that would be better.Is there any I can get? I have found some codes at the directory /home/brdsp/dvsdk_1_30_00_23/demos/encode,and I have looked over it .But I don't know if this can be the reference I need.

Are you referring to DSP codec algorithms (such as MPEG2, JPEG...); if so, you probrably want to see the examples under the codec_engine directory instead; there you will find examples on how to write codec algorithms (codecs directory), how to pull those algorithms into a DSP server (server direcotry) and finally how to test these DSP servers via Linux applications (apps directory)

Juan Gonzales said:

Are you referring to DSP codec algorithms (such as MPEG2, JPEG...); if so, you probrably want to see the examples under the codec_engine directory instead; there you will find examples on how to write codec algorithms (codecs directory), how to pull those algorithms into a DSP server (server direcotry) and finally how to test these DSP servers via Linux applications (apps directory)

I think its my poor English made you misunderstand me.But I am also confused by what you wrote. As we all know ,DM355 uses its MPEG4/JPEG Coprocessor to to encode/decode video .So, if we just want to encode video data with dm355, we do not need to study DSP codec algorithms (such as MPEG2, JPEG...),am I right?

What I mean about run-time codes is that when I have finished the drivers of ov7620 and integrated it to the kernel(by now,I havn't finished yet),how can I use the driver to encode my video data?Is there any demo codes about how to write the application codes?If there's nothing ,any guide can you give me ?Thanks.

Tony said:

I think its my poor English made you misunderstand me.But I am also confused by what you wrote. As we all know ,DM355 uses its MPEG4/JPEG Coprocessor to to encode/decode video .So, if we just want to encode video data with dm355, we do not need to study DSP codec algorithms (such as MPEG2, JPEG...),am I right?

What I mean about run-time codes is that when I have finished the drivers of ov7620 and integrated it to the kernel(by now,I havn't finished yet),how can I use the driver to encode my video data?Is there any demo codes about how to write the application codes?If there's nothing ,any guide can you give me ?Thanks.

1) DM355 does not have a DSP, hence I was a bit confused myself.  Therefore, you do not need (or have the ability via tools) to study the codec

2) If everyithing is right at the driver level (V4L2 chosses your sensor as result of u-boot configuration, or you can optionally hardcode your sensor and get rid of u-boot paramaters), then the sensor you choose should be hidden from user application by V4L2 driver.  This means that you should be able to use some of the example applications we provide to exercise your driver (PSP_01_20_00_014/examples/dm355/ipipe )

Hi.

I want to add the drvier of dm355_vpfe to my kernel,so I execute the command make menuconfig at the directory /home/brdsp/workdir/lsp/ti-davinci,and checked the option:Device Drivers->Multimedia Devices->video for linux->Davinci video Capture,and then save and quit. After that, I want to rebuild my kernel by using make command :make ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage ,and below are the information printed:

[root@brdsp ti-davinci]# make ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage
  CHK     include/linux/version.h
  SPLIT   include/linux/autoconf.h -> include/config/*
  SYMLINK include/asm-arm/arch -> include/asm-arm/arch-davinci
make[1]: “arch/arm/kernel/asm-offsets.s”是最新的。
  CHK     include/asm-arm/constants.h
make[1]: “include/asm-arm/mach-types.h”是最新的。
  CHK     include/linux/compile.h
  CHK     usr/initramfs_list
  LD      drivers/media/video/built-in.o
drivers/media/video/dm355-vpfe.o(.text+0x22b0): In function `free_reserved_pages':
dm355_vpfe.c: multiple definition of `free_reserved_pages'
drivers/media/video/davinci-vpfe.o(.text+0xd60):davinci_vpfe.c: first defined here
drivers/media/video/dm355-vpfe.o(.text+0x7e8): In function `ccdc_config_raw':
dm355_vpfe.c: multiple definition of `ccdc_config_raw'
drivers/media/video/davinci-vpfe.o(.text+0x644):davinci_vpfe.c: first defined here
arm_v5t_le-ld: Warning: size of symbol `ccdc_config_raw' changed from 1816 in drivers/media/video/davinci-vpfe.o to 5800 in drivers/media/video/dm355-vpfe.o
drivers/media/video/dm355-vpfe.o(.bss+0x0): multiple definition of `vpfe_dev'
drivers/media/video/davinci-vpfe.o(.bss+0x0): first defined here
drivers/media/video/dm355-vpfe.o(.text+0x65c): In function `ccdc_config_ycbcr':
dm355_vpfe.c: multiple definition of `ccdc_config_ycbcr'
drivers/media/video/davinci-vpfe.o(.text+0x4d4):davinci_vpfe.c: first defined here
arm_v5t_le-ld: Warning: size of symbol `ccdc_config_ycbcr' changed from 368 in drivers/media/video/davinci-vpfe.o to 396 in drivers/media/video/dm355-vpfe.o
drivers/media/video/dm355-vpfe.o(.text+0x0): In function `ccdc_readregs':
dm355_vpfe.c: multiple definition of `ccdc_readregs'
drivers/media/video/davinci-vpfe.o(.text+0x0):davinci_vpfe.c: first defined here
arm_v5t_le-ld: Warning: size of symbol `ccdc_readregs' changed from 852 in drivers/media/video/davinci-vpfe.o to 348 in drivers/media/video/dm355-vpfe.o
drivers/media/video/dm355-vpfe.o(.data+0x0): multiple definition of `vpfe_drvcap'
drivers/media/video/davinci-vpfe.o(.data+0x0): first defined here
drivers/media/video/dm355-vpfe.o(.text+0x384): In function `ccdc_setwin':
dm355_vpfe.c: multiple definition of `ccdc_setwin'
drivers/media/video/davinci-vpfe.o(.text+0x3e4):davinci_vpfe.c: first defined here
arm_v5t_le-ld: Warning: size of symbol `ccdc_setwin' changed from 240 in drivers/media/video/davinci-vpfe.o to 280 in drivers/media/video/dm355-vpfe.o
drivers/media/video/dm355-vpfe.o(.text+0x15c): In function `ccdc_reset':
dm355_vpfe.c: multiple definition of `ccdc_reset'
drivers/media/video/davinci-vpfe.o(.text+0x354):davinci_vpfe.c: first defined here
arm_v5t_le-ld: Warning: size of symbol `ccdc_reset' changed from 144 in drivers/media/video/davinci-vpfe.o to 552 in drivers/media/video/dm355-vpfe.o
make[3]: *** [drivers/media/video/built-in.o] error 1
make[2]: *** [drivers/media/video] error 2
make[1]: *** [drivers/media] error 2
make: *** [drivers] error 2
[root@brdsp ti-davinci]#

It seems that there two copies of drivers at the path"drivers/media/video":dm355_vpfe.c and davinci_vpfe.c ,why this happen? Can I just by delete one of them to solve this problem?

And I have another question:when I have modified the drivers,how can I generator the .ko and .o file.I have tried the make command ,but it seems doesn't work.

Tony said:

It seems that there two copies of drivers at the path"drivers/media/video":dm355_vpfe.c and davinci_vpfe.c ,why this happen? Can I just by delete one of them to solve this problem?

And I have another question:when I have modified the drivers,how can I generator the .ko and .o file.I have tried the make command ,but it seems doesn't work.

Having multimple files should not matter; when the kernel is configured to build for the appropriate platform (done via menuconfig per Getting Started Guide), it uses the information in the Makefile to figure out which files to include in the build process.  When it is configure for DM355, it will only pick up dm355_vpfe.c.  I would double check your Makefile

Also, to get a .ko file, you need to build your driver as a standalone module (requires wrtting more makefiles, Kconfig files...); in our software architecture, we include the sensor driver as part of V4L2 driver (easier).  Unless you are familiar with Linux Kernel build scripts, I would stick to our approach and just add any additional files (e.g. my_sensor.c) to the list in the Makefile.

Juan -

I'm having the same error Tony had above, which from your comments indicates that the error is not with the duplicate copy of the "davinci_vpfe.c" file, but with the "built-in.o" file.  I was able to change the "make menuconfig" options to get this error not to occur, but I'm wondering if you have any insight as to why this "built-in.o" file is causing error.

If you compile the kernel using the defalt settings from the "davinci_dm355_evm_defconfig" the uImage compiles without error.

If you add the Device Drivers (davinci video capture, davinci-video display, etc.) as static (*) options for the kernel and try and compile this new kernel the above error occurs.

If you add the same Device Drivers as Module (M) options rather then static options, the new kernel complies without error, but now you have to deal with the .ko and make files rather then passing bootargs trhu the kernel.

I believe the reason Tony and I are adding these new multimedia device drivers to compile a new kernel is to have access to the CCDC drivers according to the SPRUEP7 (LSP 1.20 CCDC Driver User Guide ).

Thanks,

Nathan Evans

Nathan Evans said:

If you add the Device Drivers (davinci video capture, davinci-video display, etc.) as static (*) options for the kernel and try and compile this new kernel the above error occurs.

What DVSDK version are you using and how are you enabling capture and display drivers; I just tried this on DVSDK_1_30_00_41

>make ARCH=arm CROSS_COMPILE=arm_v5t_le- davinci_dm355_evm_defconfig
>make ARCH=arm CROSS_COMPILE=arm_v5t_le- menuconfig

and can confirm that capture and display drivers are build into the kernel staticly (*) by default.  see "Device Drivers->Multimedia devices->Video For Linux" under menuconfig ...

I was originally using the dvsdk_1_30_00_23 and and entered the following:

>make ARCH=arm CROSS_COMPILE=arm_v5t_le- davinci_dm355_evm_defconfig
>make ARCH=arm CROSS_COMPILE=arm_v5t_le- menuconfig

In the 'Device Drivers -> Multimedia devices -> Video For Linux, the 'Davinci Video Capture' and 'Davinci Video Display' were blank (  ), so I can only assume the default config doesn't include them. I enabled them statically (*) and exited. I then executed the following:

>make ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage

The "built-in.o" error from the previous thread occured. When I go back thru the previous steps and enable those drivers modularly (M) and then execute the following:

>make ARCH=arm CROSS_COMPILE=arm_v5t_le- uImage modules

The kernel compiles without error.

So, I then started from scratch and installed the new dvsdk_1_30_01_41 on the host PC, reloaded the new 'uImage-dm355' from the updated dvsdk_1_30_01_41, and reflashed the EVM NAND with the new dm355_flash_image_1_30_01_41.tar.  The only item i didn't update from the software upgrades website was the LSP. I currenly have the original version from the CD, which is lsp_DM355_setuplinux_1_30_00_23. The version on the website is mvl_4_0_1_demo_lsp_setuplinux_01_20_00_014., which from the versions numbers seems older, but has a newer release date.

I followed the procedure above with the exact same results.

All of these commands are executing from the /opt/mv_pro_4.0.1/montavista/pro/devkit/lsp/ti-davinci directory, so I can only assume i need to update this lsp, which I will test tommorrow. Could you determine your version of the lsp and also try to add those drivers statically and re-compile the kernel without error?

Thanks,

Nathan Evans

I am using lsp_01_20_00_014 and can confirm I do not see this issue.  FYI, LSP version (1.20.00.014) is different from DVSDK version (1.30.00.23); lsp version 1.20 is newer than what is found in DVSDK_1_30_00_23.

The kernel compiled sucessfully with the new LSP installed. Also note, that the 'Davinci Video Capture' and 'Davinci Video Diplay' device drivers were already included in the kernel statically in the this updated version of the LSP, but not in the previous version of the LSP. I did add the 'Omnivision Chipsets' statically to the new kernel and compiled it succesfully without error.

Thanks for the assistance.

hi，all

I'm use  the ov7620 too.

Nathan Evans said:

The kernel compiled sucessfully with the new LSP installed. Also note, that the 'Davinci Video Capture' and 'Davinci Video Diplay' device drivers were already included in the kernel statically in the this updated version of the LSP, but not in the previous version of the LSP. I did add the 'Omnivision Chipsets' statically to the new kernel and compiled it succesfully without error.

Thanks for the assistance.

How did you get the omnivision camera recognized and output video to the DM355EVM ?

thanks