3 ms·

Not defending Google’s actions but it worth noting that not updating devices usually has to do with the SoC supplier ceasing support for the chip by not shippin

by Zhenya 4y ago

Not defending Google’s actions but it worth noting that not updating devices usually has to do with the SoC supplier ceasing support for the chip by not shipping BSPs which support new OS features. Yes google should have negotiated better support but it’s lack of support has to do more with inability to do so within reasonable means. They have projects ongoing to decouple OS functionality from the base firmware (project treble and project keystone). https://www.googblogs.com/tag/keystone/ https://www.googblogs.com/tag/keystone/ This whole issue is probably one reason that Google went through all the trouble to first develop their own support silicon and then the main SoC (pixel 6).

my123 4y ago
For Chrome OS not the problem a lot of the time, they drop support for devices using commodity SoCs that are still supported elsewhere... it's a quite hardcoded expiry date. And they don't even drop support for all machines using a given SoC at the same time. For Chrome OS updates are wholly owned by Google too.
- Zhenya 4y ago
  I am more knowledgeable about the arm / android world. I do wonder if for the chrome os world there are SoC+BSP vs ChromeOS feature requirements that cause this lack of ability to support (e.g. trust zone etc)
  - my123 4y ago
    > (e.g. trust zone etc) For chromeOS devices, the boot firmware (incl TZ) is owned by Google.
yegle 4y ago
This is well known for Android devices. If you look for "longest supported Android devices", you might find: - Nvidia Shield TV 2015: initially released with Android 6 and is currently on Android 11. It uses a CPU from Nvidia itself and is expected to continue receiving updates. - Nexus Player: initially released with Android 5, last updated to Android 8. It uses an Intel CPU and does not require special binary blobs to support newer Linux kernels required by newer Android versions.
int_19h 4y ago
> develop their own support silicon and then the main SoC Their Pixels don't exactly enjoy long support lifecycles, either.
- Zhenya 4y ago
  Pixels use Qualcomm SoCs up through pixel 5
  - pjmlp 4y ago
    There is this thing called support contracts, maybe Google could try that out on their suppliers.
deleted 4y ago
[deleted]
car_analogy 4y ago
> not updating devices usually has to do with the SoC supplier ceasing support for the chip by not shipping BSPs which support new OS features I don't know what a BSP is, but why can I update linux (or indeed almost any OS) on my PC without any support from the motherboard vendor? What OS features need SoC support, and why can the OS not live without them, when it was previously able to do so? This was the case before smartphones. It is not an advanced feature of linux, developed later, that Android failed to backport. I suspect they broke it deliberately. To my lay understanding, phone hardware offers approximately the same features today as it did a decade ago - make calls, connect to the internet, interface with the camera and GPS. Occasionally a protocol might change (LTE, 4G, 5G..), but maintaining support for a slightly older, still-in-use protocol or hardware device, that serves the same basic purpose as its new replacement, is the bare minimum - it is not a radical divergence of architecture or functionality that would make maintaining old versions prohibitively difficult.
- yjftsjthsd-h 4y ago
  > I don't know what a BSP is, but why can I update linux (or indeed almost any OS) on my PC without any support from the motherboard vendor? What OS features need SoC support, and why can the OS not live without them, when it was previously able to do so? Basically, PCs have 2 things going for them: First, they use standardized, enumerable interfaces. You can boot an arbitrary Linux-based system and the kernel can ask the PCI bus "what hardware is installed?" using the same query on every machine, and get back an answer in the same format. "Embedded" devices don't have that, generally (ARM ServerReady does add this, and does create ARM-based hardware where you just stick in a random distro's USB stick and boot and it works). Second, Linux on PCs tends to use upstream drivers. When you run ex. Ubuntu on a laptop, it talks to your ex. graphics card using a driver that's in Torvald's official tree. For... reasons... that I don't claim to understand but that probably involve cost-cutting, Android phones rely on drivers that are written by hardware vendors and then abandoned without any effort to get included upstream. So the result is that in many cases you can boot vanilla Linux on an arbitrary phone or whatever, but it'll come up with access to the CPU, RAM, and USB (because that is still an enumerable bus using a standard interface), but it will have no idea how to query the rest of the hardware and if it did it wouldn't have any drivers to talk to that hardware with. Edit: I should mention, a BSP is the ... "solution" that vendors use to pretend this whole thing is workable. It stands for board support package, which is a giant blob of source code that includes at minimum a copy of Linux with all their delightfully buggy custom drivers included and all the necessary hardware devices hard-coded so the system can find the hardware when it boots. And by find, of course, I mean "blindly assume it's there". On a good day this data is encoded in a device tree, which is a file format for "here's what hardware is in this system and how to talk to it (ports, memory addresses, whatever) ".
pjmlp 4y ago
Project Treble and Keystone are worthless, because they keep the reasoning that they aren't required for Android certification. The traditional excuse is that Android is a rich ecosystem and they don't want to prevent partners from "innovation". The mess continues as Google isn't willing to take a stand on it.

by Zhenya 4y ago

my123 4y ago

For Chrome OS not the problem a lot of the time, they drop support for devices using commodity SoCs that are still supported elsewhere... it's a quite hardcoded expiry date. And they don't even drop support for all machines using a given SoC at the same time. For Chrome OS updates are wholly owned by Google too.

Zhenya 4y ago
I am more knowledgeable about the arm / android world. I do wonder if for the chrome os world there are SoC+BSP vs ChromeOS feature requirements that cause this lack of ability to support (e.g. trust zone etc)
- my123 4y ago
  > (e.g. trust zone etc) For chromeOS devices, the boot firmware (incl TZ) is owned by Google.

yegle 4y ago

This is well known for Android devices. If you look for "longest supported Android devices", you might find: - Nvidia Shield TV 2015: initially released with Android 6 and is currently on Android 11. It uses a CPU from Nvidia itself and is expected to continue receiving updates. - Nexus Player: initially released with Android 5, last updated to Android 8. It uses an Intel CPU and does not require special binary blobs to support newer Linux kernels required by newer Android versions.

int_19h 4y ago

> develop their own support silicon and then the main SoC Their Pixels don't exactly enjoy long support lifecycles, either.

Zhenya 4y ago
Pixels use Qualcomm SoCs up through pixel 5
- pjmlp 4y ago
  There is this thing called support contracts, maybe Google could try that out on their suppliers.

deleted 4y ago

[deleted]

car_analogy 4y ago

> not updating devices usually has to do with the SoC supplier ceasing support for the chip by not shipping BSPs which support new OS features I don't know what a BSP is, but why can I update linux (or indeed almost any OS) on my PC without any support from the motherboard vendor? What OS features need SoC support, and why can the OS not live without them, when it was previously able to do so? This was the case before smartphones. It is not an advanced feature of linux, developed later, that Android failed to backport. I suspect they broke it deliberately. To my lay understanding, phone hardware offers approximately the same features today as it did a decade ago - make calls, connect to the internet, interface with the camera and GPS. Occasionally a protocol might change (LTE, 4G, 5G..), but maintaining support for a slightly older, still-in-use protocol or hardware device, that serves the same basic purpose as its new replacement, is the bare minimum - it is not a radical divergence of architecture or functionality that would make maintaining old versions prohibitively difficult.

yjftsjthsd-h 4y ago
> I don't know what a BSP is, but why can I update linux (or indeed almost any OS) on my PC without any support from the motherboard vendor? What OS features need SoC support, and why can the OS not live without them, when it was previously able to do so? Basically, PCs have 2 things going for them: First, they use standardized, enumerable interfaces. You can boot an arbitrary Linux-based system and the kernel can ask the PCI bus "what hardware is installed?" using the same query on every machine, and get back an answer in the same format. "Embedded" devices don't have that, generally (ARM ServerReady does add this, and does create ARM-based hardware where you just stick in a random distro's USB stick and boot and it works). Second, Linux on PCs tends to use upstream drivers. When you run ex. Ubuntu on a laptop, it talks to your ex. graphics card using a driver that's in Torvald's official tree. For... reasons... that I don't claim to understand but that probably involve cost-cutting, Android phones rely on drivers that are written by hardware vendors and then abandoned without any effort to get included upstream. So the result is that in many cases you can boot vanilla Linux on an arbitrary phone or whatever, but it'll come up with access to the CPU, RAM, and USB (because that is still an enumerable bus using a standard interface), but it will have no idea how to query the rest of the hardware and if it did it wouldn't have any drivers to talk to that hardware with. Edit: I should mention, a BSP is the ... "solution" that vendors use to pretend this whole thing is workable. It stands for board support package, which is a giant blob of source code that includes at minimum a copy of Linux with all their delightfully buggy custom drivers included and all the necessary hardware devices hard-coded so the system can find the hardware when it boots. And by find, of course, I mean "blindly assume it's there". On a good day this data is encoded in a device tree, which is a file format for "here's what hardware is in this system and how to talk to it (ports, memory addresses, whatever) ".

pjmlp 4y ago

Project Treble and Keystone are worthless, because they keep the reasoning that they aren't required for Android certification. The traditional excuse is that Android is a rich ecosystem and they don't want to prevent partners from "innovation". The mess continues as Google isn't willing to take a stand on it.