On 26 August 2011 13:02, Fabio Estevam festevam@gmail.com wrote:

On Fri, Aug 26, 2011 at 2:38 PM, Zach Pfeffer zach.pfeffer@linaro.org wrote: ...

...

Since the kernel is running the framebuffer I would start to look there.

Yves,

Do you have a PoC for the framebuffer driver owner at Freescale?

Jason.Chen@freescale.com

Thanks Fabio. Jason, have you seen an issue with the framebuffer driver and Android where you basically see nothing on the screen until the last framebuffer update? When you use the unit the screen would basically be dark while anything was being drawn and then you'd see the results of the draw.

Regards,

Fabio Estevam

On 26 August 2011 20:06, Eric Miao eric.miao@linaro.org wrote:

On Sat, Aug 27, 2011 at 1:38 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:

...

On 26 August 2011 09:35, Eric Miao eric.miao@linaro.org wrote:

...

Hi Zach,

We are really a bit short of resource at this moment. We'll definitely look into this issue once we finish our current focused work (likely the week after next). However, before that, could your team help with:

Can you pull it in a little? You guys have known about this for a month.

Haitao was busy debugging on the issue that MMC being removed, and you changed the priority of this bug to highest just _this_ week. Does this help even if we know this for a month?

I didn't change any priority. I was asking about a bug you've had in your queue for a month and haven't touched.

...

...

1. step by step instructions of how to reproduce this in detail

Just load the build and run it.

OK, let me be clear:

• Where do we download the rootfs image?

• Which version do we need to download to reproduce?

• Any modification to u-boot command line?

• Any modification to config files on that rootfs image?

• Since you are also building the kernel from our source (and it's

changed a bit in some way as I know which I have no feedback on what has been changed), could you also point out where do we download the kernel

These instructions are listed with every release. Here they are again:

export MANIFEST_REPO=git://android.git.linaro.org/platform/manifest.git export MANIFEST_BRANCH=linaro-android-11.08-release export MANIFEST_FILENAME=LEB-iMX53.xml export TARGET_PRODUCT=iMX53 export TARGET_BUILD_VARIANT=eng export TARGET_SIMULATOR=false export TOOLCHAIN_URL=https://android-build.linaro.org/jenkins/job/linaro-android_toolchain-4.6-20...

repo init -u ${MANIFEST_REPO} -b ${MANIFEST_BRANCH} -m ${MANIFEST_FILENAME}

wget --no-check-certificate ${TOOLCHAIN_URL}

tar -jxvf android-toolchain-eabi-linaro*

make TARGET_PRODUCT=${TARGET_PRODUCT} TARGET_TOOLS_PREFIX=./android-toolchain-eabi/bin/arm-eabi- boottarball systemtarball userdatatarball

bzr branch lp:linaro-image-tools

./linaro-image-tools/linaro-android-media-create --mmc /dev/sdc --dev iMX53 --system ./out/target/product/pandaboard/system.tar.bz2 --userdata ./out/target/product/pandaboard/userdata.tar.bz2 --boot ./out/target/product/pandaboard/boot.tar.bz2

...

...

2. some analysis of this issue to see if it's really a kernel bug, as the rootfs

I know we are using now is from beagle/panda, which could be different in the framebuffer layer, that will greatly simply our debug later.

You'll need to start by pulling a build so that we're talking from the same environment. You can also load the build up to see the issue without rebuilding with these commands:

wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_leb-imx53-11.08-... wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_leb-imx53-11.08-... wget --no-check-certificate https://android-build.linaro.org/jenkins/job/linaro-android_leb-imx53-11.08-...

bzr branch lp:linaro-image-tools

./linaro-image-tools/linaro-android-media-create --mmc /dev/sdc --dev iMX53 --system system.tar.bz2 --userdata userdata.tar.bz2 --boot boot.tar.bz2

...

Since the kernel is running the framebuffer I would start to look there.

The framebuffer is working all right under Ubuntu, so I assume there could be some mis-use, esp. the omapfb extends some of the framebuffer API and we have no idea what impact that will have on top of i.MX5' fb. And FYI - the framebuffer works all right as well with Adeneo's rootfs (a 3rd party that helps Freescale w/ Android on i.MX5)

Sure, but something up with Android and we need help fixing it.

...

Yves,

Do you have a PoC for the framebuffer driver owner at Freescale?

Jason is the owner for the fb driver and he's part of the landing team. That does _not_ necessarily mean he knows how to fix this issue.

And the key point here is: you have no idea if this _is_ a framebuffer driver issue before any analysis is done.  Esp. because the framebuffer is working all right under ubuntu. And your Android team should have better idea how fb is integrated in Android, and have a better position to first debug this issue until the framebuffer driver can be blamed.

No ones blaming we're just getting things together to start debugging the issue. We need to get everyone in the room so that we can ask the right questions.

...

-Zach

...

Thanks Zach, and I'm really sorry to have some delay here.

• eric

On Fri, Aug 26, 2011 at 9:01 AM, Zach Pfeffer zach.pfeffer@linaro.org wrote:

...

The biggest priority is the display bug:

https://bugs.launchpad.net/linaro-android/+bug/824506

Where are you guys on fixing this?

-Zach

On 17 August 2011 21:21, Eric Miao eric.miao@linaro.org wrote:

