68030, 68040 and 68060 MMU support (really!) - Page 7

Toni Wilen · 04 January 2013, 14:05

Quote:

Originally Posted by Wepl

I started to check the 68030 with WHDLoad and my qa.slave.
There is a strange fault with many (but not all) checks while whdload is leaving and saving the contents of the custom registers.

What does the bus exception handler do with stack frame? I assume it clears DF bit and writes to data buffer field but does it do anything more interesting?

Toni Wilen · 04 January 2013, 14:41

Quote:

whdload qa.slave mmu custom1=92325 SplashDelay=0

This does nothing. Some Snoop option needed? (I tried Snoop but didn't get exactly same access order as in your log)

EDIT: Redownload winuae.zip, possible problem found (but not tested).

Wepl · 04 January 2013, 15:11

Quote:

Originally Posted by Toni Wilen

What does the bus exception handler do with stack frame? I assume it clears DF bit and writes to data buffer field but does it do anything more interesting?

On the 68030 WHDLoad uses some tricks to avoid enabling/disabling the MMU to read/write illegal/protected memory. There is transparent translation for an unused fc and it uses moves to access these areas.

Quote:

Originally Posted by Toni Wilen

This does nothing. Some Snoop option needed? (I tried Snoop but didn't get exactly same access order as in your log)

Sorry, yes SnoopOCS is required too for that check.

Quote:

Originally Posted by Toni Wilen

EDIT: Redownload winuae.zip, possible problem found (but not tested).

Thanks, will try on monday because I have no access to the test machine during the weekend.

Toni Wilen · 04 January 2013, 20:25

Looks like I guessed the problem, seems to work now. Emulation got confused if instruction was not MOVEM and it had more than one memory access and two or more faulted.

These kind of simple test cases are perfect, thanks

Wepl · 07 January 2013, 15:49

with the new WinUAE beta (2013.01.06) there is an endless loop

Code:

32-250 [3210 094-019]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 207-019]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 093-020]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 206-020]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 092-021]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 205-021]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 091-022]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 204-022]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 090-023]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 203-023]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 089-024]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 202-024]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)
32-250 [3210 088-025]: MMU: page fault (logical addr=00DFF002 SSW=0365 read=1 size=2 fc=5 pc=009d5f78)

WHDLoad is waiting for a video line number there but there is a loop limit, so it shouldn't wait forever.
Is it possible that the return from the access fault doesn't work?

probably this code:

Code:

;---------------
; macro which gets the actual vertical raster line to d0.w
; d1 will be trashed

GetVPOS	MACRO
.1\@		move.w	(vposr,a1),d0
		move.b	(vhposr,a1),d1
		cmp.w	(vposr,a1),d0
		bne	.1\@
		and.w	#1,d0
		lsl.w	#8,d0
		move.b	d1,d0
	ENDM

;---------------
; wait for vertical blank
; (vblank is 0..25)

	;wait for line > 150
		moveq	#0,d2
		moveq	#2,d3			;maximal number of loops
.w0		GetVPOS
		cmp.w	d0,d2
		bls	.w1
		subq.w	#1,d3
		beq	.w3
.w1		move.w	d0,d2
		cmp.w	#150,d0
		blo	.w0
.w3

	;wait for line < 150
		moveq	#0,d2
		moveq	#3,d3			;maximal number of loops
.w5		GetVPOS
		cmp.w	d0,d2
		bls	.w6
		subq.w	#1,d3
		beq	.w7
.w6		move.w	d0,d2
		cmp.w	#150,d0
		bhs	.w5
.w7

Toni Wilen · 07 January 2013, 16:18

EDIT: Should now work again.

Hmm.. I broke 020 addressing mode calculation bus error stuff when I fixed another problem. (Yes, code does not use 020+ addressing mode but d8,An,Xn uses same code path)

Wepl · 08 January 2013, 15:11

thanks, works better.
there is an endless loop with check 91905:

Code:

whdload qa.slave mmu custom1=91905 SplashDelay=0 SnoopOCS ChkBltWait

test code:

Code:

_bltwait_5	move.w	#DMAF_SETCLR|DMAF_MASTER|DMAF_BLITTER,(dmacon,a6)
		move.w	#%0000000111111111,(bltcon0,a6)
		move.w	#%0000000000000010,(bltcon1,a6)
		move.w	#-16-6,(bltdmod,a6)
		move.w	#0,d0
		move.w	#$1000,d1
		move.w	#3*64+3,d2
		movem.w	d0-d2,(bltdpt,a6)
		move.w	#0,(bltafwm,a6)
		rts

problem with the movem to blitsize?

Toni Wilen · 08 January 2013, 16:13

Fixed. MOVEM handling had issues. (MOVEM needs special handling too in bus error cases)

Wepl · 10 January 2013, 15:26

the actual beta hangs with

Code:

07-234 [812 072-212]: limit violation (lower limit 32767)
07-234 [812 072-212]: limit violation (lower limit 32767)
07-234 [812 072-212]: limit violation (lower limit 32767)
07-234 [812 096-212]: limit violation (lower limit 32767)
07-234 [812 096-212]: MMU: page fault (logical addr=0003D8DE SSW=0365 read=1 size=2 fc=5 pc=009db9c2)
07-234 [812 096-212]: limit violation (lower limit 32767)
07-234 [812 096-212]: limit violation (lower limit 32767)
07-234 [812 096-212]: limit violation (lower limit 32767)
07-234 [812 096-212]: limit violation (lower limit 32767)

during checks which previously worked.

Toni Wilen · 10 January 2013, 15:50

What previous one? Both tests work fine here.

Wepl · 10 January 2013, 16:18

the check

Code:

whdload qa.slave mmu custom1=91000 SplashDelay=0 SnoopOCS ChkBltSize

worked with the version from January 7th, now it hangs

Toni Wilen · 10 January 2013, 16:42

Argh, state buffer underflow, incorrectly calculated buffer usage..

All 3 tests work again

Wepl · 10 January 2013, 18:20

I made you test harddisk from where you can easily run all tests and single ones, it's in the zone named wt.zip

the test 93001 is looping with

Code:

14-343 [1669 134-307]: Software fixed stage B! opcode = 0002
14-343 [1669 136-307]: MMU: page fault (logical addr=00000002 SSW=5066 read=1 size=2 fc=6 pc=00000000)
14-343 [1669 055-308]: Software fixed stage B! opcode = 0002
14-343 [1669 057-308]: MMU: page fault (logical addr=00000002 SSW=5066 read=1 size=2 fc=6 pc=00000000)
14-343 [1669 203-308]: Software fixed stage B! opcode = 0002
14-343 [1669 205-308]: MMU: page fault (logical addr=00000002 SSW=5066 read=1 size=2 fc=6 pc=00000000)

this test will set the page at 0 to invalid and emulates executing instructions located on it (ProtectRead)

Toni Wilen · 10 January 2013, 18:40

93001 fixed (I assume it is supposed to complain about address zero access when it completes?). Untested instruction prefetch fault fetched replacement opcode from wrong offset of stack frame..

Toni Wilen · 12 January 2013, 11:34

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

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.

EDIT2: TAS, CAS and CAS2 Read-Modify-Write is now emulated (94040 and 94041)

mark_k · 12 January 2013, 23:09

Not sure this is the best thread for it, but NetBSD 6.0.1 seems to install correctly when the emulated machine has 68030+MMU. However after installing, when I boot the system with 68040 CPU, the system seems to hang after printing "root filesystem type: ffs". Happens with both A3000/040 (SCSI) and A4000/040 (IDE) configs. Equivalent configs with 68030+MMU both boot correctly.

There didn't seem to be anything obvious in the log (with 2.6.0b1).

Toni Wilen · 13 January 2013, 11:22

Nothing new, it probably has never worked properly because there is no good test cases. It hangs because it uses corrupted pointer which got corrupted much earlier. (68040 MMU is completely different)

Interestingly 68060 MMU works slightly better.

mark_k · 13 January 2013, 13:10

With the 2013-01-13 09:57 winuae.exe (but not with 2.6.0b1) I get this error output on booting my just-installed NetBSD test image. A4000/030 config. There was this line in the log output:
MMU: page fault (logical addr=0000009C SSW=0345 read=1 size=4 fc=5 pc=0018276c)

