Helios64 Support


gprovost
 Share

24 24

Recommended Posts

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?

 

 

Link to post
Share on other sites

Donate and support the project!

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
Link to post
Share on other sites

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

 

Link to post
Share on other sites

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=

 

Link to post
Share on other sites

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.

Link to post
Share on other sites

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,

 

Link to post
Share on other sites

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 ? 

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

 

Link to post
Share on other sites

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]

 

Link to post
Share on other sites

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).

Link to post
Share on other sites

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: 
 

 

Link to post
Share on other sites

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.

Link to post
Share on other sites

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! ]---

 

 

Link to post
Share on other sites

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)

 

Link to post
Share on other sites

@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 ?

Link to post
Share on other sites

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,

Link to post
Share on other sites

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,
 

Link to post
Share on other sites

@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'

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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.

 

Link to post
Share on other sites

  • Werner locked this topic
Guest
This topic is now closed to further replies.
 Share

24 24