Google Removes RISC-V Support From Android Common Kernel, Denies Abandoning Its Efforts (androidauthority.com) 31
Mishaal Rahman reports via Android Authority: Earlier today, a Senior Staff Software Engineer at Google who, according to their LinkedIn, leads the Android Systems Team and works on Android's Linux kernel fork, submitted a series of patches to AOSP that "remove ACK's support for riscv64." The description of these patches states that "support for risc64 GKI kernels is discontinued."
ACK stands for Android Common Kernel and refers to the downstream branches of the official kernel.org Linux kernels that Google maintains. The ACK is basically Linux plus some "patches of interest to the Android community that haven't been merged into mainline or Long Term Supported (LTS) kernels." There are multiple ACK branches, including android-mainline, which is the primary development branch that is forked into "GKI" kernel branches that correspond to a particular combination of supported Linux kernel and Android OS version. GKI stands for Generic Kernel Image and refers to a kernel that's built from one of these branches. Every certified Android device ships with a kernel based on one of these GKI branches, as Google currently does not certify Android devices that ship with a mainline Linux kernel build.
Since these patches remove RISC-V kernel support, RISC-V kernel build support, and RISC-V emulator support, any companies looking to compile a RISC-V build of Android right now would need to create and maintain their own fork of Linux with the requisite ACK and RISC-V patches. Given that Google currently only certifies Android builds that ship with a GKI kernel built from an ACK branch, that means we likely won't see certified builds of Android on RISC-V hardware anytime soon. Our initial interpretation of these patches was that Google was preparing to kill off RISC-V support in Android since that was the most obvious conclusion. However, a spokesperson for Google told us this: "Android will continue to support RISC-V. Due to the rapid rate of iteration, we are not ready to provide a single supported image for all vendors. This particular series of patches removes RISC-V support from the Android Generic Kernel Image (GKI)." Based on Google's statement, Rahman suggests that "there's still a ton of work that needs to be done before Android is ready for RISC-V."
"Even once it's ready, Google will need to redo the work to add RISC-V support in the kernel anyway. At the very least, Google's decision likely means that we might need to wait even longer than expected to see commercial Android devices running on a RISC-V chip."
ACK stands for Android Common Kernel and refers to the downstream branches of the official kernel.org Linux kernels that Google maintains. The ACK is basically Linux plus some "patches of interest to the Android community that haven't been merged into mainline or Long Term Supported (LTS) kernels." There are multiple ACK branches, including android-mainline, which is the primary development branch that is forked into "GKI" kernel branches that correspond to a particular combination of supported Linux kernel and Android OS version. GKI stands for Generic Kernel Image and refers to a kernel that's built from one of these branches. Every certified Android device ships with a kernel based on one of these GKI branches, as Google currently does not certify Android devices that ship with a mainline Linux kernel build.
Since these patches remove RISC-V kernel support, RISC-V kernel build support, and RISC-V emulator support, any companies looking to compile a RISC-V build of Android right now would need to create and maintain their own fork of Linux with the requisite ACK and RISC-V patches. Given that Google currently only certifies Android builds that ship with a GKI kernel built from an ACK branch, that means we likely won't see certified builds of Android on RISC-V hardware anytime soon. Our initial interpretation of these patches was that Google was preparing to kill off RISC-V support in Android since that was the most obvious conclusion. However, a spokesperson for Google told us this: "Android will continue to support RISC-V. Due to the rapid rate of iteration, we are not ready to provide a single supported image for all vendors. This particular series of patches removes RISC-V support from the Android Generic Kernel Image (GKI)." Based on Google's statement, Rahman suggests that "there's still a ton of work that needs to be done before Android is ready for RISC-V."
"Even once it's ready, Google will need to redo the work to add RISC-V support in the kernel anyway. At the very least, Google's decision likely means that we might need to wait even longer than expected to see commercial Android devices running on a RISC-V chip."
China (Score:5, Interesting)
Is this due to the recent reports of China all in on RISC-V?
Re: (Score:2)
Why would that matter?
Re: (Score:2)
So that China can't easily deploy Andoid clones on RISC-V if the US decides for a ban on Android software and ARM licences.
Re: (Score:2)
Trade edicts would actually hurt corporate America.
With Microsoft, Apple and Google out of the picture, what OS could you run on RISC-V?
Yes, GNU/LInux. And that ultimately means less money flowing through the proprietary software walled gardens of silicon valley.
Re: (Score:2)
Export bans on Nvidia's AI chips also hurt corporate America, and yet they exist.
Re: (Score:2)
So that China can't easily deploy Andoid clones on RISC-V if the US decides for a ban on Android software and ARM licences.
That doesn't make sense.
Android devices in China are not Google Play devices (can't be, really, thanks to the Great Firewall), so the device makers are not obligated to use the Android Common Kernel -- or anything else. They're free to take the open source and build whatever they like. Removing RISC-V support from ACK does exactly nothing to hinder their ability to build and deploy RISC-V devices. If they want to stick with Google's kernel for whatever reason, they can simply reapply the patches that we
Re: (Score:2)
China has been growing, leaps and bounds with RISC-V CPUs
I heard there was an edict handed down to embrace it. But I'm not seeing any 'leaps and bounds.' Can you elaborate?
Re: (Score:3)
> I know I need to step away from the tinfoil hat
You know you've been conditioned by the deep state when using your brain is considered taboo.
It's fairly obvious the US government is pressuring US companies and allies to limit China's ability to develop RISC-V technology, just as they did to ASML with chip fabrication.
It isn't even a secret:
https://economictimes.indiatim... [indiatimes.com]
The real conspiracy is how the deep state has convinced people that any type of rational thought is a conspiracy theory.
Re: (Score:2)
The real conspiracy is how the deep state has convinced people that any type of rational thought is a conspiracy theory.
I believe that goes hand-in-hand with actual conspiracies being out in the open and so ridiculous that they make everybody stop and wonder, "Is this even real life?" It's easy to write off dirty truths as conspiracy when reality is barely discernable as reality if you look too closely at it.
Re: (Score:2)
I doubt RISC-V will eclipse ARM but I fully expect Google are dumping it because of what you say, that they don't stand to profit from supporting work that Chinese forks leech off.
Re: (Score:2)
Hi AmiMoJo.
Re: (Score:2)
At least the US perception of those reports. Google still has to obey US laws and if the US' government is scared of RISC-V because "Chi-na", that means Google is hedging by putting in some distance.
Re: (Score:2)
Probably due to layoffs at Google, and/or RISC-V support being immature.
They did the same thing with JPEG-XL support in Chrome. The reference implementation, libjxl, is still very very beta and it makes sense for people steering a ship that large to wait for it to get stable and fast.
Re: (Score:3)
RISC-V support is first class across the board; I've been running Ubuntu (with GUI and mouse!) on RISC-V at home since early (february?) 2022 on $20 devices. Go check out the MangoPi class of $25 RISC-V devices. Ubuntu support has been around for years now.
Re: (Score:3)
Maybe it's just a pain in the ass for Google to maintain when the main beneficiaries are domestic Chinese AOSP forks where Google wouldn't see any return for their efforts. So they dump support and put the development burden on these forks.
Re:China (Score:4, Interesting)
Is this due to the recent reports of China all in on RISC-V?
It's because RISC-V is currently fragmented. Not the base ISA, but the base ISA isn't enough to build a device, and there are a lot of divergent extensions.
That wasn't a problem when RISC-V was only theoretical, but now that companies are working towards actual devices, having the "common" RISC-V support in the Android Common Kernel was a hindrance, not a help. The expectation is that over the course of a few years the RISC-V Android ecosystem will coalesce and settle on a common set of extensions to the ISA and it will then be possible to standardize the RISC-V support in ACK. Until then, it's better if ACK doesn't have any RISC-V support so chip vendors and OEMs can straightforwardly patch in what they need.
Re: (Score:3)
Is this due to the recent reports of China all in on RISC-V?
It's because RISC-V is currently fragmented. Not the base ISA, but the base ISA isn't enough to build a device, and there are a lot of divergent extensions.
That wasn't a problem when RISC-V was only theoretical, but now that companies are working towards actual devices, having the "common" RISC-V support in the Android Common Kernel was a hindrance, not a help. The expectation is that over the course of a few years the RISC-V Android ecosystem will coalesce and settle on a common set of extensions to the ISA and it will then be possible to standardize the RISC-V support in ACK. Until then, it's better if ACK doesn't have any RISC-V support so chip vendors and OEMs can straightforwardly patch in what they need.
I should mention that although I'm an Android engineer, I don't have any significant contact with RISC-V work. The above is my interpretation of the public comments, in light of what I do know about the state of RISC-V and the way the Android ecosystem is structured and works.
Re: (Score:2)
This is correct. RISC-V has the base ISA of integer core, everything else you want is an extension. Any implementation needs to only implement the base integer core to call themselves RISC-V compliant.
Then you have the fact that like ARM, SoC vendors are able to put whatever peripherals they want anywhere in the memory map, so you get all the fun of ARM
So this is a commercial product from Google... (Score:2)
Do any vendors use the RISC-V version of the product? If not, what's the big deal?
Re: (Score:2)
Get OVER IT use the mainline Kernel (Score:2)
This is a QA action, the whole point is that Android should work on the mainline kernel
removing their QA'd kernel sources is so that reports are clean and they can QA with real hardware and releases
if android did not work on the mainline Linux kernel this would be news...
Re: (Score:2)
'should'.
Maybe Google wants to avoid the mistakes of the Arm platform by minimizing out of tree patches. But more likely they're waiting on the Alibaba Xuantie team spearheading the porting effort to rebase and stabilize their efforts e.g. for the RVV 1.0 vector extension. once there are actually critical masses of Androi
It's not dead (Score:3)
Android support for RISC-V is not dead, it just smells that way.
RISC-V isn't ready for Android anyway (Score:3)
Android needs a superscalar OOO core to run it. RISC-V isn't there yet, and won't be for a while. This is going to remain ARM's stronghold for a long time. Instead RISC-V is disrupting from the bottom, like micro computers did to mainframes to 40 years ago. Here's a 32 CPU RISC-V CPU [aliexpress.com] that sells for around $0.10. That sighing sound you hear is microcontroller designers saying "bugger, the ARM licence costs us more than that". Well, not really, but it doesn't leave a lot of room for ARM's royalties.
Re: (Score:3)
There are already such cores available.
For example you have the T-Head TH1520 SoC which is a quad-core RISC-V Xuantie C910 processor. The C910 core is 12-stage dual-issue out-of-order.
Even higher performance cores should become commercially available over the next two years.
Re: (Score:2)
Thanks. Excellent info.
For those following along, data on the Xuantie C910 [riscfive.com]:
Frequency: 2 – 2.5 GHz
Area: 1.137 (MP2)/0.398 (core)
Power: 200 uW/MHz
For context [wikipedia.org] ARM Cortex-A57: 4.1–4.8 DMIPS/MHz, Cortex-A77: 13-16 DMIPS/MHz.