Beagleboard-xM and DVI unstable on 3.11 kernel

A pre-configured Raring 13.94 image with the 3.11 kernel seems to be very unstable with my DVI monitor. Depending on some boot timing, it may not recognize the monitor at all, or it may recognize it correctly, and work with it.

Sometimes the EDID info can be read:

parse-edid /sys/class/drm/card1-Unknown-1/edid

parse-edid: parse-edid version 2.0.0
parse-edid: EDID checksum passed.

EDID version 1 revision 3

Section “Monitor”

Block type: 2:0 3:fd

Block type: 2:0 3:ff

Block type: 2:0 3:fc

Identifier “Acer S231HL”
VendorName “ACR”
ModelName “Acer S231HL”

Block type: 2:0 3:fd

HorizSync 30-80
VertRefresh 55-75

Max dot clock (video bandwidth) 160 MHz

Block type: 2:0 3:ff

Block type: 2:0 3:fc

DPMS capabilities: Active off:yes Suspend:no Standby:no

Mode “1920x1080” # vfreq 60.000Hz, hfreq 67.500kHz
DotClock 148.500000
HTimings 1920 2008 2052 2200
VTimings 1080 1084 1089 1125
Flags “+HSync” “+VSync”
EndMode

Block type: 2:0 3:fd

Block type: 2:0 3:ff

Block type: 2:0 3:fc

EndSection

Sometimes the EDID info “cannot be read”:

parse-edid /sys/class/drm/card1-Unknown-1/edid

parse-edid: parse-edid version 2.0.0
parse-edid: IO error reading EDID

When this happens, the monitor no longer shows anything at all. If I re-plug the DVI cable, the picture sometimes shows up after a couple of seconds, and then a couple of seconds later goes away. Seems that EDID reading has become unstable.

I rebuilt the 3.11 kernel with the latest patches, no difference.

When the monitor is connected via a KVM switch, the resolution is sometimes lower than with the direct connection. And the same thing often happens: after a couple of seconds the picture disappears.

On 3.7 I never saw anything like this. Would have stayed on 3.7 for now, which seems to be more stable, but I the 3.11 has some USB EHCI fixes to enable support for the KVM switch.

Thanks!

Well the video stack between 3.7 and 3.11 is completely different.

So if your going to use this device in a KVM switch environment with
3.11 (omapdrm/kms), figure out now what your display actually supports
and hardcode it as a boot time argument (bootargs)..

video=DVI-D-1:1024x768@60 (or whatever resolution you want..)

btw, you'll also have to add this setting to xorg.conf that way xorg
has the same resolution..

otherwise random is what your going to get...

Regards,

Well, this didn’t seem to help. Here is my new mmcargs line in the uEnv.txt:

mmcargs=setenv bootargs console=${console} ${optargs} ${kms_force_mode} video=DVI-D-1:1024x768@60 root=${mmcroot} rootfstype=${mmcrootfstype} ${expansion}

When plugged into the KVM, the u-boot orange color comes up, and then the signal to the monitor disappears. I don’t even see the Linux startup logo. Once the OS has booted, switching to another source and then back to BB-xM causes the monitor picture to come up… only for a couple of seconds. Then the monitor seems to go out of sync, and the picture disappears.

I am not even running X at this time, just the text monitor.

Seems to work solid as a rock on 3.7. I can set the dvimode, and it does work too.

Well, this didn't seem to help. Here is my new mmcargs line in the
uEnv.txt:

mmcargs=setenv bootargs console=${console} ${optargs} ${kms_force_mode}
video=DVI-D-1:1024x768@60 root=${mmcroot} rootfstype=${mmcrootfstype}
${expansion}

When plugged into the KVM, the u-boot orange color comes up, and then the
signal to the monitor disappears. I don't even see the Linux startup logo.
Once the OS has booted, switching to another source and then back to BB-xM
causes the monitor picture to come up... only for a couple of seconds. Then
the monitor seems to go out of sync, and the picture disappears.

I am not even running X at this time, just the text monitor.

I need to backport another fix i just found yesterday on v3.12-rc1, v3.11
https://github.com/RobertCNelson/linux-dev/blob/master/patches/omap_dt_dss/0023-test-ARM-omap3-beagle-xm.dts-add-display-information.patch#L23

With v3.11.x, on bootup u-boot sets bit 2 high so the tfp410 is on,
but then the kernel dts would switch that back to a pull down (low)
thus disabling the screen, before it finally comes up again..

Seems to work solid as a rock on 3.7. I can set the dvimode, and it does
work too.

Well like i said, "it's different" and i'm still shipping 3.7 with the
option for 3.11 (3.11 also adds 1Ghz operation..)

Regards,

Well, I’ll be waiting for you to backport the fix into 3.11, or until you release 3.12. I tried incorporating the fix myself, but got an error on device tree compile:

DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
Error: arch/arm/boot/dts/omap3-beagle-xm.dts:265.2-3 label or path, ‘dpi’, not found
FATAL ERROR: Syntax error parsing input tree

which probably shows that I don’t know what I am doing. Besides, I should probably be editing the arch/arm/boot/dts/omap3-beagle-xm-c.dts file, as that is the actual device we are using.

3.7 does work for the DVI monitor, but the KVM switch is not recognized on EHCI USB (the problem must have been fixed somewhere in 3.8+, as it wasn’t working on BBB either until I rebuilt the kernel a few days ago, and now it unexpectedly does work).

Well, I'll be waiting for you to backport the fix into 3.11, or until you
release 3.12. I tried incorporating the fix myself, but got an error on
device tree compile:

DTC arch/arm/boot/dts/omap3-beagle-xm.dtb
Error: arch/arm/boot/dts/omap3-beagle-xm.dts:265.2-3 label or path, 'dpi',
not found
FATAL ERROR: Syntax error parsing input tree

which probably shows that I don't know what I am doing. Besides, I should
probably be editing the arch/arm/boot/dts/omap3-beagle-xm-c.dts file, as
that is the actual device we are using.

Just pushed it out, give it a test top of the "v3.11.x" branch:
https://github.com/RobertCNelson/armv7-multiplatform

https://github.com/RobertCNelson/armv7-multiplatform/commit/c28324a226a7383f9fdd03ec74e509646b4d1c2b

3.7 does work for the DVI monitor, but the KVM switch is not recognized on
EHCI USB (the problem must have been fixed somewhere in 3.8+, as it wasn't
working on BBB either until I rebuilt the kernel a few days ago, and now it
unexpectedly does work).

So for usb with v3.11, we are finally enabling the "famous"
sprz319_erratum_v2.1 workaround. Before, the patch had issues where
it would cause lockups on earlier omap34xx devices (beagleboard
classic).. Now that everything is protected behind a omap34xx &
omap36xx path in the kernel...

Regards,

Thanks! It really does seem to be working better. At least so far since pulling and building the latest update I’ve been unable to reproduce the problem of the monitor getting the picture, then going away after a couple of seconds.

However, the resolution is still random! If during the kernel startup the KVM is switched to another port (a desktop PC), the beagle is able to read the EDID, and sets the resolution to whatever the desktop sets it to (1280x1024).

If during the boot the KVM is switched to the beagle, the beagle cannot access the EDID, and sets the resolution to 800x600.

The video=DVI-D-1:1024x768@60 setting in uEnv.txt doesn’t seem to come into play at all.

Thanks! It really does seem to be working better. At least so far since
pulling and building the latest update I've been unable to reproduce the
problem of the monitor getting the picture, then going away after a couple
of seconds.

Cool, glad that's working.. I'll post a patch upstream for it too..

However, the resolution is still random! If during the kernel startup the
KVM is switched to another port (a desktop PC), the beagle is able to read
the EDID, and sets the resolution to whatever the desktop sets it to
(1280x1024).

If during the boot the KVM is switched to the beagle, the beagle cannot
access the EDID, and sets the resolution to 800x600.

The video=DVI-D-1:1024x768@60 setting in uEnv.txt doesn't seem to come into
play at all.

Humm, can you post your full dmesg output to pastebin.com?

"dmesg | pastebinit" will do it automaticly..

Regards,

sure, here it is: http://paste.ubuntu.com/6133927/

BTW, I’ve been enabling the sprz319_erratum patch since I started working with the beagles, as the LAN connections were frequently getting stuck and killing the whole USB on some of our boards. On 3.7 it didn’t seem to make any difference in regard to the KVM switch. I just rebuilt the latest version, still the same result:

[ 171.847137] usb 1-2.3: new high-speed USB device number 24 using ehci-omap
[ 171.965270] usb 1-2.3: New USB device found, idVendor=0409, idProduct=005a
[ 171.965332] usb 1-2.3: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 171.972503] hub 1-2.3:1.0: USB hub found
[ 171.973358] hub 1-2.3:1.0: 4 ports detected
[ 176.253479] hub 1-2.3:1.0: Cannot enable port 4. Maybe the USB cable is bad?
[ 180.339172] hub 1-2.3:1.0: Cannot enable port 4. Maybe the USB cable is bad?
[ 184.425109] hub 1-2.3:1.0: Cannot enable port 4. Maybe the USB cable is bad?
[ 188.511383] hub 1-2.3:1.0: Cannot enable port 4. Maybe the USB cable is bad?
[ 188.519836] hub 1-2.3:1.0: unable to enumerate USB device on port 4
[ 192.761230] hub 1-2.3:1.0: Cannot enable port 3. Maybe the USB cable is bad?
[ 196.847473] hub 1-2.3:1.0: Cannot enable port 3. Maybe the USB cable is bad?
[ 200.932891] hub 1-2.3:1.0: Cannot enable port 3. Maybe the USB cable is bad?
[ 205.018798] hub 1-2.3:1.0: Cannot enable port 3. Maybe the USB cable is bad?
[ 205.027374] hub 1-2.3:1.0: unable to enumerate USB device on port 3

Thanks! So now i see my mistake..

In my hack of a attempt at enabling omapdrm/kms i missed one little detail..

the connector is labled as "card1-Unknown-1"

debian@arm:~$ uname -a
Linux arm 3.11.1-armv7-x13.2 #2 SMP Fri Sep 20 11:56:12 CDT 2013
armv7l GNU/Linux
debian@arm:~$ ls /sys/class/drm/
card0 card1 card1-Unknown-1 controlD64 controlD65 version

in v3.12.x it is the correct "DVI-D-1"

So use this instead for v3.11.x

video=Unknown-1:1024x768@60e

The "e" also should force it no matter what..
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/fb/modedb.txt#n41

Regards,

Thanks, that’s what I needed! I didn’t understand the meaning of video= setting at the kernel command line before, and I do now. Every new kernel version seems to have a different name for those video “cards”. :slight_smile:

Well the good news, going forward all kms/drm drivers follow the
modedb video setup; video=device:XxY@FREQ for everything,
imx/ati/nvidia/etc so all that omapfb stuff can be forgotten..

The bad news the "Unknown-1" name was auto-detected at bootup, so you
need to check that directory for every different device..

Regards,