LinuxQuestions.org
Latest LQ Deal: Latest LQ Deals
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 03-18-2020, 04:32 PM   #46
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
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....
 
1 members found this post helpful.
Old 04-18-2020, 10:20 AM   #47
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
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.
 
Old 06-05-2020, 12:33 AM   #48
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
Fresh images to account for the new rootfs and PAM and friends.


https://3space.xyz/pineslarm/
 
Old 06-06-2020, 02:26 PM   #49
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
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
 
Old 06-11-2020, 09:04 PM   #50
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
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
 
Old 06-12-2020, 04:42 PM   #51
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
Hi Shelldweller,

Raised the version of ATF and u-boot.
Please check on a non-working image by updating the bootloader on it:
Code:
dd if=idbloader.img of=/dev/mmcblk0 seek=64
dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
or
Code:
dd if=idbloader.img of=image.img seek=64
dd if=u-boot.itb of=image.img seek=16384

Last edited by sndwvs; 06-12-2020 at 06:13 PM.
 
Old 06-15-2020, 03:37 PM   #52
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
Hi Shelldweller,

Raised the version of ATF and u-boot.
Please check on a non-working image by updating the bootloader on it:
Code:
dd if=idbloader.img of=/dev/mmcblk0 seek=64
dd if=u-boot.itb of=/dev/mmcblk0 seek=16384
or
Code:
dd if=idbloader.img of=image.img seek=64
dd if=u-boot.itb of=image.img seek=16384
Hi sndwvs,

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?

thanks for helping me figure this out.
 
Old 06-15-2020, 04:05 PM   #53
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
Hi Shelldweller,

Try this option (after that the image should mount normally):
Code:
LOOP=$(losetup -f)
losetup $LOOP slarm64-current-aarch64-base-rootfs-*.img
fdisk -l $LOOP
dd if=idbloader.img of=${LOOP}p1 seek=64
dd if=u-boot.itb of=${LOOP}p1 seek=16384
losetup -D
This will replace the u-boot with a new one in an idle manner.
Strange, but writing to a sdcard shouldn't have damaged partitions.

oh I was very wrong,Try:
Code:
dd if=idbloader.img of=/dev/mmcblk0p1 seek=64
dd if=u-boot.itb of=/dev/mmcblk0p1 seek=16384

Last edited by sndwvs; 06-15-2020 at 04:08 PM.
 
Old 06-15-2020, 11:42 PM   #54
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
Hi Shelldweller,

Try this option (after that the image should mount normally):
Code:
LOOP=$(losetup -f)
losetup $LOOP slarm64-current-aarch64-base-rootfs-*.img
fdisk -l $LOOP
dd if=idbloader.img of=${LOOP}p1 seek=64
dd if=u-boot.itb of=${LOOP}p1 seek=16384
losetup -D
This will replace the u-boot with a new one in an idle manner.
Strange, but writing to a sdcard shouldn't have damaged partitions.

oh I was very wrong,Try:
Code:
dd if=idbloader.img of=/dev/mmcblk0p1 seek=64
dd if=u-boot.itb of=/dev/mmcblk0p1 seek=16384
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?

I will try your suggestions next. Thank you.
 
Old 06-17-2020, 11:55 AM   #55
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
Quote:
Originally Posted by shelldweller View Post
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.
 
Old 06-22-2020, 09:06 PM   #56
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
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:

https://3space.xyz/pineslarm/pinebook-bad.log.xz

https://3space.xyz/pineslarm/pinebook-good.log.xz

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.


thanks again.
 
Old 06-23-2020, 12:43 PM   #57
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
shelldweller,

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?
 
Old 06-23-2020, 11:44 PM   #58
shelldweller
Member
 
Registered: Mar 2019
Distribution: Slackware
Posts: 300

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by sndwvs View Post
shelldweller,

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
thanks.
 
Old 06-24-2020, 02:09 PM   #59
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
shelldweller,

I apologize, I recently thought that the processor is rk3399, not the A64.
 
Old 06-25-2020, 12:06 PM   #60
sndwvs
Senior Member
 
Registered: Aug 2014
Posts: 1,889

Rep: Reputation: Disabled
Again, we try on a non-working image already recorded on the SDcard:
u-boot-sunxi-with-spl.bin
Code:
dd if=u-boot-sunxi-with-spl.bin of=/dev/mmcblk0p1 bs=1024 seek=8
 
  


Reply

Tags
arm, kernel, pine64, slackware, slarm64


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] slarm64 (aarch64 unofficial slackware) sndwvs Slackware - ARM 347 12-15-2021 01:45 PM
slarm64 no wifi kermitdafrog8 Slackware - ARM 45 09-27-2019 10:33 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 05:48 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration