4 ms·

ARM isn't a lot better. It helps that the (relatively simple) boards have the schematics available, but most platforms require binary blobs and there are few of

ARM isn't a lot better. It helps that the (relatively simple) boards have the schematics available, but most platforms require binary blobs and there are few of them that don't have a bunch of useful information tucked away behind a gazillion NDAs. The various warts in the implementation (e.g. no BIOS, so there's quite some effort going just into making something boot on a new ARM board) and the non-standard, or just closed source-dependent, augmentations that are required in order to make an ARM CPU do anything breathtaking (PowerVR and Mali, TI's EVEs) also mean that, at least if you're using Linux, you're often living outside the mainline kernel. I have very few kind words to say about some of the code that I've seen in manufacturers' kernel trees, especially on let's-pump-two-more-cores-before-next-years-mobile-world-so-that-we-can-play-a-demo-that-looks-exactly-like-last-year-except-salespeople-are-gasping-for-some-reason, the ancient Indian name by which ARM is also known in some places. I would rather not have useful/important data reside on devices which run that stuff.

kriro 10y ago
I have admittedly not investigated it very deeply but the Beagle Bone Black seems good enough with compromises. AFAIK it will boot without a blob but contains one for the GPU (PowerVR). The device will run non-OpenGL stuff fine and I believe there is some progress on reverse engineering an open driver. There's armv7 (am335x) from OpenBSD which is my base indicator that it's at least somehow usable without any blobs. I'll yield to more informed people but searching a reasonably useful and completely open (I guess I can live without HDL for everything but it would be nice) machine has been a quest I go on every now and then. ARM seems to be the best (and most affordable) bet. I'll gladly take other suggestions as the whole ARM licensing model doesn't really sit well with me.
- notalaser 10y ago
  I go on that quest every once in a while, too, but without too much luck. I haven't ran OpenBSD on the BeagleBone Black, but I imagine it has no graphical output of any kind. I see the X packages but the only on-board devices that are listed as supported are: BeagleBone, BeagleBone Black Supported on-board devices: standard serial port (com) watchdog controller (omdog) ethernet controller (cpsw) GPIO controller (omgpio) so it boots but it seems a little unlikely that you can do much post-1980s work on it. I run into various ARM platforms at $work. The platform, as a whole, is probably a step backwards from e.g. PowerPC; it's very relevant today because its power consumption is very hard to beat, and between mobile phones, tablets, IoT and in-car infotainment, this is an important topic. But unless you need something that's super low power, the only thing ARM CPUs have to show for themselves is that they aren't x86. This is more than made up for by the headaches involved into getting stuff that runs on a company's Cortex A7 to run on another company's Cortex A7. This isn't to say that it's a bad thing. Pre-64-bit ARMs were designed (with the exception of some really old stuff in the 80s) as a platform for appliances, not for computers. They're excellent for designing phones and tablets and smart TVs and whatnot. It's trying to bolt a general-purpose environment on top of them that gives people headaches.
  - rjsw 10y ago
    The display controller on ARM SoCs is typically separate from the Mali or PowerVR GPU and is often documented. If there are multiple ARM cores on the SoC then the display may still feel fast enough for basic stuff even though the CPU is doing all the work. Another factor is that some modern GPUs are 3D only, the graphics stack gets a lot more complicated if it has to translate 2D requests from an application into OpenGL calls to the GPU. NetBSD has a framebuffer driver for TI OMAP CPUs so it could be possible to port it to OpenBSD.
    - notalaser 10y ago
      Ah -- yes, on many (most?) devices, you can get framebuffer output without the GPU. I just don't know if OpenBSD has that.

kriro 10y ago

I have admittedly not investigated it very deeply but the Beagle Bone Black seems good enough with compromises. AFAIK it will boot without a blob but contains one for the GPU (PowerVR). The device will run non-OpenGL stuff fine and I believe there is some progress on reverse engineering an open driver. There's armv7 (am335x) from OpenBSD which is my base indicator that it's at least somehow usable without any blobs. I'll yield to more informed people but searching a reasonably useful and completely open (I guess I can live without HDL for everything but it would be nice) machine has been a quest I go on every now and then. ARM seems to be the best (and most affordable) bet. I'll gladly take other suggestions as the whole ARM licensing model doesn't really sit well with me.

notalaser 10y ago
I go on that quest every once in a while, too, but without too much luck. I haven't ran OpenBSD on the BeagleBone Black, but I imagine it has no graphical output of any kind. I see the X packages but the only on-board devices that are listed as supported are: BeagleBone, BeagleBone Black Supported on-board devices: standard serial port (com) watchdog controller (omdog) ethernet controller (cpsw) GPIO controller (omgpio) so it boots but it seems a little unlikely that you can do much post-1980s work on it. I run into various ARM platforms at $work. The platform, as a whole, is probably a step backwards from e.g. PowerPC; it's very relevant today because its power consumption is very hard to beat, and between mobile phones, tablets, IoT and in-car infotainment, this is an important topic. But unless you need something that's super low power, the only thing ARM CPUs have to show for themselves is that they aren't x86. This is more than made up for by the headaches involved into getting stuff that runs on a company's Cortex A7 to run on another company's Cortex A7. This isn't to say that it's a bad thing. Pre-64-bit ARMs were designed (with the exception of some really old stuff in the 80s) as a platform for appliances, not for computers. They're excellent for designing phones and tablets and smart TVs and whatnot. It's trying to bolt a general-purpose environment on top of them that gives people headaches.
- rjsw 10y ago
  The display controller on ARM SoCs is typically separate from the Mali or PowerVR GPU and is often documented. If there are multiple ARM cores on the SoC then the display may still feel fast enough for basic stuff even though the CPU is doing all the work. Another factor is that some modern GPUs are 3D only, the graphics stack gets a lot more complicated if it has to translate 2D requests from an application into OpenGL calls to the GPU. NetBSD has a framebuffer driver for TI OMAP CPUs so it could be possible to port it to OpenBSD.
  - notalaser 10y ago
    Ah -- yes, on many (most?) devices, you can get framebuffer output without the GPU. I just don't know if OpenBSD has that.