LinuxQuestions.org
Review your favorite Linux distribution.
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 06-27-2020, 10:20 PM   #61
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 99

Original Poster
Rep: Reputation: Disabled

Quote:
Originally Posted by sndwvs View Post
Again, we try on a non-working image already recorded on the SDcard:
u-boot-sunxi-with-spl.bin
Code:
dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0p1 bs=1024 seek=8
Thanks for this. I tried this on two non-booting images: the first non-booting commit, and a very recent commit. Neither of the resulting images booted, same black screen, no error messages. So, same problem persists.

I will try a few things this weekend. Much appreciated.
 
Old 07-04-2020, 03:14 PM   #62
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 99

Original Poster
Rep: Reputation: Disabled
I have not given up on this, but I do not have any exciting progress to report either.

I have tried examining both image files using fdisk, parted, and file. I see no differences that would affect the boot process. I have also checked the build logs of several booting images versus several non-booting images and I see nothing that stands out about u-boot, the filesystem, ATF, etc. No error messages, nothing obvious.

I can still do the weird thing where I move all of the contents from the booting SD card to the non-booting SD card after deleting all of its contents, and it still will not boot. And the reverse is true, I can take a booting image, delete all of the contents of that card, move over the contents of a newer non-booting image, and that one will boot.

So, I can get the *content* of the latest commit to boot if I move it over to an emptied SD card of an already-booting image. However, even with content that is otherwise known to boot, an SD card made with a later commit will not even attempt to boot. Literal "Black Screen Of Death", no error messages, no noticeable disk activity, and it does not even try to boot from EMMC.

I am almost out of ideas. Next, I will try booting both images in QEMU just to see if I can generate any error messages at least. If I do, I will report back.

thanks, as always.
 
Old 07-04-2020, 03:32 PM   #63
sndwvs
Member
 
Registered: Aug 2014
Posts: 514

Rep: Reputation: Disabled
shelldweller,

You can check the old bootloader on a non-working image

Code:
dd if=sunxi-spl.bin of=/dev/mmcblk0 bs=8k seek=1 conv=fsync
dd if=u-boot.itb of=/dev/mmcblk0 bs=8k seek=5 conv=fsync
Above in posts I incorrectly specified a record on a disk, I ask also to check this bootloader:
Code:
dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1024 seek=8

Last edited by sndwvs; 07-04-2020 at 03:40 PM.
 
Old 07-06-2020, 11:57 PM   #64
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 99

Original Poster
Rep: Reputation: Disabled
Excellent news! This worked on a non-booting image, one of the most recent commits:

Code:
dd if=sunxi-spl.bin of=/dev/mmcblk0 bs=8k seek=1 conv=fsync
dd if=u-boot.itb of=/dev/mmcblk0 bs=8k seek=5 conv=fsync
However this still does not work:
Code:
dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0 bs=1024 seek=8
So, the A64 Pinebook does not like the new bootloader it seems. Can we just revert back to the older bootloader for the A64 Pinebook only in the build script?

thanks a lot!
 
Old 07-07-2020, 12:03 PM   #65
sndwvs
Member
 
Registered: Aug 2014
Posts: 514

Rep: Reputation: Disabled
ok, now let's find out who is to blame for ATF or u-boot.
on this to try on a non-working image one by one first sunxi-spl.bin write from the old, boot.
then again, on the initially inoperative image, write u-boot.itb and also boot

new bootloader boot-20200707.tar.xz assembly, try checking it too

Last edited by sndwvs; 07-07-2020 at 01:14 PM.
 
Old 07-07-2020, 11:00 PM   #66
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 99

Original Poster
Rep: Reputation: Disabled
Okay, I tested both bootloader assemblies, each part separately, and here is what I found:

using boot-20200214.tar.xz on my latest commit image:

Code:
dd if=sunxi-spl.bin of=/dev/mmcblk0 bs=8k seek=1 conv=fsync
does nothing by itself, while

Code:
dd if=u-boot.itb of=/dev/mmcblk0 bs=8k seek=5 conv=fsync
alone results in a booting image. Yay! So it seems like we have narrowed it down to u-boot.

Neither part, nor both parts together resulted in a booting image with the boot-20200707.tar.xz assembly.

So I guess Pinebook is very picky with the u-boot version.
 
Old 07-08-2020, 01:23 PM   #67
sndwvs
Member
 
Registered: Aug 2014
Posts: 514

Rep: Reputation: Disabled
Thanks shelldweller,

