I'm experiencing strange problems with pxafb in the 2.6.21 kernel, built
via oe. I never had this problems with the 2.6.21 kernel built
In my 1st home-made PCB, I connected my LCD panel (Sharp LQ057V3DG01 5.7"
640×480, bought from Farnell) to a console-vx to which I had soldered a
45 pin FH12 flex cable connector (I didn't need the backlighting stuff of
On this 1st PCB, I had two FH12 connectors: one 45 pin FH12 that mated
with the flex cable from the console-vx card, and one 33 pin connector for
the flex cable to the LCD panel.
I used a buildroot kernel and root filesystem, and this setup worked
perfectly, but I wanted 18 bits per pixel, and the same time lose the
So, I've just made a 2nd PCB on which a lone verdex XM4 motherboard is
piggybacked, connected to a 60 pin Hirose DF12 connector on my board. On
this PCB, I routed all 18 color bits to the 33-pin FH12.
Now the strange thing: using identical panel parameters as above, I end
up with seemingly random values. One notable strangeness is, that
right after boot, the LCD pixel clock divisor (LCCR3_PCD) is set to
2 (yielding a 17.334MHz pixelclock), but it should've been 1 (yielding a
26.0MHz pixelclock) like on the buildroot build!!!??
Also, if I set e.g. LCCR3_PCD to 1, it will be set back to 2 when I tried
to run one directfb example program. Merely writing a random bit pattern
to /dev/fb0 didn't set it back to 2, though -- but launching df_porter
In the working buildroot version, pxafb was a kernel module, and I had an
entry for it in /etc/modules with the above parameters (but with
640x480-16) being specified there. In the non-working oe version, pxafb
is not a kernel module. Will this somehow affect how pxafb behaves?
I know, "use the source, Luke" but I don't have the time!
And BTW, changing to 16bpp does nothing to remedy the problem.
Anyone got any clues? Please help! I have a deadline!
I solved the LCD panel timing problem after a while. It was a collision
between my overriding pxafb options passed in the kernel command line (set
in u-boot's bootargs env. var) and the defaults that seem to be restored
when the /dev/fb0 device is closed (or, when one of the directfb-examples
When I disabled CONFIG_VT in my kernel's .config file, everything worked
-- no panel-specific (i.e. one of the panel types that exist in the
current version of pxafb.c) defaults were restored when df_porter
I also noticed that it is a pain in the ass to do a simple linux kernel
menuconfig from within openembedded! You have to watch every step you
take, and carefully check the logfiles before you reflash the motherboard.