Google pulls RISC-V support from generic Android kernel

Support for RISC-V was dropped from Android's Generic Kernel Image (GKI) thanks to a patch successfully merged today. The patch, filed under the topic "ack_riscv64_turndown" on the Android Open Source Project (AOSP) tracker, removes files from the Android Generic Kernel (GKI) that existed to implement support for RISC-V, an …

[aerogems]

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.

[Anonymous Coward]

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?

[doublelayer]

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.

[Jason Bloomberg]

It does look to me like a 'come back when you've got something which isn't shifting sand' scenario. If RISC-V support was to be dropped entirely I would have expected them to have done more than they have.

It has always intrigued me as to why Android has so much architecture specific code. Chip or product specific code for memory, display, IO, and initialisation I can understand, but the rest should merely be a compiler option.

[Chappy]

The obvious power the USA has in this matter is to ban things from being imported into the USA and to encourage US allies such as EU, Australia, Canada, NZ, UK, to do the same.

[druck]

China can, whenever it wants, stop paying ARM for licenses and still crank out as many ARM chips as they want.

I think they already tried that when the Chinese join venture with ARM went rogue.

[Anonymous Coward]

Why do you care?

Haven't we been told that Huawei's HarmonyOS was China's future universal OS, independent from evil democracies? Surely it will have all RISC-V support it needs for decades to come.

[StrangerHereMyself]

I'm worried that the U.S. politicians are starting to see open-source more and more as a liability. They believe that sharing information on AI and processor designs will aid our adversaries and help them to keep up technologically and thwart sanctions.

Congress is already moving to discourage the sharing of AI models under the guise of fighting "misinformation" and "responsible security." The same is happening with RISC-V and I fear that they'll move towards software in general like cryptographic ciphers or encrypted communications apps next. Eventually all open-source software which can broadly be interpreted as "aiding our enemies" could become suspect. And yes, that includes Linux, but also CAD programs (KiCad, FreeCAD), FEM software, 3D printing software and embedded operating systems.

[K]

They tried this back in the late 90's with PGP, it didn't get very far... hell they even tried forcing all PCs to have a backdoor.

Besides, America doesn't do this alone.. Nvidia, Intel, AMD etc rely upon global sales to cover the cost of R&D... take that away, and some-one else will step into the spot, yes probably ARM or a Chinese company.. the only bug loser is the US economy and they'll no longer dominate the Tech game.

[StrangerHereMyself]

If they introduce liability laws for open-source software it could have a huge chilling effect on the movement. Nobody is going to release software which might get them into a trial, result in large fines or even prison time.

[aerogems]

It probably played a part, but I'm betting it was more like reason #50 of however many different reasons there were. It might have been what ultimately pushed it over the edge, but I highly doubt it was a major factor.

[fPuck]

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.

[Anonymous Coward]

Google Still Supporting 64-bit RISC-V

This is being reported incorrectly by many outlets.

Google clarifies:

https://lists.riscv.org/g/sig-android/message/389

Nothing has changed for android RISC-V RV64 support for AOSP.

[StrangerHereMyself]

Re: Google Still Supporting 64-bit RISC-V

They could just refrain from releasing any ACK/GKI builds henceforth. That would have the same effect as halting support for RISC-V. Producing a RISC-V Android version without it would be impossible.

[3arn0wl]

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.

[HuBo]

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 6.8 Million ops/s, while a run of the mill (for smartphones) Rockchip 3588 ARM Cortex-A76 gets 6.7 Billion ops/s (similar to Intel Core i3-4130).

[3arn0wl]

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.

[Charlie Clark]

Re: This seems like really odd timing.

Take your blinkers off.

Qualcomm is more than capable of adding support itself. This isn't a ban on Android for RISC-V, it's just a removal from the generic builds and it's reasonable to think that this is for justified technical reasons.

[david 12]

Re: This seems like really odd timing.

Yes, actual physical implementations are in the pipeline, so now seems to be the time to deprecate the version that doesn't have hardware support, and to wait and see what emerges, or the time to work with hardware providers,

[aerogems]

Re: This seems like really odd timing.

And... if any of those products do well in the market, they may reverse the decision. Still, even if one or two products become smash successes, that's not even a drop in the ocean of all the other Android on ARM devices out there. You start getting at least mid-double digits and they may consider it worth the resources needed to have these patches as part of the main tree.

[abend0c4]

A future RV smartphone

In view of recent developments, my initial thought that this was to be Tesla's next vehicle.

[ICL1900-G3]

Tho?

FFS!