68030, 68040 and 68060 MMU support (really!)

[Toni Wilen]

Ah, it must have been 1.1 that didn't work.

[Toni Wilen]

Same image (NetBSD_1.3.3_4G_HD) seems to boot fine here, 68060 MMU.

(I am still wondering about that "no battery block" message)

[mark_k]

Strange. The configs I tested with are attached, I get a crash with both A3000/060 and A4000/060. (Did you try unpacking the HDF archive again? Maybe not using a fresh copy could cause some change in the boot sequence so the crash doesn't happen?)

I'm not sure why the message about no clock found appears either. But if you check the NetBSD 1.2 src/sys/arch/amiga/dev/clock.c, it does look a little strange. See rtcinit() near line 745. It sets clockaddr to 0xDC0000, then seems to access addresses based off that, even on A3000/4000. (Is the A3K/4K Ricoh RTC at 0xDC0000 too??) Using an A2000 config NetBSD does find the RTC.

[Toni Wilen]

Originally Posted by mark_k

Strange. The configs I tested with are attached, I get a crash with both A3000/060 and A4000/060.

It was CPU "More compatible" checkbox (=don't emulate missing 68060 integer instructions), it created incorrect PC field in exception stack frame that confused software emulation routine. Fixed now.

(Is the A3K/4K Ricoh RTC at 0xDC0000 too??) Using an A2000 config NetBSD does find the RTC.

Address is exact same, both have 16 registers. Time registers are mostly same, config/status registers are totally different.

EDIT: I think clock detection problem is caused by this "if (range_test(year, STARTOFTIME, 2000)) return(0);". Also year was originally counted as number of years from 1900 but because clock chip has limited range (BCD counters), it was later changed to last 2 digits of year. UAE uses new method when Ricoh clock is used, other clock uses original for compatibility reasons.

[mark_k]

Ah. If you look at the a34kbbc.c history, scroll down to revisions 1.4/1.5/1.6. Commit comments for those revisions are below. You can click the links to see diffs from version to version.

1.4:

*sigh*
Y2000-patch for A2000, A3000 and A4000 battery backed clock modules,
mostly by Adam Ciarcinski.

1.5:

Write part of the y2k fix.
This is not strictly necessary, as
- at least for the Ricoh chip in the A3000 and A4000, as those chips' Y10
  registers happily continue to count up from 0xA if manually incremented
  past 0x9.
- the Amiga ROMs and "setclock" commands seem to interpret 0xA 0x? like
  200?, etc.

However,
- the Amiga setclock writes the modulo 10 value into the chips
- the chip docs of both chips, including the Y2K information of their
  manufacturers, only refer to the range 0-9
- the chips increment from 9 to 0

So we better conform to this, to avoid unpleasant surprises.

1.6:

The Ricoh chip has a seperate leapyear counter.
We must write this when we write the year register, keeping them in sync.
XXX the chosen algorithm only works for 1901 <= year <= 2099.

According to the NetBSD/amiga year 2000 compliance page NetBSD 1.4.2 was the first Y2K-fixed NetBSD release. So hopefully all versions after that should find the clock running in WinUAE.

[strim]

Originally Posted by mark_k

So hopefully all versions after that should find the clock running in WinUAE.

You may have problems with NetBSD 6 and A2000-style RTC clock. But that's a bug in NetBSD that was fixed recently (in case of a problem just use daily binary build of HEAD branch from releng.netbsd.org).

[mark_k]

Originally Posted by Toni Wilen

I am not so sure about software FPU emulation support because all FPU instructions generate standard line-f exception if CPU is 68020 or 68030 and FPU is missing. Nothing special should be needed.

Since I got the problem with 68030 + no FPU testing NetBSD 6.0.1, I thought it was possible there has been some regression with NetBSD and no FPU, if all the NetBSD devs' machines have FPUs.

But I just tested with NetBSD 1.3.3 and that also crashes without FPU. NetBSD 1.3 was the first version which is supposed to work without FPU. The error message is different, screenshot attached. There is no relevant output in the WinUAE log.

[Toni Wilen]

It attempted to execute FPU instruction. I still don't think it can work without FPU. Possibly kernel works but applications compiled with FPU won't, can't find any kind of m68k FPU emulation layer.

[mark_k]

This mailing list thread is from someone with an A600 + ACA630 accelerator (with no FPU) who says they successfully used NetBSD on it.

[Toni Wilen]

Different kernel with FPU emulation compiled in? As usual, I won't assume anything. Must have confirmed working exact same installation.

[mark_k]

I thought that might have been the reason for the problem. Perhaps the NetBSD installer installs an FPU-only kernel when run on a machine with FPU. So booting an already-installed NetBSD HDF on an FPU-less machine would not work.

But I just tried running the NetBSD 1.3.3 installer with A3000/030/noFPU config and got a couple of Illegal instruction messages. This line was output a couple of times in the WinUAE log:
B-Trap f227 at 1015b6 (00000000)

Running the 6.0.1 installer I got the first Illegal instruction message after typing y to proceed with installation.

Edit to add: Same with with emulated A600/030noFPU config. (At the initial boot prompt you need to type netbsd -c600 to tell the boot loader it's running on an A600, since it's not clever enough to figure that out.)

[strim]

Originally Posted by mark_k

Since I got the problem with 68030 + no FPU testing NetBSD 6.0.1, I thought it was possible there has been some regression with NetBSD and no FPU, if all the NetBSD devs' machines have FPUs.

I have an A600 with ACA630 (so no FPU) and HEAD branch NetBSD works just fine. I'm not sure about 6.0.1, but I think that nothing FPU-related has changed since 6.0. So it should work too.

And I think that all SHARP X68000 machines used by devs don't have FPU. So they would also notice.

Kernel does not use FPU at all, even on FPU enabled machines. So the problem with FPU emulation will appear only when running user space program.

FPU emulation is implemented in src/sys/arch/m68k/fpe.

[Wepl]

Originally Posted by strim

Kernel does not use FPU at all, even on FPU enabled machines. So the problem with FPU emulation will appear only when running user space program.

I can hardly believe that the kernel doesn't use fpu instructions because for task switching it has to save/restore the status/registers.

[strim]

Originally Posted by Wepl

I can hardly believe that the kernel doesn't use fpu instructions because for task switching it has to save/restore the status/registers.

That's the only exception. Other than that using FPU in kernel is forbidden.

[mark_k]

In case it might help figure out what's going on, the code which prints messages like Illegal instruction seems to be in src/sys/arch/amiga/amiga/trap.c.

[Toni Wilen]

It appears to be loader problem, loadbsd works, gobsd does not. (1.3.3 tested)

Line-F vector is not modified when gobsd is used (points to original fpfline function) but it points to fpemuli (fpu emulation function) when loadbsd is used.

It seems "vectab" does not point to correct address when gobsd is used. (vectab[11] = fpuemuli is in machdep.c)

EDIT: updated winuae.zip required, 68020/030 without FPU F-line exceptions got slightly broken in previous 68040+ FPU updates..

[mark_k]

I'll check the latest winuae.zip.

With the previous winuae.zip, I just tried running the NetBSD 1.3.3 installer (as opposed to booting the full pre-installed OS) using loadbsd netbsd with A3000/030/no FPU config and got the Illegal instruction messages. The same happened when I booted the pre-installed 1.3.3 HDF to multi-user mode with loadbsd -a netbsd.

What about the NetBSD 6.0.1 boot loader though? Later versions of NetBSD don't use loadbsd/gobsd, they use custom boot code.

[mark_k]

With the latest winuae.zip and A3000/noFPU config there are still some Illegal instruction messages on booting the pre-installed NetBSD 6.0.1 HDF.

And running the NetBSD 1.6.2 installer, there is an Illegal instruction message at the creating filesystems stage.

[Toni Wilen]

I don't really care anymore, everything points to loader bug or something similar, I am not going to waste anymore time to debug this.

Perhaps it assumes running setpatch or something.

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.

[strim]

Originally Posted by mark_k

What about the NetBSD 6.0.1 boot loader though? Later versions of NetBSD don't use loadbsd/gobsd, they use custom boot code.

NetBSD boot block loader should be functionally equivalent to loadbsd. Also, using loadbsd is still a supported way to boot the kernel.