Another try, now ATF v2.3 boot-20200708.tar.xz.
The difference between those two commits is changing the version of u-boot from v2019.10 to v2020.01, although v2020.04, which is now current, should also work.
 
Old 07-09-2020, 09:02 PM   #68
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 99

Original Poster
Rep: Reputation: Disabled
Thanks sndwvs,

I tested both parts of the new boot file. The ATF seems to work fine, but u-boot still gives me a black screen of death. The only u-boot that works is from 20200214. All the others that have come since that I have tried give me the same BSOD effect.

I first wrote both parts to a non-booting image, and that did not work. Then I wrote the working u-boot over that, and the rest worked fine.

So, it seems I am fully dependent on the u-boot from 20200214. As long as I have that in place, all other combinations seem to work out fine.
 
Old 07-13-2020, 09:04 PM   #69
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 99

Original Poster
Rep: Reputation: Disabled
Digging around a bit more, I found this u-boot commit from Feb 06, might be part of the issue:

https://github.com/u-boot/u-boot/com...efb25b032ce04c

Code:
This partially reverts changes by commit 2cc393f
("video: make BPP and ANSI configs optional") since it
caused issues with other boards (missing LCD console
output on pinebook, x86 platform or sandbox). Enable
all disabled options again and opt out of not supported
color depth in board defconfigs.
I am not sure of the implications yet, but the date range seems to be right. Hmmm.... Anyway, just posting here for future reference.
 
Old 07-14-2020, 01:44 PM   #70
sndwvs
Member
 
Registered: Aug 2014
Posts: 514

Rep: Reputation: Disabled
then try to raise the version to v2020.07 boot-20200714.tar.xz
 
Old 07-15-2020, 10:16 AM   #71
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 99

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
then try to raise the version to v2020.07 boot-20200714.tar.xz
Nope, the same problem persists. Anyway, I think I figured out exactly what happened. Seems like they changed the pinebook_defconfig file upstream in u-boot. Here is an email thread about it that seems to have gone nowhere:

https://lists.denx.de/pipermail/u-bo...ry/396890.html

That patch never got merged into the master branch (at least not yet):

https://gitlab.denx.de/u-boot/u-boot...book_defconfig

So, basically, there is a single line missing from pinebook_defconfig in the u-boot source tree:

Code:
---

 configs/pinebook_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/pinebook_defconfig b/configs/pinebook_defconfig
index 929434e25a..306a6bc6b9 100644
--- a/configs/pinebook_defconfig
+++ b/configs/pinebook_defconfig
@@ -22,3 +22,4 @@ CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE=y
 # CONFIG_USB_GADGET is not set
 CONFIG_VIDEO_BRIDGE=y
 CONFIG_VIDEO_BRIDGE_ANALOGIX_ANX6345=y
+CONFIG_VIDEO_BPP32=y
--
And I would bet dollars to dabs that if we patched that single line back into pinebook_defconfig before building u-boot, then my problem would magically go away.

Worth a shot?
 
Old 07-15-2020, 10:54 AM   #72
sndwvs
Member
 
Registered: Aug 2014
Posts: 514

Rep: Reputation: Disabled
it seems I found the problem, please check boot-20200715.tar.xz
%98 that everything will work
 
Old 07-15-2020, 06:03 PM   #73
shelldweller
Member
 
Registered: Mar 2019
Distribution: Freenix & Slarm64
Posts: 99

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
it seems I found the problem, please check boot-20200715.tar.xz
%98 that everything will work
I tried that one on a non-booting image, and the same problem is still there.

I also added a patch to the u-boot patches directory to add that missing line to the pinebook_defconfig file. My patch worked, the config file shows the added line. However, the resulting image built with the modified u-boot still does not boot.

My lead might have been a red herring, because it is more than just a screen issue. The first time boot scripts do not run either (SD does not get resized, etc.). So maybe that was just a false lead.

I will try to get on the u-boot mailing list to see if I can get some insights from there.

thanks, as always.
 
Old 07-17-2020, 02:00 PM   #74
sndwvs
Member
 
Registered: Aug 2014
Posts: 514

Rep: Reputation: Disabled
to understand nevertheless without a conclusion on uart it is impossible to do.
 
1 members found this post helpful.
Old 07-18-2020, 07:31 PM   #75
sndwvs
Member
 
Registered: Aug 2014
Posts: 514

Rep: Reputation: Disabled
try version v2020.04 with patches boot-20200719.tar.xz
 
  


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 176 Yesterday 10:55 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 04:54 AM.

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