Hi,
Per Zach's request, I'm forwarding this tip to this list.
I managed to fix bug #872819 (see
https://bugs.launchpad.net/linaro-android/+bug/872819 )
on my Panda running ICS 4.0.1.
One just need to force "ro.opengles.version" system property to
"131072" makes it work.
The game then runs flawlessly on my board (with PVR GFX libs ofc).
Do you need me to submit a patch for that or are the info enough ?
Ben
Hi,
I've verified that toolchain 11.12 compiles our userland ok, the only
problem is w/ the kernel.
A build using the 11.12 toolchain for userland and an older toolchain
for the kernel is ok.
Currently trying some other workarounds, such as adding
-mno-unaligned-access to the kernel compiler flags, checking if it's
already fixed on head, trying the generic arm-eabi toolchain for the
kernel, etc.
ttyl
bero
Thanks Tony. Including others who are curious about DS-5.
On 18 December 2011 15:59, Tony Mansson <tony.mansson(a)linaro.org> wrote:
> Hi Zach,
>
>
> Start on this
> page: https://wiki.linaro.org/Platform/Android/DebugAndroidUsingDS-5
>
> You may want to skip the gdb debugging under the section "Getting started".
> gdb debugging is completely done over adb, so "Linaros" responsibility for
> functionality is just to make sure that adb is working. For Snowball that of
> course means adb over Ethernet since USB is crap. That's easy to set up.
>
> The the link at the bottom of the page goes to the Developer peoples page
> where it is demonstrated how to run Slipstream.
>
> Slipstream is the thing that talks to gatord and makes sens out of the data
> collection that gatord gets from gator.ko. So if DS-5 can draw its fancy
> charts then the gator functionality is verified. I have done this with my
> Snowball a couple of days ago.
>
> This is a good
> page: http://www.arm.com/products/tools/software-tools/ds-5/community-edition/ind…
>
> I will focus on gdb with DS-5 tomorrow because that's what people will be
> most interested in and it needs to be described properly on the wiki.
>
> There is a guy from ARM who will be available from Wednsday to help me make
> sure I get all the finder details of running DS-5.
>
>
> /Tony
--
Zach Pfeffer
Android Platform Team Lead, Linaro Platform Teams
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linarohttp://twitter.com/#!/linaroorg - http://www.linaro.org/linaro-blog
Hi,
I've done a quick 4.0.3 rebase and started a Panda test build:
https://android-build.linaro.org/builds/~berolinux/landing-panda-4.0.3/
Source-wise we should be ok, so you may want to play around with it on
all boards over the weekend.
This is extremely late for 11.12 (somehow Google's release cycle
doesn't like ours...), but let's see...
If this build actually works well, I'll make builds for all other boards.
ttyl
bero
I'll try isolating the breakage with a slightly different strategy:
https://android-build.linaro.org/builds/~berolinux/panda-bisect-component/
The idea is to isolate the component that breaks things by switching
revisions from the pinned-manifest.xml files. Once we know the
component, finding the commit should be a lot easier.
The first build is identical to the first bad build, with
device/linaro/common
device/linaro/pandaboard
platform/dalvik
platform/frameworks/base
platform/system/core
reverted to the revisions found in the last good build.
I'm pretty sure that will produce another "good" build (the other
changes really shouldn't affect bootup...)
Then we can go back to the versions of device/* from the bad build,
and we're already down to 2 or 3 components as the possible culprits.
If we ever have plenty of time, a "repo bisect" function (like git
bisect) would be great to have...
ttyl
bero
