Microwindows, M5329x Framebuffer, and LTIB

[Mr_Bob]

Hi,

I'm working with a board derived from the Freescale/LogicPD mcf5329
evaluation board, and using the microwindows-0.90 package which is
included in ltib-cf_nommu-20081215 from Freescale's web site.  The
framebuffer (kernel is linux-2.6.26) is set up for a 320 wide by 240
high LCD.  The penguin shows fine on power-up.

But, when I try to run some of the demo apps, I get mixed results at
best.  As a good example of exactly where I'm at, if I
run /usr/nanox/launcher.sh, I get what appears to be a 3 x 3 matrix of
icons, presumably for launching other demo apps; the icons included are
(top row) Tetrix, Slider, Terminal; (middle row) Clock, Magnifier,
Scribble, (bottom row) Roach, Tux, and NXEyes.  This matrix has its
lower left corner aligned with the lower left corner of the screen, and
does not occupy the entire screen; the remainder (about the top 25% and
the rightmost 10%) seems to be some patterned background.  All this
appears good - I say "appears" as I'm not really sure what to expect.
However, there is a big problem - the bottom ~20% of the screen has a
flicker that exhibits itself as random row-wide artifacts.  What I mean
is that it seems some rows really are not being drawn - for example, row
200 might be drawn, row 201 gets skipped, and row 202 gets drawn where
201 should be.  I say this because it appears that the labels of the
bottom three icons (i.e. Roach, Tux, and NXEyes jump up and down a row
or two.  The rest of the display is rock-solid.

After playing with this a while, I've discovered something.  After about
15 seconds, the launcher.sh demo goes into a random screensaver mode.
Some screensavers look really good, such as a "searchlight" that
illuminates a small circle that is moved over the display, the rest of
which is black - simulating a flashlight searching in a darkened room.
For this screensaver, every thing is sharp, and there is no flicker
whatsoever.  Other screensavers, such as one that looks like lighting
flashes, exhibits the flicker over large portions of the display - not
just the bottom portion.

Other screensavers show either extreme, or behavior in between them.
What seems to be going on is that the more dynamic the graphics, the
more the flicker is exhibited. Put another way, the more static the
display, the less flicker is noticed.  I would expect that a totally
static display might well show no flicker whatsoever.  (Note: I don't
know if the launcher.sh main screen is indeed fully static - it would
appear to be, but perhaps something at the very bottom isn't).

This would seem to be timing related or something, but I haven't been
able to find anything amiss in the stock code.  I did come across
something regarding priority of the LCD controller on the internal
crossbar switch, but it appears that it has already been elevated to the
highest priority by the kernel.

I'm completely stumped by this - anyone have any ideas on what might be
amiss, or what to investigate?

Thanks,
-Bob

[Mr_Bob]

Wow, thanks for all the help! 

Seriously, it seems Microwindows is NOT the problem.  I wrote a very simple program that writes directly to the framebuffer, and I still see flickering/tearing/shearing of the display.

Attached is a silly test program, which in pseudo-code goes like this:

test:
  open framebuffer
  write all zeros to it (i.e. erase the screen)
  sleep(10) to allow inspection
  lseek to beginning
  write all ones to it (i.e. set all pixels white)
  sleep(10)
  lseek to beginning
  write a pattern of 8x8 multi-colored boxes to screen
  sleep(10)
  close framebuffer

Running this shows a nice blank screen for 10 seconds, then a white
screen for 10 seconds, then finally some pretty boxes.  Or at least,
that is what is supposed to happen.

What actually happens, sometimes, is that, sometimes it works, other
times the white screen shows the flicker/tearing/shearing throughout the
entire lower two-thirds of the screen.  Of course, the black looks fine,
but surprisingly, the colored blocks also looks fine.  Well, almost -
when the white shows the shearing, there is usually a small black
rectangle, maybe 3-4 pixels wide by 6-8 high, at the far left of the
screen, centered vertically about the first sheared line; this block is
also present on the white screen, along with an 6-8-pixel long vertical
black line at the same elevation, midway across the screen.  I don't
know if that little line shows up with the colored boxes.

I don't thing there is anything wrong with my code - it's so simple -
but perhaps I'm missing something?  Any ideas?

Presuming my code is okay, where is the framebuffer running into trouble? 

I'm really at a loss here, and while my client is very patient, he's likely to pull the plug soon...

Thanks,
-Bob

[Mr_Bob]

Oops, here's the code itself...

[obidon]

Hi Mr. Bob, I just noticed this posting. What did you come up with? I am involved in project that is based on the MCF5328 and using an Optrex 640 x 480 display.  For our purpose I found that the framebuffer at 18 bpp took too much bus bandwidth. I wrote an alternate display driver instead of using the framebuffer/microwindows and we run mostly in 8 bpp which allows not having LCDC at the highest priority.