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:
> 
>         (320 and 319C/330 requires "RAS instead of CAS" patch, maybe due to 16 bit bus RAMs)
>          https://github.com/NetBSD/src/compare/trunk...tsutsui:netbsd-src:hp300-ras-instead-of-cas

This one had me puzzled just a little bit, so I went back and checked the 68020 manual, and lo and behold, "5.3.3 Read-Modify-Write Cycle” states that TAS, CAS, and CAS2 are the only instructions on the 68020 that use that bus cycle type (defined as assertion of /RMC during the “indivisible operation” and the lack of assertion of /BG in response to observing assertion of /BR during the “indivisible operation").

My assumption that TAS will blow up the same way on these machines.  I guess there must be some specific logic in the memory control hardware that specifically asserts /BERR if /RMC is asserted, because if you look at the state and timing diagrams in the manual, the R-M-W bus cycle doesn’t look appreciably different from the garden variety read and write bus cycles.  Even /AS and /DS behave as if they were individual cycles (unless my eyesight is failing me!), so even bus cycle timeout logic that would assert /BERR should work the same.  If you ever feel like satisfying my curiosity, it would be interesting to see what the /RMC pin on the 68020 is connected to!

This apparently hold true at least through the 68040 (although the 68040 will also use R-M-W to update PTEs during an MMU table-walk, according to section 7.4.5 of the 68040 manual.

I think the best way to deal with this is a run-time patch of the CAS-using code paths, with some compile-time conditionals on when this might be necessary (__HAVE_M68K_BROKEN_RMC ?)

FWIW, this also implies that any future MP support for m68k (hey, it could happen! :-) needs to be aware of this and not assume that the current implementations of e.g. atomic_or(3), etc. are MP-safe.

-- thorpej