Has anyone managed to make work powervr? [WAS: PowerVR kernel drivers available for testing]

Hello,

Has anyone managed to make work the solution referenced below, i.e.
powervr open source driver by Nokia?

When pvrsrvinit starts, the following error is dumped to the console:

Unable to handle kernel NULL pointer dereference at virtual address
00000000
pgd = c6fac000
[00000000] *pgd=86eb6031, *pte=00000000, *ppte=00000000
Internal error: Oops: 17 [#1]
Modules linked in: pvrsrvkm ipv6
CPU: 0 Not tainted (2.6.27-omap1 #1)
PC is at PVRSRV_BridgeDispatchKM+0x70/0xd0 [pvrsrvkm]
LR is at 0x0
pc : [<bf03cb4c>] lr : [<00000000>] psr: 20000013
sp : c6de3f00 ip : 00000004 fp : c6de3f3c
r10: 41024000 r9 : c6de2000 r8 : c0034dc4
r7 : c6e7ef80 r6 : c01c670c r5 : 0000058b r4 : beb28b9c
r3 : 00000000 r2 : 00000000 r1 : beb28bb8 r0 : 00000000
Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 00c5387f Table: 86fac018 DAC: 00000015
Process pvrsrvinit (pid: 1548, stack limit = 0xc6de22e8)
Stack: (0xc6de3f00 to 0xc6de4000)
3f00: c01c670c 0000001c 00000000 00000000 beb28bb8 00000008 00000000
00000000
3f20: c0094580 c01c670c beb28b9c 00000003 c6de3f54 c6de3f40 c00aeecc
bf03cae8
3f40: c6e7ef80 beb28b9c c6de3f7c c6de3f58 c00af14c c00aee70 c6fab034
00000010
3f60: 00000003 beb28b9c c01c670c c6e7ef80 c6de3fa4 c6de3f80 c00af19c
c00aeee8
3f80: 4113d000 00000000 0001d008 00000003 00000008 00000036 00000000
c6de3fa8
3fa0: c0034c40 c00af168 0001d008 00000003 00000003 c01c670c beb28b9c
00000000
3fc0: 0001d008 00000003 00000008 00000036 00000000 00000000 41024000
00000000
3fe0: beb28ccc beb28b98 425f2750 410da99c 20000010 00000003 ebfffffe
e89da800
Backtrace:
[<bf03cadc>] (PVRSRV_BridgeDispatchKM+0x0/0xd0 [pvrsrvkm]) from
[<c00aeecc>] (vfs_ioctl+0x68/0x78)
r6:00000003 r5:beb28b9c r4:c01c670c
[<c00aee64>] (vfs_ioctl+0x0/0x78) from [<c00af14c>] (do_vfs_ioctl
+0x270/0x280)
r5:beb28b9c r4:c6e7ef80
[<c00aeedc>] (do_vfs_ioctl+0x0/0x280) from [<c00af19c>] (sys_ioctl
+0x40/0x64)
r7:c6e7ef80 r6:c01c670c r5:beb28b9c r4:00000003
[<c00af15c>] (sys_ioctl+0x0/0x64) from [<c0034c40>] (ret_fast_syscall
+0x0/0x2c)
r7:00000036 r6:00000008 r5:00000003 r4:0001d008
Code: e353000b 0a000005 e51b3024 e50b3020 (e5933000)
---[ end trace 2fcc06b7a0e8dd74 ]---

Any idea?

Gregoire

PS: I'm running linux-omap_2.6.27.bb (rc4) which includes the pvr
patches:
http://gitweb.openembedded.net/?p=openembedded.git;a=commitdiff;h=a61d3745d51ff8b2c7c8b307bfccea031cf99e30
and Koen has confirmed that it's not working right out of the box!

Gregoire,

I could run the demos on OMAP3 EVM using 2.6.27-omap1 kernel applied following patch and using the user space binaries corresponding to that pvr kernel module's version (cat /proc/pvr/version).

You need to load pvrsrvkm.ko, bc_example.ko and omap_lfb.ko and mknod /dev/pvrsrvkkm before running pvrsrvinit, I also increased framebuffer memory to 4MB (vram:4M) in bootargs.

Regards,
Pratheesh

It looks like I'm at the same point as Gregoire, since I'm receiving
the same NULL pointer deference in PVRSRV_BridgeDispatchKM. I'd like
to match up the version numbers as you suggest. It looks like I need
to request an older SDK from TI, but before I go through that process,
I want to confirm that there is no other route.

Here are the version numbers that I have found so far:

# cat /proc/pvr/version
Version 1.1.11.970 (release) drivers/gpu/pvr
System Version String: SGX revision = 1.0.3

SDK Package from TI: CSSD_Linux_23.10_GFX_SDK_v1.8.exe

binary_omap3430_linux_release/build_data.xml:
  <version>1.3.13.1397</version>

Sadly, the TI package did provide a 1.3.13.1397 version of
pvrsrvkm.ko, but it won't insert in the 2.6.27-omap1 kernel. It looks
like they built it against a 2.6.24 kernel.

Any ideas?

Thanks,
Frank

I have done more work so as to follow the instructions of Pratheesh
but with no luck so far.

Koen: you may consider to change defconfig in 2.6.27 and add
CONFIG_PVR_BUFFERCLASS_EXAMPLE=y. It could not hurt.

Frank: you can hex-edit the kernel modules and change the magic
string. I was able to insmod 2.6.22 working modules but obviously I
got more compatibility problems after.

I can't figure out if I have the right pvrsrvkm bin. There is no
version number anywhere. The TI extranet is a little bit challenging:
there are multiple entries (hard to figure out which SDK is really the
one for beagleboard), and the link I eventually got is not working any
more!

Any help from anyone would be appreciated,

Gregoire

Op 2 jan 2009, om 15:06 heeft TK, Pratheesh Gangadhar het volgende geschreven:

I am not sure what version of user space binaries Gregoire is using. If you have access to SDK from TI, you could look at install.sh for user space binary version. This script is generated while building DDK.

With attached pvrsrvkm.ko, I can use 1.3.13.1397 (23.10) version of user space binaries on my OMAP3 EVM running 2.6.27-omap1 kernel. I removed some functionality specific to TI kernel from this module to run with community kernel. I tried couple of OGLES1 and OGLES2 demos and they run fine.

Could you share the sources of this binary?

regards,

Koen

Op 2 jan 2009, om 15:06 heeft TK, Pratheesh Gangadhar het volgende
geschreven:

I am not sure what version of user space binaries Gregoire is using. If
you have access to SDK from TI, you could look at install.sh for user space
binary version. This script is generated while building DDK.

With attached pvrsrvkm.ko, I can use 1.3.13.1397 (23.10) version of user
space binaries on my OMAP3 EVM running 2.6.27-omap1 kernel. I removed some
functionality specific to TI kernel from this module to run with community
kernel. I tried couple of OGLES1 and OGLES2 demos and they run fine.

I just tried the attached pvrsrvkm.ko and am still having trouble.
Here's a log:

root@beagleboard:~# uname -a
Linux beagleboard 2.6.27-omap1 #1 Wed Dec 31 15:28:08 EST 2008 armv7l unknown
root@beagleboard:~# cp pvrsrvkm.ko
/lib/modules/2.6.27-omap1/kernel/drivers/gpu/pvr
root@beagleboard:~# modprobe -f pvrsrvkm
pvrsrvkm: Unknown symbol malloc_sizes
FATAL: Error inserting pvrsrvkm
(/lib/modules/2.6.27-omap1/kernel/drivers/gpu/pvr/pvrsrvkm.ko):
Unknown symbol in module, or unknown p)
root@beagleboard:~#

Thanks,
Frank

Op 2 jan 2009, om 15:06 heeft TK, Pratheesh Gangadhar het volgende
geschreven:

I am not sure what version of user space binaries Gregoire is using.
If you have access to SDK from TI, you could look at install.sh for
user space binary version. This script is generated while building
DDK.

With attached pvrsrvkm.ko, I can use 1.3.13.1397 (23.10) version of
user space binaries on my OMAP3 EVM running 2.6.27-omap1 kernel. I
removed some functionality specific to TI kernel from this module to
run with community kernel. I tried couple of OGLES1 and OGLES2 demos
and they run fine.

Could you share the sources of this binary?

Unfortunately I can't do that until we get a go ahead from legal. Jason might know the latest status.

Regards,
Pratheesh

Op 2 jan 2009 om 18:18 heeft "TK, Pratheesh Gangadhar" <pratheesh@ti.com> het volgende geschreven:\

From: Koen Kooi [mailto:koen@beagleboard.org]
Sent: Friday, January 02, 2009 7:47 PM
To: TK, Pratheesh Gangadhar
Cc: Beagle Board
Subject: Re: Has anyone managed to make work powervr? [WAS: PowerVR kernel drivers available for testing]

Op 2 jan 2009, om 15:06 heeft TK, Pratheesh Gangadhar het volgende
geschreven:

I am not sure what version of user space binaries Gregoire is using.
If you have access to SDK from TI, you could look at install.sh for
user space binary version. This script is generated while building
DDK.

With attached pvrsrvkm.ko, I can use 1.3.13.1397 (23.10) version of
user space binaries on my OMAP3 EVM running 2.6.27-omap1 kernel. I
removed some functionality specific to TI kernel from this module to
run with community kernel. I tried couple of OGLES1 and OGLES2 demos
and they run fine.

Could you share the sources of this binary?

Unfortunately I can't do that until we get a go ahead from legal. Jason might know the latest status.

Kernel modules are gpl, so why does legal need to sign off on it?

Regards,

Koen

Here is an update of the mplayer patch to output the video on plane 1.
It's compatible with linux-omap_2.6.29.bb (DSS2 with or without
rotation) and still uses the Mru assembly yuv conversion,

