Skip to first unread message
porkupan
Sep 19, 2013, 5:15:20 PM9/19/13
to beagl...@googlegroups.com
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:
Sometimes the EDID info "cannot be read":
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!
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
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
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!
Robert Nelson
Sep 19, 2013, 5:26:38 PM9/19/13
to Beagle Board
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,
--
Robert Nelson
http://www.rcn-ee.com/
porkupan
Sep 20, 2013, 11:22:38 AM9/20/13
to beagl...@googlegroups.com
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.
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.
Robert Nelson
Sep 20, 2013, 11:30:07 AM9/20/13
to Beagle Board
On Fri, Sep 20, 2013 at 10:22 AM, porkupan <vladimi...@gmail.com> wrote:
> 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
> 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.
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.
option for 3.11 (3.11 also adds 1Ghz operation..)
porkupan
Sep 20, 2013, 12:46:01 PM9/20/13
to beagl...@googlegroups.com
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).
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).
Robert Nelson
Sep 20, 2013, 1:06:12 PM9/20/13
to Beagle Board
On Fri, Sep 20, 2013 at 11:46 AM, porkupan <vladimi...@gmail.com> wrote:
> 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:
> 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.
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).
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...
porkupan
Sep 20, 2013, 2:28:46 PM9/20/13
to beagl...@googlegroups.com
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.
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.
Robert Nelson
Sep 20, 2013, 2:38:19 PM9/20/13
to Beagle Board
On Fri, Sep 20, 2013 at 1:28 PM, porkupan <vladimi...@gmail.com> wrote:
> 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..
> 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.
"dmesg | pastebinit" will do it automaticly..
porkupan
Sep 20, 2013, 2:46:55 PM9/20/13
to beagl...@googlegroups.com
sure, here it is: http://paste.ubuntu.com/6133927/
porkupan
Sep 20, 2013, 2:56:24 PM9/20/13
to beagl...@googlegroups.com
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
[ 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
On Friday, September 20, 2013 1:06:12 PM UTC-4, RobertCNelson wrote:
Robert Nelson
Sep 20, 2013, 4:08:21 PM9/20/13
to Beagle Board
On Fri, Sep 20, 2013 at 1:46 PM, porkupan <vladimi...@gmail.com> wrote:
> sure, here it is: http://paste.ubuntu.com/6133927/
Thanks! So now i see my mistake..
> sure, here it is: http://paste.ubuntu.com/6133927/
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
porkupan
Sep 20, 2013, 4:21:29 PM9/20/13
to beagl...@googlegroups.com
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". :)
Robert Nelson
Sep 20, 2013, 4:30:25 PM9/20/13
to Beagle Board
On Fri, Sep 20, 2013 at 3:21 PM, porkupan <vladimi...@gmail.com> wrote:
> 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". :)
Well the good news, going forward all kms/drm drivers follow the
> 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". :)
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..
Reply all
Reply to author
Forward
0 new messages