Jump to content

Recommended Posts

Posted
  On 10/27/2020 at 6:45 AM, flower said:

Yes, all docker container and system together is around 1gb ram usage. 

It uses zram after a while but that seems unrelated to that sync error. 

I never saw my ram completely filled. 

 

I dont use armbian nextcloud. I tweaked the mysql, redis, alpine variant which now runs stable on my old pc. Emby takes much ram there, but that container wasnt enabled on helios64. 

Screenshot_20201027_074310.jpg

Expand  

 

 

how did you display this ingenious output?
I currently have a consumption of 88-90% on my Helios64 and suspect that a container is at fault.

 

edit:

ok with docker stats I got a similar output, but yours is even more "neat".

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
7b42ac796d6f        pihole              0.13%               18.92MiB / 3.711GiB   0.50%               0B / 0B             2.87GB / 621MB      21
3d3d14ccf50d        unifi-controller    3.85%               938.7MiB / 3.711GiB   24.70%              0B / 0B             6.22GB / 8.44GB     124
711e02b8f517        iobroker            15.94%              977.9MiB / 3.711GiB   25.73%              0B / 0B             4.79GB / 59.5GB     144
ae4aba42dce4        embyserver          2.94%               928MiB / 3.711GiB     24.42%              0B / 0B             13.2GB / 423MB      39
0150a9f8edfb        portainer-ce        0.66%               14.87MiB / 3.711GiB   0.39%               5.95MB / 9.88MB     741MB / 136MB       15

 

Posted

Hello,

 

I am trying to setup LACP aggregation on my helios64 between the two ethernet ports on the helios64 and I noticed I can set the MTU of the 2.5G port up to 9000 but the 1G ethernet port top at 1500.

I use the 2.5G port as 1G as my network switch is gigabit only.

Can you confirm that the 'first' port (aka the 1G port) is not jumbo frame compliant ?

 

This error shows up when I try to change the size:

 

rk_gmac-dwmac fe300000.ethernet eth0: must be stopped to change its MTU

 

when the command is used:

 

# ip link set mtu 3000 eth0
RTNETLINK answers: Device or resource busy


 

Even when the link eth0 is down, the MTU cannot be changed.

 

Kernel version:

5.8.16-rockchip64 #20.08.14

Packages versions:

 

armbian-config : 20.08.20
armbian-firmware : 20.08.17
linux-dtb-current-rockchip64 : 20.08.14
linux-headers-current-rockchip64 : 20.08.14
linux-image-current-rockchip64 : 20.08.14


 

Posted
  On 11/1/2020 at 9:41 AM, AurelianRQ said:

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

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


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

Expand  

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

 

  On 11/1/2020 at 11:41 AM, bverhagen said:

Hi all,

 

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

 

  Reveal hidden contents

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

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

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

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

Expand  

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

1. Get serial console

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

3. enter this command

  

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

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

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

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

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

 

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

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

Expand  

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

HandlePowerKey=ignore

 

Posted

@wurmfood and @357up it could be an issue with the wire harness. Can you do more try by swapping the cable between the bay slots and sata ports in order to narrow down the problem to the wire harness. If it's the case then you can contact us to support@kobol.io and we will help you from there.

 

@AurelianRQ Regarding the issue for 2.5GbE port that doesn't perform properly when used in 1000Mb mode, unfortunately there is no fix that can be done by software. But it's actually pretty easy to fix on the board itself, it only requires to solder one wire between 2 points. Our mistake is that we didn't connect center tap of the 2.5Gb MAGJACK to 2.5V power rail (connected to ground instead) in order to provide common mode for MDI signals which is required for 1000Mb mode somehow. We will post a PCN bulletin to explain better this limitation and how to fix it for people who are up for a bit of soldering.

 

@aegiap Unfortunately your link aggregation is going to be impacted to the issue mentioned above. The 2.5GbE doesn't perform properly in 1000Mb mode.

 

 

 

Posted
  On 11/2/2020 at 9:58 AM, gprovost said:

 

 

@AurelianRQRegarding the issue for 2.5GbE port that doesn't perform properly when used in 1000Mb mode, unfortunately there is no fix that can be done by software. But it's actually pretty easy to fix on the board itself, it only requires to solder one wire between 2 points. Our mistake is that we didn't connect center tap of the 2.5Gb MAGJACK to 2.5V power rail (connected to ground instead) in order to provide common mode for MDI signals which is required for 1000Mb mode somehow. We will post a PCN bulletin to explain better this limitation and how to fix it for people who are up for a bit of soldering.

Expand  

That's sad.

 

  19 minutes ago, gprovost said:

@aegiap Unfortunately your link aggregation is going to be impacted to the issue mentioned above. The 2.5GbE doesn't perform properly in 1000Mb mode.

Expand  

Any information about the jumbo frame support on the working ethernet port ?

Posted

Hello, after setting up my Helios64 kit, flashing an SD card, and setting up the serial, i connect to picocom and nobody's home. 
there are no HDD installed yet because I am testing the board itself, but it will not boot. I have tried multiple known-good sandisk microsds, both the armbian and ubuntu version (whatever was current as of 1 Nov) with no success. 

 

would maskrom mode be my first logical step to recovery?
 

Posted

Has anyone tried moving Armbian OS over from the emmc to a sata drive? Any advantages to doing this? I found this in a banana pi forum:https://wiki.daniel-keil.de/projekte/banana-pro/install-armbian-to-a-sata-drive

 

Had no problem with general install of armbian to the emmc and updating firmware thru armbian-config (worked like a charm).  

Posted
  On 11/2/2020 at 9:58 AM, gprovost said:

@AurelianRQ Regarding the issue for 2.5GbE port that doesn't perform properly when used in 1000Mb mode, unfortunately there is no fix that can be done by software. But it's actually pretty easy to fix on the board itself, it only requires to solder one wire between 2 points. Our mistake is that we didn't connect center tap of the 2.5Gb MAGJACK to 2.5V power rail (connected to ground instead) in order to provide common mode for MDI signals which is required for 1000Mb mode somehow. We will post a PCN bulletin to explain better this limitation and how to fix it for people who are up for a bit of soldering.

Expand  

Soldering? No problem here !

I can help users from Germany to fix their helios board once the solution is released.

Posted
  On 11/1/2020 at 6:29 PM, TonyMac32 said:

power delivery through USB-C. 

 

Oh and mode switching.  So if it set to the mode you want by default it should be ok, but the better question is why was it eating clock cycles

Expand  

So far I have found that the I2C bus generates ~20k interrupts sec:

 

root@helios64:/proc# cat interrupts && sleep 10 && cat interrupts

<snip>
 43:    4107025          0          0          0          0          0     GICv3  88 Level     ff3d0000.i2c

<snip>
 43:    4311805          0          0          0          0          0     GICv3  88 Level     ff3d0000.i2c

 

but I don't know what exactly that means. A simple i2cdetect on that bus generates 351 interrupts. So it's not bits.

 

  

  On 11/2/2020 at 7:11 PM, Z06Frank said:

Has anyone tried moving Armbian OS over from the emmc to a sata drive? Any advantages to doing this? I found this in a banana pi forum:https://wiki.daniel-keil.de/projekte/banana-pro/install-armbian-to-a-sata-drive

 

Had no problem with general install of armbian to the emmc and up: dating firmware thru armbian-config (worked like a charm).  

Expand  

 

Yes I did. I wrote about it in the comments section of sata in the wiki: https://wiki.kobol.io/helios64/sata/

Posted

Is the U-Boot image installed on the SPI Flash? If not is it possible to install it there?

The instructions on the Wiki page say to write it to the microSD card and have the board boot from the microSD.

Posted

Hello,

 

I just tried to copy my Armbian install from the SD Card to the eMMC, but I'm not sure it has been successful, how can I be sure?

 

For information, I also encrypted my HDDs using LUKS and I use MergerFS to pool their data.

 

Boot sequence from serial console

  Reveal hidden contents

 

Output from df

  Reveal hidden contents

 

