Re: [PATCH] riscv: deprecate CONFIG_MMU=n

[Charles Lohr]

Jisheng, are you using musl or uclibc? I've been having difficulty
getting new versions of each working with the newer kernels with
system calls not lining up.

Also, is there a better place to ask questions about the more
user-spacy stuff?  That's really where I've been struggling to
maintain things, keeping buildroot working when targeting RV32 NOMMU.
Thankfully a lot of the stickiest problems have all been upstreamed.

Charles

On Mon, Mar 25, 2024 at 10:12 AM Jisheng Zhang <jszhang@xxxxxxxxxx> wrote:
>
> On Thu, Mar 14, 2024 at 09:02:43PM +0800, Jisheng Zhang wrote:
> > On Thu, Mar 14, 2024 at 08:46:21PM +0800, Jisheng Zhang wrote:
> > > On Tue, Feb 27, 2024 at 08:38:50AM -0800, Palmer Dabbelt wrote:
> > > > On Tue, 27 Feb 2024 01:11:41 PST (-0800), cleger@xxxxxxxxxxxx wrote:
> > > > >
> > > > >
> > > > > On 26/02/2024 20:00, Charles Lohr wrote:
> > > > > > WOAH! Please DO NOT deprecate NOMMU. I use the NOMMU build constantly
> > > > > > and NOMMU Linux on RISC-V is the avenue used by many FPGA soft cores
> > > > > > for Linux, as well as some limited systems.
> > > >
> > > > OK.
> > > >
> > > > I just build test this stuff, as I don't really have a use for it
> > > > personally.  I figured if nobody's reporting bugs then probably it's broken
> > > > and nobody's noticed because nobody's using it.
> > > >
> > > > > > I get new copies of the kernel when there are releases and test them
> > > > > > frequently to make sure everything is still working as expected.
> > > >
> > > > I'd actually expected it to be broken, but I guess we managed to avoid
> > > > screwing things up ;)
> > > >
> > > > > > For us we just don't care about XIP. I mean if someone did push it
> > >
> > > I don't care XIP either, and IMHO the XIP's maintenance effort is much
> > > bigger than NOMMU(just check the various XIP_FIXUP* or CONFIG_XIP_KERNEL
> > > macros around lowlevel pgtable.h, page.h). If we can remove XIP, the
> > > code readability will be much better.
> > >
> > > Or sending out a similar XIP deprecation patch to see whether there's
> > > any complain ? ;)
> > >
> > > > > > through to fruition, I'd also test and use it, but I urge you please
> > > > > > do not deprecate this.  While it's sometimes needed a bit of a
> > >
> > > +1 for urge the upstream please do not deprecate NOMMU.
> > >
> > > Besides the soft(FPGA) core mentioned by Charles, here is another real
> >
> > And I'd like to write more about soft core: riscv is a free and open
> > ISA, this make it really good for education, for simple riscv
> > implementation or emulator. Once riscv IMA is implemented(even if MMU,
> > cache, TLB stuff don't exist), it's not far away from making linux
> > running on the FPGA or emulator. If the gain is larger than the maintenance
> > effort, I'd like to urge keeping the NOMMU support.
> >
> > Thanks a lot
> >
> > > usage case: As is known, Sophgo CV1800B platforms such as Milk Duo
> > > contains two C906 core, one(a.k.a big core) with MMU another(a.k.a small
> > > core)w/o MMU. The vendor sdk runs freertos on the small core, but it
> > > doesn't prevent users to run other OS such as threadx, zephyr or nommu
> > > linux on the small core. In fact, I sucessfully brought up nommu linux
> > > on the small core. I didn't just send out the patches in time during this
> > > dev window duo to my personal career reason(I spent the time on hunting
> > > for a new job)
> > >
> > > I plan to send out NOMMU related patches once 6.9-rc1 is out.
>
> As is promised, the NOMMU improvement patches are sent out
> https://lore.kernel.org/linux-riscv/20240325164021.3229-1-jszhang@xxxxxxxxxx/T/#t
>
> Thanks
>
> > >
> > > > > > creative build to get everything working, I've never needed to patch
> > > > > > anything in the kernel beyond patching in a custom console for serial
> > > > > > output.
> > > > > >
> > > > >
> > > > > Hey Charles,
> > > > >
> > > > > No worries, we actually did not expected NOMMU to have *so many* users.
> > > > > I guess deprecating stuff is a good way to have immediate feedback ;).
> > > > > Having FDPIC psABI to be merged upstream could also probably be a
> > > > > positive point toward a better NOMMU support.
> > > >
> > > > Ya, that's probably the right way to do it.  Touching anything in the psABI
> > > > is pretty miserable, though, so I don't really want to force people to do
> > > > it...
> > > >
> > > > > > I am happy to discuss the possibility of me and or one of the other
> > > > > > RISC-V soft (FPGA) core people stepping up to try to be more active,
> > > > > > but so far we've just been very well serviced by the current NOMMU
> > > > > > Linux setup.
> > > > >
> > > > > It could probably be nice to have some feedback/Tested-by: from NOMMU
> > > > > users for new releases then.
> > > >
> > > > Having more upstream interaction from users is always appreciated, that's
> > > > the best way to prove people are using the code.  If you guys have the time
> > > > it'd be great to get this into some sort of CI, ideally running on some real
> > > > platform.
> > >
> > > As above, I'd also like to step up on the NOMMU stuff, at least test
> > > nommu on milkv duo's small core. And can be seen from my git commit
> > > histotry, I was active, and I belive I will still be active on riscv linux
> > > kernel development.
> > >
> > > >
> > > > > Thanks,
> > > > >
> > > > > Clément
> > > > >
> > > > > >
> > > > > > Charles
> > > > > >
> > > > > >
> > > > > > On Mon, Feb 26, 2024 at 8:03 AM Conor Dooley <conor@xxxxxxxxxx> wrote:
> > > > > > >
> > > > > > > On Mon, Feb 26, 2024 at 04:25:24PM +0100, Clément Léger wrote:
> > > > > > > > I guess I could also mark XIP as deprecated.
> > > > > > >
> > > > > > > I'm not so sure, people recently added XIP support to QEMU (and sent
> > > > > > > kernel fixes in December). XIP is also not nearly as much of a problem
> > > > > > > to support, there's far less that it does differently, the main barrier
> > > > > > > was the inability to test it which is no longer the case.
> > > > > > > That said, XIP is gonna kill itself off I feel as it does not support
> > > > > > > runtime patching and therefore is extremely limited on extensions, given
> > > > > > > we use alternatives for all of that (although I suppose if someone has a
> > > > > > > usecase they could make nasty macros worse and implement a compiletime
> > > > > > > switch in the alternatives too).
> > > > > > >
> > > > > > > Cheers,
> > > > > > > Conor.
> > > > > > >
> > > > > > > _______________________________________________
> > > > > > > linux-riscv mailing list
> > > > > > > linux-riscv@xxxxxxxxxxxxxxxxxxx
> > > > > > > http://lists.infradead.org/mailman/listinfo/linux-riscv
> > > >
> > > > _______________________________________________
> > > > linux-riscv mailing list
> > > > linux-riscv@xxxxxxxxxxxxxxxxxxx
> > > > http://lists.infradead.org/mailman/listinfo/linux-riscv