Slarm64 on the Pinebook 1080 - help with kernel?
 

Hello folks,

I have been running a Frankenstein's version of Slarm64 on my Pinebook 1080 for about a year now, and I have ironed out just about all of the quirks.

Besides the blueman bug that still confounds me, the only missing piece now is the kernel+modules.

I have been using a kernel version 4.20.0 from anarsoul's ArchLinux image, as it works better with the Slarm64 rootfs than any other starting image, and I have tried every image I can get my hands on.

However, I do not want to run this kernel forever, as it is not an LTS kernel, and everyone else has moved on to 5.4.x by now, at least in -current. I would like to build my own kernel from Slackware sources for the Pinebook 1080. I have been trying this in various forms for the last year. Everything from cross-compiling to native SlackBuilds on the machine itself, all of my usual tricks have not been working.

I am usually a whiz at compiling kernels for x86 architecture. I have done that so many times, I have it down to a fine science by this point, no real surprises anymore. However, ARM has proved to be a completely different beast for me. I have followed building guides from the vendor wikis, any anything else I could find. Usually, my kernels do not boot at all, or if they do I am not getting any screen output whatsoever.

Anyway, what I am trying to say is that I would like to do something similar to mara's slackware-arm-build-kit and add support for the Pinebook 1080. I see other Pine boards on the support list already, and I see other Allwinner boards there too. So I am sure it is possible, I just do not know where to start.

Can anyone just point me in the right direction? I am willing to do all of the dirty work myself, but any pointers that others could provide would be extremely appreciated.

On a related note, you can see the results of my efforts so far here:

https://3space.xyz/pineslarm/

There you will find an lzipped image that, when decompressed, can be dd'd onto a 16GB SD card that I know the Pinebook 1080 will boot from, resulting in a full GUI desktop and all package sets already installed. I realize this is not really the Slackware-way, and a true Slacker would just start from the rootfs and build up their own machine. And I also know that this image works smoother on this machine than any of the other images you can find on the Pine Wiki, so I felt like it was worth sharing.

Maybe of more importance, I have also uploaded all of my SlackBuilds.org packages to the same repository. Not all of those work (like Electrum, for example, something is wrong with python3-sip), and eventually I will just remove the non-working packages.

I have not attempted to document dependencies at all. If a package needs dependencies beyond the base Slackware installation, then the dependency is present, but not listed anywhere specifically except over at slackbuilds.org.

On the other hand, some packages that used to be dependencies for other packages are also present, and I will eventually get around to removing those, one day. For example, there are many dependencies for LibreOffice present, but the build of LibreOffice that I have uploaded most recently only has a single dependency: libfreehand. Everything else has been built into the LibreOffice package itself. I find that approach minimizes breakage when other things start updating.

That is all for now. I get busy with work and real life, as we all do, so I only tinker with this when I have the spare time. It is really just a fun project for me, nothing more. If I could just get a working kernel+modules built, that would be the final nail in the coffin, so to speak.

Thanks for reading, and mega-thanks to everyone that has made Slackware-ARM, Slarm64, and Slackware itself such an amazing operating system. Hopefully I can start giving back more in some way beyond my current level of participation and support.

- shelldweller

hi shelldweller,

essentially you need to add to slackware_arm_build_kit:
board configuration
config/boards
download script
config/boot_scripts
kernel configuration
config/kernel
kernel sources, bootloader
config/sources
in patch atf and u-boot kernel patches

i can make a branch for Pinebook 1080 (a64)
basic configuration, but I can not verify

Ah, very nice, I see. Thank you, that helps. I will dig into that more this weekend, I see now how I can get started at least. I will post here if I run into any strange issues. And, I will be able to verify any branches you make. :study:

overall.sh gcc version ?
 

Alright... I think I have all the right files in the right places. I used the Armbian Pinebook gitlab as an example/source for the relevant config files and patches needed for the Pinebook 1080 (henceforth called the Pinebook A64, since this is how it is distinguished from the Pinebook Pro; apparently the lower resolution model is the same board more or less).

It took a few tries to get the build script to start, and now it goes further than it has so far. It seems to get stuck checking the gcc version though:

Am I overlooking something obvious?

Are development packages like gcc installed?

Try compiling some packages from slackbuilds.org, it can help to show missing dependencies.

I am using the suggested build environment
 

This is on a full clean updated Slackware64 14.2 installation. gcc is definitely installed. I build from SBo on this machine all the time. I also tried it from an updated full installation of -current, and I get the same issue.

overall.sh gets created dynamically when I run build.sh, so all of my attemtps to edit the script get overwritten.

Strangely, the resulting overall.sh does not match the one in the git repository. Did one of my config files cause overall.sh to be regenerated somehow?

This chunk is causing the issue:

After I get the error, if I look at overall.sh, the commented line is uncommented, and the line below it is missing. It is reverting to another version of the script? I am not sure...

I will try a clean git pull and see if it is still happening.

I built the kernel on the SBC itself. I dont know if it can be built on a x86 computer or not..

