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.
Shrinking the size of displayed video did next to nothing. Slackware Arm seems little better. Kernel 6.0.9 seems to have no acceleration enabled.
Funny. I tried this last night again and the 6.0.9 RazPi image from mid-November (post#58 on that thread) seemed notably lower than 5.16.7 on cpu usage. I didn't get to try it on my test video though. Is there some reason you released the 5.15.85 image yesterday?
I had a number of lock-ups yesterday requiring hard power-offs, and I was unlucky in the disk & sdcard lottery, so repairs today. This 25th is always a lazy day for me. We're Jehovah's Witnesses, and don't do the Xmas/Saturnalia/Christmas thing at all. I even had my Meeting yesterday, because there's too many congregations using our Kingdom Hall, so we we have Saturday Morning at the moment.
I also gave up on the debian 64bit as there's no flesh on the bones. They cross-compiled it on X86_64 I'm sure, because they don't have the basics for it(e.g. gcc!). I grabbed the Debian 32bit, which is an OS with a full repo. It's there as a last resort. The guy who does box64 also does a 32bit version, box86, so I can even try zoom on it. I managed to untangle a 32bit zoom from their website.
EDIT: with your 6.0.9 image, mpv ran my test mkv video segment @ 350-375% in top, although I thought I saw higher peaks in htop. VLC doesn't share the threads around as carefully and stalls. Debian runs it @ 60-70% on the same segment. But there seems to be an improvement over 5.16.7 in other formats, although I'd have to run comparisons to be sure.
Last edited by business_kid; 12-25-2022 at 10:31 AM.
this is the recommended kernel from the raspberry pi foundation.
OK, I'll try it. They're not a lot I trust much. When the hardware guys/gals understand & inform the software guys well, things work best and development goes places. But the more closed source cores go into an SoC, the less folks understand it. Raspberry Pi has put off new product (RazPi 5) development and clearly have to gear up for competition. Hardware guys won't be easy to hold on to. It's a dog-eat-dog world, worse than software because there's too many guys for too few jobs. The top hardware experts make millions, the rest - nothing.
I'll bet the raspberry pi foundation backed 5.15.x because 5.15.x is LTS. The 6.0.9 had bcm2835 staging drivers. I see you've enabled 30 of them. I have the 6.0.9 kernel, so I can upgrade the 5.15.85 on the new image if I don't like it. I can't imagine it being better, but here goes.
BTW, what are you doing online on christmas day?
Last edited by business_kid; 12-25-2022 at 12:11 PM.
Ah! I have the 5.15.85 kernel in. It looks like you backported the patches . Mind you, I'm not checking the source to find out.
Hardware wise, I never gave much thought to the RazPi 5, but it's a problem. Whatever they do, they lose half their market. So they'll have to do a couple of things together.
Ah! I have the 5.15.85 kernel in. It looks like you backported the patches . Mind you, I'm not checking the source to find out.
in this kernel they still support this driver and as far as I remember when playing video, it gave the best result.
Quote:
Originally Posted by business_kid
Hardware wise, I never gave much thought to the RazPi 5, but it's a problem. Whatever they do, they lose half their market. So they'll have to do a couple of things together.
boards based on rk3588/rk3588s(orange pi 5 implements everything I need with 16GB of memory) came out on the market for a good price by a wide margin, and support mainly lies with community, however, all the features are implemented in the kernel from the manufacturer 5.10.y.
As an invalid, I work at a much less frenetic pace than I used do, and certainly attempt less than my days at soldering SMT under magnification. I can't solder at all these days but I did make some progress.
I restored my SSD from backup at the second attempt. I bent that straight, and that runs, but the graphics suck.
I had Debian 32bit up & running, but like a fool I let it update, and the sound went. It also defied sanity by refusing to set screen size. So I can't update it.
I burned an sdcard with your 5.15.85 image, but got no sound. Next day I tried it again, and it got lost at the boot stage. ;eek: Burning it again now.
I burned the 6.0.9 image (from mid November) and it works well. Video on the mkv test section is up at 350% usage, but another .mp4 video only showed ~130%. I think .avi is lighter again. What's irritating is that a h264 video doesn't seem to use the h264 section of the gpu. But on debian's kernel, it seems to.
I also had a look at your orange pi 5. Personally, I wouldn't buy as there's too much on a small pcb for someone more clumsy like me. I'd expect broken connectors. Thick wires (e.g hdmi) going into surface mounted connectors is bad practise. I'd need a robust enclosure at least. I'd also wonder about total cost. The ssd (NVME?) onboard is a lovely feature.
The cpu/gpu pair on the orange pi look very good for your use case(compiling). The orange Pi 5 has it's niche now, but not many folks out there need an awkward little sbc talking about AI & 8K video. There's plenty of cheaper models. If I could get that pi 4 comfortable with videos, I'd leave it be. The Raspberry Pi lot are probably going to lose out here because they're not thinking far enough ahead.
A few questions:
Can I stick the newer kernels onto my old system or will something like glibc versions trip me up?
Your "Transfer-to-disk" script: I have sda1=/boot; sda2=/; sda3=/home, which is the biggest on a 240G SSD. What do I come out with? Will /home be formatted?
Last edited by business_kid; 12-26-2022 at 11:35 AM.
Can I stick the newer kernels onto my old system or will something like glibc versions trip me up?
glibc built with the same options as slackwar64 --enable-kernel=2.6.32
Quote:
Originally Posted by business_kid
Your "Transfer-to-disk" script: I have sda1=/boot; sda2=/; sda3=/home, which is the biggest on a 240G SSD. What do I come out with? Will /home be formatted?
yes, when transferring, it re-creates 2 partitions, but for raspberry pi, you can create those partitions that you need and transfer only 1 partition should be fat.
Like I said, a nice feature. But I'm sure cost mounts, when you buy board, + daughter board + nvme + heatsinks + fan or thermal case + keyboard & mouse.
Quote:
Originally Posted by sndwvs
glibc built with the same options as slackwar64 --enable-kernel=2.6.32
Good. I can update whatever system then.
Quote:
Originally Posted by sndwvs
yes, when transferring, it re-creates 2 partitions, but for raspberry pi, you can create those partitions that you need and transfer only 1 partition should be fat.
It's a good thing I asked, as that would wipe my third partition. A couple of comment lines at the top of the script "This will wipe all existing partitions..." Are you sure? Y/N above the action might help.
I'll drop something on a usb stick instead and rsync it accross. Most of home is Videos, and it's a pain in the proverbials having to drag that ssd about and copy them.
The 5.15.85 image never copied over, so I never got to test it. The 'dd' started going out to lunch @1100 seconds. But as it seems to have the latest versions of stuff (kernel excluded) I should update to that image. I'll have to grok the Changelog in Current as I'm not aware of what's been dropped, and introduced. I'd better mirror current while I'm at it. You're on glibc-2.36. Slackware-15.0 has 2.33.
EDIT: Was there some issue with the 6.0.9 kernel? it seems fine here, although I did hear of booting issues with 6.x.x.
Last edited by business_kid; 12-27-2022 at 08:37 AM.
It's a good thing I asked, as that would wipe my third partition. A couple of comment lines at the top of the script "This will wipe all existing partitions..." Are you sure? Y/N above the action might help.
yes, you need to add
Quote:
Originally Posted by business_kid
It's a good thing I asked, as that would wipe my third partition. A couple of comment lines at the top of the script "This will wipe all existing partitions..." Are you sure? Y/N above the action might help.
Well, I burned an sdcard of the 5.15.85 snapshot from 20221224 on an sdcard, and a usb key. I mirrored the ~current and put that on a third partition. The idea was that I was going to rsync the usb key OS over to my ssd, and add whatever was missing there. But I got an idea how the day was going to go when I ran 'lsblk' and it showed sdb2 mounted on / & sdb1 on /boot.
Your Readme.txt that you attach with the images is wrong, because you've gone over to UUIDs instead of device names. So my Pi mounted the sdcard RO, and then the USB key RW over the sdcard. I searched for entries in /proc and couldn't see them. We have days like this here occasionally where reality is suspended, the weather forecast is 100% wrong, and Murphy's Law with all corollaries & amendments is the Constitution... Yesterday was evidently one of them.
Now the sdcard boots fine; I even got sound out of it. The usb key does likewise, but is horribly slow. Below is a snippet from /var/log/dmesg
Code:
…Dec 28 09:51:00 raspberry-pi-4 kernel: hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
Dec 28 09:51:00 raspberry-pi-4 kernel: MAI: ASoC: error at soc_pcm_prepare on MAI: -22
Dec 28 09:51:00 raspberry-pi-4 kernel: hdmi-audio-codec hdmi-audio-codec.0.auto: Not able to map channels to speakers (-22)
Dec 28 09:51:00 raspberry-pi-4 kernel: hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
Dec 28 09:51:00 raspberry-pi-4 kernel: MAI: ASoC: error at soc_pcm_prepare on MAI: -22
Dec 28 09:51:00 raspberry-pi-4 kernel: hdmi-audio-codec hdmi-audio-codec.0.auto: Not able to map channels to speakers (-22)
Dec 28 09:51:00 raspberry-pi-4 kernel: hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
Dec 28 09:51:00 raspberry-pi-4 kernel: MAI: ASoC: error at soc_pcm_prepare on MAI: -22
Dec 28 09:51:00 raspberry-pi-4 kernel: hdmi-audio-codec hdmi-audio-codec.0.auto: Not able to map channels to speakers (-22)
Dec 28 09:51:00 raspberry-pi-4 kernel: hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
Dec 28 09:51:00 raspberry-pi-4 kernel: MAI: ASoC: error at soc_pcm_prepare on MAI: -22
Dec 28 09:51:00 raspberry-pi-4 kernel: hdmi-audio-codec hdmi-audio-codec.0.auto: Not able to map channels to speakers (-22)
Dec 28 09:51:00 raspberry-pi-4 kernel: hdmi-audio-codec hdmi-audio-codec.0.auto: ASoC: error at snd_soc_pcm_dai_prepare on i2s-hifi: -22
Dec 28 09:51:00 raspberry-pi-4 kernel: MAI: ASoC: error at soc_pcm_prepare on MAI: -22
Dec 28 09:51:00 raspberry-pi-4 pulseaudio[1469]: [pulseaudio] module-alsa-card.c: Failed to find a working profile.
Dec 28 09:51:00 raspberry-pi-4 pulseaudio[1469]: [pulseaudio] module.c: Failed to load module "module-alsa-card" (argument: "device_id="1" name="platform-fef05700.hdmi" card_name="alsa_card.platform-fef05700.hdmi" namereg_fail=false tsched=yes fixed_latency_range=no ignore_dB=no deferred_volume=yes use_ucm=yes avoid_resampling=no card_properties="module-udev-detect.discovered=1""): initialization failed.
Dec 28 09:51:01 raspberry-pi-4 pulseaudio[1469]: [pulseaudio] authkey.c: Failed to open cookie file '/root/.config/pulse/cookie': No such file or directory
Dec 28 09:51:01 raspberry-pi-4 pulseaudio[1469]: [pulseaudio] authkey.c: Failed to load authentication key '/root/.config/pulse/cookie':
No such file or directory
Dec 28 09:51:01 raspberry-pi-4 pulseaudio[1469]: [pulseaudio] authkey.c: Failed to open cookie file '/root/.pulse-cookie': No such file or directory
Dec 28 09:51:01 raspberry-pi-4 pulseaudio[1469]: [pulseaudio] authkey.c: Failed to load authentication key '/root/.pulse-cookie': No such file or directory
Dec 28 09:51:02 raspberry-pi-4 pulseaudio[1469]: [pulseaudio] cli-command.c: stat('/etc/pulse/default.pa.d'): No such file or directory
Dec 28 09:51:02 raspberry-pi-4 pulseaudio[1543]: [pulseaudio] pid.c: Daemon already running.
Dec 28 09:59:42 raspberry-pi-4 pulseaudio[1469]: [pulseaudio] pid.c: Failed to open PID file '/run/user/0/pulse/pid': No such file or directory…
Have a look in syslogs on your Pi, it's all fundamental sound errors. Expect sound complaints. Like I say it gave me sound this time. Previously it didn't.
My SSD has been programmed up, it just needs sorting out. Your sdcard mount options apparently stop the SSD from mounting RW. I removed 'data=writeback,errors=remount,ro' and that seemed to sort it. That also needs to get figured into your 'transfer-to-disk' script. But mercifully, I have sound.
Oh, you still can't get a luser password to stick. Had you not sorted that? You set the user password, everybody goes away happy, and then it gets refused when you try to log in. Slackware-15.0 has gone over to Pam, hasn't it? I have a user 'dec' on my pcs Here's my slackware X86_64 box
Code:
bash-5.1$ grep dec /etc/passwd*
/etc/passwd:dec:$5$c/H2x/txIBl/o.g$XtYyKdJkFP5JOhNR4N3foEcf0U4Jk/UyHxuPQ4TKivA:1000:100::/home/dec:/bin/bash
/etc/passwd-:dec:$5$c/H2x/txIBl/o.g$XtYyKdJkFP5JOhNR4N3foEcf0U4Jk/UyHxuPQ4TKivA:1000:100::/home/dec:/bin/bash
bash-5.1$ grep dec /etc/shadow*
<No Output.>
Now compare that with the Slarm64 output (Which doesn't work).
Code:
grep dec /mnt/dvd/etc/passwd*
/mnt/dvd/etc/passwd:dec:x:1000:100::/home/dec:/bin/bash
/mnt/dvd/etc/passwd-:dec:$5$c/H2x/txIBl/o.g$XtYyKdJkFP5JOhNR4N3foEcf0U4Jk/UyHxuPQ4TKivA:1000:100::/home/dec:/bin/bash
bash-5.1$ grep dec /mnt/dvd/etc/shadow*
/mnt/dvd/etc/shadow:dec:$6$i/qkz4uUyEa9Bivq$Cz096p6KiO2I55jfd8bMGYzr6NDAO3VADmadYfsST36OD97/WKuHEM4rLUl1JTmf/VQZ38Z7tPPKp6YgQnN1x0:19355::::::
I'm not passwords and that end of it much, but maybe you should go figure. I particularly am suspicious of the two different lines in passwd & passwd- on slarm64.
Last edited by business_kid; 12-29-2022 at 10:24 AM.
[ 49.267] (II) LoadModule: "fbdev"
[ 49.267] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
[ 49.267] (EE) Failed to load /usr/lib64/xorg/modules/drivers/fbdev_drv.so: /usr/lib64/xorg/modules/drivers/fbdev_drv.so: undefined symbol: fbdevHWSave
[ 49.267] (EE) Failed to load module "fbdev" (loader failed, 0)
Any ideas for me? It has the feel of some lib not up to date. Do I need to update something? Is it a reportable bug. This thing is probably on some git page somewhere…
Your Readme.txt that you attach with the images is wrong, because you've gone over to UUIDs instead of device names.
the readme.txt is correct, just a different approach.
Quote:
Originally Posted by business_kid
My SSD has been programmed up, it just needs sorting out. Your sdcard mount options apparently stop the SSD from mounting RW. I removed 'data=writeback,errors=remount,ro' and that seemed to sort it. That also needs to get figured into your 'transfer-to-disk' script.
worth adding.
Quote:
Originally Posted by business_kid
Oh, you still can't get a luser password to stick. Had you not sorted that? You set the user password, everybody goes away happy, and then it gets refused when you try to log in.
the password is not set, but the parameter is set to require a password when logging in, but since no one logged into the system, the password was not set.
Your "Transfer-to-disk" script: I have sda1=/boot; sda2=/; sda3=/home, which is the biggest on a 240G SSD. What do I come out with? Will /home be formatted?
there is a warning about deleting data in the script for a long time.
Quote:
Originally Posted by business_kid
That alpha fbdev driver is puking thusly:
Code:
[ 49.267] (II) LoadModule: "fbdev"
[ 49.267] (II) Loading /usr/lib64/xorg/modules/drivers/fbdev_drv.so
[ 49.267] (EE) Failed to load /usr/lib64/xorg/modules/drivers/fbdev_drv.so: /usr/lib64/xorg/modules/drivers/fbdev_drv.so: undefined symbol: fbdevHWSave
[ 49.267] (EE) Failed to load module "fbdev" (loader failed, 0)
this is normal since the configuration is dynamic and the first suitable driver is fbdev, but then the modesetting is loaded with which we then work.
Any ideas for me? It has the feel of some lib not up to date. Do I need to update something? Is it a reportable bug. This thing is probably on some git page somewhere…
if you don't like it add the following 20-device.conf file to /etc/X11/xorg.conf.d
Code:
Section "Device"
Identifier "Default Device"
Driver "modesetting"
Option "AccelMethod" "glamor" ### "glamor" to enable 3D acceleration, "none" to disable.
EndSection
I'm now running the 20221224 image, but with the kernel 6.0.9 on the SSD, and I also have the 5.15.85 kernel on a usb key. Here's where we are:
The error I copied into post#29 in that alpha fbdev driver is a show-stopper. The new fbdev driver is unloaded and the system runs on the inbuilt 'fb' driver = the old driver. Readelf -s shows the fbdevHWSave symbol in the fbdev driver, and the system doesn't have it. Performance is unchanged. Whether I see the error or not matters little. I stuck in your suggested bodge with glamoregl.
Now /usr/lib64/xorg/modules/drivers/fbdev_drv.so is missing the symbol fbdevHWSave. But /usr/lib64/xorg/modules/libfbdevhw.so appears to provide a function called fbdevHWSave. Try
Code:
readelf -a |grep fbdevHWSave
on them both. So it seems that what's called for is to let the fbdev driver know about the library, and I imagine a clever few lines in /etc/X11/xorg.conf.d/10-video.conf might do it, but I'm not inspired to try today. I read about an option for it, but lost the page.
The screen is overscanning badly here, and no amount of adjustment in /boot/config.txt fixes that, unlike with my 5.16.7 setup. I've dispensed with u-boot. It appears to go wrong about the time that / is remounted rw, or just before. Probably it's when the kernel fires up it's inbuilt framebuffer code & sets 1920x1080 again, undoing my config options; but I can't confirm that. I'm just reading the logs. Do I need a kernel framebuffer driver, seeing as we're going to load X over it anyhow? I feel a kernel compile coming on, but I'm game for that. It's just a royal PITA to be having to guess what's on the bottom of screen and move mouse pointers beyond the top left corner to get a menu.
Last edited by business_kid; 12-31-2022 at 12:12 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
But there seems to be an improvement over 5.16.7 in other formats, although I'd have to run comparisons to be sure.
. Mind you, I'm not checking the source to find out.
It also defied sanity by refusing to set screen size. So I can't update it.
Yesterday was evidently one of them.
