Re: [RFC] To port rv32 to Debian
On 20 May 2023, at 03:15, Bo YU <tsu.yubo@gmail.com> wrote:
>
> 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
That’s not riscv32, that’s riscv64ilp32, which is still cursed and
undesired in the context of Debian in my opinion. 32-bit architectures
are being killed off one-by-one, not being added.
> 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.
You will quickly find that desktop packages are key dependencies for
seemingly-unrelated things. Unpicking that is a lot of work, and don’t
expect maintainers to be receptive to such patches; many of their
answers will surely be “just fix the desktop packages or remove the
architecture”.
> 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.
I don’t see how a general-purpose distribution like Debian is well
suited to tiny embedded devices. Yocto/buildroot/etc is much more
appropriate. Yes, it’s not as friendly to use. But the people using
riscv32 are tinkerers, not people who want a computer.
> 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
Don’t confuse ISA with ABI. But this is all about real riscv32, which
isn’t related to the mailing list post you linked.
My opinion is still “no”, but I am just one of many Debian Developers.
Jess
> 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 about
> this 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
>
Reply to: