gprovost

Members
  • Content Count

    236
  • Joined

  • Last visited

 Content Type 

Forums

Member Map

Store

Crowdfunding

Raffles

Applications

Everything posted by gprovost

  1. @lloyd094 When you did the test (drive by drive), all the other drives are disconnected even from the power yes ? Effectively your 'delta' disk might have issue, but could also be a faulty power cable or sata cable. Anyway I think it's better we stop the test here. The results don't make any sense and I don't think we are going to find out the real issue. Please PM me in order to discuss the return of the board for us to test it and fix / replace it if necessary... or any other parts (PSU or cable) that could be the cause.
  2. @lloyd094 Well based on your log now HDDs connected to port 1 and port 3 are detected... so there is no more logic here :/ Can you just test each port one by one with one the SATA cable we know work. I don't know why but I still feel some is wrong either with SATA cable or the PSU. I mean understand, if you sent us the board we are happy to test it and fix it if effectively there is an issue with it. It's just it would be a waste of time and shipping fees if we realize the issue is something else.
  3. Yeah something is really no quite right here. Actually in Test 2 one of the HDD is detected, so could still be a SATA cable/connection issue. Any chance you have some spare SATA cable from somewhere else that you could try ?
  4. @lloyd094 Based on the logs effectively something is wrong with disks attached to SATA port 1 and port 2. Hard to guess what's the root cause. [ 11.593597] ata1: softreset failed (1st FIS failed) [ 11.594024] ata2: softreset failed (1st FIS failed) [ 21.593168] ata2: softreset failed (1st FIS failed) [ 21.593809] ata1: softreset failed (1st FIS failed) [ 56.593597] ata2: softreset failed (1st FIS failed) [ 56.593600] ata2: limiting SATA link speed to 3.0 Gbps [ 56.594023] ata1: softreset failed (1st FIS failed) [ 56.594026] ata1: limiting SATA link speed to 3.0 Gbps [ 61.805168] ata2: softreset failed (device not ready) [ 61.805171] ata2: reset failed, giving up [ 61.813167] ata1: softreset failed (device not ready) [ 61.813170] ata1: reset failed, giving up You will have to do the following tests in the exact sequence in order to narrow down the issue. 1. Disconnect the disks connected to SATA port 3 and 4, and see after reboot if then suddenly SATA port 1 and 2 works. If it works, then maybe still an issue with the PSU. 2. Use the cables that was used for SATA port 3 and 4 for SATA port 1 and 2. If it works, then could be bad SATA cables. 3. Use the HDD that was connected to SATA port 3 and 4 with SATA port 1 and 2. If it works, then could be HDD issue, if it doesn't then can be a board issue. I mean you see the logic, we need to narrow down the issue to understand the root cause.
  5. Don't worry, we all do silly mistake like that. Ok let us know the status and don't forget to share the output link of armbianmonitor -u if something is still wrong.
  6. @lloyd094 Just to be sure, at the prompt 'Current password' you enter again 1234 ?
  7. Have you try with another usb cable ? I have already experienced more than once a usb cable with the microUSB side a bit quirky.
  8. Do you see under Windows device manager a device detected as something like 'USB Serial Port (COMxx)' ? Are you able to connect via SSH ? How do you know the HDDs drop if you can't connect to the console / terminal ?
  9. Ok then it's time to share some logs in order to see what happen when the disks drop from the system. Start your system with the HDDs connected and run from the terminal armbianmonitor -u then post the generated url link here. How long your system has been running without issue before you start realizing this issue with dropping HDD ?
  10. Do you have multimeter/voltmeter? Could you measure DC voltage on molex power connector shown on photo below? Expected measured value, on 5V rail: 4.90 V - 5.20 V on 12V rail: 11.90 V - 12.5 V If 5V is outside that range, that mean the onboard regulator is faulty (board problem). If 12V is outside that range, that mean the power supply is faulty.
  11. Armada A8040 is 5x-6x more expensive than RK3399K... it just doesn't fit into the bill for a consumer device like Helios64. Also from the info I got, Marvell is not going to develop anymore their Armada family. They will focus on low power SoC, and let the high performance Armada SoC get phase out by Cavium ones... quite sad actually.
  12. Based on what you say it seems LED1 is ON, but do you see it blinking ? If yes, then it means your system is up and running, therefore your issue is effectively on establishing the serial connection. If no, then it means something else is wrong and that could explain why you don't see anything on the serial console.
  13. Yeah I should have mentioned that also. Through the same USB Type-C we also support Flash over USB with the rockchip dev/flash tools available. The recovery button is on one of 3 push button on the board. Each on-board memory (SPI and eMMC) can be disabled with a proper jumper ( No need to have 16 fingers to flash the board ). We will try our best. Also we will sell a simple adapter kit in order for people to use Helios64 with any mini-ITX and ATX PSU. This way people could recycle their old case and save money.
  14. We will offer an ECC option. The Rockchip RK3399 SoC itself doesn't have a memory controller that has ECC feature, however we are currently working with a SDRAM vendor that now offer built-in ECC feature inside the SDRAM directly. It's not impossible it will be available on day one. No. It is not a use case that make sense from our point of view. I don't believe there will be a lot of people out there with a USB Type-C power adapter that can delivered up to 100W. Plus the power circuitry (and the PSU) would be quite expensive. No. It's a pure M.2 SATA port. FYI it's share with the SATA port 1, so the combination is either ( 1x M.2 SSD + 4x HDD/SSD ) or 5x HDD/SSD. Yes there is a 128Mb SPI NOR Flash. Something we didn't disclose because too much info already on the picture, the USB Type-C has been designed with a 4-in-1 mode concept : - Display Port - DAS mode - Host mode - Serial Console Access We will explain more at a later stage... but it's quite a unique design we did. We wanted to make the eMMC a basic feature of our board. I mean what's the point to sell it as a module when you know that in 90% of the case your user should use eMMC instead of SDcard. It also help in term of software support to know that all user Helios64 user will have the same config, therefore we can focus on installation guide that use the eMMC. You guess right this is not just some bare bone carrier board with a SoC in the middle. Between the PCIe-to-SATA bridge, the 2.5Gbe interface, the built-in UPS feature, RAM, eMMC, etc... it adds-up quickly. We also paid a lot of attention on the different power rails, this is a premium design compare to all the RK3399 board out there. Helios4 was USD200 with the full kit (PSU, case, cable, fan, etc...), our goal it to try to be in the same ballpark. This time we will sell a-la-carte style, you can just buy the board alone, our with the case, if you already have a PSU then no need to order one...
  15. It's not the same form factor. Helios4 was 100x100mm, Helios64 is 120x120mm... There will be a new case of Helios64 and on this aspect the case will also significantly improved over the previous one. Yes you could re-use the Helios4 PSU (12V/8A), however it might be wiser to for a 10A that we will sell also.
  16. Hi guys, I guess some might have heard that we (Kobol Team) were spinning a new project to succeed to Helios4. Here it is... Helios64 We didn't have to look too far for the board name since in essence the goal was to redesign from scratch Helios4 with a 64-bit SoC and try to improve every key features that made Helios4 a very targeted board for NAS setup. Right now we are at the prototyping test phase, hopefully in a 2 month time will have dozen of Eval boards to send around for evaluation and review... and if all goes well first batch should be available for order in Feb / March 2020. Happy to answer any question :-)
  17. @tuxd3v Yeah @aprayoga and myself have ofcourse setup running with 4 disks. Why you are asking ?
  18. @lanefu Ok please send me a PM to arrange replacement of PSU.
  19. @lanefu It clearly looks like a dying PSU. Expected measured value, on 5V rail: 4.90 V - 5.20 V on 12V rail: 11.90 V - 12.5 V If 5V is outside that range, that mean the onboard regulator is failed (board problem). If 12V is outside that range, that mean the power supply is failed. So you confirm the issue on the 12V rail ? If yes then we will send you a new PSU.
  20. @Colink I think it's the first time we hear such issue. FYI the FTDI chip (USB-to-UART) is supplied through the microUSB and actually doesn't require that both RX / TX works. It's quite strange that connecting to the unpopulated UART header (J13) makes then the FTDI kinda works afterward. Each board goes through a Factory Acceptance Test (FAT) which is actually controlled by the serial console, so I'm quite surprise you have such issue, Could be a faulty connection between the SoM and the carrier board. Even though we don't recommend it because it's easy to make a mistake you could unscrew the heatsink then unplug / plug the SoM from the carrier and put back the heatsink in place. Would have been easier you contact us directly by email for such issue, not very helpful to post here if it's a confirmed manufacturing issue. Anyhow please PM me and we will see what we can do do to fix / replace your board.
  21. Most probably not loaded because no software is calling the AF_ALG API. Again, did you configured OpenSSL to use AF_ALG ?
  22. @Mangix algif_hash and algif_skcipher are already compiled as module, so there aren't missing : Kernel 4.19 https://github.com/armbian/build/blob/master/config/kernel/linux-mvebu-next.config#L5113 Kernel 4.14 https://github.com/armbian/build/blob/master/config/kernel/linux-mvebu-default.config#L5161 Did you configured OpenSSL to offload on AF_ALG ? https://wiki.kobol.io/cesa/#configure-openssl
  23. Couldn't it be the ribbon cables of the fans that touch the fan blades ?
  24. @Jeckyll Maybe you should first double check that fancontrol is properly installed and configured. Refer to this section of our wiki : https://wiki.kobol.io/pwm/#fancontrol-automated-software-based-fan-speed-control
  25. @uiop @devman Well it would be great to cross check first what I reported about BTRFS tools on 32-bit arch. Maybe there have been some improvements done by the BTRFS community. @jimandroidpc Yes L1 and L2 cache is parity protected on Marvell Armada 38x. Well it wouldn't make sense to have ECC RAM with a CPU (SoC) that doesn't have at least cache protected with parity check mechanism.