Jump to content
  • 0

Kobol Team is pulling the plug ;(


rjgould
 Share

Question

29 answers to this question

Recommended Posts

  • 0

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 :)

Link to comment
Share on other sites

When discussing a problem make sure to provide full logs!

  • 0

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.

Link to comment
Share on other sites

  • 0

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....

Link to comment
Share on other sites

  • 0

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. 

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

 

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0

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.

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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 ...

 

 

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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?

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0

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 ;)

Link to comment
Share on other sites

  • 0

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).

Link to comment
Share on other sites

  • 0

@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.

Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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. 

Link to comment
Share on other sites

  • 0
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 by ebin-dev
Link to comment
Share on other sites

  • 0
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.

Link to comment
Share on other sites

  • 0
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 :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Answer this question...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
 Share

×
×
  • Create New...