/etc/fstab

  Reveal hidden contents

 

Posted
  On 11/4/2020 at 6:57 PM, axeleroy said:

/dev/mmcblk0p1                               60910176    5312260   54945884   9% /

Expand  

As far as I can see it booted from sd, or at least the root file system is an 64GB sd card. To boot from emmc you have to remove the sd card.

 

  On 11/4/2020 at 4:33 AM, gprovost said:

 

Yes we are aware of that, something wrong with fusb302 driver, @aprayoga is looking into it.

Expand  

OK, thanks.

Posted

Welp, I removed the SD card and it did not boot to eMMC.

 

  Reveal hidden contents

 

Posted
  On 11/4/2020 at 8:22 PM, axeleroy said:

Welp, I removed the SD card and it did not boot to eMMC.

 

  Reveal hidden contents

 

Expand  

 

use the command df -h to show from which storage the system was loaded.
If it says /dev/mmcblk1p1 it is the eMMC and if it says /dev/mmcblk0p1 it is still your microSD.
You can also tell from the memory size whether it is the eMMC (has 15GB) or your microSD.

 

root@helios64:~# df -h
Filesystem      Size  Used Avail Use% Mounted on
udev            1.8G     0  1.8G   0% /dev
tmpfs           381M   37M  344M  10% /run
/dev/mmcblk1p1   15G  7.8G  5.7G  59% /
tmpfs           1.9G     0  1.9G   0% /dev/shm
tmpfs           5.0M     0  5.0M   0% /run/lock
tmpfs           1.9G     0  1.9G   0% /sys/fs/cgroup
tmpfs           1.9G  4.0K  1.9G   1% /tmp

 

Posted (edited)
  Reveal hidden contents

 

Edited by djurny
Issue was cabling after all.
Posted
  On 11/4/2020 at 8:22 PM, axeleroy said:

Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
## Executing script at 00500000
Wrong image format for "source" command
SCRIPT FAILED: continuing...

Expand  

 

The boot.scr script is damaged. You can try to recreate it. Boot from sd once again, mount the emmc filesystem and recreate

 

mkdir /tmp/mmc
mount /dev/mmc/mmcblk1p1 /tmp/mmc
chroot /tmp/mmc mkimage -C none -A arm -T script -d /boot/boot.cmd /boot/boot.scr

 

 

Posted
  On 11/5/2020 at 3:27 PM, djurny said:

Anyone have any idea on what to check next?

Expand  

 

Well according to your ethtool ouput. Your switch only advertise 10 and 100baseT/Full. What switch model it is ?

 

        Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                             100baseT/Half 100baseT/Full 

 

I think you need to try again with the other switch you mentioned about. What switch model it is ?

Posted

Hi,

 

  On 11/6/2020 at 4:57 AM, gprovost said:

 

Well according to your ethtool ouput. Your switch only advertise 10 and 100baseT/Full. What switch model it is ?

I think you need to try again with the other switch you mentioned about. What switch model it is ?

Expand  

Both are Zyxel switches, one is 16 ports GS1100 -16 and the other is 8 ports GS-108Bv3. Both are Gbps capable, as shown by other devices connected to the same switch:

 

Helios4:

Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                     100baseT/Half 100baseT/Full 
                                     1000baseT/Full 


Just now, I tried yet another set of cables to connect to the Helios64 box, and it seems I have bought several batches of cat "5e" cables, with stress on "5e". Looks like a cabling issue still. I never noticed this, as most are connected to either Raspberry Pi2b or OrangePi zero devices (see ethtool output from one of the Pis below, connected to the same 16ports Gbps capable switch). I already ordered another batch of [apparently] shielded cat 6 cables, hopefully they are indeed shielded, cat 6 and not cat "6".

 

Raspberry Pi2b:

Link partner advertised link modes:  10baseT/Half 10baseT/Full 
                                     100baseT/Half 100baseT/Full

 

Please disregard my previous post.


Thanks,

Groetjes,

Posted

What is a normal CPU temperature on idle? Mine is never lower than 40°C, at an ambient temperature of 19°C, which makes me wonder how much electricity it draws. Is it possible that the GPU is actively doing nothing, or something like that? If so, can it be switched off?

 

