We’ve first covered Alibaba T-Head work on Android 10 for RISC-V in January 2021, and later that year they started selling the T-Head RVB-ICE dual-core RISC-V board with GPU for software development. The company has now provided an update for Android 12 RISC-V port, instructions to build Android RISC-V to run it in an emulator, as well as a 2022-2023 roadmap.
Alibaba T-head is working on hardware platforms, which appears to be similar to T-Head RVB-ICE board, with the following minimal specifications:
- CPU – At least Dual-core XuanTie C910 (rv64imafdcv) processor
- GPU – Compatible with OpenGL ES and OpenCL
- VPU – HW Video/Picture codec
- Neural Network Accelerator
- System Memory – 4GB or more DDR Memory
- Display – MIPI/HDMI
- Audio – Multi-Channel Audio output & input
- Camera – ISP with support for multiple MIPI CSI lanes
- USB interface(s)
They built upon the work done on Android 10 to add support for new features, tools like Android Studio, as well as software/drivers from third parties. Performance was also optimized, and the company added support for TF Lite runing on the processor’s NPU. Camera and video decoding drivers are also being worked on, but this will take more time.
Based on the roadmap above, it seems Android 12 has already passed some CTS/VTS certifications, and upstreamed some source code. I also understand they are working on Android 13 (AOSP) to refine RISC-V patches for core components, and hopefully Android 14 will fully support RISC-V targets with commercial RISC-V Android devices coming late next year.
You’ll find the RISC-V Android Source repository on Github, and if you don’t feel like spending $400 on T-Head RB-ICE board, you could try the Android 12 RISC-V port in an emulator after building it from source.
First, you’d need to get the code:
|
1 2 3 4 5 6 7 8 9 10 |
mkdir ~/riscv-android-src && cd ~/riscv-android-src repo init -u git@github.com:riscv-android-src/manifest.git -b riscv64-android-12.0.0_dev repo sync cd prebuilts/rust/ git lfs pull cd - cd prebuilts/clang/host/linux-x86/ git lfs pull cd - rm external/angle/Android.bp |
This require a fast Internet connection, which I don’t have right now, and “repo sync” have been running for three hours so far on my laptop with only 12% of the code retrieved…
Somehow you’re asked to change the “/dev/block/vdc/” line in ~/riscv-android-src/device/generic/goldfish/fstab.ranchu.riscv.ex file manually…
|
1 |
/dev/block/vdc /data ext4 noatime,nosuid,nodev,nomblk_io_submit,errors=panic wait,check,quota,latemount |
… before starting the build:
|
1 2 3 |
source build/envsetup.sh lunch sdk_phone64_riscv64 m -j |
This will also take a while, but you should finally be able to launch he RISC-V 64 AVD system image in the Android Emulator as follows:
|
1 |
emulator -no-qt -show-kernel -noaudio -selinux permissive -qemu -smp 1 -m 3584M -bios kernel/prebuilts/5.10/riscv64/fw_jump.bin |
You’ll probably need a machine with at least 8GB RAM to run the emulator.
Via Drew Fustini
Jean-Luc started CNX Software in 2010 as a part-time endeavor, before quitting his job as a software engineering manager, and starting to write daily news, and reviews full time later in 2011.
Support CNX Software! Donate via cryptocurrencies, become a Patron on Patreon, or purchase goods on Amazon or Aliexpress
This require a fast Internet connection, which I don’t have right now” … maybe do it on a VPS, and access that with “ssh -X …”?
I have time… I have an appointment on Friday to install fiber broadband in this house.
I know that Android is the popular option, but what has been done so far can be made usable much sooner with (recently revised) B2G/KaiOS, and given less resource requirements that also mean cheaper devkits to wider audience of developers to let snowball roll sooner.
I can’t wait for the software shitshow we’ll get once Risc-V becomes mainstream.
Like what?
Take the situation with ARM SBCs: only supported by specific builds of Android and Linux based on old kernels, broken support for features like GPU hardware acceleration all over the place, and the “community” is forced to get it working. RISC-V will be much like that sh1tshow except even the instruction set can be fragmented or have proprietary extensions. RISC-V: looks like the open savior on first glance, but it just benefits big companies by letting them change more stuff and pay less licensing fees.
> broken support for features like GPU hardware acceleration
Since when has lack of graphics acceleration been a problem on Android?
Today ARM SoC vendor provides the device maker with a tar archive containing loads of crap based on Android frameworks and the required kernel version Google is asking for. Among this crap are forward ported drivers and BLOBs for media support. What should change here with RISC-V even if SoC vendors use ISA extensions?
As he said it could only be worse because at least with ARM you have access to the CPU’s specs and know the instruction set. With RISC-V you’ll find proprietary variant XYZ in your NAS/accesspoint/IoT crap without even being able to disassemble some proprietary extension, let alone know what they’re supposed to do or emit similar/compatible code. Not very appealing to me :-/
> Not very appealing to me :-/
Same here. The starting conditions clearly yell ‘Skip this and move along’ 🙂
But for the average Android e-waste device (be it a TV box, some retro gaming console, some ‘smart’ thing spying on its users or whatever) nothing really changes: SoC vendor provides crappy proprietary BSP to device vendor who sells something barely working to consumer who always buys as cheap as possible.
There’s a lot of ‘interference’ – largely from a very worried Arm – about RISC-V extensions. Linux will run on RV64GC – that is: the Base Instruction Set plus the Compressed extension, and RISC-V chip designers and OEMs know that. The only reason to use a proprietary extension would be for a specific use case, not consumer computing where the hardware is reliant on the software.
Secondly, according to Bruce Hoult: “the disk images currently being distributed have UBoot and OpenSBI for a given board in them, so the image is board-specific. But they are in different partition(s) to Linux itself, so can be replaced quite easily.
“However, it’s the intention that each board will have it’s custom UBoot and OpenSBI in something like SPI flash on the board itself, and then the Linux disk images will be completely board-independent.”
And finally, if we’re putting dibs in for OSs, I think it’d make a lot of sense to have a lightweight, morphing OS like Ubuntu Touch (Linux Lomiri).
Not being able to use certain apps because non compiled for the right ISA? Or not having the right extensions.
Not that I was talking Android specifically. Rather the SBC Linux situation that will arise. (Not that it isn’t a shitshow already…)
Disclaimer: I couldn’t care less about Android since I never use it.
But even Google should be able to adopt concepts like ‘universal binaries’ (app binary containing code for more than one CPU arch). And wrt RISC-V extensions they just need to define a common denominator binaries have to been built for. It’s their eco system and how it works can be copied from Apple.
> the SBC Linux situation
…is crap and a huge waste of time anyway. At leasts if hardware on these SBC originates from the Android e-waste world and everything important needs to be reverse engineered.
RISC-V in other areas might serve different purposes and work pretty well there (e.g. helping China overcoming US sanctions).
Oh … Linux on those RISC-V devices? Yes, big problems.
I have a RISC-V SBC (D1), with Debian on it. And already problems: the D1 does not implement FENCE.TSO (and has that documented … good), but Debian’s included LLVM does use that command in its binaries, resulting in core dump. Great.
Also: which RISC-V extensions (like vector extensions) does a RISC-V implement … ?
But: this article is about Android on RISC-V. Closed as hell.
Since memory, GPU, and all other hardware peripherals have been running Linux Android for a longtime. Why is it so hard, to translate software, drivers to RISC V ?
What gpu will they use ???
It should be a Vivante GC8000UL GPU