LinuxQuestions.org
Share your knowledge at the LQ Wiki.
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 07-18-2020, 08:09 PM   #76
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Original Poster
Rep: Reputation: Disabled

Quote:
Originally Posted by sndwvs View Post
to understand nevertheless without a conclusion on uart it is impossible to do.
Ah, excellent, more hardware to buy. ;-) Something like this?

https://store.pine64.org/product/pin...erial-console/

I will try to roll that into my next hardware purchase budget.

Quote:
Originally Posted by sndwvs View Post
try version v2020.04 with patches boot-20200719.tar.xz
I tried that one, same problem as before. I am now comparing u-boot build output from the working and non-working images. I am trying out a few different patches. Nothing works yet, but I have narrowed it down to only a few possible config settings. If I get something to stick, I will report here.

thanks again.
 
Old 07-18-2020, 08:16 PM   #77
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
Quote:
Originally Posted by shelldweller View Post
Ah, excellent, more hardware to buy. ;-) Something like this?

https://store.pine64.org/product/pin...erial-console/

I will try to roll that into my next hardware purchase budget.
not worth spending an extra day, maybe someone can check who has the opportunity to check it.
 
Old 07-24-2020, 06:03 PM   #78
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Original Poster
Rep: Reputation: Disabled
I really appreciate all the input and advice sndwvs. The entire process is much less mysterious to me now.

I have enough to work with here to keep me occupied for a while. I can set the u-boot version in the config file and narrow down at exactly which release the booting stops working. Then I maybe I can hack together a working patch and/or bug upstream u-boot to fix the issue. I know that there has been some changes to how u-boot handles pinebook since all this started. I am seeing some mention of the same problem for pinebook in the Armbian forum that resulted in a custom patch there, that could be useful. That should keep me busy for some time at least.

In the mean time, writing an older u-boot to a freshly built image is simple enough to make a working image. Thanks for showing me how to do that. Maybe one day I can figure out how to use a new u-boot that actually boots on pinebook.

Also, my "day job" is starting to pick up again. I probably will not have much time to tinker for the next month or so. And if I do, it will just be comparing different u-boot releases anyway.

On the plus side, you have a new Patreon supporter. It is not much, but every little bit helps, I am sure. It is the least I can do to show my appreciation.

Keep up the good work, I will check in here when I am able.

Last edited by shelldweller; 07-24-2020 at 06:07 PM. Reason: flow
 
Old 07-24-2020, 06:33 PM   #79
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
Thanks shelldweller,

this patch should have solved the current problem.
here is a similar problem.
i added a patch to disable the pinebook.

please check boot-20200725.tar.xz

Last edited by sndwvs; 07-24-2020 at 07:01 PM.
 
Old 07-25-2020, 11:36 PM   #80
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
Thanks shelldweller,

this patch should have solved the current problem.
here is a similar problem.
i added a patch to disable the pinebook.

please check boot-20200725.tar.xz
Thanks for keeping up with this. Here are the steps I took:

Fresh git clone (about 7 or 8 hours ago).

Built a default pinebook image, making no changes.

Tested this image, does not boot.

Wrote the latest u-boot file to the sd card (from boot-20200725).

Tested this modified image, does not boot

Wrote the known-working u-boot file to the same sd card (boot-20200214).

Tested this new modified image, and it boots successfully.

So, same problem as always.

I was looking at those patches, thanks for bringing them up. I wonder if they are for the original Pinebook or the Pinebook 1080p which came out later? I am going to try tweaking those patches, maybe...
 
Old 07-26-2020, 03:21 AM   #81
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
Quote:
Originally Posted by shelldweller View Post
I wonder if they are for the original Pinebook or the Pinebook 1080p which came out later?
u-boot configuration for Pinebook and Pinebook 1080p is the same.
 
Old 07-26-2020, 04:21 AM   #82
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
looking at the finished assembled blobs u-boot.itb noticed the difference that is observed in the difference between the ATF bl31.bin bl31.elf
rebuilt from bl31.elf instead of bl31.bin, please check boot-20200726.tar.xz

it's all a mistake

Last edited by sndwvs; 07-26-2020 at 08:42 AM.
 
Old 07-26-2020, 09:00 AM   #83
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
Omedetō!
everything is just in u-boot.itb did not get ATF.
please check boot-20200726-v2.tar.xz

Last edited by sndwvs; 07-26-2020 at 09:10 AM.
 
Old 07-28-2020, 03:20 PM   #84
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
Omedetō!
everything is just in u-boot.itb did not get ATF.
please check boot-20200726-v2.tar.xz
Okay, very interesting. This one boots! However, the first part of the boot process is still a blank screen, and by the time it loads the kernel the screen becomes active, and the booting process continues all the way to a login prompt as expected.

So, this is much better! The black screen before the kernel loads is not fatal... does something need to be added to the new initrd, perhaps?

excellent work!
 
1 members found this post helpful.
Old 07-29-2020, 12:42 PM   #85
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
Quote:
Originally Posted by shelldweller View Post
Okay, very interesting. This one boots! However, the first part of the boot process is still a blank screen, and by the time it loads the kernel the screen becomes active, and the booting process continues all the way to a login prompt as expected.

So, this is much better! The black screen before the kernel loads is not fatal... does something need to be added to the new initrd, perhaps?
yes, this is because of the patch that disables EDID.
and so the final implementation and assembly of the image:

boot-20200729.tar.xz
slarm64-current-aarch64-base-rootfs-20200628-5.7.10-pinebook-build-20200729.img.zst
slarm64-current-aarch64-base-rootfs-20200628-5.7.10-pinebook-build-20200729.img.zst.md5
 
Old 07-29-2020, 08:07 PM   #86
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
Very nice! Your image boots, and I see both u-boot messages and kernel messages on the screen. Awesome!

There is a ~8s blank delay between thek u-boot messages "loading the kernel..." and the initrd loading the modules and the actual kernel. I think the system is just decompressing/loading the initrd during this blank period, and I do not think any messages are missed. Just something interesting to notice, as this did not happen on my older working image (pre- initrd I believe)

So, this is a winner. Thank you for figuring this out.

I was testing out the 5.7.10 kernel image, and something is very sluggish by the time I got to an Xfce interface. I might downgrade back to the 5.5.x kernel just to see if there is a difference.

In any case, the boot issue seems to be fixed. This is truly a great day, thank you.

Oh, and nice move to *.zst, very cool, I learn about something new every day.

Last edited by shelldweller; 07-29-2020 at 08:15 PM. Reason: forgot to mention something...
 
Old 08-06-2020, 09:20 AM   #87
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by shelldweller View Post
I was testing out the 5.7.10 kernel image, and something is very sluggish by the time I got to an Xfce interface. I might downgrade back to the 5.5.x kernel just to see if there is a difference.
I have spent some more time investigating this. On the latest image, there is something going on with Xorg that is extremely sluggish, and I am not sure where to look for the problem.

At first I thought it was just Xfce, but now I am noticing it on all of the desktops to some degree. Everything seems fine when idling, but as soon as I start to move around the mouse cursor with the trackpad, then entire system slows to a crawl. I opened htop to see what was going on. There is a single process that can take up over 400% on a single core just by moving around the mouse cursor:

Code:
/usr/libexec/Xorg :0 -auth /home/user/.serverauth.1809
Although I think the numbers at the end can vary. Do you think this might be related to the ATF/u-boot issue? Are there any obvious things I can look at?

I tried building an image with a legacy kernel instead of a next kernel, and it always hangs during the last part of the kernel build with no errors put out to the console or to the build.log. It just stops in the same place every time. Since I cannot get the legacy kernel (5.5.x) to build anymore, I might have to do some trickery to downgrade the 5.7.x kernel and make a new initrd to rule out that specific kernel.

I can also dig through the Xorg logs to see if there are any glaring error messages or warnings.

Is there any other way I can narrow down what is going on here?

much appreciated, as always.
 
Old 08-06-2020, 10:06 AM   #88
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
Quote:
Originally Posted by shelldweller View Post
Although I think the numbers at the end can vary. Do you think this might be related to the ATF/u-boot issue? Are there any obvious things I can look at?
I don't think it has anything to do with ATF/u-boot.

you can try for Pinebook 1080 P to switch to the kernel from manjaro, the previous kernel in my opinion was based on manjaro.

I was wrong it was with Pinebook Pro.
build kernel 5.4.x
fixed kernel config removed module # CONFIG_WIREGUARD is not set
also a large load on the CPU is possible due to the lima driver

Last edited by sndwvs; 08-06-2020 at 12:29 PM.
 
Old 08-06-2020, 07:04 PM   #89
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 180

Original Poster
Rep: Reputation: Disabled
Ok, I will try a rebuild, thanks. In the meantime, I found this in Xorg.0.log in the new image, (it is the only error), seems to be related possibly:

Code:
[   220.900] (EE) AIGLX error: sun4i-drm does not export required DRI extension
Shouldn't that be sun8i-drm for A64? Or something like that?
 
Old 08-06-2020, 09:18 PM   #90
sndwvs
Member
 
Registered: Aug 2014
Posts: 892

Rep: Reputation: Disabled
Quote:
Originally Posted by shelldweller View Post
Ok, I will try a rebuild, thanks. In the meantime, I found this in Xorg.0.log in the new image, (it is the only error), seems to be related possibly:

Code:
[   220.900] (EE) AIGLX error: sun4i-drm does not export required DRI extension
Shouldn't that be sun8i-drm for A64? Or something like that?
no, that's a common name.
this driver is in the package mesa.
but I should use lima_dri.

kernel 5.4.55

slarm64-current-aarch64-base-rootfs-20200628-5.4.55-pinebook-build-20200806.img.zst
slarm64-current-aarch64-base-rootfs-20200628-5.4.55-pinebook-build-20200806.img.zst.md5

Last edited by sndwvs; 08-06-2020 at 09:21 PM.
 
  


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
slarm64 (aarch64 unofficial slackware) sndwvs Slackware - ARM 317 Today 11:38 AM
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:32 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