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.

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.

not worth spending an extra day, maybe someone can check who has the opportunity to check it.

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.

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...

u-boot configuration for Pinebook and Pinebook 1080p is the same.

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

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.

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

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.

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:

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.

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

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:

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