Kernel 3.15.10 bone 8 + 4D LCD7 cape failed on BBB

Hi all,

First thanks to Robert and other contributors for having put dts files for the capes in the kernel tree.

I've been away from BBB those last weeks because of work, and back on it after having played a bit with Qt5, opengl, pruss and ldc4 cape...
I found out my fingers are way too big for the 4.3 screen, in fact I have too many buttons and text for my application.

So I bought a 4D LCD7 cape, pulled the new kernel 3.15 and built it.

I disabled HDMI, added the include for the cape, tried to boot and nothing on screen.
Backlight is on, screen initialize but on the console I have:
tilcdc 4830e000.fb: timeout waiting for framedone.

LCD4 from circuitco is fine with kernel built the same way, and LCD7 is working fine under 3.8.13 base image on emmc.

I did not had time to investigate any further because it was almost time to get the kids at school, but I'll check more in depth tomorrow.

But if anyone went across this kind of trouble and fixed it, would be glad to hear what has been done.

Regards,

Cedric

Which version of the lcd7 is it?

on v3.8.x

dmesg | grep cape

will tell us everything. (revision etc..)

Regards,

Hi Robert,

I checked this morning and it’s A3
[ 0.595611] bone-capemgr bone_capemgr.9: slot #0: ‘4D 7.0 LCD CAPE- 4DCAPE-70T ,00A3,4D SYSTEMS ,BB-BONE-LCD7-01’

[ 0.689675] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMI
[ 0.689690] bone-capemgr bone_capemgr.9: Skipping loading of disabled cape with part# BB-BONELT-HDMIN
[ 0.689887] bone-capemgr bone_capemgr.9: loader: before slot-0 BB-BONE-LCD7-01:00A3 (prio 0)
[ 0.689902] bone-capemgr bone_capemgr.9: loader: check slot-0 BB-BONE-LCD7-01:00A3 (prio 0)
[ 0.689942] bone-capemgr bone_capemgr.9: initialized OK.
[ 0.692709] bone-capemgr bone_capemgr.9: loader: after slot-0 BB-BONE-LCD7-01:00A3 (prio 0)
[ 0.692732] bone-capemgr bone_capemgr.9: slot #0: Requesting part number/version based 'BB-BONE-LCD7-01-00A3.dtbo
[ 0.692749] bone-capemgr bone_capemgr.9: slot #0: Requesting firmware ‘BB-BONE-LCD7-01-00A3.dtbo’ for board-name '4D 7.0 LCD CAPE- 4DCAPE-70T ', version ‘00A3’
[ 0.692769] bone-capemgr bone_capemgr.9: slot #0: dtbo ‘BB-BONE-LCD7-01-00A3.dtbo’ loaded; converting to live tree

Also got

[ 12.306552] tilcdc 4830e000.fb: timeout waiting for framedone
[ 24.290871] tilcdc 4830e000.fb: timeout waiting for framedone

but everything is working fine.

Ah, the 4dcape-70t, (i grabbed the wrong lcd this morning..)

So this one was a little fun to get working, i don't remember if i
pushed all the fixes to v3.15.x

sudo apt-get update
sudo apt-get install linux-image-3.14.17-ti-r19

sudo cp -v /boot/dtbs/3.14.17-ti-r19/am335x-boneblack.dtb
/boot/dtbs/3.14.17-ti-r19/am335x-boneblack.bak
sudo cp -v /boot/dtbs/3.14.17-ti-r19/am335x-boneblack-4dcape-70t.dtb
/boot/dtbs/3.14.17-ti-r19/am335x-boneblack.dtb

sudo reboot

Regards,

I will try, but I’m checking diffs between 3.8.13 dts and 3.15.10, because using dtb from 3.14 is not really a solution for me as I also need pruss.
Well I think :slight_smile:

Thanks

https://github.com/beagleboard/linux/commit/94f48ff05623afbfcf75ca211b4c4df23a66f82e

starting with r18, we got pruss from ti..

Regards,

I will try, but I’m checking diffs between 3.8.13 dts and 3.15.10, because
using dtb from 3.14 is not really a solution for me as I also need pruss.
Well I think :slight_smile:

https://github.com/beagleboard/linux/commit/94f48ff05623afbfcf75ca211b4c4df23a66f82e

starting with r18, we got pruss from ti…

Regards,


Robert Nelson
http://www.rcn-ee.com/

Ok, so LCD7 is working now.

What I did:

