SGX driver failing on ICS on tracking-panda

[vishal]

SGX driver is failing on tracking-panda build https://android-build.linaro.org/builds/~linaro-android/tracking-panda/ . The build is excluding the binaries from http://git.omapzoom.org/?p=device/ti/proprietary-open.git . After adding the binaries manually, ICS fails to boot with the error
PVR_K:(Error): BridgedDispatchKM: Driver initialisation not completed yet. [4652, drivers/gpu/pvr/bridged_pvr_bridge.c]
[ 21.756896] PVR_K:(Error): BridgedDispatchKM: Driver initialisation not completed yet. [4652, drivers/gpu/pvr/bridged_pvr_bridge.c] .

the SGX driver and binaries need to be updated for ICS.

[warmcat (andy-warmcat)]

Seems you forgot to copy something over in the rootfs? -->

[ 6.012756] init: cannot find '/vendor/bin/pvrsrvinit', disabling 'pvrsrvinit'

[vishal (vishalbhoj)]

oops I copied it into the wrong path (system/bin/) . I have now copied it at the right location and driver loads up but userspace fails to work with the GB binaries.

The driver and the userspace need to be upgraded for ICS .

[warmcat (andy-warmcat)]

It wouldn't surprise me if the SGX stuff does need upgrading, but it seems it blows chunks here and then never starts the SGX user libs at the moment

[ 5.498321] ERROR omaplfb (InitDev 1549): Framebuffer 1 has an invalid state, width and height are 0,0
[ 5.508728] ERROR omaplfb (OMAPLFBInit 1813): Unable to initialize display device 1
[ 5.517059] WARNING omaplfb (OMAPLFB_Init 432): Driver init failed

[Scott Bambrough (scottb)]

It seems that the latest binaries available from Google rely on PVR DDK1.8. Currently we only have kernel source for PVR DDK1.7 in the TILT tree. Perhaps we should create a topic branch from the PVR DDK1.8 code in the AOSP kernel, and use the Google binarie for our Android release, since I see none forthcoming to Linaro in the immediate future. Maybe we can convince Nicholas to move the Ubuntu binaries in the PPA up to the same release; Andy and/or I can explore that with him.

[Nicolas Dechesne (ndec)]

scott, as of today, there is no DDK1.8 that works with X11. hence we cannot move Ubuntu to 1.8. we are tracking this internally, but it requires engineering effort to make the transition, and there is no good reason and no resources to do it now (except to align ubuntu and android DDK which is not a must have as of today for us).

also the DDK1.7 was especially made to allow a reuse of the kernel driver between Android and Ubuntu (Motorola BIONIC is the reason why this happens...), there is no reason to believe that the DDK1.8 will offer that too...

However, the linaro kernel includes the PVR driver for GB indeed (DDK1.7) but for Ubuntu we use an external PVR module that is provided as an out-of-driver. so you might be able to update the in-tree PVR to 1.8 without impacting Ubuntu images at all.

that said, I believe that GFX in ICS will require much more drivers than just PVR. there are new dss features in the ICS OMAP kernel, as well as new components such as dsscomp or ion which is required for GFX in ICS.

I would definitely recommend that we main a common base kernel used for Ubuntu and put the Android stuff in another branch as I am not sure if the android bits will impact Ubuntu GFX... it might be able to be managed with flags eventually, but let's start with a branch.

[Alexander Sack (asac)]

Hi,

On Thu, Dec 8, 2011 at 7:04 PM, Nicolas Dechesne
<email address hidden>wrote:

> However, the linaro kernel includes the PVR driver for GB indeed
> (DDK1.7) but for Ubuntu we use an external PVR module that is provided
> as an out-of-driver. so you might be able to update the in-tree PVR to
> 1.8 without impacting Ubuntu images at all.
>

This was what I was proposing as a general rule:
 1. in-kernel module == android
 2. out-of-kernel tree == ubuntu would definitely recommend that we main a
common base kernel used for

Ubuntu and put the Android stuff in another branch as I am not sure if
> the android bits will impact Ubuntu GFX... it might be able to be
> managed with flags eventually, but let's start with a branch.
>

I would prefer if we default to use the same branch and only start
branching off
after good evaluation and knowing that there are issues (rather than
suspecting).

--
Alexander Sack
Technical Director, Linaro Platform Teams
http://www.linaro.org | Open source software for ARM SoCs
http://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog

[Nicolas Dechesne (ndec)]

On Thu, Dec 8, 2011 at 8:21 PM, Alexander Sack <email address hidden> wrote:

> Ubuntu and put the Android stuff in another branch as I am not sure if
> > the android bits will impact Ubuntu GFX... it might be able to be
> > managed with flags eventually, but let's start with a branch.
> >
>
> I would prefer if we default to use the same branch and only start
> branching off
> after good evaluation and knowing that there are issues (rather than
> suspecting).

you can make a common branch, but there will be lots of #ifdef in display
driver in the board config file and that will make the code less manageable
and more difficult to rebase..

also this bug is about GFX, but soon we will talk about MM h/w, and here
again it will be very difficult and cumbersome to maintain a single code
base.

in any case 2 branch with clean code or 1 branch with #ifdef, it's still 2
code base ;-)

[Scott Bambrough (scottb)]

I'm proposing we add an in kernel module for PVR for Android as a topic branch used only for Android.

Nicholas is suggesting we may need further topic branches (dss, dsscomp, etc) for Android as well.

>> DDK1.7 was especially made to allow a reuse of the kernel driver between Android and Ubuntu
>> (Motorola BIONIC is the reason why this happens...), there is no reason to believe that the DDK1.8
>> will offer that too...

Not sure if DDK1.8 will have a kernel driver that is reusable between Android and Ubuntu. Nicholas, were you trying to say 1.7 was a one off, and re-usability won't be a feature in DDK1.8?

We can't default to the same branch. The Android stuff won't work in Ubuntu (no X11 support). Also we will need to keep the Ubuntu stuff working consistently, as TI plans to use 3.2 for their next customer release in early January. If anything is going to be broken, it has to be Android, not Ubuntu per our obligations in the SOW.

[warmcat (andy-warmcat)]

Guys we have been working on this for nearly a week now trying to extract everything from omapzoom. I spent a couple of days on it and handed it over to Jassi with my notes.

However it seems despite omapzoom seems to have appropriate set of ingredients, it is not workable with 'mr0' userland libs for ics and Vishal advises us to go mine from Android's Panda tree instead.

I wouldn't assume this will bear any fruit in the next week or two for 11.12, it is a very large and ugly job that has already defeated several people. In addition, we not only transplant to tracking which is its own challenge, but on top of quite different dss there which will demand a lot of integration action, overlay apis and dssconp were obvious differenes but there are lots more.

Also we know from previous work there is very very unlikely to be any commonality between sgx for android and vanilla. So we already deal with that well by having in-tree sgx in its own topic that ubuntu never sees and use out-of-tree sgx build for ubuntu.

That technique can get expensive if overused because it multiplies the number of output trees for test, however it's powerful enough to deal with dss changes / additions on top of current tracking entirely in the sgx topic, so no worries there at least (worries everywhere else on this one though). Similarly this is why we're unfazed about supporting 2.0 and 3.0 mm stuff together, we would build the tree twice once with each kind of topics.

[Zach Pfeffer (pfefferz)]

We've got SGX working with the kernel from AOSP right now. We can keep using that and working with those guys and the guys from omapzoom until the LT tree gets fixed.

[warmcat (andy-warmcat)]

TI LT added SGX-1.8 working with Build 4 of Linaro ICS to tilt-android-tracking before Christmas... I suggest you target resources on that rather than one of the many release-based Google kernels.

[vishal (vishalbhoj)]

SGX works on https://android-build.linaro.org/builds/~linaro-android/tracking-panda/#build=134

[Abhishek Paliwal (abhishek-paliwal)]

No HwGfx on https://android-build.linaro.org/builds/~linaro-android/staging-panda-12.01-release/#build=2

[Tony Mansson (tony-mansson)]

PLease see bug #921098 that is the same issue limited to staging-panda and generic panda.