[SOLVED] Slarm64 on the Pinebook 1080 - help with kernel?
Slackware - ARMThis forum is for the discussion of Slackware ARM.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
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....
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.
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:
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?
Last edited by shelldweller; 06-11-2020 at 09:06 PM.
Reason: added kernel info
Okay, I tried both of those, using the SD card and the image from the first commit that does not boot for me. Those commands shrunk the image of the SD card down to 8.5MB. Is there more to that command that I should try, or a missing flag perhaps? Alternatively, should I just put those in place somewhere and try rebuilding the image from scratch?
Okay, I will try that next. I am convinced it has nothing to do with the content of the image, but how the card is being prepared. Here is my reasoning:
I can create two SD cards from two different images: One that boots from March 15th, and one that does not boot (anytime after March 15th, and for this test I used the most recent commit).
I mount both cards. On the booting card, I delete all of the contents using rm -r *. Then I copy all of the contents from the non-booting card to the booting (now empty) card. At this point, the contents of both cards are identical. However, one boots (the one that previously booted with the older content) and one does not (the newer image). So, I really do not think this has anything do do with u-boot or the firmware. I can boot into a card with only the new content as long as it was formatted using a commit before March 15th.
So, something about how the card gets formatted in the first place, perhaps?
Just the difference in u-boot and ATF, the rest is the same.
I finally had some time to get back into this. I tried out all of your suggestions above on the non-booting image, both before I wrote it to the card, and also by first writing the unaltered image to the card and then applying the second changes you mentioned. Neither approach resulted in a booting SD card, unfortunately.
I am now trying to read through the build logs for each image to see if I notice any obvious differences. They are rather large, but just in case anyone is interested, I uploaded compressed logs here:
bad=non-booting="black screen, no error messages of any kind"=latest commit
good=boots (and everything else works as expected, too)=March 15th commit
I was also thinking of inspecting both images directly to see if they have any different properties, like boot flags or something similar. If I can find anything noteworthy, I will report it here.
Made a comparison between two comites
7714ec87943be2fb3e65b509d6cd987d5622e26b (working)
bcbb0299d6f5a77716969742a712889fde6d9df6 (not working)
The difference that may affect this is the lineup of u-boot and ATF
when working, DDR blobs were used and when working, the bootloader output file is rksd_loader.img, do you have it?
Made a comparison between two comites
7714ec87943be2fb3e65b509d6cd987d5622e26b (working)
bcbb0299d6f5a77716969742a712889fde6d9df6 (not working)
The difference that may affect this is the lineup of u-boot and ATF
when working, DDR blobs were used and when working, the bootloader output file is rksd_loader.img, do you have it?
Hi sndwvs,
I just finished a rebuild of bcbb0299d6f5a77716969742a712889fde6d9df6 (not working). I checked the output directory, and unpacked the boot-20200623.tar.xz that resulted. I do not see rksd_loader.img in there. In fact, I just did a system-wide search for *_loader.img, and nothing comes up at all. Where should this be, am I looking in the right place?
Code:
bash-5.0$ tar --list -f boot-20200623.tar.xz
boot/
boot/sunxi-spl.bin
boot/u-boot.itb
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.