[SOLVED] Slarm64 on the Pinebook 1080 - help with kernel?
Slackware - ARMThis 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.
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.
1) The fix is dependent on the a/cpufrequtils package. Can we make this part of the base image in the build script? I personally would appreciate that very much.
2) Once that package is installed, there are several methods of getting the CPU to run at a sane speed. These include, but are not limited to:
a) add the line SCALING_GOVERNOR=performance to the file /etc/default/cpufreq (this seems to be the ideal method)
b) change the line SCALING_GOVERNOR=ondemand to say instead SCALING_GOVERNOR=performance in /etc/rc.d/rc.cupfreq (this seems to kick in a bit sooner in the boot sequence, but that may be an illusion)
c) Change the default CPU_SCALING= setting in the kernel config file before building the kernel and then make /etc/rc.d/rc.cpufreq non-executable (this was an attempt to work around the missing package, but it did not work quite like I thought it would, although the boot sequence seems to be the fastest this way).
In any case, one of the above is needed for the Pinebook image to be usable. I was going to submit a working commit via git, but I was not sure which was the best route for the build script. One approach was to modify /etc/default/cpufreq using /tmp/firstboot. So far, this has been my go-to method.
Everything is just there are standard settings in the distribution kit and we will use them, added the GOVERNOR setting for pinebook.
Quote:
Originally Posted by shelldweller
I was trying to make a new Pinebook image with the updated 10/23 rootfs and the 5.8.16 kernel since that is the only kernel available for the Pinebook so far that incorporates the "Bleeding Tooth" vulnerability patch, and I ran into a few issues. Neither of the images has the cpufrequtils package as part of the initial setup, so that would be a much welcomed addition to both images. Also, the xfce image does not seem to get to the login screen. It seems to go into a death spiral once Xorg starts, for some reason. This got me thinking about the xfce image in general...
I do not think that updating the kernel 5.8.15 to 16 broke something.
Most likely (since slarm64-current keeps up with the original distribution and packages are constantly updated) the problem is in the libraries, you need to look at /var/log/Xorg.0.log
Quote:
Originally Posted by shelldweller
What is the intended purpose for this image? Why does it start Xorg as root by default? Isn't that a big no-no? Shouldn't the new user script be run so that a non-root user can be selected for the Xfce session? Just curious...
It is understood that the user himself knows what to do, remain root or create a separate user. For this, distribution methods are used to further customize the system according to your opinion.
Quote:
Originally Posted by shelldweller
In any case, it has me wanting a third image build option, in addition to "base" and "xfce". I would like to see a "full" option, or at least a "full minus kde" option. Sure, the resulting image would be big, but I wind up installing most of that soon after anyway. Maybe we could leave out packages that would never get used, like grub and lilo just as examples off the top of my head.
Frankly, I don't see any sense in this, since there are convenient tools for installing the ap,kde,l series of packages, and so far slackpkg handles this.
Quote:
Originally Posted by shelldweller
Oh, and don't change the run level
it is changed because the xfce image is designed to work with an X server.
Quote:
Originally Posted by shelldweller
Oh, and one last thing, I have been bumping the version of Sunxi-tools from 1.2 to 1.4. Is there any reason to leave it at 1.2? Just curious.
At one time above version 1.2 sunxi-tools on arm x32 was not compiled.
Thanks, old version in packages, updated.
Everything is just there are standard settings in the distribution kit and we will use them, added the GOVERNOR setting for pinebook.
Understood. I appreciate sticking with the upstream defaults as much as possible. I was just trying things out to get the pinebook image to work "out of the box", so to speak. Those were more "notes for myself" than wishes or commands. I refer back to this thread often.
Quote:
Originally Posted by sndwvs
I do not think that updating the kernel 5.8.15 to 16 broke something.
Ah, I did not mean to imply that it started with the change to 5.8.16, this has been going on for some time. I was just too lazy/busy to investigate further. I think I figured it out though, see below for the test image results...
Quote:
Originally Posted by sndwvs
It is understood that the user himself knows what to do, remain root or create a separate user. For this, distribution methods are used to further customize the system according to your opinion.
I could not agree more with this statement, no argument here at all.
Quote:
Originally Posted by sndwvs
Frankly, I don't see any sense in this, since there are convenient tools for installing the ap,kde,l series of packages, and so far slackpkg handles this.
True, I see your point, but that argument could also be made for the Xfce packages....
Quote:
Originally Posted by sndwvs
it is changed because the xfce image is designed to work with an X server.
Yes, but it is not like that even in a full x86 installation. The run level stays at the console unless the user changes it, regardless of what window managers are installed. Normally, I would not have a problem with this, since I can just open another virtual console and create a non-root user from there before logging in to Xorg. However, in this case, I am not able to do that because the Xorg loop prevents me from doing anything. In any case, I might have figured that one out...
I did a bunch of builds after you added a/cpufrequtils and tested each one. Here is what I found:
Before the latest kernel update (@5.8.16)
"base" works flawlessly, no sluggishness, no problems at all. This is a great image!
"xfce" goes into the Xorg loop, and it seems to be because of fbturbo, at least that is what I can figure from the Xorg.0.log.
After the latest kernel update (@5.8.17)
Nothing happens on either "base" or "xfce" after u-boot. It seems like 5.8.17 does not load at all. No logs generated, no swapfile created, just blank deadness, although the images build fine without errors.
Legacy kernel after the BT patch (@5.6.19)
the build fails during the kernel compilation, with no apparent errors:
Code:
LD [M] drivers/media/usb/gspca/gspca_stv0680.o
LD [M] drivers/media/usb/gspca/gspca_t613.o
LD [M] drivers/media/usb/gspca/gspca_topro.o
LD [M] drivers/media/usb/gspca/gspca_touptek.o
LD [M] drivers/media/usb/gspca/gspca_tv8532.o
LD [M] drivers/media/usb/gspca/gspca_vicam.o
CC [M] drivers/media/usb/pwc/pwc-if.o
CC [M] drivers/media/usb/stk1160/stk1160-core.o
LD [M] drivers/media/usb/pvrusb2/pvrusb2.o
CC [M] drivers/media/usb/pwc/pwc-misc.o
CC [M] drivers/media/usb/tm6000/tm6000-cards.o
CC [M] drivers/media/usb/tm6000/tm6000-core.o
CC [M] drivers/media/usb/stk1160/stk1160-v4l.o
CC [M] drivers/media/usb/tm6000/tm6000-i2c.o
LD [M] drivers/media/usb/gspca/gspca_vc032x.o
LD [M] drivers/media/usb/gspca/gspca_xirlink_cit.o
LD [M] drivers/media/usb/gspca/gspca_zc3xx.o
CC [M] drivers/media/usb/stk1160/stk1160-video.o
CC [M] drivers/media/usb/stk1160/stk1160-i2c.o
CC [M] drivers/media/usb/pwc/pwc-ctrl.o
CC [M] drivers/media/usb/stk1160/stk1160-ac97.o
CC [M] drivers/media/usb/pwc/pwc-v4l.o
CC [M] drivers/media/usb/tm6000/tm6000-video.o
CC [M] drivers/media/usb/tm6000/tm6000-stds.o
CC [M] drivers/media/usb/pwc/pwc-uncompress.o
CC [M] drivers/media/usb/pwc/pwc-dec1.o
LD [M] drivers/media/usb/stk1160/stk1160.o
CC [M] drivers/media/usb/usbtv/usbtv-core.o
CC [M] drivers/media/usb/tm6000/tm6000-input.o
CC [M] drivers/media/usb/pwc/pwc-dec23.o
CC [M] drivers/media/usb/pwc/pwc-kiara.o
CC [M] drivers/media/usb/pwc/pwc-timon.o
CC [M] drivers/media/usb/usbtv/usbtv-video.o
CC [M] drivers/media/usb/tm6000/tm6000-alsa.o
CC [M] drivers/media/usb/tm6000/tm6000-dvb.o
CC [M] drivers/media/usb/usbtv/usbtv-audio.o
LD [M] drivers/media/usb/pwc/pwc.o
CC [M] drivers/media/usb/usbvision/usbvision-core.o
CC [M] drivers/media/usb/uvc/uvc_driver.o
CC [M] drivers/media/usb/uvc/uvc_queue.o
LD [M] drivers/media/usb/tm6000/tm6000.o
CC [M] drivers/media/usb/uvc/uvc_v4l2.o
AR drivers/media/usb/built-in.a
CC [M] drivers/media/usb/uvc/uvc_video.o
LD [M] drivers/media/usb/usbtv/usbtv.o
CC [M] drivers/media/usb/uvc/uvc_ctrl.o
CC [M] drivers/media/usb/uvc/uvc_status.o
CC [M] drivers/media/usb/uvc/uvc_isight.o
CC [M] drivers/media/usb/uvc/uvc_debugfs.o
CC [M] drivers/media/usb/uvc/uvc_metadata.o
CC [M] drivers/media/usb/uvc/uvc_entity.o
CC [M] drivers/media/usb/usbvision/usbvision-video.o
CC [M] drivers/media/usb/usbvision/usbvision-i2c.o
CC [M] drivers/media/usb/usbvision/usbvision-cards.o
LD [M] drivers/media/usb/uvc/uvcvideo.o
LD [M] drivers/media/usb/usbvision/usbvision.o
AR drivers/media/built-in.a
AR drivers/built-in.a
|err | details /pro/pineslarm/pinebook-fixed/build/source/build.log
Here is the full build.log if you want to look further up the message chain.
The last time something like this happened, it had something to do with WIREGUARD not being set in the config. Maybe this is something similar? Just a guess.
In any case, if I can get the 5.6.19 kernel with the BT patch to build, I am tempted to put out a "stable" image for the pinebook based on that and then leave it alone for a while, at least until the next LTS kernel matures a bit, or I get more spare time somehow.
"base" works flawlessly, no sluggishness, no problems at all. This is a great image!
"xfce" goes into the Xorg loop, and it seems to be because of fbturbo, at least that is what I can figure from the Xorg.0.log.
rebuilt xf86-video-fbturbo-20151007_f9a6ed7-aarch64-1mara.txz, you need to see if it helped or not.
Quote:
Originally Posted by shelldweller
Legacy kernel after the BT patch (@5.6.19)
the build fails during the kernel compilation, with no apparent errors...
Here is the full build.log if you want to look further up the message chain.
The last time something like this happened, it had something to do with WIREGUARD not being set in the config. Maybe this is something similar? Just a guess.
I looked at what the problem was, I adapted the patch from the 5.8.y kernel (it has a slightly different structure), changed it to a patch from 5.4.y (patch-5.4.71-72)
Very cool. I built these myself before I checked in here. Both of my images work fine, no adjustments were needed. The CPUFREQ issue was never present on the older kernels, and even the Xorg-death-loop is not present on this Xfce image for whatever reason. From what I can tell, all the recent bugs are missing from these. I will test yours as well, but I suspect they also work as expected.
This is a definite milestone. Thank you a million for all you did to get to this point. I am considering these the latest "stable" release for slarm64 on pinebook a64. I am hosting my own images, but I bet they are basically identical to yours in any case:
After a bit of testing, I have run into an interesting omission from the 5.6.19 kernel modules (or something along those lines). I am not sure if this is related to the BT patch, but I have no Wi-Fi at all on this image. I am a bit embarrassed to admit I did not notice this sooner (I usually use an ethernet-USB-converter).
What is strange is that Bluetooth seems to work, but I get no wlan0 interface at all, even if I plug in an external WiFi dongle that has been known to work in the past.
I tried the 5.9.3 kernel packages you provided to see if there was any difference, but those still do not boot past u-boot.
On the 5.6.19 modules, there is no 8723cs module listed at all.
Code:
bash-5.0# modprobe 8723cs
modprobe: FATAL: Module 8723cs not found in directory /lib/modules/5.6.19
So far, the only other thing I noticed (might be an upstream thing) is that seamonkey needs to be rebuilt against the new icu4c (maybe?):
Code:
bash-5.0$ seamonkey
XPCOMGlueLoad error for file /usr/lib64/seamonkey/libxul.so:
libicui18n.so.67: cannot open shared object file: No such file or directory
Couldn't load XPCOM.
Although I know there is waning interest in Seamonkey. Some have mentioned dropping it. I use it as an alternative browser quite often, but I could find something else for that use case if I had to. Just something I thought worthy of a mention.
After a bit of testing, I have run into an interesting omission from the 5.6.19 kernel modules (or something along those lines). I am not sure if this is related to the BT patch, but I have no Wi-Fi at all on this image. I am a bit embarrassed to admit I did not notice this sooner (I usually use an ethernet-USB-converter).
What is strange is that Bluetooth seems to work, but I get no wlan0 interface at all, even if I plug in an external WiFi dongle that has been known to work in the past.
added a patch for WIFI 8723cs, and compile kernel, please testing.
So far, the only other thing I noticed (might be an upstream thing) is that seamonkey needs to be rebuilt against the new icu4c (maybe?):
Code:
bash-5.0$ seamonkey
XPCOMGlueLoad error for file /usr/lib64/seamonkey/libxul.so:
libicui18n.so.67: cannot open shared object file: No such file or directory
Couldn't load XPCOM.
Although I know there is waning interest in Seamonkey. Some have mentioned dropping it. I use it as an alternative browser quite often, but I could find something else for that use case if I had to. Just something I thought worthy of a mention.
added a patch for WIFI 8723cs, and compile kernel, please testing.
Okay, interesting. This is better, but still strange. I upgraded to these kernels, and now I can see Wi-Fi networks, but I cannot connect to anything because I do not have permission, or so says the pop-up error message. In the network manager applet, the options to turn on/off networking and on/off wi-fi are greyed out. I logged in as root, connected to my Wi-Fi network, and the entire system locked up. So, I can now see Wi-Fi, but connecting either is impossible or catastrophic.
UPDATE: I tried an SD image that I built last night (rather than just upgrading kernels on my pinebook), and that image does NOT have the problem. So it must be something wrong with my setup and not the kernel. Thus the latest legacy image seems to work, expect an upload soon....
Quote:
Originally Posted by sndwvs
I recompiled the seamonkey
Cool thanks. Tested and working.
Last edited by shelldweller; 11-06-2020 at 10:08 AM.
Reason: checked sd image
I have been testing these, and so far I may have noticed some unusual Xorg behavior, but it is not quite reproducible yet, so I will keep testing. I suggest anyone that uses these test them thoroughly.
I finally have some spare time again, yay! Also, I get the sense that upstream x86 is getting close to a release-candidate for 15.0, like in another month or two maybe. Anyway, I have been trying out a few of the next kernels for Pinebook-A64, and so far none of them complete building the kernel. Most recently, one of the patches failed, and it stops here without any other errors or warnings:
Code:
[...]
CC [M] drivers/iio/light/tsl2772.o
CC [M] drivers/iio/industrialio-trigger.o
CC [M] drivers/iio/industrialio-configfs.o
CC [M] drivers/iio/industrialio-sw-device.o
CC [M] drivers/iio/light/tsl4531.o
CC [M] drivers/iio/industrialio-sw-trigger.o
CC [M] drivers/iio/industrialio-triggered-event.o
LD [M] drivers/iio/industrialio.o
CC [M] drivers/iio/light/us5182d.o
CC [M] drivers/iio/light/vcnl4000.o
CC [M] drivers/iio/light/vcnl4035.o
CC [M] drivers/iio/light/veml6030.o
CC [M] drivers/iio/light/veml6070.o
CC [M] drivers/iio/light/vl6180.o
CC [M] drivers/iio/light/zopt2201.o
Think this would be worth upgrading to 5.10.y? I am happy to test on my end. In any case, thanks for all of your hard work, as always.
Cool, thanks for these, I will try them. I built some on my own machine, and they did not boot past u-boot. No kernel messages, no logs were created, no swapfile, sd card was not resized, etc... that is usually what happens when the kernel just does not boot for whatever reason.
Maybe yours are better than mine, I will give them a try. I also have the UART module now, so I can get that set up and see if I get any output that way.
You probably already know about this one, but just in case you have not seen it yet, u-boot has been complaining about missing external blobs after the latest several git pulls:
Code:
OBJCOPY spl/u-boot-spl-nodtb.bin
SYM spl/u-boot-spl.sym
COPY spl/u-boot-spl.bin
MKSUNXI spl/sunxi-spl.bin
BINMAN all
Image 'main-section' is missing external blobs and is non-functional: scp
/binman/u-boot-sunxi-with-spl/fit/images/scp/scp:
SCP firmware is required for system suspend, but is otherwise optional.
Please read the section on SCP firmware in board/sunxi/README.sunxi64
Some images are invalid
/home/krt/projects/pineslarm/pinebook-next/build/source/u-boot /home/krt/projects/pineslarm/pinebook-next/build/source/u-boot
install: cannot stat 'u-boot.itb': No such file or directory
In any case, the images I downloaded from your site had the same non-booting kernel issue as mine. Seems to be a common theme on this Pinebook..
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
