Re: New pmap module for m68k

Jason Thorpe <[email protected]> Wed, 12 Nov 2025 10:15:03 -0800
Newsgroups gmane.os.netbsd.ports.m68k
Message-ID <[email protected]>
> On Nov 9, 2025, at 12:07=E2=80=AFPM, Izumi Tsutsui =
<[email protected]> wrote:
>=20
>         (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=E2=80=9D=
 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 =
=E2=80=9Cindivisible operation=E2=80=9D and the lack of assertion of /BG =
in response to observing assertion of /BR during the =E2=80=9Cindivisible =
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=E2=80=99t 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