Google Plans RISC-V Android Tools In 2024, Wants Developers To 'Be Ready' (arstechnica.com) 47
An anonymous reader quotes a report from Ars Technica: Android is slowly entering the RISC-V era. So far we've seen Google say it wants to give the up-and-coming CPU architecture "tier-1" support in Android, putting RISC-V on equal footing with Arm. Qualcomm has announced the first mass-market RISC-V Android chip, a still-untitled Snapdragon Wear chip for smartwatches. Now Google has announced a timeline for developer tools via the Google Open Source Blog. The last post is titled "Android and RISC-V: What you need to know to be ready."
Getting the Android OS and app ecosystem to support a new architecture is going to take an incredible amount of work from Google and developers, and these tools are laying the foundation for that work. First up, Google already has the "Cuttlefish" virtual device emulator running, including a gif of it booting up. This isn't the official "Android Emulator" -- which is targeted at app developers doing app development -- Cuttlefish is a hardware emulator for Android OS development. It's the same idea as the Android Emulator but for the bottom half of the tech stack -- the kernel, framework, and hardware bits. Cuttlefish lets Google and other Android OS contributors work on a RISC-V Android build without messing with an individual RISC-V device. Google says it's working well enough now that you can download and emulate a RISC-V device today, though the company warns that nothing is optimized yet.
The next step is getting the Android Emulator (for app developers) up and running, and Google says: "By 2024, the plan is to have emulators available publicly, with a full feature set to test applications for various device form factors!" The nice thing about Android is that most app code is written with no architecture in mind -- it's all just Java/Kotlin. So once the Android RunTime starts spitting out RISC-V code, a lot of app code should Just Work. That means most of the porting work will need to go into things written in the NDK, the native developer kit, like libraries and games. The emulator will still be great for testing, though.
Getting the Android OS and app ecosystem to support a new architecture is going to take an incredible amount of work from Google and developers, and these tools are laying the foundation for that work. First up, Google already has the "Cuttlefish" virtual device emulator running, including a gif of it booting up. This isn't the official "Android Emulator" -- which is targeted at app developers doing app development -- Cuttlefish is a hardware emulator for Android OS development. It's the same idea as the Android Emulator but for the bottom half of the tech stack -- the kernel, framework, and hardware bits. Cuttlefish lets Google and other Android OS contributors work on a RISC-V Android build without messing with an individual RISC-V device. Google says it's working well enough now that you can download and emulate a RISC-V device today, though the company warns that nothing is optimized yet.
The next step is getting the Android Emulator (for app developers) up and running, and Google says: "By 2024, the plan is to have emulators available publicly, with a full feature set to test applications for various device form factors!" The nice thing about Android is that most app code is written with no architecture in mind -- it's all just Java/Kotlin. So once the Android RunTime starts spitting out RISC-V code, a lot of app code should Just Work. That means most of the porting work will need to go into things written in the NDK, the native developer kit, like libraries and games. The emulator will still be great for testing, though.
Re: (Score:2)
There may be some differences in various parts of the design based on the ISA, but the overall approach to getti
Google Money (Score:2)
if a company has their own design team and wanted to invest the money into developing a chip like that.
We'll probably see it eventually as the main allure of RISC-V is that it's open and there's no licensing fee.
Which is probably a potential interest to Google: they already have some custom silicon knowhow (the ML accelerators they design and use in their data centers) and they could thus they pretty much make their own ready-to-use Android chips that they could directly sell to their customers (android device makers), without needing any licensing. All benefits for them, not a cent lost to ARM and ARM's licensee.
Re: (Score:1)
Watch this space, bookmark this post.
RISCv does not now and will never be faster than ARM CPU.
It is also not now and never will be more power efficient.
Re: (Score:2)
Many Chinese companies are entering the chat to refute that. It won't be that long before they start having fab parity with TSMC.
Re: (Score:1)
Don't be silly.
The Chinese companies will keep using ARM, clone the design and call it something ridiculous like Gui (Silicon in the silly language).
They don't care for trademarks or patents, but since they've already written code for ARM chips its easier to keep using that architecture.
RISC may have been a great idea if it was implemented 20 years ago, but today the momentum and big money is behind ARM, and since RISC is not cheaper to produce and does not provide drop-in replacement for existing code, it
Re: (Score:2)
Not for any product they want to export.
Plus there is government policy goals, to have domestic design and production of "strategic" goods. Internal consumption of RISC-V could greatly increase efficiencies of scale.
CPUs need to be "fast enough" not "fastest" (Score:2)
RISCv does not now and will never be faster than ARM CPU. It is also not now and never will be more power efficient.
Faster is irrelevant, it only needs to be "fast enough" for Android devices. Which have a variety of tiers from high performance to low cost.
Similarly more power efficient is irrelevant, it only needs to be "efficient enough" to get the targeted longevity for the tier.
Also as Apple has shown, the circuitry added to the core CPU architecture can be far more important with respect to device performance. ML engines, image processing extensions, etc. Compare Apple A and M series CPUs to a Raspberry Pi 5 t
Re: (Score:2)
Even on general purpose ARM code the Apple Silicon wins.
lol. It's really not even close to comparable.
A single M1 core performs equivalent to about 3x rpi 5 cores.
rpis are piles of crap, performance wise.
Re: (Score:2)
Even on general purpose ARM code the Apple Silicon wins.
lol. It's really not even close to comparable. A single M1 core performs equivalent to about 3x rpi 5 cores. rpis are piles of crap, performance wise.
Let's not get as ridiculous as the GP I responded to. RPi's are awesome. They stick to general purpose ARM to reduce cost. For $100 you can get an RPi 400 4GB kit with everything except a display. That is a pretty amazing Linux environment for the money. It brilliantly fulfills its mission as a low cost educational environment to learn software and hardware. It is not trying to compete with a $600 Mac mini, different goals led to different designs. It's just a convenient platform to judge general purpose AR
Re: (Score:2)
That BCM chip was never a good chip. It was a cheap chip.
Re: (Score:2)
That's a cool advertisement, but I wasn't opining on the "awesomeness" of the rpi. I was opining on the fact that performance wise, it's a pile of shit. I haven't had a phone as slow as my Pi in over a decade. That BCM chip was never a good chip. It was a cheap chip.
Again, its performance is not shitty, To repurpose my title, it's "fast enough" for the job it needs to do. That's an engineering success.
The really point here is that you can't compare Apple Silicon to generic RISC-V, not even generic ARM. Apple Silicon performance really comes from the vendor specific enhancements. The same will be true for RISC-V.
Re: (Score:2)
For a desktop, the performance of the BCM chips used in the RPi line are absolutely abysmal.
For the small workloads those chips were really designed for, they're fantastic.
But the machines can only hit a bit about 4GB/s from their L2.
That means just displaying a 4K video at 60fps consumes 46% of the entire system's bandwidth.
Desktops on RPi's suck, and I think that people who say they don't do Arms in general a great disservice, because it gives people the impression tha
Re: (Score:2)
For a desktop, the performance of the BCM chips used in the RPi line are absolutely abysmal.
For a dirt cheap education platform the desktop performance is OK. That said, I don't use the desktop. I ssh in. An absolutely wonderful environment to learn ARM32 or ARM64 assembly language. A full Linux toolchain.
It's also very convenient to ssh in and test cross platform code primarily being developed on Intel to make sure it runs on ARM, or write the NEON counterparts to SSE/AVX code. I'm normally using a 4GB Pi4 for this but I have a Pi Zero 2 W in my MacBook Pro (Intel) bag in case I need to do som
Re: (Score:2)
For a dirt cheap education platform the desktop performance is OK. That said, I don't use the desktop. I ssh in. An absolutely wonderful environment to learn ARM32 or ARM64 assembly language. A full Linux toolchain.
Sure, and a bottom of the barrel Honda Civic is a great car to learn to drive in. That doesn't make it a great car.
It's also very convenient to ssh in and test cross platform code primarily being developed on Intel to make sure it runs on ARM, or write the NEON counterparts to SSE/AVX code. I'm normally using a 4GB Pi4 for this but I have a Pi Zero 2 W in my MacBook Pro (Intel) bag in case I need to do something on ARM on the road.
That convenience applies to any SBC that runs Linux.
The cheapness of the RPi is not in debate.
I'll see about the same gains from C/C++ to NEON intrinsics on Apple Silicon as on RPi. So professionally RPi can be quite useful.
NEON is supported in AS, of course.
Fine with me, its an educational platform not a desktop replacement for Windows or macOS or Linux.
Absolutely. Fine, but not good.
The RPi, and particularly the BCM chips it uses are cheap devices, not good.
You can get better for more expensive. Using its cheapness as an excuse for its poor performance and efficiency doesn't somehow make the parts good.
Their use
Re: (Score:2)
There are plenty of very good Arm parts out there. Your Pi just doesn't have one of them, and that's because it was sponsored by Broadcom.
I've used many, various SBCs and embedded solutions. The cost benefit doesn't really get good compared to RPi until we get to smartphones (Apple, Google, etc), all highly customized.
I'm glad you get good use from a Raspberry Pi. I'm glad their ecosystem exists. It's an overall good thing for humanity. But their products are not good in comparison to anything else in that space, merely cheap.
Again, cost benefit, now toss in some quirkiness. Rock64 etc is not really displacing RPi for a reason. If one can get past the quirks sure it has more bandwidth for some applications, but for general code that additional bandwidth goes unused. Looking at general purpose code on RPi is not really distorting ARM.
Plus the low e
Re: (Score:2)
I've used many, various SBCs and embedded solutions. The cost benefit doesn't really get good compared to RPi until we get to smartphones (Apple, Google, etc), all highly customized.
This wasn't about cost benefit. It was specifically not about cost benefit. It was about the BCM parts being crap processors.
I already said they were cheap, so if you're in the market for cheap Arm CPUs that are comparable in performance to a Pentium 4, and comparable in performance per watt to a 10 year old celeron, then they're your guy.
Again, cost benefit, now toss in some quirkiness. Rock64 etc is not really displacing RPi for a reason. If one can get past the quirks sure it has more bandwidth for some applications, but for general code that additional bandwidth goes unused. Looking at general purpose code on RPi is not really distorting ARM.
Everything is quirky. The BCM chips with their VideoCore and no direct hardware access without permission from the supervisor running on it is plenty quirky.
Nothing disp
Re: (Score:2)
By quirky I was referring to users not able to get the thing up and running.
And $200 won't get you much better outside of edge cases either. And at $300 you should probably just get a Mac mini.
Re: (Score:2)
Cost is inherently tied to the benefits. And BCM part deficiencies don't change the benefits much as those deficiencies tend to only manifest in edge cases few people care about.
No more than the color of it is, in that it is a benefit, which may or may not matter.
In a discussion about the merits of the CPU, it matters about as much as pointing out that you can get a Pentium 4 for very cheap these days.
And BCM part deficiencies don't change the benefits much as those deficiencies tend to only manifest in edge cases few people care about.
Nonsense.
There's a reason you don't find tablets or smart phones using BCM parts.
Because, as it turns out, quite a few people do care about them.
In the SBC hobbyist market- you are entirely correct.
But we weren't talking about SBC hobbyist boards in the initial value analysis- w
Re: (Score:2)
Cost is inherently tied to the benefits. And BCM part deficiencies don't change the benefits much as those deficiencies tend to only manifest in edge cases few people care about.
No more than the color of it is, in that it is a benefit, which may or may not matter.
Nonsense, benefit is inherently related to cost.
Would I pay $100 for an RPi (complete except display)? Yes.
Would I pay $1,000 for a Mac mini? Yes.
Would I pay $1,000 for a RPi? No. Why? It does not offer the same benefits, or utility if you prefer, as a Mac mini. Performance, UI, software, etc.
And BCM part deficiencies don't change the benefits much as those deficiencies tend to only manifest in edge cases few people care about.
Nonsense. There's a reason you don't find tablets or smart phones using BCM parts. Because, as it turns out, quite a few people do care about them.
Off topic. You don't find stock ARM CPUs either. You find heavily enhanced ARM like the Apple A series, which as I mentioned before perform somewhat near the desktop M series.
In the SBC hobbyist market- you are entirely correct.
And now we are back on topic. Again, the
Re: (Score:2)
Nonsense, benefit is inherently related to cost.
Would I pay $100 for an RPi (complete except display)? Yes.
Would I pay $1,000 for a Mac mini? Yes.
Would I pay $1,000 for a RPi? No. Why? It does not offer the same benefits, or utility if you prefer, as a Mac mini. Performance, UI, software, etc.
You literally just demonstrated my point.
It matters to you.
Because you're willing to sacrifice quality for a lower price. Which is fine. But you don't get to somehow alter the qualitative analysis of the entire system just because it ticks one of your boxes.
Off topic. You don't find stock ARM CPUs either. You find heavily enhanced ARM like the Apple A series, which as I mentioned before perform somewhat near the desktop M series.
You're confused about what the word topic means.
Major android CPU vendors are:
Samsung, Qualcomm, Mediatek, Google, HiSilicon.
Arm does not make CPUs. Arm licenses cores.
Literally all 5 of those vendors are using CPUs with bone-stock Arm cores (With
Re: (Score:2)
Nonsense, benefit is inherently related to cost. Would I pay $100 for an RPi (complete except display)? Yes. Would I pay $1,000 for a Mac mini? Yes. Would I pay $1,000 for a RPi? No. Why? It does not offer the same benefits, or utility if you prefer, as a Mac mini. Performance, UI, software, etc.
You literally just demonstrated my point. It matters to you.
Nope. The fact that RPi is a leader with hobbyists and has some acceptance in industry demonstrates otherwise. RPi's benefits, its utility, is established. The boards you may prefer may have greater utility in niche applications. But the market largely does not care about that incremental benefit over RPi.
Because you're willing to sacrifice quality for a lower price. Which is fine. But you don't get to somehow alter the qualitative analysis of the entire system just because it ticks one of your boxes.
I am sacrificing nothing. The additional incremental utility you focus on is not important to me, nor most others.
Off topic. You don't find stock ARM CPUs either. You find heavily enhanced ARM like the Apple A series, which as I mentioned before perform somewhat near the desktop M series.
You're confused about what the word topic means.
No, you are confused about what you wrote. Let me refresh: "you don't find tablets or smart
Re: (Score:2)
Re: (Score:2)
Na, we're done here, Dunning Kruger.
Psychological Projection.
Lawyers are running Faster.. (Score:2)
Re: (Score:2)
One of the biggest reasons is that it has fewer patents on the ISA, and China is doing a ton of chip design with it. China and India have a ton of people who know what they are doing when it comes to hardware engineering.
If one takes a look at the MILK-V boards and other boards coming out of China, even with their relatively antediluvian process nodes (definitely not 3 nm), they are cranking out some pretty good SBCs, even factoring in the older Linux kernel versions and other software in use. And more bo
Re: (Score:2)
I think the biggest reason is due to the instability around ARM ltd. Sure, at the moment they have very reasonable licensing fees, but given it's a profit driven company, it is almost inevitable that the more successful it is, the more likely that someone takes over who just starts abusing customers to squeeze out more short term profits.
Add in the threat of sanctions on ARM products to China, and there is now a lot of momentum around getting away from ARM before they become a problem.
Which is quite sad, as
Re: (Score:2)
It's not about being "faster or more efficient" but avoiding the cost of expensive license to use ARM instruction set. RISC-V is free to use to design CPU.
device drivers (Score:3)
It seems to me that the main tasks will be rewriting device drivers for all the hardware components in the phones, and reworking the memory management. I wonder how much assembler there is in Android OS?
Re: (Score:3)
Actually there is very little reworking required. Linux is extremely portable and already runs on RISC V. It's mostly a tooling thing. Compilers are already there. So it's mostly a matter of setting RISC V as the target platform and hit make. There are no doubt small amounts of assembly in the Android Runtime VM, but that's already been ported.
Android has always had OEM-supplied binary firmware blobs to interface with the GPU and locked bootloaders. This is no different on RISC V.
Probably 90% of the apps o
Re: (Score:2)
I wonder how much assembler there is in Android OS?
Not much, it's mostly in the Linux Kernel.
Re: (Score:2)
Android is just a userland on the Linux kernel. Most stuff will likely just require a recompile, although having to deal with new SBC drivers will be what the engineers will have to deal with.
Re: (Score:2)
Having done a fair amount of kernel and device driver work, I don't think it is that simple.
https://www.linkedin.com/advic... [linkedin.com]
sounds great (Score:2)
Which variant of RISC-V should we expect to code against? Obviously some flavor of RV64I, but it seems like we still have some pretty big differences between vendors. Admittedly the worst problems are below user space and really only matter to kernel developers. But I still feel like R5 is still a tough target for app developers to reliably produce compatible binaries. I guess what I'm hoping for is a stricter spec kind of like ARM has for Aarch64 SBSA (Server Base System Architecture).
P.S. I love R5. I've
Re: (Score:3)
Based on Qualcomm's R5 chip apparently. Mostly they're pointing at RISC-V Software Ecosystem's [riseproject.dev] compiler offerings and indicating let the compiler handle it.
But I still feel like R5 is still a tough target for app developers to reliably produce compatible binaries
Well it's just Qualcomm at the moment, so there's little reason for portable for the moment. But I do know that SiFive and others that have R5 chips are joined in with RISE, so maybe they've got a point about trust the compiler? I don't know, a lot of the stuff on the site doesn't look to be updated and the documentation indicates:
Our WG does not have a recurring meeting; instead we try to handle RISE specific items via email and the project specific items in the project related meetings
So I guess you need
Re: (Score:2)
and indicating let the compiler handle it.
That's the head scratcher to me. There are a ton of different compiler options that control parameters and instructions in a RISC-V toolchain. And the Embedded (E) variants can get pretty out there with a different number of general purpose registers and no GPU. But we can safely ignore (E) variants if it is for a reasonably portable Android BSP.
Well it's just Qualcomm at the moment, so there's little reason for portable for the moment.
So Google didn't learn their lesson from NVIDIA's 64-bit ARM ( Nexus 9's Denver CPU) that was a slightly older rev than what ended up being commonplace by the end o
Re: (Score:2)
So Google didn't learn their lesson from NVIDIA's 64-bit ARM
Muwahahahahaha. Do they ever?
Maybe if I were still on a chip bring-up team I'd be more deeply involved in RISE
Agreed. I'd love to see R5 but I'm too old for that ground laying work. I'm a bit bias towards OpenPOWER since I'm z and i machines for a living (see aforementioned old), but IBM still has the lion's share of say in the spec that it feels less open than R5.
but it also will probably do what Google feels best
I mean that's what happened to the web so, yeah pretty much agree there too.
Re: (Score:2)
P.S. I love R5. I've been slowly porting my hobby projects to an Allwinner D1 board (Mango Pi MQ Pro).
What is great about it?
Re: (Score:2)
You shouldn't have to worry about which variant of RISC-V you are targeting for most apps. They compile to Kotlin byte code, not machine code. During installation the byte code is compiled into appropriate machine code for your device.
You can use compiled C code as well, in which case you can provide multiple variants and the Play Store will pick the right one for the user's device.
Re: (Score:2)
NDK is still a thing on Android and a product requirement that can't be ignored.
A working Bionic runtime that is binary compatible with AOSP is also very desirable. We're going to see some de facto standard for RISC-V binaries or something explicit like RISE hit the Android ecosystem for this to be a viable platform.
You can use compiled C code as well, in which case you can provide multiple variants and the Play Store will pick the right one for the user's device.
You can't identify them as there is a serious issue with describing a particular RISC-V implementation. It's accurately described by the set of compiler parameters you built your toolchain with,
Re: (Score:2)
specific ABI differences in the same hardware have always been specified in the -march.
there are like 800 arm -marches.
RISC-V is already in a tablet from Pine64 (Score:2)
Here is a link to the store page:
Pine64 - tablets store page [pine64.com]
They also have a Wiki page on the hardware:
Pine64 - RISC-V tablet Wiki page [pine64.org]
Now I don't know if that is a stable tablet, (meaning hardware reliable whence the OS is complete enough). Nor do I think it will be as fast as most tablets o
OS Lag (Score:2)
How about they fix their stupid OS so that it doesn't hiccup and stutter when just scrolling a heavy website, especially as the phone ages and more apps get installed? They just brute forced the problem with high CPU speeds but the OS is so crude. Its update methods, its privacy protections, its UI priority. They're so god dang lazy to not be willing to redo the architecture it after all these years. I remember Android fanboys getting so hyped over Fuschia because it was supposed to be a legitimately fa