badaddr() panics when TT is enabled

Hello, m68k users,

Current 020/030 bus error handler doesn't support TT register.
Only news68k and luna68k use TT among m68k ports, so trying
badaddr() to an address where no device is present in the TT
region on these ports causes a panic.

As background, I have tried to add news68k emulation in my LUNA
emulator 'nono' (though I don't have any plan to add more news68k
support at this point :-).
Therefore, it doesn't have news68k's SCSI controller yet.
Even without the SCSI controller, I expected that the kernel
reached a boot device prompt.  But actually it panics in
si_match() (sys/arch/news68k/dev/si.c).  0xe0cc0000 is the address
of the SCSI controller as described in news68k/conf/GENERIC.  

[   1.0000000] NetBSD 9.3 (GENERIC) #0: Thu Aug  4 15:30:37 UTC 2022
[   1.0000000]  [email protected]:/usr/src/sys/arch/news68k/compile/GENERIC
[   1.0000000] SONY NET WORK STATION, Model NWS-1750, Machine ID #0
[   1.0000000] total memory = 16384 KB
[   1.0000000] avail memory = 12656 KB
[   1.0000000] mainbus0 (root)
 :
[   1.0000000] zsc0 at hb0 addr 0xe0d40000 ipl 5 vect 64
[   1.0000000] zstty0 at zsc0 channel 0 (console i/o)
[   1.0000000] zstty1 at zsc0 channel 1
[   1.0000000] uvm_fault(0x2cad38, 0xe0cc0000, 0x1) -> 0xe
[   1.0000000]   type 8, code [mmu,,ssw]: 4010155
[   1.0000000] trap type 8, code = 0x4010155, v = 0xe0cc0000
[   1.0000000] kernel program counter = 0x1eb4
[   1.0000000] kernel: MMU fault trap
 :

I don't know about NEWS hardware specifics.  But if the hardware
returns a bus error where no device is present, badaddr() should
be able to detect it.

You can reproduce this panic on your PC:
 1. Install pkgsrc/emulators/nono (>= 0.4.3).
 2. Build news68k kernel.
 3. Run nono.
    % mkdir news
    % cd news
    % cat > nono.cfg
    vmtype=news
    hostcom-driver=stdio
    hostnet-driver=none
    ^D
    % nono -X <objdir>/news68k/obj/sys/arch/news68k/compile/GENERIC/netbsd

Here is a patch.
According to 68030 Users' Manual (Fig.9-39 in p.9-62), the T bit of
MMUSR should be checked before any other bits.

--- a/src/sys/arch/m68k/m68k/busaddrerr.s
+++ b/src/sys/arch/m68k/m68k/busaddrerr.s
@@ -219,7 +219,12 @@ Lbe10:
 	jeq	Lbe10a			| if no, done
 	movql	#5,%d0			| else supervisor program access
 Lbe10a:
-	ptestr	%d0,%a0@,#7		| do a table search
+	ptestr	%d0,%a0@,#0		| check without table search
+	pmove	%psr,%sp@
+	movw	%sp@,%d1
+	btst	#6,%d1			| TT?
+	jne	Lisberr1		| yes -> bus error
+	ptestr	%d0,%a0@,#7		| no, do a table search
 	pmove	%psr,%sp@		| save result
 	movb	%sp@,%d1
 	btst	#2,%d1			| invalid (incl. limit viol. and berr)?


I have confirmed it on luna68k (real LUNA-I):
 - lcd_match() uses badaddr().  It works on an address that
   device is present even with above patch.
 - The following is a PoC patch.  0xc0000000 on LUNA-I is in TT
   area and causes a bus error.  badaddr() without above patch
   panics for this address but with above patch don't panic.
--- a/sys/arch/luna68k/luna68k/mainbus.c
+++ b/sys/arch/luna68k/luna68k/mainbus.c
@@ -42,7 +42,7 @@
 
 static const struct mainbus_attach_args luna_devs[] = {
 	{ "clock",  0x45000000, -1 },	/* Mostek TimeKeeper */
-	{ "lcd",    0x4d000000, -1 },	/* Sharp LM16X212 LCD module */
+	{ "lcd",    0xc0000000, -1 },	/* Sharp LM16X212 LCD module */
 	{ "le",     0xf1000000, 3 },	/* Am7990 */
 	{ "sio",    0x51000000, 6 },	/* uPD7201A */
 	{ "xpbus",  0x71000000, -1 },	/* HD647180XP */

Of course I have also confirmed that even x68k (real X68030) that
doesn't use TT works with above busaddrerr.s patch.

But I don't have news68k.
Would someone try it? or any comments?

Thanks,
---
Tetsuya Isaki <[email protected] / [email protected]>