10 ms·

(disclaimer: I work at Qualcomm) > Mobile devices have no UEFI Since the Snapdragon 835, Android devices with Qualcomm processors use UEFI all the way to the

by my123 5y ago

(disclaimer: I work at Qualcomm) > Mobile devices have no UEFI Since the Snapdragon 835, Android devices with Qualcomm processors use UEFI all the way to the kernel. However, custom UEFI binaries aren't part of the boot flow, with an Android UEFI boot application running instead. > no bus enumeration It's device tree instead of ACPI, but apart from that the situation isn't _that_ different from PCs today. We aren't in the ATAGS era anymore. The reflashing interface nowadays is standardised through fastboot too. > so the OS image has to be taylored for each device Thankfully a lot of progress has been done on that. Since Treble, the BSP proper has been untied from Android releases. Since devices shipping with Android 12, a Google-built kernel with a stable kernel module ABI has been shipping (for a given major kernel + Android version release combo). This allows kernel security updates to be identical across the whole ecosystem. > althrough both are arm, you cannot use Ubuntu (or other disto) image intended for one on another That used to be true, but across the whole Android device fleet (even between SoC vendors) it's not true anymore. However, there's a catch still: there isn't a central update service. So while you might use a custom OS that way, you'll still need to update the vendor partitions (with the drivers, both kernel and user-mode ones) out of band in that scenario to get updates for those. More info on generic system images: https://developer.android.com/topic/generic-system-image https://developer.android.com/topic/generic-system-image. This mechanism allows to have universal Android images that work across all of the ecosystem, and can be used for GNU/Linux distributions on phones too if there's motivation to do so.

danielEM 5y ago
Hey @my123 > However, there's a catch still: there isn't a central update service. So while you might use a custom OS that way, you'll still need to update the vendor partitions (with the drivers, both kernel and user-mode ones) out of band in that scenario to get updates for those. > This mechanism allows to have universal Android images that work across all of the ecosystem, and can be used for GNU/Linux distributions on phones too if there's motivation to do so. So assuming my bootloader is unlocked, have a GSI compliant phone, what is the remaining work I would need to have done in order to get it working under linux (and by working I mean all devices - including cameras and etc)?
- my123 5y ago
  > what is the remaining work I would need to have done in order to get it working under A good chunk of the Linux community on phones didn't want to have to rely on binary drivers for non-technical reasons, and that's one of the reasons why it isn't exactly well taken care of today. For Ubuntu Touch specifically: https://docs.ubports.com/en/latest/porting/introduction/Intro.html https://docs.ubports.com/en/latest/porting/introduction/Intr... for Ubuntu Touch. https://github.com/ubports/porting-notes/wiki/Generic-System-image-(GSI) https://github.com/ubports/porting-notes/wiki/Generic-System... An upgraded Halium (https://github.com/Halium https://github.com/Halium) image on a can work unmodified across the whole ecosystem of Android devices. However, the latest currently developed experimental Halium works on an Android 11 base at most, so that devices launched with Android 12 might be using drivers too new for it at this point in time. (https://gitlab.com/ubports/community-ports/jenkins-ci/generic_arm64/-/pipelines https://gitlab.com/ubports/community-ports/jenkins-ci/generi...) This can be fixed with an engineering effort to do so to make it work on devices launched with Android 12. The Linux on phones community is very small and that causes problems in this case. Together with the unified kernel image (GKIs) on Android 12 which allows to have kernel image binaries built with GNU/Linux-specific features that work across the whole fleet, a full straightforward experience can be made possible. This would fill the last chunk of custom per-device bits. I wonder how big the audience would be for such a project though. :)

by my123 5y ago

danielEM 5y ago

Hey @my123 > However, there's a catch still: there isn't a central update service. So while you might use a custom OS that way, you'll still need to update the vendor partitions (with the drivers, both kernel and user-mode ones) out of band in that scenario to get updates for those. > This mechanism allows to have universal Android images that work across all of the ecosystem, and can be used for GNU/Linux distributions on phones too if there's motivation to do so. So assuming my bootloader is unlocked, have a GSI compliant phone, what is the remaining work I would need to have done in order to get it working under linux (and by working I mean all devices - including cameras and etc)?

my123 5y ago
> what is the remaining work I would need to have done in order to get it working under A good chunk of the Linux community on phones didn't want to have to rely on binary drivers for non-technical reasons, and that's one of the reasons why it isn't exactly well taken care of today. For Ubuntu Touch specifically: https://docs.ubports.com/en/latest/porting/introduction/Intro.html https://docs.ubports.com/en/latest/porting/introduction/Intr... for Ubuntu Touch. https://github.com/ubports/porting-notes/wiki/Generic-System-image-(GSI) https://github.com/ubports/porting-notes/wiki/Generic-System... An upgraded Halium (https://github.com/Halium https://github.com/Halium) image on a can work unmodified across the whole ecosystem of Android devices. However, the latest currently developed experimental Halium works on an Android 11 base at most, so that devices launched with Android 12 might be using drivers too new for it at this point in time. (https://gitlab.com/ubports/community-ports/jenkins-ci/generic_arm64/-/pipelines https://gitlab.com/ubports/community-ports/jenkins-ci/generi...) This can be fixed with an engineering effort to do so to make it work on devices launched with Android 12. The Linux on phones community is very small and that causes problems in this case. Together with the unified kernel image (GKIs) on Android 12 which allows to have kernel image binaries built with GNU/Linux-specific features that work across the whole fleet, a full straightforward experience can be made possible. This would fill the last chunk of custom per-device bits. I wonder how big the audience would be for such a project though. :)