Helios4 Support

[gprovost]

This main thread has been locked. Thanks to the Armbian team, we now have our own Kobol club (kinda sub forum) dedicated to our products (Helios64 & Helios4).

So now you are encourage to create individual threads for new issue, discuss feature, share setup, etc...

This will help to improve overall readability.

 

Note : Before asking a question please insure the information is not already available on Helios4 Wiki or addressed in a previous post in this forum.

 

 

 

Latest Build :

 

Check : https://dl.armbian.com/helios4/

 

Archived Build :

 

Check :  https://archive.armbian.com/helios4/archive/

 

Known Issues :

• During SATA heavy load, accessing SPI NOR Flash will generate ATA errors. Temporary fix : Disable SPI NOR flash by default.
  • Refer to following page to use SPI NOR Flash : https://wiki.kobol.io/helios4/spi/
• SDcard High Speed timing have compatibility issue with some brands. Temporary fix : Disable UHS option/support by default.
  • Refer to following page to enable UHS mode : https://wiki.kobol.io/helios4/sdcard/

 

 

 

[Igor]

@zador.blood.stained Merging 4.4.y kernels from Marvell seems a bit problematic and wasteful. Shall we implement this workaround to the mvebu.conf:

https://github.com/armbian/build/blob/master/config/sources/mvebu.conf#L16

    if [[ $BOARD == helios4 ]]; then
        KERNELSOURCE='https://github.com/helios-4/linux-marvell'
        KERNELBRANCH='branch:linux-marvell-4.4'
        KERNELDIR='linux-helios-4'
        LINUXFAMILY=helios4
    fi

Mainline target remains mvebu-next. Any better idea?

 

[zador.blood.stained]

2 minutes ago, Igor said:

Any better idea?

Why do we have to use a separate kernel tree in the first place? If there are no critical features in the helios4 fork we should stay with the current 4.4.y branch and try to cherry-pick the helios4 DT and other small improvements.

According to the commit log the only problematic change may be the PWM support which wasn't even working the last time it was mentioned.

[gprovost]

@Igor @zador.blood.stained

 

Even though we have our own 4.4 marvell kernel repo, as agreed with Zador before, to add Helios4 support in Armbian framework we are integrating our additions/modifications via patches to armbian mvebu-default, this way all mvebu board build against the same kernel repo (which uses moonman repo).  We have new stuff to be merged soon for mvebu-default, can be found here.

 

For the mvebu-next (mainline), we are almost done also, can found the work here.

 

Later today or tomorrow, we will rise a pull request from our armbian/build repo to update both mvebu-default and mvebu-next. Hopefully from this point you will start to build Helios4 image and make them available on your website. For the time being I will still build and maintain on our own builds as found here. Once you are making build available, then our wiki will point to your download page for baseline Jessie and Stretch build... we will then only build and maintain OMV images.

 

@Igor Nice pic ;-) You will realize the casing is not really perfect for single disk, it needs at least 2 disks to properly hold together. You should rather put your disk in one of the middle slots.

[Igor]

I had troubles with images above - sometimes network was not recognized ... so I tried to put together mvebu-next with 4.14.12 ... I only used DT from legacy, no other patches. The network works, CPU scaling works, SATA works, ... Fans. One is spinning fast and one slow. I didn't even try to resolve this PWM thingy.

 

Download page: https://www.armbian.com/helios4/
Boot logs: http://ix.io/DIO

 

Yes, I quickly find out that you need at least two drives so I added one at the bottom and case become stable. Eventually, I ended up in "engineering mode" 

[gprovost]

Hi All,

 

As announced in our blog Debian 9 Stretch release is now available which provide the best hardware support of Helios4. For now you can find the latest build release on our wiki, link also available above in the this thread banner.

[NickS]

Running OpenMediaVault image on Helios4

Supplied fans connected to fan headers continue to spin after shutdown or in standby mode.

 

[NickS]

OpenMediaVault image comes with SABNZBD plug-in.

I have used SABNZBD for years on several different OS's - installs have usually been issue free.

However I cannot get this implementation to access any storage share.

 

Config folder options are restricted to the base folder - which with Helios4 - is the microSD card - a bit useless really for 

a NAS. Has anyone worked out how to move SABNZBD's incomplete & complete folders to a storage share on one of the HDDs?

[gprovost]

3 hours ago, NickS said:

Running OpenMediaVault image on Helios4

Supplied fans connected to fan headers continue to spin after shutdown or in standby mode.

 

 

I think this is expected. At PWM 0, this fan type will still run at minimum rpm.

Note : standby mode is not yet fully supported. Plus there is no yet proper way to wake up, this will come later with Wakeup-On-Lan support.

 

3 hours ago, NickS said:

OpenMediaVault image comes with SABNZBD plug-in.

I have used SABNZBD for years on several different OS's - installs have usually been issue free.

However I cannot get this implementation to access any storage share.

 

Config folder options are restricted to the base folder - which with Helios4 - is the microSD card - a bit useless really for 

a NAS. Has anyone worked out how to move SABNZBD's incomplete & complete folders to a storage share on one of the HDDs?

 

FYI This is the kind of question that should be rather asked on openmediavault forum.

OMV3 mounts file system under /srv folder. So in sabnzd config folder you can chose/find your share folders by browsing under /srv/<mount-point-name>/<your-share-folders>.

Important : Don't forget under OMV / Share Folder / ACL to give read/write permission to sabnzbd user for the share folders you wanna use.

[bigheart]

Hello,

i have the OMV image on my Helios4.

i have it running overnight however, i found the serial console port is not work after.

the system is still up and running, ssh and OMV web interference is still working.

i have to reboot the Helios in order to bring the serial console back.

anyone have the same problem?

Joseph

[Igor]

30 minutes ago, bigheart said:

Hello,

i have the OMV image on my Helios4.

i have it running overnight however, i found the serial console port is not work after.

the system is still up and running, ssh and OMV web interference is still working.

i have to reboot the Helios in order to bring the serial console back.

anyone have the same problem?

Joseph

 

Nope, unknown to this moment. Can you try to get some logs? I assume you are running kernel 4.4.y?

[gprovost]

@bigheart Is the serial issue you described happens all the time after over night running ?

 

The helios4 board has an onboard FTDI USB-to-UART bridge (FT230X), this way you don't need to have a RS232 port on your computer or to buy a USB-to-Serial converter.

The FT230X is actually power supplied by the USB port of your computer that you connect to the Heliso4 micro-USB console port, so even if the Helios4 board is not powered-on the FTDI USB-to-UART bridge will still come to live and should be detected by your computer.

 

Assuming your computer is a Linux machine, as soon as you connect the Helios4 console port you should see the following in your kernel messages

$> dmesg -w
[...]
[684438.411938] usb 1-2: new full-speed USB device number 18 using xhci_hcd
[684438.547622] usb 1-2: New USB device found, idVendor=0403, idProduct=6015
[684438.547631] usb 1-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[684438.547636] usb 1-2: Product: FT230X Basic UART
[684438.547639] usb 1-2: Manufacturer: FTDI
[684438.547643] usb 1-2: SerialNumber: DN00KDNN
[684438.551627] ftdi_sio 1-2:1.0: FTDI USB Serial Device converter detected
[684438.551703] usb 1-2: Detected FT-X
[684438.552290] usb 1-2: FTDI USB Serial Device converter now attached to ttyUSB0

 

If you unplug you should see the following USB disconnect message

[684398.900050] usb 1-1: USB disconnect, device number 17
[684398.900432] ftdi_sio ttyUSB0: FTDI USB Serial Device converter now disconnected from ttyUSB0
[684398.900463] ftdi_sio 1-1:1.0: device disconnected

 

So when the serial issue you described happens again, you should try to unplug / plug the console port and see if you see the above messages appearing in you kernel messages.

 

