Hacker News Reader

Comment by kees99 | Hacker News Reader

My understanding is that each android phone model is unique and requires unique OS update (unlike, say, BIOS- or UEFI-based x86 PCs, where exact same Windows/Linux/BSD/... image can be installed on any of them).

Having a "standard" OS interface for the phone, where there is just one OS image for a given OS version, and that image could be installed on any phone - now that would be the true alternative, which I would be delighted to vote for with my wallet.

View on HN

> Having a "standard" OS interface for the phone, where there is just one OS image for a given OS version, and that image could be installed on any phone

Project Treble is working towards this, in a way. But it's a huge hack that's still dependent on lots of weird AOSP-specific stuff, and doesn't even give you a "single" OS image for every device - the "proper" image for your device varies by baseline AOSP support (7, 8, 9, 10), "A" vs. "A+B" boot and of course 32-bit vs. 64-bit architecture. Nowhere near "UEFI-based PC" territory.

Eh... remember 32-bit UEFI? It might be smaller, but there is still room for weirdness.

> My understanding is that each android phone model is unique

Sure, but each PC is also 'unique' in that sense, in fact I'd happily bet that there are more different kinds of hardware combinations for PCs than there are android phone models. And yet, that never was a problem.

Plug-and-Play and then ACPI have been used to get around this. Hardware discovery just doesn't seem to be a thing on these embedded SoC platforms, and even the hardware support itself (drivers, etc.) is extremely sub-par if you expect to run the ordinary, mainline kernel.

Even before harware discovery and plug-and-play you could do this by simply specifying what hardware you had or by 'probing' the hardware for presence of certain characteristics (this wasn't always fool proof). The hardest parts were when interrupts were still selected with jumpers rather than automatically enumerated.

8086 has 256 IO addresses, and hardware of that era had fairly simple initialization, so completely naive way to find peripheral X was to 'probe' each and every possible IO address with something like:

  for i in range(256):
    poke(i,magic1)
    if peek(i) == magic2:
      found!

256 probes in all is not that bad, and real-world probing would only try a handful of commonly used addresses, making it even faster.

Phone SoCs on the other hand have many peripherals memory-mapped, (meaning there are millions/billions addresses to 'probe'), plus there are things like power sequencing, GPIO enable lines that need to be asserted, and clock-sources configured before peripheral would even respond at all. Oh, and that GPIO, or power controller, or clock source themselves might be accessible via an i2c chip speaking its own protocol, so you need to initialize those first, etc, etc.

All of this complexity could be described via linux "devicetree" subsystem, and devicetrees are in a usable state for some hardware (although DT itself is often a labyrinth to navigate). Thing is - factory software for most phones have been extremely slow to adopt DT, and even some that do use DT, don't do it in a particularly portable way.

However, every PC descends from the original IBM 5150 from the 1980s, which gives the PC a common base which phones never had.

Reply on news.ycombinator.com