Google pulls RISC-V support from generic Android kernel
- Reference: 1714584965
- News link: https://www.theregister.co.uk/2024/05/01/riscv_support_android_pulled/
- Source link:
The patch, filed under the topic "ack_riscv64_turndown" on the Android Open Source Project (AOSP) [1]tracker , removes files from the Android Generic Kernel (GKI) that existed to implement support for RISC-V, an open CPU architecture that sees use in many kinds of electronics, though hasn't made the leap to smartphones yet.
"Remove ACK's [Android Common Kernel] support for riscv64. Support for risc64 GKI kernels is discontinued," the patch note briefly says. The deletion was submitted by a Google engineer, and naturally passed the review process.
[2]
It's a significant U-turn for the Chocolate Factory, which has accepted RISC-V patches for Linux-powered Android since November 2022 (including GKI patches), and [3]formally added support in October 2023.
[4]
[5]
The practical effect of this is that Android operating system implementations using the next release of GKI won't work on RISC-V chips out of the box.
Support for RISC-V will have to be added back in by other developers, and while it's not unusual for SoC manufacturers and OEMs to make their own tweaks to Android, adding in support for a whole architecture is unusual.
[6]US government reportedly ponders crimping China's use of RISC-V
[7]RISC-V AI chip upstart Rivos plans to undercut Nvidia, helped by a quarter-billion in VC lucre
[8]SiFive is back with another 64-bit RISC-V dev board – hopefully
[9]Imagination licenses RISC-V CPU cores for smart TVs, IoT, embedded stuff
It's unclear what kind of effect this will have on RISC-V's integration into the Android ecosystem. There are no RISC-V smartphones out there yet, so it won't make life hard for phone makers, but it's hard to see GKI support being axed as conducive for the adoption of the open source CPU arch. Android still accepts RISC-V patches via AOSP.
Google assures, however, that the end of RISC-V's GKI support isn't a death sentence for RISC-V on Android. "Android will continue to support RISC-V," the ad biz said in a statement to [10]Android Authority . "Due to the rapid rate of iteration, we are not ready to provide a single supported image for all vendors."
[11]
To us, this sounds like Google thinks it's worth plowing on with RISC-V support in Android but doesn't think it's ready yet for prime time.
It's an especially weird time to make this kind of move since [12]Qualcomm is set to incorporate RISC-V CPUs and Google's Wear OS for future wearables. The work of adding RISC-V support for Wear OS would surely carry over at least partially to Android. We've asked Google for further comment on its motivations for removing RISC-V support in GKI, and we'll update if we get a reply.
Meanwhile, the RISC-V community has [13]issued its RISC-V Boot and Runtime Services Specification, which aims to define a common, generic platform on which OSes and hypervisors can start and manage a system. ®
Get our [14]Tech Resources
[1] https://android-review.googlesource.com/q/topic:%22ack_riscv64_turndown%22
[2] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/personaltech&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZjK7fkWwgjXto5kNobA@XgAAAI0&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[3] https://www.theregister.com/2023/10/31/google_android_risc_v/
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/personaltech&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZjK7fkWwgjXto5kNobA@XgAAAI0&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[5] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/personaltech&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZjK7fkWwgjXto5kNobA@XgAAAI0&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[6] https://www.theregister.com/2024/04/24/us_commerce_china_risc_v_investigation/
[7] https://www.theregister.com/2024/04/17/riscv_ai_startup_rivos_funded/
[8] https://www.theregister.com/2024/04/09/sifive_riscv_hifive/
[9] https://www.theregister.com/2024/04/08/imagination_riscv_cpu_cores/
[10] https://www.androidauthority.com/android-drop-risc-v-kernel-3438330/
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_onprem/personaltech&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZjK7fkWwgjXto5kNobA@XgAAAI0&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[12] https://www.theregister.com/2023/10/18/qoogle_qualcomm_riscv_snapdragon/
[13] https://github.com/riscv-non-isa/riscv-brs
[14] https://whitepapers.theregister.com/
How much of this decision do you think is tied in with the US Government looking at the possibility of restricting RISC V to the Chinese?
Given how many Chinese companies design chips around ARM cores, then manufacture them, then write the software that runs on them, I don't think that's the reasoning. China can, whenever it wants, stop paying ARM for licenses and still crank out as many ARM chips as they want. I'm sure American politicians will figure this out in time and make statements about how they'll prevent them from doing so which will have about as much success as their desires to prevent them from using RISC-V, which is about as much if they announced that they will be banning them from using iron.
Meanwhile, to keep the code in the project means plenty of developer time spent testing and fixing these things, all for hardware that doesn't exist. It's not surprising that Google wants to wait until their work is achieving something before they take on the effort of maintaining it. Almost certainly, if Qualcomm starts to make RISC-V phone chips and gets someone to build a device around them, they will merge plenty of changes to account for how their version differs from the theoretical version. When they're done with that, Google can merge the important ones back into their project rather than trying to do that continuously. The effect of the delay to end users will be unnoticeable.
Yeah, this kinda seems like a nothing burger. It's still in development, they're just not packaging it with official builds, 3rd parties can still add them just like any other package.
This seems like really odd timing.
As the piece says, there's a Qualcomm-Google collaboration for RISC-V smartwatches, but also, there's a couple of more-capable RISC-V processors on the near horizon :
- the SpacemiT K1 and the
- the sophgo SG2380
both of which are capable of running Linux or Android smoothly.
RISC-V is going to be a thing, with or without Android : other OSs are available.
I can only think this is political.
Re: This seems like really odd timing.
... or maybe it is technical. Android needs Java (or Kotlin), and if I read the related benchmarks correctly, the RISC-V SiFive HiFive Unmatched gets a Java JMH throughput of [1]6.8 Million ops/s, while a run of the mill (for smartphones) Rockchip 3588 ARM Cortex-A76 gets [2]6.7 Billion ops/s (similar to Intel Core [3]i3-4130 ).
[1] https://openbenchmarking.org/result/2206040-NE-RISCVSIFI55#results
[2] https://openbenchmarking.org/result/2309052-NE-1806117FO92
[3] https://openbenchmarking.org/test/pts/java-jmh-1.0.0
Re: This seems like really odd timing.
I guess it would be better if it were a technical issue, rather than a political/economic decision, in that progress will be made over time.
A future RV smartphone
In view of [1]recent developments , my initial thought that this was to be Tesla's next vehicle.
[1] https://www.theregister.com/2024/04/30/tesla_ai_workloads/
I can kind of understand this, since RISC-V hasn't really made much in the way of inroads into the phone and tablet market, working to keep those patches up to date and testing them is probably a not insignificant amount of work. They can always add it back later if there's a need for it.