Toni Wilen · 13 January 2013, 14:31

Should work now. Don't use unofficial versions unless asked

Toni Wilen · 14 January 2013, 17:16

I think only way to solve 68040/060 MMU issues is to test all available m68k unix/linux/whatever versions and hopefully some of them have "better" crashes

07 January 2013, 16:18	#126
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	EDIT: Should now work again. Hmm.. I broke 020 addressing mode calculation bus error stuff when I fixed another problem. (Yes, code does not use 020+ addressing mode but d8,An,Xn uses same code path) Last edited by Toni Wilen; 07 January 2013 at 16:38.

10 January 2013, 16:18	#131
Wepl Moderator Join Date: Nov 2001 Location: Germany Posts: 876	the check Code: whdload qa.slave mmu custom1=91000 SplashDelay=0 SnoopOCS ChkBltSize worked with the version from January 7th, now it hangs

12 January 2013, 11:34	#135
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	Opword stage B replacement fixed (33012 and possibly others). Now full test set runs without hangs. 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. EDIT2: TAS, CAS and CAS2 Read-Modify-Write is now emulated (94040 and 94041) Last edited by Toni Wilen; 12 January 2013 at 21:42.

12 January 2013, 23:09	#136
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,349	Not sure this is the best thread for it, but NetBSD 6.0.1 seems to install correctly when the emulated machine has 68030+MMU. However after installing, when I boot the system with 68040 CPU, the system seems to hang after printing "root filesystem type: ffs". Happens with both A3000/040 (SCSI) and A4000/040 (IDE) configs. Equivalent configs with 68030+MMU both boot correctly. There didn't seem to be anything obvious in the log (with 2.6.0b1). Attached Thumbnails

13 January 2013, 13:10	#138
mark_k Registered User Join Date: Aug 2004 Location: Posts: 3,349	With the 2013-01-13 09:57 winuae.exe (but not with 2.6.0b1) I get this error output on booting my just-installed NetBSD test image. A4000/030 config. There was this line in the log output: MMU: page fault (logical addr=0000009C SSW=0345 read=1 size=4 fc=5 pc=0018276c) Attached Thumbnails

04 January 2013, 20:25	#124
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	Looks like I guessed the problem, seems to work now. Emulation got confused if instruction was not MOVEM and it had more than one memory access and two or more faulted. These kind of simple test cases are perfect, thanks

08 January 2013, 16:13	#128
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	Fixed. MOVEM handling had issues. (MOVEM needs special handling too in bus error cases)

10 January 2013, 15:50	#130
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	What previous one? Both tests work fine here.

10 January 2013, 16:42	#132
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	Argh, state buffer underflow, incorrectly calculated buffer usage.. All 3 tests work again

10 January 2013, 18:40	#134
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	93001 fixed (I assume it is supposed to complain about address zero access when it completes?). Untested instruction prefetch fault fetched replacement opcode from wrong offset of stack frame..

13 January 2013, 11:22	#137
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	Nothing new, it probably has never worked properly because there is no good test cases. It hangs because it uses corrupted pointer which got corrupted much earlier. (68040 MMU is completely different) Interestingly 68060 MMU works slightly better.

13 January 2013, 14:31	#139
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	Should work now. Don't use unofficial versions unless asked

14 January 2013, 17:16	#140
Toni Wilen WinUAE developer Join Date: Aug 2001 Location: Hämeenlinna/Finland Age: 49 Posts: 26,574	I think only way to solve 68040/060 MMU issues is to test all available m68k unix/linux/whatever versions and hopefully some of them have "better" crashes

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
68040 vs 68060	tesla	support.Hardware	10	20 April 2013 19:13
68040 MMU jsr/bsr	Toni Wilen	Coders. General	5	28 April 2010 20:57
68060 fpu not available mmu not active	amigarlz	support.Hardware	6	18 March 2010 06:35
WTB: 68030 or 68040 accelerator for A2000	Shadowfire	MarketPlace	2	19 September 2009 17:52
68030/mmu Support in WinUAE	dkovacs	request.UAE Wishlist	19	22 August 2005 14:42