>Number:         1853
>Category:       port-amiga
>Synopsis:       grf_ul initialization fails on some machines/with some bootloaders
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    gnats-admin (GNATS administrator)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Dec 21 07:05:02 1995
>Last-Modified:
>Originator:     Ignatios Souvatzis
>Organization:
	Me, myself and I
>Release:        1.1
>Environment:
	
System: NetBSD beverly.rhein.de 1.1 NetBSD 1.1 (BEVERLY) #15: 
	Thu Dec 21 11:55:35 MET 1995 
	is@beverly.rhein.de:/usr/src/sys/arch/amiga/compile/BEVERLY amiga


>Description:
	Console gets grabbed by the A2410, but apparently its
	colormap is messed up (all gray, sometimes all black, sometimes
	black on dark yellow instead of on gray). This was verified 
	by be with blind typing.
	
>How-To-Repeat:
	Boot on A3000/030/25 with A2410 and ULOWELL_CONSOLE with
	M. Hitch's bootblock using Fastmem (anytime) or the Chipmem
	(sometimes). There is also a report by Brian King who has 
	the same symptoms on a A2000/040 machine.
>Fix:
	Looking at my own code, I wonder how it ever worked, for
	two reasons:

	1. The alternative chosen for initial colormap setup depends
	on the main CPU being slow enough (or the TMS34010 being
	fast enogh), so that the TMS34010 software input queue is
	set up before the colormap is called. As there are only a
	few lines between TMS34010 start and the colormap command
	issuing, on the M68K cpu, this should be expected to fail
	with fast cpus or phase of moon.

	2. The colormap writing code in the initialization calls
	the normal ul_putcmap() function, which uses copyin() to
	get the colormap data to write. I guess this is NOT expected
	to work when booting; it might have worked on my machine
	because I a) never looked at the initialized image color
	map lately, as the text console is on the overlay planes,
	and the overlay planes color map is set up again by the
	TMS34010 code.

	I append a patch which fixes these, and is verified to work
	on my machine with all possible combinations of power
	cycling, resetting, reboot(8)ing from NetBSD, and using
	loadbsd, bootblock or the bootbsd program from AmigaOS,
	using (where applicable) chipmem or fastmem for kernel
	loading.

	Brian, please apply the patch to your sources and verify
	if that fixes your problems, too.

Index: grf_ul.c
===================================================================
RCS file: /monster/cvs/src/sys/arch/amiga/dev/grf_ul.c,v
retrieving revision 1.1.1.4
diff -u -r1.1.1.4 grf_ul.c
--- grf_ul.c	1995/11/12 12:52:55	1.1.1.4
+++ grf_ul.c	1995/12/21 11:29:22
@@ -273,10 +273,7 @@
 
 	/* font info was uploaded in ite_ul.c(ite_ulinit). */
 
-	/* unflush cache, unhalt cpu -> nmi starts to run */
-	ba->ctrl &= ~(HLT|CF);	
-
-#if 0
+#if 1
 	/* XXX load image palette with some initial values, slightly hacky */
 
 	ba->hstadrh = 0xfe80;
@@ -293,17 +290,50 @@
 
 	/* 
 	 * XXX load shadow overlay palette with what the TMS code will load 
-	 * into the real one some time after the TMS code is started above. 
-	 * This is a rude hack.
+	 * into the real one some time after the TMS code is started below. 
+	 * This might be considered a rude hack.
 	 */ 
 	bcopy(ul_ovl_palette, gup->gus_ovcmap, 3*4);
+
+	/* 
+	 * Unflush cache, unhalt cpu -> nmi starts to run. This MUST NOT BE 
+	 * DONE before the image color map initialization above, to guarantee
+	 * the index register in the bt478 is not used by more than one CPU
+	 * at once.
+	 *
+	 * XXX For the same reason, we'll have to rething ul_putcmap(). For
+	 * details, look at comment there.
+	 */
+	ba->ctrl &= ~(HLT|CF);	
+
 #else
-	/* XXX This version will work for the overlay, if our queue codes 
+	/*
+	 * XXX I wonder why this partially ever worked. 
+	 *
+	 * This can't possibly work this way, as we are copyin()ing data in
+	 * ul_putcmap.
+	 *
+	 * I guess this partially worked because SFC happened to point to 
+	 * to supervisor data space on 68030 machines coming from the old 
+	 * boot loader.
+	 *
+	 * While this looks more correct than the hack in the other part of the
+	 * loop, we would have to do our own version of the loop through 
+	 * colormap entries, set up command buffer, and call gsp_write(), or
+	 * factor out some code.
+	 */
+
+	/*
+	 * XXX This version will work for the overlay, if our queue codes 
 	 * initial conditions are set at load time (not start time).
 	 * It further assumes that ul_putcmap only uses the 
 	 * GRFIMDEV/GRFOVDEV bits of the dev parameter.
 	 */
 
+
+	/* unflush cache, unhalt cpu first -> nmi starts to run */
+	ba->ctrl &= ~(HLT|CF);	
+
 	gcm.index = 0;
 	gcm.count = 16;
 	gcm.red   = ul_std_palette +  0;
@@ -810,6 +840,14 @@
 
 	/* then write from there to the hardware */
 	ba = (struct gspregs *)gp->g_regkva;
+	/*
+	 * XXX This is a bad thing to do.
+	 * We should always use the gsp call, or have a means to arbitrate 
+	 * the usage of the BT478 index register. Else there might be a 
+	 * race condition (when writing both colormaps at nearly the same
+	 * time), where one CPU changes the index register when the other
+	 * one has not finished using it.
+	 */
 	if (mxidx > 4) {
 		/* image color map: we can write, with a hack, directly */
 		ba->ctrl = LBL;
>Audit-Trail:
>Unformatted: