Hacker News Reader

Comment by bastard_op | Hacker News Reader

It would be nice if the software weren't terrible and they properly make linux kernel contributions to make their product usable. Every chinese soc that comes out is a broken experience out of box, rpi is about the only vendor that supports their product adequately. Until this changes, these chips will always be nothing more than a novelty and simple money grab left dumbfounded at why they failed so painfully.

View on HN

Most of these chips have perfectly fine Linux kernel support, it just comes more from the community rather than the vendor, and that is a common practice among pretty much all manufacturers other than the Raspberry PI Foundation. Just pick the distribution that suits your needs. Either the usual ones that already support the ARM architecture (Debian, Alpine, etc) or others specifically made for embedded systems such as Armbian and DietPI. Hardware support is a moving target; if your board doesn't appear there today, check the forums, then return in a week. The amount of work these folks are doing is amazing and well worth of donations and other contribution.

https://www.armbian.com/download/?device_support=Supported

https://dietpi.com/#download

Using a distribution developed by the community is a lot better than relying from the vendor: no planned obsolescence because the vendor wants to sell the latest board, and great integration between different boards from different manufacturers. Of course that means some more time to wait until support by the community reaches a stable state, which I concur can be a subjective problem; not a huge one however.

> Most of these chips have perfectly fine Linux kernel support, it just comes more from the community rather than the vendor

So you mean no actual support and bug fix is pretty much never once the community moved on.

"The community" is not a magic bullet.

I wrote that there's no lack of support due to planned obsolescence, which is very different. Of course the community too eventually moves on, but that usually happens a lot later than the product goes out of production.

Honestly, the StarFive VisionFive 2 RISC-V based board is approaching, or maybe even beyond that reality. It is only slightly more expensive than the Pi 4, is almost just as fast, has way more IO options, is completely open source, and has Ubuntu support coming soon, Debian, etc. I preordered one after the kickstarter, so I guess I'll see how it adds up. I will try to add my thoughts here when I receive it.

Please do. I worked on the Hifive board and was depressed with how expensive it was. StarFive's been coming on strong and I really want to like their products.

I'm very excited! Got it for myself as an Christmas gift.

My only concern is the PCB quality looked poor but they were pre-production models.

Do you know if it has Tensorflow support?

I might order one of these for a Mycroft unit.

I'm guessing these are not SystemReady certified with UEFI firmware and require "bespoke" preinstalled arm images?

https://www.arm.com/architecture/system-architectures/system...

https://developer.arm.com/documentation/102677/0100/UEFI-req...

I have three SystemReady arm devices and it's pretty awesome to be able to just boot an aarch64 live ISO and install. The experience is the same for running vms via ESXi arm edition.

Nvidia Jetson AGX Xavier - https://developer.nvidia.com/embedded/downloads#?search=uefi

Honeycomb LX2 - https://github.com/SolidRun/lx2160a_uefi

RPI4 - https://github.com/pftf/RPi4

It can be tedious building/provisioning the firmware but once complete they are ready for any aarch64 uefi iso.

What is annoying however is when distros don't ship an aarch64 uefi iso - but instead choose to build a zillion device specific "preinstalled" arm images. (looking at you manjaro)

The list of supported devices for ESXi arm edition is a great place to start for identifying options and is constantly updated.

https://flings.vmware.com/esxi-arm-edition

  Raspberry-Pi-4
  Ampere-eMAG-8180
  SolidRun-HoneyComb-LX2K
  NXP-LS1046A-FRWY
  NXP-LS1046A-RDB
  Arm-Neoverse-N1-System
  Ampere-Altra-based-Serv
  NVIDIA-Xavier-AGX-Devel
  NVIDIA-Xavier-NX-Devel
  Ampere-Altra-from-OCI
  Marvell-Armada-A8040-Octeon-TX2
  Socionext-SynQuacer
  PINE64-Quartz64-Model-A

I'm really hoping the PINE64 Quartz64 continues improving its support (I'm looking forward to getting my boards hooked up with a bootloader testing CI pipeline) the progress getting it to use stock UEFI/SystemReady has been good.

The current RPi shortage really highlights the need for multiple cheap(ish), widely available, and well enough supported ARM boards if we want to have a healthy ecosystem for hobby/tinkerers.

Alternative take: Linux could finally create a stable driver ABI so that drivers compiled in 1999 still work with the latest kernel without recompiling, as is with Windows. Until then only the most main-stream devices will be supported.

Alternativer take: vendors should get their drivers upstreamed so they don't have to maintain them much. Of course, this also means publishing decent hardware documentation which they should be doing regardless.

Windows did have and to some extent still has many crappy, old drivers that reduce system stability. We don't need to encourage that on Linux.

> Alternativer take: vendors should get their drivers upstreamed so they don't have to maintain them much

This is ideology. In real-life, some OEMs are binded by NDAs (so they can't do all what they'd like), and the split between hardware and software is quite blurry (chipset vendors don't want to disclose their secrets by open-sourcing their code).

I wish like you that more code would be supported in mainline kernel (just as I wish every single board would support SystemReady/UEFI or any similar solution (ideally more lightweight) so that they could boot a generic kernel just like x86 does (and regardless of the availability of the proper dts for this specific board, which may be hard to download after several years)). But this is not the world we live in.

Because of this "stable-api-nonsense" ideology, we end up with piles of junk (e.g. all old smartphones and boards that become unsupported after 2-3 years... and we only have one planet !) while we can still easily use 10-15 years-old PCs.

> This is ideology. In real-life, some OEMs are binded by NDAs (so they can't do all what they'd like)

This can be solved by offering a binary firmware, can it not?

What is in it for the maintainers who would then have to support hardware they do not neccessarly have access to, adding development time to the linux kernel maintainers who honestly would be better off spending their time improving linux further instead of supporting potentially thousands of users at best?

Imo the responisibility lies with the hardware vendors. Sell your hardware with working software, and support it for x years guaranteed. When the support period ends they can decide to extend it (they wont, but they could) instead of relying on developers who have nothing to do with the product and are working for free for the hardware vendor.

Either that or contract kernel maintainers to upstream it for x years and they do the heavy lifting, but that's always going to be more expensive than doing it in-house.

This is exactly what I am struggling with as well - what's the point of having it in the upstream, when developers CAN'T TEST THE DRIVER WITH THE DEVICE. Just provide some stable API for drivers and let hardware developers do their job. Microsoft Windows understood this, why is it so difficult for Linux Kernel do get the memo.

Why do these things have to be mutually exclusive?

They already hire kernel hackers to build their drivers and bespoke images in the first place.

Make it open source, let it be merged in the Linux kernel, and be happy.

I don't want windows and exactly this outdated shit. I want Linux and vendors that understand, that software is part of their job if they want to sell me hardware.

rockchip does a fine job of getting stuff upstream, actually.

The vendor-specific device trees are not always upstreamed, but you can compile a mainline kernel post-rk3588 release and have it work with the right device tree.

Reply on news.ycombinator.com