PicoComA5 Linux and the ETM043080ADH6 LCD problems

      PicoComA5 Linux and the ETM043080ADH6 LCD problems


      I am trying to substitute the picocom4 with the picocoma5.
      I was using the picocom4 with the ETM043080ADH6 (480x272) LCD which has an external touch controller.

      I have been able to adapt the faraday dcu framebuffer driver to the smaller display and the driver for the touch controller to the picocoma5.

      After configuring the picocoma5 I replaced the picocom4 with it to see how it works. I get a picture and I am able to use the touchscreen. But the LCD has a lot of artifacts.
      Horizontal white lines look white but vertical white lines look fuzzy and colorful.

      Another problem, when attaching the A5 to the 4's SKIT board (which looks like to be exactly the same model as the A5 SKIT) the A5 boots very slowly compared to when it is attached to its own board.
      Also, when attaching the picocomA5 to my own device where I used the picocom4 previously, I get a slow boot but the picture looks normal.

      My own guess is that there is something wrong with the power usage (because the A5 uses more power than the 4). The lower power makes the A5 slower, therefore the slower boot. Maybe that has something to do with how it draws on the screen too.

      The weird thing is that the SKIT baseboards should be the same but I still get a slowdown.
      The SKIT for PicoCOM4 and PicoCOMA5 ist exactly the same. In fact it is already from PicoCOM2, with only a small modification on the VBUS voltage for the USB device port.

      Why the PicoCOMA5 is running slower on your base board, I can not explain. Are you sure that this is not the result of your display driver modification? How did you change the settings for the display? Because if the clock speed is too high, then the DMA transfers to the display could block the system bus so that the CPU core can only get data sporadically. This could slow down the speed of the board and would also explain the imprecise pixel output.

      Your F&S Support Team
      F&S Elektronik Systeme GmbH
      As this is an international forum, please try to post in English.
      Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.
      I edited the framebuffer drivers before building the kernel.

      File: linux-3.0.15-fsvybrid-V2.2/drivers/video/mfv_dcu.c

      Source Code

      1. static struct fb_videomode __devinitdata mvf_dcu_mode_db[] = {
      2. {
      3. .name = "480x272",
      4. .xres = 480,
      5. .yres = 272,
      6. .left_margin = 2,
      7. .right_margin = 2,
      8. .upper_margin = 2,
      9. .lower_margin = 2,
      10. .hsync_len = 41,
      11. .vsync_len = 10,
      12. .sync = FB_SYNC_COMP_HIGH_ACT,
      13. .vmode = FB_VMODE_NONINTERLACED,
      14. },

      File: linux-3.0.15-fsvybrid-V2.2/arch/arm/mach-mfv/mach-picocoma5.c

      Source Code

      1. static struct mvf_dcu_platform_data mvf_dcu_pdata = {
      2. .mode_str = "480x272", /* Use WVGA default display */
      3. //### .mode_str = "320x240", /* Use QVGA default display */
      4. .default_bpp = 16, /* or 24 or 32 */
      5. .enable_power = mvf_lcd_enable_power,
      6. .enable_display = mvf_lcd_enable_display,
      7. };

      There is no configuration for the pixclock but it seems to be calculated from the timings (also in mfv_dcu.c):

      Source Code

      1. /* Target clock rate computed from timing data */
      2. t = var->right_margin + var->hsync_len + var->left_margin + var->xres;
      3. t *= var->lower_margin + var->vsync_len + var->upper_margin + var->yres;
      4. t *= 60; /* ### TODO: Use given framerate resp. var->pixclock */

      Post was edited 3 times, last by “linjar” ().

      These timings look absolutely correct. So the pixelclock should be right, about 9MHz. What I see from the data sheet, this display latches data on the rising edge of the pixel clock, which is rather unusual (and different to other ETM043 display variants). So you should invert the pixel clock polarity. You can do this by adding FB_SYNC_ON_GREEN to the .sync entry above. This is "misused" as pixel clock polarity in the Vybrid display driver. This should fix the jagged graphics, for example in vertical lines. And the display cable should not be longer than about 10cm, the shorter the better.

      Another idea for the slow speed. Can it be that there are some pins that are not connected in your baseboard and where the signals are floating now? If this somehow triggers interrupts, then the board may be slow because it has to service many many interrupts in a rather high frequency.

      Your F&S Support Team
      F&S Elektronik Systeme GmbH
      As this is an international forum, please try to post in English.
      Da dies ein internationales Forum ist, bitten wir darum, Beiträge möglichst in Englisch zu verfassen.
      There doesn't seem to be any problems with the pins on our board. I have been able to connect to the debug serial port to see what happens during boot. The boot seems to hang for a couple of minutes before continuing. I have been trying to find any error message. When comparing the dmesg logs from using both the SKIT board and our board, there is no diff.
      After booting and waiting past the hangup, the OS seems to work normally.
      I have no clue as to what is making the boot hang for a few minutes.

      I have tried to config some features of the picocoma5 kernel to disable unused pins. But that doesn't seem to help and I also encounter errors when building the kernel. The errors I encountered I could debug by googling for the error and manually edit the drivers to fix them.

      Is there any tool or setting I can add to the kernel or rootfs build to be able to debug the boot sequence? Is there some obvious place I have not looked?