The NAS has been placed vertically, with the CPU on bottom. The disk in slot 5 is 22°C.

Posted
  On 10/8/2020 at 2:45 AM, gprovost said:

 

Could you please send us an email to support@kobol.io with some pictures in order to check what's wrong with your enclosure unit.

Expand  

When I received my Helios64 - the case was out of whack -- the alignment was off by about 1/4 inch (3-5mm or so)....

since it was out of whack -- I gave it one - with a rubber mallet - worked perfectly - 

a gentle but sharp tap - once on both sides (I'll go through my phone later today to see if I took pictures)

 

Rich

Posted
  On 11/7/2020 at 11:50 AM, RockBian said:

What is a normal CPU temperature on idle? Mine is never lower than 40°C, at an ambient temperature of 19°C, which makes me wonder how much electricity it draws. Is it possible that the GPU is actively doing nothing, or something like that? If so, can it be switched off?

 

The NAS has been placed vertically, with the CPU on bottom. The disk in slot 5 is 22°C.

Expand  

 

Mine is running somewhere around 44 - 52°C - at an ambient temperature of 23°C.

CPU frequency for both Big and Little cores are around 408 MHz according to 'htop'

Posted
  On 11/7/2020 at 7:15 PM, SIGSEGV said:

 

Mine is running somewhere around 44 - 52°C - at an ambient temperature of 23°C.

CPU frequency for both Big and Little cores are around 408 MHz according to 'htop'

Expand  

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.

Posted
  On 11/2/2020 at 9:58 AM, gprovost said:

 

@wurmfood and @357up it could be an issue with the wire harness. Can you do more try by swapping the cable between the bay slots and sata ports in order to narrow down the problem to the wire harness. If it's the case then you can contact us to support@kobol.io and we will help you from there.

 

@AurelianRQ Regarding the issue for 2.5GbE port that doesn't perform properly when used in 1000Mb mode, unfortunately there is no fix that can be done by software. But it's actually pretty easy to fix on the board itself, it only requires to solder one wire between 2 points. Our mistake is that we didn't connect center tap of the 2.5Gb MAGJACK to 2.5V power rail (connected to ground instead) in order to provide common mode for MDI signals which is required for 1000Mb mode somehow. We will post a PCN bulletin to explain better this limitation and how to fix it for people who are up for a bit of soldering.

 

@aegiap Unfortunately your link aggregation is going to be impacted to the issue mentioned above. The 2.5GbE doesn't perform properly in 1000Mb mode.

 

 

Expand  

T

  On 11/2/2020 at 11:58 AM, gprovost said:

Cool, well I can do that I guess if that does not void the warranty in this case, Honestly to get a 300 E switch to manage 2.5 or 100 E adapters that I don't even know they work, I prefer to fix it the easy way if possible. Thanks and I guess waiting for your details. 

Expand  

 

Posted

@AurelianRQ You post is a bit messed up (can you edit/fix it ?).

 

You can find multi-gigabit switch at 150euros check Zyxel XGS1010-12 or even QNAP QSW-1105-5T. As for the instruction to fix the 1000Mb mode on the 2.5Gbe port, it was posted above.

Posted

Assembled my first (of two) helios64s. I needed to insulate the chassis around the leds, but the USB-C connector fit perfectly into the back panel opening. I noticed a problem with the sata cable for slot 1 where it passes under the chassis to reach the board socket. The chassis has a sharp edge that presses onto the cable, so I padded it with some electrical tape.

 

cable-chassis.jpg

 

In the box containing the system board there was a plastic bag with two jumper plugs and two screws and a threaded spacer. What is the purpose of the spacer and screws?

spacer-and-screws.jpg

 

I had stability problems using Windows to install OS to eMMC. Windows recognized the eMMC as a storage device for a few seconds after helios64 started but then it disappeared. It finally worked after about 10 tries. I was using a USB3 extension cable to reach my pc - perhaps that was the cause.

 

Thanks,

Jeff

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines