Pine A64 instability - firmware questions

Troubleshooting
1

Hi,

I have a couple of 2Gb Pine A64s from their introductory Kickstarter.

They have never been particularly stable, one of them loses the time about once a week, and the other suddenly dies without any real reason.

As a result I can’t use them for anything production. I got excited when I saw that you had an image for them running Bullseye x64. Sadly the one that dies randomly still does so. I then saw the recommendation to upgrade the firmware, but it seems that the image already does this, as
cat /proc/version reports the following before and after the upgrade:

Linux version 5.15.25-sunxi64 (root@be0d054872f0) (aarch64-linux-gnu-gcc (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 8.3.0, GNU ld (GNU Toolchain for the A-profile Architecture 8.3-2019.03 (arm-rel-8.36)) 2.32.0.20190321) #22.02.1 SMP Sun Feb 27 09:24:04 UTC 2022

Looking at some old messages, a replacement firmware by a user “longsleep” was supposed to cure a crash involving ETH0: and 2Gb models. Can I assume that the same patches are incorporated into 5.15.25-sunxi64 ?

I assume that there is no on board memory that holds a BIOS that could be at fault, correct? As in “firmware”.

If anyone could give any tips on how to find out what causes the system to die, I’d be really grateful!


(BTW: I find the terminology equating firmware and kernel confusing. Running “Update Firmware” leads me to suppose that a devices on board memory would be reprogrammed, whereas a kernel is loaded at boot time, isn’t it?)

Thanks!

Brian

2

Just to avoid a misunderstanding. DietPi is not doing any kernel development. We simple use the kernel as they are provided by the base image we use to run DietPi scripts on. Therefore we are not really able to answer what has been included into 5.15.25-sunxi64. This would be more a question to Armbian guys.

To get a view on the system crashing, you could try to activate persistent system logs:

dietpi-software uninstall 103 # uninstalls DIetPi-RAMlog
mkdir /var/log/journal # triggers systemd-journald logs to disk
reboot # required to finalise the RAMlog uninstall

Then you can check system logs via:

journalctl

which will then show as well logs from previous boot sessions. To limit the size, you can additionally e.g. apply the following:

mkdir -p /etc/systemd/journald.conf.d
cat << '_EOF_' > /etc/systemd/journald.conf.d/99-custom.conf
[Journal]
SystemMaxFiles=2
MaxFileSec=7day
_EOF_

This will limit logs to 14 days split across two journal files, so that with rotation you will always have between 7 and 14 days of logs available.

3

Many thanks for your reply, I’ll study it and use it for debugging purposes.

Regarding the kernel, this might explain it: (admittedly quite an old post from 2016)

Announcement: DietPi for PineA64

DietPi for Pine A64 is currently based on longsleeps’s excellent simpleImage (U-boot + BSP kernel) with Debian Jessie (arm64) debootstrap (according to these instructions: > https://wiki.debian.org/Arm64Port#Debootstrap_arm64 > ). The DietPi also make use of longsleep’s u-boot and kernel update scripts to keep in sync with his ongoing development work.

Further down it says:

I’m glad that it’s working for you. Be sure to run the “Update Firmware” option in dietpi-config to insure that you have longsleep’s latest kernel.

So, at least in 2016, it looks like someone at Dietpi was involved in shepherding in a kernel by “longsleep”

By 2018, it looks like development on that kernel was forked from Longsleep to a chap called “ayufan”.

I haven’t been able to find out when it moved to 5.15.25-sunxi64, but I wonder if the fixes in the old (U-boot + BSP kernel) kernel were incorporated into it. Any idea how I could find out?

Thanks!

Brian

4

Don’t rely on such old post. If I’m not mistaken we use Armbian as base image in meantime. Maybe these guys are able to answer your question regarding the kernel.

5

Yes, I found this one at last.

https://dietpi.com/forum/t/rock64-new-image/2958/2

Re: Rock64 new image
Post by MichaIng » Thu Feb 21, 2019 9:28 pm

Hmm the new image is based on ARMbian, while the old was from Ayufan. Actually the new one should provide newer kernel and such, which was the reason why Fourdee switched it.

Is the performance with the old image directly better or do you need to run rock64_fix_performance.sh and/or rock64_health.sh?
If so what do those scripts do, could you paste the content here?

Thanks for all your help. I assume you mean the Armbian forum here ? https://forum.armbian.com/forum/23-communitynewbie-forums/

B.

6

ah sorry, I thought I provided the link. Yes that’s the Armbian forum.

Anyway be careful with latest Armbian kernel 5.15. We have a couple of reports about thinks not working as they should be.

7

Jep it’s Armbian since some years now with kernel being upgraded to latest Linux 5.15 on first boot. Indeed there are some open issues with 5.15, which is quite new, but I haven’t heared of stability issues with PINE A64 (or Allwinner A64 SoC in general) yet.

Could you try whether flashing latest U-Boot helps:

. /usr/lib/u-boot/platform_install.sh
write_uboot_platform "$DIR" "$(lsblk -npo PKNAME "$G_ROOTFS_DEV")"
reboot

If not, to rule out that it’s something our end, you could try the latest Armbian Bullseye image and see whether it works stable: https://www.armbian.com/pine64/

8

Hello,

yes, I will try that. I am away from home until Tuesday, and then I will investigate. Question: What is U-boot?

Thanks!

Brian

9

U-Boot is the bootloader used on most SBCs. It is responsible for loading the kernel, mounting the root filesystem (via so called initramfs) and such, so the earliest boot stage. There is a boot sector at the beginning of bootable system drives which contains that bootloader, respectively the first part of it. It is located before/outside the actual partitions and filesystems, so on cannot see or trivially update it, which is instead done by the script/commands suggested above.