BBB Debian Corrupt LCD

We have a built a custom board with an LCD interface to drive a 1024 x 768 pixel LVDS panel, 16BPP. It works great on the Beaglebone White with the old Angstrom 3.2 using the board file configuration.

We want to use the Beaglebone Black so we built up a system from http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2014-07-22 . I added a dts using the same parameters from the old board file but the graphics are blurred and corrupted. The card I made boots on the White also and gives the same results as on the Black. See images below.

I’ve fiddled with the panel timings but they don’t seem to have any effect.

Does anyone have any idea what is wrong and how do I fix it?

Regards,

James

This is part of the (good) image from the frame buffer.

This is a photo of the output on the screen, showing a similar area.

The following is the panel section of the dts file, based on an LCD4 dts:-

/* Settings for AUO G121XN01 / mita cape: */

panel {

compatible = “tilcdc,panel”;

pinctrl-names = “default”;

pinctrl-0 = <&bone_mita_cape_lcd_pins>;

panel-info {

ac-bias = <255>;

ac-bias-intrpt = <0>;

dma-burst-sz = <16>;

bpp = <16>;

fdd = <0x80>;

tft-alt-mode = <0>;

stn-565-mode = <0>;

mono-8bit-mode = <0>;

sync-edge = <0>;

sync-ctrl = <1>;

raster-order = <0>;

fifo-th = <0>;

invert-pxl-clk = <0>;

};

display-timings {

native-mode = <&timing0>;

timing0: 1024x768 {

hactive = <1024>;

vactive = <768>;

hback-porch = <80>;

hfront-porch = <48>;

hsync-len = <32>;

vback-porch = <15>;

vfront-porch = <3>;

vsync-len = <4>;

clock-frequency = <56000000>;

hsync-active = <0>;

vsync-active = <0>;

};

};

};

fb {

compatible = “ti,am33xx-tilcdc”;

reg = <0x4830e000 0x1000>;

interrupt-parent = <&intc>;

interrupts = <36>;

ti,hwmods = “lcdc”;

ti,power-gpio = <&gpio1 2 0x0>;

ti,allow-non-reduced-blanking-modes;

};

If you read the manual, you will see that these lines are also connected to the HDMI chip. To use it also as an LCD panel, you need to buffer these signals and account for any noise that may be introduced as a result of the loading of these 6ma drive signals my the HDMI chip.

Gerald

Hi Gerald, thanks for that reminder.

However, there should be no such loading on the White since it doesn’t have HDMI on board? The problem also occurs on the White. What else could it be?

Regards,
James

Still could be the same issue. What buffer are you using to drive the signals to the LVDS device? Are the trace lengths match to insure that all the setup and hold times are met by having all signals with the same delay?

Gerald

Gerald,

The pins are connected directly to the LVDS chip, a DS90C383BMT. Trace lengths are short and matched.
But on the same board with the older software, it worked fine - what would have changed to require the use of a buffer?

Regards,
James

Sounds like something in the SW has changed. I can’t really answer as to what that would be.

Gerald