Re: RISC-V -- are we ready for more, and what do we need to do it?

[Reon Beon via devel]

>RISE project
https://riseproject.dev/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Reon Beon via devel]

Can't wait for a risc-v Fedora iso for Workstation! 
https://fedoraproject.org/workstation/download/ here
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Jun Aruga (he / him)]

> 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  for
the timezone.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Richard W.M. Jones]

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-development-of-risc-v
> 
> [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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Jun Aruga (he / him)]

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-development-of-risc-v

[1] https://www.arm.com/markets/computing-infrastructure/works-on-arm

-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Eike Rathke]

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-propagation.pdf
("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

-- 
GPG key 0x6A6CD5B765632D3A - 2265 D7F3 A7B0 95CC 3918  630B 6A6C D5B7 6563 2D3A


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Josh Boyer]

On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov
 wrote:
>
> On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer  wrote:
> >
> > On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa  wrote:
> > >
> > > On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer  
> > > wrote:
> > > >
> > > > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> > > >  wrote:
> > > > >
> > > > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  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 

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Neal Gompa]

On Tue, Jan 10, 2023 at 5:11 AM David Abdurachmanov
 wrote:
>
> On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer  wrote:
> >
> > On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa  wrote:
> > >
> > > On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer  
> > > wrote:
> > > >
> > > > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> > > >  wrote:
> > > > >
> > > > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  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 

Re: RISC-V -- are we ready for more, and what do we need to do it?

[David Abdurachmanov]

On Mon, Jan 9, 2023 at 3:22 PM Josh Boyer  wrote:
>
> On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa  wrote:
> >
> > On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer  wrote:
> > >
> > > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> > >  wrote:
> > > >
> > > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  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 

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Josh Boyer]

On Mon, Jan 9, 2023 at 9:15 AM Neal Gompa  wrote:
>
> On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer  wrote:
> >
> > On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
> >  wrote:
> > >
> > > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  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 

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Jeff Law]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Neal Gompa]

On Mon, Jan 9, 2023 at 8:47 AM Josh Boyer  wrote:
>
> On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
>  wrote:
> >
> > On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  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 

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Josh Boyer]

On Sun, Jan 8, 2023 at 2:42 AM David Abdurachmanov
 wrote:
>
> On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[David Abdurachmanov]

On Sun, Jan 8, 2023 at 2:28 AM Jeff Law  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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[David Abdurachmanov]

On Sat, Jan 7, 2023 at 2:42 AM Jeff Law  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-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Jeff Law]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Jun Aruga (he / him)]

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-support-for-risc-v/
> Arm has become an unstable, volatile business partner

[1] 
https://discussion.fedoraproject.org/t/risc-v-server-spec-for-fedora-koji-system-as-builder/35264/7



-- 
Jun | He - Him | Timezone: UTC+1 or 2, Czech Republic
See  for
the timezone.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Al Stone]

On 06 Oct 2021 10:17, Justin Forbes wrote:
> On Mon, Oct 4, 2021 at 12:03 PM 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).
> >
> > 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?

-- 
ciao,
al
---
Al Stone
Principal Software Engineer
Red Hat, Inc.
a...@redhat.com
---
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Al Stone]

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.

-- 
ciao,
al
---
Al Stone
Principal Software Engineer
Red Hat, Inc.
a...@redhat.com
---
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Fu Wei]

Fu Wei  于2021年10月8日周五 上午11:55写道：
>
> Hi All,
>
> Great thanks for your explanation, Zamir.
>
> Zamir SUN  于2021年10月7日周四 下午9:55写道：
> >
> >
> >
> > 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.
>
> the early next spring,  we may can have RISC-V laptop. :-), Hardware
> won't be a problem anymore
>
> > >
> > > 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.
>
> We are NOT ONLY working on D1, but also continually release Fedora
> Image for StarFive Soc, currently JH7100, will focus on JH7110 later.
>
> https://fedora.starfivetech.com/pub/downloads/BeagleV-release/
>
> we have several Koji systems can be used :
> https://koji.oepkgs.net/koji/   (we will start to use it to build all
> the Fedora packages later)
> https://openkoji.iscas.ac.cn/koji  (Our main playground )
> https://fedora.starfivetech.com/koji (StarFive koji system for Fedora on JH 
> Soc)
>
> Our extra REPO for fedora RISC-V:
> https://repo.oepkgs.net/people/extra-repos/rv64-ext-repo/
>
> for now , I am also working upstream opensbi/uboot/linux kernel
> patches for RISC-V
>
>
> > >
> > >>> 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.
>
> yes, that could work, if we have more then 100 builder( 4~9-core ,
> 32GB) on the cloud,
> that would be enough, I think
>
> > >>>
> > >>> 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?
>
> QA is a problem. I and my colleagues can work on engineering  side,
> but we also need QE/QA.
>
> > >>
> > >> 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.
>
> any other info you need , other than the koji info above
>
> > >>
> > >> Perhaps we could get a up to date status report from folks working on
> > >> this, answering such questions as:
> > >>
> > >> * How good is emulation support
>
> Good enough as builders :-) please check our kojis in China
>
> > >> * What would it 

Re: RISC-V -- are we ready for more, and what do we need to do it?

[David Abdurachmanov]

On Thu, Oct 7, 2021 at 1:30 AM Neal Gompa  wrote:
>
> On Wed, Oct 6, 2021 at 1:50 PM Josh Stone  wrote:
> >
> > On 10/4/21 12:12 PM, Neal Gompa wrote:
> > > On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi  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-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Zamir SUN]

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-le...@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





--
Zamir SUN
GPG : 1D86 6D4A 49CE 4BBD 72CF FCF5 D856 6E11 F2A0 525E
Want to know more about Fedora?
Visit https://fedoraproject.org/wiki/
Ready to contribute? See https://whatcanidoforfedora.org/
想了解更多中文资讯，访问 https://zh.fedoracommunity.org/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Neal Gompa]

On Wed, Oct 6, 2021 at 1:50 PM Josh Stone  wrote:
>
> On 10/4/21 12:12 PM, Neal Gompa wrote:
> > On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi  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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Richard W.M. Jones]

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  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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Matthew Miller]

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.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Josh Stone]

On 10/4/21 12:12 PM, Neal Gompa wrote:
> On Mon, Oct 4, 2021 at 3:07 PM Kevin Fenzi  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?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Justin Forbes]

On Mon, Oct 4, 2021 at 12:03 PM 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).
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[David Abdurachmanov]

On Mon, Oct 4, 2021 at 10:13 PM Neal Gompa  wrote:
>
> On Mon, Oct 4, 2021 at 3:07 PM 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?
> >
> > > 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-le...@lists.fedoraproject.org
> Fedora 

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Matthew Miller]

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.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Leigh Scott]

> On Mon, Oct 4, 2021 at 7:04 PM Matthew Miller  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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Luna Jernberg]

https://www.opensourcevoices.org/20

On Mon, Oct 4, 2021 at 10:47 PM Dominik 'Rathann' Mierzejewski <
domi...@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-le...@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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Dominik 'Rathann' Mierzejewski]

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-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Richard W.M. Jones]

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-le...@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


-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Richard W.M. Jones]

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.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Neal Gompa]

On Mon, Oct 4, 2021 at 3:07 PM 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?
>
> > 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?



-- 
真実はいつも一つ！/ Always, there's only one truth!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Kevin Fenzi]

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[linux guy]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Neal Gompa]

On Mon, Oct 4, 2021 at 1:35 PM Fabio Valentini  wrote:
>
> On Mon, Oct 4, 2021 at 7:04 PM 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).
> >
> > 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!
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[Fabio Valentini]

On Mon, Oct 4, 2021 at 7:04 PM 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).
>
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

Re: RISC-V -- are we ready for more, and what do we need to do it?

[JT]

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 
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?
>
>
>
> * see http://fedora.riscv.rocks/koji/
> --
> Matthew Miller
> 
> Fedora Project Leader
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

RISC-V -- are we ready for more, and what do we need to do it?

[Matthew Miller]

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/
-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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