5 ms·

> like Linux distros, which can still run on 15 year old hardware just fine First, let's remind that LineageOS does not run on 15 year old smartphones (and the

> like Linux distros, which can still run on 15 year old hardware just fine First, let's remind that LineageOS does not run on 15 year old smartphones (and they drop support for a device when there is no upstream support from vendors on the same Android version). One issue is that unlike x86/x86_64, there is no generalized abstraction platform (similar to BIOS/UEFI/ACPI description tables) that enables "one kernel to rule them all" i.e. you need some custom adjustments on your kernel for your SoC and board. Since a few years we have device-tree which improves a lot the situation, but I understand it does not cover everything (i.e. there would still be some missing aspects compared to UEFI/ACPI with regards to hardware description. Maybe some embedded experts can comment ?). Besides it is still not always implemented in chipset vendor's BSP which sometimes still rely on board files (where the data is not easy to extract from a binary kernel, noting that a lot of low-end OEMs do not properly comply with GPL and do not publish their sources)...

zozbot234 5y ago
> and they drop support for a device when there is no upstream support from vendors on the same Android version Nope, they drop support when the community runs into issues with a particular model that it's impractical to fix. Upstream vendor support helps but is not required in any way. Device tree "doesn't cover everything" because some device components are yet to be supported in the mainline kernel. Once mainline support is added, that enables a 'universal' kernel to provide that support via the device tree.
- eric__cartman 5y ago
  This is true. I have used Lineage OS with android 7.1 on a first gen Motorola G phone (that was declared EOL after the Android 5.1 update) and now on a OnePlus 5 with Android 11 (manufacturer dropped support after 10)
  - BenjiWiebe 5y ago
    And I can get Android 11 (LineageOs 18.1) for my Galaxy S5. I believe Samsung stopped updating it at 6.
my123 5y ago
> One issue is that unlike x86/x86_64, there is no generalized abstraction platform (similar to BIOS/UEFI/ACPI description tables) that enables "one kernel to rule them all" Windows on Arm devices use UEFI + ACPI, including Windows Phone starting from Windows Phone 8 (2012!). That allowed even the latest releases of Windows 10 Mobile to work on totally unsupported devices (1st gen WP8 devices) when that existed. It's not an Arm problem, it's that the Android world didn't bother really tackling the problem for a long time.
- ryandrake 5y ago
  I think user karteum brings up good points, but they are more like industry excuses than reasons. It's clearly possible to clean up this mess, but the OEMs and OS vendors simply won't bother since there is no regulatory reason to do it. This move from Germany is a great first step, but it's a step down a long road that the industry will fight at every exit.
- surajrmal 5y ago
  This is a bit disingenuous. The problem is that every soc manufacturer wants custom data to pass to their driver. With ACPI, you need to standardize this data and get it published in the yearly spec update. With device tree you just check in your new device tree bindings alongside your driver in the kernel repo. Device Tree blobs are only stable with respect to the kernel version they were built for. It also doesn't have to worry about being OS independent. SoC manufacturers are happy with this arrangement because it lets them iterate quickly. It is a much lower bar with much lower costs compared to ACPI. In recent years, ACPI has started adding support for encoding data which is non standard by allowing key value data, but using that sort of defeats the point. Those fields aren't usually documented and only the driver written for it understands how to interpret that data. Again, that forces ACPI blobs to be versioned alongside drivers. There is completely unlike how x86 works where everything really is standardized and you don't need specific drivers operate every peripheral on the board. Of course even on x86 you can have more specific drivers which are more optimized or expose additional functionality, but generic drivers can an do exist which get you decent support. Beyond device tree/ACPI this means adhering to standardized register layouts and things like that which is completely off the table with arm soc manufacturers.

zozbot234 5y ago

> and they drop support for a device when there is no upstream support from vendors on the same Android version Nope, they drop support when the community runs into issues with a particular model that it's impractical to fix. Upstream vendor support helps but is not required in any way. Device tree "doesn't cover everything" because some device components are yet to be supported in the mainline kernel. Once mainline support is added, that enables a 'universal' kernel to provide that support via the device tree.

eric__cartman 5y ago
This is true. I have used Lineage OS with android 7.1 on a first gen Motorola G phone (that was declared EOL after the Android 5.1 update) and now on a OnePlus 5 with Android 11 (manufacturer dropped support after 10)
- BenjiWiebe 5y ago
  And I can get Android 11 (LineageOs 18.1) for my Galaxy S5. I believe Samsung stopped updating it at 6.

my123 5y ago

> One issue is that unlike x86/x86_64, there is no generalized abstraction platform (similar to BIOS/UEFI/ACPI description tables) that enables "one kernel to rule them all" Windows on Arm devices use UEFI + ACPI, including Windows Phone starting from Windows Phone 8 (2012!). That allowed even the latest releases of Windows 10 Mobile to work on totally unsupported devices (1st gen WP8 devices) when that existed. It's not an Arm problem, it's that the Android world didn't bother really tackling the problem for a long time.

ryandrake 5y ago
I think user karteum brings up good points, but they are more like industry excuses than reasons. It's clearly possible to clean up this mess, but the OEMs and OS vendors simply won't bother since there is no regulatory reason to do it. This move from Germany is a great first step, but it's a step down a long road that the industry will fight at every exit.
surajrmal 5y ago
This is a bit disingenuous. The problem is that every soc manufacturer wants custom data to pass to their driver. With ACPI, you need to standardize this data and get it published in the yearly spec update. With device tree you just check in your new device tree bindings alongside your driver in the kernel repo. Device Tree blobs are only stable with respect to the kernel version they were built for. It also doesn't have to worry about being OS independent. SoC manufacturers are happy with this arrangement because it lets them iterate quickly. It is a much lower bar with much lower costs compared to ACPI. In recent years, ACPI has started adding support for encoding data which is non standard by allowing key value data, but using that sort of defeats the point. Those fields aren't usually documented and only the driver written for it understands how to interpret that data. Again, that forces ACPI blobs to be versioned alongside drivers. There is completely unlike how x86 works where everything really is standardized and you don't need specific drivers operate every peripheral on the board. Of course even on x86 you can have more specific drivers which are more optimized or expose additional functionality, but generic drivers can an do exist which get you decent support. Beyond device tree/ACPI this means adhering to standardized register layouts and things like that which is completely off the table with arm soc manufacturers.