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