If the expected kernel messages appear but you still can't access the shell console of the Linux running on your Helios4, then the issue is somewhere else than the onboard FTDI USB-to-UART bridge (unless a very unlikely issue with the Dual-Buffer IC between the FTDI chip ans the SoM) . In this case you should post the full dmesg ouput of your Helios4 when the issue appear (use https://pastebin.com/ to share the output to us).

[pedro67]

using latest kernel provided trough "apt upgrade"

# uname -a
Linux helios4 4.14.14-mvebu #2 SMP Thu Jan 25 14:43:10 CET 2018 armv7l GNU/Linux

 

the PWM/fancontrol does not work anymore.

 

Feb  3 12:30:00 localhost fancontrol[5566]: Device path of hwmon2 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device path of hwmon3 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device path of hwmon4 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device name of hwmon2 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device name of hwmon3 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device name of hwmon4 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Configuration appears to be outdated, please run pwmconfig again
Feb  3 12:30:00 localhost systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE

 

 

any idea how to fix it (the FAN at full speed are really noisy) ? (or how to revert back to previous kernel)

 

 

Thanks

[gprovost]

6 minutes ago, pedro67 said:

using latest kernel provided trough "apt upgrade"

# uname -a
Linux helios4 4.14.14-mvebu #2 SMP Thu Jan 25 14:43:10 CET 2018 armv7l GNU/Linux

 

the PWM/fancontrol does not work anymore.

 

Feb  3 12:30:00 localhost fancontrol[5566]: Device path of hwmon2 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device path of hwmon3 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device path of hwmon4 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device name of hwmon2 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device name of hwmon3 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Device name of hwmon4 has changed
Feb  3 12:30:00 localhost fancontrol[5566]: Configuration appears to be outdated, please run pwmconfig again
Feb  3 12:30:00 localhost systemd[1]: fancontrol.service: Main process exited, code=exited, status=1/FAILURE

 

 

any idea how to fix it (the FAN at full speed are really noisy) ? (or how to revert back to previous kernel)

 

 

Thanks

@pedro67  The issue is not really related to kernel, but rather in which order the kernel detects the difference hwmon type device, and sometimes the order unfortunately change. We are working on this issue, it will be fix in our next build release tomorrow. We are adding udev rules to hardcode the path of the hwmon devices.

[pedro67]

any potential temporary fix to reduce the speed of the FAN  using CLI  (while waiting for next build) ? 

[gprovost]

1 minute ago, pedro67 said:

any potential temporary fix to reduce the speed of the FAN  using CLI  (while waiting for next build) ? 

 

Go to /sys/class/hwmon

Look inside each hwmon[1-5] folders to find the two folder that contain a file named pwm1.

Let's say folder hwmon4 and hwmon5 contains the filename pwm1, then to setup the speed do the following command :

$> echo 100 > /sys/class/hwmon/hwmon4/pwm1
$> echo 100 > /sys/class/hwmon/hwmon5/pwm1

PWM range is 1 - 255, so you can have fun trying different speed.

[pedro67]

4 hours ago, gprovost said:

Go to /sys/class/hwmon

Look inside each hwmon[1-5] folders to find the two folder that contain a file named pwm1.

Let's say folder hwmon4 and hwmon5 contains the filename pwm1, then to setup the speed do the following command :

$> echo 100 > /sys/class/hwmon/hwmon4/pwm1
$> echo 100 > /sys/class/hwmon/hwmon5/pwm1

 

Thanks for the hint, in fact I don't see any pwm1 available

root@helios4:/sys/class/hwmon# ls -laR | grep pwm
root@helios4:/sys/class/hwmon#

 

I have only  hwmon0  and hwmon1

# ls -l
total 0
lrwxrwxrwx 1 root root 0 Feb  3 17:24 hwmon0 -> ../../devices/platform/soc/soc:internal-regs/f1072004.mdio/mdio_bus/f1072004.mdio-mii/f1072004.mdio-mii:00/hwmon/hwmon0
lrwxrwxrwx 1 root root 0 Feb  3 17:24 hwmon1 -> ../../devices/virtual/hwmon/hwmon1

 

