Some info about macbsd and the 040, and IDE too :

- An unexpected trap on the 040 is 90% of the time a badly
  handled bus error. The handling code is broken, and since
  I don't know 040 stack frames nor do I have any doc about
  them I can't fix it.

- The io mapping is broken. In fact, I think it's a matter of luck
  that macbsd works. Here is the problem :

Before pmap bootstrapping, io adresses are set in machdep.c, function
setmachdep. For example for quadras it's :

	case MACH_CLASSQ:
		VIA2 = 1;
		IOBase = 0x50f00000;
		Via1Base = (volatile u_char *) IOBase;
        [...]

This is a physical address, since before pmap bootstrapping the MMU is
off.

Then the pmap is bootstrapped. Some pages are reserved for the ios and
are mapped that way (pmap_bootstrap.c/pmap_bootstrap)

	pte = PA2VA(iiopa, u_int *);
	epte = PA2VA(rompa, u_int *);
	protopte = INTIOBASE | PG_RW | PG_CI | PG_V;
	[...]

The important point is that the virtual pages mapping starts at address
INTIOBASE. Then IOBase is computed (same function) :

	IOBase = (u_long)mac68k_ptob(nptpages*NPTEPG -
			(IIOMAPSIZE + ROMMAPSIZE + NBMAPSIZE + VIDMAPSIZE));

This means that IOBase points at the start of the virtual addresses mapped
to the io (yes, really ;-). In other term, accessing to the memory address
IOBase accesses to the physical IO address INTIOBASE.

Then io adresses are recomputed via mac68k_set_io_offsets(IOBase); (in
pmap_bootstrap.c/bootstrap_mac68k) which leads for the quadras to (machdep.c) :

void
mac68k_set_io_offsets(base)
	vm_offset_t base;
{
	[..]
	case MACH_CLASSQ:
		Via1Base = (volatile u_char *) base;
	[...]

So, what should the value of INTIOBASE be ? Easy, you'd say, 0x50f00000.
Now let's look at cpu.h :

/* This should not be used.  Use IOBase, instead. */
#define INTIOBASE       (0x50000000)

You lost, thanks for having played... I think this is definitively broken,
that this define should go away and that pmap_bootstrap() should use IOBase
instead. But I'm not the one who write the code in the first place, and someone
may know better. Note that a quickly hacked 040 get_physical equivalent shows
the physical address accessed at IOBase is 0x50000000, not 0x50f00000.

A funny thing is that it (mostly) works anyway. Probably a side effect of old
24-bits oriented hardware. But it does not work anymore for the latest devices,
like IDE.

Speaking of IDE the first version of the driver is nearly finished (synchronous
access, one sector a time, but it works). It crashes with a panic("swap_init") but
I'll quickly fix that (three candidates : autoconf.c, swap_generic.c or the fact
that I didn't implement ioctl for now ;-). Too bad JPW's .90 patches do not work
no matter of INTIOBASE value because we would have had a booting 630 by the end
of the week :-)

  Sarayan

PS: Ok it's a long letter but when I find a bug I feel important in others code
    I think I have to justify what I say.