Procedure for submitting RISC-V based BSP to Newlib

Procedure for submitting RISC-V based BSP to Newlib

[Bandhav Veluri]

Hi,

In our research group at University of Washington, we developed a generic
riscv BSP with integrated file-system that can support file i/o without the
need for any i/o proxying mechanism. What would be the appropriate place to
submit a pull request for our BSP? I'm uncertain because the
riscv-gnu-toolchain seem to use a forked copy of newlib called riscv-newlib.

Is there a way to upstream our work in a way that riscv-gnu-toolchain could
provide an option to install the toolchain with our BSP?

Thanks,
Bandhav

Re: Procedure for submitting RISC-V based BSP to Newlib

[Prof. Michael Taylor]

A little more on this —

1. It does this by supporting a miniature DRAM-based file system.

2. We have targeted RISC-V, but it is not necessarily RISC-V specific. It
could work with any architecture.

3. It seems to me that there are two separate issues; one is upstreaming to
newlib, and the other is updating RISC-V infrastructure to be able to
select this BSP.

Michael Taylor
Professor
University of Washington

On Wed, Jul 24, 2019 at 12:22 AM Bandhav Veluri <bandhav@uw.edu> wrote:

> Hi,
>
> In our research group at University of Washington, we developed a generic
> riscv BSP with integrated file-system that can support file i/o without the
> need for any i/o proxying mechanism. What would be the appropriate place to
> submit a pull request for our BSP? I'm uncertain because the
> riscv-gnu-toolchain seem to use a forked copy of newlib called riscv-newlib.
>
> Is there a way to upstream our work in a way that riscv-gnu-toolchain
> could provide an option to install the toolchain with our BSP?
>
> Thanks,
> Bandhav
>
-- 
Apologies for all typos. Message sent by combination of an approximate
neural network and a smartphone.

Re: Procedure for submitting RISC-V based BSP to Newlib

[Kito Cheng]

Hi Bandhav, Michael:

riscv-newlib in riscv-gnu-toolchain basically won't modify anything if
possible, it just kind of buffer, hold some un-upstreamed patches, and
will going to upstream eventually, it's also a place to report RISC-V
specific bug.

So the newlib part I think you could submit patches to this mailing
list directly or send a pull request on riscv-newlib is fine.
And riscv-gnu-toolchain part you could try to fork it first, and might
send pull request on gitthub to start further discussion about how to
integration.

:)

On Wed, Jul 24, 2019 at 9:10 PM Prof. Michael Taylor
<prof.taylor@gmail.com> wrote:
>
> A little more on this —
>
> 1. It does this by supporting a miniature DRAM-based file system.
>
> 2. We have targeted RISC-V, but it is not necessarily RISC-V specific. It
> could work with any architecture.
>
> 3. It seems to me that there are two separate issues; one is upstreaming to
> newlib, and the other is updating RISC-V infrastructure to be able to
> select this BSP.
>
> Michael Taylor
> Professor
> University of Washington
>
> On Wed, Jul 24, 2019 at 12:22 AM Bandhav Veluri <bandhav@uw.edu> wrote:
>
> > Hi,
> >
> > In our research group at University of Washington, we developed a generic
> > riscv BSP with integrated file-system that can support file i/o without the
> > need for any i/o proxying mechanism. What would be the appropriate place to
> > submit a pull request for our BSP? I'm uncertain because the
> > riscv-gnu-toolchain seem to use a forked copy of newlib called riscv-newlib.
> >
> > Is there a way to upstream our work in a way that riscv-gnu-toolchain
> > could provide an option to install the toolchain with our BSP?
> >
> > Thanks,
> > Bandhav
> >
> --
> Apologies for all typos. Message sent by combination of an approximate
> neural network and a smartphone.

Re: Procedure for submitting RISC-V based BSP to Newlib

[Jim Wilson]

On Wed, Jul 24, 2019 at 9:20 AM Kito Cheng <kito.cheng@gmail.com> wrote:
> riscv-newlib in riscv-gnu-toolchain basically won't modify anything if
> possible, it just kind of buffer, hold some un-upstreamed patches, and
> will going to upstream eventually, it's also a place to report RISC-V
> specific bug.

I would prefer no un-upstreamed patches at all in riscv-newlib.
Currently I think we don't have any.  We just have some patches
backported.  This is something that could just as well be handled as a
RISC-V Foundation vendor branch in the upstream tree.  The only issue
is getting upstream write access for everyone that wants to
contribute.  Some people got write access to the github.com/riscv
trees long ago before tools were upstreamed, and have been reluctant
to get write access to the upstream trees.  I've been acting as a go
between for some of this, but eventually I would like to see the
riscv-newlib and other riscv toolchain trees die off and have us do
all work upstream.  But for the moment, the fact that the 32-bit glibc
support isn't upstream yet means we have to have riscv specific
toolchain sources to hold those patches, so I can't kill off the
github.com/riscv toolchain trees just yet.  I am slowly moving in that
direction though.  I just recently replaced riscv-qemu with upstream
qemu after getting a few patches accepted into upstream qemu.  I'd
like to do this for a few more riscv trees when I have a chance.

> So the newlib part I think you could submit patches to this mailing
> list directly or send a pull request on riscv-newlib is fine.
> And riscv-gnu-toolchain part you could try to fork it first, and might
> send pull request on gitthub to start further discussion about how to
> integration.

Since these filesystem patches aren't riscv specific,  they need to go
upstream first.  It isn't reasonable to ask us to be a go-between for
patches like this.  Once they are upstream, we can backport them if
necessary and/or convenient.

Jim