got a bit further....
 

Okay, a clean git pull fixed the gcc version issue. And then I quickly realized that the gcc in 14.2 is too old. So I switched to my -current x86_64 box, where it complained about architecture issues. So then I switched to my slarm64 build box, and I got much further this time. Now it is saying it cannot find the command create_uboot:

I made sure that u-boot-tools is installed. What package provides create_uboot? All I can find is this, and I am guessing this is not exactly the same thing I need?

https://github.com/genodelabs/genode...l/create_uboot

I am getting closer each time I try though, that is encouraging.

in order to build on x86 PC you need to use the master branch.
but since I have not had x86 PС for a long time, this branch has not been updated for a long time, although it should work.

this function is located in config/sources/sunxi.inc or rockchip.inc and is specific for different SoCs, but the finished loaders are output.

we have liftoff!
 

Ah, thanks for the hint. I just learned a LOT, actually. It has been so long since my programming classes, I forgot to check the includes files.

Okay, so I was not running a clean environment, and selecting the "clean" option in the build script help clear out the SOCFAMILY variable that was set to rk*, hence the failure to find create_uboot.

It looks like I am now getting past the config stage and the build seems to be running fine as I type this. I appreciate the help getting this far, and I think I am getting the hang of how you have set this up.

I will report back anything unusual. For now, I think I've got this. Much appreciated.

It seems that I typed that too soon. I am still getting that same errors, but now I can see a bit better what is happening. create_uboot should only be needed for SOCFAMILY=rk33*, and is not needed for SOCFAMILY=sun*, of which the pinebook_a64 belongs to. I have the SOCFAMILY set to sun50iw1 in the config file, which is what this A64 is. And for some reason, when it starts working through compliation.sh, the SOCFAMILY has been switched to rk33* somehow, or at least that is the best I can figure so far.

I need to go outside and play for a bit. Hopefully I can come back with a fresh mind on this one.

thanks again.

shelldweller,

look at the basic changes for pinebook, atf is not added to the collection and the atf record in the image

shelldweller,

i build the kernel and the image, but I think the image lacks atf, while i see what else is needed.
you can try the kernel.

prepared test image for Pinebook and P1080 Pinebook.
please test, otherwise further support will not make sense.

slarm64-current-aarch64-base-rootfs-20200118-5.5.0-pinebook-build-20200208.img.xz
slarm64-current-aarch64-base-rootfs-20200118-5.5.0-pinebook-build-20200208.img.xz.md5

Cool! I will test this tonight. I spent the weekend rebuilding my build-box. I am guessing I corrupted the eMMC, because booting became unstable after a while. Now that I am done with that, I can try out what you were building this in the meantime.

thanks, I will report back ASAP.

Okay, I have been testing your new image. Everything seems to work fine with one tiny exception: I cannot get the bluetooth adapter to respond at all now. If I reboot into my usual desktop, the adapter works fine, but the blueman bug is still there. I cannot even check the blueman situation in the new image because the bluetooth adapter is not recognized at all. The fix might be a simple one, and so far that is the only issue I have detected.

I will back up the system I have on the eMMC and will try the setup option to install to the eMMC sometime this week. I will post here my findings.

Thanks for this, I appreciate the effort and was thrilled to see the image boot to a command prompt. That was exciting!

UPDATE!:

I got some hints from dmesg:

So I took a closer look at the Arch-based setup, and I found some extra files in /lib/firmware/rtl_bt, namely:

Of these, I believe only the last two pertain to the Pinebook. The Arch-kernel image produces:

(the delay is me unlocking an encrypted drive during boot)

So I dropped those (all four) into the same directory on the new image you provided, and the bluetooth adapter was finally available via bluetoothctl. I still get the blueman bug in this image, but that is another thread already....

So, if we can figure out why we wind up wind missing firmware files, then I would consider this a success. Every other feature I have tested so far works fine, including screen brightness, which is something missing from half of the images on the Pine wiki for this machine.

Any clue how to bring in the extra firmware files?

thanks,
add and make a test image

Cool, thanks! After a fresh git clone on a recently rebuilt build-box, I get this after a while, which does not seem related to the Pinebook at all...

Is this something having to do with my build environment? It looks like a patch failed. I will look into it a bit further later. Thanks much.

update
slarm64-current-aarch64-base-rootfs-20200118-5.5.0-pinebook-build-20200214.img.xz
slarm64-current-aarch64-base-rootfs-20200118-5.5.0-pinebook-build-20200214.img.xz.md5

This one is a winner! 100% functionality on an SD card. Next, I will test the setup function to install to eMMC. I am prepping for that now, and will report back my findings here.

Thank you!

after your message I will collect the image XFCE.

setup does nothing
 

The setup script does nothing and gives no errors. A look at /root/setup.sh shows that there is no mention of pinebook at all. Is this script only meant for other boards, or has pinebook support just not been added to the setup script yet? I am just curious. I only started to look at the script just now, I will have time to dig deeper later in the week.

thanks!