...

Hi Bero,

I was not there but Haitao was. Weird that you found no one. Haitao's nick is minipanda|*, and he was in channel #linaro-android. Think there is some misunderstanding here. I think we agreed on:

1. staying in #linaro-android for discussion (freenode)
2. if necessary, mumble for real time talk

And Haitao was working on the MMC card being incorrectly removed during android startup. Let me know from Android team the priority of the bugs so we can focus.

Thanks

• eric

On Thu, Aug 18, 2011 at 1:11 AM, Bernhard Rosenkranzer bernhard.rosenkranzer@linaro.org wrote:

...

Hi, I haven't heard anything, and nobody else seemed to be around at the meeting time. Have you done any work on this?

ttyl bero

On 16 August 2011 07:42, Eric Miao eric.miao@linaro.org wrote: > On Tue, Aug 16, 2011 at 5:25 PM, Bernhard Rosenkranzer > bernhard.rosenkranzer@linaro.org wrote: >> Hi, >> I'm "somewhat" around -- still have to do a lot of work on the day job, and >> the only official OK I have is to participate in the related IRC sessions. >> But I can make some time aside from that. >> 6 more weeks and I'm finally out of there (probably a bit less, I still have >> a couple of vacation days left). > > Thanks Bero, Haitao will be working on the bugs at that time, and could > ping you on IRC now and then. > >> ttyl >> bero >> >> On 16 August 2011 10:28, Eric Miao eric.miao@linaro.org wrote: >>> >>> Bero, >>> >>> Bero, will you be available for tomorrow's hacking session? So Haitao >>> could help work on the bugs you filed last week? >>> >>> - eric >> >> >

Hi,

OK, here's one preliminary theory after I dragged Jason to a conversation from his weekend in a vacation.

Thanks! Could have waited until Monday of course, but it's great to have another starting point to work on over the weekend.

There could be mis-use of the framebuffer's FBIOPUT_VSCREENINFO as a way to update the screen instead of using FBIOPAN_DISPLAY.

That's exactly what Android does in a couple of places, e.g. system/core/init/logo.c, function fb_update() [that one actually calls FBIOPUT_VSCREENINFO _twice_ to update the screen] hardware/libhardware/modules/gralloc/framebuffer.cpp, function fb_post

This should be fairly easy to fix, but googling it, I found an explanation from an upstream engineer on why they're doing it that way -- apparently on some graphics drivers, FBIOPAN_DISPLAY does smooth panning, which obviously isn't what you want for a simple screen refresh.

I'm definitely going to change it to see whether or not this is the problem (and also to probably get a bit of a performance boost on Panda) - but I wonder what hardware we're going to break with that.

Given other pieces of code (e.g. SDL) use FBIOPAN_DISPLAY for screen refreshes, I think using that ioctl should be mostly safe.

The former ioctl could take significant amount of time re-calculating the timing assuming resolution/color depth changes, and re-initializing the controller for a new mode, and that could result in screen blinking.

That is consistent with the messages I'm seeing in dmesg output. Maybe (in addition to fixing userland) the driver should be a bit smarter and not reinitialize the controller if it realizes the old and new modes are actually the same, given Android is probably not the only piece of code that uses FBIOPUT_VSCREENINFO, given apparently some fb drivers interpret FBIOPAN_DISPLAY as something different...

ttyl bero

On Sun, Aug 28, 2011 at 8:52 PM, Bernhard Rosenkranzer bernhard.rosenkranzer@linaro.org wrote:

On 27 August 2011 21:45, Bernhard Rosenkranzer bernhard.rosenkranzer@linaro.org wrote:

...

That's exactly what Android does in a couple of places, e.g. system/core/init/logo.c, function fb_update() [that one actually calls FBIOPUT_VSCREENINFO _twice_ to update the screen] hardware/libhardware/modules/gralloc/framebuffer.cpp, function fb_post

I just changed it, and it works! We now have a really working display on iMX53 Android. Thanks to everyone who helped!

Thanks Bero for the hard work, glad we helped.

Zach,

Can we close this bug or let me know what further can we help on this one. Thanks.

ttyl bero

On 29 August 2011 07:11, Christian Robottom Reis kiko@linaro.org wrote:

I don't think we should keep the bug open pending feedback from upstream, but we definitely should start a thread to figure out why upstream has chosen to use FBIOPUT_VSCREENINFO.

We know that -- they chose it because some driver they were working with thought that FBIOPAN_DISPLAY should do smooth panning, which obviously isn't what you want to do to flip between 2 buffers. IMO that driver should be fixed if we ever run into it (especially given other stuff, like SDL, also uses FBIOPAN_DISPLAY).

If we run into it and we can't fix the driver, I propose something along the lines of

static int REFRESH_DISPLAY = FBIOPAN_DISPLAY; [...] ioctl(fd, FBIOGET_FSCREENINFO, &fi); if(!strcmp(fi.id, "BrokenDriver")) REFRESH_DISPLAY = FBIOPUT_VSCREENINFO; [...] ioctl(fd, REFRESH_DISPLAY, &whatever);

Given FBIOPAN_DISPLAY and FBIOPUT_VSCREENIFNO take the same parameters, we can do that almost without penalty.

ttyl bero