68030, 68040 and 68060 MMU support (really!)

[mark_k]

I set up a NetBSD 1.6 install HD image and tested that with A3000/040 emulation. That shows a problem much earlier. After some initial text the installer repeatedly prints
Process (pid 1) got signal 11

WinUAE log output repeatedly prints
040 BUS ERROR: fc=1 w=0 logical=4e560000 ssw=0121 PC=00002256

[mark_k]

Also, booting that HD image with a 68030 A1200 config results in this log output:
MMU: page fault (logical addr=0A020000 SSW=5066 read=1 size=2 fc=6 pc=0a020000)
[that line repeated many times]
MMU: page fault (logical addr=0A020000 SSW=5066 read=1 size=2 fc=6 pc=0a020000)
MMU: page fault (logical addr=0039BFFC SSW=0305 read=0 size=4 fc=5 pc=0a020000)
CPU halted: reason = 1

[Toni Wilen]

Looks more interesting but NetBSD 1.6 sources are also needed.

[mark_k]

You can browse the NetBSD 1.6 source at http://cvsweb.netbsd.org/bsdweb.cgi/...sd-1-6-RELEASE. For different versions change the release tag in the URL. Probably src/sys/arch/amiga or src/sys/arch/m68k would be good places to start.

[Toni Wilen]

Unfortunately early A1200 mode crash is either NetBSD bug or not enough RAM (Some kernel memory region is for some reason marked read-only), it works when using enough Z3 RAM.

And unfortunately A3000 test is not that useful either because there are lots more bus errors between SCSI messages and it is impossible to know which one is correct and which one is bogus.

[mark_k]

Hmmm, the NetBSD 1.6 install document says a minimal configuration requires 6MB RAM (excluding chip RAM). I wonder whether it's actually possible to install 1.6 on a real Amiga with 8MB fast RAM?

One of the changes listed in the 1.6.2 document is:
Amiga boot handling has been modified to better handle certain machine configurations.

I'll try installing that version and see if it behaves differently.

Update: I installed NetBSD 1.6.2 (using an emulated A3000 config), then booted it using an emulated A2000/030/A2091/8MB fast config. It did boot, and after editing some X-related config files I was actually able to run X. I imagine doing that on a real 8MB fast A2000 would be incredibly slow due to a large amount of swapping.

Update 2: Booting the NetBSD installer on an A1200 config has the same problem as NetBSD 6.0.1; it doesn't detect the connected IDE hard disk.

[mark_k]

Originally Posted by Toni Wilen

And unfortunately A3000 test is not that useful either because there are lots more bus errors between SCSI messages and it is impossible to know which one is correct and which one is bogus.

Booting an A4000/040 config with the NetBSD 1.6 install HD image, the WinUAE log reports:
IDE0 recalibrate
IDE0 drive multiple mode = 64
(those two lines repeated another 10 times)

NetBSD doesn't automatically find the root device (which is wd0b in this case). I think it probably would on a real A4000, since booting the HD image on an A2091/A3000 the root device is detected correctly. Anyway, after specifying wd0b as the root device, there is the repeated
Process (pid 1) got signal 11
message as with installing on A3000/040 config. Log output then was:

040 BUS ERROR: fc=1 w=1 logical=0dfffff5 ssw=0021 PC=0012d04e
040 BUS ERROR: fc=5 w=0 logical=032e2000 ssw=0105 PC=0019a50c
040 BUS ERROR: fc=5 w=1 logical=01e60000 ssw=0025 PC=0012d0e2
040 BUS ERROR: fc=5 w=0 logical=032e4000 ssw=0105 PC=0012d028
040 BUS ERROR: fc=1 w=1 logical=00156000 ssw=0001 PC=0012d02e
040 BUS ERROR: fc=1 w=1 logical=0dfffd88 ssw=0001 PC=0012d02e
040 BUS ERROR: fc=2 w=0 logical=00002180 ssw=0142 PC=00002180
040 BUS ERROR: fc=1 w=1 logical=00000000 ssw=0001 PC=000021c0
040 BUS ERROR: fc=1 w=1 logical=001177a4 ssw=0001 PC=000021cc
040 BUS ERROR: fc=1 w=0 logical=001177a4 ssw=0101 PC=000021d2
040 BUS ERROR: fc=1 w=0 logical=4e560000 ssw=0121 PC=00002256
040 BUS ERROR: fc=1 w=0 logical=4e560000 ssw=0121 PC=00002256
(last line repeats over and over)

