* Procedure for submitting RISC-V based BSP to Newlib @ 2019-07-24 7:24 Bandhav Veluri 2019-07-24 13:10 ` Prof. Michael Taylor 0 siblings, 1 reply; 4+ messages in thread From: Bandhav Veluri @ 2019-07-24 7:24 UTC (permalink / raw) To: newlib; +Cc: Bandhav Veluri, Michael 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Procedure for submitting RISC-V based BSP to Newlib 2019-07-24 7:24 Procedure for submitting RISC-V based BSP to Newlib Bandhav Veluri @ 2019-07-24 13:10 ` Prof. Michael Taylor 2019-07-24 16:20 ` Kito Cheng 0 siblings, 1 reply; 4+ messages in thread From: Prof. Michael Taylor @ 2019-07-24 13:10 UTC (permalink / raw) To: newlib; +Cc: Bandhav Veluri, Bandhav Veluri 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Procedure for submitting RISC-V based BSP to Newlib 2019-07-24 13:10 ` Prof. Michael Taylor @ 2019-07-24 16:20 ` Kito Cheng 2019-07-24 21:40 ` Jim Wilson 0 siblings, 1 reply; 4+ messages in thread From: Kito Cheng @ 2019-07-24 16:20 UTC (permalink / raw) To: Prof. Michael Taylor Cc: Newlib, Bandhav Veluri, Bandhav Veluri, Jim Wilson, Palmer Dabbelt 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Procedure for submitting RISC-V based BSP to Newlib 2019-07-24 16:20 ` Kito Cheng @ 2019-07-24 21:40 ` Jim Wilson 0 siblings, 0 replies; 4+ messages in thread From: Jim Wilson @ 2019-07-24 21:40 UTC (permalink / raw) To: Kito Cheng Cc: Prof. Michael Taylor, Newlib, Bandhav Veluri, Bandhav Veluri, Palmer Dabbelt 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 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2019-07-24 21:40 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-07-24 7:24 Procedure for submitting RISC-V based BSP to Newlib Bandhav Veluri 2019-07-24 13:10 ` Prof. Michael Taylor 2019-07-24 16:20 ` Kito Cheng 2019-07-24 21:40 ` Jim Wilson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).