Kobol Team is pulling the plug ;(

[rjgould]

Feels like this should be on here so everyone knows

 

https://blog.kobol.io/2021/08/25/we-are-pulling-the-plug/

[Zac]

Sad sad news! 

Sad for the team, they put a lot of effort into this, I'm sure they made a lot of sacrifices for that project, and it's never pleasant to end an intense effort like that.

And of course sad for the customers, who were counting on them.  Especially since Helios was a success, customers were had high expectations for Helios64. Very sad that it didn't work out...

I believe hardware wise, the team did an excellent job, Helios64 looks really good,  and the specs were quite nice. 

But I'm guessing it's on the software side that it didn't work out, which is really a shame, because software can always be fixed. It requires time, it requires effort, it's not cheap, but it's easier to fix than a hardware issue. 

So although I'm a gutted that they are pulling the plug, good luck to Kobol team, and hope that you come back having learnt from this experience

[jotapesse]

Really sad news, very sorry to hear that for them as a team and company and for ourselves the users of course. The Helios64 is one of the best NAS solutions out there for the budget and the specs and with great potential. I was also counting on getting a Helio64 next revision with the expected improvements and the expected support from the Kobol team... Well hopefully better days will come for all.

[akschu]

Frustrating.  Any other arm based board that's 64-bit and has an actual SATA controller?   I need this to run zfs for a backup system.  I suppose ODROID-HC4 works, but the toaster form factor is lame.

[ning]

your data is expansive, don't stick to arm.

[barnumbirr]

5 hours ago, ning said:

your data is expansive, don't stick to arm.

Wut?

[Heisath]

I think what he meant is: "Your data is expensive, don't stick to ARM" -> Buy a better / easier supported and more stable / mature board like literally ANY x86 small form factor thing. Can get them easy with actual SATA etc. Real BIOS....

[akschu]

Uh, arm is the future for everything.  Intel is on its way out.   Also, I use this for offsite backup.  All of the servers I manage have raid 1 for storage, a second internal disk for backup,  and an offsite storage box that grabs the latest snapshot every hour.  I've been using a kobol and a HC4 to do this for months now, it works fine. 

[TeoTwawki]

Well this sucks. I never got my usb-c cable or any replies to emails about it, they must be just swamped overworked to death and decided this wasn't worth it (kinda what it sounded like in the newsletter, top much work for 3 people). Hopefully being open source means we can keep up on the software end for awhile without them. I got this specifically to have an ARM based linux device that had multiple native sata ports instead of sata-over-usb. I had kind of a niche use and this fit the bill.

[abreyu]

better have 2/3 "cheap" low power consumpiton arm platform than a single expansive x86 solution. If your data is so important you need to save it at least in 3 different places...

[meymarce]

I am still sad about the news. However I wish the team the best and some more free time and hopefully you will regain some of that passion. You have come a long way from an originally failed Kickstarter campaign for the helios4 (which still came to life) to the helios64. The work you have done for the open source community is impressive.

A personal thank you to @gprovost @aprayoga and also Dmitriy Sidorovich (which I have not seen on the forums).

 

I would be very much interested in how everything worked behind the scenes. Like, how do find a factory, how does sourcing the parts work, how many prototypes were there?. This is something that I guess few think about and may have as little clue as I have. It'd be super cool if you could share some of that, obv. just if you don't mind and as far as maybe NDAs allow for.

 

[aprayoga]

Hi everyone, thank you for all of your support.

I'll be still around but not in full time as before.

 

I saw Helios64 has several issues in this new release. I will start looking into it.

[SIGSEGV]

18 hours ago, aprayoga said:

Hi everyone, thank you for all of your support.

I'll be still around but not in full time as before.

 

I saw Helios64 has several issues in this new release. I will start looking into it.

Thank you @aprayoga

[ThisGuy]

I have been very sad that Kobol is finished.  I really think these products were great, and I really love the idea that they were open source.

 

Speaking of which, since these products are now discontinued, would it be possible to publish the CAD / Gerber files for these boards?  I know there are diagrams and schematics, but if the actual source files are available it would be possible to have another company continue producing and maybe improving these.  That would make this TRULY open hardware.

[ebin-dev]

Kobol stopped operations (partly due to the chip shortage) and @gprovost himself did not exclude that Kobol may resume operations some time again.

I am still hoping that we will see a follow-up of Helios64 based on a successor of the rk3399 developed by Kobol.

[Alexander Eiblinger]

vor 22 Stunden schrieb ebin-dev:

I am still hoping that we will see a follow-up of Helios64 based on a successor of the rk3399 developed by Kobol.

 

The question is, if you would trust them again ... they pulled the trigger already once and let their customers alone.

 

[Igor]

1 hour ago, Alexander Eiblinger said:

and let their customers alone.

 

They were honest in this decision, weren't they?

Can't say this is a general practice in the world where leaning to community resources and reselling "Linux" is the way to sell hardware.

 

We have support know-how and we would take their customers, but the problem is that we can't afford doing that and pay for everything. End users (also vendors doesn't like) are not willing to compensate for the damages such support service will create. Frustration and violence from end users generates stress and people that waste weeks and months staring into the code and solve problems has to eat. I understand you would expect support service from vendors, but they expect that community will fill the gap they are not able to cover. None of vendors has that ability and most of other vendors would remain in the cave if there would not be community support. Just this device doesn't attract enough people since it's too special.

 

On 12/23/2021 at 3:51 PM, ThisGuy said:

I really think these products were great, and I really love the idea that they were open source.

 

Great hw, indeed. Sources are available, Armbian even provide high-end build framework to support R&D and maintenance activities, forum for finding people with the same problems ... Now, someone needs to sponsor support lead and hire let's say two full time developers to proceed with support.

 

We provide and maintain expensive infrastructure, which vendor saw as advantage. Perhaps this is the way to start with developing resources to get what you need.

[Alexander Eiblinger]

Zitat

They were honest in this decision, weren't they?

 

They were. 

But you should also see the other side:
I purchased Helios64 with the assumption of buying a solid and reliable NAS system - which is linux based = open. I also had the assumption that Kobol will support the device for at least 2-3 years ...

What I got was:

• A definitively cool and powerful Linux NAS system
• where Wake on Lan does not work (although it was advertised) ... and prop. never will work (one of my reasons to buy!)
• where the 2.5 GB LAN port only works reliable with 2.5 GB ... (except you're willing to solder SMD - and risk to mess it up completely)(I was under the - reasonable - assumption that this port will also work well with GB LAN ... one reason to buy!)
• where the SATA Ports / cables seem to have troubles (at least my btrfs degrades every now an then, according to the forum, others have the same issue ...) ... a solution will never be available!
• where it is hard to get a running updated system, as you're in the risk of losing functionality 
• where you will get no spare parts, etc. anymore ... also no second (replacement) unit (unless you want to buy an used one - which is not that easy, as they are rare).
• where you will get no real support anymore (also "support" and "warranty" was rather limited anyhow). 
• ...

My personal conclusion: A rather mixed feeling ... I did not really get what I bought. I'm now sitting on an island, which I have to take as it is, depending on "the community" for each upgrade (and for security reasons sometimes you need to update!). Technically the best thing to do would be to sell the unit. 

 

I expected that these type of products, coming from China/Singapur, heavily relaying on the community, have "limited" durability. But - for me - less than a year, was really unexpected to me! So even if Kobol team would return, not sure if I ever would buy from them again ...

 

 

[ebin-dev]

24 minutes ago, Alexander Eiblinger said:

So even if Kobol team would return, not sure if I ever would buy from them again ...

I can understand that you are disappointed.

 

But I think that Kobol had to pull the plug, in the context of the current chip shortage - with limited (sometimes even no) availability of components and SOCs and rising prices. That is not the right environment for a small start-up to grow. - it is a rather toxic environemnt that will lead to insolvency, as profitable growth is impossible to achieve. Without growth (no new/further products to offer) you are just faced with fixed costs and without income. Not sustainable at all.

 

All three of the founding members of Kobol deserve our full respect. They only drew a logical conclusion. Hopefully it can be reversed some time.

[Igor]

18 hours ago, Alexander Eiblinger said:

But you should also see the other side

 

Did you ever checked what Armbian do for you on their expense?

 

18 hours ago, Alexander Eiblinger said:

depending on "the community" for each upgrade

 

Consumers and HW vendor are always depending heavily on community, on our investment (which creates nothing but expenses). It is your problem that you believe in something that is complete fabrication, a fat lie if that term suits better. There are three sides in this game and two of them - consumers and HW vendor are abusing the 3rd. There is no magic in this. This is just how this business works.

 

18 hours ago, Alexander Eiblinger said:

not sure if I ever would buy from them again

Do you really think other players in this field are any better?

[rjgould]

On 12/27/2021 at 10:05 AM, Igor said:

Did you ever checked what Armbian do for you on their expense?

 

Speaking just for myself here, I think the Armbian team have been amazing in relation to the Helios64.  Especially so given the fact that Kobol has gone away.

 

I wish I knew or understood enough about building Linux to be more helpful in terms of keeping it supported but I honestly don't understand any of it.

 

The product wasn't perfect but it was a Kickstarter after all and I've still not seen anything else on ARM yet with the same amount of SATA ports available.

 

Hopefully any future board creators will learn that they should create symbiotic relationships with Armbian and provide time and resources to the project.

[bunducafe]

Just a quick question: Is there any community related development regarding the helios64? I know there is no official support but I am curious where to look whether there are some coders who do so. When setting up the helios from scracth I found the archived download page that contain the old images and of course I can use them. But I just wonder if there is any form of development.

 

Otherwise I also will have too look into compile kernels myself

[Werner]

Only general development on rockchip64 family. However since Helios64 has no maintainer changes there could also break functionality.

[bunducafe]

Okay, after I dared to do an upgrade last week my helios64 is not constantly trying to reboot. I am back with an old backup now but just wonder how you guys are doing it: Freeze the kernel updates? Or do you indeed compile yourselves?

 

To be honest I could not dig into compiling a kernel myself so far as I don't have the time right now. But somehow I think it will be the only solution in the end (or get rid of the helios64 and change to a different board).

[ebin-dev]

@bunducafe I am still running this system:  Armbian 21.08.2 Bullseye with Linux 5.10.43-rockchip64.

The Armbian image should still be available in the archive and I downgraded linux to 5.10.43, since this is the last version able to access emmc with hs400.

Since there is no maintainer I have disabled any updates through the Armbian channel (in /etc/apt/sources.list.d/armbian.list).

Debian Bullseye updates are not affected in any way by this and still arrive from time to time. That is fine for now.

[usual user]

3 hours ago, bunducafe said:

To be honest I could not dig into compiling a kernel myself so far as I don't have the time right now.

If it's just about a current mainline kernel build, I might be able to offer my build.
I know from the experiment in this thread, that my kernel builds are working for Helios64. It is possible to keep as many different kernels installed as persistent space is available. A kernel upgrade  will never leave an unbootable system behind as long as a previously working one is  still installed. So if someone wants to experiment with my kernels, you have to let  me know and I will talk you thru the experiment.

[bunducafe]

vor 16 Stunden schrieb ebin-dev:

Since there is no maintainer I have disabled any updates through the Armbian channel (in /etc/apt/sources.list.d/armbian.list).

Debian Bullseye updates are not affected in any way by this and still arrive from time to time. That is fine for now.

 

Okay. Just wondering, how you are disable the armbian.list. Here I only have one entry and so far I went down the freeze kernel via armbian-config. Is there any difference? And if so, what would it be.

 

vor 15 Stunden schrieb usual user:

If it's just about a current mainline kernel build, I might be able to offer my build.

 

Thanks you for the offer. I will look into your link once I am back in my office and then might get back to you in the near future  That's very kind.

 

BTW: The actual culprit of my random reboots has not been a faulty upgrade rather than the USP Battery caused the problems and made my machine unusable (did not react when pressing buttons and rebooted every 10 minutes). After ripping the USP out everything works flawlessly again. 

[ebin-dev]

8 hours ago, bunducafe said:

Okay. Just wondering, how you are disable the armbian.list.

 

Just put a # in front of the line in armbian.list (should have the same effect as freeze kernel in armbian-config):

cat  /etc/apt/sources.list.d/armbian.list
# deb http://apt.armbian.com bullseye main bullseye-utils bullseye-desktop

 

Regarding a new kernel: the new ones (newer than 5.10.43) do not support emmc speed HS400, seem to have issues with the 2.5Gb/s interface (transfer rates are about half the speed), and the switch to the new mainlined bootloader is essentially untested... Would be wise to focus on this - besides the general stability.

Edited August 19, 2022 by ebin-dev

[usual user]

2 hours ago, ebin-dev said:

Regarding a new kernel: the new ones (newer than 5.10.43) do not support emmc speed HS400

The kernel has support for it and my rk3399 device makes use of it:

Spoiler

dmesg
mmc2: SDHCI controller on fe330000.mmc [fe330000.mmc] using ADMA
mmc2: Command Queue Engine enabled
mmc2: new HS400 Enhanced strobe MMC card at address 0001
mmcblk2: mmc2:0001 AJTD4R 14.6 GiB
mmcblk2boot0: mmc2:0001 AJTD4R 4.00 MiB
mmcblk2boot1: mmc2:0001 AJTD4R 4.00 MiB
mmcblk2rpmb: mmc2:0001 AJTD4R 4.00 MiB, chardev (507:0)

********************************************************************************
FriendlyElec NanoPC-T4
CPU 0-3: schedutil 408 MHz - 1416 MHz
CPU 4-5: schedutil 408 MHz - 1800 MHz
6.0.0-0.rc1.13.fc34.aarch64 #1 SMP PREEMPT_DYNAMIC Mon Aug 15 19:33:39 CEST 2022
hdparm -ITt --direct /dev/disk/by-path/${device}
********************************************************************************
/dev/disk/by-path/platform-f8000000.pcie-pci-0000:01:00.0-nvme-1:
 Timing O_DIRECT cached reads:   2064 MB in  2.00 seconds = 1033.92 MB/sec
 Timing O_DIRECT disk reads: 3220 MB in  3.00 seconds = 1072.93 MB/sec
********************************************************************************
/dev/disk/by-path/platform-fe320000.mmc:
 Timing O_DIRECT cached reads:   118 MB in  2.02 seconds =  58.34 MB/sec
 Timing O_DIRECT disk reads: 124 MB in  3.02 seconds =  41.03 MB/sec
********************************************************************************
/dev/disk/by-path/platform-fe330000.mmc:
 Timing O_DIRECT cached reads:   486 MB in  2.00 seconds = 242.63 MB/sec
 Timing O_DIRECT disk reads: 778 MB in  3.00 seconds = 259.28 MB/sec
********************************************************************************
/dev/disk/by-path/platform-fe3c0000.usb-usb-0:1:1.0-scsi-0:0:0:0:
 Timing O_DIRECT cached reads:    52 MB in  2.00 seconds =  25.94 MB/sec
 Timing O_DIRECT disk reads:  86 MB in  3.02 seconds =  28.48 MB/sec
********************************************************************************
/dev/disk/by-path/platform-xhci-hcd.0.auto-usb-0:1.1:1.0-scsi-0:0:0:0:
 Timing O_DIRECT cached reads:   578 MB in  2.00 seconds = 288.67 MB/sec
 Timing O_DIRECT disk reads: 916 MB in  3.00 seconds = 305.26 MB/sec
********************************************************************************

 

Why it isn't wired up for Helios64 I can't tell, but when my kernel is running it can be wired up and tested.

[bunducafe]

vor 18 Stunden schrieb ebin-dev:

Regarding a new kernel: the new ones (newer than 5.10.43) do not support emmc speed HS400, seem to have issues with the 2.5Gb/s interface (transfer rates are about half the speed), and the switch to the new mainlined bootloader is essentially untested... Would be wise to focus on this - besides the general stability.

 

For me a nobrainer, as I am sticking with SD cards in order to not have the hassle if something really goes wrong as they are easier to backup. But in any case I have this kernel also as a running backup on a SD Card