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

Cedric_Malitte · September 11, 2014, 12:36am

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

RobertCNelson · September 11, 2014, 1:29am

Which version of the lcd7 is it?

on v3.8.x

dmesg | grep cape

will tell us everything. (revision etc..)

Regards,

Cedric_Malitte · September 11, 2014, 1:12pm

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.

RobertCNelson · September 11, 2014, 2:02pm

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,

Cedric_Malitte · September 11, 2014, 2:26pm

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

Thanks

RobertCNelson · September 11, 2014, 2:32pm

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

starting with r18, we got pruss from ti..

Regards,

Cedric_Malitte · September 11, 2014, 4:00pm

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

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

RobertCNelson · September 11, 2014, 4:26pm

> 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

remoteproc/pruss: add a remoteproc driver for PRUSS in TI SoCs · beagleboard/linux@94f48ff · GitHub

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:

github.com

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


      
          
          	/* rtc-01-00a1 */
          	gpio1_29_pins: pinmux_gpio1_29_pins {
          		pinctrl-single,pins = <
          			0x07c 0x3f	/* gpmc_csn0.gpio1_29, INPUT | PULLDIS | MODE 7 */
          		>;
          	};
          
          	/* lcd3-01-00a2 */
          	gpio3_19_led_pins: pinmux_gpio3_19_led_pins {
          		pinctrl-single,pins = <
          			0x1a4 0x07	/* mcasp0_fsr.gpio3_19, OUTPUT | MODE7 */
          		>;
          	};
          
          	bbcape_backlight_pins: bbcape_backlight_pins {
          		pinctrl-single,pins = <
          			0x48  (PIN_OUTPUT | MUX_MODE7)	/* gpmc_a[2].GPIO1[18] (backlight control) */
          		>;
          	};

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,

Cedric_Malitte · September 11, 2014, 6:28pm

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

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

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

Cedric

RobertCNelson · September 11, 2014, 6:55pm

> 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

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

Make sure they are -1 compared with v3.8.13

github.com

RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-keymap0.dtsi

/*
 * Copyright (C) 2012 Texas Instruments Incorporated - http://www.ti.com/
 *
 * This program is free software; you can redistribute it and/or modify
 * it under the terms of the GNU General Public License version 2 as
 * published by the Free Software Foundation.
 */

&ocp {
	P9_15_pinmux {
		/* gpio1[16] */
		status = "disabled";
	};
	P9_16_pinmux {
		/* gpio1[19] */
		status = "disabled";
	};
	P9_21_pinmux {
		/* gpio0[3] */
		status = "disabled";

This file has been truncated. show original

Regards,

Cedric_Malitte · September 11, 2014, 8:29pm

About Touchscreen …
forget all I said

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