This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Linux/AM3354: U-boot splash screen causes kernel display problem

Part Number: AM3354

Tool/software: Linux

Hi:

I'm using u-boot 2011 + kernel 4.4.32 (extracted from am3354 processor sdk 03.02.00.05).

right now i wanted to implement the splash screen feature for u-boot.

i referred to

as previous post in the forum.

Firstly the u-boot lcd driver worked fine after i followed the steps in the post.

My kernel dts setting for LCD was:

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

  display-timings {
   320x240p62 {
    clock-frequency = <21000000>;
    hactive = <320>;
    vactive = <240>;
    hfront-porch = <18>;
    hback-porch = <56>;
    hsync-len = <10>;
    vback-porch = <17>;
    vfront-porch = <10>;
    vsync-len = <1>;
    hsync-active = <0>;
    vsync-active = <0>;
    pixelclk-active = <1>;
   };
  };
 };

  it worked well when the lcd driver is not implemented in the u-boot.

  then i changed the code in lcd driver for u-boot for it to be exactly like what's in the kernel.Like this:

    /* Configure the pclk */
    RasterClkConfig(SOC_LCDC_0_REGS, 21000000, 192000000);//(SOC_LCDC_0_REGS, 21000000, 192000000)     //changed pclk to 21MHz.

    ....

    /* Configuring horizontal timing parameter */
    RasterHparamConfig(SOC_LCDC_0_REGS, 320, 10, 18, 56);   //changed the horizonal pixel number. hfp,hbp and hsw.
    /* Configuring vertical timing parameters */
    RasterVparamConfig(SOC_LCDC_0_REGS, 240, 1, 10, 17);    //changed the vertical pixel number. vfp,vbp and vsw.

As you can see.till now it's exact the same parameter for LCD as in the kernel dts.

So.I built the u-boot.reboot.

it looks fine in the splash screen.Here it is.

Also i'm aware that for 4.4 kernel.It's necessary to use display PLL instead of pheripheral PLL.

So that part of code is also implemented in the u-boot lcd driver.(thanks to one of the post in the forum)

I'm attaching the driver code here.

2728.lcd.zip

Now.Here is the strange part.

After the u-boot is done.And when kernel starts up.I can see that the kernel displays image slightly moved to the left. (  kernel worked well when the lcd driver is not implemented in the u-boot.)

i started a SGX demo application to show you what it would look like.Here:

So.To my experience i started to change hsw or hbp or hfp to see if i can get it right.But turned out that none of the parameter really solved the problem.

Here's what i did.

1.hsync-len = <10>;     ->      hsync-len = <1>;

As you can see in the photo below.There is this strange area of pixel (a vertical column in the red square i marked).The pixels seems to be repeating themselves.

2.hsync-len = <10>;   ->    hsync-len = <30>;

As you can see.I managed to align correct the right column.But the strange pixel area persists.

3.hback-porch = <56>;  ->   hback-porch = <75>

basically the same as the last experiment.I managed to align correct the right column.But the strange pixel area persists.Only this time it's the hbp i chanegd.

4.hfp don't affect the display however i changed it.

So till now.

I can be sure:

a.no matter how i modified hfp/hbp/hsw. Not to mention vfp/vbp/vsw. the phenomenon exists.

b.in the lcd driver of u-boot. the source of clock for the lcd driver doesn't matter. Be it display PLL.Or pheripheral pll. Or even core pll.

c.i even tried to cut out the lcd driver of uboot piece by piece. To remove pieces of code to find out exactly which setting caused the kernel to behave strangely.But there's no success.As soon as the code reaches RasterEnable(SOC_LCDC_0_REGS); Things went wrong.

Please advise what is should do?

to change the lcd driver in uboot?

Or to see if there's a way to reset the lcd registers when kernel starts to initialize lcd controller?

thank you guys