Is the "logical=" supposed to be logical addresses? Because 4E560000 looks suspicious; it's the opcode for LINK A6,#0.

[Toni Wilen]

Some 68040 and 68060 MMU emulation problems fixed. Now they both seem to work identically, including hanging in exact same position

EDIT: 68040 and 060 MMU emulation does not yet support locked read-modify-write cycles and 68060 non-locked read-modify-write cycle flag is never set.

[mark_k]

I set up a hardfile for installing OpenBSD 3.2. It's similar to the NetBSD HDFs I uploaded, except instead of booting directly into the installer the FFS partition is bootable and its startup-sequence runs the loadbsd command. The archive is about 90MB. http://www..com/file/VeQXlnoI...ot_sets_b.html

Booting with an emulated A3000/030 config, I get a crash with both 2.6.0b1 and the 2013-01-17 17:18 winuae.exe. Wine reports
wine: Unhandled page fault on read access to 0x0cf70000 at address 0x841b4a (thread 0009), starting debugger...
Unhandled exception: page fault on read access to 0x0cf70000 in 32-bit code (0x00841b4a).

Of course you'll want to check whether that happens in Windows. Booting with emulated A3000/040 it gets further but can't seem to find the root partition. The WinUAE log reports this:

UAEHF: unsupported scsi command 0x00 LUN=1
UAEHF: unsupported scsi command 0x12 LUN=1
UAEHF: unsupported scsi command 0x00 LUN=2
UAEHF: unsupported scsi command 0x12 LUN=2
UAEHF: unsupported scsi command 0x00 LUN=3
UAEHF: unsupported scsi command 0x12 LUN=3
UAEHF: unsupported scsi command 0x00 LUN=4
UAEHF: unsupported scsi command 0x12 LUN=4
UAEHF: unsupported scsi command 0x00 LUN=5
UAEHF: unsupported scsi command 0x12 LUN=5
UAEHF: unsupported scsi command 0x00 LUN=6
UAEHF: unsupported scsi command 0x12 LUN=6
UAEHF: unsupported scsi command 0x00 LUN=7
UAEHF: unsupported scsi command 0x12 LUN=7
SCSI command 1E, no direction specified (IN?)!
UAEHF: unsupported scsi command 0x1E LUN=0
SCSI command 1E, no direction specified (IN?)!
UAEHF: unsupported scsi command 0x1E LUN=0
SCSI command 1E, no direction specified (IN?)!
UAEHF: unsupported scsi command 0x1E LUN=0
SCSI command 1E, no direction specified (IN?)!
UAEHF: unsupported scsi command 0x1E LUN=0
SCSI command 1E, no direction specified (IN?)!
UAEHF: unsupported scsi command 0x1E LUN=0
SCSI command 1E, no direction specified (IN?)!
UAEHF: unsupported scsi command 0x1E LUN=0
SCSI command 1E, no direction specified (IN?)!
UAEHF: unsupported scsi command 0x1E LUN=0
SCSI command 1E, no direction specified (IN?)!
UAEHF: unsupported scsi command 0x1E LUN=0

Update: you need to enter sd0* when prompted for a root device (with A3000/040 config). It gets a little further then aborts with a bus error message.

Unlike NetBSD, OpenBSD does seem to detect that it's running on an (emulated) A1200.

[Wepl]

Originally Posted by Toni Wilen

Opword stage B replacement fixed (33012 and possibly others). Now full test set runs without hangs.

great

Originally Posted by Toni Wilen

EDIT: Could you flush the log file buffers after each test? It was quite boring to find the test that hangs because log missed all recent entries. Also option to do the full test with optional beginning test number would be nice too.

I reworked the test script. It writes before the test number into the file 'qualitycheck.last'. So you can see the last test before crash.
Further I added option 'number-' which means do all test starting with the given number.
Attached new qa.pl and shell-startup (for boot message).

I deeper checked test 91202. The stackframe is not correct.
Run 'tr 91202' and then 'Show Regs'. You will see stackframe from fault of second movem write. At offset $10 should be 'data cycle fault address', it's correct '$dff058'. At offset $18 should be 'data output buffer', it's wrong '$1100' (d0) but should be '$83.w' (d1).

[Toni Wilen]

Originally Posted by Wepl

I reworked the test script

Thanks

I deeper checked test 91202. The stackframe is not correct.

Fixed. Another bug due to MOVEM special case.

