Raspberry Pi 4 bcm2711 / Raspberry Pi 3 bcm2837 (aarch64)
slarm64This forum is for the discussion of slarm64.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Just loaded 6.0.6 on my pi400, and it completely broke the HDMI output! It was broken to the extent that I couldn't even switch the monitor to my x86_64 machine to SSH in! I had to physically unplug the monitor from the Pi to be able to see my pc!
Once I did manage to SSH in, I reverted to 6.0.2 - with no other changes (aside from rebuilding the initrd), and normal service has been restored.
Not sure what caused it. I should have checked dmesg once I'd SSH'd in, but forgot in my panic to get it working again! I've never seen an HDMI output do that before!
Just loaded 6.0.6 on my pi400, and it completely broke the HDMI output! It was broken to the extent that I couldn't even switch the monitor to my x86_64 machine to SSH in! I had to physically unplug the monitor from the Pi to be able to see my pc!
Once I did manage to SSH in, I reverted to 6.0.2 - with no other changes (aside from rebuilding the initrd), and normal service has been restored.
Not sure what caused it. I should have checked dmesg once I'd SSH'd in, but forgot in my panic to get it working again! I've never seen an HDMI output do that before!
--
Pete
yes, it looks like the HDMI output was broken, I just assembled the last core, the problem remained.
And here's me updating the 6.0.2 image to 6.0.6 because mpv needed recompiling on 6.0.2 .... I think not!
It's called "the Bleeding Edge" for a reason. But keep up the good work. Maybe give the next one a try yourself?##I don't need/want bleeding edge, but reliability. I have an image on disk from last March which is basically 15.0 with a 5.16.7 kernel. It's a Known good image, so I'll install that on my "Just in case" MMC card.
EDIT: My little "Overscanning" problem pales into insignificance here really. We'll see what gives when the fix to the major issues happens.
Last edited by business_kid; 11-02-2022 at 11:55 AM.
@business_kid: That's a little harsh! If you want stability, stick to the 15.0 release. The -current release is always experimental, and sometimes things go wrong. Even Slackware is not immune to this, though it is a rare occurrence!
I don't recall having to rebuild mpv because of the kernel change. I had to do it when I upgraded ffmpeg (not surprisingly!), but had no issues recompiling 5.1.2 with my desired options.
Interestingly, I see this mornings updates over on Slawareaarch64 mention that the VC4 drivers work "out of the box" on kernel 6.0.6. I can't currently run Slackwareaarch64 as a kernel update (5.19.something or other) completely stopped my Pi400 from booting at all! I'm waiting for 6.0.6+ to be fully incorporated before trying it again.
No idea why it works there and not here unless its a configuration peculiarity - either in the kernel itself, or in the /boot/config.txt file. I can't see anything obvious in the latter.
I'm sure sndwvs will find a fix sooner rather than later.
in the kernel from the raspberry pi foundation, changes were made between kernel versions 6.0.4 and 6.0.6 in the vc4 driver, due to which the HDMI output broke, so far I have returned the driver behavior to version 6.0.4
Thanks for the update! I usually update from your kernel repository: https://dl.slarm64.org/slackware/ima...y_pi_4/kernel/
but it seems to be unavailable at the moment. I'll perhaps have another look tomorrow, as I guess you might be updating?
Thanks for the update! I usually update from your kernel repository: https://dl.slarm64.org/slackware/ima...y_pi_4/kernel/
but it seems to be unavailable at the moment. I'll perhaps have another look tomorrow, as I guess you might be updating?
@business_kid: That's a little harsh! If you want stability, stick to the 15.0 release. The -current release is always experimental, and sometimes things go wrong. Even Slackware is not immune to this, though it is a rare occurrence!
I don't recall having to rebuild mpv because of the kernel change. I had to do it when I upgraded ffmpeg (not surprisingly!), but had no issues recompiling 5.1.2 with my desired options.
Well, I want stability, but 15.0 needed a kernel update. Where I have the RazPi is very awkward for me. 5.16.7 came shortly after and I've added the d/ section of 15.0 which the image omits with no issues. I thought there was a video upgrade out, so I tried the imnage. But my MMC has died. I'm not aggrieved - that one served me well.
The mpv thing was that on the 6.0.2 image, mpv wanted libavutil.so.56 and the image supplied libavutil.so.57. I symlinked it. But mpv complained about another lib, so I ran
Code:
ldd /usr/bin/mpv |grep found
and got half a dozen libs. It looks like all the libs were updated, but mpv wasn't.
EDIT: Despite wanting stability, it's a media box. So if a video upgrade comes, I'll take it, and settle everything after.
Last edited by business_kid; 11-03-2022 at 09:31 AM.
Yes, that's got it working again! Thanks for your efforts!
Video performance is improved, with 1080 now using under 50% on 3 cores and 60% on the fourth. Previously it was nearly 90% on all four! 4K is still problematic, though, using 90%+ on all 4 cores, and stuttery. It is better than before though, when it was unusable.
According to Phoronix, we need to wait for 6.2 to get full 4K on Pi's....!
There is an interesting article here: https://melissawen.github.io/blog/20...n-the-mainline
on getting the V3D drivers running fully on Pi4s and newer. I'm not sure how the compilation instructions compare with how sndwvs compiles, but it certainly looks interesting.
One interesting point is that it appears to use the mainline kernel, not the "Pi-tweaked" one.
Just as feedback, I dropped this (XFCE) image on a new MMC card and booted it. All seems excellent with it and no graphics wobbles. The ext2 filesystem did need minor surgery. Here, I use the combination of SSD for normal use with an sdcard as a spare. That way, if the system goes funny, I can shove in the sdcard and it has booting precedence over the SSD. I did try moving the "kernel=u-boot.bin" line to the very end of /boot/config.txt to see if something would pay attention to the overscan parameters I need for my (digital) tv, but no joy. So I'm booting directly via config.txt on the kernel & initrd with version numbers.
I'm not tempted to try compiling unstable kernels for improved graphics. I've had my share of 500+ messages/day on LKML, & compiling unstable and reluctant kernels on cheapskate hardware; and of angry kernel devs snarling at me and my flaky hardware. I'll wait for 6.2.x to be on the other end of a url that some kind soul (probably sndwvs) supplies. Murphy's Law of course dictates that as soon as kernel-6.2.0 is declared, that's when all the bugs will appear.
Just as feedback, I dropped this (XFCE) image on a new MMC card and booted it. All seems excellent with it and no graphics wobbles. The ext2 filesystem did need minor surgery. Here, I use the combination of SSD for normal use with an sdcard as a spare. That way, if the system goes funny, I can shove in the sdcard and it has booting precedence over the SSD. I did try moving the "kernel=u-boot.bin" line to the very end of /boot/config.txt to see if something would pay attention to the overscan parameters I need for my (digital) tv, but no joy. So I'm booting directly via config.txt on the kernel & initrd with version numbers.
the choice of a disk with a root partition is based on the UUID specified in /boot/uEnv.txt
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
