Delaying OMAP DSS screen initialization

This forum is for supported devices using an ARMv7 Texas Instruments (TI) SoC.

Delaying OMAP DSS screen initialization

Postby ciofeca » Wed Sep 07, 2016 10:29 am

In 2015 I've been using a Sunfounder HDMI display for months. Everything went flawless.
Then I left that Beagleboard XM somewhere collecting dust.

A few days ago I switched it on again and upgraded everything - arrrgh, didn't keep a backup.

Sometimes the HDMI display does not get recognized. In the journal the only hint about it is this line:
$this->bbcode_second_pass_code('', '[drm] Cannot find any crtc or sizes - going 1024x768')

So far tried four different Beagleboard XM (three "rev.C" and one "rev.B"), a different HDMI cable, a different HDMI display - the problem persists.

I even added a check: if dmesg contains "any crtc or sizes" then reboot immediately.

Then I found a cleaner trick that doesn't require a reboot:

1. move the omapdrm directory from the /lib/modules tree to /root

2. during boot, execute as root this script:
$this->bbcode_second_pass_code('', '#!/bin/sh

insmod omapdrm/dss/omapdss.ko.gz
insmod omapdrm/omapdrm.ko.gz
insmod omapdrm/displays/encoder-tfp410.ko.gz
insmod omapdrm/displays/connector-dvi.ko.gz
')

I guess the problem is the HDMI stuff gets initialized quite too early in the Linux kernel.

I don't know if it's a new OMAP kernel bug introduced with the 4.7 series, or something in the 7" Sunfounder HDMI display goes wrong from time to time (less probable, since UBoot always correctly initializes it at boot).

Currently I get my software displaying its logo on the screen in 23 seconds from turning on the XM, that is, about 3 to 5 seconds more than the a few months ago. Arrgh.
ciofeca
 
Posts: 13
Joined: Wed Feb 20, 2013 10:19 pm

Re: Delaying OMAP DSS screen initialization

Postby ciofeca » Sat Oct 15, 2016 5:16 pm

Just updated to Linux version 4.8.1-2-ARCH, and the Cannot find any crtc or sizes message did not appear anymore - the output of dmesg | grep drm is:

$this->bbcode_second_pass_code('', '[ 1.968902] [drm] Initialized drm 1.1.0 20060810
[ 10.394287] omapdrm omapdrm.0: DMM not available, disable DMM support
[ 10.395446] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 10.395446] [drm] No driver support for vblank timestamp query.
[ 10.468536] omapdrm omapdrm.0: fb0: omapdrm frame buffer device
[ 10.468566] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0
')

Thus, the only working solution to get that external HDMI working at boot, is to manually insmod the modules after booting (that omapdrm must not be in the /lib/modules tree, to not to allow the kernel to automatically load them). Now I get the same messages, but this time the kernel command line parameter was correctly interpreted:

$this->bbcode_second_pass_code('', '[ 1.968841] [drm] Initialized drm 1.1.0 20060810
[ 22.009857] omapdrm omapdrm.0: DMM not available, disable DMM support
[ 22.010314] [drm] forcing DVI-D-1 connector ON
[ 22.013458] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[ 22.013458] [drm] No driver support for vblank timestamp query.
[ 22.141845] omapdrm omapdrm.0: fb0: omapdrm frame buffer device
[ 22.183258] [drm] Initialized omapdrm 1.0.0 20110917 on minor 0
')

Output of my cat /proc/cmdline using the Sunfounder HDMI monitor:
$this->bbcode_second_pass_code('', 'video=DVI-D-1:1024x600@60e vt.global_cursor_default=0 consoleblank=0 console=ttyS2,115200n8 quiet loglevel=3 rootwait ro root=/dev/mmcblk0p2')

Note the DVI-D-1 (that is, the HDMI jack of the Beagleboard) at 1024x600, 60 Hz, always enabled ("e").
ciofeca
 
Posts: 13
Joined: Wed Feb 20, 2013 10:19 pm


Return to Texas Instruments (TI)

Who is online

Users browsing this forum: No registered users and 3 guests