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.

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.

shelldweller,

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

Above in posts I incorrectly specified a record on a disk, I ask also to check this bootloader:

Excellent news! This worked on a non-booting image, one of the most recent commits:

However this still does not work:
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!

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

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:

does nothing by itself, while

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.

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.

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.

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

I am not sure of the implications yet, but the date range seems to be right. Hmmm.... Anyway, just posting here for future reference.

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:

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?

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.

to understand nevertheless without a conclusion on uart it is impossible to do.

1 members found this post helpful.

try version v2020.04 with patches boot-20200719.tar.xz