LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 08-20-2020, 12:00 PM   #46
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Rep: Reputation: Disabled

Ha, I figured this one out....

My problem is that I am using HDMI to VGA converter. This works fine on the 5.6.x image (but the lights do not blink ever at all, strange...)

With the 5.7.x image, I get output on HDMI-to-DVI, (I do not have a pure HDMI monitor), but no longer does HDMI-to-VGA work like it used to. And the lights make sense now, the white is disk activity, I can see that clearly now. I was used to solid lights from the previous image.

I ran into something like this with the legacy kernel versus the next kernel. If I recall correctly, the audio jack only works on the legacy kernel, and you need to use HDMI audio out on the next kernel. Or vice versa. One of the kernels had limited audio support, and it was an upstream thing. I could try to re-investigate that one again.. some day.

Anyway, this image works as long as you avoid HDMI-to-VGA, which is something I use a lot, so I might just stick with the 5.6.x kernel on this board.
 
Old 08-29-2020, 10:10 AM   #48
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Rep: Reputation: Disabled
Interesting turn of events... after an xorg update (I think), now even my working 5.6.19 image segfaults when I try to start X, using the HDMI-VGA converter. So I lost that ability on even my old image. I am hoping that maybe the next xorg update fixes things....

Your fresh images seem to work fine, as long as I avoid the HDMI-VGA converter. That might be broken forever now. Which obsoletes several of my monitors. *Sigh*
 
Old 08-29-2020, 11:49 AM   #49
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Original Poster
Rep: Reputation: Disabled
try to boot and then check /var/log/Xorg.0.log on something else, so that you can understand what the problem is.
 
Old 08-30-2020, 08:29 AM   #50
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
try to boot and then check /var/log/Xorg.0.log on something else, so that you can understand what the problem is.
Oh, good idea. I tried the same thing using my HDMI-DVI converter/monitor and got the same segfault. No segfault before an update, and then segfault immediately after the update. Here is Xorg.0.log, same using both monitors:

Code:
[    57.852] 
X.Org X Server 1.20.9
X Protocol Version 11, Revision 0
[    57.866] Build Operating System: Slackware 15.0 Slackware Linux Project
[    57.870] Current Operating System: Linux Builder.Bob 5.6.19 #1 SMP PREEMPT Sat Jun 20 23:26:53 MDT 2020 aarch64
[    57.870] Kernel command line: root=/dev/mmcblk1p1 ro rootwait rootfstype=ext4 init=/sbin/init console=ttyS2,1500000n8 console=tty1 panic=10 consoleblank=0 loglevel=4 
[    57.879] Build Date: 29 August 2020  05:21:10AM
[    57.883]  
[    57.887] Current version of pixman: 0.40.0
[    57.895] 	Before reporting problems, check http://wiki.x.org
	to make sure that you have the latest version.
