Jump to content

Helios4 Support


gprovost

Recommended Posts

@helios4noob Your issue is unrelated to Helios4 hardware. It's a software setup issue, could be on your computer / laptop trying to access the share drives on Helios4. You will find better help effectively on the OMV forum for that.

 

Have you tried to disable the firewall on you computer / laptop just to test if you can access the share drives without ? I  assume you are using windows machine.

 

As for the Helios4 froze that happened once, next occurrence check status of  LED8 and LED1 and let us know. (ref to this wiki page to identify LED : https://wiki.kobol.io/led/)

 

 

Link to comment
Share on other sites

I've had a running Helios4 system for almost a year, and it suddenly stopped working (there could have been a power outage, I don't know). When booted, the led next to the power inlet blinks slowly green, but it won't connect to the wired network, and it won't show me a login prompt over the serial connection.

 

- can I review the boot screen/tty from serial, without logging (boot process)?

- Shall I try to use the reset button on the board?

- Where should I check for logs on the SD card?

- Is there a way to boot from another medium (I know about the jumpers, but how to configure the medium when it's not booting at the moment)?

Link to comment
Share on other sites

16 hours ago, Iskren Chernev said:

I've had a running Helios4 system for almost a year, and it suddenly stopped working (there could have been a power outage, I don't know). When booted, the led next to the power inlet blinks slowly green, but it won't connect to the wired network, and it won't show me a login prompt over the serial connection.

 

- can I review the boot screen/tty from serial, without logging (boot process)?

- Shall I try to use the reset button on the board?

Hi,

yes, you can see the boot process from serial. you can follow the instruction in our wiki. After the serial terminal ready, you can press the reset button to see the boot process since very beginning.

You should see something like:

U-Boot SPL 2018.11-armbian (Jan 20 2019 - 20:02:45 -0800)
High speed PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  6   |  SATA0	|
 |   1    |  5   |  USB3 HOST0	|
 |   2    |  6   |  SATA1	|
 |   3    |  6   |  SATA3	|
 |   4    |  6   |  SATA2	|
 |   5    |  5   |  USB3 HOST1	|
 --------------------------------
High speed PHY - Ended Successfully
mv_ddr: mv_ddr-armada-17.10.4 
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR Training Sequence - Start scrubbing
DDR3 Training Sequence - End scrubbing
mv_ddr: completed successfully
Trying to boot from MMC1


U-Boot 2018.11-armbian (Jan 20 2019 - 20:02:45 -0800)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, ECC enabled)
MMC:   mv_sdh: 0
Loading Environment from MMC... *** Warning - bad CRC, using default environment

Model: Helios4
Board: Helios4
SCSI:  MVEBU SATA INIT
Target spinup took 0 ms.
SATA link 1 timeout.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs 

Net:   
Warning: ethernet@70000 (eth1) using random MAC address - 52:fc:90:b3:be:70
eth1: ethernet@70000
Hit any key to stop autoboot:  3  2  1  0 
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
Found U-Boot script /boot/boot.scr
1979 bytes read in 104 ms (18.6 KiB/s)
## Executing script at 03000000
Boot script loaded from mmc
220 bytes read in 86 ms (2 KiB/s)
19717 bytes read in 353 ms (53.7 KiB/s)
4714605 bytes read in 852 ms (5.3 MiB/s)
5460016 bytes read in 1037 ms (5 MiB/s)
## Loading init Ramdisk from Legacy Image at 02880000 ...
   Image Name:   uInitrd
   Created:      2019-02-07  11:42:01 UTC
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    4714541 Bytes = 4.5 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02040000
   Booting using the fdt blob at 0x2040000
   Using Device Tree in place at 02040000, end 02047d04

Starting kernel ...

But i think you won't see that screen.

LED8 near power inlet indicate the input voltage, if it's blink (nothing fancy here, just LED connected to 12V  3.3V) then it's a hardware problem. most probably the power adapter.

 

Do you have a voltmeter? Could you measure the voltage on these pin

839584136_male4pin.jpg.96ab051398e49235d1ddbcab0a9f76c7.jpg

 

to determine whether it's power adapter or on-board regulator failure.

Edited by aprayoga
Link to comment
Share on other sites

I measured the voltage (and shorted it for a few seconds while trying to do so, these pins are kinda hard to reach with other sticking pins :)), and it was 2.57 volts. I believe it should be 12V (unless its like the old apple chargers which switch a few seconds later). Shall I find a new power supply?

Link to comment
Share on other sites

Hi @gprovost,

 

Reading the wiki while waiting for the Batch3 , I was wondering if it would be possible to boot directly to a sata disk...

SPI-NOR Flash wiki page only mentions booting to a microSD card or USB drives. Would something like the following work ?

ext4load sata 0:1

Or does the concurrent access issue between SPI NOR Flash and SATA drives currently prevents this ? Thanks.

Link to comment
Share on other sites

27 minutes ago, MarcC said:

Hi @gprovost,

 

Reading the wiki while waiting for the Batch3 , I was wondering if it would be possible to boot directly to a sata disk...

SPI-NOR Flash wiki page only mentions booting to a microSD card or USB drives. Would something like the following work ?


ext4load sata 0:1

Or does the concurrent access issue between SPI NOR Flash and SATA drives currently prevents this ? Thanks.

 

Yes, you can boot from SATA disk but currently limited only from SATA1 port.

Take a look on following log:

U-Boot SPL 2018.11-00008-g8f200a3d28 (Jul 03 2019 - 08:01:15 +0800)
High speed PHY - Version: 2.0
Detected Device ID 6828
board SerDes lanes topology details:
 | Lane #  | Speed |  Type       |
 --------------------------------
 |   0    |  6   |  SATA0       |
 |   1    |  5   |  USB3 HOST0  |
 |   2    |  6   |  SATA1       |
 |   3    |  6   |  SATA3       |
 |   4    |  6   |  SATA2       |
 |   5    |  5   |  USB3 HOST1  |
 --------------------------------
High speed PHY - Ended Successfully
mv_ddr: mv_ddr-armada-17.10.4
DDR3 Training Sequence - Switching XBAR Window to FastPath Window
DDR Training Sequence - Start scrubbing
DDR3 Training Sequence - End scrubbing
mv_ddr: completed successfully
Trying to boot from SPI


U-Boot 2018.11-00008-g8f200a3d28 (Jul 03 2019 - 08:01:15 +0800)

SoC:   MV88F6828-A0 at 1600 MHz
DRAM:  2 GiB (800 MHz, 32-bit, ECC enabled)
MMC:   mv_sdh: 0
Loading Environment from SPI Flash... SF: Detected w25q32bv with page size 256 Bytes, erase size 4 KiB, total 4 MiB
OK
Model: Helios4
Board: Helios4
SCSI:  MVEBU SATA INIT
Target spinup took 0 ms.
Target spinup took 0 ms.
AHCI 0001.0000 32 slots 2 ports 6 Gbps 0x3 impl SATA mode
flags: 64bit ncq led only pmp fbss pio slum part sxs

Net:
Warning: ethernet@70000 (eth1) using random MAC address - ee:e0:5b:09:22:72
eth1: ethernet@70000
Hit any key to stop autoboot:  0
starting USB...
USB0:   MVEBU XHCI INIT controller @ 0xf10f4000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
USB1:   MVEBU XHCI INIT controller @ 0xf10fc000
Register 2000120 NbrPorts 2
Starting the controller
USB XHCI 1.00
scanning bus 0 for devices... 1 USB Device(s) found
scanning bus 1 for devices... 1 USB Device(s) found
       scanning usb for storage devices... 0 Storage Device(s) found