if pwm1 is not present,  is there a way to change the speed using the GPIO FAN ?

 

Thanks for your help

 

 

[pedro67]

after a bit more digging it seems that the kernel provided by armbian  trough apt in version 4.14.14  does not enable PWM :-(

 

root@helios4:/boot# cat config-4.14.14-mvebu  | grep PWM
# CONFIG_PWM is not set
root@helios4:/boot# cat config-4.14.14-mvebu  | grep LM75
# CONFIG_SENSORS_LM75 is not set

the root issue seems here :-(

 

 

 

[gprovost]

7 hours ago, pedro67 said:

after a bit more digging it seems that the kernel provided by armbian  trough apt in version 4.14.14  does not enable PWM :-(

 

root@helios4:/boot# cat config-4.14.14-mvebu  | grep PWM
# CONFIG_PWM is not set
root@helios4:/boot# cat config-4.14.14-mvebu  | grep LM75
# CONFIG_SENSORS_LM75 is not set

the root issue seems here :-(

 

You right I didn't realized you upgraded your kernel to the latest provided by Armbian dpkg repo which unfortunately is missing PWM and LM75 options because of a incomplete merge on Armbian side. Our intention was to fix this issue along the improvement of udev rules and PWM support in LK4.4, I didn't foresee that people will be updating their kernel via dpkg and end up in your situation Will post something here once new kernel version is available. Some manual editing will be require in /etc/fancontrol and udev rules.

[wsian]

Can you share the add on for oled display as mentioned earlier?

Bought a few 1.3" oled for esp8266 project. (Unfortunately can get SSD1306 type, only SH1106)

Would like to see what can be expected for info display. 

 

[gprovost]

@pedro67 @Igor

 

Pull Request has been created : https://github.com/armbian/build/pull/885

Waiting it get merged and that Igor publishes the kernel debian packages on apt.armbian.com

Once it's done I will post a blog post tomorrow morning with the instructions on how to upgrade from an existing install.

 

Meanwhile I'm building on my side the different sdcard images that I will publish tomorrow morning on our wiki.

[pedro67]

4 hours ago, gprovost said:

Pull Request has been created : https://github.com/armbian/build/pull/885

 

Thanks @gprovost

 

BTW apart this pwm fan issue, the helios4 NAS works great for me ! good job @gprovost

[Igor]

17 hours ago, gprovost said:

Waiting it get merged and that Igor publishes the kernel debian packages on apt.armbian.com

Done, default 4.4 kernel was also upgraded with upstream patches and tested.

[soydemadrid]

Hi I've just received two Helios4 kits. I'm having some teething problems getting them both set up on my network though.

 

My local network router is on 192.168.1.1 and has a dhcp pool of .3 to .150

 

I then have one Helios4 with a static IP set of .200 and the other Helios4 set as .250

 

They can both ping out no problem, both to 8.8.8.8 for example and google.com

 

They can also both ping other devices on my local network and other devices can ping them...

 

But the problem is they can't ping each other!

 

Another odd thing is when I log in via ssh I get in fine on both Helios4 devices, but trying to type is really slow, choppy and delayed. I type something then have to wait 20 seconds for it to then show up.

 

The third thing I've noticed which is odd is that in my router web admin area on the Network Map, only one of them shows up with 192.168.1.200 - but it has a little 2 icon on it saying "2 devices are connected".

 

When I run ifconfig on either Helios4 it also shows the same MAC address on both of them - I don't know if this is normal or if it matters?

 

Can anyone please help with a fix for these issues? I really need both devices to see each other so I can transfer files between them. Also ssh is nearly unusable like this despite already setting UseDNS no and UsePAM no

[gprovost]

@Igor Thanks a lot

 

@pedro67 Check our latest blog post on how to update/patch existing system : https://blog.kobol.io/2018/02/05/sw-fw-update/

 

@soydemadrid You correctly pinpointed the issue, if you have 2 identical MAC address on same network you will see the exact issue you are observing. You will need to change the predefined MAC address in one of your Helios4.

Here the steps :

1. Launch armbian-config from console / shell

2. Go in following menu System > Bootenv

3. Add the following line eth1addr=00:50:43:84:25:2f

4. Save, Exit and Reboot

Note : Because of udev rules your interface might be rename as eth1 after you change MAC address.  Delete file /etc/udev/rules.d/70-persistent-net.rules and reboot.

 

@wsian I don't have time now to write as I was planning some wiki page about how to use a I2C OLED screen. You will have to dig by yourself first.

There is this driver that supports many OLED screen (including SH1106)  https://github.com/hallard/ArduiPi_OLED

[pedro67]

Thanks @gprovost works !

[soydemadrid]

1 hour ago, gprovost said:

@soydemadrid You correctly pinpointed the issue, if you have 2 identical MAC address on same network you will see the exact issue you are observing. You will need to change the predefined MAC address in one of your Helios4.
Here the steps :

1. Launch armbian-config from console / shell

2. Go in following menu System > Bootenv

3. Add the following line eth1addr=00:50:43:84:25:2f

4. Save, Exit and Reboot

Note : Because of udev rules your interface might be rename as eth1 after you change MAC address.  Delete file /etc/udev/rules.d/70-persistent-net.rules and reboot.

 

Hi thanks that did the trick and now console access if much easier and snappier!! Everything pinging nicely now too. Thanks again for the fix!

[Guest]

Hello,

 

I just got my helios4 and am super excited about it!

I noticed that suspend/resume is a bit broken right now (I can suspend, but the fans stay on and I can't resume via usb keyboard or wol). Is this a known issue? Is this the right place to post about it? or should I open an issue on https://github.com/helios-4/linux-marvell/issues?

 

Also, I'm trying to understand code organization. It seems like armbian/build pulls & builds https://github.com/helios-4/u-boot-marvell. However I don't quite understand how https://github.com/helios-4/linux-marvell fits into the picture.

 

Thanks for all of your awesome work!

[fpabernard]

Hello

 

I just started my new Helios4. The hardware is incredible and it's very easy to have a running Openmediavault running system, so the job is great but ...

 

I used to have a Cubox and could run OMV on it (see here Installing Openmediavault on a CuBox (ARM machine))

 

At that time in 2012, I had to rebuild a kernel to get GPT, LVM, XFS, etc. support.

 

As I want to use my Helios4 as a backup device (I have another Openmediavault server on classical x64 machine), I use XFS because I have huge filesystems (24 TB) and I found this filesystem to be very reliable (I have a XFS running now for 10 years, which i grew several times but never had to rebuild it).

 

So I built a copy of this FS (using 2 x 12 TB drives) using GPT and LVM. Helios4 recognizes immediately the volume after installing LVM2 plugin for OMV. But it can not mount the XFS filesystem (but the XFS commands are present in the Linux image). So I suppose the prebuilt kernel does not include XFS support.

 

I know that on old ARM kernels XFS seemed to be buggy, but I never had any problem with it on my Cubox.

 

I did not find a very clear documentation for rebuilding a kernel for Helios4. Perhaps you could include XFS by default on the helios4 kernel for OMV, as this filesystem is supported by default, including the GUI for creating new FS ?

 

Best regards

 

F.Bernard

[Igor]

32 minutes ago, fpabernard said:

I did not find a very clear documentation for rebuilding a kernel for Helios4. Perhaps you could include XFS by default on the helios4 kernel for OMV, as this filesystem is supported by default, including the GUI for creating new FS ?

Official OMV for ARM hw is Armbian based. What you look for is enabled by default on both kernels:

• https://github.com/armbian/build/blob/master/config/kernel/linux-mvebu-next.config#L4104
• https://github.com/armbian/build/blob/master/config/kernel/linux-mvebu-default.config#L4617

Rebuilding kernel - if you need: 

• https://docs.armbian.com/Developer-Guide_Build-Preparation/

OMV install:

 

armbian-config -> software -> softy -> OMV
or

softy -> OMV

 

Debian Jessie base is recommended for stable OMV.