Gregoire

diff --git a/recipes/mplayer/files/omapfb.patch
b/recipes/mplayer/files/omapfb.patch
index 860cf07..2356d80 100644
--- a/recipes/mplayer/files/omapfb.patch
+++ b/recipes/mplayer/files/omapfb.patch
@@ -8,3 +8,22 @@
  extern vo_functions_t video_out_svga;
  extern vo_functions_t video_out_png;
  extern vo_functions_t video_out_ggi;
+@@ -177,6 +178,7 @@
+ #ifdef CONFIG_FBDEV
+ &video_out_fbdev,
+ &video_out_fbdev2,
++ &video_out_omapfb,
+ #endif
+ #ifdef CONFIG_SVGALIB
+ &video_out_svga,
+--- a/Makefile 2009-02-03 13:45:48.000000000 -0800
++++ b/Makefile 2009-02-03 13:45:50.000000000 -0800
+@@ -551,7 +551,7 @@
+ SRCS_MPLAYER-$(DXR2) += libao2/ao_dxr2.c libvo/vo_dxr2.c
+ SRCS_MPLAYER-$(DXR3) += libvo/vo_dxr3.c
+ SRCS_MPLAYER-$(ESD) += libao2/ao_esd.c
+-SRCS_MPLAYER-$(FBDEV) += libvo/vo_fbdev.c libvo/vo_fbdev2.c
++SRCS_MPLAYER-$(FBDEV) += libvo/vo_fbdev.c libvo/vo_fbdev2.c
libvo/vo_omapfb.c libvo/yuv.S
+ SRCS_MPLAYER-$(GGI) += libvo/vo_ggi.c
+ SRCS_MPLAYER-$(GIF) += libvo/vo_gif89a.c
+ SRCS_MPLAYER-$(GL) += libvo/gl_common.c libvo/vo_gl.c
libvo/vo_gl2.c

diff --git a/recipes/mplayer/mplayer_svn.bb
b/recipes/mplayer/mplayer_svn.bb
index fa39d79..3162191 100644
--- a/recipes/mplayer/mplayer_svn.bb
+++ b/recipes/mplayer/mplayer_svn.bb
@@ -16,7 +16,7 @@ SRC_URI = "svn://svn.mplayerhq.hu/mplayer;module=trunk
\
      "

SRC_URI_append_armv7a = " \
-# file://omapfb.patch;patch=1 \
+ file://omapfb.patch;patch=1 \
      file://vo_omapfb.c \
      file://yuv.S \
     "
@@ -198,6 +198,8 @@ do_configure_prepend_armv7a() {
    cp ${WORKDIR}/vo_omapfb.c ${S}/libvo
   cp ${STAGING_KERNEL_DIR}/arch/arm/plat-omap/include/mach/omapfb.h
${S}/libvo/omapfb.h || true
    cp ${STAGING_KERNEL_DIR}/include/asm-arm/arch-omap/omapfb.h
${S}/libvo/omapfb.h || true
+ cp ${STAGING_KERNEL_DIR}/include/linux/omapfb.h ${S}/libvo/omapfb.h ||
true
+ sed -e 's/__user//g' -i ${S}/libvo/omapfb.h || true
}