Device 0: device type unknown
... is now current device
scanning bus for devices...
  Device 0: (0:0) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00
            Type: Hard Disk
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
  Device 0: (0:1) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00
            Type: Hard Disk
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
  Device 0: (1:0) Vendor: ATA Prod.: STEC MACH8 SSD Rev: 1031
            Type: Hard Disk
            Capacity: 57241.8 MB = 55.9 GB (117231408 x 512)
  Device 0: (1:1) Vendor: ATA Prod.: STEC MACH8 SSD Rev: 1031
            Type: Hard Disk
            Capacity: 57241.8 MB = 55.9 GB (117231408 x 512)
Found 4 device(s).

Device 0: (0:0) Vendor: ATA Prod.: TOSHIBA MK5065GS Rev: GJ00
            Type: Hard Disk
            Capacity: 476940.0 MB = 465.7 GB (976773168 x 512)
... is now current device
Scanning scsi 0:1...
Found U-Boot script /boot/boot.scr
2948 bytes read in 88 ms (32.2 KiB/s)
## Executing script at 03000000
Boot script loaded from scsi
199 bytes read in 54 ms (2.9 KiB/s)
18933 bytes read in 167 ms (110.4 KiB/s)
5408781 bytes read in 223 ms (23.1 MiB/s)
5590368 bytes read in 218 ms (24.5 MiB/s)
## Loading init Ramdisk from Legacy Image at 02880000 ...
   Image Name:   uInitrd
   Image Type:   ARM Linux RAMDisk Image (gzip compressed)
   Data Size:    5408717 Bytes = 5.2 MiB
   Load Address: 00000000
   Entry Point:  00000000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 02040000
   Booting using the fdt blob at 0x2040000
   Loading Ramdisk to 0fad7000, end 0ffff7cd ... OK
   reserving fdt memory region: addr=2040000 size=6a000
   Loading Device Tree to 0fa6a000, end 0fad6fff ... OK

Starting kernel ...

Uncompressing Linux... done, booting the kernel.

Helios4 boot from SPI with rootfs located on scsi 0:1

 

To access the SATA disk, you have to use scsi command instead of sata command

Link to comment
Share on other sites

16 hours ago, aprayoga said:

Yes, you can boot from SATA disk but currently limited only from SATA1 port.

Take a look on following log:

[...]

Helios4 boot from SPI with rootfs located on scsi 0:1

To access the SATA disk, you have to use scsi command instead of sata command

 

Thanks @aprayoga, this is great news.

 

As an alternative, is it also possible to write directly U-Boot to the SATA1 disk (the process should be similar to the microSD card process described in Wiki) and boot it directly by setting the SW1 dipswitch to SATA1 value ?

Link to comment
Share on other sites

@MarcC it is possible to write U-Boot directly to SATA disk but currently no U-Boot image for SATA available. and AFAIK,  the procedure a bit different but more similar like PC.  Write U-Boot SPL to disk boot sector then put u-boot.bin into FAT formatted 1st partition.

We are still experimenting with this, can not say when it would be ready.

 

Link to comment
Share on other sites

17 hours ago, Koen said:

Any ETA on Debian 10 (Duster) ?

 

Armbian Buster is ready, but we are still working at upgrading Linux Kernel and U-boot for Default and Next Armbian branch. Making the upcoming release a major Armbian release For Helios4. New OS images and Debian packages should be published in one to 2 weeks time max.

Link to comment
Share on other sites

@jimandroidpc I tested again the patch and it works. Patch it's for OMV4, didn't tested on OMV3 or 5.

sudo patch < helios4-omv-luks.patch  /usr/share/php/openmediavault/system/storage/luks/container.inc
patching file /usr/share/php/openmediavault/system/storage/luks/container.inc

The maintainer of openmediavault-luksencryption plugin hasn't yet did the modification, so you still need to use the patch.

If you can't use the patch, just open the patch file and look at the two +/- lines, you will see it's pretty straight forward, so you can manually modify the code.

Link to comment
Share on other sites

15 hours ago, gprovost said:

@jimandroidpc I tested again the patch and it works. Patch it's for OMV4, didn't tested on OMV3 or 5.


sudo patch < helios4-omv-luks.patch  /usr/share/php/openmediavault/system/storage/luks/container.inc
patching file /usr/share/php/openmediavault/system/storage/luks/container.inc

The maintainer of openmediavault-luksencryption plugin hasn't yet did the modification, so you still need to use the patch.

If you can't use the patch, just open the patch file and look at the two +/- lines, you will see it's pretty straight forward, so you can manually modify the code.

 

@gprovost I manually made the change and confirmed the encryption. Now transfer speeds are 75-80MB/sec up/down compared to 50-55 on XTS. 

Link to comment
Share on other sites

Hi there im currently in the process of upgrading from debian stretch to buster.If something goes wrong and i have to reinstall it,do i lose all the data i currently have on my drives? also will i lose it if my SD card fails? Im running OMV 4 on raid 10 over 4 Drives.Thanks

Link to comment
Share on other sites

@Mikezim No you won't loose your data, each RAID array self contains its own metadata that define the array definition. However it's always wiser to do a backup first of your most valuable data.

After doing a fresh install you can refer to the following section of our wiki : https://wiki.kobol.io/mdadm/#import-an-existing-raid-array or under OMV it's pretty obvious how to add an existing array.

Just be careful, to understand what you are doing before just doing copy&paste command lines.

 

Important: As mentioned in our different announcement, OMV for Debian Buster is not stable, still in Beta. You won't be able to run properly OMV4 on Buster. So if you still want to use OMV, you need to stick to Debain Stretch+ OMV4  for now.

Link to comment
Share on other sites

I installed a fresh Debian Buster and followed the guide at https://wiki.kobol.io/i2c/

to add the OLED-Display shipped with batch 3. Can´t get it to work:

Spoiler

nas@helios1:~$ sudo i2cdetect -y 1
     0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f
00:          -- -- -- -- -- -- -- -- -- -- -- -- --
10: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
20: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
30: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
40: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
50: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
60: -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- --
70: -- -- -- -- -- -- -- --

nas@helios1:~$ sudo sys-oled --display ssd1306
Traceback (most recent call last):
  File "/usr/local/bin/sys-oled", line 151, in <module>
    device = get_device()
  File "/usr/local/bin/sys-oled", line 55, in get_device
    device = cmdline.create_device(args)
  File "/usr/local/lib/python3.7/dist-packages/luma/core/cmdline.py", line 189, in create_device
    device = Device(serial_interface=Serial(), **vars(args))
  File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/__init__.py", line 185, in __init__
    self._const.NORMALDISPLAY)
  File "/usr/local/lib/python3.7/dist-packages/luma/core/device.py", line 39, in command
    self._serial_interface.command(*cmd)
  File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 85, in command
    list(cmd))
  File "/usr/local/lib/python3.7/dist-packages/smbus2/smbus2.py", line 482, in write_i2c_block_data
    ioctl(self.fd, I2C_SMBUS, msg)
OSError: [Errno 6] No such device or address

 


nas@helios1:~$ sudo sys-oled --display sh1106
Traceback (most recent call last):
  File "/usr/local/bin/sys-oled", line 151, in <module>
    device = get_device()
  File "/usr/local/bin/sys-oled", line 55, in get_device
    device = cmdline.create_device(args)
  File "/usr/local/lib/python3.7/dist-packages/luma/core/cmdline.py", line 189, in create_device
    device = Device(serial_interface=Serial(), **vars(args))
  File "/usr/local/lib/python3.7/dist-packages/luma/oled/device/__init__.py", line 85, in __init__
    self._const.CHARGEPUMP,         0x14)
  File "/usr/local/lib/python3.7/dist-packages/luma/core/device.py", line 39, in command
    self._serial_interface.command(*cmd)
  File "/usr/local/lib/python3.7/dist-packages/luma/core/interface/serial.py", line 85, in command
    list(cmd))
  File "/usr/local/lib/python3.7/dist-packages/smbus2/smbus2.py", line 482, in write_i2c_block_data
    ioctl(self.fd, I2C_SMBUS, msg)
OSError: [Errno 6] No such device or address

 

I´ve double checked wiring and got 3,3V at the OLED-PCB.  Also tried a second OLED without success. Any suggestions what to check next?

Link to comment
Share on other sites

Hi sirleon,

I'm running OMV4 in my deployment, and a recent set of updates broke "psutil.disk_io_counters()".

If you are using this routine in your OLED code to fetch disk information then this may be your problem. Anyway you should

SSH into your NAS and run the OLED code directly from the SSH terminal and let us see all the nice error messages it throws up :}

 

Link to comment
Share on other sites

@sirleon Based effectively on your I2C scan, no device is detected on channel 1. I would still suspect wrong wiring.

 

Can you post a picture of your I2C wiring on each side ?

 

Have you tried another cable ? In the kit there is 2 ribbon cables, a long one (30cm) and a short one (20cm). The short one is just a spare cable. Maybe try with the short one, just to be sure it's not a cable issue first.

 

The second OLED display you tried is it from another Helios4 kit, or just another display you already had ?

Link to comment
Share on other sites

Thank you very much! Yes, changing to the 30cm ribbon cable did the trick. Wired it same as before and checked the 20cm cable with an ohmmeter, i can´t find any broken wire and tried it again with no success. This is no problem as i have other spare ribbon cables to change. Don´t know what else could be wrong...

It is working now so i´m happy :)

Link to comment
Share on other sites

@sirleon Good to hear.

 

BTW it's the 30cm ribbon cable that needs to be used when putting together the Kit, the 20cm is a bit too short. I made a mistake when sourcing the OLED displays and ordered the wrong cable length along. Fortunately we realized it on time and added the 30cm one last minute. That's the reason in the kit there are 2 cables (1x 20cm and 1x 30cm) :P

Link to comment
Share on other sites

Hi, I've got my Helios4 yesterday. After assembly I plugged in the power -  a flash of green light appeared inside the case, the fans started(minimal rotating/spinning) then everything stopped. Tried serveral times to disconnect / connect the power cabel without any sign of life on the board (no lights from LEDs).  Have I accidentally toasted the board? 

 

 

Edited by epleminator
Link to comment
Share on other sites

Received my board. Got it booting from the SD card without building the kit. Was running fine. Halted it. Assembled the entire kit following the WIKI instructions to the letter. Applied power and nothing, no LED's no fans no disk power up, nothing. Stripped it down the the board only, completely removed from the kit, applied power and nothing.  Nothing on the serial console.   Had a lovely chat with someone who gave me some suggestions.  I will report back here my progress.

Link to comment
Share on other sites

Just to say my batch 3 is working great !

I just got the Helios4 to boot Archlinux (thanks Gontran !) directly from a SSD on sata1, thanks to @aprayoga ealier tip in this thread about using the scsi command in uboot. That's nice, no more microSD card !

Link to comment
Share on other sites

I just received and set up my Helios4. I set it up with Buster and it seems to be working OK.

 

One thing that seems to be missing is the ch341 usb serial driver. I have this attached to an old APC UPS that has a serial port and a USB serial cable that uses the HL-340 serial chip.

 

I was unable to find the driver in /lib/modules. Will I need to compile the driver myself or am I missing a package?

 

If it wasn't included intentionally, is there a technical reason not to include the driver for this kernel?

Link to comment
Share on other sites

@tekrantz Sorry to hear that, I understand the frustration when something goes wrong with a product you just got.

Let's try to figure out what's the issue first ok ? If the Board or the PSU is defective then we will proceed to a replacement. Don't worry.

 

Any change you have voltmeter to measure voltage on the DC connector of the PSU ?

 

PSU_Pinout.jpg.f11c99bc2c1f5857b74ceff37e744a77.jpg

Link to comment
Share on other sites

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

Important Information

Terms of Use - Privacy Policy - Guidelines