[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.
Yeah, I see your point. I am not sure why I was having a different result after that commit. I am trying again now, but using only the legacy kernel. I have gotten past that commit without the black screen issue, so I was mistaken somehow. I will see how far up the commit chain I can get using the legacy kernel before the black-screen issue manifests.
I do know that if I overwrite the u-boot files (both are necessary) from a working image to a recent image, the black-screen issue goes away, so it seems to be u-boot related.
I also just received my UART module from Pine64. If/when I run into that black-screen problem again, I will try to generate some serial console output if I can.
Thanks, sorry for the previous mistake, and the search continues....
I do know that if I overwrite the u-boot files (both are necessary) from a working image to a recent image, the black-screen issue goes away, so it seems to be u-boot related.
Thanks, I will try to analyze the u-boot assembly for errors.
I worked my way up the commit chain more carefully this time, only using the legacy kernel for each build. The breaking point seems to make more sense now, but there are a lot of changes at the broken commit, so I am not sure how to narrow it down further. Here is what found this time:
Commit e3e6b96f "broadcom: config.txt update gpu driver name vc4-kms-v3d -> vc4-fkms-v3d. xorg 1.20.9 crashed due to an error" boots fine, although it has the sluggish cpu governor thing going on, but I can fix that later.
then, the very next one...
Commit 0b286560 "allwinner: update legacy kernel 5.4.62->63 and mainline kernel 5.8.6->7" is where things go wrong somehow. No screen output after u-boot. No logging occurs either, so it never gets past u-boot.
I had to apply the wireguard fix from 39e73a66 to get it to build all of the way, but other than that, it seems like something goes bad with the kernel config setting here, maybe.
I have the same sort of problem from that point forward. I can try the same breaking point using the mainline kernel. Although, I wanted to try the Rock64 fix you suggested on the other thread first, so I am going to let this one sit for a few days before I come back to it. I have more recent image with the same problem, I will check it to see if logs are generated on that one.
Yes, I was mistaken when I thought it was u-boot related. I was not able to reproduce the fix by copying an old u-boot. I must have gotten my images switched out by mistake when I thought that was the case.
Your image here shows the same problem as the others. U-boot works fine, and the system actually boots, creates a swap, and creates some system logs, but nothing shows up on screen after u-boot loads the kernel/initrd. Oh, removing initrd does not change anything either, I tried that, thanks for that suggestion.
I saved some logs from this image that you provided:
Let me know if any other log files would be helpful, these are the main three I usually look at. I am going to generate some logs for a non-modified latest mainline image, as well as for my last working image. I will try both mainline and legacy kernels, to see if they both have the same problem at the same commit.
BINGO! That is literally the best Pinebook image I have seen since March. Well done!
The boot process is very fast, everything outputs to the LCD, and there is not a hint of that cpufreq sluggishness.
I would call this an official Pinebook 1080P release. It is that good. I will continue to test it, but so far it has none of the issues I have been seeing since last March.
Quote:
Originally Posted by sndwvs
for kernels 5.8.y I watch patches regarding LCD all changes and the screen should work.
Wow, cool, I learn something new every day. Had not seen that one yet, thanks!
So, is it kernel-specific? Because I was having issues with 5.4.y as well, but not in the same places in the commit history. I could get farther in the log on the legacy branch, and had to roll it back much further on the mainline branch to get a booting image.
5.5.y worked fine last March, and now 5.6.y works even better it seems.
In any case, this new image seems to be great. Thanks for working on this, I really appreciate it now that I have less spare time. (my workload has increased significantly, I tend to have more downtime in the summer, just FYI).
So, is it kernel-specific? Because I was having issues with 5.4.y as well, but not in the same places in the commit history. I could get farther in the log on the legacy branch, and had to roll it back much further on the mainline branch to get a booting image.
yes, driver problem and device tree.
nice to hear, then we'll do so, leave version 5.6.19 as an outdated kernel, and develop the next one according to the kernel releases.
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.
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...
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...
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.
Personally, I would like to see an image that builds with all of the package sets installed with the possible exceptions of the K, KDE, and KDEI package sets. It would be nice to have that option, at least. Oh, and don't change the run level. I would like to be as close to a fresh full install of x86 versions of Slackware given the platform.
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.
Anyway, just some stuff I have been thinking about in my limited spare time. Your work is much appreciated, as always.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.