Re: New pmap module for m68k

[Jason Thorpe <thorpej%me.com@localhost>]

> On Nov 9, 2025, at 12:07 PM, Izumi Tsutsui <tsutsui%ceres.dti.ne.jp@localhost> wrote:
> 
> One question: do you have any idea how to enable MMU on ports VA!=PA, like
> hp300 (as you know) and next68k (currently using TT0 mapping to handle it)?

Well, for now, it’s all still left to machine-dependent code in locore.s.  My plan for hp300 is to treat the MMU trampoline page the same way as a device page.  See below.

> I also wonder how "static I/O spaces (like INTIO on hp300)" should be mapped
> (i.e. how MD stuff in current pmap_bootstrap.c should be handled),
> but I guess this should be discussed in a separate thread..

My current thinking there is to have a table that gets instantiated if a port defines a CPP macro that provides the table’s contents.  The table would have:

==> Variable where to stash the VA for the special range
==> The PA for the special range
==> Size of the special range
==> Flags for the special range (fixed VA?  No-cache?  Maybe it’s always no-cache…)

The table gets passed through once to allocate the VAs, then then again to actually insert the mappings.

That should be able to handle both the static I/O device ranges as well as the MMU trampoline page on hp300.  Eventually I might also make it possible to use a separate fixed VA for kernel_ptes[]; hp300 could benefit from that because it needs tables to map the end of the kernel address space for the MMU trampoline anyway, so putting kernel_ptes[] up there would probably save some PT pages (especially on small memory machines like the 320 & 350).

>> Definitely looking for help in this aspect, so drop me an email if you're interested
>> in helping with the effort and have hardware (or a decently functioning emulator)
>> that can be used for testing.
> 
> I can try (and hopefully help) the following machines here:

I was kind of hoping you’d be able to :-).  I really need to spend some time getting Nono set up, as well.

-- thorpej