Re: badaddr() panics when TT is enabled
Tetsuya Isaki <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.m68k |
|---|---|
| Message-ID | <x7leioily5.wl%[email protected]> |
At Sat, 15 Apr 2023 17:19:55 +0900, Izumi Tsutsui wrote: > > Would you also try a case where badaddr() fires in TT area? > > I don't know well about NEWS but how about this? : > It boots but si1 is also attached, i.e. looks no bus error. : > According to "md" command outputs on PROM monitor, whole 0xeXXXXXXX > region doesn't cause bus error, but at least 0xf0000000 does. Thanks! This is interesting result. nono should be updated... > However, this means we should implememnt some proper probe routine > for nono emulator that doesn't have si(4) SCSI. Umm. nono's news68k emulation is pretty incomplete quality (because we authors don't know about NEWS hardware at all). I prefer that guest OS doesn't take care of such in-development emulators that run differently from the real hardware. On the other hand, in general, it's welcome to make our probe routine more robust. > Just because MC68030 USER'S MANUAL 9.7.4 says: > >> The PTEST instruction searches either the ATC (PTEST with level 0) or > >> the translation tables (PTEST with levels of 1-7) to determine status > >> information about the translation of a specified logical address. > > (Ah, I misread "either" as "entire") I see :) > I.e. > PTEST with level 0: searches the ATC > PTEST with levels of 1-7: searches the translation tables > ..to determine status information about the translation > > I guess "PTEST, level 0" is more explicit, per Table 9-3 ? How about the following comment that spans in two lines? (Both one and two space indentation seem to be used to represent line continuation) +Lbe10a: + ptestr %d0,%a0@,#0 | only PTEST #0 can detect transparent + pmove %psr,%sp@ | translation (TT0 or TT1). + movw %sp@,%d1 + btst #6,%d1 | transparent (TT0 or TT1)? > > Unfortunately, it's not possible to find spc0 and spc1 correctly > > by only using current spc_mainbus_match() on LUNA due to its hard- > > ware characteristics. > > As you pointed out actually it doesn't cause bus error. > > I'll add a machtype check and cleanup maimbus_attach_args later. Nice. (I prefer more strict way but it maybe excessive..) --- Tetsuya Isaki <[email protected] / [email protected]>