V4L drivers on OMAP35x

While I could not tell you why exactly your kernel is giving the page allocation failure I can say that if you use the current SDK kernel with the current DVSDK software package out of the box that you do not get the page allocation error, the demos work properly for me booting it up over TFTP/NFS. This being said there is a good chance that some modification was made, perhaps inadvertently, that is causing this error, my suggestion would be to run through the getting started guide after downloading the SDK/DVSDK packages to get your software stack into a known good state.

Hi Thompson,

I have set up NFS server and using the latest DVSDK_3_00_00_29, but the following errors are coming if I try to run video demos.

[root@OMAP3EVM dvsdk]# ./decode -v data/videos/davincieffect_ntsc_1.264
Decode demo started.
CMEMK Error: get_phys: Unable to find phys addr for 0x42463000
CMEMK Error: get_phys: get_user_pages() failed: -14
CMEMK Error: GETPHYS: Failed to convert virtual 0x42463000 to physical.
CMEM Error: getPhys: Failed to gCMEMK Error: get_phys: Unable to find phys addr for 0x42463003
et physical address of 0x4246300CMEMK Error: get_phys: get_user_pages() failed: -14
0
CMEMK Error: GETPHYS: Failed to convert virtual 0x42463003 to physical.
CMEM Error: getPhys: Failed to get physical address of 0x42463003
omap-resizer omap-resizer: Bad command value
Error: Failed to configure frame copy job

However we have loaded cmemk.ko as per given in loadmodules.sh script as follows:-

insmod cmemk.ko phys_start=0x85800000 phys_end=0x86800000 pools=20x4096,8x131072,5x1048576,1x1429440,1x256000,1x3600000,5x829440,

Then why the demo app is looking for 0x424..... address (Unable to find phys addr for 0x42463000),  how to resolve this issue now?

Regards,

Vineet

The 0x424... is a virtual address (user space demos cannot access physical address directly); this probrably explains why it is not in the range specified by loadmodules.sh (physical address).

I have not run the OMAP demos myself, but this would appear to point to some incompatibility between the memory pools specified in loadmodules.sh and what the demos used (assuming you have not modifed any source code).  Can you confirm that both demos and loadmodules.sh being used are from the same software release (DVSDK_3_00_00_29 as stated above)?

It seems that the decode demo is somehow trying to convert an invalid virtual address to a physical address, it would seem to me that some sort of pointer corruption has taken place though I am not sure what the root cause would be for this case. I can say that the demo works from the command line properly when booting my EVM over TFTP/NFS with the DVSDK 3.0.0.29.

I agree with Juan that as this is known to work properly there is probably a software version mismatch somewhere, though your cmemk.ko insertion looks correct, perhaps you are using an older kernel or cmem.ko file somehow. For everything to work you must ensure that every piece of software you are running is in agreement, a version difference in any part can cause prevent proper operation. In general your U-Boot (has not changed recently), uImage (kernel), and filesystem (demo binary and collateral such as cmem.ko and loadmodules.sh) must all be compatible, for example note that the DVSDK 3.0.0.29 software is dependent on the SDK 1.0.2 kernel.

Eureka!

After writing the last post I decided to do a quick test, I get the exact same error message if I try to run the decode demo when booting the older SDK 1.0.0 kernel, so this is a versioning issue. To use the latest DVSDK 3.0.0.29 you need to install SDK 1.0.2 as mentioned in the DVSDK documentation and use the kernel out of that, if you boot the newer kernel your demo should work properly.

Hi Juan and Thompson ...

Happy  New  Year.

I had reflashed OMAP_SDK 1.0.2 images again , I had micron board on which I performed run rf_all_min_rd, which to relash  U-boot, X-loader, Kernel, ramdisk.min.gz. I copied DVSDK_3_00_00_29 and when I run ./decode -v data/video/davincieffect_ntsc_1.264 again the same error is coming which I had already posted in 1st post of this thread.

Which board are you using, Samsung or Micron? Which is the new board? Can we flash rootfs.jffs image on Micron board? How can we change the buffersize ? Is there anything wrong with loadmodule script?

insmod cmemk.ko phys_start=0x85800000 phys_end=0x86800000 pools=20x4096,8x131072,5x1048576,1x1429440,1x256000,1x3600000,5x829440

How to fix it?

Regards,

Vineet

Happy New Year!

I am using a Samsung board, the newer boards are Micron, you should be able to tell what board you have by looking at the logo on the PoP chip on the underside of the EVM. I believe the Micron board was to be setup with a RAM disk instead of a JFFS image, I am not sure if there are limitations that would prevent the JFFS image from working, though this is unlikely related to the problem, in general I only boot over TFTP and NFS anyway so I don't run into the flash filesystem myself very much and should be aside from if the demo works or not.

The loadmodules script you have (at least the insmod cmemk.ko part) looks correct, it is the same as the one I was booting.

My suggestion would be to boot everything over the network instead of trying to develop with the on board flash, this allows greater flexibility in changing versions and makes development easier. Since I received the exact same error message booting the 1.0.0 SDK kernel (down to the addresses it references) I believe it is highly probable that you are inadvertently still booting a 1.0.0 kernel, if you set up for TFTP boot you can more easily prove and change what you are booting.

EDIT: If you are having trouble getting the TFTP boot to work please post your U-Boot arguments and any error messages, and we will probably be able to fix it quick and easy.

Hi Thompson ,

I had setup NFS server and flashed the latest kernel from SDK_1.0.2, now I am able to play davincieffect video files on LCD, but If I am not booting the filesystem from NFS server, and flashing rootfs.jffs on samsung board, then the same error is coming what I sent in the 1st post... failed to create display device....

Finally our aim is to run this display wither with flash on MMC card, our aim is not to use NFS, is it possible to run the demo without NFS server? Sometimes video demo is working once only and if I try to run it again then the following errors are coming:-

[root@OMAP3EVM dvsdk]# ./decode -a data/sounds/davincieffect.mp3 -v data/videos/davincieffect_ntsc_1.264
Decode demo started.
omap-resizer: Device is opened in blocking mode
CMEMK Error: Failed to find a pool which fits 829440
CMEM Error: getPool: Failed to get a pool fitting a size 829440
Failed to allocate memory.
Error: Failed to create BufTab for display pipe
[root@OMAP3EVM dvsdk]#

Decode demo started.
CMEMK Error: Failed to find a pool which fits 692224
CMEM Error: getPool: Failed to get a pool fitting a size 692224
Failed to allocate memory.
*** glibc detected *** ./decode: free(): invalid pointer: 0x0005eeec ***

If I restart the board then its working again.

What is the problem with this?

Regards,

Vineet

I am trying to flash the DVSDK filesystem to my EVM but I am running into trouble with the file size of the rootfs.jffs2 being too large, the reflashing script errors with "TFTP error: 'File is too big, try increasing block size' (0)". I am looking internally to see if there is a better way to do this or a way to fix this (I suspect I have to rebuild U-Boot with a larger block size for TFTP which I will probably try). Once I get it flashed properly I can try to reproduce your demo failures from flash.

As to the error message, I can see this happen as well if I exit the demo forcibly (ctrl-C), I suspect this is a bug in the decode demo where there is an invalid exit condition and it is not freeing the resources it claimed properly, essentially the error message is saying that it could not obtain the proper memory from CMEM because it is still claimed by the bad exit of the first run of decode.

It seems rebuilding U-Boot with a block size of 1300 that should have adequately covered the size of the DVSDK filesystem did not work (or perhaps I am doing something else wrong). This being said I am curious how you are flashing the DVSDK filesystem to the EVM board?

Thompson,

I didnt flash the rootfs.jffs from DVSDK rather I flashed it from SDK. Perhaps I will flash it from DVSDK and check.

Regards,

Vineet