Kobol Helios64 RK3399K SBC & 5-Bay NAS Pre-Orders to Start Next Week

We covered Rockchip RK3399K processor a few months ago, as a version of RK3399 processor qualified to run at 2.0 GHz, or supporting a wider-temperature range (-20 to +85°C) at 1.8 GHz.

We found out about the new processor, as Kobol was working on a Helios64 SBC designed for NAS that featured RK3399K SoC. At the time, we just had a drawing of the board and some specifications, but now the company has announced pre-orders for the board and a complete 5-bay NAS kit will start next week and the actual shipping start in March.

Kobol Helios64 SBC

Click to Enlarge

Specifications:

  • SoC – Rockchip RK3399K hexa-core processor with 2x Arm Cortex-A72 cores @ 2.0 GHz, 4x Cortex-A53 cores @ 1.6 GHz
  • System Memory – 4GB LPDDR4
  • Storage – 16GB eMMC 5.1 flash, 5x SATA 3.0, 1x M.2 SATA slot shared with one SATA 3.0 port, MicroSD port
  • Connectivity – 1x 2.5GbE port, 1x Gigabit Ethernet port
  • USB – 3x USB 3.0 ports, 1x USB Type-C port with DP (DisplayPort) and DAS (Direct Access Storage) modes
  • Expansion – Headers for I2C, UART, SPI, GPIOs…
  • Misc – 2x PWM fan headers, RTC with backup battery, buzzer
  • Power Supply – Dual DC inputs, built-in UPS support with optional battery.
  • Dimensions – 120 x 120 mm (nano-ITX form factor)

The board will ships with a large heatsink as shown above. There’s no mention of OS support in the currently empty Wiki, but we should expect Debian and Armbian support.

Kobol Helios64 5-Bay NAS Enclosure

Kobol’s first product, Helios4 NAS SBC, would optionally ship with an acrylic enclosure which kept cost low, but it was not necessarily the most eye-pleasing design.

Click to Enlarge

So the company has come up with a much nicer design for Kobol Helios64 enclosure as shown above.

Key features:

  • Support for up to 5x 3.5” SATA HDD
  • Hot-Plug HDD Tray System
  • Integrated Control Panel
  • 1x USB 3.0 Port
  • 2x 80mm PWM Fans
  • Dimensions – H 134mm x W 222mm x D 250mm

All necessary cables as included with the case.

The company also plans to offer an adapter kit to install Helios64 SBC in any mini-ITX tower to recycle old PC cases.

Pricing

Prices for the board, enclosure, accessories, and complete kit are as follows:

  • Helios64 SBC with heatsink – $189
  • Helios64 enclosure – $95
  • 12V/10A Power Adapter – $14
  • UPS battery pack comprised of Panasonic Cell NCR18650BD – $12
  • Helios64 Full Kit with all four items above – $295 – Pre-order price: $285 until March 2020

Via LinuxGizmos

Share this:

Support CNX Software! Donate via PayPal or cryptocurrencies, become a Patron on Patreon, or buy review samples

26 Replies to “Kobol Helios64 RK3399K SBC & 5-Bay NAS Pre-Orders to Start Next Week”

  1. On LinuxGizmos somewhere in the comments Gauthier now indirectly answered my previous question: 2.5GbE is provided via USB so I would assume we’re talking about:

    * The 5 SATA ports provided by a JMB585 (‘wasting’ two of the four PCIe Gen2 lanes)
    * 2.5GbE provided by a RTL8156 behind some USB3 hub sharing bandwidth with the 3 Type-A ports

    No ECC memory (even if they can provide later a version with integrated on-die ECC this is something entirely different than proper ECC support where the host can read out whether bit flips occurred and so the user can act on accordingly) and crappy software support.

    I guess this is mostly for people impressed by slogans like ‘open source’ and things of the past like mdraid/RAID5…

    1. What will be a CNX post without a comment from @tkaiser 😉

      * We would have loved to expose the spare PCIe lanes but the cost of PCIe Switch wasn’t fitting in the bill. You should know that there is always some trade-off to be done to find the best recipe within certain constrains.
      * Actually the 2.5Gbe over USB3 hub is performing well even in a share bandwidth scenario. Of course all of this require proper cpu affinity configuration.

      Maybe you should have a closer look into SDRAM with on-die ECC. The one we will be using ( from Intelligent Memory) provide a special register in order to query the number of ECC events. It also provide a physical ERR event signal pin that can be used as an interrupt.

      I follow you on this, for Helios64 we will encourage people to look at other approach than usual mdadm RAID.

      1. > SDRAM with on-die ECC. The one we will be using ( from Intelligent Memory) provide a special register in order to query the number of ECC events. It also provide a physical ERR event signal pin that can be used as an interrupt.

        Which framework will allow to handle this stuff? Do you use this ‘physical ERR event signal pin’ and if so in which way? Which software component will take care of this?

        1. We are still experimenting with it, obviously it’s not trivial to access such memory register. As for the ERR signal is just meant to be used as trigger intead of constantly polling register. We will share our progress at later stage, plus IM is a bit behind schedule on their 8Gb SDRAM. We want to at least offer 2GB for the ECC option.

      2. > We would have loved to expose the spare PCIe lanes but the cost of PCIe Switch wasn’t fitting in the bill.

        I think that’s not the excuse if you are selling something at $189.

        1. What we are offering is a novel design with a lot of built-in features like 2.5Gbe Ethernet or On-Board UPS that you won’t find on any other off-the-shelf boards.

          But above all, for this price users can expect a premium quality design, something you can rely on for setting up your NAS. One example is that we put a lot of emphasis in the design quality of the power circuitry and management, not like other boards.

          Also we are using only quality components, not refurbished / rebranded SDRAM or eMMC modules from brand like Rayson or Foresee. For people who don’t know those refurbished chips are chips that didn’t pass quality tests from original foundries (e.g Samsung or Micron) and are resold via other channels under different brands.

          If we had taken some of these shortcuts we could have lowered the BOM cost, but we rather focus on delivering quality designs which users can recognize and appreciate.

          1. Rant: It’s alarming to see how easily otherwise-reputable vendors are willing to revert to sources like Rayson and Foresee so that they can shave 5-10% of BOM in their effort to one-up the next RPi or each other. In the race to the bottom they easily cross the fine line between ‘a useful product of good value’ and ‘a cheap product of little value’.

          2. Lower quality bins of dram and nand really aren’t that problematic, that some people make it.

            Quality of nand is usualy determined by number of bad blocks from the factory; more bad blocks, lower the tier.
            Similar with dram; lower bins tend to run and lower frequency and higher timings.

            The real issue is implementation within cheap end products; you can have the shittiest nand in the world, but it will still outlast the useful lifetime of the device. Par a quality nand with a shittiest of shit flash controller and you’ll soon run into trouble.

          3. Given the shortcomings, you should at least consider lowering the price. Your bundle costs a whopping $295 and an additional $43 for shipping!!!

            At this cost, as @e97 suggested, why would someone aware of the facts not go for a Mini-ITX board/one of the embedded Ryzen SBCs?

      3. > for Helios64 we will encourage people to look at other approach than usual mdadm RAID.

        Curious what that might be… I bet your target audience is clearly people who confuse data availability with data safety and data integrity.

          1. Maybe I made a mistake because I didn’t buy the Fujitsu D3644-B which is unfortunately no longer available. With it you can achieve very low IDLE results with an Intel x86 CPU (5 to 10 Watt, Powertop, Linux). Sure, more expensive. But no problems with ECC-Ram, outdated kernel (incl. maintenance) etc.

            It is important to me:
            Mirror – ZFS or BTRFS
            Low IDLE power consumption
            LAN > 1 Gbe

            These ARM devices all have disadvantages that are only visible at second glance. There also seems to be no SoC that is really suitable for a NAS and remains affordable.

          2. I forgot to mention that ECC-Ram is important to me. That should be a matter of course in a NAS.

  2. There’s not much space for the OS. Nowadays people expect the hardware to be able to run multi gigabyte Docker containers.

    1. My home NAS running on 1/1024 of that (16 MB) proves you wrong. This is a NAS, not an application server (nor an RPi competitor in case you’re going to ask).

      1. Well, the thing can be an application server, for specific applications. Like a NAS or similar

        (Those are applications… X-D)

        In the end, you can fit quite a bit onto 16Gb of store. For example, you can get a TVHeadend server to fit onto less than 512Mb of flash, including Linux, network management via connman, etc. I just did one as an experiment. That would be a bit of an interesting application for this board, for example.

        1. > That would be a bit of an interesting application for this board, for example.

          Well, this board would cost me around 250€ (neither shipping nor VAT nor taxes are included in Kobol’s prices). For such an expense I would need the right set of features for an appropriate use case.

          Probably interesting features:

          * 5 PCIe attached SATA ports so no USB(-attached SATA) storage hassles
          * 2.5GbE Ethernet
          * DC UPS (only interesting if UPS software gets compatible to the implementation here)
          * maybe DAS mode (only interesting if it works reliable and performant)

          Now for this combination of features I’m just missing a use case…

    2. Not much space for the OS…

      This depends on what class of people you’re talking about. Quit trying to do web apps on things not designed for the purpose, I’d say. There’s quite a bit one can do with this board that’s rather interesting…and not just serving disks/files is on that list. No, it’s not intended for a RPi replacement/competitor. It’s not even remotely that- but server appliance where you need boot, disk, etc. It works out nicely.

  3. Is it just me or have x86 NAS options gotten really expensive, making this ARM one viable? I currently use Ceph for my storage and want to expand it, so that knocks out all the usual NAS appliances that can’t be made to run Linux and leaves low end servers (starting at £500 new) or a self-build I suppose. It’s a shame all the £100 or less entry level servers have dried up.

    1. They’re alright while idling but if they’re regularly pushed hard they’ll spend a lot of time in power hungry states. For home NAS usage I’d rather degrade performance before consuming more power, but with a lot of those server boards you won’t be able to underclock. You could set a Conservative or powersave governor to help, something I’m going to try shortly.

      1. “if they’re regularly pushed hard they’ll spend a lot of time in power hungry states. ”

        At home use the CPU is IDLE most of the time. And if you really need computing power, the CPU may also consume power (e.g. transcoding).
        The consumption of the hard disks should not be underestimated. It is independent of the CPU architecture.
        With a really economical board (Fujitsu D3644-B = high quality) you can consume less than 10W in IDLE. As far as I remember correctly, I have already read about 5W consumption in IDLE with PicoPSU. With a very good ATX power supply also a very low consumption is possible (the German magazine c’t tested and used the mainboard). The board supports ECC memory.
        Unfortunately it is obviously no longer available. And I don’t know any other mainboards which are similarly good and support ECC-Ram.

        If ECC memory works on the Helios64 and the kernel support is good, it could be interesting.

Leave a Reply

Your email address will not be published.

Advertisement
Advertisement