jimandroidpc reacted to gprovost in Helios64 Annoucement
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...
jimandroidpc reacted to gprovost in Helios4 Support
@SweetKick Regarding the issue of WoL not being enable at each startup, there is effectively a timing issue that seems to be new... the eth0 interface is not yet ready when helios4-wol.service is triggered. I'm going to look at this and see how to fix that.
Regarding the other issue where your system reboot 1-2 minute after the system has been put in suspend mode, my guess is because you have installed OpenMediaVault. OMV install watchdog service by default. When the system is put in standby / suspend mode the watchdog is not stopped, therefore since nothing will be kicking the watchdog in that state, the watchdog will reset the system after 60sec.
The workaround for now is to disable watchdog service.
sudo systemctl disable watchdog
Note: you will need to reboot after you disable the watchdog in order to ensure the watchdog is stopped.
This also something I was supposed to investigate, in order to see how to make systemcl disable / enable watchdog before / after going to suspend mode.
Actually I forgot but I did work with OMV guys to fix the watchdog / suspend issue here : https://github.com/openmediavault/openmediavault/issues/343 But the fix only made to it OMV5.
You can add manually the tweak for OMV4, by creating files /lib/systemd/system-sleep/openmediavault and /usr/lib/pm-utils/sleep.d/openmediavault with the code you find in this commit : https://github.com/openmediavault/openmediavault/pull/345/commits/1c162cf69ed00beccdfe65501cb93f6fb1158df0
I fixed the issue related to WoL not being enable at startup. The issue was now that we rely completely on NetworkManager to configure the network interface, the unit file that enabled WoL on eth0 didn't use anymore the right target dependency and was called too early. Just edit /lib/systemd/system/helios4-wol.service,
then do sudo systemctl daemon-reload and reboot the system