Dear Maintainer, Currently riscv32 has been supported upstream for a while[0] and people can setup a riscv32 qemu with yocto[1], but it is time consuming. There is no distro to support riscv32 AFAIK until now however I think this will benefits users who want to setup riscv32 rootfs quickly if we support this. I thought the riscv32 has met the request[2] also. Please let me know if there is any issue. [0]: https://github.com/riscv-collab/riscv-gnu-toolchain#installation-linux [1]: https://github.com/riscv/meta-riscv [2]: https://wiki.debian.org/Teams/Dpkg/FAQ#Q._Can_we_add_support_for_new_dpkg_architectures.3F
Hi! Is your intention to create such port (unofficially or officially in Debian)? I assume the ABI is set in stone and well defined. I think at the time when we added riscv64 we didn't also add riscv32 because it was not clear whether there was then interest or demand, and I don't recall whether there were concerns about what ISA baseline to choose? (But I guess this would use the default baseline specified currently by the compiler.) Thanks for the patch, I've adapted it slightly for the test suite (now it passes «make authorcheck», and added the missing ABI tracking support, but I think I'll split that into its own commit as that is affecting riscv64 too. (I'm in the process of preparing another upload to sid, ideally before the release, and if this looks all good, I'd be inclined to include part of this (probably not the ABI tracking bits) into that release, to make adding such port possible in the near future.) Thanks, Guillem
... FWIW, when I gave a short talk about Debian's riscv64 port a few years ago almost all the questions from the audience basically came down to "when are you going to do a riscv32 port?" ... I suspect it was at least partly because it is much easier to implement a riscv32 core in FPGA that riscv64. So there is *some* interest, even if a bit niche, though the landscape maybe has changed a bit since 2019 with more riscv64 silicon available? live well, vagrant
Hi! Yeah, I am trying to do such port and I guess riscv32 ends up in the debian-port given the troubles that 32-bit systems present to packages maintainer. There is no doubt that the porting of riscv64 is our first priority and it's already in a good shape -- except for the official port.:( For riscv32 case, I think it'd be pretty helpful to let users to setup rv32 Debian rootfs or to let rv32 Debain run on RISC-V 32 bit hardware that will be emerged in the near future. Here I simply assume that rv32 compiler with `--with-arch=rv32gc --with-abi=ilp32d`[0] is enough? Many thanks here. In fact in either case, the first step is to enable rebootstrap[1] work. This process will be accelerated if dpkg can support this I think. [0]: https://github.com/riscv-collab/riscv-gnu-toolchain#installation-linux [1]: https://salsa.debian.org/helmutg/rebootstrap
There are three ABIs for 32-bit RISC-V. They are well defined, but it is not clear which ABI is being proposed for Debian here. Do you have any references for this hardware? That is one choice, but not the only one. The argument in favor of a 32-bit port of RISC-V is typically motivated by the assumption that such processors will be smaller, in terms of the hardware (i.e., ASIC gates or FPGA LUTs). However, as compared to rv64gc, eliminating floating point typically provides a much more significant decrease in size. Thus, often when one is talking about smaller, 32-bit RISC-V processors, they *also* eliminate floating point. In other words, the processors are rv32imac, not rv32gc. In fact, I wouldn't be surprised if rv64imac processors were more common than rv32gc, given the minimal hardware resources for 64-bit versus 32-bit, all else being equal. // darius
Hi, From my vague memory, there will be k230 fully support rv32 in userspace from canaan. Sorry, I was trying to find news or useful url but fail here. Thanks for explaining this. Here are some of my thoughts about it. I think, as a distribution, we should provide a basic baseline of instruction set supported to cover most hardware vendors. We should not assume that hardware vendors will product their CPUs on a certain instruction set. In addition, refer to other 32-bit architectures, like armhf[1] and mips[2], They are also supporting floating point instructions(IIUC). Also, keep the same baseline with rv64, maybe it will reduce confusion for users. I am not sure how much would we benefit from dropping support for 'F' or 'D', but maybe we can't lost something if we support full set(rv32gc) from port's view. [0]: https://www.canaan.io/ [1]: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules2#L485 [2]: https://salsa.debian.org/toolchain-team/gcc/-/blob/master/debian/rules2#L646
From what I can see it’s using a C908 which is RV64. Maybe it can also do RV32 if you switch mode, but why would you, just as we don’t recommend people run i386 on amd64. RV32-only Unix-capable hardware would be more interesting, but seems like a foolish thing to build in this decade. We should support hardware that does exist, not hardware that might exist. So long as there is no RV32-only Unix-capable hardware out there, what is the point in Debian producing a distribution? Because they date back to when 32-bit computing was common practice, and wanted floating-point. These days, 64-bit is the standard, and there is little motivation for building a 32-bit core with floating-point given the tiny additional area needed to make it 64-bit (especially since you already need 64-bit data paths for the D extension). If you’re going to provide a distribution for RV32, dropping F and D seems like the right thing to do, since that’s the only sensible thing to build hardware for. But why commit to one now when nothing exists yet to motivate any of them. Jess
Hi! Sorry for the later reply. I consulted relevant people on this topic. If running on rv32 mode, it will save about 8% ddr. Sorry, I do not understand correctly maybe here. If you talk about the point of porting riscv32, porting one arch in emulators before real hardware came out should be feasible. Now qemu can support rv32 and the upstream toolchain is well also. Certainly, this is also the result of RISC-V people supporting 64-bit and 32-bit from the beginning. On the other hand, as a distribution, if we have the opportunity to get more people to choose Debian over other distributions or yocto, the porting may also make sense from this point of view. If you talk about the baseline ABI according to hardware, yeah, this is still open. Thanks for more background here. I thought this might lead to a wider discussion before solid ABI as pabs' suggestion. BR, Bo
Hi! Given the ongoing discussion, where the ABI does not seem clear, and there is even concerns about the existence of the port at all, I'll defer this one for now, so that I can submit the current pending unblock request. Once things are more clear from the RISC-V porters side, then I'm happy to include this in git HEAD, and even propose updating dpkg in stable release branches to add it there if necessary. Thanks, Guillem
Hi! There's been not much progress (that I know of) with this port, (in rebootstrap, etc), so as part of some bug triaging I'm going to be closing this now. While I also question the point of introducing new 32-bit ports at this point in time, please don't consider this closure something final. If there's ever renewed interest in pushing forward this port, and there are no concerns from the various items before the dpkg one in <https://wiki.debian.org/PortsDocs/New>, then please feel free to either reopen this report or create a new one. Thanks, Guillem