many thanks,
i fixed it in README.TXT, later I will fix it in the setup.sh script as well

when executing the script, what name does the script find, or give lsblk output when booting from SDcard

1 members found this post helpful.

Here it is, from SD card:

Ignore the sizes. After booting the eMMC for the first time, the partition gets resized to the full 57.6G. I am prepping the eMMC for an encrypted root partition, hence the size difference between mmcblk2 and mmcblk2p1. I have done that since the installation. Normally they wind up the same size.

FWIW, the output from lsblk is the same when booting from eMMC. The eMMC remains mmcblk2 and the SD card remains mmcblk0.

Just a quick update, and then marking this one as "solved".

I can build images on the Pinebook itself that work great now. I can build new kernels, etc. My Pinebook is now officially self-hosting. I can build the full OS on the Pinebook without needing any other machines. Very cool!

One side note is that the kernel-headers package for the "next" kernel, does not seem to allow me to build other packages. I had to install the kernel-headers package from the main repository to build anything. I might switch to the legacy branch next, just to see. But the point is that I am now trying out different kernel configurations and such, which is exactly where I wanted to be.

Much thanks sndwvs, I truly appreciate your help on this one.

1 members found this post helpful.

... oops, seems like I spoke too soon. I was able to do a full build about a week or two ago. Today's attempt fails in a new place though:
It seems like the download for sunxi-tools is failing. I am not sure why this is a new error. I checked the link in the config file, seems to work from what I can tell. Any idea what might be causing this? I was able to get past it by re-running the build.sh script and unselecting clean, download, and tools. Just wanted to report this here. thanks.

thanks shelldweller,
fixed

1 members found this post helpful.

Hmm, OK. Now it builds without error, that fixed it. However, the resulting image does not boot at all when written to an SD card. I get nothing on the screen at all, no error messages, no u-boot text, nothing but a black screen.

I took a look at the files in /boot, and everything looks okay to me there. I have tried two different SD cards, and I get the same result on both.

FWIW, the kernel packages that get built work fine, I am running those now as I type this.

Everything was working a few weeks ago, just for reference. I have a build from 2/14 that boots. So, one of the commits since then broke booting, most likely.

something is wrong with the bootloader, you can try to write down the previous

I have been looking into this more:

I have checked all of the pinebook-associated files, everything seems fine there, I do not see any notable changes.

I looked at all the commits made in the past month at your gitlab, and nothing stands out as breaking u-boot in any way.

I have compared the resulting boot files from the working image to the non-working image, and everything is the same.

I even copied over the working boot and lib directories to the new image, just to see if I could at least get some u-boot error messages to pop up. There is still nothing on the screen when the newer image is booted from.

It is as if the new image is not bootable at all. I cannot even get to a u-boot prompt to see environment variables. I have had the same results both before and after you updated the u-boot source version.

I will keep investigating, but I am out of ideas for the moment. Thanks. At least I have the one booting image from 02/14.

Maybe next I will try copying over the new boot directory to the working SD card, just to see if it will do anything at all.

A ha, that last idea panned out. Here is what I did:

Make two SD cards, one from 02/14 build image, and one from 03/11 build.

Delete contents of 02/14 SD card using rm -r *

Copy contents from 03/11 SD card to now empty 02/14 SD card using cp -r /path/to/SD/card/* .

Now the 02/14 SD card boots perfectly into the 03/11 image with a new kernel and everything.

So this has nothing to do with boot scripts or anything in the new image. Just how the image is created, somehow.

What part of your build script controls that? I will take a look when I have some time. I am now running late for work, oops!

means the bootloader, I raised the u-boot version to v2020.01

... a several builds later, I have been able to narrow it down to the last commit that I can boot from. Commit 1b181b72 from 29 Feb is the last commit that builds and boots successfully for me. After that, the very next commit cfa1d1dd gives no u-boot messages at all. The commit 42bff4ab after that *does* give u-boot messages, but then no kernel messages. After that, the build fails due to the missing downlad link for many commits, and then once that gets fixed, no more booting images result.

Okay, so here is what I do not understand: The two commits after the last working commit do not seem to have anything to do with the pinebook files. cfa1d1dd seems to only affect rockchip files, and 42bff4ab adds clear_boot_tools to overall.sh. But then how does that first break u-boot (rockchip commit), and then un-break u-boot but break the kernel (clear_boot_tools commit)?

Forgive me if I am being dense. I am learning this as I go. On the bright side I am still very happy to be able to build from the working commit, so I can still build new images and kernels, no harm done there. I am just curious about the script development process and how it affects these images I am building.

I am just recording my thoughts and findings here. No need to fix anything right away. I just find certain things interesting. I am going to keep playing around with the files to see if I can figure out a fix myself. Thanks, as always.

shelldweller, thanks for the analysis.

after seeing the subsequent changes, the first thing that catches your eye, this was the version of the ATF for everyone (and this is the first thing to load before u-boot).
changed to the current change.

Thank you sndwvs.

Oh, interesting. I would have never thought to check ATF. Still, something is not quite right. I cloned, built, and burned the latest commit/image, and it still does not boot at all, no u-boot messages whatsoever. I will continue to try different things. I am still baffled by my finding a few posts ago, where I copied the contents of a non-booting SD over to an emptied booting SD and it booted fine. It makes me think something is going wrong in the formatting of the SD, but I see no difference in the filesystems that result.

Either way I have another big job to build (LibreOffice update), so that will occupy my remaining a64 machine (this pinebook) for the next few days. My build-box (NanoPi Neo Core2, same architecture) seems to have gone belly up, so my building capability has been cut in half. I might try a cross-compile, but I usually prefer to build natively.

I will post more if I find out any more. thanks as always.

sndwvs provides package for libreoffice, you can try if you like. :-)

https://osdn.net/projects/slarm64/st...kages/aarch64/

Ah yes, thanks aaditya, I will try it. I recall trying one of his previous builds, and it did not work on my machine for some reason, I think there was a difference in the installed libraries or dependencies perhaps. I will try this image again to see if the issue persists. And I will post mine when it is done building, just to share.

1 members found this post helpful.