2011/12/19 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:

So whatever calls ProcessFlipV2() disagrees with the kernel on just what a dsscomp_setup_dispc_data structure should contain.

Just checked, the problem is that the kernel's idea of a dss2_ovl_info struct is different from bionic's. Very different, even.

The problem is the rather stupid idea of including a set of kernel headers (external/kernel-headers/original/) inside AOSP instead of getting the kernel headers from the kernel, where they ought to be. I think the best way to fix it is to put the correct kernel headers in place and add an invocation of bionic/libc/kernel/tools/update_all.py to the build process.

Will check if that's doable without too much effort.

ttyl bero

2011/12/19 Zach Pfeffer zach.pfeffer@linaro.org:

Here's the current score card:

https://android-build.linaro.org/builds/~berolinux/landing-panda-4.0.3/#buil...

• blows up, 4430

The reason is that the kernel and userland disagree about the size and content of the dss2_ovl_info. The problem's core is that Bionic grabs prepackaged kernel headers instead of using those from the actual kernel being used, but the fix for that (replacing them with proper kernel headers) causes stuff not to build because it's missing some headers, and the quickfix (just copying over the file defining dss2_ovl_info, video/dsscomp.h) breaks the build because the kernel's dsscomp.h doesn't define DSSCIOC_QUERY_DISPLAY, but hardware/ti/omap4xxx/hwc/hwc.c:1924 tries to make use of that.

Another possible fix is reverting the commit in external/kernel-headers that changed dss2_ovl_info (commit ID 305d9b714eb73c10465abdade0061eee3bdb76ef and its followup 7c04a2b599c5c989bb1aaf24905f71ae0ab4e9e5), but chances are that will compile, but break at runtime (because DSSCIOC_QUERY_DISPLAY is defined and used in omap4xxx/hwc/hwc.c, but the kernel has no idea what to do with it). But it's worth a try, will start a build.

https://android-build.linaro.org/builds/~berolinux/staging-imx53-4.0.3/#buil...

• no display

Probably not 4.0.3 related https://bugs.launchpad.net/linaro-android/+bug/906245

This is probably the same thing I've seen last night, but that went away after rebooting. I guess we have some odd random failure here (timing issue?). Seems to happen all the time on Botao's box though (his has a HDMI extension, that may or may not be related. Apparently 11.11 works though, and there hasn't been any kernel change on iMX53 since 11.11.

https://android-build.linaro.org/builds/~berolinux/staging-snowball-4.0.3/#b...

• fails

Any idea why?

no landing-snowball

I overlooked that one, building right now

ttyl bero

2011/12/19 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org

2011/12/19 Zach Pfeffer zach.pfeffer@linaro.org:

...

Here's the current score card:

https://android-build.linaro.org/builds/~berolinux/landing-panda-4.0.3/#buil...

...

• blows up, 4430

The reason is that the kernel and userland disagree about the size and

content of the dss2_ovl_info. The problem's core is that Bionic grabs prepackaged kernel headers instead of using those from the actual kernel being used, but the fix for that (replacing them with proper kernel headers) causes stuff not to build because it's missing some headers, and the quickfix (just copying over the file defining dss2_ovl_info, video/dsscomp.h) breaks the build because the kernel's dsscomp.h doesn't define DSSCIOC_QUERY_DISPLAY, but hardware/ti/omap4xxx/hwc/hwc.c:1924 tries to make use of that.

Another possible fix is reverting the commit in external/kernel-headers that changed dss2_ovl_info (commit ID 305d9b714eb73c10465abdade0061eee3bdb76ef and its followup 7c04a2b599c5c989bb1aaf24905f71ae0ab4e9e5), but chances are that will compile, but break at runtime (because DSSCIOC_QUERY_DISPLAY is defined and used in omap4xxx/hwc/hwc.c, but the kernel has no idea what to do with it). But it's worth a try, will start a build.

Reverting the last 2commits on the kernel may get it back to the working

stage with graphics binaries for master from http://code.google.com/android/nexus/drivers.html#panda, but the reason for failure here is that we are using older proprietary binaries thruough "install-binaries.sh" script. I tried with 4.0.3http://code.google.com/android/nexus/drivers.html#pandagraphics binaries for panda but it is still failing.

My guess is that the kernel source is not yet updated using which we(device/linaro/pandaboard based builds) do our builds whereas aosp device/ti/panda configuration uses only the kernel binary (seems to have update the bianary here http://android.git.linaro.org/gitweb?p=device/ti/panda.git%3Ba=summary).

...

https://android-build.linaro.org/builds/~berolinux/staging-imx53-4.0.3/#buil...

...

• no display

Probably not 4.0.3 related https://bugs.launchpad.net/linaro-android/+bug/906245

This is probably the same thing I've seen last night, but that went away after rebooting. I guess we have some odd random failure here (timing issue?). Seems to happen all the time on Botao's box though (his has a HDMI extension, that may or may not be related. Apparently 11.11 works though, and there hasn't been any kernel change on iMX53 since 11.11.

...

https://android-build.linaro.org/builds/~berolinux/staging-snowball-4.0.3/#b...

...

• fails

Any idea why?

...

no landing-snowball

I overlooked that one, building right now

ttyl bero

staging-snowball 4.0.3 build https://android-build.linaro.org/builds/~berolinux/staging-snowball-4.0.3/fa... to boot. linaro_android_4.0.3 branch device/linaro/snowball doesn't seem to be at linaro_android_4.0.1 . Running one more build now with the branch being updated to the tip.

2011/12/19 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org

2011/12/19 Bernhard Rosenkränzer bernhard.rosenkranzer@linaro.org:

...

So whatever calls ProcessFlipV2() disagrees with the kernel on just what a dsscomp_setup_dispc_data structure should contain.

Just checked, the problem is that the kernel's idea of a dss2_ovl_info struct is different from bionic's. Very different, even.

The problem is the rather stupid idea of including a set of kernel headers (external/kernel-headers/original/) inside AOSP instead of getting the kernel headers from the kernel, where they ought to be. I think the best way to fix it is to put the correct kernel headers in place and add an invocation of bionic/libc/kernel/tools/update_all.py to the build process.

Will check if that's doable without too much effort.

ttyl bero