[Wepl]

thanks

there are three issues left:

93001: this has taken me a while, it seems that the instruction 'movem.l (a0),d0-a1' is not correctly executed (probably the stack frames are not correct and whdload's af-handler copies wrong data), a0=$240, after the execution the regs d0-a1=$a3a3a3a3, could there be still a bug in the movem area?

33202/33203: the stacked pc at offset 2 is different to real hardware, my observation/understanding is that on reads the stacked pc is the instruction which has faulted but on writes it is the instruction after.
as a good example #33202 does a (ea)++ which creates two faults, first a read and second a write. in the first fault the pc is at the instruction and in the second after it.

[Toni Wilen]

Originally Posted by Wepl

93001: this has taken me a while, it seems that the instruction 'movem.l (a0),d0-a1' is not correctly executed (probably the stack frames are not correct and whdload's af-handler copies wrong data), a0=$240, after the execution the regs d0-a1=$a3a3a3a3, could there be still a bug in the movem area?

Where is this movem.l (a0),d0-a1? I can't see it anywhere in 93001 test code.. It would be nice to see at least short disassembly so that I can find the code in my tests.

EDIT: Found it

33202/33203: the stacked pc at offset 2 is different to real hardware, my observation/understanding is that on reads the stacked pc is the instruction which has faulted but on writes it is the instruction after.
as a good example #33202 does a (ea)++ which creates two faults, first a read and second a write. in the first fault the pc is at the instruction and in the second after it.

Documentation only says "PC may not be the instruction that generated the faulted bus cycle". So I am not going to change this, at least not now because normal programs can't depend on it and it is difficult to get right without breaking other stuff.

[Toni Wilen]

Originally Posted by Wepl

93001

Fixed. I forgot to fetch data buffer from stack frame during movem special handling = whatever was left in internal data buffer variable was "read" from memory by movem...

[Wepl]

Originally Posted by Toni Wilen

Documentation only says "PC may not be the instruction that generated the faulted bus cycle". So I am not going to change this, at least not now because normal programs can't depend on it and it is difficult to get right without breaking other stuff.

that's ok, I also could not say how it works on movem or non aligned accesses

Originally Posted by Toni Wilen

Fixed. I forgot to fetch data buffer from stack frame during movem special handling = whatever was left in internal data buffer variable was "read" from memory by movem...

great

[mark_k]

I re-tested my NetBSD 6.0.1 HDF (http://www..com/file/kfNmf5cG...nstall_A3.html, ~84MB) with today's winuae.exe, emulated A3000/040 config.

On booting WinUAE the first few MMU-related lines in the log were:

68040 MMU: enabled=0 page8k=0
hardreset, memory cleared
SERIAL: period=372, baud=9600, hsyncs=16, bits=8, PC=f80136
68040 MMU: enabled=0 page8k=0
WD33C93 in use
68040 MMU: enabled=0 page8k=0
68040 MMU: enabled=1 page8k=1
NTSC mode lace V=59.8859Hz H=15734.2637Hz (227x262+0) IDX=11 (NTSC) D=0 RTG=0
MMU: invalid root descriptor urp for 1dfffff5 desc at 7ff8038 desc=0
040 MMU MOVES fc=1 -> 1
040 BUS ERROR: fc=1 w=1 logical=1dfffff5 ssw=0421 PC=0005852a INS=0E19
040 BUS ERROR: fc=5 w=0 logical=056ba000 ssw=0505 PC=003389ac INS=22D8
040 BUS ERROR: fc=5 w=0 logical=056bc418 ssw=0505 PC=003389ac INS=22D8
040 BUS ERROR: fc=5 w=0 logical=056be030 ssw=0505 PC=00338a1c INS=2320
040 BUS ERROR: fc=5 w=1 logical=05f00000 ssw=0425 PC=000585f2 INS=12C0
MMU: invalid root descriptor urp for 6000 desc at 7ff8000 desc=0
040 MMU MOVES fc=1 -> 1
040 BUS ERROR: fc=1 w=1 logical=00006000 ssw=0401 PC=0005854a INS=0E99
040 BUS ERROR: fc=5 w=0 logical=056c0000 ssw=0505 PC=00058544 INS=2418
MMU: invalid root descriptor urp for 8014000 desc at 7d0e010 desc=0
040 MMU MOVES fc=1 -> 1
040 BUS ERROR: fc=1 w=1 logical=08014000 ssw=0401 PC=0005854a INS=0E99
MMU: invalid root descriptor urp for 1dffef3c desc at 7d0e038 desc=0
040 MMU MOVES fc=1 -> 1
040 BUS ERROR: fc=1 w=1 logical=1dffef3c ssw=0401 PC=0005854a INS=0E99
040 BUS ERROR: fc=5 w=1 logical=05eec010 ssw=0445 PC=00338a0c INS=3320
040 BUS ERROR: fc=2 w=0 logical=08008810 ssw=0542 PC=08008810 INS=FFFF
MMU: write protected 8014034 by atc 
040 BUS ERROR: fc=1 w=1 logical=08014034 ssw=0401 PC=080088be INS=D391
040 BUS ERROR: fc=2 w=0 logical=0800ae38 ssw=0542 PC=0800ae38 INS=FFFF
040 BUS ERROR: fc=2 w=0 logical=0800ee88 ssw=0542 PC=0800ee88 INS=FFFF
040 BUS ERROR: fc=2 w=0 logical=080110d4 ssw=0542 PC=080110d4 INS=FFFF
...

[Wepl]

68060 works completely except for the missing rwm indicator in the fslw, this reduces the usability somehow for whdload.

now trying 68040, but this will take some time because snoop never worked on this cpu. I have to fix whdload for that and hope to maybe found the reason in conjunction with winuae now

[Toni Wilen]

Do you know if bitfield instructions (bfchg, bfclr, bfset and bfins) are considered read-modify-write? I assume they are but these kinds things are not always logical

EDIT: read-modify-write status bits emulated (does not include bitfields)

now trying 68040, but this will take some time because snoop never worked on this cpu.

68040 MMU is annoying, it is basically combination of worst parts of 030 and 060 MMU

68030 is very logical, full continuation model, no special cases.
68060 is very logical, full restart model, no special cases.
68040: bleh.

[Toni Wilen]

68040/060 still works incorrectly or hangs Unix-like operating systems, reason unknown (nothing new since 040 was implemented for the first time)

It is probably something messing up condition codes or some other state information in some specific bus error conditions. Probably also depends on interrupt timing because behavior usually changes when using debug builds.

More test images needed

[Wepl]

Originally Posted by Toni Wilen

Do you know if bitfield instructions (bfchg, bfclr, bfset and bfins) are considered read-modify-write? I assume they are but these kinds things are not always logical

EDIT: read-modify-write status bits emulated (does not include bitfields)

I tested on 68060:
all writing bf* seems to be rwm (bfchg, bfclr, bfins, bfset)
even a 'bfins d0,(a2){0:32}' which doesn't require a read is a rwm
the other ones are reads (bfexts, bfextu, bfffo,bftst)

Originally Posted by Toni Wilen

68040 MMU is annoying, it is basically combination of worst parts of 030 and 060 MMU

yes it seems.
I have to rewrite the complete handler because I wasn't aware that there can be multiple 'write back's in one fault, see:

Exception "Access Fault" ($7008) PC = $7FCA470 (Resload $1470) Byte Write to
$BFDC00 (ciab.sdr)

$07fca454 lea          ($bfe001),a6
$07fca45a lea          (-$1001,a6),a5                 ;$00bfd000
$07fca45e move.b       ($16,a0),($c00,a6)             ;$07fdb442 $00bfec01
$07fca464 move.b       ($16,a1),($c00,a5)             ;$07fdb45e $00bfdc00
$07fca46a move.b       (4,a0),($200,a6)               ;$07fdb430 $00bfe201
>$07fca470 tst.b        (a6)                           ;$00bfe001
$07fca472 tst.b        (a6)                           ;$00bfe001
$07fca474 move.b       (2,a0),(a6)                    ;$07fdb42e $00bfe001

exception stackframe:
$0007FFC4 200007FC A4707008 0007FFCC 04A500A5 00A50025 00BFDC00 00BFE201 00000003
$0007FFE4 00BFDC00 00000000 CCCCCCCC CCCCCCCC 200007FC A4502024 07FCA44C

  ----0---- ----1---- ----2---- ----3---- ----4---- ----5---- ----6---- ----7----
Dx     A300         0       133         0    DFF000  DDDDDD00   7FC990A  DDDD007F
Ax  7FDB42C   7FDB448   7FDB46C   7FDB318   7FD4000    BFD000    BFE001

also see that the fault pc is two instructions after the faulting one