> 
> NetBSD 1.2A (GENERIC) #21: Sat Nov  9 10:16:20 EST 1996
>     briggs@puma:/u/home/briggs/netbsd/sys/arch/mac68k/compile/GENERIC
> Apple Macintosh Quadra 840AV  (68040)
> real mem = 33554432
> avail mem = 29630464
> using 204 buffers containing 835584 bytes of memory
> mrg: kernel has no ROM vectors for this machine!
> adb: using serial console
> mainbus0 (root)
> obio0 at mainbus0
> adb0 at obio0 (ADB event device)
> esp0 at obio0: address 0x898000: NCR53C96 25Mhz, target 7
> scsibus0 at esp0
> sd0 at scsibus0 targ 2 lun 0: <HP, C2247, 0BC4> SCSI2 0/direct fixed
> sd0: 1003MB, 2051 cyl, 13 head, 77 sec, 512 bytes/sec
> cd0 at scsibus0 targ 3 lun 0: <MATSHITA, CD-ROM CR-8008, 8.0e> SCSI2 5/cdrom rem
> ovable
> sd1 at scsibus0 targ 6 lun 0: <QUANTUM, CTS40S, 4.07> SCSI2 0/direct fixed
> sd1: 40MB, 1536 cyl, 1 head, 53 sec, 512 bytes/sec
> zsc0 at obio0 chip type 0
> zstty0 at zsc0 channel 0
> zstty1 at zsc0 channel 1 (console)
> fpu0 at obio0 (mc68040)
> nubus0 at mainbus0
> root on sd1a swap on sd1b
> PRAM time does not appear to have been read correctly.
> PRAM: 0x83da4f80, macos_boottime: 0x328d9938.
> init: not found
> panic: no init
> Stopped at      _Debugger+0x6:  unlk    a6
> db>
> 
> 	If Serial Console is turned off, the mrg: and adb: messages appear
> they should:
> 
> mrg: 'Quadra AV ROMs' ROM glue, tracing off, debug off, silent traps
> mrg: I/O map kludge for ROMs that use hardware addresses directly.
> adb: bus subsystem
> Got following HwCfgFlags: 0xfc00, 0x4900081f, 0x 300bf26, 0x  9393b8
> mrg: setup_egret:
> mrg: setup_egret: done.
> adb: mapped device (5) at 2
> adb: 200 dpi mouse at 3

Weird. What happens if you boot with serial echo on? This booting works
(AFAIK) on other systems. Grr. I'd really need an 840av to play with to get
it to work. :-(

> 	Now that I have a good working system, I'm going to start stealing
> the drivers from the MkLinux source (I found drivers for NCR53C94 and Cuda
> chips) and patching them into the kernel.
> 
> * Anyone know of the differences between the 53C94 (which the Quadra 660av
>   and 840av machines have) and the 53C96 (which the other Quadras use)?
> 
> * I know Steve Campbell FTP'd AMD's technical docs for the 53C96.
>   Does the same site have 53C94 docs?
> 
> * I read on the Mac Linux page that source code from our kernel is deemed
>   not acceptable for distribution by the Linux maintainers, and that the
>   code from the MkLinux src may not be either. Is Linus just being choosy?

"Deemed not acceptable?" If those were the exact words, then they are
probably being choosy. But there is a problem with mixing GPL'd code
with non-GPL'd code. Basically you can't distribute an amalgamation of
GPL'd and non-GPL'd code. It's from the clause of the GPL which tries
to keep people from taking GPL'd code and making proprietary additions
to it, and selling the whole.

(I know this as I've looked at porting a GPL'd mac fs package to NetBSD.
We probably will, but it won't go in the kernel.)

The thing is that our kernel contains code with explicit directions on what
you can and can't do with it, typically words like "you can use it, but
you can't say you wrote it, you have to keep this message intact, and
no warranty." Adding more restrictions on its distribution is NOT an
option given to us by the copyright holder. But under GPL, we'd have to
ensure that all future modifications of the whole thing were GPL'd.
We'd have to change the restrictions on code we got from others.

AFAIK, the MkLinux microkernel is under a BSD-esque copyright, not GPL.
Thus it can't be included in a binary amalgamation with GPL'd code. So
that code can't wind up in a monolithic (non-microkernel) Linux-PowerMac
port.

The reason you can use MkLinux (with Linux GPL'd and the microkernel not)
is the same reason we could use GPL'd lkm's. GPL covers compile-time
linkings. It does NOT cover run-time linkings (this question has been
specifically asked of the FSF folks I hear). So you can't make one big
program file which contains GPL'd and non-GPL'd code. But you can make
two binary files (one GPL and one not) and have them link together at
run time. So a GPL'd lkm is fine for us, and a non-GPL'd lkm is fine for
them.

> * Does anyone know what the story might be if I, say, used cuda.c from
>   MkLinux src? The file header says that it can be distributed if the headers
>   remain intact. (and they actually used some early NetBSD ioctl code, the
>   copyright headers are still there!)
>   Can we subsequently modify and re-distribute?

As I understand it, YES. The fact they included NetBSD code indicates
there's no strong naughtyness. And I've heard tell that the NetBSD code
helped them get up to speed faster in a few places, so it'd be fair. The
thing I'd love to see would be DBDMA support eventually work into our
kernels. But cuda and 53C94 support would probably be equally or more
important in the short term.

Take care,

Bill