NetBSD Problem Report #9852

Received: (qmail 13769 invoked from network); 10 Apr 2000 13:07:16 -0000
Message-Id: <200004101307.GAA01898@nbwww.isc.org>
Date: Mon, 10 Apr 2000 06:07:15 -0700 (PDT)
From: daishi@axlight.com
Reply-To: daishi@axlight.com
To: gnats-bugs@gnats.netbsd.org
Subject: Duo support
X-Send-Pr-Version: www-1.0

>Number:         9852
>Category:       port-mac68k
>Synopsis:       Duo support
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    port-mac68k-maintainer
>State:          feedback
>Class:          change-request
>Submitter-Id:   net
>Arrival-Date:   Mon Apr 10 13:08:00 +0000 2000
>Closed-Date:    
>Last-Modified:  Fri Nov 08 19:10:02 +0000 2019
>Originator:     Daishi Kato
>Release:        current-20000318
>Organization:
Japan
>Environment:
NetBSD duo230.axlight.com 1.4X NetBSD 1.4X (DUOTEST) #1: Thu Apr 6 05:47:32 PDT 2000 root@duo230.axlight.com:/usr/src/sys.000331/arch/mac68k/compile/DUOTEST mac68k
>Description:
Support for Duo-series.
With the patch it will boot,
and the internal keyboard will work.
The patch is only tested with Duo230.
(Sorry for this short message.)
>How-To-Repeat:

>Fix:
This is the patch.

--- mac68k/locore.s.orig	Fri Mar 10 04:31:57 2000
+++ mac68k/locore.s	Mon Apr  3 06:34:12 2000
@@ -120,6 +120,10 @@
 GLOBAL(bletch)
 	.long	0

+/* to use tt1 instead of tt0 in get_pte() */
+GLOBAL(mac68k_use_tt1)
+	.long	0
+
 BSS(esym,4)

 ASENTRY_NOPROFILE(start)
@@ -1632,7 +1636,13 @@

 	lea	_ASM_LABEL(longscratch),a0
 	movl	#0x00ff8710,a0@	| Set up FC 1 r/w access
+	tstl	_C_LABEL(mac68k_use_tt1)
+	beq	Lusett0_1
+	.long	0xf0100c00	| pmove a0@,tt1
+	bra	Ldonett0_1
+Lusett0_1:
 	.long	0xf0100800	| pmove a0@,tt0
+Ldonett0_1:

 	movl	sp@(8),a0	| logical address to look up
 	movl	#0,a1		| clear in case of failure
@@ -1757,7 +1767,13 @@
 get_pte_success:
 	lea	_ASM_LABEL(longscratch),a0 | disable tt
 	movl	#0,a0@
+	tstl	_C_LABEL(mac68k_use_tt1)
+	beq	Lusett0_2
+	.long	0xf0100c00	| pmove a0@,tt1
+	bra	Ldonett0_2
+Lusett0_2:
 	.long	0xf0100800	| pmove a0@,tt0
+Ldonett0_2:

 	addql	#4,sp		| return temporary space
 	rts
--- mac68k/machdep.c.orig	Mon Mar 20 04:20:54 2000
+++ mac68k/machdep.c	Mon Apr  3 06:38:31 2000
@@ -215,6 +215,9 @@
 struct extent *iomem_ex;
 int iomem_malloc_safe;

+/* this value is used in locore.s */ /* by daishi */
+extern u_long mac68k_use_tt1;
+
 static void	identifycpu __P((void));
 static u_long	get_physical __P((u_int, u_long *));

@@ -2146,6 +2149,8 @@
 		via_reg(VIA1, vIER) = 0x6f;	/* disable VIA1 int */
 		/* Are we disabling something important? */
 		via_reg(VIA2, rIER) = 0x7f;	/* disable VIA2 int */
+		/* to use tt1 instead of tt0 in get_pte() */ /* by daishi */
+		mac68k_use_tt1 = 1;
 		break;
 	case MACH_CLASSQ:
 	case MACH_CLASSQ2:
--- dev/adb_direct.c.orig	Thu Mar 23 04:27:02 2000
+++ dev/adb_direct.c	Mon Apr  3 06:34:14 2000
@@ -2104,6 +2104,8 @@
 	int device;
 	int nonewtimes;		/* times thru loop w/o any new devices */

+	adb_setup_hw_type();	/* setup hardware type */
+
 	/* Make sure we are not interrupted while building the table. */
 	/* ints must be on for PB & IOP (at least, for now) */
 	if (adbHardware != ADB_HW_PB && adbHardware != ADB_HW_IOP)
@@ -2122,8 +2124,6 @@
 	 */
 	for (i = 0; i < 16; i++)
 		ADBDevTable[i].devType = 0;
-
-	adb_setup_hw_type();	/* setup hardware type */

 	adb_hw_setup();		/* init the VIA bits and hard reset ADB */

--- dev/pm_direct.c.orig	Sun Mar 19 04:17:11 2000
+++ dev/pm_direct.c	Mon Apr  3 06:34:15 2000
@@ -1066,8 +1066,20 @@
 	/* wait until the PM interrupt is occured */
 	delay = 0x80000;
 	while (adbWaiting == 1) {
+	switch (mac68k_machine.machineid) { /* by daishi only tested with Duo230 */
+		case MACH_MACPB210:
+		case MACH_MACPB230:
+		case MACH_MACPB250:
+		case MACH_MACPB270:
+		case MACH_MACPB280:
+		case MACH_MACPB280C:
+			pm_intr((void *)0);
+			break;
+		default:
 		if ((via_reg(VIA1, vIFR) & 0x10) == 0x10)
 			pm_intr((void *)0);
+			break;
+	}
 #ifdef PM_GRAB_SI
 #if 0
 			zshard(0);		/* grab any serial interrupts */

>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback
State-Changed-By: maya@NetBSD.org
State-Changed-When: Mon, 04 Nov 2019 19:38:32 +0000
State-Changed-Why:
It looks like the adb part of the patch got committed, but I don't see anything about the pmap part.
What happened with that? was it still a patch you had to locally apply? Thanks.


From: Hauke Fath <hf@spg.tu-darmstadt.de>
To: gnats-bugs@NetBSD.org
Cc: port-mac68k-maintainer@NetBSD.org, gnats-admin@NetBSD.org, maya@NetBSD.org,
        daishi@axlight.com
Subject: Re: port-mac68k/9852 (Duo support)
Date: Fri, 8 Nov 2019 20:08:15 +0100

 On Mon,  4 Nov 2019 19:38:33 +0000 (UTC), maya@NetBSD.org wrote:
 > It looks like the adb part of the patch got committed, but I don't=20
 > see anything about the pmap part.
 > What happened with that? was it still a patch you had to locally=20
 > apply? Thanks.

 It would be helpful if the submitter clarified the (expected)=20
 significance of using a different mmu register on the Duo.=20

 I have a Duo 280(c), and remember booting it successfully with a=20
 (soft-float) kernel post-1.4, but that is with a 68LC040 as opposed to=20
 the Duo 230's 68030.

 Cheerio,
 hauke

 --=20
      The ASCII Ribbon Campaign                    Hauke Fath
 ()     No HTML/RTF in email            Institut f=FCr Nachrichtentechnik
 /\     No Word docs in email                     TU Darmstadt
      Respect for open standards              Ruf +49-6151-16-3281

>Unformatted:

Home	PR Database Search