martinayotte

As I said above about eMMC priority is still true for any Rockchip SoC. Did you tried using Serial Debug to stop U-Boot and force it to boot from SDCard ?

What is installed in you eMMC ? Because eMMC has priority over SDCard ... If the U-Boot currently present in eMMC is able to be stopped by keystroke on Serial Debug port, you can do "mmc list" to figure out the SDCard slot number, and do "setenv devnum <N>" followed by "run mmc_boot", it will then boot from SDCard .

Ahahah ! It is not as simple as that ... Why are you come to this conclusion ? Armbian folks are not responsible for all the issues, most comes from upstream ...

When changing ROOTFS, you need to change BOTH places in /boot/armbianEnv.txt as well as /etc/fstab, otherwise you get this "ALERT! UUID=... doesn't exist" ...

I'm currently busy on switching sunxi-dev to 5.6.y, but if any PR is provided, I'm ready to merge it ...

I'm happy to help, and I will do, but if you're too lazy to look at output/debug/compilation.log for details and search for "error:" , I won't do it for you !!! Would you help me to figure out why have troubles of switching Armbian Dev from 5.5.y to 5.6.y ? I've working on that task since more than a week !!!

Why ? I've better things to do, such as preparing the switch of Armbian DEV to 5.6.y ... If it doesn't compile and you wish it to compile, it is up to yourself to look into output/debug/compilation.log for details and search for "error:" ! Don't ask other to do your own tasks for you !

What do you mean ? As long as you are executing as "root", you don't need to have "crw-rw" flags ...

Look into output/debug/compilation.log for details and search for "error:" ...

I don't no ... Did you check the build log into output/debug/compilation.log ? Is the DTB package succeeded to be build ? Resulting packages are located in output/debs/ ...

It is not enough to format the partition of SDCard, it doesn't get rid of the u-boot located between partition table and the first partition. You need to do the following : dd if=/dev/zero of=/dev/mmcblk0 bs=1024 count=2048 fdisk /dev/mmcblk0 Then you can re-create new partition and format it ...

To try figuring about this crash, you will need to change "verbosity=1" to "verbosity=7" in /boot/armbianEnv.txt ...

Some new ones : I've done tests on my OPiPC2, OPiZeroPlus2, OPi+2E, OPiOne and OPiLite which also don't have a external 32768 crystal, drifts are seen only on H3 but not on H5 ... Also, the H3 RTC drift is late/slow compared to H2+ of the OPiZero previously tested which were ahead/fast.

That strange, you drifts is really bigger than mines, mines are 1 or 2 or 3 seconds per 2 minutes ... I've added "hwclock -w" before the loop and get the following results (not that I forgot to add UTC to "date") : Yes, it seems that a background process is doing "hwclock -w" in background, maybe every 12 minutes, as you said, most probably the ntp or chrony service ... BTW, I've the same test on my OPi3 which actually has an external crystal, no drifts at all ...

In fact, this URL is completely obsolete, it is a snapshot of code from 4 years ago ... The current Mainline is here : https://github.com/torvalds/linux/blob/master/drivers/rtc/rtc-sun6i.c But they still don't check the LOSC_AUTO_SWT_STA_REG register ... EDIT: I've done few tests with measurement at 8 minutes intervals, it is loosing/gaining around 8 seconds / 8 minutes, but since it is both loosing/gaining, overall the average should be good.

That is not really a good way to test, since your loop is a bit more than 1 second due to execution of previous lines. Do a sleep of 120 seconds or even bigger, such 1 hour, and calculate the number of seconds elapse between the two devmem2.

Don't you have another board that are still running ? If Yes, simply put your SDCard reader/writer into it USB and have access to it after mounting it in /mnt.

But none of those are for an A64 SoC ...

Maybe you can try to put 5.4.y compiled DTB into the 5.1.15 image and give it a try ...

Because it is a snapshot in time, it hard to revert to builds from 8 months ago. Do you still have that old 5.1.15 images ? Would it help if I provided one of my old Pine64 images ? Although it is not BananaPi-M4, maybe it will still boot since it is also an A64 ...

It seems like a can of worms ... Why don't you try using Legacy 4.19.y instead ?

You're right ! I don't see those warning in my dmesg ... something fishy there ... But, at least, it still seems to work in my case. EDIT: Oh ! But rtc-sunxi.c doesn't even look at LOSC_AUTO_SWT_STA_REG, it is only validate that write to SUNXI_LOSC_CTRL_REG was successful ... hmmm !

Megous still have 5.1 branch, but I doubt it will work easily since Armbian will still try to apply 5.4 patches on top of this 5.1 tree ...

Right ! But since the RTC has no external source, it stays with internal one. Check the registers description of Allwinner H3 user manual and check values with "devmem2" "devmem2 0x01f00000" report 0x0001, which is effectively mean LOSC_SRC_SEL bit is set to External, but "devmem2 0x01f00004" (the LOSC_AUTO_SWT_STA_REG) report 0x4, where LOSC_SRC_SEL_STA status bit is 0 meaning InternalOSC. To my understanding, the LOSC_AUTO_SWT_STA_REG autoswitch probably detect that there is no clock present and doesn't switch the clock ... Did you verify with "hwclock" on your board if it is accurate ?

Maybe ... But there are some images there : https://dl.armbian.com/orangepiplus/