LVDS Output Scrambled

I’m running the latest BSP for the Apalis (Apalis_iMX6_LinuxImageV2.6) with an Ixora v1.1 board, and I’m unable to get stable output on an attached LVDS screen. It is clear from the output that the data to be displayed is present, as I can discern a scrambled Toradex logo and default LXDE desktop. However, I suspect something is misconfigured in the display settings and would appreciate any input anyone may have.

I’m selecting the LVDS device as preferred output with u-boot vidargs set to:

video=mxcfb0:dev=ldb video=mxcfb1:off video=mxcfb2:off video=mxcfb3:off fbmem=32M

My device tree settings are (cut out the irrelevant resolutions):

fb@0 { 
               compatible = "fsl,mxc_sdc_fb"; 		
               disp_dev = "ldb";
    	       interface_pix_fmt = "RGB666";
    	       default_bpp = <0x10>; 		
               int_clk = <0x0>; 		
               late_init = <0x0>; 		
               status = "okay";  
};

ldb@020e0008 {
				#address-cells = <0x1>;
				#size-cells = <0x0>;
				gpr = <0x17>;
				status = "okay";
				compatible = "fsl,imx6q-ldb", "fsl,imx53-ldb";
				clocks = <0x2 0x87 0x2 0x88 0x2 0x27 0x2 0x28 0x2 0x29 0x2 0x2a 0x2 0xb8 0x2 0xb9 0x2 0xd1 0x2 0xd2 0x2 0xd3 0x2 0xd4>;
				clock-names = "ldb_di0", "ldb_di1", "di0_sel", "di1_sel", "di2_sel", "di3_sel", "ldb_di0_div_3_5", "ldb_di1_div_3_5", "ldb_di0_div_7", "ldb_di1_div_7", "ldb_di0_div_sel", "ldb_di1_div_sel";

				lvds-channel@0 {
					reg = <0x0>;
					status = "okay";
					fsl,data-mapping = "spwg";
					fsl,data-width = <0x12>;
					crtc = "ipu2-di1";
					primary;

					display-timings {
...
                     1024x768 {
							clock-frequency = <0x3938700>; /* 60MHz */
							hactive = <0x400>;
							vactive = <0x300>;
							hback-porch = <0xa0>;
							hfront-porch = <0x18>;
							vback-porch = <0x1d>;
							vfront-porch = <0x3>;
							hsync-len = <0x88>;
							vsync-len = <0x6>;
							hsync-active = <0x0>;
							vsync-active = <0x0>;
							pixelclk-active = <0x0>;
							linux,phandle = <0x28>;
							phandle = <0x28>;
						};
...

The relevant output from boot is as follows:

[    0.179291] mxc_sdc_fb fb.20: registered mxc display driver ldb
[    0.187550] mxc_sdc_fb fb.20: 1024x768 h_sync,r,l: 136,24,160  v_sync,l,u: 6,3,29 pixclock=60002000 Hz
[    0.203342] imx-ipuv3 2800000.ipu: IPU DMFC DP HIGH RESOLUTION: 1(0,1), 5B(2~5), 5F(6,7)
[    0.240051] mxc_sdc_fb fb.20: 1024x768 h_sync,r,l: 136,24,160  v_sync,l,u: 6,3,29 pixclock=60002000 Hz
[    0.261176] Console: switching to colour frame buffer device 128x48
[    0.300479] mxc_sdc_fb fb.21: mxcfb1 is turned off!
[    0.300633] mxc_sdc_fb fb.22: mxcfb2 is turned off!
[    0.300776] mxc_sdc_fb fb.23: mxcfb3 is turned off!

and later:

[ 9.959093] mxc_sdc_fb fb.20: 1024x768 h_sync,r,l: 136,24,160 v_sync,l,u: 6,3,29 pixclock=60002000 Hz
[ 10.011625] mxc_sdc_fb fb.20: 1024x768 h_sync,r,l: 136,24,160 v_sync,l,u: 6,3,29 pixclock=60002000 Hz
[ 10.060104] mxc_sdc_fb fb.20: 1024x768 h_sync,r,l: 136,24,160 v_sync,l,u: 6,3,29 pixclock=60002000 Hz
[ 10.110463] mxc_sdc_fb fb.20: 1024x768 h_sync,r,l: 136,24,160 v_sync,l,u: 6,3,29 pixclock=60002000 Hz
[ 10.699944] mxc_sdc_fb fb.20: 1024x768 h_sync,r,l: 136,24,160 v_sync,l,u: 6,3,29 pixclock=60002000 Hz

For completeness, the screen I’m attempting to attach is the Kyocera TCG101WXLPAANN-AN20:

link text

I’ve also attached a sample of the output I’m seeing - this flickers rapidly.

Any and all suggestions welcome, I’m out of ideas on this one.

Hi

  1. The first thing I would check is the wiring.
    Are the differential pairs twisted? Is their lenght about the same?
    Are the differential pairs connected correctly, e.g. the clock differential pair to the clock differential pair, data 0 pair to data 0 pair, within a pair + to +, - to -?

  2. What exact kernel version are you using?
    e.g. the output of git log --oneline --decorate up to the first one which has not been commited by you.

  3. What changes did you do to the device tree
    Your excerpts from a probably disassembled device tree are to hard to analyze. A diff against what you took as a base would be so much easier.
    e.g. if you did not (yet) check in anything git diff arch/arm/boot/dts

  4. How did you connect the BITSEL, SELLVDS signals

Max

Max,

Thanks for the suggestions and apologies for the slow response, I’ve been away.

  1. Differential pairs are twisted and the lengths look good. Tracing them back and comparing to the pinouts for the display and the Ixora connector, all seems to be in order.

  2. I haven’t compiled my own kernel, I am using the one that is used to generate the uImage provided in the ‘Apalis_iMX6_LinuxImageV2.6_20160826.tar.bz2’ at the Linux BSP download page. Looking at the release notes this is “Linux 3.14.52 kernel, based on Freescale’s BSP release imx_3.14.52_1.1.0_ga”, but I’m unsure how to link that back to a specific commit…

  3. I abandoned the ‘decompile dtb, edit dts, and recompile’ approach and instead checked out the ‘linux-toradex’ repo. I’m on branch ‘toradex_imx_3.14.52_1.1.0_ga’ and the last commit was 9f2723e1. I’ve made some edits and recompiled the dtb with ‘make imx6q-apalis-ixora.dtb’. The diff is:

    diff --git a/arch/arm/boot/dts/imx6qdl-apalis-ixora.dtsi b/arch/arm/boot/dts/imx6qdl-apalis-ixora.dtsi
    index b54e6ae…a6d59a8 100644
    — a/arch/arm/boot/dts/imx6qdl-apalis-ixora.dtsi
    +++ b/arch/arm/boot/dts/imx6qdl-apalis-ixora.dtsi
    @@ -206,7 +206,7 @@
    /* Video ADC on Analog Camera Module */
    adv7180: adv7180@21 {
    compatible = “adv,adv7180”;

    •   reg = <0x21>;
      
    •   reg = <0x20>;
        pinctrl-names = "default";
        pinctrl-0 = <&pinctrl_ipu1_csi0 &pinctrl_cam_mclk>;
        clocks = <&clks 200>;
      

    @@ -236,7 +236,7 @@
    mclk = <24000000>;
    mclk_source = <1>;
    cvbs = <1>;

    •   status = "okay";
      
    •   status = "disabled";
      
      };
      };

    diff --git a/arch/arm/boot/dts/imx6qdl-apalis.dtsi b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
    index 7cd124f…5341467a 100644
    — a/arch/arm/boot/dts/imx6qdl-apalis.dtsi
    +++ b/arch/arm/boot/dts/imx6qdl-apalis.dtsi
    @@ -85,10 +85,10 @@
    compatible = “fsl,mxc_sdc_fb”;
    disp_dev = “ldb”;
    interface_pix_fmt = “RGB666”;

    •   default_bpp = <16>;
      
    •   default_bpp = <32>;
        int_clk = <0>;
        late_init = <0>;
      
    •   status = "disabled";
      
    •   status = "okay";
      

    #endif
    };

    @@ -1015,7 +1015,7 @@
    status = “okay”;

     	display-timings {
    
    •   	native-mode = <&timing_xga>;
      
    •   	native-mode = <&timing_wxga>;
        	/* LDB-AM-800600LTNQW-A0H */
        	timing_svga: 800x600 {
        		clock-frequency = <55000000>;
      

    @@ -1060,7 +1060,7 @@
    vsync-active = <0>;
    pixelclk-active = <0>;
    };

    •   	timing_fullhd: 1920x1080 {
      
    •   	/* timing_fullhd: 1920x1080 {
        		clock-frequency = <138500000>;
        		hactive = <1920>;
        		vactive = <1080>;
      

    @@ -1073,7 +1073,7 @@
    hsync-active = <0>;
    vsync-active = <0>;
    pixelclk-active = <0>;

    •   	};
      
    •   	};*/
        };
      
      };

    diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
    index 604e54d…dcea249 100644
    — a/arch/arm/boot/dts/imx6qdl.dtsi
    +++ b/arch/arm/boot/dts/imx6qdl.dtsi
    @@ -804,16 +804,16 @@
    #address-cells = <1>;
    #size-cells = <0>;
    gpr = <&gpr>;

    •   		status = "disabled";
      
    •   		status = "okay";
      
        		lvds-channel@0 {
        			reg = <0>;
      
    •   			status = "disabled";
      
    •   			status = "okay";
        		};
      
        		lvds-channel@1 {
        			reg = <1>;
      
    •   			status = "disabled";
      
    •   			status = "okay";
        		};
        	};
      

