Helios64 Support

aprayoga · October 19, 2020

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

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.

Edited October 19, 2020 by aprayoga

aprayoga · October 19, 2020

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.

ebin-dev · October 19, 2020

5 hours ago, aprayoga said:

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.

@aprayoga Thanks for your reply. Your guess was just right - I have temporarily disconnected the UPS battery before I was experimenting with various system configurations so that I would be able to recover from a hanging system by disconnecting the main power.

If you are improving the wiki pages - there are actually at least three topics of interest:

1.) how to enable "auto power on"

2.) how to use the RTC to automatically start the system at predefined times

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

raoulh · October 19, 2020

Hi,

I tried different version, but the result are the same. I can't get correct speed with ethernet, be it the 2.5G or the 1G.

I installed armbian focal 20.08.10. The helio64 is connected through a 10G switch on eth1, and on another 1g switch on eth0.

I did some iperf tests and this is what I'm getting for both connections:

This is with eth0

➜  ~ iperf3 -c 192.168.0.86 -p 12345  
Connecting to host 192.168.0.86, port 12345
[  5] local 192.168.0.238 port 58950 connected to 192.168.0.86 port 12345
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  67.4 MBytes   565 Mbits/sec  611   17.0 KBytes        
[  5]   1.00-2.00   sec  68.0 MBytes   571 Mbits/sec  606   18.4 KBytes        
[  5]   2.00-3.00   sec  69.6 MBytes   584 Mbits/sec  633   18.4 KBytes        
[  5]   3.00-4.00   sec  69.3 MBytes   582 Mbits/sec  604   19.8 KBytes        
[  5]   4.00-5.00   sec  70.0 MBytes   587 Mbits/sec  589   19.8 KBytes        
[  5]   5.00-6.00   sec  71.3 MBytes   598 Mbits/sec  613   19.8 KBytes        
[  5]   6.00-7.00   sec  70.5 MBytes   591 Mbits/sec  570   19.8 KBytes        
[  5]   7.00-8.00   sec  67.8 MBytes   569 Mbits/sec  530   17.0 KBytes        
[  5]   8.00-9.00   sec  69.9 MBytes   586 Mbits/sec  580   32.5 KBytes        
[  5]   9.00-10.00  sec  69.4 MBytes   582 Mbits/sec  561   15.6 KBytes        
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   693 MBytes   582 Mbits/sec  5897             sender
[  5]   0.00-10.00  sec   693 MBytes   581 Mbits/sec                  receiver

And this for eth1

➜  ~ iperf3 -c 192.168.0.87 -p 12345
Connecting to host 192.168.0.87, port 12345
[  5] local 192.168.0.238 port 51834 connected to 192.168.0.87 port 12345
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  65.6 MBytes   550 Mbits/sec  566   17.0 KBytes        
[  5]   1.00-2.00   sec  69.0 MBytes   579 Mbits/sec  613   18.4 KBytes        
[  5]   2.00-3.00   sec  69.3 MBytes   582 Mbits/sec  620   19.8 KBytes        
[  5]   3.00-4.00   sec  69.5 MBytes   583 Mbits/sec  617   18.4 KBytes        
[  5]   4.00-5.00   sec  69.2 MBytes   581 Mbits/sec  623   21.2 KBytes        
[  5]   5.00-6.00   sec  63.0 MBytes   529 Mbits/sec  460   17.0 KBytes        
[  5]   6.00-7.00   sec  66.7 MBytes   559 Mbits/sec  521   19.8 KBytes        
[  5]   7.00-8.00   sec  68.5 MBytes   575 Mbits/sec  559   29.7 KBytes        
[  5]   8.00-9.00   sec  70.0 MBytes   587 Mbits/sec  565   26.9 KBytes        
[  5]   9.00-10.00  sec  71.2 MBytes   597 Mbits/sec  563   19.8 KBytes        
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   682 MBytes   572 Mbits/sec  5707             sender
[  5]   0.00-10.00  sec   682 MBytes   572 Mbits/sec                  receiver

Something is wrong here... Any idea of the cause of not getting full bandwidth?

Another unrelated issue I had is I wanted to use the helios64 as a iSCSI target and wanted to configure LIO. The problem is that the armbian kernel config does not have those options enabled as modules:

CONFIG_TARGET_CORE=m
CONFIG_TCM_IBLOCK=m
CONFIG_TCM_FILEIO=m
CONFIG_TCM_PSCSI=m
CONFIG_TCM_USER2=m

I did rebuild an armbian kernel with those enabled, and I can get iSCSI target working on the helios64.

Could it be possible to include those options for the next armbian release? I think having iSCSI is a must have for helios64.

Thanks

gprovost · October 19, 2020

2 minutes ago, raoulh said:

I tried different version, but the result are the same. I can't get correct speed with ethernet, be it the 2.5G or the 1G.

I installed armbian focal 20.08.10. The helio64 is connected through a 10G switch on eth1, and on another 1g switch on eth0.

We will do an announcement soon but we realized we made a design mistake on the Helios64 2.5GbE port (LAN2 | eth1) which makes it not perform well in 1000Mb/s mode, however no impact in 2500baseT mode.

Regarding your iperf test, seems a bit funny. You sure your routing table is correct for traffic to go really to the expected interface since you are on the same subnet.

Can you do the same tests, but for each test disconnect the cable of the interface you are not testing.... or at least use different subnet.

Also can you check interface speed with ethtool (ethtool eth0 and ethtool eth1).

flower · October 19, 2020

18 minutes ago, gprovost said:

We will do an announcement soon but we realized we made a design mistake on the Helios64 2.5GbE port (LAN2 | eth1) which makes it not perform well in 1000Mb/s mode, however no impact in 2500baseT mode.

Does this mean i can enable tx offloading again?

It is connected to a 2.5gbe switch

gprovost · October 19, 2020

7 minutes ago, flower said:

Does this mean i can enable tx offloading again?

No this is not related to tx offloading. For now we still don't know why tx offloading needs to be disabled on LK5.8, while on LK4.4 it works without issue.

RaSca · October 19, 2020

2 hours ago, aprayoga said:
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.

Hey aprayoga, thanks for your answer, I would have answered earlier, but it seems that I can't post more than ONE (!) message per day on this forum, we need to find a better way to interact with users, because it is hard to both follow discussions and search in this one single immense thread.

BTW, following the fact that with a powered USB HUB I was able to see both disks, I took a cable with the double end (one for data and the other one for the power), connected both to the two back ports, and both disks are now usable. It is in any case strange, because I can connect these disks with just the single data cable to any raspberry and work on them, but for me this is an acceptable workaround, instead of playing with the /boot/armbianEnv.txt boot parameters.

Werner · October 19, 2020

11 minutes ago, RaSca said:

but it seems that I can't post more than ONE (!) message per day on this forum,

This restriction applies to all new users. You can thank all the spamers out there which try to abuse forums to spread their BS.

You received a like which will lift the restrictions for you either immediately or after next cron batch. Not sure.

Borromini · October 19, 2020

@flower and @barnumbirr Which Noctua fans did you get?

Also curious if anyone has installed a dust filter behind the front grille.

Thanks!

antsu · October 19, 2020

4 hours ago, RamsDeep said:

Is there a How-To for deploying ZFS anywhere?

I am a beginner and figuring this out as I go.

Installing the module from OMV does not appear to work for me currently

Thanks

Use kernel 5.8 and follow the instructions on the thread above.

flower · October 19, 2020

For reference: this is my test on 2.5Gbe. One switch. helios64 has much load atm though.

tx and rx offloading is off

Server listening on 9999
-----------------------------------------------------------
Accepted connection from 192.168.178.10, port 47294
[  5] local 192.168.178.2 port 9999 connected to 192.168.178.10 port 47296
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   211 MBytes  1.77 Gbits/sec                  
[  5]   1.00-2.00   sec   190 MBytes  1.60 Gbits/sec                  
[  5]   2.00-3.00   sec   220 MBytes  1.85 Gbits/sec                  
[  5]   3.00-4.00   sec   167 MBytes  1.40 Gbits/sec                  
[  5]   4.00-5.00   sec   226 MBytes  1.89 Gbits/sec                  
[  5]   5.00-6.00   sec   211 MBytes  1.77 Gbits/sec                  
[  5]   6.00-7.00   sec   217 MBytes  1.82 Gbits/sec                  
[  5]   7.00-8.00   sec   201 MBytes  1.69 Gbits/sec                  
[  5]   8.00-9.00   sec   271 MBytes  2.28 Gbits/sec                  
[  5]   9.00-10.00  sec   215 MBytes  1.81 Gbits/sec                  
[  5]  10.00-10.00  sec   256 KBytes  1.25 Gbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  2.08 GBytes  1.79 Gbits/sec                  receiver

barnumbirr · October 19, 2020

1 hour ago, Borromini said:

@flower and @barnumbirr Which Noctua fans did you get?

Also curious if anyone has installed a dust filter behind the front grille.

Thanks!

