Ticket #1086 (closed defect: fixed)

Opened 11 years ago

Last modified 11 years ago

White pixel "noise" corrupts display dynamically after some boots

Reported by: andy@… Owned by: willie_chen@…
Priority: high Milestone:
Component: Screen Version: GTA02v2
Severity: major Keywords:
Cc: buglog@…, olv@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: PatchReviewResult:


Willie explained that occasionally during boot when the display is
initialized, it suffers from white "noise" pixels that obscures the actual
display data and moves around randomly per frame.

This symptom sounds like memory bus bandwidth being used up and the video data
is not able to keep the display pixel pipeline full all the time. If he
manages to get a boot that exhibits this behaviour, it seems to persist for
the whole boot.

He reports seeing it something like once a day, but of course he reboots a

If it is due to starvation of the video pipeline then it's interesting that it
only happens sometimes. Maybe init of SDRAM timings or video chip timings is
not 100% reliable.


glamo-confirm-pll-locked-or-retry.patch (3.4 KB) - added by andy@… 11 years ago.
Workaround for failed video init

Change History

comment:1 Changed 11 years ago by andy@…

  • Owner changed from sean_chiang@… to willie_chen@…

Reassigned to willie, it's not a physical screen issue

comment:2 Changed 11 years ago by andy@…

Willie found #1017 which sounds very similar in terms of unreliable IO between
the CPU and the display controller... going to try their U-Boot patch.

comment:3 Changed 11 years ago by andy@…

Before we got to try the patch I experienced the problem here. I noticed that
when it is corrupting pixels, there is a "hum bar" kind of effect vertically
which somehow alters the colours of pixels in vertical ranks slowly, over a
couple of seconds in a vertical sweep. The pixels are rewritten behind
this "wave front" so the display is still pretty legible.

I also noticed some kind of interlace or interleave is visible making the
pixels "twinkle" where they differ between the two lines.

I wondered immediately if the problem was a slow pixel clock, and the "hum
bar" in that case was the capacitive decay of the TFT gate level over time.
Sure enough when Willie got a 'scope, we measured PCLK in the bad mode and
afterwards in the good mode: ~1.7MHz vs ~24.5MHz or ~15 times slower when it
is bad. So it seems likely this is to do with PLL settings or issue with wait
for lock.

comment:4 Changed 11 years ago by andy@…

Roh asked to check 32kHz clock next time problem was seen -- is still a clean 32kHz.

In addition I have seen it start the kernel boot display clean, and then enter
this "slow" mode partway through the kernel boot, while it is showing jffs2

Changed 11 years ago by andy@…

Workaround for failed video init

comment:5 Changed 11 years ago by laforge@…

as indicated by olv, this might have been solved by the patch to u-boot from
#1017. Can somebody please verify that the patch attached to this bug is still
required with that fix?

comment:6 Changed 11 years ago by olv@…

  • Cc olv@… added

comment:7 Changed 11 years ago by andy

  • Status changed from new to closed
  • Resolution set to fixed

Nobody has reported this for 6 months since cranking up the waitstates to access the Glamo.

Note: See TracTickets for help on using tickets.