4 ms·

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

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.

bitL 4y ago
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.
- ronsor 4y ago
  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.
  - themoonisachees 4y ago
    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.
    - happymellon 4y ago
      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.
    - TheLoafOfBread 4y ago
      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.
  - karteum 4y ago
    > 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.
    - cromka 4y ago
      > 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?
- Mave83 4y ago
  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.
eek2121 4y ago
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.
- dingosity 4y ago
  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.
- psychphysic 4y ago
  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.
- happymellon 4y ago
  Do you know if it has Tensorflow support? I might order one of these for a Mycroft unit.
moondev 4y ago
I'm guessing these are not SystemReady certified with UEFI firmware and require "bespoke" preinstalled arm images? https://www.arm.com/architecture/system-architectures/systemready-certification-program https://www.arm.com/architecture/system-architectures/system... https://developer.arm.com/documentation/102677/0100/UEFI-requirements 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 https://developer.nvidia.com/embedded/downloads#?search=uefi Honeycomb LX2 - https://github.com/SolidRun/lx2160a_uefi https://github.com/SolidRun/lx2160a_uefi RPI4 - https://github.com/pftf/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 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
- techdragon 4y ago
  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.
squarefoot 4y ago
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://www.armbian.com/download/?device_support=Supported https://dietpi.com/#download 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.
- ekianjo 4y ago
  > 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.
  - squarefoot 4y ago
    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.
DannyBee 4y ago
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.

bitL 4y ago

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.

ronsor 4y ago
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.
- themoonisachees 4y ago
  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.
  - happymellon 4y ago
    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.
  - TheLoafOfBread 4y ago
    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.
- karteum 4y ago
  > 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.
  - cromka 4y ago
    > 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?
Mave83 4y ago
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.

eek2121 4y ago

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.

dingosity 4y ago
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.
psychphysic 4y ago
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.
happymellon 4y ago
Do you know if it has Tensorflow support? I might order one of these for a Mycroft unit.

moondev 4y ago

I'm guessing these are not SystemReady certified with UEFI firmware and require "bespoke" preinstalled arm images? https://www.arm.com/architecture/system-architectures/systemready-certification-program https://www.arm.com/architecture/system-architectures/system... https://developer.arm.com/documentation/102677/0100/UEFI-requirements 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 https://developer.nvidia.com/embedded/downloads#?search=uefi Honeycomb LX2 - https://github.com/SolidRun/lx2160a_uefi https://github.com/SolidRun/lx2160a_uefi RPI4 - https://github.com/pftf/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 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

techdragon 4y ago
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.

squarefoot 4y ago

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://www.armbian.com/download/?device_support=Supported https://dietpi.com/#download 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.

ekianjo 4y ago
> 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.
- squarefoot 4y ago
  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.

DannyBee 4y ago

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.