68030, 68040 and 68060 MMU support (really!)

[mark_k]

Originally Posted by Toni Wilen

EDIT: you can easily check if f-line vector is correct, break to debugger after netbsd has booted, type "mmu 5", "i", check address of LINEF EMU, disassemble it, it is wrong if it starts with cmp.w #$202c,something (this is correct if 68040+ or 68881 or 68882 is installed) and correct if it starts with addq.l #1,something.

I tried that after starting the NetBSD 1.6.2 installer and got this for the LINEF EMU code:

d 022de
000022DE 52b9 001d 64b0           ADD.L #$00000001,$001d64b0
000022E4 42a7                     CLR.L -(A7)
000022E6 48e7 ffff                MOVEM.L D0-D7/A0-A7,-(A7)
000022EA 7010                     MOVE.L #$00000010,D0
000022EC 60ff ffff fd3c           BT .L #$fffffd3c == $0000202a (T)
000022F2 0cb9 ffff fffe 001d 6394 CMP.L #$fffffffe,$001d6394
000022FC 66ff ffff fda0           BNE.L #$fffffda0 == $0000209e (T)
00002302 4ef9 0000 cb88           JMP.L $0000cb88
00002308 42a7                     CLR.L -(A7)
0000230A 48e7 ffff                MOVEM.L D0-D7/A0-A7,-(A7)

[Obviously the NetBSD FPU emulation code isn't coded too tightly; ADD.L could be ADDQ.L, MOVE.L could be MOVEQ, BRA.L could be BRA.W... ]

Whatever you fixed in the latest winuae.zip definitely improved things. Maybe there are still problems with some other instructions though.

[Toni Wilen]

Originally Posted by mark_k

[Obviously the NetBSD FPU emulation code isn't coded too tightly; ADD.L could be ADDQ.L, MOVE.L could be MOVEQ, BRA.L could be BRA.W... ]

Do not trust UAE debugger too much, better check the opcode encoding first
(Q for example isn't shown)

[mark_k]

strim: Would you be able to build a NetBSD kernel which gives more information than just "Illegal instruction"? Maybe the instruction opcode and address and anything else which might help figure out the problem.

[strim]

Originally Posted by mark_k

strim: Would you be able to build a NetBSD kernel which gives more information than just "Illegal instruction"? Maybe the instruction opcode and address and anything else which might help figure out the problem.

I can try modifying trap hander to print some more information. But I'm not sure when I'll have a few spare minutes to do that.



If you have some free time and C background you can try doing it yourself. Cross-compiling NetBSD is possible from Linux (or any other UNIX-like) and documented quite well.

Basically what needs to be done is to add a printf inside T_ILLINST|T_USER case that will dump important information from frame.

[Toni Wilen]

Originally Posted by mark_k

strim: Would you be able to build a NetBSD kernel which gives more information than just "Illegal instruction"? Maybe the instruction opcode and address and anything else which might help figure out the problem.

This does not help because trap handler points to original exception handler, not FPU emulation handler! Problem is somewhere in initialization/loader.

[strim]

Originally Posted by Toni Wilen

This does not help because trap handler points to original exception handler, not FPU emulation handler! Problem is somewhere in initialization/loader.

I can't reproduce this on a real FPUless machine (A1200 + ACA1232). And it does not matter if I'm using boot block loader or loadbsd.

[Toni Wilen]

Only 1.3.3 (possible other older versions too) have this problem. 6.x seems to work fine, LINE-F vector is correct and points to FPU emu code.

EDIT: Old versions also have VBR in chip ram.

[mark_k]

So I guess there must be some other problem causing the illegal instruction messages with NetBSD 6.0.1. You can see them either booting the pre-installed HDF, or running the installer when it fails at the creating filesystems stage. Booting the pre-installed HDF, some user programs in the startup sequence crash (/usr/sbin/syslog, awk and something related to fontconfig cache in the screenshot I posted before). Those crashes are not fatal though, and you can get to the login prompt, log in and type halt to shut down.

Could you upload a winuae.zip which doesn't have the limit on B-Trap messages? The normal WinUAE only prints the first 20.

[Toni Wilen]

I thought you meant you get exact same behavior with old and new winuae versions.

winuae.zip updated, no A/F-line log limits.

[mark_k]

I wonder if the underlying cause is somehow MMU-related? Anyway, I've attached logs from booting the NetBSD 6.0.1 installer (illegal instruction message when it reaches creating filesystems stage), and booting the pre-installed HDF. Some extracts... nothing really caught my eye except maybe the line B-Trap f240 at 4 (04F80004). But then, I wouldn't know what to look for.

Booting the NetBSD 6.0.1 installer, the last few B-Trap lines before illegal instruction message:

B-Trap f200 at e4bf8 (05064BF8)
B-Trap f22e at 5200a (04FD200A)
B-Trap f23c at 52010 (04FD2010)
B-Trap f22e at 5201c (04FD201C)
B-Trap f227 at 11b05c (0509B05C)
B-Trap f22e at 11b0ea (0509B0EA)
B-Trap f28e at 11b0f4 (0509B0F4)

Booting the pre-installed NetBSD 6.0.1 HDF, last few B-Trap lines before syslog crash message:

B-Trap f22e at 2ba4 (04F82BA4)
B-Trap f227 at 2a24 (04F82A24)
B-Trap f22e at 2ba4 (04F82BA4)
B-Trap f210 at 8185014 (05F00002)
B-Trap f23c at 8185018 (05F00002)
B-Trap f29b at 8185028 (05F00002)

Last few before fontconfig segmentation fault message:

B-Trap f23c at 80364fa (05F00002)
B-Trap f29d at 803650a (05F00002)
B-Trap f23c at 8036532 (05F00002)
B-Trap f200 at 803653e (05F00002)
B-Trap f200 at 8036542 (05F00002)
B-Trap f21f at 803697c (05F00002)
B-Trap f21f at 8036984 (05F00002)
B-Trap f200 at 8036988 (05F00002)
B-Trap f240 at 4 (04F80004)

Last few lines before awk illegal instruction message:

B-Trap f227 at fdfc (04F8FDFC)
B-Trap f22e at fe0c (04F8FE0C)
B-Trap f22a at fec6 (04F8FEC6)
B-Trap f22e at ff48 (04F8FF48)
B-Trap f202 at 9c2e (04F89C2E)
B-Trap f210 at 9c38 (04F89C38)
B-Trap f294 at 9c40 (04F89C40)

[Toni Wilen]

Should work now. FDBcc and FScc had wrong PC address in line-f stack frame.

[mark_k]

Nice work, NetBSD 6.0.1 now seems to boot fine without FPU. (Can't start X, but that applies with FPU too, so not related to this issue.)

More test results without FPU...
Pre-installed NetBSD 1.3.3 HDF seems to boot fine, can start X.
Pre-installed NetBSD 1.6.2 HDF seems to boot fine to console. However I can't start X. The screen clears then returns to the console with a Segmentation fault - core dumped message. (X does start correctly with FPU.)
Running the NetBSD 1.6.2 installer without FPU gives a similar error to the 2.1 installer below.

There may be one(?) remaining problem which shows up with NetBSD 2.1.
NetBSD 2.1 installed HDF (68.3MB) Multiupload link
NetBSD 2.1 pre-installation HDF (1.5MB) Multiupload link
WinUAE logs for booting installed NetBSD 2.1, and for running the installer (726KB) Multiupload link

I booted the pre-installed NetBSD 2.1 HDF with and without FPU. With FPU it works fine, you can log in and start X. Without FPU, the boot sequence hangs after printing Starting motd.
Looking at the log output, it seems to get into an infinite loop, printing many B-Trap lines, eventually the last two repeating over and over:

...
B-Trap f200 at c438 (04F8C438)
B-Trap f240 at c43c (04F8C43C)
B-Trap f22a at 105c2 (04F905C2)
B-Trap f200 at c5ca (04F8C5CA)
B-Trap f202 at c5ce (04F8C5CE)
B-Trap f227 at 80d802c (05F00002)
B-Trap f22e at 80d93c2 (05F00002)
B-Trap f227 at 80d802c (05F00002)
B-Trap f22e at 80d93c2 (05F00002)
B-Trap f227 at 80d802c (05F00002)
B-Trap f22e at 80d93c2 (05F00002)
...

Running the NetBSD 2.1 installer, that fails at the creating filesystem stage. NetBSD prints

Creating filesystems...
uid 0, pid 50, command newfs, on /: file system full

/: write failed, file system is full
[1]   Segmentation fault      newfs /dev/r${_d...

The last few B-Trap lines in the log (which might actually relate to whatever ran after newfs crashed, so you might want to view the full log) were:

B-Trap f227 at 20274 (04FA0274)
B-Trap f22e at 20ec4 (04FA0EC4)
B-Trap f227 at 29934 (04FA9934)
B-Trap f22e at 2a962 (04FAA962)
B-Trap f227 at 29934 (04FA9934)
B-Trap f22e at 2a962 (04FAA962)
B-Trap f227 at 20274 (04FA0274)
B-Trap f227 at 20274 (04FA0274)

[Toni Wilen]

Either there is bug in this netbsd version or there is some MMU related issue because this can't be caused by (missing) FPU.

[CFou!]

Hi Tony

thanks for you MMU support.

but since first winuae MMU support there are incompatibility with HRTmon build-in version and whdload when you use MMU features although HRTMON is well recognized by WHDLoad at launch.

Bert (WEPL) has just sent to my an whdload beta version which allow all hrmon read access memory.

but when you enter in hrtmon build-in version it's freeeze inside hrtmon on red screen (it works well without MMU)

I think the crash is due to the fact that the version in build-VBR hrtmon move WHDLoad or do not support the monitor moves the VBR.

Is it possible to add in WinUAE one second build-in version with 'no move VBR' option activated (leaving the choice to the user)?

Regards,

[Toni Wilen]

VBR move is not enabled in hrtmon. Can't do anything without exact instructions and required executable(s).

[CFou!]

Originally Posted by Toni Wilen

VBR move is not enabled in hrtmon. Can't do anything without exact instructions and required executable(s).

it's really curious i will send you more info tjsi evening

[CFou!]

here winuae debugger screen when there are red freeze screen.

i have uploaded in TheZone:
- whdload beta version (with hrtmon build-in version allowed by whdload by MMU)
- winaue config file
- savestate

regards

[Toni Wilen]

Originally Posted by CFOU!

here winuae debugger screen when there are red freeze screen.

Can't duplicate. I only get normal whdload error requester that says a1000c (built-in hrtmon entry point) can't be accessed due mmu access fault.

[CFou!]

Originally Posted by Toni Wilen

Can't duplicate. I only get normal whdload error requester that says a1000c (built-in hrtmon entry point) can't be accessed due mmu access fault.

Thanks

you cought reproduct red freeze all time but:

- first you must install whdload beta version done by Bert for mmu+hrtmon build-in support test if not whdload crash because hrtmon access memory not allowed....
(include file crashHRTMON.rar in TheZone!)
- The HRTmon built into WinUAE can only be detected if HRTmon has been previousy activated at least one time (press key PgUp). Because on first activation the NMI vector will be set which is used by WHDLoad to locate the monitor. (cf.http://www.whdload.de/docs/en/freezer.html)


so if you launch one time hrtmon build-in version before launch whdload MMU code must allow hrtmon adrress access but it's cause red screen without exit on whdload outbut debug window

[Toni Wilen]

MMU: page fault (logical addr=00A9F000 SSW=0345 read=1 size=4 fc=5 pc=00a10ee4 ob=0000003f ins=22D8)

Keeps repeating.

My guess is that A90000-A9FFFF is mapped as invalid. (Built-in HRTMon starts from A10000 and requires full 512k)