Hi, Maybe you've noticed a discussion about porting rv32 on this mailing list a few weeks ago. In the meantime, we,Gao Han<gaohan@iscas.ac.cn> and me, have almost finished rebootstrap's[0] support for riscv32, and already have its first users[1]. Given that, I hope to get more suggestions or opinions before any next actions from here. Why port riscv32? ------------------ In fact, I known the attitude toward 32-bit system from Debian developer because it brings many maintenance burdens. In my initial idea, the porting will be always existed in unofficial port. Under such circumstances, I think the arch will not bring trouble to the package maintainer. so we finally offer a limited, basic working Debian riscv32 rootfs that does not include large packages like Desktop app and I do not think it's sensible to run these programs on rv32. On the other hand, since the arch is in the unofficial port, the buildd machines can use qemu if there is not suitable rv32 hardware, but this is extremely the case. As for why users will use riscv32, I think the cases of the mail[1] is more convincing. But it seems the thread's main argument is rv64ilp32 vs pure 32-bit IIUC. Anyway, we've seen the potential need for rv32 userspace. I imagine that riscv32 will be more used on low power RISC-V hardware, especially embed market.Yocto[2] and buildroot are ideal tools for the embedded world but they are very clunky, especially for beginners. From a distro's point of view, there is no reason for us to give up this piece of potential users. In turn, I hope this work can contribute a little to the ecological development of RISC-V. Rebootstrap support for riscv32 was done here without too much effort we even can construct riscv32 rootfs with mmdebstrap[3], so this proves that upstream support for riscv32 is already in good shape. Surely some issues come from glibc, but we are trying to solve this issue. If the above arguments make sense, then we can move on to the following topic. Should to choose which ABI? --------------------- Here I will listen to the opinions of various experts. In fact, what I understand is more or less from documents rather than the real needs of the industry. This time our bootstrap[0] is based on rv32gc, in fact, it should not be difficult to rebootstrap based on rv32imac or other ABI. It is impossible for us to meet the requirements of every vendor but we maybe need to determine ourself ABI early so I can send such patch to support riscv32 for gcc. The worst scenario I can imagine is that it is not suited for porting riscv32 at this time. In this case, I wonder if it is possible to at least make rebootstrap support riscv32? In other words, I have to send patchs to add support riscv32 for several key packages. so others can quickly build their own Debian riscv32 repositories using rebootstrap. Because helmut made it clear that any patch that will be merged needs to be reported to the upstream at first. The above is my idea of porting rv32 and the current situation. If you think this work makes sense or have any other thoughts aboutthis please comment. Only by collaborating with more people, will be more valuable or easier. :) In fact, I got many valuable advice and help
from manuel and helmut, thanks again. Thanks in advance. [0]: https://salsa.debian.org/vimerbf-guest/rebootstrap/-/tree/support_riscv32?ref_type=heads [1]: https://lore.kernel.org/linux-riscv/20230518131013.3366406-1-guoren@kernel.org/ [2]: https://github.com/riscv/meta-riscv [3]: https://github.com/yuzibo/riscv32 root@debian:~# uname -a Linux debian 5.15.43 #1 SMP Mon May 8 14:53:14 +08 2023 riscv32 GNU/Linux root@debian:~# neofetch _,met$$$$$gg. root@debian ,g$$$$$$$$$$$$$$$P. ----------- ,g$$P" """Y$$.". OS: Debian GNU/Linux 12 (bookworm) riscv32 ,$$P' `$$$. Host: riscv-virtio,qemu ',$$P ,ggs. `$$b: Kernel: 5.15.43 `d$$' ,$P"' . $$$ Uptime: 19 hours, 30 mins $$P d$' , $$P Packages: 138 (dpkg) $$: $$. - ,d$$' Shell: bash 5.2.15 $$; Y$b._ _,d$P' Terminal: /dev/ttyS0 Y$$. `.`"Y$$$$P"' CPU: (1) `$$b "-.__ Memory: 23MiB / 994MiB `Y$$ `Y$$. `$$b. `Y$$b. `"Y$b._ `""" -- Regards, -- Bo YU
Attachment:
signature.asc
Description: PGP signature