djurny

Hi @Ed van den Enden, Looks like the on-chip RTC is used for initial time-setting by the kernel in your case. It also seems that the overlay to enable i2c is now loaded correctly! I can help with two options, you can choose which one you want to use: Option 1: Use the `rtc-sync` script with the cronjob and systemd modification. Option 2: Use the user-overlay that will move the I2C "external" RTC to the first slot, naming it `rtc0`. The on-chip RTC will move to the second slot, `rtc1`. Option 1 will need more modifications in your configuration, but will work nonetheless. You can find the script attached here: Put the rtc-sync script in /usr/local/sbin/. Change onwership/permissions: sudo chown root:staff /usr/local/sbin/rtc-sync sudo chmod 0775 /usr/local/sbin/rtc-sync Create the cronjob /etc/cron.d/rtc-sync as follows: #min hr mon day dow run-as command 30 * * * * root /usr/local/sbin/rtc-sync -Ad update Modify ntp service unit file by adding the following to the end of the file (/lib/systemd/system/ntpsec.service OR /lib/systemd/system/ntp.service depending on which ntp package you have installed): # Added to sync wallclock to an external RTC [Service] ExecStartPre=-/usr/local/sbin/rtc-sync -A -d start ExecStopPost=-/usr/local/sbin/rtc-sync -A -d stop Option 2 will require adding the user-overlay file and changing only your armbianEnv.txt. I can only give you the user-overlay i used that works for the orangepi zero, but as this uses the same CPU as your board, it should work. if it does not work, you will always have option 1 as fallback. You can find the user-overlay (rtc1-soc.dts) and the instruction on how to compile and add this to armbianEnv.txt in this topic here: The user-overlay is also included down here: In addition to the user-overlay, you will also need to disable the `fake-hwclock` service, as that tries to emulate a real RTC by reloading the last known wallclock from a file that was created when the system was shutdown/rebooted. Instructions for this also in the same linked topic. Pick your option and try it out. If it all works well, for option 2 you will find that the i2c RTC is named rtc0, for option 1 you will see i2c RTC is still rtc1, but the rtc-sync script, cronjob and systemd modification will use the i2c RTC to set the wallclock (after it's set improperly by rtc0). Feel free to check back in if it still does not work. Groetjes,

I see. The logs show that you have setup armbianEnv.txt to boot from a filesystem that the later logs show is an EXT4 filesystem, located on the first partition of first namespace of the first found NVMe device. The logs do not show any blockdevice for mmc1 (which appears to be the driver linked to the SD card). No logging usually means that there is no device detected. Do note that things will indeed not be simple if you change your setup after gathering diagnostics logs. People are willing to help, but correct diagnostics information is needed for people to actually help you. Grt,

Hi @AaronNGray, Did you check if there is indeed an SD card inserted? If so, try to remove it then re-insert it while the system has booted. Also, seems that you have an NVMe storage device attached, on which the OS was installed - not the SD card as you mentioned? As @laibsch mentioned, the eMMC is detected and available as /dev/mmcblk0, but seems that SD card is not seen (if it was inserted). Grt,

Hi @coroner21, Can you share some pics of the Helios4 you have? Thanks, Groetjes,

Hi Loeriver, Where is the other end of your USB serial dongle connected to? Can you check there if the dongle had disappeard from the USB bus and re-appeared around the same time? In my "professional" life we have had workstations mysteriously reboot whenever we would power cycle the device hosting the USB to serial device. Even though you say it's not related, if this is still mysterious, best to check under each stone... Groetjes,

Hi all, If anyone is interested, I have a Helios64 backup battery pack lying around that I did order back in the day, but never got around to installing/using it. (Have a separate UPS.) From my guess this thing is <6 years old, but again, never seen any charge or discharge. PM me when interested. Groetjes, PS Available for pickup in the San Jose, Bay Area, CA (USA) or can send domestically thru USPS.

Hi, If you are having trouble sourcing a proper serial dongle, you could also try to set (or cap) the serial console's baudrate yourself in armbianEnv.txt. Use/replace the following: console=comfort extraargs=console=ttyS2,115200 earlyprintk=ttyS2,115200 This should prevent your bootscript from setting the kernel's serial baudrate to 1M5 and at least give you some kernel logging during booting. Not sure if the login prompt will follow the same baudrate, as `getty` (or one of it's variants) might use different default settings. Groetjes,

Hi, Not an expert here, but some educated guesses would be related to either timing, blocksizes towards the devices. Anything that might change or increase the amount of ATA commands towards the disks would be my bet to look at. You could experiment with enabling/disabling NCQ, reducing read-ahead, increasing chunksizes in case you use [software] RAID, increasing caching by tweaking vm options. Perhaps even the IO schedulers, there might have been some new IO schedulers introduced on the new kernel that show different behavior compared to the older kernel, etc. Groetjes,

Hi, If you want to know which kernel is used for your build, just run: ./compile.sh inventory-boards This will take some time. Open the resulting .csv file, which will contain all combinations possible. Groetjes,

Hi, Did you also make sure that you copy any ata options from your old installation? e.g. For my own Helios64 I have had similar issues and those were resolved by limiting the SATA link speed to 3Gbps: extraargs=libata.force=1:3.0G,2:3.0G,3:3.0G,4:3.0G The internets say that those ATA errors are caused by the the disk not responding to a controller request in time. Mostly it is advised to replace the [S]ATA cables and to make sure contacts are clean and no crosstalk/EMI can occur. A reduction in the ATA link speed also helps, which in my case sure did. Do keep in mind, that if you have regular spinning drives, the most throughput you will get out of your drives will be around 100~140 MB/s, which translates to roughly 1.5 Gb/s. So decreasing the linkspeed will not cause any slowdown, your drive's throughput will remain the performance bottleneck. For my Helios64, I have had some issues with the left-most (or top) disk, as the connectors did not protrude well enough, or had a little too much flex which caused the left-most disk from sometimes not being detected at all. Reseating and pressing on the connector from the rear helped that issue. As the internets mention these errors are the ATA driver complaining about not hearing from the drive(s) in time (or at all), you might want to experiment with a lower CPU frequency, or perhaps not using any of the dynamic freq scaling governors, but sticking to the powersave or performance one. Groetjes,

Hi @zital debian, Some things you could also try: Replace cables - again. I've had similar issues where the NIC of SBC would drop to 10Mbe half duplex, persistently after using different cables. In the end it was all the cables i had lying around that were not of good quality. Replaced the cat "5e" ones with cat 6 and the issues went away. Disable autoneg on your NIC or only advertise 1Gbe. Try a different switch port, switch or router. Check if you have some of those green options on your router/switch enabled, i think it's called EEE. I had some issues with and my Orangepi zero SBCs in combination with those bad cat "5e" ethernet cables. Groetjes,

Hi @alm, You should try with the legacy kernel, 6.6.75. That still has reboot working on my (first gen) Orange pi zero. Grt,

Hi @loeriver, Check your serial console, as sending a serial <BRK> will trigger the Magic Sysrq sequence. For example, using `tio` to connect to a serial console, I can invoke the Magic Sysrq help test with <ctrl>-t + B + <enter>. Perhaps your serial port has it's RX line shorted to ground? Groetjes,

Hi @Werner, Not to pick nits, but 7 is the highest level (lowest priority) you can give a printk() statement. To make them appear however, the loglevel of the printk() needs to be smaller than the loglevel of the console, meaning the [console] loglevel needs to be 7+1: loglevel= [KNL,EARLY] All Kernel Messages with a loglevel **smaller** than the console loglevel will be printed to the console. It can also be changed with klogd or other programs. The loglevels are defined as follows: Also, the following text also steers into the direction of using 8 instead of 7 to show all printk() messages: To change the current console_loglevel simply write the desired level to ``/proc/sys/kernel/printk``. For example, to print all messages to the console:: # echo 8 > /proc/sys/kernel/printk (Taken from https://www.kernel.org/doc/Documentation/core-api/printk-basics.rst.) Grt,

Hi @gyrex, You might want to try without the fstab entry for your root filesystem: UUID=024728b4-7d81-4433-8476-0f98407d1481 / ext4 defaults,noatime,commit=600,errors=remount-ro 0 1 and add the following to your armbianEnv.txt. extraargs=rw The fstab entry for your rootfs is there to remount your rootfs with some options, it is not there to actuall mount it - that's already done by the rootdev/rootfstype in your kernel commandline. or: change the last digit from 1 to 0 in the fstab entry for your rootfs to prohibit fsck during boot. Hopefully that would allow the system to complete it's boot and make room for some live troubleshooting. Thx, Groetjes,