Just the standard Noctua NF-A8 PWM (Chromax.Black.swap because I'm a weeb :D). No dust filter for me yet: I think it might impede airflow too much but I'll see over time.

flower · October 19, 2020

1 hour ago, Borromini said:

@flower and @barnumbirr Which Noctua fans did you get?

Also curious if anyone has installed a dust filter behind the front grille.

Thanks!

80mm 2200rpm pwm

No i dont have a dust filter.

This one https://www.heise.de/preisvergleich/noctua-nf-a8-pwm-a1165563.html

inconsistant · October 19, 2020

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.

Spoiler

[ 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

aprayoga · October 20, 2020

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?

raoulh · October 20, 2020

On 10/19/2020 at 8:47 AM, gprovost said:

We will do an announcement soon but we realized we made a design mistake on the Helios64 2.5GbE port (LAN2 | eth1) which makes it not perform well in 1000Mb/s mode, however no impact in 2500baseT mode.

Regarding your iperf test, seems a bit funny. You sure your routing table is correct for traffic to go really to the expected interface since you are on the same subnet.

Can you do the same tests, but for each test disconnect the cable of the interface you are not testing.... or at least use different subnet.

Also can you check interface speed with ethtool (ethtool eth0 and ethtool eth1).

Actually you were right about the routing table, all trafic goes through the 2.5G interface. If I test the 1G interface alone I get correct results:

➜  ~ iperf3 -c 192.168.0.87 -p 12345
Connecting to host 192.168.0.87, port 12345
[  5] local 192.168.0.238 port 35700 connected to 192.168.0.87 port 12345
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   112 MBytes   938 Mbits/sec   57    160 KBytes       
[  5]   1.00-2.00   sec   112 MBytes   942 Mbits/sec   45    214 KBytes       
[  5]   2.00-3.00   sec   112 MBytes   938 Mbits/sec   37    206 KBytes       
[  5]   3.00-4.00   sec   112 MBytes   943 Mbits/sec   33    144 KBytes       
[  5]   4.00-5.00   sec   111 MBytes   935 Mbits/sec   53    185 KBytes       
[  5]   5.00-6.00   sec   112 MBytes   940 Mbits/sec   56    160 KBytes       
[  5]   6.00-7.00   sec   112 MBytes   941 Mbits/sec   56    202 KBytes       
[  5]   7.00-8.00   sec   112 MBytes   939 Mbits/sec   43    192 KBytes       
[  5]   8.00-9.00   sec   112 MBytes   939 Mbits/sec   38    201 KBytes       
[  5]   9.00-10.00  sec   112 MBytes   940 Mbits/sec   44    158 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.09 GBytes   940 Mbits/sec  462             sender
[  5]   0.00-10.00  sec  1.09 GBytes   938 Mbits/sec                  receiver

But with the 2.5G only connected to the 10G switch this is what I get:

➜  ~ iperf3 -c 192.168.0.86 -p 12345                
Connecting to host 192.168.0.86, port 12345
[  5] local 192.168.0.238 port 42958 connected to 192.168.0.86 port 12345
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  64.5 MBytes   541 Mbits/sec  509   18.4 KBytes       
[  5]   1.00-2.00   sec  64.1 MBytes   538 Mbits/sec  531   17.0 KBytes       
[  5]   2.00-3.00   sec  68.4 MBytes   574 Mbits/sec  599   18.4 KBytes       
[  5]   3.00-4.00   sec  63.6 MBytes   533 Mbits/sec  488   19.8 KBytes       
[  5]   4.00-5.00   sec  62.3 MBytes   522 Mbits/sec  461   18.4 KBytes       
[  5]   5.00-6.00   sec  63.2 MBytes   530 Mbits/sec  528   26.9 KBytes       
[  5]   6.00-7.00   sec  71.8 MBytes   602 Mbits/sec  622   25.5 KBytes       
[  5]   7.00-8.00   sec  62.8 MBytes   527 Mbits/sec  541   19.8 KBytes       
[  5]   8.00-9.00   sec  62.5 MBytes   524 Mbits/sec  472   18.4 KBytes       
[  5]   9.00-10.00  sec  69.3 MBytes   582 Mbits/sec  588   19.8 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   653 MBytes   547 Mbits/sec  5339             sender
[  5]   0.00-10.00  sec   652 MBytes   547 Mbits/sec                  receiver

And when I connect eth1 to a 1G switch this is even worse:

➜  ~ iperf3 -c 192.168.0.86 -p 12345
Connecting to host 192.168.0.86, port 12345
[  5] local 192.168.0.238 port 39408 connected to 192.168.0.86 port 12345
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  15.9 MBytes   134 Mbits/sec  330   25.5 KBytes       
[  5]   1.00-2.00   sec  18.3 MBytes   153 Mbits/sec  436   19.8 KBytes       
[  5]   2.00-3.00   sec  18.2 MBytes   153 Mbits/sec  428   15.6 KBytes       
[  5]   3.00-4.00   sec  9.69 MBytes  81.3 Mbits/sec  277   2.83 KBytes       
[  5]   4.00-5.00   sec  3.54 MBytes  29.7 Mbits/sec   58   2.83 KBytes       
[  5]   5.00-6.00   sec  13.7 MBytes   115 Mbits/sec  270   2.83 KBytes       
[  5]   6.00-7.00   sec  12.9 MBytes   108 Mbits/sec  349   14.1 KBytes       
[  5]   7.00-8.00   sec  12.3 MBytes   103 Mbits/sec  352   4.24 KBytes       
[  5]   8.00-9.00   sec  12.7 MBytes   106 Mbits/sec  307   4.24 KBytes       
[  5]   9.00-10.00  sec  6.15 MBytes  51.6 Mbits/sec  142   11.3 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec   123 MBytes   103 Mbits/sec  2949             sender
[  5]   0.00-10.20  sec   123 MBytes   101 Mbits/sec                  receiver

Something is actually wrong with the 2.5G port...

Edit: forgot the ethtool when connected on the 10G switch:

╭─root@helios64 ~  
╰─➤  ethtool eth1      
Settings for eth1:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
                                2500baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
                                2500baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 
                                             1000baseT/Half 1000baseT/Full 
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 2500Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: yes

Edited October 20, 2020 by raoulh

gprovost · October 20, 2020

10 minutes ago, raoulh said:

Something is actually wrong with the 2.5G port...

Yes as I mentioned previously there is design issue with the 2.5GbE interface when used in 1000Mb/s mode (What you see in your last iperf), however no impact in 2500baseT mode.

So now why you get only 547 Mbits/s when connected to your 10G switch it's strange... maybe your 10G port doesn't support 2500baseT mode.

As requested in my last message can show the output of ethtool eth1 on Helios64 when connected to your 10G port switch.

Edit: ok so it's in 2500Mb/s speed mode. How's you machine running iperf server is connected to the switch ? 1G or 10G or ?

raoulh · October 20, 2020

5 minutes ago, gprovost said:

Edit: ok so it's in 2500Mb/s speed mode. How's you machine running iperf server is connected to the switch ? 1G or 10G or ?

My machine is connected with a 10G SFP+ and is working great with other 10G devices I have on my network.

flower · October 20, 2020

11 minutes ago, raoulh said:

My machine is connected with a 10G SFP+ and is working great with other 10G devices I have on my network.

What todes ethtool eth1 show?

root@ghost:~# ethtool eth1
Settings for eth1:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
                                2500baseT/Full 
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Supported FEC modes: Not reported
        Advertised link modes:  10baseT/Half 10baseT/Full 
                                100baseT/Half 100baseT/Full 
                                1000baseT/Full 
                                2500baseT/Full 
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Advertised FEC modes: Not reported
        Link partner advertised link modes:  100baseT/Half 100baseT/Full 
                                             1000baseT/Full 
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Link partner advertised FEC modes: Not reported
        Speed: 2500Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: yes

the important part is: "Speed: 2500MB/s"

my iperf3 shows 1.8GBit/s

it is possible that your switch doesnt support 2.5Gbe. Could you post vendor and model?

gprovost · October 20, 2020

14 minutes ago, raoulh said:

My machine is connected with a 10G SFP+ and is working great with other 10G devices I have on my network.

What do you get when you use -R option on iperf3 client side in order do a download test from your PC to Helios64.

Here my iperf3 just done now.

PC (iperf3 -s) <-- 5G --> Netgear MS510TX <-- 2.5G --> Helios64 (iperf3 -c)

root@helios64:~# iperf3 -c 10.10.20.254
Connecting to host 10.10.20.254, port 5201
[  5] local 10.10.20.3 port 56716 connected to 10.10.20.254 port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   155 MBytes  1.30 Gbits/sec    0   2.13 MBytes       
[  5]   1.00-2.00   sec   168 MBytes  1.41 Gbits/sec    0   2.26 MBytes       
[  5]   2.00-3.00   sec   166 MBytes  1.39 Gbits/sec    0   5.03 MBytes       
[  5]   3.00-4.00   sec   166 MBytes  1.39 Gbits/sec    0   5.03 MBytes       
[  5]   4.00-5.00   sec   168 MBytes  1.41 Gbits/sec    0   6.23 MBytes       
[  5]   5.00-6.00   sec   168 MBytes  1.41 Gbits/sec    0   6.23 MBytes       
[  5]   6.00-7.00   sec   168 MBytes  1.41 Gbits/sec    0   6.23 MBytes       
[  5]   7.00-8.00   sec   168 MBytes  1.40 Gbits/sec    0   6.23 MBytes       
[  5]   8.00-9.00   sec   166 MBytes  1.39 Gbits/sec    0   6.23 MBytes       
[  5]   9.00-10.00  sec   169 MBytes  1.42 Gbits/sec    0   6.23 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  1.62 GBytes  1.39 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  1.62 GBytes  1.39 Gbits/sec                  receiver

iperf Done.


root@helios64:~# iperf3 -c 10.10.20.254 -R
Connecting to host 10.10.20.254, port 5201
Reverse mode, remote host 10.10.20.254 is sending
[  5] local 10.10.20.3 port 56720 connected to 10.10.20.254 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec   268 MBytes  2.24 Gbits/sec                  
[  5]   1.00-2.00   sec   280 MBytes  2.35 Gbits/sec                  
[  5]   2.00-3.00   sec   272 MBytes  2.28 Gbits/sec                  
[  5]   3.00-4.00   sec   280 MBytes  2.35 Gbits/sec                  
[  5]   4.00-5.00   sec   280 MBytes  2.35 Gbits/sec                  
[  5]   5.00-6.00   sec   280 MBytes  2.35 Gbits/sec                  
[  5]   6.00-7.00   sec   280 MBytes  2.35 Gbits/sec                  
[  5]   7.00-8.00   sec   278 MBytes  2.33 Gbits/sec                  
[  5]   8.00-9.00   sec   278 MBytes  2.33 Gbits/sec                  
[  5]   9.00-10.00  sec   280 MBytes  2.34 Gbits/sec                  
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  2.71 GBytes  2.33 Gbits/sec  702             sender
[  5]   0.00-10.00  sec  2.71 GBytes  2.33 Gbits/sec                  receiver

As you can see the sending perf are not good because of the TX offloading feature disable.

But the RX perf are as expected.

registr123 · October 20, 2020

On 10/19/2020 at 5:31 AM, aprayoga said:

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.

10x for the answer - I was actually trying to turn them off completely, but only the blue status light and keeping them going to red on errors etc.

raoulh · October 20, 2020

23 minutes ago, gprovost said:

What do you get when you use -R option on iperf3 client side in order do a download test from your PC to Helios64.

Here my iperf3 just done now.

PC (iperf3 -s) <-- 5G --> Netgear MS510TX <-- 2.5G --> Helios64 (iperf3 -c)

As you can see the sending perf are not good because of the TX offloading feature disable.

But the RX perf are as expected.

Ok, so I think I found the culprit. The helios64 is plugged in a SFP+ 10GBase-T module in a mikrotik switch. It seems that the SFP module I have does not support well the 10GBase-N modes (2.5 and 5Gb).

I tried connecting the helios64 directly on a machine with an 10G ethernet port (no sfp module involved) and I correctly get the speed.

➜  ~ iperf3 -c 192.168.0.86 -p 12345
Connecting to host 192.168.0.86, port 12345
[  5] local 192.168.0.238 port 41362 connected to 192.168.0.86 port 12345
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec   268 MBytes  2.25 Gbits/sec    0   1.56 MBytes       
[  5]   1.00-2.00   sec   281 MBytes  2.36 Gbits/sec    0   1.56 MBytes       
[  5]   2.00-3.00   sec   280 MBytes  2.35 Gbits/sec    0   1.56 MBytes       
[  5]   3.00-4.00   sec   280 MBytes  2.35 Gbits/sec    0   1.56 MBytes

I need to get another 10GBase-T SFP+ module that correctly support 2.5.

Thanks all for help!

dancgn · October 20, 2020

Today, home from doing stuff with my kids, the server won't work. No connection with ssh or serial.

After restart the server runs about 3-4 Minutes and then this messages was shown:

https://www.directupload.net/file/d/5977/5duv2mqg_png.htm

https://www.directupload.net/file/d/5977/jhn6v7wz_png.htm

I completley reinstalled the server, but the problem stayed. Rebooting everytime without doing something. And the startup (Starting kernel ...) needs a lot of time.

Help...

Greets

Daniel

-> My german is much better...

flower · October 20, 2020

1 hour ago, dancgn said:

Today, home from doing stuff with my kids, the server won't work. No connection with ssh or serial.

After restart the server runs about 3-4 Minutes and then this messages was shown:

https://www.directupload.net/file/d/5977/5duv2mqg_png.htm

https://www.directupload.net/file/d/5977/jhn6v7wz_png.htm

I completley reinstalled the server, but the problem stayed. Rebooting everytime without doing something. And the startup (Starting kernel ...) needs a lot of time.

Help...

Greets

Daniel

-> My german is much better...

it is easier to read logfiles. in putty under logging you can define where to write it.

---

Halloo/

Ich schreibe auch lieber auf Deutsch xD Am besten mal unter putty das Logging einschalten. Mit den Dateien kann man dann mehr anfangen.

inconsistant · October 20, 2020

13 hours ago, 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.

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?

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.

1 hour ago, dancgn said:

Today, home from doing stuff with my kids, the server won't work. No connection with ssh or serial.

After restart the server runs about 3-4 Minutes and then this messages was shown:

https://www.directupload.net/file/d/5977/5duv2mqg_png.htm

https://www.directupload.net/file/d/5977/jhn6v7wz_png.htm

I completley reinstalled the server, but the problem stayed. Rebooting everytime without doing something. And the startup (Starting kernel ...) needs a lot of time.

Help...

Greets

Daniel

-> My german is much better...

I had the same problem, you can see my logs above. I was getting the same errors after the update from 20.08.10 to 20.08.13, but also on first boot on a fresh 20.08.13 as well.

dancgn · October 20, 2020

vor 22 Minuten schrieb inconsistant:

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.

I had the same problem, you can see my logs above. I was getting the same errors after the update from 20.08.10 to 20.08.13, but also on first boot on a fresh 20.08.13 as well.

So wait for a new image, or back to 20.08.10...

vor 29 Minuten schrieb flower:

it is easier to read logfiles. in putty under logging you can define where to write it.

---

Halloo/

Ich schreibe auch lieber auf Deutsch xD Am besten mal unter putty das Logging einschalten. Mit den Dateien kann man dann mehr anfangen.

Okay...jemand der Deutsch spricht inconsistant hat ja wohl das gleiche Problem. Also warten auf Update oder zurück zur alten Version...

flower · October 20, 2020

a short feedback to the latest versions:

.10 - most stable so far. three days without a problem

.11 - crashed once in 12h

.12 - crashed once in 12h

.13 - seems ok so far. running for 12h

with .13 i get these errors though (verbosity=6 in /boot/armbianEnv.txt, no rsyslog and systemd-journald redirected to serial):

[   15.801564] systemd-udevd[466]: Process '/bin/ln -sf /sys/devices/platform/ff120000.i2c/i2c-2/2-004c/hwmon/hwmon2 /dev/thermal-board' failed with exit code 1.
[   15.804618] systemd-udevd[491]: Process '/bin/ln -sf /sys/devices/virtual/thermal/thermal_zone0/hwmon0 /dev/thermal-cpu' failed with exit code 1.

aprayoga · October 21, 2020

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/

Edited October 21, 2020 by aprayoga

jbergler · October 21, 2020

If you, like myself, installed on eMMC and are experiencing the crashes on 20.08.14 - I booted up via a 20.08.10 sdcard and fixed the environment on emmc

# mount the emmc + get ready to chroot
mkdir /mnt/chroot
mount /dev/mmcblk1p2 /mnt/chroot/
mount /dev/mmcblk1p1 /mnt/chroot/media/mmcboot
mount --bind /mnt/chroot/media/mmcboot/boot/ /mnt/chroot/boot/
mount --bind /dev /mnt/chroot/dev/
mount --bind /proc /mnt/chroot/proc/
mount --bind /tmp /mnt/chroot/tmp/

# chroot in and downgrade to 20.08.10
chroot /mnt/chroot/ /bin/bash
apt install \
  linux-dtb-current-rockchip64=20.08.10 \
  linux-headers-current-rockchip64=20.08.10 \
  linux-image-current-rockchip64=20.08.10 \
  armbian-config=20.08.10 \
  armbian-firmware=20.08.10 \
  linux-focal-root-current-helios64=20.08.10 \
  linux-u-boot-helios64-current=20.08.10

exit
# now remove the sd card and hit reset

@aprayoga It's probably unrelated, but while working through the above I noticed that I ran out of space on /boot.

I installed to eMMC the first version that was working, if that helps. I chose f2fs when I installed on eMMAC and this is the resulting partition layout

mmcblk1      179:32   0 14.6G  0 disk 
├─mmcblk1p1  179:33   0   96M  0 part
└─mmcblk1p2  179:34   0 14.3G  0 part
mmcblk1boot0 179:64   0    4M  1 disk 
mmcblk1boot1 179:96   0    4M  1 disk

Sadly I didn't grab enough info from what was in the boot partition before I nuked it and reinstalled the appropriate packages.

Edited October 21, 2020 by jbergler
fixed typo

Sign In

Helios64 Support

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Similar Content

Important Information