4 ms·

> Why do phones require device-specific builds and ROM flashing just to install a different OS? Why isn't there a phone out there with a normal boot loader that

> Why do phones require device-specific builds and ROM flashing just to install a different OS? Why isn't there a phone out there with a normal boot loader that allows me to install whatever OS I want like I can on a PC? A few reasons: 1. Proprietary drivers are the norm for mobile devices, whereas (with a few exceptions) this is not the case for desktops/laptops. 2. Even when the drivers are free, standard practice among device manufacturers seems to be forking the kernel for each device and working off that fork. These things don’t and can’t run on mainline Linux/Android. See the Librem 5 and PinePhone for what are probably the only two devices attempting to fix the above problems. And even if you fixed those: 3. ARM devices typically don’t have the same device enumeration capabilities as x86 PCs, meaning you need a separate device tree for each one. I believe there are also efforts underway to improve this situation, but that’s where we are at the moment.

monocasa 7y ago
Proprietary drivers are very much the norm on windows and mac.
- ryukafalz 7y ago
  That’s true, I was mostly looking at this from a Linux-centric point of view. You won’t be running Windows or macOS on your phone.
  - monocasa 7y ago
    What I'm getting at is that propreitary drivers has no bearing on the matter when 90+% of PCs are running propreitary drivers.
    - ryukafalz 7y ago
      It does on Linux, where there's no stable ABI for drivers to use, right? Yes, that's a design decision on Linux's part, but it's one that seems to be working out just fine for PCs.
      - monocasa 7y ago
        But that's less than 10% of the market. The rest doesn't have those problems either, despite having almost entirely proprietary drivers. Therefore it's not the propreitary drivers that are the issue.
        ryukafalz 7y ago
        Given the set of design decisions Linux has made, and assuming the Linux driver development model isn't going to change to accommodate manufacturers that want to keep their source to themselves, the proprietary drivers are part of the issue here. (The other part is manufacturers not working with the Linux community on upstreaming their drivers, even when there are free drivers.) Yes, a stable interface is another potential solution. It's unlikely to happen[0], but it would solve the issue. (Quite honestly, though, I'm glad we don't have to deal with manufacturers pulling stuff like this in the Linux world: https://twitter.com/Foone/status/1172237142485078016 https://twitter.com/Foone/status/1172237142485078016) [0] https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://www.kernel.org/doc/Documentation/process/stable-api-...
        monocasa 7y ago
        No, I'm not saying its a solution or a problem. It's completely orthogonal.
        ldng 7y ago
        The problem is those drivers are not maintained. And it just happen that those are proprietary. Is that what you're trying to say ?
        tracker1 7y ago
        The market is smart phones, where the market share for a linux kernel (android) is much higher.
kop316 7y ago
The separate device tree (#3) is not as big an issue as the first ones. If you are making a Linux kernel for an ARM device, you will have to make a device tree, and it should not change once written.
- ryukafalz 7y ago
  That’s true, it’s less of an issue than the others, but it’s still a per-device difference that the kernel needs to know about before you bring the system online. If you’re trying to make an installer that’ll run on any ARM device like those on x86, that’s a problem - how does the installation image know what device tree to use?
  - kop316 7y ago
    If I remember when I did it for the Novena, you had to include that specific dtb file for the install. That does make it a pain, as you are correct, the installation image is board/chip specific
  - monocasa 7y ago
    The device tree is part of the solution, not part of the problem. The reason PCs are able to handle this is that the really gnarly stuff (pincfg, gpios, I2C, SPI, random power management), is handled by per board tables in ACPI, and device tree handles the same niche. The problem is that the device trees are half assed since they run against a hacked up kernel, not that they exist in the first place.
    - ryukafalz 7y ago
      Ah, interesting. I think I have some reading to do; there clearly are multiplatform images out there now (Debian for example https://wiki.debian.org/DebianKernel/ARMMP https://wiki.debian.org/DebianKernel/ARMMP) so my understanding of the situation was somewhat mistaken.

monocasa 7y ago

Proprietary drivers are very much the norm on windows and mac.

ryukafalz 7y ago
That’s true, I was mostly looking at this from a Linux-centric point of view. You won’t be running Windows or macOS on your phone.
- monocasa 7y ago
  What I'm getting at is that propreitary drivers has no bearing on the matter when 90+% of PCs are running propreitary drivers.
  - ryukafalz 7y ago
    It does on Linux, where there's no stable ABI for drivers to use, right? Yes, that's a design decision on Linux's part, but it's one that seems to be working out just fine for PCs.
    - monocasa 7y ago
      But that's less than 10% of the market. The rest doesn't have those problems either, despite having almost entirely proprietary drivers. Therefore it's not the propreitary drivers that are the issue.
      - ryukafalz 7y ago
        Given the set of design decisions Linux has made, and assuming the Linux driver development model isn't going to change to accommodate manufacturers that want to keep their source to themselves, the proprietary drivers are part of the issue here. (The other part is manufacturers not working with the Linux community on upstreaming their drivers, even when there are free drivers.) Yes, a stable interface is another potential solution. It's unlikely to happen[0], but it would solve the issue. (Quite honestly, though, I'm glad we don't have to deal with manufacturers pulling stuff like this in the Linux world: https://twitter.com/Foone/status/1172237142485078016 https://twitter.com/Foone/status/1172237142485078016) [0] https://www.kernel.org/doc/Documentation/process/stable-api-nonsense.rst https://www.kernel.org/doc/Documentation/process/stable-api-...
        monocasa 7y ago
        No, I'm not saying its a solution or a problem. It's completely orthogonal.
        ldng 7y ago
        The problem is those drivers are not maintained. And it just happen that those are proprietary. Is that what you're trying to say ?
      - tracker1 7y ago
        The market is smart phones, where the market share for a linux kernel (android) is much higher.

kop316 7y ago

The separate device tree (#3) is not as big an issue as the first ones. If you are making a Linux kernel for an ARM device, you will have to make a device tree, and it should not change once written.

ryukafalz 7y ago
That’s true, it’s less of an issue than the others, but it’s still a per-device difference that the kernel needs to know about before you bring the system online. If you’re trying to make an installer that’ll run on any ARM device like those on x86, that’s a problem - how does the installation image know what device tree to use?
- kop316 7y ago
  If I remember when I did it for the Novena, you had to include that specific dtb file for the install. That does make it a pain, as you are correct, the installation image is board/chip specific
- monocasa 7y ago
  The device tree is part of the solution, not part of the problem. The reason PCs are able to handle this is that the really gnarly stuff (pincfg, gpios, I2C, SPI, random power management), is handled by per board tables in ACPI, and device tree handles the same niche. The problem is that the device trees are half assed since they run against a hacked up kernel, not that they exist in the first place.
  - ryukafalz 7y ago
    Ah, interesting. I think I have some reading to do; there clearly are multiplatform images out there now (Debian for example https://wiki.debian.org/DebianKernel/ARMMP https://wiki.debian.org/DebianKernel/ARMMP) so my understanding of the situation was somewhat mistaken.