Mize Posted November 8, 2020 Posted November 8, 2020 I accidentally broke my power adapter while adjusting the wires route (is my fault) now when I plug in the power adapter, the power adapter will not light up How or where can i buy the same power adapter According to the information on the power adapter, it is the r7b connector of 12V10A, right?
RockBian Posted November 8, 2020 Posted November 8, 2020 19 hours ago, barnumbirr said: Weird, htop on my Helios doesn't seem to be the armbian version anymore: no temperature, no frequency. Could you please share your APT sources.list so I can check I didn't accidentally overwrite mine. $ cat /etc/apt/sources.list deb http://deb.debian.org/debian buster main contrib non-free #deb-src http://deb.debian.org/debian buster main contrib non-free deb http://deb.debian.org/debian buster-updates main contrib non-free #deb-src http://deb.debian.org/debian buster-updates main contrib non-free deb http://deb.debian.org/debian buster-backports main contrib non-free #deb-src http://deb.debian.org/debian buster-backports main contrib non-free deb http://security.debian.org/ buster/updates main contrib non-free #deb-src http://security.debian.org/ buster/updates main contrib non-free $ cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com buster main buster-utils buster-desktop 2
barnumbirr Posted November 8, 2020 Posted November 8, 2020 5 hours ago, RockBian said: $ cat /etc/apt/sources.list deb http://deb.debian.org/debian buster main contrib non-free #deb-src http://deb.debian.org/debian buster main contrib non-free deb http://deb.debian.org/debian buster-updates main contrib non-free #deb-src http://deb.debian.org/debian buster-updates main contrib non-free deb http://deb.debian.org/debian buster-backports main contrib non-free #deb-src http://deb.debian.org/debian buster-backports main contrib non-free deb http://security.debian.org/ buster/updates main contrib non-free #deb-src http://security.debian.org/ buster/updates main contrib non-free $ cat /etc/apt/sources.list.d/armbian.list deb http://apt.armbian.com buster main buster-utils buster-desktop Thanks a lot! Something's up though because that's exactly the APT source list I have as well. I've even checked the htop version to make sure: root@helios64:~# apt-cache policy htop htop: Installed: 3.1.0-0~armbian20.08.2+1 Candidate: 3.1.0-0~armbian20.08.2+1 Version table: *** 3.1.0-0~armbian20.08.2+1 500 500 http://apt.armbian.com buster/buster-utils arm64 Packages 100 /var/lib/dpkg/status 2.2.0-5~armbian20.08.14+1 500 500 http://apt.armbian.com buster/buster-utils arm64 Packages 2.2.0-5~armbian20.08.1+1 500 500 http://apt.armbian.com buster/buster-utils arm64 Packages 2.2.0-3~armbian5.92+1 500 500 http://apt.armbian.com buster/buster-utils arm64 Packages
SIGSEGV Posted November 8, 2020 Posted November 8, 2020 You might want to check the configuration file for htop. sigsegv@helios64:~$ cat .config/htop/htoprc # Beware! This file is rewritten by htop when settings are changed in the interface. # The parser is also very primitive, and not human-friendly. fields=0 48 17 18 38 39 40 2 46 47 49 1 sort_key=1 sort_direction=1 hide_threads=0 hide_kernel_threads=1 hide_userland_threads=0 shadow_other_users=0 show_thread_names=0 show_program_path=1 highlight_base_name=0 highlight_megabytes=1 highlight_threads=1 tree_view=0 header_margin=1 detailed_cpu_time=0 cpu_count_from_zero=0 update_process_names=0 account_guest_in_cpu_meter=0 color_scheme=0 delay=15 left_meters=AllCPUs Memory Swap CpuTemp left_meter_modes=1 1 1 2 right_meters=Hostname Tasks LoadAverage Uptime CpuFreq Eth0 Eth0stat right_meter_modes=2 2 2 2 2 2 2 # SBC hardware and Kernel specific path. # Editable manually. BoardName= CpuFreq_handler= CpuTemp_handler= CpuVCore_l_handler= CpuVCore_b_handler= GpuVCore_handler= GpuTemp_handler= # Wlan / Eth alias eth0_alias=eth0 eth1_alias= wlan0_alias= wlan1_alias=
barnumbirr Posted November 9, 2020 Posted November 9, 2020 7 hours ago, SIGSEGV said: You might want to check the configuration file for htop. sigsegv@helios64:~$ cat .config/htop/htoprc # Beware! This file is rewritten by htop when settings are changed in the interface. # The parser is also very primitive, and not human-friendly. fields=0 48 17 18 38 39 40 2 46 47 49 1 sort_key=1 sort_direction=1 hide_threads=0 hide_kernel_threads=1 hide_userland_threads=0 shadow_other_users=0 show_thread_names=0 show_program_path=1 highlight_base_name=0 highlight_megabytes=1 highlight_threads=1 tree_view=0 header_margin=1 detailed_cpu_time=0 cpu_count_from_zero=0 update_process_names=0 account_guest_in_cpu_meter=0 color_scheme=0 delay=15 left_meters=AllCPUs Memory Swap CpuTemp left_meter_modes=1 1 1 2 right_meters=Hostname Tasks LoadAverage Uptime CpuFreq Eth0 Eth0stat right_meter_modes=2 2 2 2 2 2 2 # SBC hardware and Kernel specific path. # Editable manually. BoardName= CpuFreq_handler= CpuTemp_handler= CpuVCore_l_handler= CpuVCore_b_handler= GpuVCore_handler= GpuTemp_handler= # Wlan / Eth alias eth0_alias=eth0 eth1_alias= wlan0_alias= wlan1_alias= Nice catch, that did the trick! Still have to figure out how to prevent updates to /etc/fancontrol then I'll be golden.
gprovost Posted November 9, 2020 Author Posted November 9, 2020 19 hours ago, Mize said: I accidentally broke my power adapter while adjusting the wires route (is my fault) Please contact us to support@kobol.io if you want to order a new PSU.
JeffDwork Posted November 9, 2020 Posted November 9, 2020 What are you all using for stress testing? Is there something better than iozone ? I don't have an array - just 5 individual disks - to be accessed by NFS and samba. I'm running plain armbian ubuntu. I really want to run this thing before I trust it with my data. Thanks, Jeff
djurny Posted November 9, 2020 Posted November 9, 2020 6 minutes ago, JeffDwork said: What are you all using for stress testing? Is there something better than iozone ? I don't have an array - just 5 individual disks - to be accessed by NFS and samba. I'm running plain armbian ubuntu. I really want to run this thing before I trust it with my data. Thanks, Jeff Hi @JeffDwork, I have used snapraid for testing, and running md5sums on all the content on the disks. Once to 'sync' or create MD5 hashes, subsequent runs to 'scrub' or check MD5 hashes. This gave me some warm feeling on how fast the system can calculate hashes and how fast the disk I/O is. This would then give me a good indication on scheduling maintenance actions, e.g. if 'scrub' takes 12 hours, need to make sure it does not push out or overlap other scheduled maintenance actions etc. Overall, it will depend on what you care about the most; CPU performance/temperature, disk throughput, filesystem reliability, system stability or perhaps other factors. Groetjes,
ebin-dev Posted November 9, 2020 Posted November 9, 2020 On 10/20/2020 at 6:45 AM, aprayoga said: 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. @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 ?
Jaques-Ludwig Posted November 9, 2020 Posted November 9, 2020 I have installed Debian OS on eMMC. Now I want to install Debian on a SD-Card to boot from there. I thought I do Backup of eMMC with fsarchiver and restore it on a SD-Card. Then to put the SD-Card on the back of the Helios-NAS. Is Helios64 booting now from SD-Card or eMMC? How can I see it? Both memories are shown in the drive-section of OMV. What do I have to do, if I don't want to start from eMMC anymore? Do I have to delete it and if yes, how does it work? Is it possible to switch through both boot-modes? Thanks a lot, Jaques-Ludwig
ebin-dev Posted November 9, 2020 Posted November 9, 2020 10 hours ago, Jaques-Ludwig said: What do I have to do, if I don't want to start from eMMC anymore? You can see the current root medium by typing 'df -h'. I think this was already addressed in this thread. If there is a system installed on emmc and on SD (SD inserted), then Helios64 will always boot from SD with the current bootloader (factory default settings). If the SD is not inserted, then the system will boot from emmc.
TDCroPower Posted November 9, 2020 Posted November 9, 2020 vor einer Stunde schrieb Jaques-Ludwig: I have installed Debian OS on eMMC. Now I want to install Debian on a SD-Card to boot from there. I thought I do Backup of eMMC with fsarchiver and restore it on a SD-Card. Then to put the SD-Card on the back of the Helios-NAS. Is Helios64 booting now from SD-Card or eMMC? How can I see it? Both memories are shown in the drive-section of OMV. What do I have to do, if I don't want to start from eMMC anymore? Do I have to delete it and if yes, how does it work? Is it possible to switch through both boot-modes? Thanks a lot, Jaques-Ludwig you can use the boot mode jumper to switch between eMMC (P10) and microSD (P11) boot, see the Helios wiki... https://wiki.kobol.io/helios64/jumper/ @Helios Team... what is the current image status? Is it now possible to upgrade from 20.08.10 to the current version? By now we are already at 20.08.22... armbian-config/buster,buster 20.08.22 all [upgradable from: 20.08.10] armbian-firmware/buster,buster 20.08.22 all [upgradable from: 20.08.10] libfreetype6/stable,stable 2.9.1-3+deb10u2 arm64 [upgradable from: 2.9.1-3+deb10u1] libldap-2.4-2/stable,stable 2.4.47+dfsg-3+deb10u3 arm64 [upgradable from: 2.4.47+dfsg-3+deb10u2] libldap-common/stable,stable,stable,stable 2.4.47+dfsg-3+deb10u3 all [upgradable from: 2.4.47+dfsg-3+deb10u2] linux-buster-root-current-helios64/buster 20.08.21 arm64 [upgradable from: 20.08.10] linux-dtb-current-rockchip64/buster 20.08.21 arm64 [upgradable from: 20.08.10] linux-image-current-rockchip64/buster 20.08.21 arm64 [upgradable from: 20.08.10] linux-libc-dev/stable,stable 4.19.152-1 arm64 [upgradable from: 4.19.146-1] linux-u-boot-helios64-current/buster 20.08.21 arm64 [upgradable from: 20.08.10] openmediavault-omvextrasorg/buster,buster 5.4.2 all [upgradable from: 5.4.1] openmediavault/usul,usul,usul,usul 5.5.16-1 all [upgradable from: 5.5.12-1] salt-common/usul,usul,usul,usul 3002.1+ds-1 all [upgradable from: 3001.1+ds-1] salt-minion/usul,usul,usul,usul 3002.1+ds-1 all [upgradable from: 3001.1+ds-1] tzdata/stable-updates,stable-updates 2020d-0+deb10u1 all [upgradable from: 2020a-0+deb10u1] 1
ShadowDance Posted November 9, 2020 Posted November 9, 2020 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).
jbergler Posted November 10, 2020 Posted November 10, 2020 Have there been any changes to how the serial console is initialised? I previously had no issues using the serial console to interact with uboot, but now the serial console doesn't seem to initialise until linux boots, and even then there's a bunch of gibberish until the tty does something. [ 326.906283] reboot: Restarting system 7�[�A5_U�zz�=E:�{�;:���/{��_�Z{�h^�;���[�xz��ap��E^�x^��[6zp��xz{[��[���>va[/{=A5_U�zz�=E:�s�?:���/{��_�[{�h^�;���Z[xz?z��ap��E^�x^��[6zp��xz{[��;'~E){=a[{=Armbian 20.08.21 Focal ttyS2 helios64 login:
Igor Posted November 10, 2020 Posted November 10, 2020 9 hours ago, TDCroPower said: By now we are already at 20.08.22 Patch versions are reserved for emergency fixes, but we don't necessarily update all kernels. We need to test things before pushing out update to minimize unpleasant surprises. A major update (20.11) is around the corner and things will be updated then. 1
gprovost Posted November 10, 2020 Author Posted November 10, 2020 9 hours ago, TDCroPower said: @Helios Team... what is the current image status? Is it now possible to upgrade from 20.08.10 to the current version? By now we are already at 20.08.22... Yes you can upgrade. The issue of instability wasn't related to the kernel actually but to some silly bug in Armbian hardware optimization script. 1
jbergler Posted November 10, 2020 Posted November 10, 2020 I'm still seeing regular panics, to the point where the box won't stay up for more than a few hours. To ensure it was in a clean state, I re-installed 20.08.21 focal and only added samba + zfs back. Spoiler [13245.115739] Unable to handle kernel paging request at virtual address 7ff60000f77a94f0 [13245.116452] Mem abort info: [13245.116700] ESR = 0x96000004 [13245.116976] EC = 0x25: DABT (current EL), IL = 32 bits [13245.117441] SET = 0, FnV = 0 [13245.117711] EA = 0, S1PTW = 0 [13245.117988] Data abort info: [13245.118243] ISV = 0, ISS = 0x00000004 [13245.118579] CM = 0, WnR = 0 [13245.118842] [7ff60000f77a94f0] address between user and kernel address ranges [13245.119469] Internal error: Oops: 96000004 [#1] PREEMPT SMP [13245.119960] Modules linked in: xt_conntrack xt_MASQUERADE nf_conntrack_netlink nfnetlink xfrm_user xfrm_algo xt_addrtype iptable_filter iptable_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 bpfilter br_netfilter bridge rfkill governor_performance zfs(POE) zunicode(POE) zzstd(OE) zlua(OE) zcommon(POE) znvpair(POE) zavl(POE) icp(POE) spl(OE) r8152 snd_soc_hdmi_codec leds_pwm gpio_charger pwm_fan snd_soc_rockchip_i2s snd_soc_core snd_pcm_dmaengine snd_pcm snd_timer snd soundcore panfrost gpu_sched fusb30x(C) hantro_vpu(C) rockchip_vdec(C) rockchip_rga v4l2_h264 videobuf2_dma_contig videobuf2_dma_sg v4l2_mem2mem videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_common videodev mc sg gpio_beeper cpufreq_dt zstd zram sch_fq_codel lm75 ip_tables x_tables autofs4 raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx raid1 raid0 multipath linear md_mod realtek dwmac_rk stmmac_platform stmmac mdio_xpcs rockchipdrm analogix_dp dw_hdmi dw_mipi_dsi drm_kms_helper [13245.120050] cec rc_core drm drm_panel_orientation_quirks adc_keys [13245.128189] CPU: 4 PID: 0 Comm: swapper/4 Tainted: P C OE 5.8.17-rockchip64 #20.08.21 [13245.128964] Hardware name: Helios64 (DT) [13245.129312] pstate: 40000085 (nZcv daIf -PAN -UAO BTYPE=--) [13245.129811] pc : __schedule+0xb4/0x808 [13245.130142] lr : __schedule+0xb4/0x808 [13245.130471] sp : ffff800011ba3ea0 [13245.130763] x29: ffff800011ba3ea0 x28: ffff0000f6ea5700 [13245.131229] x27: ffff800011a10000 x26: 0000000000000000 [13245.131695] x25: 0000000000000000 x24: ffff800011809980 [13245.132160] x23: ffff0000f6ea5700 x22: 0000000000000000 [13245.132626] x21: ffff800010dfc8b0 x20: ffff0000f6ea5700 [13245.133091] x19: 7ff60000f77a8b40 x18: 0000000000000014 [13245.133556] x17: 0000000088c8bd3f x16: 00000000fe39365a [13245.134021] x15: 00000000a4a528e1 x14: 0000000100316213 [13245.134487] x13: 0000000000000101 x12: 0000000000000110 [13245.134952] x11: 0000000000000001 x10: 0000000000000a20 [13245.135418] x9 : ffff800011ba3e70 x8 : ffff0000f6ea6180 [13245.135883] x7 : 00000000ffffffff x6 : 0000004a1d089376 [13245.136349] x5 : 00ffffffffffffff x4 : ffff0000f77a9898 [13245.136815] x3 : 0000000000000000 x2 : 0000000000000000 [13245.137280] x1 : 182800a06258e900 x0 : 0000000000000000 [13245.137746] Call trace: [13245.137966] __schedule+0xb4/0x808 [13245.138267] schedule_idle+0x28/0x48 [13245.138585] do_idle+0x184/0x288 [13245.138870] cpu_startup_entry+0x28/0x68 [13245.139221] secondary_start_kernel+0x140/0x178 [13245.139621] Code: 2a1903e0 97cc5f9e aa1303e0 9400189e (b949b260) [13245.140163] ---[ end trace c9acabedf32c9896 ]--- [13245.140569] Kernel panic - not syncing: Attempted to kill the idle task! [13245.141156] SMP: stopping secondary CPUs [13246.308168] SMP: failed to stop secondary CPUs 0,4 [13246.308588] Kernel Offset: disabled [13246.308895] CPU features: 0x240022,2000600c [13246.309261] Memory Limit: none [13246.309538] ---[ end Kernel panic - not syncing: Attempted to kill the idle task! ]---
ShadowDance Posted November 10, 2020 Posted November 10, 2020 (edited) @jbergler I had the same issue with panics on 20.08.21 Buster (also using ZFS). Problem went away after I switched from ondemand to performance governor via armbian-config. Edited November 10, 2020 by ShadowDance add "switched from ondemand" 2
aldweb Posted November 10, 2020 Posted November 10, 2020 Hello, Everything seems OK with my device sor far. But, within OMV, I do not have any of the performance statistics displayed. Any idea of what could be done to get those? Regards, aldweb
SIGSEGV Posted November 10, 2020 Posted November 10, 2020 Can the Helios 64 be used for hosting iSCSI targets?? @gprovost @aprayoga Installing targetcli-fb on 20.08.21 Focal fails with a error about a missing kernel module. #apt install tuned targetcli-fb Setting up python3-rtslib-fb (2.1.71-0ubuntu1) ... Job for rtslib-fb-targetctl.service failed because the control process exited with error code. See "systemctl status rtslib-fb-targetctl.service" and "journalctl -xe" for details. invoke-rc.d: initscript rtslib-fb-targetctl, action "start" failed. ● rtslib-fb-targetctl.service - Restore LIO kernel target configuration Loaded: loaded (/lib/systemd/system/rtslib-fb-targetctl.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Fri 2020-11-06 23:11:03 CST; 50ms ago Process: 14105 ExecStart=/usr/bin/mkdir -p /etc/rtslib-fb-target (code=exited, status=0/SUCCESS) Process: 14109 ExecStart=/usr/bin/targetctl restore (code=exited, status=1/FAILURE) Main PID: 14109 (code=exited, status=1/FAILURE) Nov 06 23:11:03 helios64 target[14109]: File "/usr/bin/targetctl", line 47, in restore Nov 06 23:11:03 helios64 target[14109]: errors = RTSRoot().restore_from_file(restore_file=from_file) Nov 06 23:11:03 helios64 target[14109]: File "/usr/lib/python3/dist-packages/rtslib_fb/root.py", line 85, in __init__ Nov 06 23:11:03 helios64 target[14109]: modprobe('target_core_mod') Nov 06 23:11:03 helios64 target[14109]: File "/usr/lib/python3/dist-packages/rtslib_fb/utils.py", line 428, in modprobe Nov 06 23:11:03 helios64 target[14109]: raise RTSLibError(stderrdata) Nov 06 23:11:03 helios64 target[14109]: rtslib_fb.utils.RTSLibError: b'modprobe: FATAL: Module target_core_mod not found in directory /lib/modules/5.8.17-rockchip64\n' Nov 06 23:11:03 helios64 systemd[1]: rtslib-fb-targetctl.service: Main process exited, code=exited, status=1/FAILURE Nov 06 23:11:03 helios64 systemd[1]: rtslib-fb-targetctl.service: Failed with result 'exit-code'. Nov 06 23:11:03 helios64 systemd[1]: Failed to start Restore LIO kernel target configuration. dpkg: error processing package python3-rtslib-fb (--configure): installed python3-rtslib-fb package post-installation script subprocess returned error exit status 1 dpkg: dependency problems prevent configuration of targetcli-fb: targetcli-fb depends on python3-rtslib-fb (>= 2.1.62); however: Package python3-rtslib-fb is not configured yet. dpkg: error processing package targetcli-fb (--configure): dependency problems - leaving unconfigured Processing triggers for man-db (2.9.1-1) ... Processing triggers for dbus (1.12.16-2ubuntu2.1) ... Processing triggers for systemd (245.4-4ubuntu3.3) ... Errors were encountered while processing: python3-rtslib-fb targetcli-fb E: Sub-process /usr/bin/dpkg returned an error code (1)
gprovost Posted November 11, 2020 Author Posted November 11, 2020 @jbergler @ShadowDance Can you guys just check that the return value of the following is not 0 cat /proc/sys/net/core/rps_sock_flow_entries Just to be sure that even after you upgraded the system the hw optimization script is being properly executed. 7 hours ago, jbergler said: To ensure it was in a clean state, I re-installed 20.08.21 focal and only added samba + zfs back. You mean even after clean install you still have the instability issue ?
jbergler Posted November 11, 2020 Posted November 11, 2020 root@helios64:~# cat /proc/sys/net/core/rps_sock_flow_entries 32768 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. I did finally manage to get the serial console to print something meaningful during boot, and one thing that stands out is this Loading Environment from MMC... *** Warning - bad CRC, using default environment Full boot log is below Spoiler DDR Version 1.24 20191016 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, 254 SdmmcInit=2 0 BootCapSize=100000 UserCapSize=14910MB FwPartOffset=2000 , 100000 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 mmc0:cmd8,20 mmc0:cmd5,20 mmc0:cmd55,20 mmc0:cmd1,20 SdmmcInit=0 1 StorageInit ok = 67811 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 31 2020 - 08:21:38 +0100) 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 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 193 bytes read in 15 ms (11.7 KiB/s) 16364137 bytes read in 1576 ms (9.9 MiB/s) 27331072 bytes read in 2614 ms (10 MiB/s) 79946 bytes read in 39 ms (2 MiB/s) 2698 bytes read in 32 ms (82 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: 16364073 Bytes = 15.6 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 f4f4b000, end f5ee6229 ... OK Loading Device Tree to 00000000f4ecf000, end 00000000f4f4afff ... OK Starting kernel ... [ 16.262031] OF: graph: no port node found in /syscon@ff770000/usb2-phy@e450/otg-port [ 16.620006] systemd[1]: Failed to start Set console font and keymap. [ 17.073543] r8152 2-1.4:1.0 (unnamed net_device) (uninitialized): netif_napi_add() called with weight 256 Armbian 20.08.21 Focal ttyS2 helios64 login: 5 hours ago, gprovost said: You mean even after clean install you still have the instability issue ? Yes,
Igor Posted November 11, 2020 Posted November 11, 2020 45 minutes ago, jbergler said: Loading Environment from MMC... *** Warning - bad CRC, using default environment That is expected and normal. https://forums.xilinx.com/t5/Embedded-Linux/U-Boot-Initialization-Issues/td-p/983852 1
giddy Posted November 11, 2020 Posted November 11, 2020 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: ``` Spoiler 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,
SIGSEGV Posted November 11, 2020 Posted November 11, 2020 @Igor Would it be possible to enable CONFIG_TARGET_CORE on the kernel so that module 'target_core_mod' is included in the directory /lib/modules/5.8.17-rockchip64 ?? The objective is to enable iSCSI target mode on the installation - making the Helios64 board able to serve as SAN server. At this moment it's missing and the package targetcli-fb fails to work correctly on both Focal and Buster latest images, with error: 'modprobe: FATAL: Module target_core_mod not found in directory /lib/modules/5.8.17-rockchip64'
Igor Posted November 11, 2020 Posted November 11, 2020 1 hour ago, SIGSEGV said: Would it be possible to enable CONFIG_TARGET_CORE on the kernel so that module 'target_core_mod' is included in the directory /lib/modules/5.8.17-rockchip64 ?? There was one related PR https://github.com/armbian/build/pull/2300 and it was already merged but I am not sure its in the build yet. That not enough? In general - if anything is missing - just make a PR with changes to config. I can't possible keep an eye on everything, rockchip64* but preferable generic goes to all: https://github.com/armbian/build/tree/master/config/kernel
SIGSEGV Posted November 11, 2020 Posted November 11, 2020 31 minutes ago, Igor said: There was one related PR https://github.com/armbian/build/pull/2300 and it was already merged but I am not sure its in the build yet. That not enough? In general - if anything is missing - just make a PR with changes to config. I can't possible keep an eye on everything, rockchip64* but preferable generic goes to all: https://github.com/armbian/build/tree/master/config/kernel Thanks Igor, I'll check the repository and create the PR if needed.
Werner Posted November 12, 2020 Posted November 12, 2020 As announced here Kobol got a dedicated place for their producs. Therefore it is no longer necessary to have one hugh thread collecting everything related to this particular board. Now you can create new topics for each new issue/problem/question which greatly will increase readability and overall clarity. This topic is being archived and locked.
Recommended Posts