How to commit a new architecture like RISC-V
hello We have a new architecture , We have compiled a lot of packages.Now the system can work normally . We want to submit to debian like RISC-V. Please What documents(or others) can we refer to. I want to know the submission process and documents.I know RISC-V has done it ,but I do not know how to begain and what can referance. Please help me . thank you !!!
Re: How to commit a new architecture like RISC-V
Hi , The upsteam work is working on, But it is slow ,We can provide the patch and the apt repo. 在 2021/5/11 下午6:36, Helmut Grohne 写道: Hi, On Tue, May 11, 2021 at 05:41:35PM +0800, zhangjialing wrote: We have a new architecture , We have compiled a lot of packages.Now the system can work normally . We want to submit to debian like RISC-V. Please What documents(or others) can we refer to. I think that recent port bootstrapping efforts have been performed using https://wiki.debian.org/HelmutGrohne/rebootstrap. I want to know the submission process and documents.I know RISC-V has done it ,but I do not know how to begain and what can referance. Please follow up on this email thread with the following information: * What is the gnu triplet used for the port? loongarch64-linux-gnu * How many bits? Endianess? 64 bits,Little Endian * What is the state of binutils support? 2.31.1-16 , patch can provide * What is the state of gcc support? gcc 4:8.3.0-1 gcc-8 8.3.0-6 patch can provide * What is the state of linux support? 4.19.167,patch can provide * What is the state of glibc support 2.28-10,patch can provide * Do you have a preferred architecture name already? loongarch64 When describing "what is the state of ... support?", please tell: * If the support is upstreamed, since which version? * If not, are patches posted? Where? * If not, is support implemented in some fork? Where? Once we got answers to all these, I suppose that extending rebootstrap to support your architecture is the next step. Once finished, you get to manually fill in the gaps and roughly end up with something close to build-essential. Using that, you'll set up a native build system and build the rest of the archive. In the process, you'll break build dependency cycles using various means. The most common ones are nocheck builds and cross compilation. If you do irc, join #debian-bootstrap on oftc. Cross-bootstrap related matters are best directed at debian-cr...@lists.debian.org. Helmut
Re: How to commit a new architecture like RISC-V
在 2021/5/20 上午8:59, Paul Wise 写道: Could you also include these details and the other ones that Helmut requested in the wiki page you created? Please also rename the wiki page to the chosen architecture name (loongarch64) instead of the current name (la64). Hi, Ok, I will modify it as soon as possible
Re: How to commit a new architecture like RISC-V
在 2021/5/19 下午6:47, Helmut Grohne 写道: Hi, On Wed, May 19, 2021 at 03:22:32PM +0800, zhangjialing wrote: The upsteam work is working on, But it is slow ,We can provide the patch and the apt repo. Thank you for providing the answers on list. * What is the gnu triplet used for the port? loongarch64-linux-gnu * How many bits? Endianess? 64 bits,Little Endian Sounds sane to me. * What is the state of binutils support? 2.31.1-16 , patch can provide I'm unsure what you mean precisely here. It reads as if the architecture support was included in 2.31.1-16, but when I attempt to build it with 2.36.1-6, I get the upstream is not support now , the patch is in our local repository. | checking target system type... Invalid configuration `loongarch64-linux-gnu': machine `loongarch64-unknown' not recognized I guess that you mean that you have based your work on 2.31.1-16 and you created a patch against that version. I fear this is not something we can work with. You need to mainline your work first. Only then can Debian be bootstrapped in a reasonable way. When describing "what is the state of ... support?", please tell: * If the support is upstreamed, since which version? * If not, are patches posted? Where? * If not, is support implemented in some fork? Where? now the upstream is not support , How can I provides the source or the patch for debian. Please re-answer the questions about tooling support. This time, please really answer the three questions above for each upstream project (binutils, gcc, linux, glibc). Please do include references to public online resources if available. I fear that trying to bootstrap Debian for an architecture where the toolchain support is not mainline is not an effective use of everyone's time. We've tried that for or1k and it failed. Let's not repeat that. Really do focus on mainlining first. Doing so helps not just Debian. You'll also make it far easier to add support for e.g. Yocto or PtxDist. At a bare minimum, we'd need patches that apply to the versions in unstable. Helmut
Re: How to commit a new architecture like RISC-V
在 2021/5/20 下午5:42, Helmut Grohne 写道: Hi, On Thu, May 20, 2021 at 02:52:32PM +0800, zhangjialing wrote: the upstream is not support now , the patch is in our local repository. I fear that this is a very bad basis to bootstrap Debian from. I strongly recommend deferring a Debian port and upstreaming first. Hi, I have known upstreaming first , I will make a plan for this debian port . Please, when we upstreaming our patch , Is there a version limit for the soft like gcc ,glibc when the upstream work done , what is the next. If you want to proceed anyway, you'll pay a lot of maintenance cost. You'll be maintaining a Debian derivative. You'll include your patches and build it for a powerful existing architecture (most commonly amd64) to cross bootstrap from. Then you can use the existing bootstrap tooling (rebootstrap) and adapt it to use your derivative instead of Debian. So where does the maintenance cost come from? Debian is a moving target and whenever it changes, you get to rebase your patches. rebootstrap targets unstable. You'll be patching it. Either you'll be continuously rebasing your rebootstrap fork or you'll be solving all of the generic issues that I am solving yourself. Effectively, you'll be duplicating a ton of work. Expect that it a full time employment just to keep in sync. That's the overhead, not the development cost. Or you choose to not keep in sync with Debian and then you'll have to effectively redo the whole bootstrap once you start mainlining. Beyond this, you'll be unable to use Debian infrastructure (e.g. jenkins.debian.net). Or you may choose to go the significantly cheaper route and upstream your patches now. Yes, it'll take time, but you're still faster that way. Helmut
Re: How to commit a new architecture like RISC-V
在 2021/5/21 下午12:34, Helmut Grohne 写道: On Fri, May 21, 2021 at 09:07:10AM +0800, zhangjialing wrote: Hi, I have known upstreaming first , I will make a plan for this debian port . Good. Please, when we upstreaming our patch , Is there a version limit for the soft like gcc ,glibc I honestly fail to understand what this is supposed to mean. When upstreaming you'll always work with the respective development branch of the relevant upstream project. If you post patches for an older version, the likely outcome is that you'll be asked to post rebased versions. when the upstream work done , what is the next. This is less of a specific point in time than you may think. From your side, upstreaming is (mostly) done when your changes have been merged into the upstream VCS. A little later the respective upstream produces a release. Yet later, Debian includes that release. Often times (and for gcc and glibc in particular), new upstream releases hit the experimental suite first and only later go to unstable. What I am trying to convey here is that there is a significant amount of delay between you upstreaming your work and it being available in Debian. I think most ports in Debian were cross bootstrapped from another port. What this means is that you build cross toolchains from Debian sources and then cross build the packages required for installing build-essential. It is a tedious process requiring more than 150 builds. For earlier ports this has been manual and it is now being automated in https://wiki.debian.org/HelmutGrohne/rebootstrap. Recent ports have forked this tool to add their port-specific fixes and performed the initial bootstrap using it. Once rebootstrap finishes, a few packages (e.g. perl) are left to be manually cross built. Once you have build-essential, you continue bootstrapping natively. Please contact me once a version of binutils that supports loongarch64 is included in any Debian suite. This is the point where I can help you adapt rebootstrap. Hi, 1. is it necessary to adapt rebootstrap ? 2. after adapt rebootstrap,what is the next. I want to know the full process for a new architecture do a debian port. 3. in our local environment, we already have a Debian port based on loongarch64. Will this help the port work. Helmut
