Search the Community

DUring a fresh install of Debian buster recently, I went through the armbian-config setup, which finished with "install a whole lot of package updates, and update the boodloader." Since I've rebooted from that, the board no longer boots. It's been a while, so I have unfortunately forgotten the details of what actually happened. I didn't expect that set of updates to change anything in the firmware, only the OS and u-boot on the MMC-card. The board powers on, attempts to boot from the MMC and then bails. This is the error log: (slightly trimmed) I've tried several different MMC cards. I've tried booting from SPI, SATA and UART, all with various forms of failure. SATA & SPI also give bad header messages. UART just never seems to do anything - there don't appear to be any functional docs for this recovery method. What's next? This board is currently a heavy (and hot) paperweight.

Hello, So I am trying to setup my Helios 4. I am running into some issues with the installation, trying to group them here, so it will be easier. 1. I am trying to setup NextCloud following your tutorial on kobol wiki but I cannot install PHP 7.3 Here is the screenshot of the output after running the command: 2. Also, when I enter Armbian-Config, it seems unstable and crash. The menu doesn't display. 3. Other issue, I cannot access my NAS through SSH. It returns "operation timed out" How to solve these issues? Thank you for your help.

Hi, I am opening a new topic to make things clearer. This is a follow-up post from here: After managing to install it, I moved my Helios 4 and switched it on again. It started to work but then it shut down. I cannot switch it on anymore. I don't know if it comes from the Power supply or the motherboard. What are the solutions? Thank you for your help.

I seem to have issues on my Helios 4 where it constantly reboots. I have no idea what happens just before. I assume some kind of kernel panic. Kernel 4.19.63 - works 4.19.84 - I believe works 4.19.104 and above - broken Newer ones are broken as well. This is most likely an issue with some local patch. Any way to view the history?

I've been using a Helios4 for nearly 2 years now and it's been fantastic. A couple days ago, it stopped working though. The serial console revealed a boot loop at "U-Boot SPL" and only showing the disks, but never attempting to boot the OS. I did some forum searching and discovered the PSU could be the issue. Using a multimeter, I tested the PSU pins and I get the following (see diagram): PIN 1: +2.66V (fluctuates between 2.64-2.66) PIN 2: +2.66V (fluctuates between 2.64-2.66) PIN 3: GND PIN 4: GND What are the voltages that Helios4 expects for these pins? Should both 1 & 2 be 12V or should one be 12V and the other 5V? I already ordered the following PSU as per another thread (however, this won't arrive for another week) https://www.amazon.com/gp/product/B07NCG1P8X/

Is it me or it the mv_xor driver being loaded late? ``` [ 0.007976] xor: measuring software checksum speed [ 0.164062] xor: using function: arm4regs (2534.000 MB/sec) [ 0.316068] raid6: neonx8 xor() 1096 MB/s [ 0.452063] raid6: neonx4 xor() 1378 MB/s [ 0.588069] raid6: neonx2 xor() 1610 MB/s [ 0.724066] raid6: neonx1 xor() 1346 MB/s [ 0.860075] raid6: int32x8 xor() 328 MB/s [ 0.996072] raid6: int32x4 xor() 369 MB/s [ 1.132082] raid6: int32x2 xor() 332 MB/s [ 1.268063] raid6: int32x1 xor() 285 MB/s [ 1.268067] raid6: .... xor() 1610 MB/s, rmw enabled [ 1.665163] mv_xor f1060800.xor: Marvell shared XOR driver [ 1.694139] mv_xor f1060800.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) [ 1.694257] mv_xor f1060900.xor: Marvell shared XOR driver [ 1.722115] mv_xor f1060900.xor: Marvell XOR (Descriptor Mode): ( xor cpy intr ) ``` I see that /proc/interrupts shows no action despite me using RAID5. edit: from looking at kernel source, it seems btrfs uses xor_blocks instead of async_tx. The former seems software only.

Where can I buy Helios4? Are you still planning to sell it? Helios64 is too expensive honestly and since OpenWRT supports this device.

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/

News related to Helios4 : Software update Wiki / Documentation update Etc...

I'm having a hard time clarifying if OMV 5 is stable on Helios 4 and if there are any successful builds out there. Since there doesn't seem to be an upgrade path from OMV4 -> OMV5 and so requiring a full rebuild, I want to understand as much as possible before actually trying this new version out. Any successes out there?

I bought an helios4 (and run helios4 4.19.63-mvebu) to replace a bananapi server under armbian, the bananapi was running a DRBD node, so I need this service. I first tried to install it, and have seen that DRBD was not configured in the kernel linux-image-next-mvebu 5.91. and the module was missing I checked in the git repository that linux-mvebu64-next.config has now this configuration option, and thought that I will get a new kernel by switching to nightly build. As this option is offered by armbian-config I toggled it. After some time my Helios4 failed to reboot and was bricked. I mounted my SD on an other system to try to analyze the situation, nothing appeared in the log neither syslog, message, or apt/history.log. So I checked the script armbian-config. jobs.sh only switch the source.list from apt.armbian.com to beta.armbian.com then call reload_bsp which remove linux-image-next-mvebu, linux-dtb-next-mvebu, linux-buster-root-next-helios4, armbian-config. Then it try to reinstall them, but for helios4 linux-image-next-mvebu, linux-dtb-next-mvebu, and linux-buster-root-next-helios4 are not in beta.armbian.com, so nothing get reinstalled and the system was broken. So I checked that the previous packages were missing, except the kernel which was not removed. I downloaded them from stable, re-installed them on the sdcard with `dpkg -x`, I edited the armbian.list to switch back to apt.armbian.com, and my system came back to life after few hours of work. I would consider that it is not reasonable to propose to switch to nightly build when they don't exist. The script should first verify that the packages to be uninstalled are present on beta.armbian.com. And now my question is how to install the development kernel on Helios4, do I need to recompile the kernel, or only the DRBD module, and why daily build are missing for helios4.

Hi all, I've pre-ordered my helios4 and was so excited to finally receive my new NAS after a few months of waiting. I love this project and want to see this project to grow and maybe inspire others to create similar projects as this one. That said, I was really disappointed when I finally started my board and realized that the UART to micro usb was broken when I plugged it in my computer. No USB device is at all recognized(on linux nor on my mac). At first, to eliminate any potential problems, I tried at least 6 different micro usb to usb cables thinking that a cable could be broken... it happens some time. With all 6 cables tried, never did I get my computer to detect a USB device plugged in. To continue my great adventure, I soldered a 3 pin header on the UART ports of the board since I have a UART to USB cable at home. Once the pins were soldered on the board, with great excitement I booted the puppy to see if it fixed my issue. It fixed only half the issue. I now detect the USB device andI can now see all tx leaving the arm board however the rx seems to be broken. I get to the login page but can't type anything. Well that sucks. I was hoping the issue was between the UART and micro USB controller but I was wrong. Maybe the issue was with the rx all along and the UART to USB controller just don't work when either rx or tx is not working(this is just a guess). The issue is now more uphill than I thought and I won't be able to troubleshoot this on my own since I am no electronic engineer. So now, I have a brand new board but with only tx working but not rx so basically I am at a loss here. This looks like a manufacturing issue. Am I the only one who has this problem? This is part of batch 3 helio4. Please let me know if you ever went through something similar or if you have an idea how I can fix this. Any help would be appreciated and if others from the same batch has this issue, it would be great to report it rather to leave it at a loss. Thanks

1. Question: How do I check that ECC is really active? 2. Possible Kernel issue: The Debian Buster image's Kernel seems to lack CPU frequency info settings: "cat: /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq: No such file or directory". How can that be fixed? 3. Possible assembly issue: I think the air flow through the case should be reversed. Testing scenario: two units about 0,5 m apart in the same location. One unit assembled as shown in the Wiki, the second one assembled with reverse fan direction. First unit equipped with WD40EFRX-68N32N0 (3 platters), second one with the older WD40EFRX-68WT0N0 (4 platters). Because of that, the second unit was expected to run slightly warmer. First test after 12 hs idling, second test 30 mins. after a reboot. As you can see, the unit with the reversed air flow always stays cooler even with lower fan speeds. In idle, there is a whopping 5.72°C difference in SoC temperature and a 2.56°C difference in ambient temperature. Fans speed in second unit reduced by nearly 36%. Disk temperatures are all pretty similar. After reboot, there is a still a 3.80°C difference between the SoCs and a 1.94°C difference in ambient temperature. Fans speed difference is nearly 29%. Disks in the second unit run warmer, but are now within their optimal temperature range between 30°C and 40°C. (Beyond that, failure rates rise steeply even if WD40EFRX are rated for up to 60°C.) Of course, behaviour under load remains to be seen. I cannot test that at this early stage. But even with measurement inaccuracies taken into account I still think the fans should be mounted the other way round. That would require either longer screws, silicone anti-vibration mounts or you would have to do with the fans mounted on the other side of the plate with the ribbon cables threaded through one of the holes, as I have done for this test. Thoughts/comments? 12 hs idling: Unit #1: Unit #2: Fan J10 RPM: 68 Fan J10 RPM: 44 Fan J17 RPM: 74 Fan J17 RPM: 47 SoC core temp.: 49,408. SoC core temp.: 43,695 Ambient temp.: 34,687. Ambient temp.: 32,125 /dev/sda temp.: 23 /dev/sda temp.: 23 /dev/sdb temp.: 23 /dev/sdb temp.: 23 /dev/sdc temp.: 22 /dev/sdc temp.: 23 /dev/sdd temp.: 22 /dev/sdd temp.: 25 /dev/sda state: standby /dev/sda state: standby /dev/sdb state: standby /dev/sdb state: standby /dev/sdc state: standby /dev/sdc state: standby /dev/sdd state: standby /dev/sdd state: standby 30 mins. after reboot: Unit #1: Unit #2: Fan J10 RPM: 76 Fan J10 RPM: 52 Fan J17 RPM: 74 Fan J17 RPM: 55 SoC core temp.: 49,408. SoC core temp.: 45,600 Ambient temp.: 35,312. Ambient temp.: 33,375 /dev/sda temp.: 26 /dev/sda temp.: 29 /dev/sdb temp.: 26 /dev/sdb temp.: 30 /dev/sdc temp.: 26 /dev/sdc temp.: 31 /dev/sdd temp.: 26 /dev/sdd temp.: 30 /dev/sda state: active/idle /dev/sda state: active/idle /dev/sdb state: active/idle /dev/sdb state: active/idle /dev/sdc state: active/idle /dev/sdc state: active/idle /dev/sdd state: active/idle /dev/sdd state: active/idle

Hi, I'm new proud user of Helios4 Batch3. I started to "play" with different options on this board - and after a 24 hours of use - board doesnt start anymore. Status led blinks but and disk leds blink for short time. It is not possible to connect via terminal console or network. I'think that problem (at least logs point that way) with missing or unavail mount point or (one) disk problem. But nevertheless I think that system itself should still be accessible. Am I wrong? Some disks can fail but not all mount points reside on them. If I disconnect all disks (physically) then connection(s) is/are possible again. I'm still completely new to this board and system. Please advise. Regards.

After creating a raid 6 array and creating a filesystem on it I decided to switch to a raid 5 instead. So i re-created the array and after that was done mkfs.ext4 fails every time. The error I get is: Having to wait for the arrays to be created TWICE now has taken my entire weekend! The armbianmonitor didn't work with the following output: root@helios4:/home/user# armbianmonitor -u System diagnosis information will now be uploaded to no results to fetchPlease post the URL in the forum where you've been asked for. Can anyone help me determine why this error is happening? It'd be much appreciated!

Hi everyone, i've received my new Helios4, i installed OpenMediaVault and i've a 6TB WDRed inside Helios4. Trying to copy files on the NAS i found a very slow speed transfer rate (about 4.5MB/s) i tried to test the LAN over the Elios4 with iperf an this are the results... any idea to solve the problem ? Cables are new cat 5e. Last login: Wed Jan 9 22:58:09 2019 from 192.168.1.13 root@helios4:~# iperf -s ------------------------------------------------------------ Server listening on TCP port 5001 TCP window size: 85.3 KByte (default) ------------------------------------------------------------ [ 4] local 192.168.1.4 port 5001 connected with 192.168.1.13 port 36416 [ ID] Interval Transfer Bandwidth [ 4] 0.0-10.6 sec 51.2 MBytes 40.7 Mbits/sec

Hi everyone. I'm going through the setup process of my Helios4, but am encountering issues with the termina/serial login, which appears to be a character set issue of some type, which I can't figure out. Here is what I have so far: sudo picocom -b 115200 /dev/tty.usbserial-DJ00JLDH picocom v3.1 port is : /dev/tty.usbserial-DJ00JLDH flowcontrol : none baudrate is : 115200 parity is : none databits are : 8 stopbits are : 1 escape is : C-a local echo is : no noinit is : no noreset is : no hangup is : no nolock is : no send_cmd is : sz -vv receive_cmd is : rz -vv -E imap is : omap is : emap is : crcrlf,delbs, logfile is : none initstring : none exit_after is : not set exit is : no Type [C-a] [C-h] to see available commands Terminal ready Ubuntu 18.04.1 LTS helios4 ttyS0 helios4 login: Ubuntu 18.04.1 LTS helios4 ttyS0 helios4 login: r?????p?????????????p?????????????~p?????????????????????~p??????????????????p?????????????p?????????????~p?????????????????????~p????????????? Ubuntu 18.04.1 LTS helios4 ttyS0 when I try to enter the root login details, the character set is obviously not set correctly, but I am not sure where to begin troubleshooting this, and there is nothing in previous threads or in the Wiki. Any pointers would be greatly appreciated! thanks! _slayer_

Hello, is it possible to connect the helios4 directly on his tv to view his videos or photos. For example with a usb3 adapter type A to hdmi. if I understood correctly the helios4 does not have a graphic circuit from where my interrogation.

Hi Igor, Hi Armbian team, I wanted to give a short teaser of an upcoming board I have been developing. The board will be launched through a crowd-funding campaign in couple of weeks. Codename : Helios-4 I'm sure the heatsink will give you some hint The board has been build around the Marvell Armada 388 SoC / SoM from SolidRun. So part of the design is inspired from the Clearfog dev board. Actually the SolidRun helped me on the PCB layout to make this little guy reality. Here the main specs : - dual core A9 @1.6 GHz (max 2Ghz) - 1GB DDR3 (2GB optional) - 4x SATA III - 2x USB 3.0 - 1x Gigabit Ethernet - Micro SD card - Built-in HDD power circuitry for 4 disks - 2x Fan PWM headers - I2C, GPIO and extension pins - Micro USB to Serial - Dimension 100mm x 100mm So clearly I have started this project with one main goal in mind : to finally bring to market the 1st ARM based board which has been designed specially for NAS purpose. I was frustrated to not find any affordable ARM board which has more than 1 SATA port. Optionally the board will come along with a full kit, acrylic casing fitting 4x HDD (3.5'), 2x FAN, oled screen, cabling and power adaptor. Once assembled, it's the smallest 4x 3.5' disk NAS that you could find our there ;-) If people interested, I will post some pic. Anyhow I stop my pitch here ;-) Having used Armbian images and the build framework / toolchain for quite some times, it was logical for this project that the baseline image for Helios4 would be done via the Armbian project. I recently started to dig into your repo to see how to contribute and squeeze my board in. I might need some guidance later, so I hope I can seek a bit of support from the team. I'm also super keen to donate aboard if it can help ;-) Hope it was the right place to post this. Cheers.

To all folks, We are taking order for the 2nd batch of Helios4. If you are interested visit our shop. We offer the two following kits for order : Helios4 2GB ECC Full Kit Helios4 2GB ECC Basic Kit Thanks for the support ;-) The Kobol Team

Got notice that my Helios 4 is on it's way. Yay! But I have a question that I don't see here. I followed the topic of creating, I believe it was a raid 10 with four disks, and I think that's where I want to end up, but I only have two drives right now. Can I go ahead and start with just the two, and easily and the other two at a later date? Or would I be better off waiting until I can get the other two drives?