Re: [PATCH v4 00/16] Basic StarFive JH7100 RISC-V SoC support

[Emil Renner Berthing]

On Sat, 27 Nov 2021 at 02:30, Palmer Dabbelt <palmer@xxxxxxxxxxxx> wrote:
> On Tue, 16 Nov 2021 09:28:41 PST (-0800), kernel@xxxxxxxx wrote:
> > On Tue, 16 Nov 2021 at 17:08, Arnd Bergmann <arnd@xxxxxxxx> wrote:
> >> On Tue, Nov 16, 2021 at 4:01 PM Emil Renner Berthing <kernel@xxxxxxxx> wrote:
> >> >
> >> > This series adds support for the StarFive JH7100 RISC-V SoC. The SoC has
> >> > many devices that need non-coherent dma operations to work which isn't
> >> > upstream yet[1], so this just adds basic support to boot up, get a
> >> > serial console, blink an LED and reboot itself. Unlike the Allwinner D1
> >> > this chip doesn't use any extra pagetable bits, but instead the DDR RAM
> >> > appears twice in the memory map, with and without the cache.
> >> >
> >> > The JH7100 is a test chip for the upcoming JH7110 and about 300 BeagleV
> >> > Starlight Beta boards were sent out with them as part of a now cancelled
> >> > BeagleBoard.org project. However StarFive has produced more of the
> >> > JH7100s and more boards will be available[2] to buy. I've seen pictures
> >> > of the new boards now, so hopefully before the end of the year.
> >> >
> >> > This series is also available at
> >> > https://github.com/esmil/linux/commits/starlight-minimal
> >> > ..but a more complete kernel including drivers for non-coherent
> >> > peripherals based on this series can be found at
> >> > https://github.com/starfive-tech/linux/tree/visionfive
> >> >
> >> > [1]: https://lore.kernel.org/linux-riscv/20210723214031.3251801-2-atish.patra@xxxxxxx/
> >> > [2]: https://www.linkedin.com/pulse/starfive-release-open-source-single-board-platform-q3-2021-starfive/
> >>
> >> Thanks for adding me to Cc, I've had a look at the series and didn't
> >> see anything
> >> wrong with it, and I'm happy to merge it through the SoC tree for the
> >> initial support
> >> in 5.17, provided you get an Ack from the arch/riscv maintainers for it.
> >
> > Cool!
> >
> > @Palmer, do you mind looking through this? Probably patch 1, 15 and 16
> > are the most relevant to you.
> >
> >> Regarding the coherency issue, it's a bit sad to see yet another hacky
> >> workaround
> >> in the hardware, but as you say this is unrelated to the driver
> >> series. I'd actually
> >> argue that this one isn't that different from the other hack you
> >> describe, except
> >> this steals the pagetable bits from the address instead of the reserved flags...
> >
> > Yeah, it's definitely a hack, but at least it's not using bits the
> > spec said was reserved. Hopefully the JH7110 will be fully coherent or
> > maybe implement the new Svpbmt extension.
>
> Sorry, this had been sitting on top of my inbox because I hadn't had a
> chance to figure this stuff out.  Emil poked me on IRC about it, but I
> figured I'd just write it here so everyone can see:
>
> IMO there's a huge difference between the StarFive-flavored non-coherent
> stuff (which relies on physical aliasing) and the T-Head-flavored stuff
> (which uses page table bits): the PA-aliasing approach is allowed by the
> ISA, while the page table bits aren't (they're marked as reserved).  IMO
> we should still figure out a way to take the T-Head stuff, as it's the
> real-ist hardware we have, but that's a whole different can of worms.
>
> My worry with this is I've yet to actually be convinced that either of
> these approaches work.  Specifically, neither of them prevents M-mode
> from performing (either directly or as a side effect of something like
> speculation) accesses that violate the attributes we're ascribing to
> regions in Linux.  IIRC I pointed that out in the Svpmbt patch set,
> which has exactly the same set of problems.
>
> That said, I don't really care all that much -- having something here is
> better than nothing, and we've always relied on the HW vendors just
> producing HW that works when it comes to any of the IO stuff (ie, even
> on coherent systems).  These are all drivers so it's really up to those
> folks where the bar is, so as long as everyone's on the page about that
> you're not going to get any objections from me so
>
> Acked-by: Palmer Dabbelt <palmer@xxxxxxxxxxxx>

Thanks! Yeah, as you say something is better than nothing. I'd think
it's helpful to have something to build and test the non-coherent dma
functionality on, and the nice thing about the Starfive-flavour is
that it will actually boot into an initramfs root and have a working
serial console even without the non-coherent dmas working.

> The SOC tree works for me.  It'd be great to have a shared tag I where I
> can pull in at least the Kconfig.socs stuff, but if that's not easy then
> it's no big deal -- what's in flight there is pretty trivial on my end,
> so we can just deal with the merge conflicts.

I guess this is for the SoC maintainers to consider. Let me know if
that's wrong and I need to do anything.

/Emil