Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
* see http://fedora.riscv.rocks/koji/
I've been wanting to work with RISC-V for a while, but it's been really difficult to get my hands on a dev board. I spoke with Mark Himmelstein from RISC-V International last week and he mentioned that they are pushing hard to get more dev boards out... but they're getting hit with the chip shortage just like everyone else.
I really look forward to the day when Open ISAs like RISC-V and OpenPower have better availability. I know I'm eager to move to them as soon as I can.
I have no experience with emulating it, so I can't really give any feedback on that. Do we have a RISC-V SIG?
JT
On Mon, Oct 4, 2021 at 1:03 PM Matthew Miller mattdm@fedoraproject.org wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
-- Matthew Miller mattdm@fedoraproject.org Fedora Project Leader _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller mattdm@fedoraproject.org wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
I think the primary problem here is that koji does support neither external builders nor building on top of qemu emulation. However, COPR *does* support building on emulated architectures (that's how its armv7 and s390x support works there).
So, maybe adding a mock configuration for building RISC-V packages in qemu emulation, with the fedora repositories from http://fedora.riscv.rocks/koji/ as a base, could work until koji supports it? (I think that would involve either adding RISC-V hardware to Fedora Infrastructure, or adding support for emulated architectures to koji, or adding support for external builders to koji.)
Fabio
On Mon, Oct 4, 2021 at 1:35 PM Fabio Valentini decathorpe@gmail.com wrote:
On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller mattdm@fedoraproject.org wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
I think the primary problem here is that koji does support neither external builders nor building on top of qemu emulation. However, COPR *does* support building on emulated architectures (that's how its armv7 and s390x support works there).
So, maybe adding a mock configuration for building RISC-V packages in qemu emulation, with the fedora repositories from http://fedora.riscv.rocks/koji/ as a base, could work until koji supports it? (I think that would involve either adding RISC-V hardware to Fedora Infrastructure, or adding support for emulated architectures to koji, or adding support for external builders to koji.)
Perhaps kojivmd could be extended to support foreign architecture VMs? I think libvirt already can set up VMs with foreign architecture emulation, and kojivmd already calls libvirt for creating builder VMs.
-- 真実はいつも一つ!/ Always, there's only one truth!
I have nothing to add to this conversation other than:
1) I'd love to see RISC-V become a serious contender to X86-64. I'm tired of being controlled by the Intel/AMD oligopoly.
2) I love seeing Fedora people discuss supporting RISC-V.
3) Linux rocks. Fedora rocks.
On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller <mattdm(a)fedoraproject.org> wrote:
I think the primary problem here is that koji does support neither external builders nor building on top of qemu emulation. However, COPR *does* support building on emulated architectures (that's how its armv7 and s390x support works there).
I think your wrong about koji not supporting external builders, rpmfusion koji uses external builders.
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
We have avoided using emulation in the past because we would be chasing bugs in our emulation that aren't in real hardware and vice versa. How good is the emulation support? Do we know/have people who can fix things in it when we hit them? Tools folks: is emulation an option here? Or do we still forbid it?
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
Well, one big thing is that it's been a while since we had any secondary arches and it's unclear how they would work today. In the distant past secondary arches had their own koji and builders and composes and releases and used koji-shadow to try and match up with primary koji. This was basically more than a full time job for someone and I am sure koji-shadow has atrophied in recent years, but perhaps at least some subset could be made to work again.
On the other hand we could just add it into primary koji, but then it really really has to keep up or it's going to block everything else.
So, probibly a 'secondary' koji and builders to start with to bootstrap and to gather info on how hard it is to keep up and good emulation is would be worthwhile, but it's gonna need some dedicated work.
Perhaps we could get a up to date status report from folks working on this, answering such questions as:
* How good is emulation support * What would it take to keep up with the other arches? Is that possible? * What device(s) would we want to target and could we get sufficent numbers of them for QA and devel folks to debug problems and test? * Are there folks who can bootstrap/shepard the koji shadowing process?
I think RISC-V is pretty exciting, and I am happy to help as much as I can with adding it in. I think there's likely to be a lot of interest/growth in coming years for it.
kevin
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi kevin@scrye.com wrote:
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
We have avoided using emulation in the past because we would be chasing bugs in our emulation that aren't in real hardware and vice versa. How good is the emulation support? Do we know/have people who can fix things in it when we hit them? Tools folks: is emulation an option here? Or do we still forbid it?
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
Well, one big thing is that it's been a while since we had any secondary arches and it's unclear how they would work today. In the distant past secondary arches had their own koji and builders and composes and releases and used koji-shadow to try and match up with primary koji. This was basically more than a full time job for someone and I am sure koji-shadow has atrophied in recent years, but perhaps at least some subset could be made to work again.
On the other hand we could just add it into primary koji, but then it really really has to keep up or it's going to block everything else.
So, probibly a 'secondary' koji and builders to start with to bootstrap and to gather info on how hard it is to keep up and good emulation is would be worthwhile, but it's gonna need some dedicated work.
Perhaps we could get a up to date status report from folks working on this, answering such questions as:
- How good is emulation support
The lack of real hardware for RISC-V has made it so almost everyone is working with emulation. It's not realistic right now to work with real hardware.
- What would it take to keep up with the other arches? Is that possible?
The real hardware options do not have the performance to keep up with the other architectures.
- What device(s) would we want to target and could we get sufficent
numbers of them for QA and devel folks to debug problems and test?
This is probably more of a question for Fedora RISC-V folks like Richard W.M. Jones...
- Are there folks who can bootstrap/shepard the koji shadowing process?
We already have the other Koji instance that could be converted into a shadow Koji, couldn't it?
On Mon, Oct 4, 2021 at 10:13 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi kevin@scrye.com wrote:
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
We have avoided using emulation in the past because we would be chasing bugs in our emulation that aren't in real hardware and vice versa. How good is the emulation support? Do we know/have people who can fix things in it when we hit them? Tools folks: is emulation an option here? Or do we still forbid it?
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
Well, one big thing is that it's been a while since we had any secondary arches and it's unclear how they would work today. In the distant past secondary arches had their own koji and builders and composes and releases and used koji-shadow to try and match up with primary koji. This was basically more than a full time job for someone and I am sure koji-shadow has atrophied in recent years, but perhaps at least some subset could be made to work again.
On the other hand we could just add it into primary koji, but then it really really has to keep up or it's going to block everything else.
So, probibly a 'secondary' koji and builders to start with to bootstrap and to gather info on how hard it is to keep up and good emulation is would be worthwhile, but it's gonna need some dedicated work.
Perhaps we could get a up to date status report from folks working on this, answering such questions as:
- How good is emulation support
The lack of real hardware for RISC-V has made it so almost everyone is working with emulation. It's not realistic right now to work with real hardware.
- What would it take to keep up with the other arches? Is that possible?
Right now we run 170 QEMUs and a few boards. Most QEMU VMs run with 4 cores, but some are configured with 8 cores + 32GB of RAM. The number of boards (physical machines) will increase. With the QEMU setup we could deliver thousands of builds per week.
Of course we cannot fully keep up. For example OpenJDK doesn't have a JIT which can be used in some packages (building or running tests).
In general we have been running Fedora GNOME Wayland Desktop setup with RISC-V SoC (SiFive) + AMD GPUs for years now. I can even play a 4K movie (thanks to the GPU acceleration).
The real hardware options do not have the performance to keep up with the other architectures.
- What device(s) would we want to target and could we get sufficent
numbers of them for QA and devel folks to debug problems and test?
This is probably more of a question for Fedora RISC-V folks like Richard W.M. Jones...
The only device capable of PC-like setup is SiFive Unmatched today. That's the only board you could buy.
There are cheaper boards based on Allwinner D1, but that cheap is a complicated story. They used some reversed bits in PTE and RVV is 0.7.1, which is not compatible with what will be ratified. Technically the chip can run in "compatible" mode, but that would kill peripherals IIUC.
The current RISC-V Platforms and Profiles specifications are also not finished thus there aren't any devices that would have the official stamps of some compatibility level. If everything goes well these things will be finalized / ratified sooner than later.
- Are there folks who can bootstrap/shepard the koji shadowing process?
We already have the other Koji instance that could be converted into a shadow Koji, couldn't it?
I currently avoided "koji shadow" and used my silly scripts (which works as long as you learn all Fedora packages and how things work with some packages/ecosystems).
Cheers, david
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 10/4/21 12:12 PM, Neal Gompa wrote:
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi kevin@scrye.com wrote:
- How good is emulation support
The lack of real hardware for RISC-V has made it so almost everyone is working with emulation. It's not realistic right now to work with real hardware.
- What would it take to keep up with the other arches? Is that possible?
The real hardware options do not have the performance to keep up with the other architectures.
Is it really so slow that emulation is preferable?
On Wed, Oct 06, 2021 at 10:50:02AM -0700, Josh Stone wrote:
The real hardware options do not have the performance to keep up with the other architectures.
Is it really so slow that emulation is preferable?
Speed isn't the only concern -- in order to be reasonably manageable, we need this to be server-class hardware. Or at the very least, rackmount hardware. Dev boards -- even fast ones -- don't help much.
On Wed, Oct 06, 2021 at 10:50:02AM -0700, Josh Stone wrote:
On 10/4/21 12:12 PM, Neal Gompa wrote:
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi kevin@scrye.com wrote:
- How good is emulation support
The lack of real hardware for RISC-V has made it so almost everyone is working with emulation. It's not realistic right now to work with real hardware.
- What would it take to keep up with the other arches? Is that possible?
The real hardware options do not have the performance to keep up with the other architectures.
Is it really so slow that emulation is preferable?
Actually we prefer the real hardware over qemu for the larger builds.
As the other reply said the main concern is the lack of server-class hardware. We could build something with a Pi KVM hat, but that's not a neat integrated solution.
Rich.
On Wed, Oct 6, 2021 at 1:50 PM Josh Stone jistone@redhat.com wrote:
On 10/4/21 12:12 PM, Neal Gompa wrote:
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi kevin@scrye.com wrote:
- How good is emulation support
The lack of real hardware for RISC-V has made it so almost everyone is working with emulation. It's not realistic right now to work with real hardware.
- What would it take to keep up with the other arches? Is that possible?
The real hardware options do not have the performance to keep up with the other architectures.
Is it really so slow that emulation is preferable?
In my opinion, yes. There's a dearth of so-called "server-class" hardware, which have such useful characteristics like "large amounts of RAM", "decent memory cache", "fast I/O", "PCIe lanes", and so on.
The development boards typically are very I/O constrained and have limited amounts of RAM, making them less useful than emulation for doing builds.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Thu, Oct 7, 2021 at 1:30 AM Neal Gompa ngompa13@gmail.com wrote:
On Wed, Oct 6, 2021 at 1:50 PM Josh Stone jistone@redhat.com wrote:
On 10/4/21 12:12 PM, Neal Gompa wrote:
On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi kevin@scrye.com wrote:
- How good is emulation support
The lack of real hardware for RISC-V has made it so almost everyone is working with emulation. It's not realistic right now to work with real hardware.
- What would it take to keep up with the other arches? Is that possible?
The real hardware options do not have the performance to keep up with the other architectures.
Is it really so slow that emulation is preferable?
In my opinion, yes. There's a dearth of so-called "server-class" hardware, which have such useful characteristics like "large amounts of RAM", "decent memory cache", "fast I/O", "PCIe lanes", and so on.
The development boards typically are very I/O constrained and have limited amounts of RAM, making them less useful than emulation for doing builds.
We tried to improve the situation with SiFive Unmatched: - 16GiB of RAM (twice more compared to SiFive Unleashed); - PCIe Gen 3; - M.2 NVMe (via PCIe switch); - M.2 for WiFi/BT card (via PCIe switch); - USB-As (via PCIe switch); - You can boot firmware (OpenSBI/DT/U-Boot) via microSD card instead of SPI-NOR Flash. With SD-Muxer you could update all those bits for testing; - mini-ITX (you can put those boards in the rackmount cases); - ATX power supply; - Front panel header connector; - Multiple fan headers; - and more.
It's not perfect, but it's a decent upgrade for the 2nd generation SiFive board and the setup is way cheaper too.
Pi KVM could provide some remote management (didn't try, might get one in the future to test).
Cheers, david
-- 真実はいつも一つ!/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Oct 04, 2021 at 12:07:30PM -0700, Kevin Fenzi wrote:
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
We have avoided using emulation in the past because we would be chasing bugs in our emulation that aren't in real hardware and vice versa. How good is the emulation support? Do we know/have people who can fix things in it when we hit them? Tools folks: is emulation an option here? Or do we still forbid it?
Qemu support for RISC-V is very good, it's actually used to develop some features (virtualization and SBI). We do know people who can fix it. If you have the money real hardware is also available now.
Personally speaking I think the real barrier is someone with a large colourful hat putting up the money to hire a full time developer to work on the project.
Rich.
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
Well, one big thing is that it's been a while since we had any secondary arches and it's unclear how they would work today. In the distant past secondary arches had their own koji and builders and composes and releases and used koji-shadow to try and match up with primary koji. This was basically more than a full time job for someone and I am sure koji-shadow has atrophied in recent years, but perhaps at least some subset could be made to work again.
On the other hand we could just add it into primary koji, but then it really really has to keep up or it's going to block everything else.
So, probibly a 'secondary' koji and builders to start with to bootstrap and to gather info on how hard it is to keep up and good emulation is would be worthwhile, but it's gonna need some dedicated work.
Perhaps we could get a up to date status report from folks working on this, answering such questions as:
- How good is emulation support
- What would it take to keep up with the other arches? Is that possible?
- What device(s) would we want to target and could we get sufficent
numbers of them for QA and devel folks to debug problems and test?
- Are there folks who can bootstrap/shepard the koji shadowing process?
I think RISC-V is pretty exciting, and I am happy to help as much as I can with adding it in. I think there's likely to be a lot of interest/growth in coming years for it.
kevin
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Monday, 04 October 2021 at 22:39, Richard W.M. Jones wrote: [...]
Personally speaking I think the real barrier is someone with a large colourful hat putting up the money to hire a full time developer to work on the project.
Also, I think one of the pre-requisites to enabling it in koji would be making at least one machine available to package maintainers.
Regards, Dominik
https://www.opensourcevoices.org/20
On Mon, Oct 4, 2021 at 10:47 PM Dominik 'Rathann' Mierzejewski < dominik@greysector.net> wrote:
On Monday, 04 October 2021 at 22:39, Richard W.M. Jones wrote: [...]
Personally speaking I think the real barrier is someone with a large colourful hat putting up the money to hire a full time developer to work on the project.
Also, I think one of the pre-requisites to enabling it in koji would be making at least one machine available to package maintainers.
Regards, Dominik -- Fedora https://getfedora.org | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Mon, Oct 04, 2021 at 10:47:14PM +0200, Dominik 'Rathann' Mierzejewski wrote:
On Monday, 04 October 2021 at 22:39, Richard W.M. Jones wrote: [...]
Personally speaking I think the real barrier is someone with a large colourful hat putting up the money to hire a full time developer to work on the project.
Also, I think one of the pre-requisites to enabling it in koji would be making at least one machine available to package maintainers.
I agree. In practice it would likely be easier to ensure that we have clearer instructions for setting up qemu and timely delivery of images to run on qemu, eg through virt-builder. (I don't know about anyone else but I much prefer to work on something in a local environment.) This would be something for the person hired above to do.
Rich.
On Mon, Oct 04, 2021 at 10:47:14PM +0200, Dominik 'Rathann' Mierzejewski wrote:
Personally speaking I think the real barrier is someone with a large colourful hat putting up the money to hire a full time developer to work on the project.
Also, I think one of the pre-requisites to enabling it in koji would be making at least one machine available to package maintainers.
Yeah, I think we'd want to have at least a remote-shell system plus also an initiative to get dev boards to maintainers with specific interest.
On 10/5/21 04:39, Richard W.M. Jones wrote:
On Mon, Oct 04, 2021 at 12:07:30PM -0700, Kevin Fenzi wrote:
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
We have avoided using emulation in the past because we would be chasing bugs in our emulation that aren't in real hardware and vice versa. How good is the emulation support? Do we know/have people who can fix things in it when we hit them? Tools folks: is emulation an option here? Or do we still forbid it?
Qemu support for RISC-V is very good, it's actually used to develop some features (virtualization and SBI). We do know people who can fix it. If you have the money real hardware is also available now.
Personally speaking I think the real barrier is someone with a large colourful hat putting up the money to hire a full time developer to work on the project.
I know Wei FU(FAS: tekkamanninja) is actively working on porting Fedora to RISC-V. He has his BSP for D1 which he already put up a wiki[1]. I'm about to help him get LXQt desktop up on D1 soon.
In current situation maybe it makes more sense to start thinking about making all RISC-V contributors work together rather than doing everything on each own, which would be much efficient.
[1] https://fedoraproject.org/wiki/Architectures/RISC-V/Allwinner
Rich.
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
Well, one big thing is that it's been a while since we had any secondary arches and it's unclear how they would work today. In the distant past secondary arches had their own koji and builders and composes and releases and used koji-shadow to try and match up with primary koji. This was basically more than a full time job for someone and I am sure koji-shadow has atrophied in recent years, but perhaps at least some subset could be made to work again.
On the other hand we could just add it into primary koji, but then it really really has to keep up or it's going to block everything else.
So, probibly a 'secondary' koji and builders to start with to bootstrap and to gather info on how hard it is to keep up and good emulation is would be worthwhile, but it's gonna need some dedicated work.
Perhaps we could get a up to date status report from folks working on this, answering such questions as:
- How good is emulation support
- What would it take to keep up with the other arches? Is that possible?
- What device(s) would we want to target and could we get sufficent
numbers of them for QA and devel folks to debug problems and test?
- Are there folks who can bootstrap/shepard the koji shadowing process?
I think RISC-V is pretty exciting, and I am happy to help as much as I can with adding it in. I think there's likely to be a lot of interest/growth in coming years for it.
kevin
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On 04 Oct 2021 21:39, Richard W.M. Jones wrote:
Personally speaking I think the real barrier is someone with a large colourful hat putting up the money to hire a full time developer to work on the project.
Rich.
Big ol' +1 to that.
On Mon, Oct 04, 2021 at 01:03:27PM -0400, Matthew Miller wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
The hardware situation is actually not terrible now (albeit still very expensive). HiFive Unmatched is a very solid platform that supports mini ITX, a decent amount of RAM, M.2 SSD, AMD Radeon GPU. You can build a reasonable desktop-style machine with one of the boards.
For servers there are several missing components:
- Any kind of BMC or remote management. You can add a Raspberry Pi-based KVM hat (assuming you're happy with that incongruity)
- UEFI, although it's coming and u-boot works OK.
Qemu also works very well if you don't want or more likely can't afford the hardware.
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
I think we have most things covered. Hardware doesn't support virtualization but Qemu does. Hardware doesn't support various desirable features like the vector extension. Also it'd be nice to have a JDK port.
Rich.
On Mon, Oct 4, 2021 at 12:03 PM Matthew Miller mattdm@fedoraproject.org wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
Kernel is still an issue, in that the changes to support RISC-V have not been merged yet, though I expect that is not a massive undertaking.
Justin
On 06 Oct 2021 10:17, Justin Forbes wrote:
On Mon, Oct 4, 2021 at 12:03 PM Matthew Miller mattdm@fedoraproject.org wrote:
Hi all! I just got back from Open Source Summit, several of the talks I found interesting were on RISC-V -- a high-level one about the organizational structure, and Drew Fustini's more technical talk.
In that, he noted that there's a Fedora build *, but it isn't an official Fedora arch. As I understand it, the major infrastructure blocker is simply that there isn't server-class hardware (let alone hardware that will build fast enough that it isn't a frustrating bottleneck).
So, one question is: if we used, say, ARM or x86_64 Amazon cloud instances as builders, could we build fast enough under QEMU emulation to work? We have a nice early advantage, but if we don't keep moving, we'll lose that.
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet? Is there a big enough risc-v team to respond to arch-specific build failures? And, do we have enough people to do QA around release time?
Kernel is still an issue, in that the changes to support RISC-V have not been merged yet, though I expect that is not a massive undertaking.
Justin
Not been merged? Or just not turned on in the config?
I posted the same article on Fedora Discussion.[1] However let me share it again on the devel@ to tell it to many people.
This is interesting news about RISC-V this week. Perhaps, it’s time to prepare to add the RISC-V CPU to the Koji build system?
Google wants RISC-V to be a “tier-1” Android architecture https://arstechnica.com/gadgets/2023/01/google-announces-official-android-su...
Arm has become an unstable, volatile business partner
[1] https://discussion.fedoraproject.org/t/risc-v-server-spec-for-fedora-koji-sy...
On 1/6/23 16:19, Jun Aruga (he / him) wrote:
I posted the same article on Fedora Discussion.[1] However let me share it again on the devel@ to tell it to many people.
This is interesting news about RISC-V this week. Perhaps, it’s time to prepare to add the RISC-V CPU to the Koji build system?
I think the big question in this space is access to suitable hardware. What's out there right now is scarce and woefully under-powered.
My plan is to set up and maintain a riscv64 shadow builder as soon as possible after our Veyron-v1 bring-up. Ideally that will help forge a path to official Fedora builds as hardware availability expands.
jeff
On Sat, Jan 7, 2023 at 2:42 AM Jeff Law jeffreyalaw@gmail.com wrote:
On 1/6/23 16:19, Jun Aruga (he / him) wrote:
I posted the same article on Fedora Discussion.[1] However let me share it again on the devel@ to tell it to many people.
This is interesting news about RISC-V this week. Perhaps, it’s time to prepare to add the RISC-V CPU to the Koji build system?
I think the big question in this space is access to suitable hardware. What's out there right now is scarce and woefully under-powered.
Summary from multi-year discussions/feedback on this: - We don't have proper hardware to put into the data center that holds servers used by Fedora infrastructure. - Not enough single and multi thread performance to avoid large impact to Fedora development.
Other than that Fedora/RISCV 37 is the first Fedora version to be built fully natively using 20+ SiFive HiFive Unmatched boards. On a good day we can keep up (if the builds aren't too large, e.g. GCC). We don't really run Bodhi thus once package is built it's immediately available. We run a very minimal setup right now (ideas to expand that).
Another news is that Fedora/RISCV Koji server ( http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned server. We are about to start work on Fedora 38/Rawhide.
2023 is potentially a transition year. Ventana Veyron V1 Development Platform looks good (I assume it has BMC). SOPHGO SG2042 should also show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not yet convinced about their upstream support efforts (TBD).
If that's not available with proper support or/and in proper quantities the plan would be to continue expanding Fedora/RISCV builders with JH7110 (upstreaming ongoing for kernel/OpenSBI/U-Boot). Mainly PINE64 Star64 and VisionFive V2 boards. SiFive/Intel Pro P550 (Horse Creek) and that also has OCP DC-SCM for BMC card. Sipeed TH1520 based cluster board (7 modules, BMC incl, T-HEAD C910, up to 16G of RAM or 4G/core).
My plan is to set up and maintain a riscv64 shadow builder as soon as possible after our Veyron-v1 bring-up. Ideally that will help forge a path to official Fedora builds as hardware availability expands.
If there is away to acquire Veyron V1 Development Platform I would be interested to talk, and figure out what that would take. Such hardware would be a game charger, and I do trust Ventana regarding upstream support :)
Cheers, david
jeff _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Sun, Jan 8, 2023 at 2:28 AM Jeff Law jlaw@ventanamicro.com wrote:
On 1/6/23 23:41, David Abdurachmanov wrote:
Summary from multi-year discussions/feedback on this:
- We don't have proper hardware to put into the data center that holds
servers used by Fedora infrastructure.
Right. dev boards are not the solution here. It's got to be something that can be racked and with enough performance to matter.
- Not enough single and multi thread performance to avoid large impact
to Fedora development.
Agreed. Returning to a situation like we had with armv7 isn't acceptable IMHO.
Other than that Fedora/RISCV 37 is the first Fedora version to be built fully natively using 20+ SiFive HiFive Unmatched boards. On a good day we can keep up (if the builds aren't too large, e.g. GCC). We don't really run Bodhi thus once package is built it's immediately available. We run a very minimal setup right now (ideas to expand that).
It's fantastic we've got that far. But clearly it's not viable long term.
Agreed. We have been cooking Fedora/RISCV since 2016, but we really cannot move forward until the proper hardware (and things around it) becomes available.
Another news is that Fedora/RISCV Koji server ( http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned server. We are about to start work on Fedora 38/Rawhide.
Excellent. I'll have to update my chroots and containers as the F38 bits start appearing.
I am still tweaking the server configuration, but I should be ready for mass building soonish. I might want to wait for GCC 13 to land in Rawhide, which should happen soon (I think).
2023 is potentially a transition year. Ventana Veyron V1 Development Platform looks good (I assume it has BMC). SOPHGO SG2042 should also show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not yet convinced about their upstream support efforts (TBD).
Yes Veyron-v1 will have a BMC and will be rackable. I have no significant insight into the T-HEAD efforts other than they do work a fair amount with VRULL on compiler and related technology.
I noticed that VRULL has been involved with T-HEAD on GCC and potentially kernel side for a few months now. This makes them much more optimistic about their SoC/HW support in general.
If there is away to acquire Veyron V1 Development Platform I would be interested to talk, and figure out what that would take. Such hardware would be a game charger, and I do trust Ventana regarding upstream support :)
I'll be pushing to make systems available to Fedora and the GCC farm, but in general Ventana is more aligned towards Ubuntu. My goal is to have Fedora and Ubuntu on equal footing as quickly as possible.
We have been trying to get stuff into GCC Compiler Farm for years now. There are a couple of boards IIRC. There are additional requirements on the software side (well, distributions) that we couldn't provide for quite some time.
I do know rackable systems will be limited -- there's one particular component needed on the rackable systems that is in very short supply. We've got multiple orders in, but quantities are limited and lead times are absolutely insane.
FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G swap. The older machines had 8G/core setup. There seems to be 8 (?) servers with 80 cores, but so far only 40-50 builders are enabled (no overcommitting on CPU as that's not a great idea [based on my own experience]).
I expect Veyron V1 to deliver a decent single and multi thread performance, but we will need a lot of them. Probably 20-25 systems if we assume a similar configuration as aarch64 builders (8-core, 32-64G of RAM, 100-200G for storage). RAM and storage are cheap, but systems will continue to be a problem. If we could somehow get to this level we could stop investing into SBCs as they are stop-gap solutions for builders.
Based on some guesses there isn't a lot of time either. I would love to bootstrap CentOS Stream 10. It would be nice to have Fedora + riscv64 in a good shape before that happens, but probably unrealistic.
Cheers, david
On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Sun, Jan 8, 2023 at 2:28 AM Jeff Law jlaw@ventanamicro.com wrote:
On 1/6/23 23:41, David Abdurachmanov wrote:
Summary from multi-year discussions/feedback on this:
- We don't have proper hardware to put into the data center that holds
servers used by Fedora infrastructure.
Right. dev boards are not the solution here. It's got to be something that can be racked and with enough performance to matter.
- Not enough single and multi thread performance to avoid large impact
to Fedora development.
Agreed. Returning to a situation like we had with armv7 isn't acceptable IMHO.
Other than that Fedora/RISCV 37 is the first Fedora version to be built fully natively using 20+ SiFive HiFive Unmatched boards. On a good day we can keep up (if the builds aren't too large, e.g. GCC). We don't really run Bodhi thus once package is built it's immediately available. We run a very minimal setup right now (ideas to expand that).
It's fantastic we've got that far. But clearly it's not viable long term.
Agreed. We have been cooking Fedora/RISCV since 2016, but we really cannot move forward until the proper hardware (and things around it) becomes available.
Another news is that Fedora/RISCV Koji server ( http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned server. We are about to start work on Fedora 38/Rawhide.
Excellent. I'll have to update my chroots and containers as the F38 bits start appearing.
I am still tweaking the server configuration, but I should be ready for mass building soonish. I might want to wait for GCC 13 to land in Rawhide, which should happen soon (I think).
2023 is potentially a transition year. Ventana Veyron V1 Development Platform looks good (I assume it has BMC). SOPHGO SG2042 should also show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not yet convinced about their upstream support efforts (TBD).
Yes Veyron-v1 will have a BMC and will be rackable. I have no significant insight into the T-HEAD efforts other than they do work a fair amount with VRULL on compiler and related technology.
I noticed that VRULL has been involved with T-HEAD on GCC and potentially kernel side for a few months now. This makes them much more optimistic about their SoC/HW support in general.
If there is away to acquire Veyron V1 Development Platform I would be interested to talk, and figure out what that would take. Such hardware would be a game charger, and I do trust Ventana regarding upstream support :)
I'll be pushing to make systems available to Fedora and the GCC farm, but in general Ventana is more aligned towards Ubuntu. My goal is to have Fedora and Ubuntu on equal footing as quickly as possible.
We have been trying to get stuff into GCC Compiler Farm for years now. There are a couple of boards IIRC. There are additional requirements on the software side (well, distributions) that we couldn't provide for quite some time.
I do know rackable systems will be limited -- there's one particular component needed on the rackable systems that is in very short supply. We've got multiple orders in, but quantities are limited and lead times are absolutely insane.
FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G swap. The older machines had 8G/core setup. There seems to be 8 (?) servers with 80 cores, but so far only 40-50 builders are enabled (no overcommitting on CPU as that's not a great idea [based on my own experience]).
I expect Veyron V1 to deliver a decent single and multi thread performance, but we will need a lot of them. Probably 20-25 systems if we assume a similar configuration as aarch64 builders (8-core, 32-64G of RAM, 100-200G for storage). RAM and storage are cheap, but systems will continue to be a problem. If we could somehow get to this level we could stop investing into SBCs as they are stop-gap solutions for builders.
Based on some guesses there isn't a lot of time either. I would love to bootstrap CentOS Stream 10. It would be nice to have Fedora + riscv64 in a good shape before that happens, but probably unrealistic.
It is very unlikely that CentOS Stream 10 will include RISC-V as a fully included architecture. Perhaps via a CentOS Stream SIG.
josh
On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Sun, Jan 8, 2023 at 2:28 AM Jeff Law jlaw@ventanamicro.com wrote:
On 1/6/23 23:41, David Abdurachmanov wrote:
Summary from multi-year discussions/feedback on this:
- We don't have proper hardware to put into the data center that holds
servers used by Fedora infrastructure.
Right. dev boards are not the solution here. It's got to be something that can be racked and with enough performance to matter.
- Not enough single and multi thread performance to avoid large impact
to Fedora development.
Agreed. Returning to a situation like we had with armv7 isn't acceptable IMHO.
Other than that Fedora/RISCV 37 is the first Fedora version to be built fully natively using 20+ SiFive HiFive Unmatched boards. On a good day we can keep up (if the builds aren't too large, e.g. GCC). We don't really run Bodhi thus once package is built it's immediately available. We run a very minimal setup right now (ideas to expand that).
It's fantastic we've got that far. But clearly it's not viable long term.
Agreed. We have been cooking Fedora/RISCV since 2016, but we really cannot move forward until the proper hardware (and things around it) becomes available.
Another news is that Fedora/RISCV Koji server ( http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned server. We are about to start work on Fedora 38/Rawhide.
Excellent. I'll have to update my chroots and containers as the F38 bits start appearing.
I am still tweaking the server configuration, but I should be ready for mass building soonish. I might want to wait for GCC 13 to land in Rawhide, which should happen soon (I think).
2023 is potentially a transition year. Ventana Veyron V1 Development Platform looks good (I assume it has BMC). SOPHGO SG2042 should also show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not yet convinced about their upstream support efforts (TBD).
Yes Veyron-v1 will have a BMC and will be rackable. I have no significant insight into the T-HEAD efforts other than they do work a fair amount with VRULL on compiler and related technology.
I noticed that VRULL has been involved with T-HEAD on GCC and potentially kernel side for a few months now. This makes them much more optimistic about their SoC/HW support in general.
If there is away to acquire Veyron V1 Development Platform I would be interested to talk, and figure out what that would take. Such hardware would be a game charger, and I do trust Ventana regarding upstream support :)
I'll be pushing to make systems available to Fedora and the GCC farm, but in general Ventana is more aligned towards Ubuntu. My goal is to have Fedora and Ubuntu on equal footing as quickly as possible.
We have been trying to get stuff into GCC Compiler Farm for years now. There are a couple of boards IIRC. There are additional requirements on the software side (well, distributions) that we couldn't provide for quite some time.
I do know rackable systems will be limited -- there's one particular component needed on the rackable systems that is in very short supply. We've got multiple orders in, but quantities are limited and lead times are absolutely insane.
FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G swap. The older machines had 8G/core setup. There seems to be 8 (?) servers with 80 cores, but so far only 40-50 builders are enabled (no overcommitting on CPU as that's not a great idea [based on my own experience]).
I expect Veyron V1 to deliver a decent single and multi thread performance, but we will need a lot of them. Probably 20-25 systems if we assume a similar configuration as aarch64 builders (8-core, 32-64G of RAM, 100-200G for storage). RAM and storage are cheap, but systems will continue to be a problem. If we could somehow get to this level we could stop investing into SBCs as they are stop-gap solutions for builders.
Based on some guesses there isn't a lot of time either. I would love to bootstrap CentOS Stream 10. It would be nice to have Fedora + riscv64 in a good shape before that happens, but probably unrealistic.
It is very unlikely that CentOS Stream 10 will include RISC-V as a fully included architecture. Perhaps via a CentOS Stream SIG.
I believe that was the implication in the first place, hence mentioning CentOS Stream rather than RHEL.
The Alternative Architectures SIG in CentOS would be where this would happen. But the work needs to be done in Fedora first.
-- 真実はいつも一つ!/ Always, there's only one truth!
On 1/9/23 07:14, Neal Gompa wrote:
It is very unlikely that CentOS Stream 10 will include RISC-V as a fully included architecture. Perhaps via a CentOS Stream SIG.
I believe that was the implication in the first place, hence mentioning CentOS Stream rather than RHEL.
The Alternative Architectures SIG in CentOS would be where this would happen. But the work needs to be done in Fedora first.
Hard to see a path for CentOS and certainly not RHEL until after Fedora is in better shape. Even then ISTM we need pull from sites looking to deploy this stuff at scale.
jeff
On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Sun, Jan 8, 2023 at 2:28 AM Jeff Law jlaw@ventanamicro.com wrote:
On 1/6/23 23:41, David Abdurachmanov wrote:
Summary from multi-year discussions/feedback on this:
- We don't have proper hardware to put into the data center that holds
servers used by Fedora infrastructure.
Right. dev boards are not the solution here. It's got to be something that can be racked and with enough performance to matter.
- Not enough single and multi thread performance to avoid large impact
to Fedora development.
Agreed. Returning to a situation like we had with armv7 isn't acceptable IMHO.
Other than that Fedora/RISCV 37 is the first Fedora version to be built fully natively using 20+ SiFive HiFive Unmatched boards. On a good day we can keep up (if the builds aren't too large, e.g. GCC). We don't really run Bodhi thus once package is built it's immediately available. We run a very minimal setup right now (ideas to expand that).
It's fantastic we've got that far. But clearly it's not viable long term.
Agreed. We have been cooking Fedora/RISCV since 2016, but we really cannot move forward until the proper hardware (and things around it) becomes available.
Another news is that Fedora/RISCV Koji server ( http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned server. We are about to start work on Fedora 38/Rawhide.
Excellent. I'll have to update my chroots and containers as the F38 bits start appearing.
I am still tweaking the server configuration, but I should be ready for mass building soonish. I might want to wait for GCC 13 to land in Rawhide, which should happen soon (I think).
2023 is potentially a transition year. Ventana Veyron V1 Development Platform looks good (I assume it has BMC). SOPHGO SG2042 should also show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not yet convinced about their upstream support efforts (TBD).
Yes Veyron-v1 will have a BMC and will be rackable. I have no significant insight into the T-HEAD efforts other than they do work a fair amount with VRULL on compiler and related technology.
I noticed that VRULL has been involved with T-HEAD on GCC and potentially kernel side for a few months now. This makes them much more optimistic about their SoC/HW support in general.
If there is away to acquire Veyron V1 Development Platform I would be interested to talk, and figure out what that would take. Such hardware would be a game charger, and I do trust Ventana regarding upstream support :)
I'll be pushing to make systems available to Fedora and the GCC farm, but in general Ventana is more aligned towards Ubuntu. My goal is to have Fedora and Ubuntu on equal footing as quickly as possible.
We have been trying to get stuff into GCC Compiler Farm for years now. There are a couple of boards IIRC. There are additional requirements on the software side (well, distributions) that we couldn't provide for quite some time.
I do know rackable systems will be limited -- there's one particular component needed on the rackable systems that is in very short supply. We've got multiple orders in, but quantities are limited and lead times are absolutely insane.
FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G swap. The older machines had 8G/core setup. There seems to be 8 (?) servers with 80 cores, but so far only 40-50 builders are enabled (no overcommitting on CPU as that's not a great idea [based on my own experience]).
I expect Veyron V1 to deliver a decent single and multi thread performance, but we will need a lot of them. Probably 20-25 systems if we assume a similar configuration as aarch64 builders (8-core, 32-64G of RAM, 100-200G for storage). RAM and storage are cheap, but systems will continue to be a problem. If we could somehow get to this level we could stop investing into SBCs as they are stop-gap solutions for builders.
Based on some guesses there isn't a lot of time either. I would love to bootstrap CentOS Stream 10. It would be nice to have Fedora + riscv64 in a good shape before that happens, but probably unrealistic.
It is very unlikely that CentOS Stream 10 will include RISC-V as a fully included architecture. Perhaps via a CentOS Stream SIG.
I believe that was the implication in the first place, hence mentioning CentOS Stream rather than RHEL.
Better to be clear about direction up-front, so thanks for clarifying. "CentOS Stream" is used as both an umbrella term and a specific OS and it causes confusion sometimes.
The Alternative Architectures SIG in CentOS would be where this would happen. But the work needs to be done in Fedora first.
Alternative Arches would totally make sense to me. And agreed Fedora needs to land first.
josh
On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Sun, Jan 8, 2023 at 2:28 AM Jeff Law jlaw@ventanamicro.com wrote:
On 1/6/23 23:41, David Abdurachmanov wrote:
Summary from multi-year discussions/feedback on this:
- We don't have proper hardware to put into the data center that holds
servers used by Fedora infrastructure.
Right. dev boards are not the solution here. It's got to be something that can be racked and with enough performance to matter.
- Not enough single and multi thread performance to avoid large impact
to Fedora development.
Agreed. Returning to a situation like we had with armv7 isn't acceptable IMHO.
Other than that Fedora/RISCV 37 is the first Fedora version to be built fully natively using 20+ SiFive HiFive Unmatched boards. On a good day we can keep up (if the builds aren't too large, e.g. GCC). We don't really run Bodhi thus once package is built it's immediately available. We run a very minimal setup right now (ideas to expand that).
It's fantastic we've got that far. But clearly it's not viable long term.
Agreed. We have been cooking Fedora/RISCV since 2016, but we really cannot move forward until the proper hardware (and things around it) becomes available.
Another news is that Fedora/RISCV Koji server ( http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned server. We are about to start work on Fedora 38/Rawhide.
Excellent. I'll have to update my chroots and containers as the F38 bits start appearing.
I am still tweaking the server configuration, but I should be ready for mass building soonish. I might want to wait for GCC 13 to land in Rawhide, which should happen soon (I think).
2023 is potentially a transition year. Ventana Veyron V1 Development Platform looks good (I assume it has BMC). SOPHGO SG2042 should also show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not yet convinced about their upstream support efforts (TBD).
Yes Veyron-v1 will have a BMC and will be rackable. I have no significant insight into the T-HEAD efforts other than they do work a fair amount with VRULL on compiler and related technology.
I noticed that VRULL has been involved with T-HEAD on GCC and potentially kernel side for a few months now. This makes them much more optimistic about their SoC/HW support in general.
If there is away to acquire Veyron V1 Development Platform I would be interested to talk, and figure out what that would take. Such hardware would be a game charger, and I do trust Ventana regarding upstream support :)
I'll be pushing to make systems available to Fedora and the GCC farm, but in general Ventana is more aligned towards Ubuntu. My goal is to have Fedora and Ubuntu on equal footing as quickly as possible.
We have been trying to get stuff into GCC Compiler Farm for years now. There are a couple of boards IIRC. There are additional requirements on the software side (well, distributions) that we couldn't provide for quite some time.
I do know rackable systems will be limited -- there's one particular component needed on the rackable systems that is in very short supply. We've got multiple orders in, but quantities are limited and lead times are absolutely insane.
FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G swap. The older machines had 8G/core setup. There seems to be 8 (?) servers with 80 cores, but so far only 40-50 builders are enabled (no overcommitting on CPU as that's not a great idea [based on my own experience]).
I expect Veyron V1 to deliver a decent single and multi thread performance, but we will need a lot of them. Probably 20-25 systems if we assume a similar configuration as aarch64 builders (8-core, 32-64G of RAM, 100-200G for storage). RAM and storage are cheap, but systems will continue to be a problem. If we could somehow get to this level we could stop investing into SBCs as they are stop-gap solutions for builders.
Based on some guesses there isn't a lot of time either. I would love to bootstrap CentOS Stream 10. It would be nice to have Fedora + riscv64 in a good shape before that happens, but probably unrealistic.
It is very unlikely that CentOS Stream 10 will include RISC-V as a fully included architecture. Perhaps via a CentOS Stream SIG.
I believe that was the implication in the first place, hence mentioning CentOS Stream rather than RHEL.
Better to be clear about direction up-front, so thanks for clarifying. "CentOS Stream" is used as both an umbrella term and a specific OS and it causes confusion sometimes.
Yes, that would be CentOS Stream SIG. There is interest in this.
The Alternative Architectures SIG in CentOS would be where this would happen. But the work needs to be done in Fedora first.
Alternative Arches would totally make sense to me. And agreed Fedora needs to land first.
Agreed. Doing some prediction based on the history, we have 2-3 Fedora releases before CentOS Stream 10 might happen. Without EPEL CentOS Stream (package wise) is not large. Of course the majority (if not all) users consider EPEL an important part of the experience.
Cheers, david
josh _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Sun, Jan 8, 2023 at 2:28 AM Jeff Law jlaw@ventanamicro.com wrote:
On 1/6/23 23:41, David Abdurachmanov wrote: > > Summary from multi-year discussions/feedback on this: > - We don't have proper hardware to put into the data center that holds > servers used by Fedora infrastructure. Right. dev boards are not the solution here. It's got to be something that can be racked and with enough performance to matter.
> - Not enough single and multi thread performance to avoid large impact > to Fedora development. Agreed. Returning to a situation like we had with armv7 isn't acceptable IMHO.
> > Other than that Fedora/RISCV 37 is the first Fedora version to be > built fully natively using 20+ SiFive HiFive Unmatched boards. On a > good day we can keep up (if the builds aren't too large, e.g. GCC). We > don't really run Bodhi thus once package is built it's immediately > available. We run a very minimal setup right now (ideas to expand > that). It's fantastic we've got that far. But clearly it's not viable long term.
Agreed. We have been cooking Fedora/RISCV since 2016, but we really cannot move forward until the proper hardware (and things around it) becomes available.
> Another news is that Fedora/RISCV Koji server ( > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned > server. We are about to start work on Fedora 38/Rawhide. Excellent. I'll have to update my chroots and containers as the F38 bits start appearing.
I am still tweaking the server configuration, but I should be ready for mass building soonish. I might want to wait for GCC 13 to land in Rawhide, which should happen soon (I think).
> > 2023 is potentially a transition year. Ventana Veyron V1 Development > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not > yet convinced about their upstream support efforts (TBD). Yes Veyron-v1 will have a BMC and will be rackable. I have no significant insight into the T-HEAD efforts other than they do work a fair amount with VRULL on compiler and related technology.
I noticed that VRULL has been involved with T-HEAD on GCC and potentially kernel side for a few months now. This makes them much more optimistic about their SoC/HW support in general.
> > If there is away to acquire Veyron V1 Development Platform I would be > interested to talk, and figure out what that would take. Such hardware > would be a game charger, and I do trust Ventana regarding upstream > support :) I'll be pushing to make systems available to Fedora and the GCC farm, but in general Ventana is more aligned towards Ubuntu. My goal is to have Fedora and Ubuntu on equal footing as quickly as possible.
We have been trying to get stuff into GCC Compiler Farm for years now. There are a couple of boards IIRC. There are additional requirements on the software side (well, distributions) that we couldn't provide for quite some time.
I do know rackable systems will be limited -- there's one particular component needed on the rackable systems that is in very short supply. We've got multiple orders in, but quantities are limited and lead times are absolutely insane.
FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G swap. The older machines had 8G/core setup. There seems to be 8 (?) servers with 80 cores, but so far only 40-50 builders are enabled (no overcommitting on CPU as that's not a great idea [based on my own experience]).
I expect Veyron V1 to deliver a decent single and multi thread performance, but we will need a lot of them. Probably 20-25 systems if we assume a similar configuration as aarch64 builders (8-core, 32-64G of RAM, 100-200G for storage). RAM and storage are cheap, but systems will continue to be a problem. If we could somehow get to this level we could stop investing into SBCs as they are stop-gap solutions for builders.
Based on some guesses there isn't a lot of time either. I would love to bootstrap CentOS Stream 10. It would be nice to have Fedora + riscv64 in a good shape before that happens, but probably unrealistic.
It is very unlikely that CentOS Stream 10 will include RISC-V as a fully included architecture. Perhaps via a CentOS Stream SIG.
I believe that was the implication in the first place, hence mentioning CentOS Stream rather than RHEL.
Better to be clear about direction up-front, so thanks for clarifying. "CentOS Stream" is used as both an umbrella term and a specific OS and it causes confusion sometimes.
Yes, that would be CentOS Stream SIG. There is interest in this.
The Alternative Architectures SIG in CentOS would be where this would happen. But the work needs to be done in Fedora first.
Alternative Arches would totally make sense to me. And agreed Fedora needs to land first.
Agreed. Doing some prediction based on the history, we have 2-3 Fedora releases before CentOS Stream 10 might happen. Without EPEL CentOS Stream (package wise) is not large. Of course the majority (if not all) users consider EPEL an important part of the experience.
There is precedent for the AltArch SIG to rebuild EPEL for an alternative architecture. I think the way it would be done today would necessarily need to be different from how it was done in the times we build 32-bit x86 and ARM support with CentOS 7, but it's absolutely doable.
-- 真実はいつも一つ!/ Always, there's only one truth!
On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer jwboyer@fedoraproject.org wrote:
On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer jwboyer@fedoraproject.org wrote:
On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov david.abdurachmanov@gmail.com wrote:
On Sun, Jan 8, 2023 at 2:28 AM Jeff Law jlaw@ventanamicro.com wrote:
On 1/6/23 23:41, David Abdurachmanov wrote: > > Summary from multi-year discussions/feedback on this: > - We don't have proper hardware to put into the data center that holds > servers used by Fedora infrastructure. Right. dev boards are not the solution here. It's got to be something that can be racked and with enough performance to matter.
> - Not enough single and multi thread performance to avoid large impact > to Fedora development. Agreed. Returning to a situation like we had with armv7 isn't acceptable IMHO.
> > Other than that Fedora/RISCV 37 is the first Fedora version to be > built fully natively using 20+ SiFive HiFive Unmatched boards. On a > good day we can keep up (if the builds aren't too large, e.g. GCC). We > don't really run Bodhi thus once package is built it's immediately > available. We run a very minimal setup right now (ideas to expand > that). It's fantastic we've got that far. But clearly it's not viable long term.
Agreed. We have been cooking Fedora/RISCV since 2016, but we really cannot move forward until the proper hardware (and things around it) becomes available.
> Another news is that Fedora/RISCV Koji server ( > http://fedora.riscv.rocks/koji/ ) just moved into Fedora infra owned > server. We are about to start work on Fedora 38/Rawhide. Excellent. I'll have to update my chroots and containers as the F38 bits start appearing.
I am still tweaking the server configuration, but I should be ready for mass building soonish. I might want to wait for GCC 13 to land in Rawhide, which should happen soon (I think).
> > 2023 is potentially a transition year. Ventana Veyron V1 Development > Platform looks good (I assume it has BMC). SOPHGO SG2042 should also > show up with 64-core @ 2.0GHz (T-HEAD C910) in early 2023 (?) I am not > yet convinced about their upstream support efforts (TBD). Yes Veyron-v1 will have a BMC and will be rackable. I have no significant insight into the T-HEAD efforts other than they do work a fair amount with VRULL on compiler and related technology.
I noticed that VRULL has been involved with T-HEAD on GCC and potentially kernel side for a few months now. This makes them much more optimistic about their SoC/HW support in general.
> > If there is away to acquire Veyron V1 Development Platform I would be > interested to talk, and figure out what that would take. Such hardware > would be a game charger, and I do trust Ventana regarding upstream > support :) I'll be pushing to make systems available to Fedora and the GCC farm, but in general Ventana is more aligned towards Ubuntu. My goal is to have Fedora and Ubuntu on equal footing as quickly as possible.
We have been trying to get stuff into GCC Compiler Farm for years now. There are a couple of boards IIRC. There are additional requirements on the software side (well, distributions) that we couldn't provide for quite some time.
I do know rackable systems will be limited -- there's one particular component needed on the rackable systems that is in very short supply. We've got multiple orders in, but quantities are limited and lead times are absolutely insane.
FYI, I think, the new aarch64 builders are 8 core, 35G RAM and 8G swap. The older machines had 8G/core setup. There seems to be 8 (?) servers with 80 cores, but so far only 40-50 builders are enabled (no overcommitting on CPU as that's not a great idea [based on my own experience]).
I expect Veyron V1 to deliver a decent single and multi thread performance, but we will need a lot of them. Probably 20-25 systems if we assume a similar configuration as aarch64 builders (8-core, 32-64G of RAM, 100-200G for storage). RAM and storage are cheap, but systems will continue to be a problem. If we could somehow get to this level we could stop investing into SBCs as they are stop-gap solutions for builders.
Based on some guesses there isn't a lot of time either. I would love to bootstrap CentOS Stream 10. It would be nice to have Fedora + riscv64 in a good shape before that happens, but probably unrealistic.
It is very unlikely that CentOS Stream 10 will include RISC-V as a fully included architecture. Perhaps via a CentOS Stream SIG.
I believe that was the implication in the first place, hence mentioning CentOS Stream rather than RHEL.
Better to be clear about direction up-front, so thanks for clarifying. "CentOS Stream" is used as both an umbrella term and a specific OS and it causes confusion sometimes.
Yes, that would be CentOS Stream SIG. There is interest in this.
The Alternative Architectures SIG in CentOS would be where this would happen. But the work needs to be done in Fedora first.
Alternative Arches would totally make sense to me. And agreed Fedora needs to land first.
Agreed. Doing some prediction based on the history, we have 2-3 Fedora releases before CentOS Stream 10 might happen.
CentOS Stream 10 is actively in development under the ELN project in Fedora right now. My suggestion would be to just work in Fedora and pay attention to ELN as well if CentOS Stream SIGs, CentOS Stream, and/or RHEL are eventual goals. That is to say, don't try to guess the timing of a new CentOS Stream kicking off, because you'll likely guess incorrectly and there's no reason to with ELN. :)
Without EPEL CentOS Stream (package wise) is not large. Of course the majority (if not all) users consider EPEL an important part of the experience.
ELN Extras also covers at least a subset of what will be the next EPEL.
josh
Hi,
On Monday, 2021-10-04 13:03:27 -0400, Matthew Miller wrote:
But beyond that: What other things might be limits? Are there key bits of the distro which don't build yet?
Fwiw, I learned just yesterday that apparently to stay on the cheap side they underspecified RISC-V FPU to omit some IEEE 754 optional behaviour that would preserve and propagate a quiet NaN's payload in floating point calculations. It may or may not (optionally) be supported on a given RISC-V architecture.
That is a feature LibreOffice Calc makes heavy use of to transport error information in doubles, where without those payload details it would result in just a general NaN error for illegal FP operation.
Some other software may also use NaN payloads (R is mentioned in the IEEE 754 .pdf on NaNs https://grouper.ieee.org/groups/msc/ANSI_IEEE-Std-754-2019/background/nan-pr... ("Known and possible uses of NaN payloads"), and JavaScript NaN-boxing for type of data).
Further pointers in https://bugs.documentfoundation.org/show_bug.cgi?id=152943
Eike
This is exciting news related to the RISC-V ecosystem. I expect that the RISC-V Software Ecosystem (RISE) Project will be a leading organization to help open source projects by providing free RISC-V CI services to them, and sponsoring the free RISC-V SSH servers on the clouds to them. It is like what Works on Arm organization[1] has currently been doing for the Arm ecosystem.
Industry Leaders Launch RISE to Accelerate the Development of Open Source Software for RISC-V https://linuxfoundation.eu/newsroom/rise-project-launches-to-accelerate-deve...
[1] https://www.arm.com/markets/computing-infrastructure/works-on-arm
On Wed, May 31, 2023 at 11:58:57PM +0200, Jun Aruga (he / him) wrote:
This is exciting news related to the RISC-V ecosystem. I expect that the RISC-V Software Ecosystem (RISE) Project will be a leading organization to help open source projects by providing free RISC-V CI services to them, and sponsoring the free RISC-V SSH servers on the clouds to them. It is like what Works on Arm organization[1] has currently been doing for the Arm ecosystem.
Industry Leaders Launch RISE to Accelerate the Development of Open Source Software for RISC-V https://linuxfoundation.eu/newsroom/rise-project-launches-to-accelerate-deve...
[1] https://www.arm.com/markets/computing-infrastructure/works-on-arm
Red Hat is a member. In fact there's an (internal) kick-off meeting for RISE today which I'll be attending.
Rich.
Red Hat is a member. In fact there's an (internal) kick-off meeting for RISE today which I'll be attending.
I saw that Red Hat is a member of the RISE project on the page. And it's really great to see that you will be attending the kick-off meeting. Thank you for that. I am looking forward to seeing your updates about it if you have something to share publicly. It's a great step of the RISC-V to be a first class in Fedora Linux.
-- Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic See https://www.worldtimebuddy.com/czech-republic-prague-to-utc for the timezone.
Can't wait for a risc-v Fedora iso for Workstation! https://fedoraproject.org/workstation/download/ here