yandong

  • Hi,

    It seems that your frambuffer is out of sync. This doesn't look like a display timing issue.
  • thanks Biser.
    i believe it's not a timing issue as well.
    do you have any advise what should i do next...?
  • could someone please help me?

  • I have notified the software team. They will look into this and respond here.
  • thank you Biser.

  • Hi,

    Check these threads:
    e2e.ti.com/.../494552
    e2e.ti.com/.../1052263
    e2e.ti.com/.../1457962

    Your guess about resetting the lcdc before kernel initialization also seems valied. However the lcdc driver does not have a reset implemented, you will need to modify the driver to achieve this.

    Best Regards,
    Yordan
  • thanks Yordan!

    i will look into the posts you mentioned!

  • Hi Yordan
    I checked the posts you mentioned.
    they are majorly about changing REG_PR_OLD_COUNT bits .
    I did the similar thing when i used to fix the lcdc underflow problem in the past.
    So that part of code which modifies REG_PR_OLD_COUNT bits is already in my u-boot.
    I also removed all the codes i used to handle the lcdc underflow problem . And this image shift still exists. (stable shift. will not recover after sometime unlike the previous posts mentioned)

    here is my code used to handle the lcdc underflow problem.
    "lcdc_underflow=mw 4c000054 00FFFFF10; " \
    "mw 44e1060c 00c00000; " \
    "mw 44e10670 44444477\0" \

    Which indicates that the REG_PR_OLD_COUNT is probably not the reason why my image shift has occurred..

    Running out of ideas here...
  • i found that there is indeed some error log when kernel boots up:



    [drm] Initialized drm 1.1.0 20060810
    [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
    [drm] No driver support for vblank timestamp query.
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000004): Sync lost
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000004): Sync lost
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000004): Sync lost
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000004): Sync lost
    Console: switching to colour frame buffer device 40x30
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000104): Sync lost
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000104): Sync lost
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000104): Sync lost
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000104): Sync lost
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000104): Sync lost
    tilcdc 4830e000.lcdc: tilcdc_crtc_irq(0x00000104): Sync lost
    tilcdc 4830e000.lcdc: fb0: frame buffer device
  • Please, check this thread:
    e2e.ti.com/.../606154
  • Hi Kemal:

    thanks for the tip.

    It seems i need to port the am335x-fb.c from u-boot 2016 to my own u-boot 2011 and apply the splash.tar.gz patch mentioned in the post.

    regards.

  • You can also try the latest Processor SDK 4.0.4. I don't get any Sync lost errors on it without any additional modifications.

  • Thank Kemal.

    I will try 4.0.4 myself!

    i tried to follow the lcd controller reset procedure mentioned in am335x technical reference manual 13.4.6 Disable and Software Reset Sequence

     Set cfg_lcden=’0’.
    • Wait for the Done interrupt.
    • Set the software reset bits high (cfg_main_rst=’1’ or [cfg_dma_rst=’1’ and cfg_core_rst=’1’]) for several
    cycles.
    • Set the resets back low.
    • Set cfg_lcden=’1’.

     


    I added the above code in tilcdc_load() when kernel is initializing the lcdc.But no success.

    I also found out that in tilcdc_crtc.c.There's aleady such reset function in place and running everytime kernel boots up.Like tilcdc_crtc_enable() and tilcdc_crtc_disable()

    So my conclusion is resetting the lcdc module can not bring back the controller to it's original state like when powered on.

    lcd drivers in AM335X_StarterWare_02_00_00_07 somehow polluted the lcd controller in someway.

    I even tried to dump the entire lcdc registers and restore all the registers to it's default state before the kernel initializes the lcdc.Also no success.

    i will check 4.0.4...

    thanks for all the tips!

    yandong

  • i accidentally found a simple solution.

    In the u-boot. I called RasterDisable immediately after RasterEnable.

    i can see the splash logo is shown for 1 second.then the screen turned white. because lcdc is disabled.

    but the important thing is.In this situation.sync lost error is gone.

    Then i thought i should do the same in the kernel instead of u-boot.and it worked.

    in tilcdc_drv.c:

     /* Determine LCD IP Version */
     pm_runtime_get_sync(dev->dev);

     tilcdc_clear(dev, LCDC_RASTER_CTRL_REG, LCDC_RASTER_ENABLE);
     mdelay(3);//100 ok
     switch (tilcdc_read(dev, LCDC_PID_REG)) {
     case 0x4c100102:
      priv->rev = 1;
      break;

     


    i'm supposed to wait for frame done interrupt after the lcdc is disabled.but what the heck.

    i disabled it and wait a while.

    and it worked.

    i don't understand why the reset functions like tilcdc_crtc_disable and tilcdc_crtc_enable called later in the kernel (called by drm_fbdev_cma_init()) doesn't solve the problem though.