LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 09-16-2020, 10:09 AM   #121
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled

shelldweller, thanks for the info.
Launching from root does not affect how simply when copying system files, root rights are now installed on them.
 
Old 09-21-2020, 07:53 PM   #122
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
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....
 
Old 09-22-2020, 01:14 PM   #123
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
Quote:
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.
 
Old 09-24-2020, 11:55 AM   #124
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
the bootloader is the same size as the last working one.
 
Old 09-26-2020, 08:30 PM   #125
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
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.

thanks, more later....
 
Old 09-27-2020, 05:58 AM   #126
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
As I understand it, u-boot is always loaded, but the system does not always boot?
i used a different kernel config for pinebook:
slarm64-current-aarch64-base-rootfs-20200901-5.8.11-pinebook-build-20200927.img.zst
slarm64-current-aarch64-base-rootfs-20200901-5.8.11-pinebook-build-20200927.img.zst.md5
 
1 members found this post helpful.
Old 09-27-2020, 12:58 PM   #127
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
As I understand it, u-boot is always loaded, but the system does not always boot?
i used a different kernel config for pinebook:
slarm64-current-aarch64-base-rootfs-20200901-5.8.11-pinebook-build-20200927.img.zst
slarm64-current-aarch64-base-rootfs-20200901-5.8.11-pinebook-build-20200927.img.zst.md5
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:

dmesg
syslog
messages

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.

Thanks for looking into this.
 
Old 10-01-2020, 02:11 PM   #129
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
for kernels 5.8.y I watch patches regarding LCD all changes and the screen should work.
 
1 members found this post helpful.
Old 10-01-2020, 09:59 PM   #130
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
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 View Post
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).
 
1 members found this post helpful.
Old 10-02-2020, 12:07 PM   #131
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
Quote:
Originally Posted by shelldweller View Post
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.

updated images:
slarm64-current-aarch64-base-rootfs-20200901-5.6.19-pinebook-build-20201002.img.zst
slarm64-current-aarch64-base-rootfs-20200901-5.6.19-pinebook-build-20201002.img.zst.md5
slarm64-current-aarch64-xfce-rootfs-20200901-5.6.19-pinebook-build-20201002.img.zst
slarm64-current-aarch64-xfce-rootfs-20200901-5.6.19-pinebook-build-20201002.img.zst.md5

kernel 5.6.19 README.TXT

Last edited by sndwvs; 10-02-2020 at 12:11 PM.
 
1 members found this post helpful.
Old 10-03-2020, 04:59 AM   #132
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
taken from the mainstream kernel source, leaving only patches for the A64 and pinebook. please check.
slarm64-current-aarch64-base-rootfs-20200901-5.8.13-pinebook-build-20201003.img.zst
slarm64-current-aarch64-base-rootfs-20200901-5.8.13-pinebook-build-20201003.img.zst.md5
 
1 members found this post helpful.
Old 10-04-2020, 10:17 PM   #133
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
The LCD output works on this one, no more black screen. It still has the sluggish cpufreq issue, but at least the LCD output is working.
 
Old 10-05-2020, 11:45 AM   #134
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
ok then I'll leave these changes for the mainline kernel
 
1 members found this post helpful.
Old 10-27-2020, 02:09 AM   #135
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
A few thoughts on the sluggish CPU-FREQ issue:

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.
 
  


Reply

Tags
arm, kernel, pine64, slackware, slarm64


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] slarm64 (aarch64 unofficial slackware) sndwvs Slackware - ARM 347 12-15-2021 01:45 PM
slarm64 no wifi kermitdafrog8 Slackware - ARM 45 09-27-2019 10:33 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 07:44 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration