glamo WSOD in 2.6.32 kernel (WAS Re: Git Repository not Working)

Michael Trimarchi trimarchi at
Wed Dec 30 15:10:50 CET 2009

Martin Jansa wrote:
> On Wed, Dec 30, 2009 at 12:20:34PM +0100, Michael Trimarchi wrote:
>> Martin Jansa wrote:
>>> On Wed, Dec 30, 2009 at 02:33:39AM -0800, Waqar Ali wrote:
>>>> I am trying to compile the kernel image for my Openmoko GTA02. While compiling when I try to access the git repository (as a matter of fact when Openembedded try to fetch from the git repository) this error is shown and the openembedded build process exits.
>>>> git fetch git:// stable failed with signal 128, output:
>>>> fatal: Not a git repository
>>>> Does anybody know how to solve this issue, and if this repository still exists and works.
>>>> Regards,
>>>> Waqar Ali
>>>> Research Engineer
>>>> NexGIN Research Center
>>> Exists and works, but stable branch is quite old (based on 2.6.24
>>> an last commit was 10 months ago), which bitbake recipe are you
>>> trying to build?
>>> SHR is using 2.6.29-rc3 (andy-tracking branch)
>>> recipes/linux/
>>> and there is also newer variants available for shr
>>> recipes/linux/ andy-tracking + Thomas White's DRM
>>> patches
>> HOw can I say to shr to use the Thomas White DRM?
> If you're building your own image then set preferred provider in
> conf/maching/om-gta02.conf:
> # If you want to have KMS enabled in default kernel, uncomment
> # linux-openmoko-shr-drm-devel
> #PREFERRED_PROVIDER_virtual/kernel_shr = "linux-openmoko-shr-devel"
> #PREFERRED_PROVIDER_virtual/kernel_shr = "linux-openmoko-shr-drm-devel"
> #PREFERRED_PROVIDER_virtual/kernel_shr = "linux-openmoko-2.6.31"
> PREFERRED_PROVIDER_virtual/kernel_shr = "linux-openmoko-2.6.32"
> If you don't want to build own image/kernel then just wget uImage and
> modules from
> or
> update uImage link and unpack modules to /
> (2.6.32 isn't built on shr buildhost yet..)
> And 2.6.31+ isn't fully compatible with frameworkd, few issues can be
> fixed by switching script here:
> All those kernels are suffering from WSOD during suspend.. at least for
> me and other SHR devs, thats why they cannot be used by default and even
> testing is a bit pain without non-stop power supply and suspend
> disabled.
I don't find this commit in the new glamo driver.
Can be releated to the problem?

  Fixed the LCM driver state transition delay and pixel clock issue
        Space transition between sleep-in and sleep-out of at least
        120 ms as mentionned in the spec. Also, made sure the LCM
        is moved into sleep state before the pixel clock is turned off.
        To do so, I've modified glamo-fb to send FB_BLANK_POWERDOWN before
        turning off the pixel clock. Also fixed various violation of coding
        style. This patch should reduce the risk of white screen.
        Signed-off-by: Nicolas Dufresne <nicolas.dufresne at>

> Cheers,

More information about the openmoko-kernel mailing list