not in the script, add a few days ago

added to setup.sh to transfer to eMMC board pinebook and pinebook-pro.
try replacing the setup.sh script.

Alright, I was able to get much further this time. In the new script, I had to change:

to

otherwise the script exits without any messages.

After making that one change, the script runs, and it copies the system over to the eMMC as expected. However, the result will not boot. Powering on results in a black screen and not much else. I also noticed that uEnv.txt was not altered. No rootdev line was added, for example. So it seems like something is going wrong with the fix_config() function, perhaps?

Thanks, for H3 there was no need to change the root device due to the fact that when removing the SDcard eMMC, it becomes mmсblk0.
fixed

Hmm, okay. That line is being set correctly in uEnv.txt now. But something is still wrong, and I am stumped. The SD card works fine, no problems there. The transfer works fine, I do not see any problems there.

The end result is still not booting at all. I see nothing on the screen, no u-boot messages, no error messages, just dark blankness.

I have been comparing the boot scripts on my working eMMC image (with the Arch kernel) to the boot scripts that the new image winds up with, and I see lots of differences, but I do not know enough to figure out what is important and what is extra code in there for other boards.

What really baffles me is that the SD card image boots just fine, but the eMMC transfer does not even try to boot. I cannot even tell if is booting without display output, or just not booting at all.

The next chance I have to play around with this, I will put something in rc.local on the eMMC to be able to tell if it is booting without display output or just not booting. More on that in another day or two.

thanks, as always.

an interesting turn of events....
 

Here is an interesting twist:

I tried the first method of installing to eMMC listed in the README file, and I changed the block device as needed, and simplified a few steps for my setup. Here are the modified instructions that WORKED!

Now I am able to boot direclty from the eMMC. Very simple. I still do not know what is causing the setup script to result in an non-booting eMMC. However, with the above instructions, I am now where I need to be.

Thank you very much for all your help, I truly appreciate it. If you would like to figure out how to get the setup script to work, then I am willing to continue investigations. Otherwise, the image paired with the above instructions are satisfactory for my purposes.

:hattip:

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

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.

spoke too soon - sunxi-tools missing?
 

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

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!

:eek:

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.

The Great LibreOffice Build Race!
 

Ha, it seems like now we have two LibreOffice updates. Both work on my machine, FYI.

Here is mine, in case anyone wants to check it out:

https://3space.xyz/pineslarm/package...-2_shldwlr.tgz

https://3space.xyz/pineslarm/package...-2_shldwlr.md5

One big difference I noticed: I was able to build in embedded database support with the Firebird module. That has been impossible to build on ARM for as long as I have been aware of it. Much to my surprise, it built this time without complaint.

I did turn off JAVA support in mine, though. Does the other one get built with JAVA support? Just curious, the only time I have needed it was when I was checking out an Accessibility Checker Plugin for LibreOffice, which depends on JAVA.

I might try to build mine with JAVA support, especially if I wind up with a lot of spare time on my hands.... :rolleyes:

Some fresh kernel packages:

https://3space.xyz/pineslarm/kernels...ch64-1mara.txz
https://3space.xyz/pineslarm/kernels...-1mara.txz.md5

https://3space.xyz/pineslarm/kernels...ch64-1mara.txz
https://3space.xyz/pineslarm/kernels...-1mara.txz.md5

https://3space.xyz/pineslarm/kernels...ch64-1mara.txz
https://3space.xyz/pineslarm/kernels...-1mara.txz.md5

https://3space.xyz/pineslarm/kernels...arch-1mara.txz
https://3space.xyz/pineslarm/kernels...-1mara.txz.md5

https://3space.xyz/pineslarm/kernels...ch64-1mara.txz
https://3space.xyz/pineslarm/kernels...-1mara.txz.md5

Grab 'em while you can. My hosting provider has expressed that they do not like me "sharing files", which basically means the time has come to stop giving them money if they have that sort of attitude. These should be up for at least a few more weeks though.

Fresh images to account for the new rootfs and PAM and friends.


https://3space.xyz/pineslarm/

Nevertheless, it would be nice to determine what prevents you from working correctly in the latest edition of images_build_kit, there are not many options:

• u-boot+ATF
• kernel

Yes, I agree. I got sidetracked recently with a few other things, and I would like to get back to understanding this better.

Last time I had a chance to do a few builds, I was able to narrow it down to a specific commit:

commit 7714ec87943be2fb3e65b509d6cd987d5622e26b from 03/15 is the last commit that builds and boots for Pinebook A64 for me.

However, the very next commit (bcbb0299d6f5a77716969742a712889fde6d9df6) only adds stuff for rockchip. I cannot figure out why that change breaks booting for the Pinebook. None of the Pinebook-related files are changed by that commit, are they?

This is where I get stuck.

I really appreciate any insights you have on this point.

Oh, and I have ruled out the kernel, because when I roll back to that commit, it still downloads the latest kernel anyway. I am 99% certain this is NOT a kernel issue. Must be u-boot/ATF then?