Some notes:

  • I have some changes to do with the v4l2 drivers I need for the system (the adv and max changes codec)
  • I commented out a resolution that was beyond the screen’s range as I was seeing the system attempting to configure for this resolution (and I was getting even less out of the screen as a result)
  1. Through examining the resistor placement on the Ixora board and consulting the Ixora datasheet, it looks like BITSEL and SELLVDS are both configured for 3.3V (R97 and R100 are present). This last point worries me a bit as the datasheet for the screen doesn’t seem to indicate that both BITSEL and SELLVDS being set ‘high’ is expected.

Thanks for the help and patience - this is my first time working through an LVDS set-up. If there’s any more information I can provide please let me know.

@DiveDev

Hi

Note that if properties get redefined at a later place in the sources the device tree compiler will take the last definition it sees.
So your changes to imx6qdl.dtsi are irrelevant as the &ldb node in imx6qdl-apalis.dtsi rewrites the status property again to “okay”. The same holds true to the status property in the fb@0 node which is rewritten in arch/arm/boot/dts/imx6qdl-apalis.dtsi.

at 2)
You would find out e.g. with uname -a. For the V2.6 20160826 image it is 7c83cef

at 3)
Ok.
If you want to use the imx6q-apalis-ixora.dtb you would need to change the fdt_file U-Boot environment variable.

Apalis iMX6 # setenv fdt_file imx6q-apalis-ixora.dtb                            
Apalis iMX6 # saveenv

Interesting would be the full bootlog from U-Boot up to the login message with your self compiled device tree.

at 4)
As we don’t know what will later be connected we provide 3.3V on pin 31/32. Since the display you use defaults to 0V when an input is not connected you could simple not connect a pin you would want at 0V.

So you could try to not connect BITSEL and test with your current device tree settings. That would operate the display in 6bit/color mode.
If that works you could set fsl,data-mapping to “jeida” and fsl,data-width to <24> to see if the 8bit/color mode works as well.

Max

Apologies for the delayed follow-up to this question, we’ve had a few deadlines in recent weeks.

The solution was to disconnect the BITSEL wire and, in doing so, set it to low. The display does not support a mode where both SELVDS and BITSEL are high. As soon as BITSEL was low the picture came through clearly on the display and behavior was as desired.

@max.tx - thank you very much for your help!