>Number:         17180
>Category:       port-m68k
>Synopsis:       m68k bus_dmamap_sync() makes faulty assumption regarding DCFL()/DCFP()
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-m68k-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Wed Jun 05 23:14:01 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     Scott Reynolds
>Release:        NetBSD 1.6_BETA1 2002-06-03
>Organization:
>Environment:
System: NetBSD maverick 1.6_BETA1 NetBSD 1.6_BETA1 (GENERIC) #0: Tue Jun 4 04:45:22 UTC 2002 autobuild@tgm.daemon.org:/autobuild/mac68k/OBJ/autobuild/src/sys/arch/mac68k/compile/GENERIC mac68k
Architecture: m68k
Machine: mac68k
>Description:
	The bus_dmamap_sync() implementation in sys/arch/m68k/m68k/bus_dma.c
	assumes the general availability of DCFL() and DCFP() to flush lines
	and pages in the data cache. Because there is no directly corres-
	onding instruction for the '020 and '030, however, compiling without
	'040 and '060 support fails. Additionally, in the case of a GENERIC
	kernel the default action for these two operations is to execute an
	'040-specific instruction. Attempting a DCFL() or DCFP() will at
	best cause an illegal instruction trap on the older processors.

	While the problem was observed on mac68k specifically, its nature
	suggests that it is likely to impact most m68k ports to some degree.

>How-To-Repeat:
	Configure e.g. a mac68k kernel without support for the 68040.
	Attempt to compile the kernel; it will fail while attempting to
	compile bus_dma.c.

		-or-

	Attempt to boot a GENERIC mac68k kernel on an '020 or '030.

>Fix:
	The brutal hack is to simply bracket all cases of DCFL() and DCFP()
	with

		#if defined(M68040) || defined(M68060)
			...
		#endif

	as in other sections that use it. One could instead argue that the
	default behavior of these operations should be a no-op, which would
	of course work around the problem. However, either of these work-		arounds is almost certainly not correct. There are likely some '030
	machines that need (or will in the future need) bus_dmamap_sync()
	to operate properly.

	One solution would be to implement a data cache flush operation for
	the 68030, then update bus_dmamap_sync() to use it as appropriate
	and skip the data cache flush on the 68020 altogether.
>Release-Note:
>Audit-Trail:
>Unformatted: