8 ms·

This post nicely sums up why I just cannot get excited about anyone's announcement of some new and (on paper) awesome SBC with specs much better than those of a

by c0l0 4y ago

This post nicely sums up why I just cannot get excited about anyone's announcement of some new and (on paper) awesome SBC with specs much better than those of a contemporary Raspberry Pi. Software ecosystem support is THE killer feature for this class of device. And the RPI has, despite its fundamental shortcomings (needing the proprietary GPU to manage bootup, etc.), the best story in that particular department by so much that it's not even a contest.

jancsika 4y ago
> And the RPI has, despite its fundamental shortcomings (needing the proprietary GPU to manage bootup, etc.), the best story in that particular department by so much that it's not even a contest. Exactly! On the RPI if I want to watch HBO Max without stuttering, all I do is apt install Chromium in Raspbian Buster, fuck around with a dozen or so startup flags, give up, try Kodi, notice that there's no official plugin, install a conceivably legal plugin from "http://k.slyguy.xyz http://k.slyguy.xyz", unzip it, twiddle some quality settings, and put up with intermittent stuttering that's slightly better than when I started the whole process. I'm just guessing at the Kodi part[1] since I've only made it to the "give up on Chromium" part so far. Anyway, it's probably less work than what the author describes. Probably. 1: https://www.firesticktricks.com/hbo-max-kodi-addon.html https://www.firesticktricks.com/hbo-max-kodi-addon.html
- RealStickman_ 4y ago
  I have a Pi 4 and a Rock64Pro, both with LibreElec (basically Kodi) installed. The video playback performance and stability of the Pi 4 beat the Rock64 handily.
  - petre 4y ago
    I run LibreElec on a RPi3 A+, which has the advantage of a regular HDMI port. It runs 1080p H264 smoothly. I haven't tried 4k or H265 yet.
    - dspillett 4y ago
      Using Kodi via LibreElec on a Pi3 (a B IIRC, not a B+) and x265 was a mixed bag. There is no hardware acceleration unlike on the Pi4 so it runs the general CPU cores hard. 720P was fine, but without extra cooling 1080P in summer months would eventually (60 to 90 minutes) cause it to thermal throttle and playback would fall apart. Given how warm it felt soon after starting playback, I was surprised it managed that long before throttling. You will likely get much better results with a cooling solution of some kind, particularly an active one.
      - petre 4y ago
        I'm using a regular radiator in a 3D printed box with big holes (2…3 mm wide and 4 cm long). If it needs a fan, I wouldn't use it as a media player.
        dspillett 4y ago
        > If it needs a fan, I wouldn't use it as a media player. Same here. You might get away with higher resolution x265 with passive cooling (a really good heatsink), especially if the device is in a reliably cool environment, but around the time I started using such encoded media the Pi4 was readily available which does 265 in hardware so no similar heat problem (the Pi3 is now used for other experiments). Unfortunately current supply issues might preclude you using that upgrade option!
- zokier 4y ago
  best doesn't imply good
- edapiieaway 4y ago
  Streaming is a huge weakness of the Pi platform. It seems like the big sites change their DRM every few months, and everything stops working. A couple of years ago, I could happily use a Pi400 as a streaming box for my TV. Today, it's only good for playing videos off of an external drive with stock Raspbian. This was one big reason why I cancelled my Netflix subscription. In fairness though, I seriously doubt that other SBCs have better streaming support. Is there a project like OpenWRT for HDMI sticks like Roku, Fire TV, etc?
- luma 4y ago
  The process you link doesn't seem to be related to an rPi, rather, trying to get Kodi to play HBO. Am I misunderstanding something? Would this process be any easier on a Rock64?
- bsder 4y ago
  > On the RPI if I want to watch HBO Max without stuttering Then you're probably not in the "embedded" space. You're in the "I want a cheap desktop/laptop" space. You don't need video to run a gateway. You don't need video to drive a piece of machinery. etc.
  - frostwarrior 4y ago
    The amount of performance that these SBCs are capable of delivering makes them attractive for power users that want to use them as little Linux desktop machines. Only to be incredibly disappointed once they don't deliver what they're expected by specs alone
    - imtringued 4y ago
      I have a phone with a Snapdragon 888 and it is still too slow to do anything useful with it. Building software with gradle takes forever.
  - jancsika 4y ago
    > You don't need video to run a gateway. Sure. But if you get almost all the way through watching an entire episode of Barry on your gateway and then it stutters, trust me-- you're going to loudly ask why the hell this gateway won't do the goddamned thing it's supposed to.
- Abishek_Muthian 4y ago
  The day when RPi's browsers can play HW accelerated video without stutter, It's truly ready for desktop; Then again even with intel GPU's excellent Linux support getting HW accelerated (4k) video on browsers is not possible without some funny business(at least on Wayland). Interestingly x86 ChromeOS machines with low memory (4GB) didn't have issues with HW accelerated videos, I wonder whether the ARM ChromeOS machines of that era had issues?
turminal 4y ago
> Software ecosystem support is THE killer feature for this class of device. This is really a sad state of things and a signal something is fundamentally broken in this class of devices.
- megous 4y ago
  You shouldn't need any "ecosystem" just a bootloader, TF-A and a kernel. The rest should be abstracted away for you by the kernel, unless you're doing something really heavily reliant on details of the HW, like implementing a smartphone functionality. And that's how I use all of my SBCs (I just counted I have 7 different SoCs on my various boards and mobile devices). I put on a regular whatever distro on all of them (Arch Linux ARM in my case, but it can be anything. That's the point. The distro doesn't need to "support" my board.) it and I only figure out my own kernel and bootloader builds. Bootloader can be figured out once and forgotten about. Kernel just needs a quick update now and then, if I care. Nothing much harder than a make && make install with some env vars set and a corss-compiler installed on my workstation. I don't need any special board specific software ecosystem provided by some foundation for normal desktop or server uses. It's already there (any GNU/Linux on ARM distribution must work), and it's generic. If the SoC is so bizarre that it can't just run U-Boot/TF-A/Linux/any distro in rootfs in that order, and requires something custom, including non-standard tools in userspace to control basic things like display output, etc., that may not be worth bothering with, but that's only really a domain of Raspberry Pi, and not common anywhere else. Some distros provide generic kernel builds and a proper bootloader/device tree already, for many boards. So if someone is not interested in building their own, they don't need to. That may limit the choice of the distro though. But it's just an artificial limit.
RicoElectrico 4y ago
It so often comes to some sloppiness on the driver side. I can't help myself but think of "cha bu duo". In my experience Chinese companies (i.e. where most other SBC SoCs are designed) are notorious for having all the ingredients, yet making silly decisions that aren't really even for cost-cutting. https://www.sourcingallies.com/blog/cha-bu-duo https://www.sourcingallies.com/blog/cha-bu-duo
- lvturner 4y ago
  Loosely translated “close enough” still burned in to my ears. Either hilarious, terrifying or deeply disappointing depending on the context.
- grosswait 4y ago
  Thanks for sharing. A good read and fascinating insight.
- ethbr0 4y ago
  Exactly. Just reading this gave me PTSD and makes me glad I don't work with embedded anymore. My memories are of Indiana Jones-esque gymnastics after stepping on functionality that should have been solid... but turned out to have either been not implemented or implemented in a known-broken way. It makes me appreciate how good enterprise, desktop, and server software actually is. And understand why Apple and Google both put in the approval speed bumps they did for apps. The minimum quality floor is far lower than you would expect... I think the only sane use of most niche embedded stuff is if you're building a product for a single use case and have a team. Aiming for general purpose & everything works? Hell no!
DCKing 4y ago
I've started looking more at thin clients to take roles of small servers that people go to Raspberry Pis for. Small cheap Intel Atom based thin clients usually don't even outperform the Raspberry Pi 4 in either peak performance or power efficiency, but they're close enough in both areas that for "I just need a small server" it's not a meaningful difference. Plus they come in a case, should have reliable storage and decent IO included, and they just boot and run whatever bog standard Debian ISO I can download from debian.org with zero issues now and for years and years to come. If you can find them for a good price on eBay or the likes, it's well worth the convenience over any ARM board if all you want is to run a server - I find it preferable to the Raspberry Pi, and especially other ARM SBC hardware.
- epx 4y ago
  Expectation: dirt-cheap, power-efficient and reasonably fast SBC computers so you can dedicate one per service (or form a cluster!). Reality: a RPI 4 costing as much as a whole Intel NUC, but slower, without upgradable RAM, without native ports to mass storage (SATA/M.2), and not as reliable. Didn't even have to think that far to see that SBC computers are a joke^W^W not there yet. Considered buying a NanoPi or a Raspberry CM + some board to build a router, with at least 2 physical Gigabit ports. Tallying up all components (sbc, case, power supply, heat sink, etc.) made the NUC with 4 gigabit ports look a bargain. I really wanted to go the !x86 route, but...
jandrese 4y ago
These embedded devices have needed something like UEFI for well over a decade now. Back in the old old days when they shipped with 4MB of storage for Kernel, OS, and application it made a bit of sense to have everything stripped to the bone like this, but storage is so cheap now that even bottom of the barrel hardware ships with 64MB. There is plenty room for a standardized boot and hardware discovery process, yet nobody seems to have any interest in actually implementing it.
- oynqr 4y ago
  Take a look at tow-boot. It's u-boot with sensible defaults. There are no builds for the rock64 yet, though.
  - speed_spread 4y ago
    Resuscitating OpenBoot would be great for these devices. It used to be the BIOS of PPC Macs and Sun SPARCs. OpenBoot "programs" (PCI video card BIOS, PCI network card BIOS) were actually Forth bytecode compiled on the fly to the target architecture upon boot, so you could have architecture-independent extension cards.
apple4ever 4y ago
Seriously agree. And that has always been the biggest problem with PINE. They'r software ecosystem is terrible.
- megous 4y ago
  There's no "theirs" software ecosystem.
  - apple4ever 4y ago
    Yes, that's the problem.
    - megous 4y ago
      Why? People constantly complain about vendor's BSP packages. Not sure why it would be any different with hypothetical Pine64's one.
moonbug 4y ago
> despite its fundamental shortcomings (needing the proprietary GPU to manage bootup, etc far from being a fundamental shortcoming, that's entirely inconsequential.
heavyset_go 4y ago
I won't be buying any more ARM SoCs unless they start shipping with UEFI, ACPI or SBSA like ARM servers do. That includes Raspberry Pis, and laptops and tablets using ARM SoCs without SBSA.
- chris37879 4y ago
  Checkout Tow-Boot, it's not 100% there yet, but I'm using it to EFI boot nixos on a pinephone, granted it's the Alwinner one, not the rockchip one, but still.
  - heavyset_go 4y ago
    Does it still require DeviceTree or custom images? Because that's what I'm trying to avoid, I want to stick with devices I can load any generic ISO on. So far the only thing in the ARM space I've seen are servers.
Havoc 4y ago
I think it's mostly the ARM part rather than SBC. Just got a new SBC (Zimaboard) and slapped TrueNAS onto it and seems to work just fine

by c0l0 4y ago

jancsika 4y ago

> And the RPI has, despite its fundamental shortcomings (needing the proprietary GPU to manage bootup, etc.), the best story in that particular department by so much that it's not even a contest. Exactly! On the RPI if I want to watch HBO Max without stuttering, all I do is apt install Chromium in Raspbian Buster, fuck around with a dozen or so startup flags, give up, try Kodi, notice that there's no official plugin, install a conceivably legal plugin from "http://k.slyguy.xyz http://k.slyguy.xyz", unzip it, twiddle some quality settings, and put up with intermittent stuttering that's slightly better than when I started the whole process. I'm just guessing at the Kodi part[1] since I've only made it to the "give up on Chromium" part so far. Anyway, it's probably less work than what the author describes. Probably. 1: https://www.firesticktricks.com/hbo-max-kodi-addon.html https://www.firesticktricks.com/hbo-max-kodi-addon.html

RealStickman_ 4y ago
I have a Pi 4 and a Rock64Pro, both with LibreElec (basically Kodi) installed. The video playback performance and stability of the Pi 4 beat the Rock64 handily.
- petre 4y ago
  I run LibreElec on a RPi3 A+, which has the advantage of a regular HDMI port. It runs 1080p H264 smoothly. I haven't tried 4k or H265 yet.
  - dspillett 4y ago
    Using Kodi via LibreElec on a Pi3 (a B IIRC, not a B+) and x265 was a mixed bag. There is no hardware acceleration unlike on the Pi4 so it runs the general CPU cores hard. 720P was fine, but without extra cooling 1080P in summer months would eventually (60 to 90 minutes) cause it to thermal throttle and playback would fall apart. Given how warm it felt soon after starting playback, I was surprised it managed that long before throttling. You will likely get much better results with a cooling solution of some kind, particularly an active one.
    - petre 4y ago
      I'm using a regular radiator in a 3D printed box with big holes (2…3 mm wide and 4 cm long). If it needs a fan, I wouldn't use it as a media player.
      - dspillett 4y ago
        > If it needs a fan, I wouldn't use it as a media player. Same here. You might get away with higher resolution x265 with passive cooling (a really good heatsink), especially if the device is in a reliably cool environment, but around the time I started using such encoded media the Pi4 was readily available which does 265 in hardware so no similar heat problem (the Pi3 is now used for other experiments). Unfortunately current supply issues might preclude you using that upgrade option!
zokier 4y ago
best doesn't imply good
edapiieaway 4y ago
Streaming is a huge weakness of the Pi platform. It seems like the big sites change their DRM every few months, and everything stops working. A couple of years ago, I could happily use a Pi400 as a streaming box for my TV. Today, it's only good for playing videos off of an external drive with stock Raspbian. This was one big reason why I cancelled my Netflix subscription. In fairness though, I seriously doubt that other SBCs have better streaming support. Is there a project like OpenWRT for HDMI sticks like Roku, Fire TV, etc?
luma 4y ago
The process you link doesn't seem to be related to an rPi, rather, trying to get Kodi to play HBO. Am I misunderstanding something? Would this process be any easier on a Rock64?
bsder 4y ago
> On the RPI if I want to watch HBO Max without stuttering Then you're probably not in the "embedded" space. You're in the "I want a cheap desktop/laptop" space. You don't need video to run a gateway. You don't need video to drive a piece of machinery. etc.
- frostwarrior 4y ago
  The amount of performance that these SBCs are capable of delivering makes them attractive for power users that want to use them as little Linux desktop machines. Only to be incredibly disappointed once they don't deliver what they're expected by specs alone
  - imtringued 4y ago
    I have a phone with a Snapdragon 888 and it is still too slow to do anything useful with it. Building software with gradle takes forever.
- jancsika 4y ago
  > You don't need video to run a gateway. Sure. But if you get almost all the way through watching an entire episode of Barry on your gateway and then it stutters, trust me-- you're going to loudly ask why the hell this gateway won't do the goddamned thing it's supposed to.
Abishek_Muthian 4y ago
The day when RPi's browsers can play HW accelerated video without stutter, It's truly ready for desktop; Then again even with intel GPU's excellent Linux support getting HW accelerated (4k) video on browsers is not possible without some funny business(at least on Wayland). Interestingly x86 ChromeOS machines with low memory (4GB) didn't have issues with HW accelerated videos, I wonder whether the ARM ChromeOS machines of that era had issues?

turminal 4y ago

> Software ecosystem support is THE killer feature for this class of device. This is really a sad state of things and a signal something is fundamentally broken in this class of devices.

megous 4y ago
You shouldn't need any "ecosystem" just a bootloader, TF-A and a kernel. The rest should be abstracted away for you by the kernel, unless you're doing something really heavily reliant on details of the HW, like implementing a smartphone functionality. And that's how I use all of my SBCs (I just counted I have 7 different SoCs on my various boards and mobile devices). I put on a regular whatever distro on all of them (Arch Linux ARM in my case, but it can be anything. That's the point. The distro doesn't need to "support" my board.) it and I only figure out my own kernel and bootloader builds. Bootloader can be figured out once and forgotten about. Kernel just needs a quick update now and then, if I care. Nothing much harder than a make && make install with some env vars set and a corss-compiler installed on my workstation. I don't need any special board specific software ecosystem provided by some foundation for normal desktop or server uses. It's already there (any GNU/Linux on ARM distribution must work), and it's generic. If the SoC is so bizarre that it can't just run U-Boot/TF-A/Linux/any distro in rootfs in that order, and requires something custom, including non-standard tools in userspace to control basic things like display output, etc., that may not be worth bothering with, but that's only really a domain of Raspberry Pi, and not common anywhere else. Some distros provide generic kernel builds and a proper bootloader/device tree already, for many boards. So if someone is not interested in building their own, they don't need to. That may limit the choice of the distro though. But it's just an artificial limit.

RicoElectrico 4y ago

It so often comes to some sloppiness on the driver side. I can't help myself but think of "cha bu duo". In my experience Chinese companies (i.e. where most other SBC SoCs are designed) are notorious for having all the ingredients, yet making silly decisions that aren't really even for cost-cutting. https://www.sourcingallies.com/blog/cha-bu-duo https://www.sourcingallies.com/blog/cha-bu-duo

lvturner 4y ago
Loosely translated “close enough” still burned in to my ears. Either hilarious, terrifying or deeply disappointing depending on the context.
grosswait 4y ago
Thanks for sharing. A good read and fascinating insight.
ethbr0 4y ago
Exactly. Just reading this gave me PTSD and makes me glad I don't work with embedded anymore. My memories are of Indiana Jones-esque gymnastics after stepping on functionality that should have been solid... but turned out to have either been not implemented or implemented in a known-broken way. It makes me appreciate how good enterprise, desktop, and server software actually is. And understand why Apple and Google both put in the approval speed bumps they did for apps. The minimum quality floor is far lower than you would expect... I think the only sane use of most niche embedded stuff is if you're building a product for a single use case and have a team. Aiming for general purpose & everything works? Hell no!

DCKing 4y ago

I've started looking more at thin clients to take roles of small servers that people go to Raspberry Pis for. Small cheap Intel Atom based thin clients usually don't even outperform the Raspberry Pi 4 in either peak performance or power efficiency, but they're close enough in both areas that for "I just need a small server" it's not a meaningful difference. Plus they come in a case, should have reliable storage and decent IO included, and they just boot and run whatever bog standard Debian ISO I can download from debian.org with zero issues now and for years and years to come. If you can find them for a good price on eBay or the likes, it's well worth the convenience over any ARM board if all you want is to run a server - I find it preferable to the Raspberry Pi, and especially other ARM SBC hardware.

epx 4y ago
Expectation: dirt-cheap, power-efficient and reasonably fast SBC computers so you can dedicate one per service (or form a cluster!). Reality: a RPI 4 costing as much as a whole Intel NUC, but slower, without upgradable RAM, without native ports to mass storage (SATA/M.2), and not as reliable. Didn't even have to think that far to see that SBC computers are a joke^W^W not there yet. Considered buying a NanoPi or a Raspberry CM + some board to build a router, with at least 2 physical Gigabit ports. Tallying up all components (sbc, case, power supply, heat sink, etc.) made the NUC with 4 gigabit ports look a bargain. I really wanted to go the !x86 route, but...

jandrese 4y ago

These embedded devices have needed something like UEFI for well over a decade now. Back in the old old days when they shipped with 4MB of storage for Kernel, OS, and application it made a bit of sense to have everything stripped to the bone like this, but storage is so cheap now that even bottom of the barrel hardware ships with 64MB. There is plenty room for a standardized boot and hardware discovery process, yet nobody seems to have any interest in actually implementing it.

oynqr 4y ago
Take a look at tow-boot. It's u-boot with sensible defaults. There are no builds for the rock64 yet, though.
- speed_spread 4y ago
  Resuscitating OpenBoot would be great for these devices. It used to be the BIOS of PPC Macs and Sun SPARCs. OpenBoot "programs" (PCI video card BIOS, PCI network card BIOS) were actually Forth bytecode compiled on the fly to the target architecture upon boot, so you could have architecture-independent extension cards.

apple4ever 4y ago

Seriously agree. And that has always been the biggest problem with PINE. They'r software ecosystem is terrible.

megous 4y ago
There's no "theirs" software ecosystem.
- apple4ever 4y ago
  Yes, that's the problem.
  - megous 4y ago
    Why? People constantly complain about vendor's BSP packages. Not sure why it would be any different with hypothetical Pine64's one.

moonbug 4y ago

> despite its fundamental shortcomings (needing the proprietary GPU to manage bootup, etc far from being a fundamental shortcoming, that's entirely inconsequential.

heavyset_go 4y ago

I won't be buying any more ARM SoCs unless they start shipping with UEFI, ACPI or SBSA like ARM servers do. That includes Raspberry Pis, and laptops and tablets using ARM SoCs without SBSA.

chris37879 4y ago
Checkout Tow-Boot, it's not 100% there yet, but I'm using it to EFI boot nixos on a pinephone, granted it's the Alwinner one, not the rockchip one, but still.
- heavyset_go 4y ago
  Does it still require DeviceTree or custom images? Because that's what I'm trying to avoid, I want to stick with devices I can load any generic ISO on. So far the only thing in the ARM space I've seen are servers.

Havoc 4y ago

I think it's mostly the ARM part rather than SBC. Just got a new SBC (Zimaboard) and slapped TrueNAS onto it and seems to work just fine