[    57.895] Markers: (--) probed, (**) from config file, (==) default setting,
	(++) from command line, (!!) notice, (II) informational,
	(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
[    57.912] (==) Log file: "/var/log/Xorg.0.log", Time: Thu Jan 21 08:51:07 2016
[    57.928] (==) Using system config directory "/usr/share/X11/xorg.conf.d"
[    57.932] (==) No Layout section.  Using the first Screen section.
[    57.932] (==) No screen section available. Using defaults.
[    57.932] (**) |-->Screen "Default Screen Section" (0)
[    57.932] (**) |   |-->Monitor "<default monitor>"
[    57.933] (==) No monitor specified for screen "Default Screen Section".
	Using a default monitor configuration.
[    57.933] (==) Automatically adding devices
[    57.933] (==) Automatically enabling devices
[    57.933] (==) Automatically adding GPU devices
[    57.933] (==) Automatically binding GPU devices
[    57.935] (==) Max clients allowed: 256, resource mask: 0x1fffff
[    57.935] (WW) The directory "/usr/share/fonts/local" does not exist.
[    57.935] 	Entry deleted from font path.
[    57.935] (WW) The directory "/usr/share/fonts/CID" does not exist.
[    57.935] 	Entry deleted from font path.
[    57.940] (==) FontPath set to:
	/usr/share/fonts/misc,
	/usr/share/fonts/TTF,
	/usr/share/fonts/OTF,
	/usr/share/fonts/Type1,
	/usr/share/fonts/75dpi/:unscaled,
	/usr/share/fonts/100dpi/:unscaled,
	/usr/share/fonts/75dpi,
	/usr/share/fonts/100dpi,
	/usr/share/fonts/cyrillic
[    57.940] (==) ModulePath set to "/usr/lib64/xorg/modules"
[    57.940] (II) The server relies on udev to provide the list of input devices.
	If no devices become available, reconfigure udev or disable AutoAddDevices.
[    57.940] (II) Loader magic: 0x620c28
[    57.940] (II) Module ABI versions:
[    57.940] 	X.Org ANSI C Emulation: 0.4
[    57.940] 	X.Org Video Driver: 24.1
[    57.940] 	X.Org XInput driver : 24.1
[    57.940] 	X.Org Server Extension : 10.0
[    57.941] (II) xfree86: Adding drm device (/dev/dri/card0)
[    57.941] (II) Platform probe for /sys/devices/platform/display-subsystem/drm/card0
[    57.972] (EE) 
[    57.982] (EE) Backtrace:
[    57.992] (EE) 0: /usr/libexec/Xorg (OsLookupColor+0x188) [0x583290]
[    57.997] (EE) 
[    58.001] (EE) Segmentation fault at address 0x0
[    58.006] (EE) 
Fatal server error:
[    58.015] (EE) Caught signal 11 (Segmentation fault). Server aborting
[    58.019] (EE) 
[    58.023] (EE) 
Please consult the The X.Org Foundation support 
	 at http://wiki.x.org
 for help. 
[    58.038] (EE) Please also check the log file at "/var/log/Xorg.0.log" for additional information.
[    58.042] (EE) 
[    58.046] (EE) Server terminated with error (1). Closing log file.
Is this just me? I am getting the same error on two different builds (older 5.6.19 stable build and fresh 5.7.x build).

thanks.
 
Old 08-30-2020, 09:37 AM   #51
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Original Poster
Rep: Reputation: Disabled
try to block the panfrost module from starting
Code:
echo "install panfrost /bin/false" > /etc/modprobe.d/blacklist-panfrost.conf
 
Old 09-04-2020, 09:34 PM   #52
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Original Poster
Rep: Reputation: Disabled
shelldweller, it turned out to be a problem of xorg 1.20.9 itself https://bugzilla.redhat.com/show_bug.cgi?id=1707234
 
Old 09-06-2020, 12:57 PM   #53
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
shelldweller, it turned out to be a problem of xorg 1.20.9 itself https://bugzilla.redhat.com/show_bug.cgi?id=1707234
Ah, I had a feeling that this was the case. Thanks for looking into it. I will have some time to play around today. If I make any discoveries, I will let you know.
 
Old 09-07-2020, 04:29 PM   #54
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Rep: Reputation: Disabled
Your patch did the trick. Xorg is back to normal on my Rock64. I am sticking with the 5.6.y kernel for now to keep the external monitor working. I will keep testing the new kernel though, when I get a chance. Thanks sndwvs.
 
Old 09-12-2020, 08:27 PM   #55
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Rep: Reputation: Disabled
I was able to reproduce the HDMI-converter bug on Armbian Buster. The legacy image with the 4.4.y kernel works as expected, and on the 5.8.y kernel image, HDMI-to-anything conversion is broken. This must be a 5.8.y kernel issue. Just thought I would report my updated findings here. Carry on...
 
1 members found this post helpful.
Old 09-18-2020, 10:45 AM   #56
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Original Poster
Rep: Reputation: Disabled
maybe this is the same problem, I looked in the old kernel there is this setting in DTS.
Need to add to DTS and rebuild the make dtbs
try renaming 1-rk3328-rock64.dtb or 2-rk3328-rock64.dtb to and replacing the file in /boot/dtb/rk3328-rock64.dtb

Last edited by sndwvs; 09-18-2020 at 11:54 AM.
 
Old 10-13-2020, 06:06 PM   #57
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
maybe this is the same problem, I looked in the old kernel there is this setting in DTS.
Need to add to DTS and rebuild the make dtbs
try renaming 1-rk3328-rock64.dtb or 2-rk3328-rock64.dtb to and replacing the file in /boot/dtb/rk3328-rock64.dtb
I have been investigating this a bit further. The strange part is that I cannot reproduce my previous results of the problem being adapter-dependent. What I am seeing now is much more straightforward though:

Legacy kernel works fine, no problems there at all, it seems.

There is no video out at all through HDMI port using the mainline kernel. I have a VGA monitor and a DVI monitor, and in both cases, there is no output on the screen at all at any stage, while both work fine on the legacy kernel using the same connectors.

I went rolling back through the commits, and the results were not all that surprising. 5.6.y kernels worked fine, and the problem manifests the very instant of the switch to the 5.7.y kernel. The problem seems to persist up to 5.8.y. I tried the latest commit, and I still have that problem.

I might not be understanding the proposed fix: I just rename each of those files and replace /boot/dtb/rk3328-rock64.dtb with each one, one at a time, and test, correct? I tried that, and it does not seem to make any difference at all.

I have no idea why it seemed to work on one monitor but not the other at one point. I can try to figure that out, but for now every mainline image I build for this board for any 5.7.y or 5.8.y kernel gives the same result.

I guess I was just getting some weird results for a while there, both on this board and on the Pinebook, for whatever reason. At least it is more consistent now.

This is not a huge deal, but it is interesting at the very least. Thanks as always.
 
Old 10-13-2020, 06:21 PM   #58
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by shelldweller View Post
I might not be understanding the proposed fix: I just rename each of those files and replace /boot/dtb/rk3328-rock64.dtb with each one, one at a time, and test, correct?
yes. we will look at development.
 
  


Reply

Tags
rk3328, rock64


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
LXer: Meet ROCK64, a 4K-Capable Single-Board Computer That Can Run Android 7.1, Debian LXer Syndicated Linux News 0 07-07-2017 08:30 AM
LXer: Open-spec, RPi-style SBC features new Rockchip RK3328 LXer Syndicated Linux News 0 07-05-2017 08:03 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 08:33 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration