Slackware - ARM This forum is for the discussion of Slackware ARM. |
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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
|
 |
|
09-24-2021, 06:16 PM
|
#211
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Rep: 
|
i added the main differences with armbian.
|
|
1 members found this post helpful.
|
09-25-2021, 01:50 AM
|
#212
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Rep: 
|
|
|
1 members found this post helpful.
|
09-25-2021, 10:37 PM
|
#213
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Original Poster
Rep: 
|
Quote:
Originally Posted by sndwvs
|
Hmmm, the problem persists with this new image, no change in behavior at all. I checked both yours and one I built, same story.
I noticed that /etc/NetworkManager/NetworkManager.conf is different in armbian, and there are different files in /etc/NetworkManager/conf.d/ there as well. I copied those over to the slarm64 image, but it made no difference, the behavior was the same.
It must be hardware-specific, because I am not seeing anything like this on my other boards, including the other A64, the SOPine.
Here are the logs from the first boot of your image above, without the USB dongle connected.
https://shelldweller.beauxbead.com/s...ext-mara-logs/
Just for comparison, here are the logs from the slarm64 image with the NetworkManager.conf and conf.d files copied over from armbian (I think the USB dongle was connected that time):
https://shelldweller.beauxbead.com/s...-configs-logs/
It is interesting to note that when the USB dongle is connected, it actually obtains a dhcp lease via dhcpcd, and then goes on to run into problems via NetworkManager, which kills the networking entirely. The first sign of trouble is when NTPD cannot find any servers. So, this must be some default networking config setting clashing with the Pinebook network hardware, somehow? Or maybe something is being set via u-boot? Otherwise, I am not sure what is going on.
Thanks for your help. I will keep poking around to see if I can find any other clues.
|
|
|
10-04-2021, 07:27 PM
|
#214
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Original Poster
Rep: 
|
EUREKA!!!
I finally figured out what was keeping the next kernels from working on the Pinebook. I took a recent next image and hard-rebooted it every time it got stuck until I could finally get to some sort of command prompt. I has been thinking that it is strange that I only see this issue on Pinebook and not on any other boards at all. This led me to think it must be hardware specific, and the clues seemed to indicate networking hardware malfunctioning somehow.
Running lsmod gave me the final clue. There was a module loaded called "8723cs_old", which I had never seen before. I am used to seeing "8723cs" in the list of loaded modules, so I started to wonder what this "old" one is all about. My plan was to just blacklist whatever networking hardware was specific to the Pinebook. Since this was the only obvious one running, I blacklisted the 8723cs_old driver and rebooted. All of the problems went away. And I mean ALL of the problems. Not only does the system boot and reboot reliably now (no longer hanging up when shutting down network interfaces), but I STILL had wifi and bluetooth capabilities, which completely surprised me. One more glance at lsmod shows that, instead of 8723cs_old, there is now the familiar 8723cs module loaded in its place. I have no idea why BOTH are present on the system. Clearly, blacklisting the old one did the trick and is not needed at all, since the non-old one works perfectly.
In addition to all that, it seems like I no longer need the SCALING_GOVERNOR=performance setting. The default ondemand governor worked well, and I even ran it for a while using the conservative governor to see how battery usage changed. Much better, now the battery can last the whole day instead of just a few hours.
While sitting idle on an Xfce desktop, the screen blanked out, and later when I woke it up, it CAME BACK ON! The Pinebook has not been able to do that for quite some time. So, it seems like most of the issues with the legacy kernel that required workarounds are no longer problems at all on the next kernel. I also unblacklisted the lima driver and watched a video full screen for a while, that did not cause any errors either, however those lima crashes can be completely random and unpredictable. So I am not sure if lima still needs to be blacklisted or not. Better safe than sorry perhaps, because it is easy enough to unblacklist if desired on a per-user basis.
The one and only problem I was able to detect is something I noticed on all the other images (Armbian, et al.): the headphone audio jack gets no audio signal at all. I can get sound to come out of the internal speakers, and audio over bluetooth works as expected. But when I plug in analog headphones, nothing happens. The sound keeps coming out of the speakers, no matter what I change in alsamixer. I am tempted to think that this has to do with the fact that the audio jack doubles as a serial console port. Its almost like it is stuck in serial console mode. I have not tried yet, but maybe flipping the hardware switch to the other position will cause the audio to work. Or, maybe fiddling with alsa and/or pulseaudio settings will work. Or maybe using pipewire in place of pulseaudio might fix things. In any case, troubleshooting the audio jack issue is less annoying than the laundry-list of problems that were cropping up before I blacklisted the right module.
So, in summary, here are a few changes I propose for the Pinebook images:
- Blacklist 8723cs_old, either instead of or in addition to lima. This will not cause problems with the legacy kernel since that module is not present there anyway.
- Remove the SCALING_GOVERNOR=performance setting. Or should we leave this for legacy and manually change it on the next images? I am tempted to just forget about legacy now, for this very reason. I noticed the same problem on SOPine, so this might be related to the A64 processor specifically.
- While testing the lima driver, I could not get mpv to launch. It needed (but could not find) vid.stab and openal-soft. If both of those packages are added to the desktop images, then mpv will work out of the box, so to speak.
- While watching the video, I tried to change the volume, but pavucontrol would not launch until I installed json-glib. That one should also be added to the desktop images.
Anyway, thanks for helping me figure this out, I really appreciate your patience and guidance. I have probably learned more trying to get this Pinebook to work than I have from any other single computer I have ever owned. I am confident now that, if/when a stable "slarm64-15.0" is released, I can have a Pinebook image with an up-to-date kernel as part of the offering. Super cool. Thanks again.
|
|
|
10-05-2021, 01:20 PM
|
#215
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Rep: 
|
shelldweller thanks,
added your comments.
|
|
1 members found this post helpful.
|
10-06-2021, 06:10 PM
|
#216
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Original Poster
Rep: 
|
Quick update: After some extended testing, the desktop started freezing on me, but I could still switch over to other consoles with Ctl-Alt-F2, etc. So, I blacklisted lima to see if that could be the problem. It definitely was. The freeze was reproducible and predictable (start an upload and try switch to another workspace, and the display would freeze). I tried that same sequence after blacklisting lima, and now it is acting like it used to.
So, the fix was easy, just blacklist lima, problem solved. I just wanted to report that here, FYI.
Thanks again.
|
|
|
10-08-2021, 10:07 PM
|
#217
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Original Poster
Rep: 
|
Here are two more. Not really fixes, more like tweaks.
This one makes the trackpad more stable:
https://slarmboards.3space.xyz/mods/....touchpad.conf
This one sets the keyboard to the correct mapping:
https://slarmboards.3space.xyz/mods/00-keyboard.conf
I think I got the first one from a recent Kali image, and the second from Manjaro I believe. I put them into:
images_build_kit/system/overall/slackware/etc/X11/xorg.conf.d/
and built some fresh images with those in place, plus the two modules blacklisted. Might be the best Pinebook images yet...
thanks as always.
|
|
|
10-08-2021, 11:46 PM
|
#218
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Rep: 
|
thanks shelldweller,
added your settings.
|
|
1 members found this post helpful.
|
10-10-2021, 07:31 PM
|
#219
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Original Poster
Rep: 
|
One more patch... I got the idea for this one from here:
https://forum.armbian.com/topic/1584...sound-problem/
I finally learned out to make patches using git. This one fixes the analog audio output through the 3.5mm jack on the Pinebook:
https://slarmboards.3space.xyz/mods/...jack-fix.patch
I put it into images_build_kit/patch/u-boot/sun8i/. It patches the *.dts file for the Pinebook. The result is independent control of the internal speakers and the analog audio headphone jack. You can independently turn on one, both, or neither, using alsamixer. Previously, no sound would come through headphones no matter what was done in alsamixer, as described in the thread above.
This may also be needed for the SOPine/Baseboard combo. I will test that soon, since the patch is board-specific.
This solves the last remaining problem that I am aware of on the Pinebook. Further testing may reveal more issues, but for now every issue I was focusing on has been solved.
|
|
|
10-11-2021, 12:01 PM
|
#220
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Rep: 
|
Quote:
Originally Posted by shelldweller
One more patch... I got the idea for this one from here:
https://forum.armbian.com/topic/1584...sound-problem/
I finally learned out to make patches using git. This one fixes the analog audio output through the 3.5mm jack on the Pinebook:
https://slarmboards.3space.xyz/mods/...jack-fix.patch
I put it into images_build_kit/patch/u-boot/sun8i/. It patches the *.dts file for the Pinebook. The result is independent control of the internal speakers and the analog audio headphone jack. You can independently turn on one, both, or neither, using alsamixer. Previously, no sound would come through headphones no matter what was done in alsamixer, as described in the thread above.
This may also be needed for the SOPine/Baseboard combo. I will test that soon, since the patch is board-specific.
This solves the last remaining problem that I am aware of on the Pinebook. Further testing may reveal more issues, but for now every issue I was focusing on has been solved.
|
From the post, I realized that Headphone is muted by default, and is it enough to enable it?
Quote:
@Levent Erenler
please unmute your muted (MM) Headphone.
Select Headphone and press M to unmute (00 in green) your Headphone-Connector in the alsamixer to get analog-audio
|
|
|
1 members found this post helpful.
|
10-11-2021, 01:54 PM
|
#221
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Original Poster
Rep: 
|
Quote:
Originally Posted by sndwvs
From the post, I realized that Headphone is muted by default, and is it enough to enable it?
|
Nope. That is not my original post, by the way, just someone else that had a similar problem and a solution. I am not muted here at all.
Without this patch, I literally went through alsamixer and unmuted every single channel. I did same with pulseaudio volume control. I toggled every setting I could find. No sound would come through the headphones no matter what settings I tried, muted, unmuted, etc.
FWIW, I noticed the same thing on Armbian/Kali/Manjaro. Anyone with a kernel past 5.9.y or so has this problem on the Pinebook, across the board. The internal speakers work fine, and bluetooth audio works fine, but the headphone jack gives absolutely nothing. I have tried everything I could.
Before the patch, the Headphones channel in alsamixer controls the internal speakers and seemed to be linked to the Line Out channel. Both have to be unmuted for the internal speakers to work.
After the patch, the Headphones channel controls the headphones, as desired. The internal speaker is separately controllable by the Line Out channel. I can have sound coming through one, both, or neither, all by muting the Line Out and/or the Headphones channels in alsamixer. I am pretty sure this is the desired behavior. At least for me it is. This was the default behavior before kernel 5.10.y. It changed when I moved to the next kernel.
I suppose there is a way to have the internal speakers mute automatically when the headphones are plugged in, like it would on a smartphone. I am not sure how to do that without a script of some sort. As for now, I prefer to be able to control the internal speakers and headphones separately anyway.
Besides, if you read the entire Armbian thread all the way down, unmuting did NOT solve the original posters problem. He had to either recompile the dts file or else use a sound overlay to achieve the same result. That was his only solution, and it worked for another user with the same issue at the bottom of the thread. I figured I could try the same thing on Pinebook, and it worked. Same symptoms, same solution, not a huge surprise since the two boards are related.
|
|
|
10-11-2021, 02:41 PM
|
#222
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Rep: 
|
thanks, added this patch.
|
|
1 members found this post helpful.
|
10-13-2021, 01:14 PM
|
#223
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Original Poster
Rep: 
|
better patch
Quote:
Originally Posted by sndwvs
thanks, added this patch.
|
Thank you, I appreciate that one more than usual. I made a small mistake with that patch, more on that later....
I did some more research to make sure I knew what I was talking about. The different distros have inconsistent audio jack behavior:
1) Armbian has NO audio out of the analog jack AT ALL, regardless of ANY settings in alsamixer or pulseaudio. This was the old slarm64-next behavior before the patch. Toggling every setting and umuting everything sends absolutely nothing to the headphone jack. I cannot believe this is desired behavior, just how the latest kernels react to this hardware, I suppose. I did not look at the dtb/dts file since this is undesired behavior.
2) Both Kali and Manjaro have really odd behavior: Sound comes out of the headphones if "A1F1" and "Headphones" are both unmuted. Sound from the internal speakers can be controlled using "Line Out" as long as the first two are also unmuted. However, if "Headphones" is muted, then the internal speakers are also muted, even if "Line Out" and "A1F1" are both unmuted. So, it is possible to have headphones working with the internal speakers muted, but not vice versa. If headphones are muted, then the internal speaker is automatically muted. The only way to have speakers but not headphones is to turn the headphone volume down all the way (which oddly does not affect the internal speaker volume as mute does), or unplug the cable (which is obvious and not really a solution). This is how slarm64-next acts after the correct patches are applied.
I decompiled the Manjaro dtb file into a dts file. Oddly, the "Headphone" lines are present there, so they must be achieving the same results in a different way.
https://slarmboards.3space.xyz/mods/...4-pinebook.dts
The real bummer is that the audio is not in stereo in case 2), it is a mixed mono in both channels. So if I run speaker-test -c 2, I get sound out of both ears all the time, which is NOT the case with the internal speakers. I could be wrong, but I remember getting true stereo out of the audio jack with the 5.4.y kernel (despite all the other issues with that kernel, at least the sound worked as intended). I should test that again, just to verify.
Now, about the patch. I did the test run by patching the dts file in both the u-boot and linux-next repositories. The patch I gave you only patches u-boot. I was under the assumption that linux-next was getting the patched dts file from the u-boot repository, but I was wrong. Each repository has its own independent dts file. I made images with both patches in place and they work as in case 2) above (better than nothing). I also updated an image with only the kernel packages but did NOT flash the new boot files. The audio still works as intended. This makes me think that maybe only the kernel patch is needed, and not the u-boot patch (even though they both make the same change to the same file in each repository). Do you think both patches should be applied to keep the two dts files in sync?
Here is the kernel-repo dts patch, which does what the other patch I gave you fails to do by itself (sorry about that).
https://slarmboards.3space.xyz/mods/...x-kernel.patch
Anyway, this might all change with the next kernel version bump anyway. But at least I have a better idea of what is going on.
In the meantime, if I want decent audio out from this device, I need to use HDMI audio (untested, I am not set up for that anyway), or bluetooth audio, which I have in abundance, although I prefer good ol' analog wires when I can get away with them.
Thanks again for reading my exploratory analysis.
|
|
|
10-13-2021, 01:59 PM
|
#224
|
Senior Member
Registered: Aug 2014
Posts: 2,123
Rep: 
|
shelldweller thanks for the work you've done, added patch.
|
|
1 members found this post helpful.
|
10-26-2021, 10:03 AM
|
#225
|
Member
Registered: Mar 2019
Distribution: Slackware
Posts: 302
Original Poster
Rep: 
|
Quote:
Originally Posted by shelldweller
Remove the SCALING_GOVERNOR=performance setting. Or should we leave this for legacy and manually change it on the next images? I am tempted to just forget about legacy now, for this very reason. I noticed the same problem on SOPine, so this might be related to the A64 processor specifically.
|
I am glad this was not changed. I started to notice the same problem cropping up with the next kernel, just not immediately. I have devised a simple test that will bring out the issue almost instantly. Just get any video playing in mpv or MPlayer, and then open the homepage of ebay.com in any browser. At this point, unless you have set the SCALING_GOVERNOR to either performance, schedutil, or powersave, it will just crawl to a halt and you will not be able to close windows or even shut down without a hard power off.
I found some more details on Github issue for Olimex:
https://github.com/OLIMEX/olimage/issues/7
specifically this part:
Quote:
unfortunately, due to a workaround for allwiner's a64 timer instability, we can only reliably support performance and powersave governors. using any other governor may render the board very unstable (all cores at 100%)
however, you should be able to set performance governors max frequency manualy.
schedutil governor is also enabled in defconfig but we prefer not forcing it as default for now.
|
and...
This makes perfect sense with what I have been noticing with the Pinebook. I have been testing out all the available governors using the test mentioned previously, and I can verify that the only three that work with the A64 processor are performance, powersave, and schedutil.
Performance sucks the battery very quickly but at least you get full performance out of the chip.
Powersave maximizes battery life and supposedly runs the processor at the lowest frequency, but I hardly noticed a difference in userspace, honestly. Browsers still loaded fine, I could even watch full screen videos, etc. I had to run CPU benchmark tests (nbench) to notice a difference. I have switched to this one for my own machine and builds, since the Pinebook has a battery. Anyone wanting to set CPU benchmark records will have to switch to the faster governor manually as root. Otherwise, the speed loss is hardly noticeable. I mean, nothing is as bad as slowly crawling to a full lock up anyway.
Schedutil might not be working as intended, but at least it does not cause the CPU to lock up. It seems to cause the CPU to hover around 900MHz, which is a nice middle range, but it never seems to go all the way to the highest or lowest frequencies. So, it works as a good middle ground between the other two, but is not as fully dynamic as it is probably intended to be.
I just wanted to put this here in case anyone else runs into the same problem. Pick one off those three governors, leave the others alone, and you should not have any CPU issues on the Pinebook.
Same goes for the SOPine. I will probably build some of those with the slower governor just to avoid overheating issues.
I am not sure what the best default would be. Some people want maximum performance, others want to minimize power consumption. Any advanced user would be able to change these on the fly anyway, so it is probably not a big deal, as long as they stick to these three governor choices.
Thanks for reading.
|
|
|
All times are GMT -5. The time now is 07:40 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.
|
Latest Threads
LQ News
|
|