in pinmux file:
bbcape_lcd7_pins: bbcape_lcd7_pins {
pinctrl-single,pins = <
0x150 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* spi0_sclk.gpio0_2, OUTPUT | MODE7 - AVDD_EN /
0xa0 (PIN_OUTPUT | MUX_MODE0) /
lcd_data0.lcd_data0 /
0xa3 (PIN_OUTPUT | MUX_MODE0) /
lcd_data1.lcd_data1 /
0xa8 (PIN_OUTPUT | MUX_MODE0) /
lcd_data2.lcd_data2 /
0xac (PIN_OUTPUT | MUX_MODE0) /
lcd_data3.lcd_data3 /
0xb0 (PIN_OUTPUT | MUX_MODE0) /
lcd_data4.lcd_data4 /
0xb4 (PIN_OUTPUT | MUX_MODE0) /
lcd_data5.lcd_data5 /
0xb8 (PIN_OUTPUT | MUX_MODE0) /
lcd_data6.lcd_data6 /
0xbc (PIN_OUTPUT | MUX_MODE0) /
lcd_data7.lcd_data7 /
0xc0 (PIN_OUTPUT | MUX_MODE0) /
lcd_data8.lcd_data8 /
0xc4 (PIN_OUTPUT | MUX_MODE0) /
lcd_data9.lcd_data9 /
0xc8 (PIN_OUTPUT | MUX_MODE0) /
lcd_data10.lcd_data10 /
0xcc (PIN_OUTPUT | MUX_MODE0) /
lcd_data11.lcd_data11 /
0xd0 (PIN_OUTPUT | MUX_MODE0) /
lcd_data12.lcd_data12 /
0xd4 (PIN_OUTPUT | MUX_MODE0) /
lcd_data13.lcd_data13 /
0xd8 (PIN_OUTPUT | MUX_MODE0) /
lcd_data14.lcd_data14 /
0xdc (PIN_OUTPUT | MUX_MODE0) /
lcd_data15.lcd_data15 /
0xe0 (PIN_OUTPUT | MUX_MODE0) /
lcd_vsync.lcd_vsync /
0xe4 (PIN_OUTPUT | MUX_MODE0) /
lcd_hsync.lcd_hsync /
0xe8 (PIN_OUTPUT | MUX_MODE0) /
lcd_pclk.lcd_pclk /
0xec (PIN_OUTPUT | MUX_MODE0) /
lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */

;
};

in bone-panel-800x480

panel {
status = “okay”;
compatible = “ti,tilcdc,panel”;
pinctrl-names = “default”;
pinctrl-0 = <&bbcape_lcd7_pins>;
panel-info {
ac-bias = <255>;
ac-bias-intrpt = <0>;
dma-burst-sz = <16>;
bpp = <16>;
fdd = <0x80>;
sync-edge = <0>;
sync-ctrl = <1>;
raster-order = <0>;
fifo-th = <0>;
tft-alt-mode = <0>;
stn-565-mode = <0>;
};
display-timings {
native-mode = <&timing0>;
/* Settings for ThreeFive S9700RTWV35TR / LCD7 cape: */
timing0: 800x480 {
clock-frequency = <30000000>;
hactive = <800>;
vactive = <480>;
hfront-porch = <40>;
hback-porch = <40>;
hsync-len = <48>;
vback-porch = <29>;
vfront-porch = <13>;
vsync-len = <3>;
hsync-active = <0>;
vsync-active = <0>;
};
};
};

Looks like the lcd.data1 which is used on 7" screens is not the same as on 4" ones.

As for Pruss, in 3.15 bone 6 I patched uio_pruss.c driver, and enabled it in dts / Kernel config.

Will check for your remoteproc driver.

Thanks

> I will try, but I'm checking diffs between 3.8.13 dts and 3.15.10,
> because
> using dtb from 3.14 is not really a solution for me as I also need
> pruss.
> Well I think :slight_smile:

https://github.com/beagleboard/linux/commit/94f48ff05623afbfcf75ca211b4c4df23a66f82e

starting with r18, we got pruss from ti..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/

Ok, so LCD7 is working now.

What I did:

