• State Resolved
  • Locked Locked
  • Replies 5 replies
  • Subscribers 99 subscribers
  • Views 2667 views
  • Users 0 members are here
Support feedback
Options
Options
Related

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.

FB Console breaks UART0 tty AM3352 custom board

Matthew Eshleman
Prodigy 210 points
Other Parts Discussed in Thread: AM3352, DA8XX

Hello,

I'm bringing up a custom board using AM3352 without SGX option. The board is based somewhat on the AM335x evm board. The board has a 320x240 16bit LCD attached to the LDC controller and is using UART0 for uboot/linux console. I'm starting from ti-processor-sdk-linux-am335x-evm-02.00.01.07.

I've created a custom board config for uboot, and that appears to be fine. It is based on the am335x_evm. UART0 is configured as console. This is ttyS0 for Linux.

I've created a custom dts file, which also seems fine, given the results so far.

The following issue happens when I use the default kernel config tisdk_am335x-evm_defconfig, with SGX plugin option disabled (happens either way, as I do not have SGX enabled in my devicetree).

As soon as the FB console is enabled, ttyS0 becomes "garbage". It appears as if the baud rate has changed from 115200 to some other rate.

Here is the log as seen from the console serial port (ttyS0, UART0). I'm connected to this UART via a standard FTDI UART - USB cable.

[ 0.329017] Serial: 8250/16550 driver, 10 ports, IRQ sharing enabled
[ 0.332756] console [ttyS0] disabled
[ 0.332849] 44e09000.serial: ttyS0 at MMIO 0x44e09000 (irq = 155, base_baud = 3000000) is a 8250
[ 0.989019] console [ttyS0] enabled
[ 0.993551] 48022000.serial: ttyS1 at MMIO 0x48022000 (irq = 156, base_baud = 3000000) is a 8250
[ 1.003356] 48024000.serial: ttyS2 at MMIO 0x48024000 (irq = 157, base_baud = 3000000) is a 8250
[ 1.013260] [drm] Initialized drm 1.1.0 20060810
[ 1.019887] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 1.026674] [drm] No driver support for vblank timestamp query.
ààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààààà

Here is the same log from /dev/kmsg:

6,142,1019887,-;[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
6,143,1026674,-;[drm] No driver support for vblank timestamp query.
6,144,1065716,-;Console: switching to colour frame buffer device 40x30
6,145,1104840,-;tilcdc 4830e000.lcdc: fb0:  frame buffer device
 SUBSYSTEM=platform
 DEVICE=+platform:4830e000.lcdc
6,146,1139486,-;tilcdc 4830e000.lcdc: registered panic notifier
 SUBSYSTEM=platform
 DEVICE=+platform:4830e000.lcdc
6,147,1194847,-;[drm] Initialized tilcdc 1.0.0 20121205 on minor 0
6,148,1242430,-;brd: module loaded
6,149,1267097,-;loop: module loaded
3,150,1287681,-;mtdoops: mtd device (mtddev=name/number) must be supplied
6,151,1394868,-;davinci_mdio 4a101000.mdio: davinci mdio revision 1.6

Notice that the ttyS0 output goes to "garbage" at the same time the "switching to colour frame buffer device..." output is happening on kmsg. Could be a coincidence...?

All that being said, the LCD is working, I see the penguin followed by the TI progress bar. The touch screen controller on I2C0 we are using is also testing/working fine. Also able to connect via SSH/Ethernet just fine.

If I disable CONFIG_FRAMEBUFFER_CONSOLE in my kernel configuration, then ttyS0 remains working fine and I can login to the device via ttyS0. Of course then I do not get the penguin or TI progress bar on the LCD.

So... looking for ideas on how to resolve and get BOTH the ttyS0 console and the LCD working at the same time.

Thank you,

Matthew

  • 0
    TI__Guru**** 161600 points
    Hi,

    Do you have
    CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
    CONFIG_FRAMEBUFFER_CONSOLE_ROTATION=y
    Enabled as well?

    Best Regards,
    Yordan
  • 0 in reply to Yordan Kovachev
    Prodigy 210 points

    Hi Yordan,

    Yes, they are enabled.

    In the meantime I think I have nearly found the issue. I measured the UART output when it was corrupted, and it was at 19200. Linux was still reporting 115200. This made be reconsider my clock settings. When I ported uboot by creating a custom manufacturer/board combo, I also ported some old code that would display a splash screen from uboot. When I disable this code, everything works correctly in Linux.

    This uboot LCD code makes many changes to AM3352 clock settings, so I suspect one of those isn't being reset by Linux or is considered incorrect from a Linux point of view. I'm still digging for the exact issue.

    Thank you for the reply!

  • 0 in reply to Matthew Eshleman
    Prodigy 210 points
    The issue was the older uboot code (and some current uboot examples do this too...) that was setting up the LCD controller using the Peripheral PLL/clock as the parent/source clock for the LCDC instead of using the Display PLL/clock. This "worked" ok from a uboot splash screen point of view...

    However, when Linux starts and initializes the latest TI LCDC driver, this driver would always set the LCDC divider to 2, and then change the PARENT clock to the appropriate setting to drive the pixel clock correctly. Since uboot configured the parent to the be the Peripheral clock, this immediately broke all UARTS, etc, when Linux made this change. I later also noticed that my I2C devices were also behaving incorrectly.

    I modified our uboot to activate and setup the Display PLL and use that clock source as the parent for the LCDC. This resolved all issues.
  • 0 in reply to Matthew Eshleman
    Prodigy 180 points

    Hi, Matthew,

    We are also stuck on same point as you were related to lcdc driver and display pll.

    Can you help how you help me on what exact change you made in uboot and kernel to solve that issue??

    Regards

    Rohit Khatri

  • 0 in reply to Parveen Kumar Yadav
    Prodigy 210 points

    Hello,

    There were no changes to Linux. The fix was entirely within the device's uboot port.

    The key points to help:

    * Deeply read and understand the Sitara's Technical Reference on the clock tree and PLLs. Especially the Display PLL and Peripheral PLL, noting that the SoC has internal switches that allow routing and using PLLs to source multiple internal devices. For example, see section 8.1.6.10 on the Display PLL. NOTE: the original uboot code did NOT use or activate this PLL. 

    * After understanding the above, find appropriate example code and supporting functions in existing uboot code that allow/enabling/setup the Sitara PLLs. Copy/modify so that they will modify/setup the Display PLL instead of the Peripheral PLL.

    * Calculate the M/N values for the Display PLL to drive your LCDC setup. I cheated and allowed Linux to boot, and then directly read the appropriate register values after the existing lcdc driver made the calculations based on my device tree setup for the target LCD screen.

    * Use the M/N values in your uboot code. Setup the Display PLL and make sure the LCDC registers are setup to use the Display PLL instead of the Peripheral PLL.

    Some other random notes:

    • We are using
    • CONFIG_VIDEO_DA8XX
    • CONFIG_LCD
    • Note: I used alot of uboot's built in LCD/splashscreen support, but ended up manually reading the target BMP file from flash and providing it via the uboot APIs for display. The version provided in the TI SDK seemed to still have issues in this area...
    • And, of course, the BMP must be in the format of your LCDC bit depth, etc..

    Hope that helps!

    Best regards,

    Matthew

    https://covemountainsoftware.com/consulting/