6 ms·

Google "wants" that, but doesn't seem to push forward on that matter. AOSP gerrit received risc-v jvm CLs 2 years ago from external contributors, and didn't mer

by phh 4y ago

Google "wants" that, but doesn't seem to push forward on that matter. AOSP gerrit received risc-v jvm CLs 2 years ago from external contributors, and didn't merge any. (sorry, I have no source from Google's gerrit since they regularly clean it up, but you can find https://www.theregister.com/2021/01/21/android_riscv_port/ https://www.theregister.com/2021/01/21/android_riscv_port/ for related info ) Current state of Android RISC-V support 2 years after those ignored contribution is literally "we have a working libc", which isn't great. My understanding of Google's presentation is that Android 14 (Q3 2023) will have interpreter-only jvm support for RISC-V, no JIT/AOT. (I'm surprised there is no pure C interpreter that would work anywhere, but well). So decent RISC-V support in Android may happen for Android 15, so Q3 2024. Will there be weird ABI/ISA issues that will need few versions to iron out? Hard to say, armv5 didn't go smoothly, nor armv7 (hi neon-less nvidia), and risc-v's modularity might prove to be challenging on that regard. Overall, even though Google/Android doesn't seem as pushy on risc-v as they pretend to be, I'd say Google/Android will indeed be ready when the risc-v industry is ready for prime time.

Conan_Kudo 4y ago
Nobody really wanted to integrate RISC-V support anywhere while the ISA and ABI was unstable. That only really got finalized last year, so I am not surprised that it took this long.
- packetlost 4y ago
  This actually seems like the most reasonable reason to me. It wasn't stable, there was nobody (planning) on making RISC-V devices on which you'd want to run Android, and compiler support was far behind. We're in a very different place now, I would have made that same call (though perhaps would have given more reasoning to reduce speculation).
- fulafel 4y ago
  Is this more about the ABI? I couldn't find incompatible userspace ISA changes since many years (things sounded to have settled down since a while even in 2016: https://riscv.org/wp-content/uploads/2016/06/riscv-spec-v2.1.pdf https://riscv.org/wp-content/uploads/2016/06/riscv-spec-v2.1...). The RISC-V Linux port was also merged to mainline in 2017 and presumably been living under the stern binary & ABI compatibility rules there.
  - Conan_Kudo 4y ago
    Since ISA collections affect ABI in RISC-V, getting an agreement of the baseline for RISC-V ISA for Linux-based systems was extremely difficult. On top of that, the ABI stabilization work couldn't begin until the required ISA extensions for Linux were locked in. So it was all a mess. (It still is a mess, to be honest...)
photonbeam 4y ago
My guess is that theyve only recently been asked by handset manufacturers to consider non-ARM chips, for example this would be a great way for Qualcomm to gain leverage over ARM given the recent lawsuit
- kllrnohj 4y ago
  Android has official x86 & x86_64 support and used to have MIPS support back when MIPS still existed, so this isn't the first "not-ARM" support to happen. But the change from ignoring risc-v contributions to saying it's important probably did come from a significant SoC manufacturer pushing for it, yeah.
- packetlost 4y ago
  I'm aware of at least one Chinese manufacturer building a RISC-V based smartphone
  - solarkraft 4y ago
    On what timeline? Are there any suitable SoCs yet?
    - packetlost 4y ago
      This one is what I'm aware of: https://sipeed.com/licheepi4a/ https://sipeed.com/licheepi4a/ Alt: https://linuxgizmos.com/lichee-pi-4a-risc-v-platform-available-for-pre-order/ https://linuxgizmos.com/lichee-pi-4a-risc-v-platform-availab... At the bottom they say they have a tablet and phone planned, though no info on when.
- phh 4y ago
  Another possible guess, is that Google wants to start making their own CPU cores to beat Apple (I'm more along your guess, but I've seen so much Pixel-first AOSP development, that I have to doubt)
izacus 4y ago
What would be the correct way to handle this in your opinion then? Invest in migrating a massive OS onto the new arch before it's stabilized and has a working SoC with 3D acceleration (which Android needs)?
solarkraft 4y ago
The timeline looks similar to when I expect the first RISC-V consumer devices to be ready, so they'll be ready in time for that. The downside is that developers won't be able to test their stuff on the dev boards that are already available, which may harm the ecosystem on launch.

by phh 4y ago

Conan_Kudo 4y ago

Nobody really wanted to integrate RISC-V support anywhere while the ISA and ABI was unstable. That only really got finalized last year, so I am not surprised that it took this long.

packetlost 4y ago
This actually seems like the most reasonable reason to me. It wasn't stable, there was nobody (planning) on making RISC-V devices on which you'd want to run Android, and compiler support was far behind. We're in a very different place now, I would have made that same call (though perhaps would have given more reasoning to reduce speculation).
fulafel 4y ago
Is this more about the ABI? I couldn't find incompatible userspace ISA changes since many years (things sounded to have settled down since a while even in 2016: https://riscv.org/wp-content/uploads/2016/06/riscv-spec-v2.1.pdf https://riscv.org/wp-content/uploads/2016/06/riscv-spec-v2.1...). The RISC-V Linux port was also merged to mainline in 2017 and presumably been living under the stern binary & ABI compatibility rules there.
- Conan_Kudo 4y ago
  Since ISA collections affect ABI in RISC-V, getting an agreement of the baseline for RISC-V ISA for Linux-based systems was extremely difficult. On top of that, the ABI stabilization work couldn't begin until the required ISA extensions for Linux were locked in. So it was all a mess. (It still is a mess, to be honest...)

photonbeam 4y ago

My guess is that theyve only recently been asked by handset manufacturers to consider non-ARM chips, for example this would be a great way for Qualcomm to gain leverage over ARM given the recent lawsuit

kllrnohj 4y ago
Android has official x86 & x86_64 support and used to have MIPS support back when MIPS still existed, so this isn't the first "not-ARM" support to happen. But the change from ignoring risc-v contributions to saying it's important probably did come from a significant SoC manufacturer pushing for it, yeah.
packetlost 4y ago
I'm aware of at least one Chinese manufacturer building a RISC-V based smartphone
- solarkraft 4y ago
  On what timeline? Are there any suitable SoCs yet?
  - packetlost 4y ago
    This one is what I'm aware of: https://sipeed.com/licheepi4a/ https://sipeed.com/licheepi4a/ Alt: https://linuxgizmos.com/lichee-pi-4a-risc-v-platform-available-for-pre-order/ https://linuxgizmos.com/lichee-pi-4a-risc-v-platform-availab... At the bottom they say they have a tablet and phone planned, though no info on when.
phh 4y ago
Another possible guess, is that Google wants to start making their own CPU cores to beat Apple (I'm more along your guess, but I've seen so much Pixel-first AOSP development, that I have to doubt)

izacus 4y ago

What would be the correct way to handle this in your opinion then? Invest in migrating a massive OS onto the new arch before it's stabilized and has a working SoC with 3D acceleration (which Android needs)?

solarkraft 4y ago

The timeline looks similar to when I expect the first RISC-V consumer devices to be ready, so they'll be ready in time for that. The downside is that developers won't be able to test their stuff on the dev boards that are already available, which may harm the ecosystem on launch.