CFLAGS_append = " -I${S}/libdvdread4 "

/*

vo_omapfb.c (13.6 KB)

patch1 (870 Bytes)

patch2 (1.14 KB)

I tried it, but I get:

[omapfb] Error mmap

regards,

Koen

Here is a patch against Felipe's gst-omapfb which enables to move around
the video outputted on plane 1. It also uses the optimized assembly YUV
conversion from Man's omapfbplay. It has been successfully tested
against 2.6.29 with DSS2 and totem 2.6.24.

With 2.6.29, DSS2, DSP-[link or bridge], Totem obviously beats my
"mplayer -vo omapfb" (same color conversion but you compare ffmpeg
against DSP!) and it uses only 15% of CPU. Nevertheless, it's a little
bit longer to start than mplayer.

Here are a couple of ideas of contributions in the video space if people
want to help:
- color conversion in DSP. That would be interesting! Somebody needs to
write a DSP-top tool to see if there are enough DSP cycles after
decoding to add the conversion on top of it.

- DSP[bridge or link] integrated into mplayer. We did some
investigations and it's definitely feasible. A guy on OpenMoko
succesfully did some similar work. But this requires some efforts.

Grégoire

PS: Sorry, the recipe is not very clean in the do_configure_prepend due
to the headers which have moved around but it works...

DESCRIPTION = "GST Omapfb"
AUTHOR = "Gregoire Gentil"
LICENSE = "GPL"

inherit autotools

DEPENDS = "gstreamer linux-omap"

PR = "r1"
SRCREV = "6f0b1cb50d1c67c3a3db2f11246256060ac871de"
PV = "0.0+${PR}+gitr${SRCREV}"

SRC_URI = "git://github.com/felipec/${PN}.git;protocol=git \

file://0001-Implement-XOverlay-and-I420-to-422-colorspace-conver.patch;patch=1"

S="${WORKDIR}/git"

EXTRA_OEMAKE_append = " KERNEL=
${STAGING_DIR}/${MACHINE_ARCH}${TARGET_VENDOR}-${TARGET_OS}/kernel"

do_configure_prepend() {
  cp
${STAGING_DIR}/${MACHINE_ARCH}${TARGET_VENDOR}-${TARGET_OS}/kernel/include/linux/omapfb.h ${STAGING_DIR}/armv7a${TARGET_VENDOR}-${TARGET_OS}/usr/include/linux/omapfb.h
   sed -e 's/__user//g' -i ${STAGING_DIR}/armv7a
${TARGET_VENDOR}-${TARGET_OS}/usr/include/linux/omapfb.h
}

do_install() {
  install -d ${D}${libdir}
  install -d ${D}${libdir}/gstreamer-0.10
  install -m 0755 libgstomapfb.so ${D}${libdir}/gstreamer-0.10
}

FILES_${PN} += "/usr/lib/gstreamer-0.10/libgstomapfb.so"

From 7c8f0e13cd2558851ab3277a14a8929e14f5428f Mon Sep 17 00:00:00 2001

gst-omapfb_1.0.bb (998 Bytes)

0001-Implement-XOverlay-and-I420-to-422-colorspace-conver.patch (34.6 KB)

Here is a patch against Felipe's gst-omapfb which enables to move around
the video outputted on plane 1. It also uses the optimized assembly YUV
conversion from Man's omapfbplay. It has been successfully tested
against 2.6.29 with DSS2 and totem 2.6.24.

With 2.6.29, DSS2, DSP-[link or bridge], Totem obviously beats my
"mplayer -vo omapfb" (same color conversion but you compare ffmpeg
against DSP!) and it uses only 15% of CPU. Nevertheless, it's a little
bit longer to start than mplayer.

Here are a couple of ideas of contributions in the video space if people
want to help:
- color conversion in DSP. That would be interesting! Somebody needs to
write a DSP-top tool to see if there are enough DSP cycles after
decoding to add the conversion on top of it.

TI's decoders already support multiple YUV formats (I420, UYVY, YUY2),
there's no need for conversion on ARM side, but also, there a DSP
converter, although I'm not sure it's distributed on the public
binaries.

And we already have a dsp-top utility at Nokia, I'll try to clean it
up to make a public release :slight_smile:

- DSP[bridge or link] integrated into mplayer. We did some
investigations and it's definitely feasible. A guy on OpenMoko
succesfully did some similar work. But this requires some efforts.

The good thing is that you have libomxil-ti for reference, so in
theory it's only a matter of removing all the OpenMAX stuff.

I'll review the patches as soon as I can.

Cheers.

Hello, Grégoire!

I too have a recipe for gst-omapfb. In case it's of any use for you, it's here:
  http://github.com/mturquette/meta-texasinstruments/blob/01619b4e50b2e8be7482ab84adeb108a8baf7961/packages/gst-omapfb/gst-omapfb_git.bb

(The patch is in the same directory.)

Greetings!

Daniel Díaz
ddiaz@ti.com

> Here is a patch against Felipe's gst-omapfb which enables to move around
> the video outputted on plane 1. It also uses the optimized assembly YUV
> conversion from Man's omapfbplay. It has been successfully tested
> against 2.6.29 with DSS2 and totem 2.6.24.
>
> With 2.6.29, DSS2, DSP-[link or bridge], Totem obviously beats my
> "mplayer -vo omapfb" (same color conversion but you compare ffmpeg
> against DSP!) and it uses only 15% of CPU. Nevertheless, it's a little
> bit longer to start than mplayer.
>
> Here are a couple of ideas of contributions in the video space if people
> want to help:
> - color conversion in DSP. That would be interesting! Somebody needs to
> write a DSP-top tool to see if there are enough DSP cycles after
> decoding to add the conversion on top of it.

TI's decoders already support multiple YUV formats (I420, UYVY, YUY2),
there's no need for conversion on ARM side, but also, there a DSP
converter, although I'm not sure it's distributed on the public
binaries.

[G2]. Correct. When gstreamer uses the DSP, there is no need of color
conversion. Man's assembly is only used in gst-omapfb if you use the
ffmpeg gstreamer.

And we already have a dsp-top utility at Nokia, I'll try to clean it
up to make a public release :slight_smile:

> - DSP[bridge or link] integrated into mplayer. We did some
> investigations and it's definitely feasible. A guy on OpenMoko
> succesfully did some similar work. But this requires some efforts.

The good thing is that you have libomxil-ti for reference, so in
theory it's only a matter of removing all the OpenMAX stuff.

I'll review the patches as soon as I can.

[G2]. Thanks!

Grégoire