helios4noob Posted June 14, 2019 Posted June 14, 2019 Please find it attached. Firewall prevented direct linking. Helio4 Dump.txt
gprovost Posted June 17, 2019 Author Posted June 17, 2019 @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/)
Iskren Chernev Posted June 25, 2019 Posted June 25, 2019 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)?
aprayoga Posted June 25, 2019 Posted June 25, 2019 (edited) 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 to determine whether it's power adapter or on-board regulator failure. Edited June 26, 2019 by aprayoga 1
Iskren Chernev Posted June 27, 2019 Posted June 27, 2019 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?
gprovost Posted June 28, 2019 Author Posted June 28, 2019 @Iskren Chernev Please PM me and we see what's the best approach to replace your power supply ;-)
MarcC Posted July 3, 2019 Posted July 3, 2019 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.
aprayoga Posted July 3, 2019 Posted July 3, 2019 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
MarcC Posted July 4, 2019 Posted July 4, 2019 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 ?
aprayoga Posted July 5, 2019 Posted July 5, 2019 @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. 1
gprovost Posted July 14, 2019 Author Posted July 14, 2019 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. 1
jimandroidpc Posted July 30, 2019 Posted July 30, 2019 On 3/14/2019 at 10:46 PM, jimandroidpc said: I cant tell if its applied or not @gprovost when I run the helios4-omv-luks.patch, it says **** malformed patch at line 6:
gprovost Posted July 30, 2019 Author Posted July 30, 2019 @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.
jimandroidpc Posted July 30, 2019 Posted July 30, 2019 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. 2
Mikezim Posted August 3, 2019 Posted August 3, 2019 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
gprovost Posted August 5, 2019 Author Posted August 5, 2019 @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.
sirleon Posted August 9, 2019 Posted August 9, 2019 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?
NickS Posted August 10, 2019 Posted August 10, 2019 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 :} 1
gprovost Posted August 10, 2019 Author Posted August 10, 2019 @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 ? 1
sirleon Posted August 10, 2019 Posted August 10, 2019 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
gprovost Posted August 11, 2019 Author Posted August 11, 2019 @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)
epleminator Posted August 14, 2019 Posted August 14, 2019 (edited) 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 August 14, 2019 by epleminator
gprovost Posted August 14, 2019 Author Posted August 14, 2019 @epleminator Not even LED8 is ON ? (LED located near the DC connector). Is the LED on the Power Adapter ON ? By any chance you have a voltmeter to check the output of the DC plug of the power adapter ?
epleminator Posted August 14, 2019 Posted August 14, 2019 Nope, none of the LED (1,2,3,4,5etc) gave any signal. Yes, the Power adapter light is ON. I'll buy one on my way home from work and post back later.
tekrantz Posted August 14, 2019 Posted August 14, 2019 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.
MarcC Posted August 15, 2019 Posted August 15, 2019 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 ! 3
jimbolaya Posted August 15, 2019 Posted August 15, 2019 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? 1
gprovost Posted August 15, 2019 Author Posted August 15, 2019 @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 ?
Recommended Posts