Yeah, it makes sense, sadly. The NanoPi R76S has Realtek NICs, but PHC support isn't included into the mainline kernel. The out-of-tree r8125 driver is... let's just say it's not very stable. The in-kernel driver doesn't display PHC at all, so it's not surprising that ethtool -T doesn't show anything. If you're noticing missing MACs and PHC vanishing after a reboot with r8125-9.016.01, it's generally because the driver and kernel versions don't match. That driver is quite sensitive to the internals of the kernel, and things become strange very quickly if udev or the DT bindings don't match up. It's also important to note that even when PHC works with Realtek, it's frequently not fully developed. For example, timestamping could be there, but it won't sync well with ptp4l, particularly when the system is under a lot of demand. So, for PHC accuracy and stability, this board was never meant to be used for serious time sync. In short: No PHC support for mainline kernel out-of-tree r8125 is unstable and breaks easily R76S hardware isn't very good for precise timing. If PHC is a must, Intel i210/i225-based NICs will work considerably better for you. Realtek + PHC is like being in agony mode.

Same problem here except there's no Desktop option. Only these: - Kernel - Storage - Access - User - Updates Got any other solutions?

You can't truly "force" the boot sequence on Helios64 since U-Boot already checks SD, eMMC, and SATA. The SD card isn't bootable if the eMMC is still booting. Things to check quickly: SD must contain a properly written raw Armbian image (dd / balenaEtcher). You can't copy files. Check that it contains a bootloader and not simply an ext4 partition. Before starting, turn off the power completely (warm reboots might disregard SD). Once the computer has started, use lsblk -f to inspect the layout of the devices. On Helios64, the mmc numbering does change, therefore tools may conceal devices to save the live rootfs from being destroyed. If you want to be 100% sure, unplug the eMMC for a short time. If it boots, the SD is OK. The boot sequence isn't the problem; the SD image is.

It said "archlinux" because I took something from my notes for my Arch Linux images. It was only an example command and you can put there anything on how you named the image. I did not include image creating and bootrapping an OS into the image. I mainly wanted to show you how you can build and flash your custom u-boot. You get these "idbloader.img" and "u-boot.itb" files from the steps I laid out. If you download u-boot, bl31, ddr and compile it, you will see the files in the folder. I am sure you will understand this pretty fast. :-) Create an empty img file Create a rootfs partition (should start at 16MB) Bootstrap Debian or Ubuntu into the image Then start with the u-boot stuff above. By the time 6.19 drops, you will be a master in building images. :-)

yes. I tried r8125-9.016.01 but with mixed results. Ethernet addresses could not be read by the new driver. And PHC support was no longer shown after reboot.