in pinmux file:
bbcape_lcd7_pins: bbcape_lcd7_pins {
pinctrl-single,pins = <
0x150 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* spi0_sclk.gpio0_2, OUTPUT | MODE7 -
AVDD_EN */

I think this was the fix ^..

I can do something simlar to:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-common-pinmux.dtsi#L66

which i did to make the lcd4 work..

0xa0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 */
0xa3 (PIN_OUTPUT | MUX_MODE0) /* lcd_data1.lcd_data1 */

I saw this too... 0xa3 is not a valid pin...

0xa8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data2.lcd_data2 */
0xac (PIN_OUTPUT | MUX_MODE0) /* lcd_data3.lcd_data3 */
0xb0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data4.lcd_data4 */
0xb4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data5.lcd_data5 */
0xb8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data6.lcd_data6 */
0xbc (PIN_OUTPUT | MUX_MODE0) /* lcd_data7.lcd_data7 */
0xc0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data8.lcd_data8 */
0xc4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data9.lcd_data9 */
0xc8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data10.lcd_data10 */
0xcc (PIN_OUTPUT | MUX_MODE0) /* lcd_data11.lcd_data11 */
0xd0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data12.lcd_data12 */
0xd4 (PIN_OUTPUT | MUX_MODE0) /* lcd_data13.lcd_data13 */
0xd8 (PIN_OUTPUT | MUX_MODE0) /* lcd_data14.lcd_data14 */
0xdc (PIN_OUTPUT | MUX_MODE0) /* lcd_data15.lcd_data15 */
0xe0 (PIN_OUTPUT | MUX_MODE0) /* lcd_vsync.lcd_vsync */
0xe4 (PIN_OUTPUT | MUX_MODE0) /* lcd_hsync.lcd_hsync */
0xe8 (PIN_OUTPUT | MUX_MODE0) /* lcd_pclk.lcd_pclk */
0xec (PIN_OUTPUT | MUX_MODE0) /* lcd_ac_bias_en.lcd_ac_bias_en (lcd_en) */

;

};

in bone-panel-800x480

panel {
status = "okay";
compatible = "ti,tilcdc,panel";
pinctrl-names = "default";
pinctrl-0 = <&bbcape_lcd7_pins>;
panel-info {
ac-bias = <255>;
ac-bias-intrpt = <0>;
dma-burst-sz = <16>;
bpp = <16>;
fdd = <0x80>;
sync-edge = <0>;
sync-ctrl = <1>;
raster-order = <0>;
fifo-th = <0>;
tft-alt-mode = <0>;
stn-565-mode = <0>;

These last two are not in the driver...

Regards,

I will try, but I’m checking diffs between 3.8.13 dts and 3.15.10,
because
using dtb from 3.14 is not really a solution for me as I also need
pruss.
Well I think :slight_smile:

https://github.com/beagleboard/linux/commit/94f48ff05623afbfcf75ca211b4c4df23a66f82e

starting with r18, we got pruss from ti…

Regards,


Robert Nelson
http://www.rcn-ee.com/

Ok, so LCD7 is working now.

What I did:

in pinmux file:
bbcape_lcd7_pins: bbcape_lcd7_pins {
pinctrl-single,pins = <
0x150 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* spi0_sclk.gpio0_2, OUTPUT | MODE7 -
AVDD_EN */

I think this was the fix ^…

Yes this is the fix :slight_smile:

I can do something simlar to:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-common-pinmux.dtsi#L66

which i did to make the lcd4 work…

0xa0 (PIN_OUTPUT | MUX_MODE0) /* lcd_data0.lcd_data0 /
0xa3 (PIN_OUTPUT | MUX_MODE0) /
lcd_data1.lcd_data1 */

I saw this too… 0xa3 is not a valid pin…

Put it back to 0xa4

tft-alt-mode = <0>;
stn-565-mode = <0>;

These last two are not in the driver…

Nope but were in 3.8.13…

Another trouble is with keymap now.

If I enable keymap for the user buttons ( even if I do not need them for now ) , the touchscreen is clicking by itself when I do a ts_calibrate.

Going to investigate :slight_smile:

Cedric

> in pinmux file:
> bbcape_lcd7_pins: bbcape_lcd7_pins {
> pinctrl-single,pins = <
> 0x150 (PIN_OUTPUT_PULLUP | MUX_MODE7) /* spi0_sclk.gpio0_2, OUTPUT |
> MODE7 -
> AVDD_EN */

I think this was the fix ^..

Yes this is the fix :slight_smile:

Cool! i'll enable that by default...

Another trouble is with keymap now.

If I enable keymap for the user buttons ( even if I do not need them for now
) , the touchscreen is clicking by itself when I do a ts_calibrate.

Going to investigate :slight_smile:

Make sure they are -1 compared with v3.8.13

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-keymap0.dtsi

Regards,

About Touchscreen …
forget all I said :slight_smile:

My very own fault, I had leftover TS things in /etc/profile pointing to /dev/input/event1 instead of /dev/input/event2

So back to my sandbox for a bit more games :slight_smile: