Jump to content

aprayoga

Members
  • Posts

    138
  • Joined

  • Last visited

Posts posted by aprayoga

  1. @ShadowDance have you tried to unplug and replug the SATA cable from the board?

    I have similar issue (reset link and downgraded to 3.0 Gbps) in the past and it was fixed after i unplug and replug the sata cable.

    At that time i used off the shelf sata cable, atx power supply and 5x 2.5" sandisk sata ssd

     

    I tried to reproduce issue with hardware i have, 3x WD20EFRX and 2x ST1000DM010-2EP102.

    The WD drives connected to SATA port 3, 4, 5 and configured as mdadm raid 5.

    I scrub the array which took ~4hrs to finish. no ata issue occurred.

    then i prepared the drive for hotplug,
     

    mdadm -S md127
    echo 1 > /sys/block/sdc/device/delete

    remove the drive, wait for a while then replug the drive and re-assemble the array.

    The drive still connected at 6.0Gbps

     

    The log

    Spoiler
    
    
    
    Nov 26 14:47:38 helios64 kernel: sd 2:0:0:0: [sdc] Synchronizing SCSI cache
    Nov 26 14:47:38 helios64 kernel: sd 2:0:0:0: [sdc] Stopping disk
    Nov 26 14:47:38 helios64 systemd-udevd[575]: Process '/sbin/mdadm -If sdc1 --path platform-f8000000.pcie-pci-0000:01:00.0-ata-3' failed with exit code 1.
    Nov 26 14:47:38 helios64 kernel: ata3.00: disabled
    Nov 26 14:47:42 helios64 login[2096]: pam_unix(login:session): session opened for user root by LOGIN(uid=0)
    Nov 26 14:47:42 helios64 systemd-logind[1527]: New session 9 of user root.
    Nov 26 14:47:42 helios64 systemd[1]: Started Session 9 of user root.
    Nov 26 14:47:42 helios64 login[2520]: ROOT LOGIN  on '/dev/ttyS2'
    Nov 26 14:47:57 helios64 kernel: ata3: SATA link down (SStatus 0 SControl 300)
    Nov 26 14:48:01 helios64 CRON[2530]: pam_unix(cron:session): session opened for user root by (uid=0)
    Nov 26 14:48:01 helios64 CRON[2531]: (root) CMD (/usr/sbin/omv-ionice >/dev/null 2>&1)
    Nov 26 14:48:01 helios64 CRON[2530]: pam_unix(cron:session): session closed for user root
    Nov 26 14:48:33 helios64 kernel: ata3: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
    Nov 26 14:48:33 helios64 kernel: ata3.00: ATA-9: WDC WD20EFRX-68EUZN0, 82.00A82, max UDMA/133
    Nov 26 14:48:33 helios64 kernel: ata3.00: 3907029168 sectors, multi 0: LBA48 NCQ (depth 32), AA
    Nov 26 14:48:33 helios64 kernel: ata3.00: configured for UDMA/133
    Nov 26 14:48:33 helios64 kernel: scsi 2:0:0:0: Direct-Access     ATA      WDC WD20EFRX-68E 0A82 PQ: 0 ANSI: 5
    Nov 26 14:48:33 helios64 kernel: sd 2:0:0:0: Attached scsi generic sg2 type 0
    Nov 26 14:48:33 helios64 kernel: sd 2:0:0:0: [sdc] 3907029168 512-byte logical blocks: (2.00 TB/1.82 TiB)
    Nov 26 14:48:33 helios64 kernel: sd 2:0:0:0: [sdc] 4096-byte physical blocks
    Nov 26 14:48:33 helios64 kernel: sd 2:0:0:0: [sdc] Write Protect is off
    Nov 26 14:48:33 helios64 kernel: sd 2:0:0:0: [sdc] Mode Sense: 00 3a 00 00
    Nov 26 14:48:33 helios64 kernel: sd 2:0:0:0: [sdc] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
    Nov 26 14:48:33 helios64 kernel:  sdc: sdc1
    Nov 26 14:48:33 helios64 kernel: sd 2:0:0:0: [sdc] Attached SCSI disk
    Nov 26 14:49:01 helios64 CRON[2559]: pam_unix(cron:session): session opened for user root by (uid=0)
    Nov 26 14:49:01 helios64 CRON[2560]: (root) CMD (/usr/sbin/omv-ionice >/dev/null 2>&1)
    Nov 26 14:49:01 helios64 CRON[2559]: pam_unix(cron:session): session closed for user root
    Nov 26 14:50:01 helios64 CRON[2598]: pam_unix(cron:session): session opened for user root by (uid=0)
    Nov 26 14:50:01 helios64 CRON[2599]: (root) CMD (/usr/sbin/omv-ionice >/dev/null 2>&1)
    Nov 26 14:50:01 helios64 CRON[2598]: pam_unix(cron:session): session closed for user root
    Nov 26 14:51:01 helios64 CRON[2617]: pam_unix(cron:session): session opened for user root by (uid=0)
    Nov 26 14:51:01 helios64 CRON[2618]: (root) CMD (/usr/sbin/omv-ionice >/dev/null 2>&1)
    Nov 26 14:51:01 helios64 CRON[2617]: pam_unix(cron:session): session closed for user root
    Nov 26 14:52:01 helios64 CRON[2634]: pam_unix(cron:session): session opened for user root by (uid=0)
    Nov 26 14:52:01 helios64 CRON[2635]: (root) CMD (/usr/sbin/omv-ionice >/dev/null 2>&1)
    Nov 26 14:52:02 helios64 CRON[2634]: pam_unix(cron:session): session closed for user root
    Nov 26 14:53:01 helios64 CRON[2656]: pam_unix(cron:session): session opened for user root by (uid=0)
    Nov 26 14:53:01 helios64 CRON[2657]: (root) CMD (/usr/sbin/omv-ionice >/dev/null 2>&1)
    Nov 26 14:53:01 helios64 CRON[2656]: pam_unix(cron:session): session closed for user root
    Nov 26 14:54:01 helios64 CRON[2677]: pam_unix(cron:session): session opened for user root by (uid=0)
    Nov 26 14:54:01 helios64 CRON[2678]: (root) CMD (/usr/sbin/omv-ionice >/dev/null 2>&1)
    Nov 26 14:54:01 helios64 CRON[2677]: pam_unix(cron:session): session closed for user root
    Nov 26 14:54:12 helios64 kernel: md: array md127 already has disks!
    Nov 26 14:54:12 helios64 kernel: md/raid:md127: device sde1 operational as raid disk 2
    Nov 26 14:54:12 helios64 kernel: md/raid:md127: device sdd1 operational as raid disk 1
    Nov 26 14:54:12 helios64 kernel: md/raid:md127: device sdc1 operational as raid disk 0
    Nov 26 14:54:12 helios64 kernel: md/raid:md127: raid level 5 active with 3 out of 3 devices, algorithm 2
    Nov 26 14:54:12 helios64 kernel: md127: detected capacity change from 0 to 4000527155200
    Nov 26 14:54:12 helios64 systemd[1]: Started MD array monitor.
    

     

     

    I use Armbian 20.11 Buster (LK 5.9.10) for the test

     

  2.  

    @slymanjojo to use DAS on LK 5.9, you would need to configure the USB-C as device mode.

     

    In your helios64, create a file dwc3-0-device.dts contains following code

    /dts-v1/;
    /plugin/;
    
    / {
    	compatible = "rockchip,rk3399";
    
    	fragment@0 {
    		target = <&usbdrd_dwc3_0>;
    		__overlay__ {
    			dr_mode = "peripheral";
    		};
    	};
    };

    add and enable to user overlay

    sudo armbian-add-overlay dwc3-0-device.dts

    and reboot

     

    Now, you can follow instruction on our wiki to enable DAS. If you are using Windows, you might need to unplug and replug the usb cable after enabling the DAS mode. 

    ---

    If you want to use USB-C in Host mode, you need to remove folloing line from /boot/armbianEnv.txt

    user_overlays=dwc3-0-device

    and enable host mode overlay on armbian-config > System > Hardware and tick dwc3-0-host

  3. @jbergler Could you try the attached u-boot ? This u-boot contains updated Rockchip blob (DDR driver & ATF)

    install with

     

    dpkg -i linux-u-boot-current-helios64_20.11.0-trunk_arm64.deb

    After that, run armbian-config > System > Install > 5 Install/Update the bootloader on SD/eMMC

     

    If you are using SD card, make sure to clean bootloader on the eMMC. you can run

    dd if=/dev/zero of=/dev/mmcblk1 seek=64 count=30000

     

    Power cycle the system. The system should boot with new bootloader.

     

    Spoiler
    
    DDR Version 1.24 20191016 RevNocRL
    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 416MHZ, ctl_index 0
    ddr_set_rate to 856MHZ, ctl_index 1
    support 416 856 328 666 MHz, current 856MHz
    OUT
    Boot1 Release Time: May 29 2020 17:36:36, version: 1.26
    CPUId = 0x0
    ChipType = 0x10, 352
    SdmmcInit=2 0
    BootCapSize=100000
    UserCapSize=14910MB
    FwPartOffset=2000 , 100000
    mmc0:cmd5,20
    SdmmcInit=0 0
    BootCapSize=0
    UserCapSize=15103MB
    FwPartOffset=2000 , 0
    StorageInit ok = 67151
    SecureMode = 0
    SecureInit read PBA: 0x4
    SecureInit read PBA: 0x404
    SecureInit read PBA: 0x804
    SecureInit read PBA: 0xc04
    SecureInit read PBA: 0x1004
    SecureInit read PBA: 0x1404
    SecureInit read PBA: 0x1804
    SecureInit read PBA: 0x1c04
    SecureInit ret = 0, SecureMode = 0
    atags_set_bootdev: ret:(0)
    GPT 0x3335db8 signature is wrong
    recovery gpt...
    GPT 0x3335db8 signature is wrong
    recovery gpt fail!
    Trust Addr:0x4000, 0x58334c42
    No find bl30.bin
    No find bl32.bin
    Load uboot, ReadLba = 2000
    Load OK, addr=0x200000, size=0xdd6b0
    RunBL31 0x40000 @ 191346 us
    NOTICE:  BL31: v1.3(debug):2803a2c8a
    NOTICE:  BL31: Built : 14:31:03, May 19 2020
    NOTICE:  BL31: Rockchip release version: v1.1
    INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
    INFO:    Using opteed sec cpu_context!
    INFO:    boot cpu mask: 0
    INFO:    plat_rockchip_pmu_init(1191): pd status 3e
    INFO:    BL31: Initializing runtime services
    WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
    ERROR:   Error initializing runtime service opteed_fast
    INFO:    BL31: Preparing for EL3 exit to normal world
    INFO:    Entry point address = 0x200000
    INFO:    SPSR = 0x3c9
    
    
    U-Boot 2020.07-armbian (Nov 25 2020 - 07:14:05 +0700)
    
    SoC: Rockchip rk3399
    Reset cause: POR
    DRAM:  3.9 GiB
    PMIC:  RK808
    SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
    MMC:   mmc@fe320000: 1, sdhci@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:   eth0: ethernet@fe300000
    scanning bus for devices...
    Hit any key to stop autoboot:  0
    switch to partitions #0, OK
    mmc1 is current device
    Scanning mmc 1:1...
    Found U-Boot script /boot/boot.scr
    3185 bytes read in 6 ms (517.6 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from mmc 1
    166 bytes read in 5 ms (32.2 KiB/s)
    14091886 bytes read in 600 ms (22.4 MiB/s)
    27331072 bytes read in 1157 ms (22.5 MiB/s)
    79946 bytes read in 13 ms (5.9 MiB/s)
    2698 bytes read in 10 ms (262.7 KiB/s)
    Applying kernel provided DT fixup script (rockchip-fixup.scr)
    ## Executing script at 09000000
    ## Loading init Ramdisk from Legacy Image at 06000000 ...
       Image Name:   uInitrd
       Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
       Data Size:    14091822 Bytes = 13.4 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 f5176000, end f5ee662e ... OK
       Loading Device Tree to 00000000f50fa000, end 00000000f5175fff ... OK
    
    Starting kernel ...
    

     

    Please take note at binaries version

    DDR Version 1.24 20191016 RevNocRL
    NOTICE:  BL31: Built : 14:31:03, May 19 2020
    U-Boot 2020.07-armbian (Nov 25 2020 - 07:14:05 +0700)

     

    Try to trigger the kernel crash.

     

    ---

    If you want to restore the original u-boot you can run

    apt install linux-u-boot-helios64-current=20.08.21

    and update the u-boot using armbian-config

    ---

     

    There is built in memory tester on Linux kernel,

    just add this line to /boot/armbianEnv.txt

    extraargs=memtest=10

    you can change number of loop (10). It took quite some time to run the test.

    you can see the result using dmesg

     

     

     

     

    linux-u-boot-current-helios64_20.11.0-trunk_arm64.deb

  4. LEGACY branch (Linux Kernel 4.4)
    Feature Support Status Remarks
    Shutdown Partial Fails to shutdown PMIC and triggers crash, HDD already parked
    Reboot Partial

    Similar like shutdown but Watchdog triggers the reboot so it appears successful

    Suspend to RAM Not Supported Fails to resume operation after wake up
    2.5G Ethernet
    (2.5G speed)
    OK  
    2.5G Ethernet
    (1G speed)
    Performance issue Requires hardware fix.
    Main Power/UPS Status OK Status can be read from sysfs
    Battery Charging Status Not Supported  
    UPS configuration OK

    Auto shutdown after 10 min of power loss.

    USB Type C - Host OK  
    USB Type C - Gadget OK Use g_mass_storage kernel module
    USB Type C - DisplayPort OK  
    eMMC Boot OK  
    SPI Boot Not Supported  
    Recovery Button OK

    To use maskrom, jumper P13 must be enabled.

    USB LED Not Supported  
    LAN LED Not Supported  
    Wake On LAN Not Supported

    Suspend still have issue

         

     

    Armbian 21.02

  5.  

    On 11/11/2020 at 4:08 PM, jbergler said:

    I also tried the suggestion to set a performance governor, and for shits and giggles I reduced the max cpu frequency, but that hasn’t made a difference.

    System still locks up within a few hours.

    What was the max cpu freq you set?

    Could you try with performance governor at 1.2GHz and at 816 MHz?

    How did you load the system?

     

     

    Did you encounter kernel crash on 20.08.10 ?
     

  6. To continue discussion from Helios64 Support

      

    17 hours ago, giddy said:

    I have a Helios Kobol64, I kept it off for a few hours.
    Now powering on, it stays stuck in "maintenance".
    No services start up.

    Before this, I followed the guide on https://wiki.kobol.io/helios64/install/emmc/ and installed the Armbian_20.08.13_Helios64_buster_current_5.8.16.img
    everything worked fine, and I have OMV on it, rebooted it several times.. no issues.
    Today, I started it, and nothing..
    I managed to connect to it via serial (usbc - COMPORT SERIAL)
    below is the output:
    ```

      Hide contents

     

    SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
    MMC:   mmc@fe320000: 1, sdhci@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:   eth0: ethernet@fe300000
    scanning bus for devices...
    Hit any key to stop autoboot:  0
    Card did not respond to voltage select!
    switch to partitions #0, OK
    mmc0(part 0) is current device
    Scanning mmc 0:1...
    Found U-Boot script /boot/boot.scr
    3185 bytes read in 18 ms (171.9 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from mmc 0
    166 bytes read in 15 ms (10.7 KiB/s)
    16002825 bytes read in 1539 ms (9.9 MiB/s)
    27331072 bytes read in 2610 ms (10 MiB/s)
    79946 bytes read in 44 ms (1.7 MiB/s)
    2698 bytes read in 39 ms (67.4 KiB/s)
    Applying kernel provided DT fixup script (rockchip-fixup.scr)
    ## Executing script at 09000000
    ## Loading init Ramdisk from Legacy Image at 06000000 ...
       Image Name:   uInitrd
       Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
       Data Size:    16002761 Bytes = 15.3 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 f4fa3000, end f5ee5ec9 ... OK
       Loading Device Tree to 00000000f4f27000, end 00000000f4fa2fff ... OK

    Starting kernel ...

    Give root password for maintenance
    (or press Control-D to continue):

     


    ```

    I am not able to login with any of the passwords (my own or defaults).
    I type `1234` return, it says incorrect login, I assume it only asking for root password not the username.


    I appreciate if anyone could help me please.

    Regards,
     

     

    Could you boot from micro SD card? Please use Armbian 20.08.10 image, version 20.08.13 known to have stability problem on many users.

    After setting up Armbian on the micro SD, reboot (to finish the setup) and login as root, you can check eMMC for filesystem error

    fsck -p /dev/mmcblk1p1

     

    You can try to change the password of Armbian on the eMMC:

    Spoiler

     

    
    mkdir -p /mnt/emmc
    mount /dev/mmcblk1p1 /mnt/emmc
    mount -o bind /proc /mnt/emmc/proc
    mount -o bind /sys /mnt/emmc/sys
    mount -o bind /dev /mnt/emmc/dev
    mount -o bind /dev/pts /mnt/emmc/dev/pts
    chroot /mnt/emmc/
    

     

    inside the chroot'd system, you can run

    passwd

    and set your password.

    You can

    exit

    the chroot, and do clean up

    
    umount /mnt/emmc/{dev/pts,dev,sys,proc}
    umount /mnt/emmc

     

     

    After finished you can poweroff the system, remove the micro SD card and power on the system again. See if you can boot to your system on eMMC.

     

     

     

  7. To continue discussion from Helios64 Support

      

    On 11/10/2020 at 5:29 AM, ShadowDance said:

    Hi, I've gone ahead and installed Armbian Buster (20.08.21) with root on ZFS (SATA) and I would like to boot from ZFS as well. However, I noticed u-boot isn't built with ZFS support enabled. I've worked around it for now by keeping /boot on eMMC but would it be possible to enable ZFS support in future builds? It can be enabled by building u-boot with CONFIG_CMD_ZFS defined. The benefits are that /boot can be snapshotted, rolled back, raid/mirror, etc along with root. I would also be quite happy building u-boot myself but I have no experience with it and I'd like to ensure that I can stay up-to-date with Helios64 patches, etc.

     

    In case anyone is interested, I've also done a few simplistic benchmarks for encryption using ZFS native encryption (aes-256-gcm) and ZFS on top of LUKS (aes-xts-plain64).

    • ZFS Native encryption: read ~60 MB/s / write ~65 MB/s
    • ZFS on LUKS: read ~210 MB/s / write >100MB/s (sorry for the inaccurate number, write speeds were capped by /dev/urandom)

    The pool was a single raidz2 vdev with 4 disks (one missing). Speeds were similar on both ZFS 0.8.5 and 2.0.0-rc5. Suffice to say, LUKS performs a lot better, ZFS native encryption is also very heavy on the CPU (think full cpu utilization @ 80C for as long as you're reading / writing). I'm hoping ZFS native encryption will be able to do better optimizations on ARM hardware in the future, but for now I'm going with LUKS.

     

    PS. I've also had to limit SATA speed to 3 Gbps for my disks via extraargs=libata.force=3.0, similar to another user in this thread (I had the same issue, also WD disks and they were being reset left and right without it).

     

    Noted, we will enable ZFS support after Armbian 20.11 released.

    I will need your help to test since i don't have system with ZFS.

  8. To continue discussion from Helios64 Support

     

    On 11/9/2020 at 11:39 PM, ebin-dev said:

     

    @aprayoga I am still interested in controlling the power of rail A and B. You mentioned that the power is controlled by the bootloader, but that the delay would be user configurable sometime.

     

    I would like to almost always power off rail A: In my use case rail A contains two hard disks supposed to alternatively back up the content of the SSDs in rail B - i.e once a day or even only once a week. The remaining time it would be beneficial to power off the hard drives in order to eliminate start/stop cycles and to make those drives inaccessible (protection against malware).

     

    Would there be a solution to make this user configurable - i.e by setting the delay to a very large number ? 

    Currently there is no plan to support to disable the power but it's interesting to know such use case.

    If we implemented this feature, you would need to go u-boot prompt to enable and disable the power. would this acceptable for you?

     

    Under Linux device tree, the power rail declared as regulator node with regulator-always-on property. This prevent kernel (and user) to turn off the regulator.

    Unless we are able to create device node for the SATA port, to act as consumer of the regulator, we can't remove the regulator-always-on property.

  9. CURRENT branch (Linux Kernel 5.10)
    Feature Support Status Remarks
    Shutdown OK  
    Reboot OK  
    Suspend to RAM Not Supported USB host controller refuses to enter suspend mode
    2.5G Ethernet
    (2.5G speed)
    OK

    TX offload disabled by default, can be enabled for better performance

    2.5G Ethernet
    (1G speed)
    Performance issue

    Requires hardware fix.

    Main Power/UPS status OK

    Status can be read from sysfs

    Battery Charging OK Status can be read from sysfs

    UPS configuration

    OK Auto shutdown after 10 min of power loss.
    USB Type C - Host OK use dwc3-0-host overlay. Enable P13 jumper to be able to use USB 2.0 device.
    USB Type C - Gadget OK use overlay to enable USB device mode. refer to this link
    USB Type C - DisplayPort OK  
    eMMC Boot OK  
    SPI Boot Not Supported  
    Recovery Button OK To use maskrom, jumper P13 must be enabled.
    USB LED Not Supported usbport led trigger does not support activity and only works with USB 2.0 device
    LAN LED OK

     default to eth0 activity

    Wake On LAN Not Supported Suspend still have issue

     

    Armbian 21.02

  10. 22 hours ago, AurelianRQ said:

    Apparently Kobol team recommended to stay off the new kernels and to use their recommended ones. The problem is that every few days I get the Red System error led flashing and the box is not reachable so I have to force restart it so I can have access to it again 

    and many many others. I don't see network activity as well on the front panel, is that pending as well ? It would be nice to have something functional that does not crash . Is this a hardware issue or just software issue ? 


    Running your image 5.8.14-rockchip64 #20.08.10 SMP PREEMPT Tue Oct 13 16:58:01 CEST 2020 aarch64 GNU/Linux

    It seem you get a kernel crash. You should connect to serial console to get the kernel crash log.
    The network activity led is still not implemented yet.

     

    20 hours ago, bverhagen said:

    Hi all,

     

    Last week I rendered my device unbootable by upgrading to 20.08.13 (it is stuck in U-boot rather than in starting the kernel though). This is 'known territory' though. So starting again from a vanilla install, 20.08.10 gets stuck in U-boot too, with the following error:

     

      Reveal hidden contents

    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
    Boot1: 2019-03-14, version: 1.19
    CPUId = 0x0
    ChipType = 0x10, 253
    SdmmcInit=2 0
    BootCapSize=100000
    UserCapSize=14910MB
    FwPartOffset=2000 , 100000
    mmc0:cmd5,20
    SdmmcInit=0 0
    BootCapSize=0
    UserCapSize=14792MB
    FwPartOffset=2000 , 0
    StorageInit ok = 66004
    SecureMode = 0
    SecureInit read PBA: 0x4
    SecureInit read PBA: 0x404
    SecureInit read PBA: 0x804
    SecureInit read PBA: 0xc04
    SecureInit read PBA: 0x1004
    SecureInit read PBA: 0x1404
    SecureInit read PBA: 0x1804
    SecureInit read PBA: 0x1c04
    SecureInit ret = 0, SecureMode = 0
    atags_set_bootdev: ret:(0)
    GPT 0x3380ec0 signature is wrong
    recovery gpt...
    GPT 0x3380ec0 signature is wrong
    recovery gpt fail!
    LoadTrust Addr:0x4000
    No find bl30.bin
    No find bl32.bin
    Load uboot, ReadLba = 2000
    Load OK, addr=0x200000, size=0xded88
    RunBL31 0x40000
    NOTICE:  BL31: v1.3(debug):42583b6
    NOTICE:  BL31: Built : 07:55:13, Oct 15 2019
    NOTICE:  BL31: Rockchip release version: v1.1
    INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
    INFO:    Using opteed sec cpu_context!
    INFO:    boot cpu mask: 0
    INFO:    plat_rockchip_pmu_init(1190): pd status 3e
    INFO:    BL31: Initializing runtime services
    WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
    ERROR:   Error initializing runtime service opteed_fast
    INFO:    BL31: Preparing for EL3 exit to normal world
    INFO:    Entry point address = 0x200000
    INFO:    SPSR = 0x3c9


    U-Boot 2020.07-armbian (Sep 23 2020 - 17:44:09 +0200)

    SoC: Rockchip rk3399
    Reset cause: POR
    DRAM:  3.9 GiB
    PMIC:  RK808
    SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
    MMC:   mmc@fe320000: 1, sdhci@fe330000: 0
    Loading Environment from MMC... unable to select a mode
    *** Warning - No block device, using default environment

    In:    serial
    Out:   serial
    Err:   serial
    Model: Helios64
    Revision: 1.2 - 4GB non ECC
    Net:   eth0: ethernet@fe300000
    scanning bus for devices...
    Hit any key to stop autoboot:  0
    switch to partitions #0, OK
    mmc1 is current device
    Scanning mmc 1:1...
    Found U-Boot script /boot/boot.scr
    3185 bytes read in 5 ms (622.1 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from mmc 1
    166 bytes read in 5 ms (32.2 KiB/s)
    14089265 bytes read in 599 ms (22.4 MiB/s)
    27275776 bytes read in 1156 ms (22.5 MiB/s)
    libfdt fdt_check_header(): FDT_ERR_BADMAGIC
    No FDT memory address configured. Please configure
    the FDT address via "fdt addr <address>" command.
    Aborting!
    2698 bytes read in 8 ms (329.1 KiB/s)
    Applying kernel provided DT fixup script (rockchip-fixup.scr)
    ## Executing script at 09000000
    ## Loading init Ramdisk from Legacy Image at 06000000 ...
       Image Name:   uInitrd
       Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
       Data Size:    14089201 Bytes = 13.4 MiB
       Load Address: 00000000
       Entry Point:  00000000
       Verifying Checksum ... OK
    ERROR: Did not find a cmdline Flattened Device Tree
       Loading Ramdisk to f5174000, end f5ee3bf1 ... OK
    FDT and ATAGS support not compiled in - hanging
    ### ERROR ### Please RESET the board ###

    Installing to either SD or the eMMC rendered the same issue.

    I had to revert to 20.08.4 for my device to properly boot again (from SD, as eMMC does not work yet for this release). Since the 5.8.14 kernel is considered stable, I followed https://blog.kobol.io/2020/10/27/helios64-software-issue/ to upgrade to that kernel from 20.08.4 (using armbian-config). Fearing I would draw in the bad 5.8.16 kernel, I did not update anything else from 20.08.4. Unfortunately, this once again rendered my device unbootable, with the same error message as above. So for me, 20.08.10 seems to be not stable too. The Helios64 wiki claims it is though and many users of this forum seem to have no issues with 20.08.10 either.

    After another fresh install of 20.08.4 - and no further upgrades - the Helios 64 is running stable for over a week now (it had been running on this version stable for a month previously too).

    So this finally gets me to my question: Does anyone have any idea what goes wrong here? Does anyone have any suggestions on how to debug this? Why is my device unable to boot a fresh image for the 'stable' 20.08.10 release? At no point in the lifetime of the NAS did I tinker with U-boot.

    You are using old U-Boot. It couldn't get the required device tree file. There was file renaming applied to Armbian 20.08.8 (released on 13 Oct 2020). You can do

    1. Get serial console

    2. When U-Boot appear, spam Enter key until you get U-Boot prompt (=> )

    3. enter this command

      

    setenv fdtfile "rockchip/rk3399-kobol-helios64.dtb"
    bootd

    4. After boot to Linux and login create symlink to new dtb

    sudo ln -sf rk3399-kobol-helios64.dtb /boot/dtb/rockchip/rk3399-helios64.dtb

    5. Upgrade the bootloader using armbian-config, System > Install > 5 Install/Update the bootloader on SD/eMMC

    On next boot you should see U-Boot with more recent build date.

     

    On 11/1/2020 at 11:28 AM, djurny said:

    Have not checked if the buttons can be disabled in software yet (https://wiki.kobol.io/helios64/button/), perhaps the PMIC can be programmed in user space?

    Unfortunately the Reset and Power button wired directly to PMIC and no configuration on the PMIC to disable it. However, short press Power button (graceful shutdown) can be disabled by editing /etc/systemd/logind.conf and set

    HandlePowerKey=ignore

     

  11. 10 hours ago, inconsistant said:

     

    My logs are actually from a serial console start up.  The logs I captured was a fresh SD card with 20.08.13 on the first time boot.

    You should see something like this when capturing serial console from power on

    Spoiler
    
    
    DDR Version 1.24 20191016
    In
    soft reset
    SRX
    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
    Boot1: 2019-03-14, version: 1.19
    CPUId = 0x0
    ChipType = 0x10, 324
    SdmmcInit=2 0
    BootCapSize=100000
    UserCapSize=14910MB
    FwPartOffset=2000 , 100000
    mmc0:cmd5,20
    SdmmcInit=0 0
    BootCapSize=0
    UserCapSize=15193MB
    FwPartOffset=2000 , 0
    StorageInit ok = 77398
    SecureMode = 0
    SecureInit read PBA: 0x4
    SecureInit read PBA: 0x404
    SecureInit read PBA: 0x804
    SecureInit read PBA: 0xc04
    SecureInit read PBA: 0x1004
    SecureInit read PBA: 0x1404
    SecureInit read PBA: 0x1804
    SecureInit read PBA: 0x1c04
    SecureInit ret = 0, SecureMode = 0
    atags_set_bootdev: ret:(0)
    GPT 0x3380ec0 signature is wrong
    recovery gpt...
    GPT 0x3380ec0 signature is wrong
    recovery gpt fail!
    LoadTrust Addr:0x4000
    No find bl30.bin
    No find bl32.bin
    Load uboot, ReadLba = 2000
    Load OK, addr=0x200000, size=0xdd6b0
    RunBL31 0x40000
    NOTICE:  BL31: v1.3(debug):42583b6
    NOTICE:  BL31: Built : 07:55:13, Oct 15 2019
    NOTICE:  BL31: Rockchip release version: v1.1
    INFO:    GICv3 with legacy support detected. ARM GICV3 driver initialized in EL3
    INFO:    Using opteed sec cpu_context!
    INFO:    boot cpu mask: 0
    INFO:    plat_rockchip_pmu_init(1190): pd status 3e
    INFO:    BL31: Initializing runtime services
    WARNING: No OPTEE provided by BL2 boot loader, Booting device without OPTEE initialization. SMC`s destined for OPTEE will return SMC_UNK
    ERROR:   Error initializing runtime service opteed_fast
    INFO:    BL31: Preparing for EL3 exit to normal world
    INFO:    Entry point address = 0x200000
    INFO:    SPSR = 0x3c9
    
    
    U-Boot 2020.07-armbian (Oct 19 2020 - 08:25:23 +0200)
    
    SoC: Rockchip rk3399
    Reset cause: RST
    DRAM:  3.9 GiB
    PMIC:  RK808
    SF: Detected w25q128 with page size 256 Bytes, erase size 4 KiB, total 16 MiB
    MMC:   mmc@fe320000: 1, sdhci@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:   eth0: ethernet@fe300000
    scanning bus for devices...
    Hit any key to stop autoboot:  0
    switch to partitions #0, OK
    mmc1 is current device
    Scanning mmc 1:1...
    Found U-Boot script /boot/boot.scr
    3185 bytes read in 5 ms (622.1 KiB/s)
    ## Executing script at 00500000
    Boot script loaded from mmc 1
    117 bytes read in 5 ms (22.5 KiB/s)
    14090231 bytes read in 600 ms (22.4 MiB/s)
    27275776 bytes read in 1158 ms (22.5 MiB/s)
    79946 bytes read in 13 ms (5.9 MiB/s)
    2698 bytes read in 9 ms (292 KiB/s)
    Applying kernel provided DT fixup script (rockchip-fixup.scr)
    ## Executing script at 09000000
    ## Loading init Ramdisk from Legacy Image at 06000000 ...
       Image Name:   uInitrd
       Image Type:   AArch64 Linux RAMDisk Image (gzip compressed)
       Data Size:    14090167 Bytes = 13.4 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 f5176000, end f5ee5fb7 ... OK
       Loading Device Tree to 00000000f50fa000, end 00000000f5175fff ... OK
    
    Starting kernel ...

     

     

     

    We are investigating what change causing this crash, what changes on upstream kernel could have an impact.

    Meanwhile, if you want to revert to previous kernel, 5.8.14, used on Armbian 20.08.10, you could use armbian-config > System > Other

    armbian-config_revert_kernel.png.f1cfbb0e8a81211bfde9764461c0f413.png

     

    or you could also get previous image from https://archive.armbian.com/helios64/archive/

     

  12. 22 hours ago, ebin-dev said:

    3.) how to control powering hdd rails A and B

    I forgot to answer this. the power staggering is handled by bootloader and not user configurable.
    We have tested various HDD brand/model and the highest current during spin up can go up to 7 seconds. We are considering the delay to be user configurable in future.

     

    10 hours ago, inconsistant said:

    Ran an update and now on 20.08.13 but getting errors immediately. Thought maybe it was something I had done so was preparing to start with a fresh install. First boot on SD with 20.08.13 gets the following error on boot.

     

      Reveal hidden contents

    [   26.679038] Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
    [   26.679536] Modules linked in: r8152 snd_soc_hdmi_codec hantro_vpu(C) rockchi                        p_vdec(C) snd_soc_rockchip_i2s rockchipdrm v4l2_h264 rockchip_rga videobuf2_dma_                        contig dw_mipi_dsi snd_soc_core zstd videobuf2_vmalloc videobuf2_dma_sg v4l2_mem                        2mem dw_hdmi videobuf2_memops snd_pcm_dmaengine analogix_dp leds_pwm snd_pcm vid                        eobuf2_v4l2 drm_kms_helper panfrost videobuf2_common snd_timer cec gpio_charger                         videodev gpu_sched rc_core snd pwm_fan sg soundcore fusb30x(C) mc drm drm_panel_                        orientation_quirks gpio_beeper cpufreq_dt zram lm75 ip_tables x_tables autofs4 r                        aid10 raid1 raid0 multipath linear raid456 async_raid6_recov async_memcpy async_                        pq async_xor async_tx realtek md_mod dwmac_rk stmmac_platform stmmac mdio_xpcs a                        dc_keys
    [   26.685159] CPU: 5 PID: 45 Comm: kworker/5:1 Tainted: G         C        5.8.                        16-rockchip64 #20.08.13
    [   26.685963] Hardware name: Helios64 (DT)
    [   26.686330] Workqueue: events dbs_work_handler
    [   26.686730] pstate: 00000085 (nzcv daIf -PAN -UAO BTYPE=--)
    [   26.687228] pc : do_undefinstr+0x2ec/0x310
    [   26.687594] lr : do_undefinstr+0x1e0/0x310
    [   26.687959] sp : ffff800011d6b320
    [   26.688256] x29: ffff800011d6b320 x28: ffff0000f66a1d00
    [   26.688730] x27: ffff0000f588ecf8 x26: ffff0000f66a1d00
    [   26.689202] x25: ffff8000119cf3a8 x24: 0000000001000001
    [   26.689675] x23: 0000000080000085 x22: ffff8000100101f8
    [   26.690148] x21: ffff800011d6b4d0 x20: ffff0000f66a1d00
    [   26.690620] x19: ffff800011d6b390 x18: 0000000000000000
    [   26.691092] x17: 0000000000000000 x16: 0000000000000000
    [   26.691563] x15: 0000000000000000 x14: 0000000000000137
    [   26.692036] x13: 0000000000000355 x12: 000000000000035d
    [   26.692507] x11: 0000000000000001 x10: 0000000000000a20
    [   26.692979] x9 : ffff800011d6b460 x8 : ffff0000f66a2780
    [   26.693450] x7 : 0000000000000001 x6 : ffff800011d6b378
    [   26.693922] x5 : 00000000d5300000 x4 : ffff800011806118
    [   26.694394] x3 : 0000000092800000 x2 : 0000000000000002
    [   26.694866] x1 : ffff0000f66a1d00 x0 : 0000000080000085
    [   26.695338] Call trace:
    [   26.695563]  do_undefinstr+0x2ec/0x310
    [   26.695903]  el1_sync_handler+0x88/0x110
    [   26.696255]  el1_sync+0x7c/0x100
    [   26.696548]  unwind_frame+0x78/0x1a0
    [   26.696869]  return_address+0x58/0x90
    [   26.697200]  preempt_count_add+0xb8/0x158
    [   26.697564]  _raw_spin_lock_irqsave+0x28/0xa0
    [   26.697954]  prepare_to_wait_event+0x24/0xe8
    [   26.698339]  rk3x_i2c_xfer+0x2c8/0x448
    [   26.698675]  __i2c_transfer+0x144/0x650
    [   26.699018]  i2c_transfer+0x60/0x128
    [   26.699338]  i2c_transfer_buffer_flags+0x5c/0x88
    [   26.699752]  regmap_i2c_write+0x20/0x58
    [   26.700099]  _regmap_raw_write_impl+0x6f8/0x8c0
    [   26.700504]  _regmap_bus_raw_write+0x68/0x88
    [   26.700886]  _regmap_write+0x6c/0x160
    [   26.701216]  _regmap_update_bits+0xf8/0x110
    [   26.701591]  regmap_update_bits_base+0x64/0x98
    [   26.701990]  regulator_set_voltage_sel_regmap+0x4c/0x98
    [   26.702458]  _regulator_call_set_voltage_sel+0x78/0xd0
    [   26.702916]  _regulator_do_set_voltage+0x474/0x5f0
    [   26.703343]  regulator_set_voltage_rdev+0xac/0x230
    [   26.703771]  regulator_do_balance_voltage+0x280/0x420
    [   26.704223]  regulator_balance_voltage+0x50/0x90
    [   26.704634]  regulator_set_voltage_unlocked+0x94/0x118
    [   26.705090]  regulator_set_voltage+0x50/0x90
    [   26.705474]  _set_opp_voltage+0x44/0x110
    [   26.705826]  dev_pm_opp_set_rate+0x250/0x618
    [   26.706213]  set_target+0x40/0x88 [cpufreq_dt]
    [   26.706611]  __cpufreq_driver_target+0x2c4/0x668
    [   26.707023]  od_dbs_update+0xbc/0x1a0
    [   26.707353]  dbs_work_handler+0x40/0x80
    [   26.707700]  process_one_work+0x1c4/0x470
    [   26.708060]  worker_thread+0x4c/0x420
    [   26.708391]  kthread+0x118/0x150
    [   26.708682]  ret_from_fork+0x10/0x34
    [   26.709006] Code: f9401bf7 17ffff7d a9025bf5 f9001bf7 (d4210000)
    [   26.709549] ---[ end trace 96ce5fbef0a4e2d9 ]---
    [   26.709961] note: kworker/5:1[45] exited with preempt_count 2
    [   26.710629] ------------[ cut here ]------------
    [   26.711057] WARNING: CPU: 5 PID: 0 at kernel/rcu/tree.c:618 rcu_eqs_enter.isr                        a.0+0x150/0x168
    [   26.711802] Modules linked in: r8152 snd_soc_hdmi_codec hantro_vpu(C) rockchi                        p_vdec(C) snd_soc_rockchip_i2s rockchipdrm v4l2_h264 rockchip_rga videobuf2_dma_                        contig dw_mipi_dsi snd_soc_core zstd videobuf2_vmalloc videobuf2_dma_sg v4l2_mem                        2mem dw_hdmi videobuf2_memops snd_pcm_dmaengine analogix_dp leds_pwm snd_pcm vid                        eobuf2_v4l2 drm_kms_helper panfrost videobuf2_common snd_timer cec gpio_charger                         videodev gpu_sched rc_core snd pwm_fan sg soundcore fusb30x(C) mc drm drm_panel_                        orientation_quirks gpio_beeper cpufreq_dt zram lm75 ip_tables x_tables autofs4 r                        aid10 raid1 raid0 multipath linear raid456 async_raid6_recov async_memcpy async_                        pq async_xor async_tx realtek md_mod dwmac_rk stmmac_platform stmmac mdio_xpcs a                        dc_keys
    [   26.717407] CPU: 5 PID: 0 Comm: swapper/5 Tainted: G      D  C        5.8.16-                        rockchip64 #20.08.13
    [   26.718188] Hardware name: Helios64 (DT)
    [   26.718541] pstate: 200003c5 (nzCv DAIF -PAN -UAO BTYPE=--)
    [   26.719037] pc : rcu_eqs_enter.isra.0+0x150/0x168
    [   26.719457] lr : rcu_eqs_enter.isra.0+0x1c/0x168
    [   26.719867] sp : ffff800011c5bf00
    [   26.720164] x29: ffff800011c5bf00 x28: 0000000000000000
    [   26.720636] x27: ffff0000f6ea6580 x26: 0000000000000000
    [   26.721109] x25: 0000000000000000 x24: ffff80001125f1f8
    [   26.721581] x23: ffff0000f6ea6580 x22: ffff8000114f2738
    [   26.722053] x21: ffff8000117fa2a0 x20: ffff8000117f9980
    [   26.722525] x19: ffff8000114f47c0 x18: 000000000000000e
    [   26.722997] x17: 0000000000000001 x16: 0000000000000019
    [   26.723468] x15: 0000000000000004 x14: 0000000000000149
    [   26.723940] x13: 0000000000000003 x12: 0000000000000000
    [   26.724412] x11: 0000000000000040 x10: ffff800011819518
    [   26.724884] x9 : ffff800011819510 x8 : ffff0000f6800028
    [   26.725356] x7 : 0000000000000000 x6 : 000000003be2522a
    [   26.725832] x5 : 00ffffffffffffff x4 : 0000000000002774
    [   26.726304] x3 : ffff8000114de018 x2 : 4000000000000000
    [   26.726776] x1 : 4000000000000002 x0 : ffff0000f77c87c0
    [   26.727248] Call trace:
    [   26.727472]  rcu_eqs_enter.isra.0+0x150/0x168
    [   26.727864]  rcu_idle_enter+0x10/0x20
    [   26.728193]  do_idle+0x20c/0x288
    [   26.728484]  cpu_startup_entry+0x28/0x68
    [   26.728837]  secondary_start_kernel+0x140/0x178
    [   26.729240] ---[ end trace 96ce5fbef0a4e2da ]---
    [   36.086089] EXT4-fs (mmcblk0p1): resized to 3670016 blocks
     

     

    Strange, that kind of crash should be fixed since 20.08.8. I don't encounter such crash on latest image. Could you get the serial console log start from power up?

  13. On 10/15/2020 at 2:11 PM, RaSca said:

    Hi everybody,

    as I mentioned on the helios64 site, there seems to be a problem with external USB drives.

    I've tried with two different of them that works perfectly on other systems, but not here.
    The first one, once connected (it doesn't matter front or rear), gives these messages:

     

    
    Oct 13 12:42:18 helios64 kernel: usb 2-1.3: USB disconnect, device number 8
    Oct 13 12:42:21 helios64 kernel: usb 2-1.2: new SuperSpeed Gen 1 USB device number 9 using xhci-hcd
    Oct 13 12:42:31 helios64 kernel: usb 2-1.2: New USB device found, idVendor=174c, idProduct=5106, bcdDevice= 0.01
    Oct 13 12:42:31 helios64 kernel: usb 2-1.2: New USB device strings: Mfr=2, Product=3, SerialNumber=1
    Oct 13 12:42:31 helios64 kernel: usb 2-1.2: Product: AS2105
    Oct 13 12:42:31 helios64 kernel: usb 2-1.2: Manufacturer: ASMedia
    Oct 13 12:42:37 helios64 kernel: usb 2-1.2: can't set config #1, error -110

    The second one:
     

    
    Oct 14 15:41:07 helios64 kernel: usb 1-1.3: new high-speed USB device number 55 using xhci-hcd
    Oct 14 15:41:07 helios64 kernel: usb 1-1.3: New USB device found, idVendor=1e68, idProduct=003a, bcdDevice= 1.32
    Oct 14 15:41:07 helios64 kernel: usb 1-1.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
    Oct 14 15:41:07 helios64 kernel: usb 1-1.3: Product: DS pocket light
    Oct 14 15:41:07 helios64 kernel: usb 1-1.3: Manufacturer: TrekStor
    Oct 14 15:41:07 helios64 kernel: usb 1-1.3: SerialNumber: 201108241936
    Oct 14 15:41:07 helios64 kernel: usb-storage 1-1.3:1.0: USB Mass Storage device detected
    Oct 14 15:41:07 helios64 kernel: scsi host5: usb-storage 1-1.3:1.0
    Oct 14 15:41:07 helios64 kernel: usb 1-1.3: USB disconnect, device number 55
    Oct 14 15:41:07 helios64 kernel: usb 1-1.3: new high-speed USB device number 56 using xhci-hcd
    Oct 14 15:41:08 helios64 kernel: usb 1-1.3: device descriptor read/all, error -71
    Oct 14 15:41:08 helios64 kernel: usb 1-1.3: new high-speed USB device number 57 using xhci-hcd
    Oct 14 15:41:09 helios64 kernel: usb 1-1.3: device descriptor read/64, error -71
    Oct 14 15:41:09 helios64 kernel: usb 1-1.3: Device not responding to setup address.
    Oct 14 15:41:10 helios64 kernel: usb 1-1.3: Device not responding to setup address.

     

     

    Any suggestion?

    Could you try edit the /boot/armbianEnv.txt and add idVendor and idProduct of your drive to usbstoragequirks ?

    usbstoragequirks=0x2537:0x1066:u,0x2537:0x1068:u,0x174c:0x5106:u,0x1e68:0x003a:u

    reboot the system and see whether your external USB drive can be recognized.

     

  14.  

    On 10/14/2020 at 4:13 PM, registr123 said:

    Controlling the LEDs.

     

    Hello, I am looking for the proper way to control the LEDs. (box facing front next to the TV etc.)

    
    
    Operating System: Armbian 20.08.9 Buster
    Kernel: Linux 5.8.13-rockchip64

     

    What I get is :

     

    
    
    root@helios64:/# echo "0" > /sys/devices/platform/io-gpio-leds/leds/helios64:blue:hdd-status/max_brightness
    -bash: /sys/devices/platform/io-gpio-leds/leds/helios64:blue:hdd-status/max_brightness: Permission denied

     

     

    :unsure:

     

    The LED brightness is not adjustable. You would need to use semi transparent plastic/tape to reduce the brightness, or change the resistor on front panel board.

     

    On 10/15/2020 at 1:36 AM, ebin-dev said:

     

    @aprayogaThe installation of a fresh 20.08.10 image to emmc using armbian-config and to boot from emmc works perfectly. Thank you.

     

    
    
    root@helios64:~# df -h
    Filesystem      Size  Used Avail Use% Mounted on
    udev            1.8G     0  1.8G   0% /dev
    tmpfs           381M  5.3M  375M   2% /run
    /dev/mmcblk1p1   15G  1.6G   12G  12% /
    tmpfs           1.9G     0  1.9G   0% /dev/shm
    tmpfs           5.0M  4.0K  5.0M   1% /run/lock
    tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
    tmpfs           1.9G  4.0K  1.9G   1% /tmp
    /dev/zram0       49M  160K   45M   1% /var/log
    tmpfs           381M     0  381M   0% /run/user/0

     

    P.S.: The way to install Armian to emmc with a u-boot only image as described here https://wiki.kobol.io/helios64/install/emmc/ did not work for me. I tried it using macOS, Ubuntu 20.04 and Windows. The issue is that Helios64 does not show up as an USB Drive.

    Does FTDI USB serial still connected to your PC? That image should switch USB MUX to RK3399 internal USB and you would see the FTDI disconnected on your PC.

    On Windows, if you ever installed rockusb driver then you would need uninstall it otherwise it will be recognized as rockusb device instead of usb drive.

     

     

    On 10/15/2020 at 6:14 PM, ebin-dev said:

     

    If the file /lib/systemd/system-shutdown/disable_auto_poweron is deleted  "auto power on" does not happen - it sits just there and waits for the power button to be pressed. Would you please explain any further actions necessary to "enable auto power on" ?

     

    The information about the power staggering approach of HDD Rails A and B is very interesting.  HDD rail A seem to refer to disks 3,4, and 5. They are powered up first. After about 10s disks 1 and 2 follow. Could you briefly explain how to enable/disable powering HDD rails A and B ?

    How did you test? After remove the file, shutdown the system and unplug the power supply, then the system would automatically power on without need to press power button when power supply re-plugged.

    Ah i just remember, do you have RTC battery or the UPS battery? the batteries is needed to make auto power on working correctly.

    More info will be described on the wiki.

     

    On 10/15/2020 at 10:02 PM, tekrantz said:

    As I am (as usual) doing something slightly different can someone tell me what module (or whatever) needs to me loaded to cause the /dev/fan* devices to exist?

     

    Thanks in advance!

     

     

    As mentioned by @flower, those are just symlinks generated by udev rules. The reason is similar like we have done in Helios4, the hwmon order could be changed depend on kernel version or kernel module loading order.

    With this symlink, fancontrol configuration can just refer to /dev/fan-*.

     

    On 10/16/2020 at 4:27 AM, axeleroy said:

    Hi,

     

    Not sure if this is the right place, but I cannot seem to boot Armbian 20.08.10 Kernel 5.8 from SD.
    After I unsuccessfully installed on a Samsung EVO SD Card, I tried once again on a Sandisk Ultra (this exact model) but it has been stuck on "Starting Kernel..." for more than 5 minutes.

    I'm not sure if it's just the first boot that takes a while or if I botched something. Also probably not helping is that the provided USB C to A cable is a bit loose and can easily be pulled from the board.

     

    Thanks!

    The first boot should not take time more than 5 minutes, unless you were using 64GB/128GB card. As suggested by other, you need to shave the cable so it can connect properly. You definitely need access to serial console for system setup.

     

    9 hours ago, Bethlehem said:

    The Linux 5.8 kernel is getting more and more stable now. I have to do a hard-reset on Helios64 at least once per day before and I rarely have to do it after Armbian 20.08.10. Although I am still waiting for the DAS mode to be sorted out on USB-C port (I never touched the USB-C port after getting OMV fixed up). 

     

    My only concern now is the CPU temperature. It sometimes runs up to around 65-70 C. I got a spare 2-pin cpu fan that I bought for my Raspberry Pi 4 and I think it could be installed onto the Helios64's heatsink. I just have to figure out where should the two power pins be put onto.

     

    Note.: I installed the OS on MicroSD card. I know EMMC would run faster but I am OK with the speed now.

    You could get supply for your fan from pin 1 or 2 and pin 3 on GPIO header but i'm not sure whether the additional fan would help much.

     

  15. Armbian 20.08.10 has been released with eMMC boot fixed.
    Please do a fresh install. If you want to boot from eMMC, you can transfer using armbian-config > System > Install > 2 Boot from eMMC - system on eMMC

  16. On 10/10/2020 at 12:09 AM, flower said:

    if someone wants to shutdown their unit on powerloss:

     

    create file: /etc/udev/rules.d/15-gpio-charger.rules

    
    SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/usr/sbin/halt"

     

    i'd love to know a way to start that unit when power is available again though.

     

    on 4.4 the system crashes on halt. but as it does this after all services are stopped and the disks are synced this is not really a problem.

    on 5.8 the system stops and "system halted" appears on serial console - BUT it is still on and fans are spinning.

     

    19 hours ago, ebin-dev said:

    @gprovost I think "auto power on" should be the default system behaviour - without requiring to set any gpio pins, since Helios64 will not operate 24/7 in most of the use cases. The easiest way to achieve that is to interrupt the power after a normal shutdown (i.e. using a DECT switch) and to automatically boot the device once the power is back on.

    you could re-enable auto power on by removing /lib/systemd/system-shutdown/disable_auto_poweron . You can check the file to see how to control the gpio pin for the auto power on feature.

    The auto power on is always enabled by bootloader.

     

     

    16 hours ago, alchemist said:

    Hi,

     

    Do the SPI boot work? Can I install u-boot on SPI and then boot sda1 from SPI?

     

    As @flower answered,  SPI boot is not yet working. Theoretically after boot from SPI  you could change boot target to first SATA drive

  17. On 10/6/2020 at 3:32 PM, flower said:

    Is there a way to update from legacy to current? 

    You could use armbian-config, System->Other to switch branch but we are not recommend it. It might break the system.

     

     

    11 hours ago, flower said:

    - is there a way to see if the battery is used? i'd like to write a service which shuts down the unit on powerloss

    You can poll /sys/class/power_supply/gpio-charger/online to check main power supply status.
     

    12 hours ago, flower said:

    - i get log messages about tx disconnect for r8152. followed by usb errors. iperf shows my transferrate correctly at 2.5gbits but file transfers hover around 80-150mb/s which is a bit slow

    Yes, this is performance issue mentioned on our table. Our iperf test shown, only a few first transfer correctly at 2.5gbits

    Spoiler


    
    root@helios64:~# iperf3 -s
    -----------------------------------------------------------
    Server listening on 5201
    -----------------------------------------------------------
    Accepted connection from 10.10.10.254, port 57412
    [  5] local 10.10.10.2 port 5201 connected to 10.10.10.254 port 57414
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-1.00   sec   265 MBytes  2.23 Gbits/sec                  
    [  5]   1.00-2.00   sec   280 MBytes  2.35 Gbits/sec                  
    [  5]   2.00-3.00   sec   277 MBytes  2.32 Gbits/sec                  
    [  5]   3.00-4.00   sec   280 MBytes  2.35 Gbits/sec                  
    [  5]   4.00-5.00   sec   255 MBytes  2.14 Gbits/sec                  
    [  5]   5.00-6.00   sec  0.00 Bytes  0.00 bits/sec                  
    [  5]   6.00-7.00   sec  0.00 Bytes  0.00 bits/sec                  
    [  5]   7.00-8.00   sec  0.00 Bytes  0.00 bits/sec                  
    [  5]   8.00-9.00   sec  0.00 Bytes  0.00 bits/sec                  
    [  5]   9.00-10.00  sec  0.00 Bytes  0.00 bits/sec                  
    [  5]  10.00-11.00  sec  0.00 Bytes  0.00 bits/sec                  
    [  5]  11.00-12.00  sec  0.00 Bytes  0.00 bits/sec                  
    [  5]  12.00-13.00  sec  0.00 Bytes  0.00 bits/sec                  
    [  5]  13.00-14.00  sec  0.00 Bytes  0.00 bits/sec                  
    [  5]  14.00-14.68  sec  0.00 Bytes  0.00 bits/sec                  
    - - - - - - - - - - - - - - - - - - - - - - - - -
    [ ID] Interval           Transfer     Bitrate
    [  5]   0.00-14.68  sec  1.33 GBytes   776 Mbits/sec                  receiver
    -----------------------------------------------------------
    Server listening on 5201
    -----------------------------------------------------------


     

     

     

×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines