[lowrisc-dev] Re: lowRISC kernel changes rebased over stock 4.19
asb at lowrisc.org
Wed Oct 31 14:45:50 GMT 2018
On Wed, 31 Oct 2018 at 14:32, Gabriel L. Somlo <gsomlo at gmail.com> wrote:
> On Tue, Oct 30, 2018 at 09:04:36PM +0000, Dr Jonathan Kimmitt wrote:
> > > I've managed to successfully use https://github.com/riscv/riscv-gnu-toolchain
> > > directly to build every other component of lowRISC v0.6 (specifically
> > > busybox, the kernel, and bbl). That makes it possible to ignore any
> > > current differences between the toolchain fork included in
> > > rocket-chip/riscv-tools and "upstream" :)
> > >
> > The Rocket core repository has a dire warning against using anything other
> > than their tools, but I guess that dates back to the days when CSR numbers
> > were rather unstable.
> I haven't been on the risc-v scene long enough to understand the
> distinction between Rocket's repository and the "riscv" account on
> github. The latter instinctively feels closer to the notion of "upstream",
> although they too have forked submodules of all the gnu stuff. But maybe
> they (riscv) are the established path for changes trickle up into GNU as
> well, same way they appear to be doing for the Linux kernel?
Most projects are "upstream first" now, to the extent that I think the
riscv/riscv-gnu-toolchain repos and similar have sometimes got behind
upstream and there's been a lack of time to update them.
As Jonathan says, the warnings about only using a supported compiler
version are probably no longer relevant given the privileged spec
isn't changing in backwards incompatible ways and the compiler
toolchain is in a very stable state.
> As long as it's likely for the RTL to change, I agree, it's not worth
> trying to officially push for upsream inclusion. But presenting the
> changes in "upstream-ready" form is IMHO still worth doing for
> external legibility.
Agreed. We're not at a point where we want to push device drivers
upstream - we're not fully committed to the current interfaces and
implementations, so it would seem unfair to burden the upstream kernel
community with their maintenance and review. But keeping everything
checkpatch-safe and well separated has big advantages as you suggest.
> Not sure how to best track the development of the individual drivers
> themselves if we're to present them as "upstream-ready", that's a good
> question. Do you expect the keyboard/video/ethernet/etc. drivers to
> still undergo significant development in a way that could benefit from
> tracking changs with git? Maybe having a dedicated repository for
> lowrisc driver files only, and generate "upstream-ready" patches from
> there periodically might be an option?
It's a bit awkward isn't it.
IMHO the ideal would be to maintain this clean patch set rebased on to
appropriate tags of the Linux kernel (e.g. 4.19, 4.19.1 when
available). But that would suggest that history is rewritten if those
patches evolve, which might be a pain for downstream users if they
aren't also happy rewriting history?
> > > Please let me know what you think.
> > I think cutting down the size of the needed eco system is an excellent
> > notion. If you could share more details of your intended application
> > that would be especially interesting for us.
> I'm trying to build the smallest CPU core that could still boot Linux
> (probably some form of rv32ima[c], maybe from Pulp), and needed to start
> with something that already works, understand it, and try to remove it
> and scale it down as far as possible. The opposite direction (start with
> a tiny core, and add things to it until it boots Linux) seemed like it
> had too many ways to go wrong, so I decided to try and scale *down*
> instead of *up* :)
That sounds like a _really_ fun project and it would be great to
document for people to follow. For a while RV32 linux support has been
behind RV64, but I _think_ AndesTech and others now pushed the
necessary glibc and kernel patches upstream.
More information about the lowrisc-dev