Add RISC-V architecture support #1503
Comments
|
One concern is maintenance burden since I'm not familiar with the architecture details. If you want to work on it, I hope you can support the arch issues (if any) for a long time. |
|
To Find arch specific gcc option RISC-V (VisonFive 2)static int a(void)
{
8b0: 1141 add sp,sp,-16
8b2: e406 sd ra,8(sp)
8b4: e022 sd s0,0(sp)
8b6: 0800 add s0,sp,16
8b8: 8786 mv a5,ra
8ba: 853e mv a0,a5
8bc: ee5ff0ef jal 7a0 <_mcount@plt>
return b() - 1;
8c0: 014000ef jal 8d4 <b>
8c4: 87aa mv a5,a0
8c6: 37fd addw a5,a5,-1
8c8: 2781 sext.w a5,a5
}
8ca: 853e mv a0,a5
8cc: 60a2 ld ra,8(sp)
8ce: 6402 ld s0,0(sp)
8d0: 0141 add sp,sp,16
8d2: 8082 ret
00000000000008d4 <b>:
static int b(void)
{
8d4: 1141 add sp,sp,-16
8d6: e406 sd ra,8(sp)
8d8: e022 sd s0,0(sp)
8da: 0800 add s0,sp,16
8dc: 8786 mv a5,ra
8de: 853e mv a0,a5
8e0: ec1ff0ef jal 7a0 <_mcount@plt>
return c() + 1;
8e4: 014000ef jal 8f8 <c>
8e8: 87aa mv a5,a0
8ea: 2785 addw a5,a5,1
8ec: 2781 sext.w a5,a5
}
8ee: 853e mv a0,a5
8f0: 60a2 ld ra,8(sp)
8f2: 6402 ld s0,0(sp)
8f4: 0141 add sp,sp,16
8f6: 8082 retx86_64 (VMware Kbuntu 23.10)static int a(void)
{
1229: f3 0f 1e fa endbr64
122d: 55 push %rbp
122e: 48 89 e5 mov %rsp,%rbp
1231: ff 15 b1 2d 00 00 call *0x2db1(%rip) # 3fe8 <mcount@GLIBC_2.2.5>
return b() - 1;
1237: e8 05 00 00 00 call 1241 <b>
123c: 83 e8 01 sub $0x1,%eax
}
123f: 5d pop %rbp
1240: c3 ret
0000000000001241 <b>:
static int b(void)
{
1241: f3 0f 1e fa endbr64
1245: 55 push %rbp
1246: 48 89 e5 mov %rsp,%rbp
1249: ff 15 99 2d 00 00 call *0x2d99(%rip) # 3fe8 <mcount@GLIBC_2.2.5>
return c() + 1;
124f: e8 05 00 00 00 call 1259 <c>
1254: 83 c0 01 add $0x1,%eax
}
1257: 5d pop %rbp
1258: c3 retAArch64 (RPI 4)static int a(void)
{
934: a9bf7bfd stp x29, x30, [sp, #-16]!
938: 910003fd mov x29, sp
93c: aa1e03e0 mov x0, x30
940: aa0003fe mov x30, x0
944: d50320ff xpaclri
948: aa1e03e0 mov x0, x30
94c: 97ffff99 bl 7b0 <_mcount@plt>
return b() - 1;
950: 94000004 bl 960 <b>
954: 51000400 sub w0, w0, #0x1
}
958: a8c17bfd ldp x29, x30, [sp], #16
95c: d65f03c0 ret
0000000000000960 <b>:
static int b(void)
{
960: a9bf7bfd stp x29, x30, [sp, #-16]!
964: 910003fd mov x29, sp
968: aa1e03e0 mov x0, x30
96c: aa0003fe mov x30, x0
970: d50320ff xpaclri
974: aa1e03e0 mov x0, x30
978: 97ffff8e bl 7b0 <_mcount@plt>
return c() + 1;
97c: 94000004 bl 98c <c>
980: 11000400 add w0, w0, #0x1
}
984: a8c17bfd ldp x29, x30, [sp], #16
988: d65f03c0 ret |
|
Thanks for the update, it'd be nice if you could link the psABI or calling convention document for RISC-V. |
|
@namhyung I have studied Linux Kernel & existing implementation of uftrace other arch for RISC-V implementation. Thank you! |
|
We can full virtualize the RISC-V 64bit Development Platform. :) |
|
If you are interested in documentation on building a Windows Based RISC-V development environment in korean, please see the links below. |
|
Hi @gichoel, thanks very much for the useful document. But it looks the environment is based on Windows. It'd also be useful if there is a guide for Linux users. In addition, it looks a bit complicated to extract some files such as |
|
Based on your feedback, I'll be adding documentation for the Linux version and a simple way to use files like fw_jump.elf, uboot.elf, etc. |
|
If you are interested in documentation on building a Ubuntu Linux Based RISC-V Cross-Compile development environment in korean, please see the links below. |
|
Thanks very much for the document. I'm able to setup riscv64 environment following your guide. But I think we can further simplify the steps as follows.
|
|
I think we better build and test inside riscv64 qemu. It might be a bit slower than host machine, but the development and test cycle is much better than cross compilation environment. |
|
It's a different story but it might also be very helpful if we can have a qemu android development environment as well. |
|
Thanks for the great suggestion to further simplify the steps :)
It seems like a great idea from the perspective of having a build and test environment for multiple architectures and operating systems on one local Linux machine, since users most likely don't have all the development boards or machines. I'll give it a try when I get some time. |
sudo apt-get install qemu-utils
sudo apt install qemu-system-misc |
|
There is libluajit issue for adding support RISC-V. Reference for using libluajit in RISC-V in the future. |
Thanks. I've updated the comment with |
|
We can build latest QEMU, sometimes Linux Kernel & QEMU & boot firmware are version dependent :( $ sudo apt -y install build-essential libglib2.0-dev libfdt-dev libpixman-1-dev zlib1g-dev libslirp-dev libcap-ng-dev libattr1-dev ninja-build
$ git clone https://github.com/qemu/qemu.git
$ mkdir build
$ cd build
$ ../configure --target-list=riscv64-softmmu --prefix="$HOME/MyUsrBin" --enable-slirp --enable-kvm --enable-virtfs --enable-tools
$ make -j $(nproc)
$ make install |
|
We can find latest RISC-V google android info :) |
|
We can emulate RISC-V android 12 ;) $ emulator -verbose -no-boot-anim -show-kernel -noaudio -selinux permissive -qemu -smp 1 -m 3584M -bios kernel/prebuilts/5.10/riscv64/fw_jump.bin |
Fedora 38 QEMU Guide on Window 10 WSL2The host distribution or operating system environment of the WSL doesn't really matter, but I thought it would be nice to match the redhat-like commands of the guest OS, so I done with fedora. This guide has been rewritten with Fedora's RISC-V Boot_under_QEMU Guide as a reference. 1. Install WSL2 Fedora
2. Boot under QEMUHere is the last tested configuration for the instructions below:
We will use
Download disk image and verify Download the latest U-Boot (we need U-Boot SPL and U-Boot ITB files) Update the We will use first solution We want to remove fdtdir because we will get DTB from the QEMU itself. Set console to ttyS0. So, we will remove Finally, In our Unmount Launch QEMU Optional: Add QMP Option (QEMU Guest Dump Solution) Once machine is booted you can connect via SSH: If you use it and are worried about it, be sure to change your ID and Password. Device Tree dump. This can run up to 32 CPUs. |
|
We need dynamic tracing support but let's leave it in a separate issue (#1862). |
I think add uftrace riscv support like other architectures already implemented is futuristic fantasy.
I am currently researching arm64 and riscv on the topic of architecture-dependent
mcountimplementation. and I found ftrace mcount implementation of the riscv architecture Linux kernel.Even if there is no riscv target board, full virtualization is possible in the QEMU environment, so the development environment does not seem to be a problem.
arch/riscv/kernel/mcount.Sarch/riscv/kernel/mcount-dyn.SThe text was updated successfully, but these errors were encountered: