4 ms·

Will this run off the mainline kernel? Or will require strange patches from somewhere? Half the problem with orange pi is lack of main Linux distribution suppo

by UK-AL 2y ago

Will this run off the mainline kernel? Or will require strange patches from somewhere? Half the problem with orange pi is lack of main Linux distribution support.

rcarmo 2y ago
All my (ARM) Orange Pi boards run Armbian just fine. This one, of course, is unlikely to, but I'm curious to see what it ships with.
- ThatPlayer 2y ago
  I know Armbian for the Orange Pi 4 had broken video out for at least a year: https://forum.armbian.com/topic/26818-opi-4-lts-no-hdmi-output/ https://forum.armbian.com/topic/26818-opi-4-lts-no-hdmi-outp... Haven't tried it on mine recently so no clue if it's better now.
  - rcarmo 2y ago
    Depends on whether things are officially supported or just community contributes, in my experience. I tend to stick to officially supported devices.
- pabs3 2y ago
  Armbian adds all sorts of non-mainline Linux kernels and other stuff in order to achieve the hardware support it does have. Other more standard distros like Debian or Fedora don't do this.
  - rcarmo 2y ago
    Well, do you want things to work or are you willing to wait years until things are mainlined?
    - dietr1ch 2y ago
      That's the thing, it forces me into a specific distro/kernel where the stuff that I actually want to run isn't available. I have a pair of Orange Pi 5Bs and they didn't really replaced my old Raspberries after spending more time on it than what I was initially willing to spend on my upgrade.
    - pabs3 2y ago
      My definition of "work" is a Linux kernel that can be upgraded as CVEs are discovered and new features added. Modified versions of Linux usually aren't that, much of the time they are stuck on the same kernel version, which eventually leaves security support periods.
    - wolrah 2y ago
      > Well, do you want things to work or are you willing to wait years until things are mainlined? What I want is for the SoC vendors to actually learn how to participate in the kernel process. Design their drivers from the ground up to be maintainable and mainlineable. The problem with "wanting things to work now" that we've seen over and over and over in the ARM SoC world is that each family of chips ends up with its own fork of the kernel which never gets mainlined because of one or more of the following: * It can't actually be compiled as provided * Successful compilation depends heavily on the build environment which is undocumented * It depends on binary drivers * It is written in ways that do not meet the standards of the kernel * It modifies kernel interfaces in ways that break other drivers * It's just bad code in general. When this happens the vendor might update it a couple of times over the product's profitable life but inevitably they will stop doing so. If there's enough of a community around the platform and they're lucky enough to have complete source it's sometimes possible for the community to take over development of the fork and try to port the vendor code to newer kernels while slowly cleaning it up. Most of the time though there's a binary driver somewhere critical to many if not all users which will only work with a certain range of kernel versions, at which point the community is left supporting an obsolete kernel and mostly just backporting relevant fixes rather than gaining anything new. Sometimes there's a way to shim an old driver to work with a new kernel, and sometimes a driver for a newer piece of hardware from the same vendor can be made to work on the older versions, but in neither case can it be counted on. The worst part IMO is that it's usually not even a LTS kernel that these vendors decide to settle on, it's all too often one that was obsolete and unsupported before the SoC was ever in the public's hands. If you're going to launch a Linux-based product with no intent of mainlining the kernel code at least make it run either the latest LTS or SLTS kernel. It doesn't take years to get code mainlined, lots of vendors are doing it every day for hardware that hasn't even been released yet. A lot of SoC vendors either just don't care or actively don't want to.
dhalucario 2y ago
I have a similar issue with the MangoPi MQ Pro. Its great to have a RISC-V processor now but not having HDMI available on my SBC kinda massively sucks.

by UK-AL 2y ago

Will this run off the mainline kernel? Or will require strange patches from somewhere? Half the problem with orange pi is lack of main Linux distribution support.

rcarmo 2y ago

All my (ARM) Orange Pi boards run Armbian just fine. This one, of course, is unlikely to, but I'm curious to see what it ships with.

ThatPlayer 2y ago
I know Armbian for the Orange Pi 4 had broken video out for at least a year: https://forum.armbian.com/topic/26818-opi-4-lts-no-hdmi-output/ https://forum.armbian.com/topic/26818-opi-4-lts-no-hdmi-outp... Haven't tried it on mine recently so no clue if it's better now.
- rcarmo 2y ago
  Depends on whether things are officially supported or just community contributes, in my experience. I tend to stick to officially supported devices.
pabs3 2y ago
Armbian adds all sorts of non-mainline Linux kernels and other stuff in order to achieve the hardware support it does have. Other more standard distros like Debian or Fedora don't do this.
- rcarmo 2y ago
  Well, do you want things to work or are you willing to wait years until things are mainlined?
  - dietr1ch 2y ago
    That's the thing, it forces me into a specific distro/kernel where the stuff that I actually want to run isn't available. I have a pair of Orange Pi 5Bs and they didn't really replaced my old Raspberries after spending more time on it than what I was initially willing to spend on my upgrade.
  - pabs3 2y ago
    My definition of "work" is a Linux kernel that can be upgraded as CVEs are discovered and new features added. Modified versions of Linux usually aren't that, much of the time they are stuck on the same kernel version, which eventually leaves security support periods.
  - wolrah 2y ago
    > Well, do you want things to work or are you willing to wait years until things are mainlined? What I want is for the SoC vendors to actually learn how to participate in the kernel process. Design their drivers from the ground up to be maintainable and mainlineable. The problem with "wanting things to work now" that we've seen over and over and over in the ARM SoC world is that each family of chips ends up with its own fork of the kernel which never gets mainlined because of one or more of the following: * It can't actually be compiled as provided * Successful compilation depends heavily on the build environment which is undocumented * It depends on binary drivers * It is written in ways that do not meet the standards of the kernel * It modifies kernel interfaces in ways that break other drivers * It's just bad code in general. When this happens the vendor might update it a couple of times over the product's profitable life but inevitably they will stop doing so. If there's enough of a community around the platform and they're lucky enough to have complete source it's sometimes possible for the community to take over development of the fork and try to port the vendor code to newer kernels while slowly cleaning it up. Most of the time though there's a binary driver somewhere critical to many if not all users which will only work with a certain range of kernel versions, at which point the community is left supporting an obsolete kernel and mostly just backporting relevant fixes rather than gaining anything new. Sometimes there's a way to shim an old driver to work with a new kernel, and sometimes a driver for a newer piece of hardware from the same vendor can be made to work on the older versions, but in neither case can it be counted on. The worst part IMO is that it's usually not even a LTS kernel that these vendors decide to settle on, it's all too often one that was obsolete and unsupported before the SoC was ever in the public's hands. If you're going to launch a Linux-based product with no intent of mainlining the kernel code at least make it run either the latest LTS or SLTS kernel. It doesn't take years to get code mainlined, lots of vendors are doing it every day for hardware that hasn't even been released yet. A lot of SoC vendors either just don't care or actively don't want to.

dhalucario 2y ago

I have a similar issue with the MangoPi MQ Pro. Its great to have a RISC-V processor now but not having HDMI available on my SBC kinda massively sucks.