mrjpaxton

Okay, here's the error I'm getting from the serial console: DDR Version 1.25 20210517 In channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! change freq to 416MHz 0,1 Channel 0: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB Channel 1: LPDDR4,416MHz Bus Width=32 Col=10 Bank=8 Row=16 CS=1 Die Bus-Width=16 Size=2048MB 256B stride channel 0 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 1 CS = 0 MR0=0x18 MR4=0x1 MR5=0x1 MR8=0x10 MR12=0x72 MR14=0x72 MR18=0x0 MR19=0x0 MR24=0x8 MR25=0x0 channel 0 training pass! channel 1 training pass! channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done change freq to 856MHz 1,0 ch 0 ddrconfig = 0x101, ddrsize = 0x40 ch 1 ddrconfig = 0x101, ddrsize = 0x40 pmugrf_os_reg[2] = 0x32C1F2C1, stride = 0xD ddr_set_rate to 328MHZ ddr_set_rate to 666MHZ ddr_set_rate to 928MHZ channel 0, cs 0, advanced training done channel 1, cs 0, advanced training done ddr_set_rate to 416MHZ, ctl_index 0 ddr_set_rate to 856MHZ, ctl_index 1 support 416 856 328 666 928 MHz, current 856MHz OUT U-Boot SPL 2022.07-armbian (Jun 30 2024 - 19:41:33 +0000) Trying to boot from SPI Trying to boot from MMC1 Card did not respond to voltage select! : -110 spl: mmc init failed with error: -95 Trying to boot from MMC2 NOTICE: BL31: lts-v2.8.8(release):armbian NOTICE: BL31: Built : 19:41:23, Jun 30 2024 INFO: GICv3 with legacy support detected. INFO: ARM GICv3 driver initialized in EL3 INFO: Maximum SPI INTID supported: 287 INFO: plat_rockchip_pmu_init(1624): pd status 3e INFO: BL31: Initializing runtime services INFO: BL31: Preparing for EL3 exit to normal world INFO: Entry point address = 0x200000 INFO: SPSR = 0x3c9 U-Boot 2022.07-armbian (Jun 30 2024 - 19:41:33 +0000) SoC: Rockchip rk3399 Reset cause: POR DRAM: 3.9 GiB PMIC: RK808 Core: 339 devices, 31 uclasses, devicetree: separate SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB MMC: mmc@fe320000: 1, mmc@fe330000: 0 Loading Environment from MMC... *** Warning - bad CRC, using default environment In: serial Out: serial Err: serial Model: Helios64 Revision: 1.2 - 4GB non ECC Net: dw_dm_mdio_init: mdio node is missing, registering legacy mdio busNo ethernet found. scanning bus for devices... Hit any key to stop autoboot: 0 Card did not respond to voltage select! : -110 switch to partitions #0, OK mmc0(part 0) is current device Scanning mmc 0:1... Found U-Boot script /boot/boot.scr 3906 bytes read in 17 ms (223.6 KiB/s) ## Executing script at 00500000 Boot script loaded from mmc 0:1 179 bytes read in 13 ms (12.7 KiB/s) 20409746 bytes read in 1952 ms (10 MiB/s) 39770624 bytes read in 3781 ms (10 MiB/s) 90994 bytes read in 79 ms (1.1 MiB/s) 2825 bytes read in 173 ms (15.6 KiB/s) Applying kernel provided DT fixup script (rockchip-fixup.scr) ## Executing script at 09000000 Trying kaslrseed command... Info: Unknown command can be safely ignored since kaslrseed does not apply to all boards. Unknown command 'kaslrseed' - try 'help' Moving Image from 0x2080000 to 0x2200000, end=48b0000 ## Loading init Ramdisk from Legacy Image at 06000000 ... Image Name: uInitrd Image Type: AArch64 Linux RAMDisk Image (gzip compressed) Data Size: 20409682 Bytes = 19.5 MiB Load Address: 00000000 Entry Point: 00000000 Verifying Checksum ... OK ## Flattened Device Tree blob at 01f00000 Booting using the fdt blob at 0x1f00000 Loading Ramdisk to f4b66000, end f5edcd52 ... OK Loading Device Tree to 00000000f4ae7000, end 00000000f4b65fff ... OK Starting kernel ... ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003) ERROR: rockchip_plat_sip_handler: unhandled SMC (0x82000003)

Hey guys, So I wanted to update the OS on my NAS to patch the Copy Fail vulnerability today. I installed everything, I also did an apt-upgrade (not a full one) to make sure my kernel was as up to date as I could get it, and I also updated the initramfs, too. Now when I boot up the Kobol, I can hear the disks spinning up after a few seconds upon powering up, they make an odd noise and then just stop. The LEDs on the front panel also no longer show blue anymore, and `fdisk -l` no longer shows anything. I know for a fact these HDDs are not dead. They have worked perfectly fine before the upgrade, and the SATA pins look perfectly clean. I even tried swapping from bays 1 and 2 to 3 and 4 and still no dice. I may go through and attach serial or dmesg output. But yeah, nothing much about "ata" shows up in `dmesg` after booting.

Okay, I started looking around some more. So it's a feature that's in the SATA 3.3 standard - https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/western-digital/collateral/tech-brief/tech-brief-western-digital-power-disable-pin.pdf But according to these schematics - https://wiki.kobol.io/helios64/files/schematics/Helios64_Schematics_Rev1.2.pdf It uses SATA 3.0, so my most likely guess is that it will not work right.

Hey, Quick question, can I use HDDs that have the pin-3 SATA "power disable" feature with the Kobol NAS, or should I steer completely clear of them?

@Balog Dániel Okay, just so I am 100% clear, you say you want to boot from SD card, but why is the USB-to-SATA adapter plugged in when you are booting? Are you also trying to boot from a HDD/SSD or something? Which one would you actually prefer to boot from? Unless the SD card is above Class 10 (whatever the SDXC specifications support), it's going to be slower unlike your other 3 options: eMMC, M.2 or a SATA device over USB3. You could also expose your eMMC by putting a special SD card inside. See Step 1. This will allow Offline copies since you can mount the partitions to a folder on the computer, and all you need to do is boot it with that SD card and plug it using the USB-C cable for the back. But since the Kobol runs Linux, normally any Linux backup solutions will work, including `rsync`. It should be good enough to do Online backups. If you choose to use `rsync` to backup, I recommend having a script that can do `fsfreeze -f /` followed with the folders you want to rsync over like /boot, /etc, /home, /root, /var, and then `fsfreeze -u /`. It is possible, but not advisable, to convert Ext4 to Btrfs, and then you could copy over read-only snapshots as backups, which means you don't have to do the `fsfreeze` parts, but it's a pain once you have to upgrade, because Armbian still recommends upgrading with reflashes. However, it will flash an Ext4 filesystem again. I really hope they start using Btrfs sometime on some of these larger capacity devices...

@Balog Dániel How did you install it? Since `armbian-config` is undergoing maintenance and re-haul, the best way to do it may be using `sudo nand-sata-install` at the moment, which actually seems to be part of what `armbian-config` uses anyway. Follow either System on USB or SATA (Including M.2 SATA) or Transfer rootfs from eMMC to SATA or USB depending if you want to transfer or install the OS from scratch, and skip to Step 3. Otherwise, if that's what you did, and that doesn't help... after reading your logs at the end, seems like the I2C driver gets stuck. I've read that it might be possible to solve the problem by disabling I2C. How to do that specifically for the Kobol, I'm not exactly sure, but I don't even have I2C drivers on my install when I check `lsmod | grep rk3x-i2c`. Not sure what it's needed for, so it should be possible to disable it with a blacklist config in `/etc/modprobe.d/` I'm guessing.

Yes, I have also experienced a crash without the patch. It crashed when I tried to attach a HDD hard drive with a SATA-to-USB3 device for backup (I made sure the AC adapter was used for it), so it is more "stable" and responsive than before, but not completely yet. Would it be helpful to disable Armbian's ramlog and get journald to write any dumps to storage so that I can check the logs last boot, or are you guys already aware of *all* of the issues that cause these random crashes/freezes?

Oh wow, been a while since I checked this thread. Apparently I'm still on a 2023 build. If I fully upgrade (via eMMC reflash) to Armbian 24.5.3 with the 6.6.36 kernel, will I still need the modified DTB file for improved stability, or has the DTB already been patched?

Ah, I see. Aren't there some Mali GPUs that will not run without the FOSS drivers? If it's only the drivers and not the underlying firmware, then the Mesa drivers should be fine. I'm also not using the graphical desktop, just the console. Maybe that's safer to use? Though reading here - https://wiki.debian.org/MaliGraphics Looks like it is possible to ship either user space drivers (Mesa) as well as kernel drivers. Gotta figure out which ones Armbian are using for which boards. And some may still have blobs for the drivers. So I guess it's up to everyone to figure out if they are using the completely free Mesa ones, or not.

Been hearing some news lately about some pretty big ARM Mali GPU vulnerabilities. Old boards could be affected, including ones that are not maintained. https://hothardware.com/news/arm-warns-of-mali-gpu-vulnerabilities https://developer.arm.com/Arm Security Center/Mali GPU Driver Vulnerabilities https://arstechnica.com/security/2023/10/vulnerable-arm-gpu-drivers-under-active-exploitation-patches-may-not-be-available/ I have a Rockchip RK3399 that may also be affected by this. Can Armbian do anything to help mitigate this problem? A handful of boards use these GPUs.

It can already run Mobian, which is a slightly better choice anyway. https://images.mobian.org/pinetab2/ Most ideal is just straight up Debian ARM with the vanilla Linux kernel it comes with, but that's a hard expectation these days... a pipe dream for most, because ARM hardware is so diverse and customized, and expects a whole bunch of additional cruft. The smaller screen usually demands a more mobile-focused, touchscreen interface like Phosh, Plasma Mobile, etc...

Ahh, okay. So it only has to do with the kernel and what version it is. Got it. Well, I have an eMMC install, so I back up root FS and `/boot` on an SD card every month, or when making changes, since putting the backups on the NAS itself... won't work out very well unless it's also on the entire NAS backup disk I have, too. But anyway, my kernel is "6.1.36-rockchip64", and just this week in early September I was able to do a full backup of my NAS array with Rsync on a USB 3 attached HDD just fine with zero problems on that kernel (I'm using the back USB ports, but that probably won't matter). Have you all also tested on both SD card and eMMC installs? So wait, I'm guessing this "dwc3" driver thing has to do with some other problem besides specifically USB storage devices. Maybe there are some devices it will work with, and others that it wont?

A bunch of people seem to have the same problem, and it may have to do with possibly the overall power consumption. Either that, or some other people say it's a particular software bug if you are searching for other Helios64 problem threads. Are you using the included backup battery in yours, or is it not installed?

How important is the Helios64 to you? You are going to have a very hard time finding sellers for this thing. I don't know how many total units were sold, but it seems pretty little. If you have trouble finding a seller, check my post here - https://forum.armbian.com/topic/28907-anyone-here-have-a-stable-helios64-running-omv6/?do=findComment&comment=169549 Where I talk about the TerraMaster F5-422, and JONSBO N1 and N2. The thing is these are not ARM boards, they are x86, so you can run whatever OS you want to on them as long it's all compatible with the hardware.

I don't know if 23.8 is the same as 23.08. This is where the numbering gets confusing, and I don't know why they did that... If you mean "Colobus" which was released on Sep 1st, I'm not entirely on that version right now. I didn't "dist-upgrade" the rest of the 23.08 packages. I sort of am, but here's what I mean. I have these packages held back: armbian-bsp-cli-helios64-current armbian-config armbian-firmware armbian-plymouth-theme linux-dtb-current-rockchip64 linux-image-current-rockchip64 linux-u-boot-helios64-current My version of these is apparently at "23.08.0-trunk". I can verify that my system is still working with USB and everything. Sorry to hear you're having this problem, but thanks for telling us, because I was also getting concerned if I should upgrade them or not, but I think I will hold off for a bit. The newest one available is actually 23.8.1. Have you tried that specific one, yet?

Yeah, that is a good point. I only have two drives installed in RAID 1 right now. They are HGST Ultrastar drives. I plan to install 2 more when I need more space.