SamMaEl wrote:
> 
> 	I don't remember who suggested it... but I tried compiling a
> kernel with MRG_ADB UNcommented. I wish I hadn't dumped all my mailing
> list emails to an archive or I would have replied and included the text.
> But, in any case, I compiled it last night and tried booting it just
> now... and it hung after making the screen white and displaying the first
> line of text about preserving so many bytes of kernel stuff.

Hmmm...how old are your sources?  What else is in your config file?  Is it
just GENERIC with MRG_ADB commented out?

> 	I seem to remember whomever I got the first kernel I booted
> successfully with telling me to COMMENT MRG_ADB if I built my own kernel,
> but then someone said that MRG_ADB was to fix a machine that the ADB was
> not supported on, or some such. Maybe someone remembers this?

The MRG (Mac ROM Glue) method of accessing the ADB was the second attempt
at supporting ADB under NetBSD.  It has been in use since about NetBSD
1.0, I think.  The idea is that we hook into the Mac ROM's to handle the
ADB since the ROM's already know how to do it.  John Wittkoski came up
with a 3rd method, which was to directly support the 4 or 5 different
types of ADB hardware available.  Takashi Hamada used John's code as a
starting point to support the PowerManager IC which controls the ADB on
PowerBooks...does that make sense?

Currently, there is some overlap between the machines supported by MRG and
those supported by John's code.  MRG _should_ support most machines except
for the IIfx, Quadra 900/950, and a few PowerBooks and 040's with the Cuda
chip (it supports some Cuda machines, but not others, I think).  John's
latest patches (which aren't in the tree yet), along with Takashi's
PowerManager code should support all machines except the IIfx/Quadra
900/950.  Why you're having trouble with it, tho, I'm not quite sure.
Perhaps you can write Takashi and ask him about it?

> 	I DO have a few questions... about some of the boot messages
> 
> Oct 30 15:46:58 yoda /netbsd: real mem = 20971520
> Oct 30 15:46:58 yoda /netbsd: avail mem = 16969728
> 
> 	Where's the other 4 MB go? 

It went to the kernel.  The kernel grabs 4MB of memory for use in kernel
data structures and in-kernel buffers.  It wires this memory down so that
it can guarantee that it won't be paged out by the vm system.  So,
userland only gets whatever's left for it's own uses.

> Oct 30 15:46:58 yoda /netbsd: mrg: '68040 PowerBook ROMs' ROM glue,
> tracing off,debug off, silent traps
> Oct 30 15:46:58 yoda /netbsd: mrg: I/O map kludge for ROMs that use
> hardware addresses directly.
> Oct 30 15:46:58 yoda /netbsd: adb: using PowerBook Duo-series and
> PowerBook 500-series hardware support
> Oct 30 15:46:58 yoda /netbsd: adb: cleanup: nothing returned
> Oct 30 15:46:59 yoda /netbsd: adb: ADBReInit complete
> Oct 30 15:46:59 yoda /netbsd: adb: PowerBook extended keyboard at 2
> Oct 30 15:46:59 yoda /netbsd: adb: extended mouse <tpad> 2-button 387 dpi 
> unknown device at 3
> 
> 	These lines would lead me to belive that there is not much of a
> problem with ADB with ADB_MRG uncommented... am I wrong??

Well...that last line seems to indicate a possible problem, unless the
trackpad really is 2-button and 387 dpi in some way...very strange
resolution for a pointing device.  It looks like the timing may be a bit
off.  If it boots past this point, it certainly looks like you've got a
working keyboard at least, so why are you bothering with commenting out
MRG_ADB?

> Oct 30 15:47:01 yoda /netbsd: sn0 at obio0: failed to get MAC address.
> 
> 	I won't worry about ethernet support til I can keep from using ls
> without it core dumping ;-)

:-)  Chances are that Allen Briggs or Denny Gentry could help you with
this one.  It's probably just a matter of figuring out exactly where the
registers are for the SONIC chip...

> Oct 30 15:47:01 yoda /netbsd: sbc0 at obio0: options=1<PDMA>
> 
> 	I noticed that in the GENERIC config it gave the SBC option with a
> flag of 0x1... but in another config I saw one with a 5 flag. What does
> this do?

I can't quite remember what 0x5 does at the moment, but I seem to remember
that when I was using it, I managed to get a lot more filesystem damage
than with only 0x1.  I do know that 0x1 is PDMA mode (which is a lot
better than 0x0 or PIO mode :-)  If you have the source, I think you can
look at it and figure out what that extra flag does...

> I looked in 'man options' but saw nothing about it... 8-( 

I don't think that many machine-dependent options are available in
options(4).  Perhaps each port needs it's own options(4) man page?  I'll
ask about this on current-users or netbsd-users...

> I've
> noticed the machine crashing into the kernel debugger, and trace showed
> some functions like valloc_ffs or something like that (I don't remember
> offhand, and now it's not wanting to crash ;-))

keep your fingers crossed ;-)

> but I remember it having
> to do with the file system, and writing to it... might the sbc
> option=1<PDMA> have to do with that, or no?

Hmmm...maybe.  You could try switching to the ncrscsi driver, but it's not
necessarily any more stable than the sbc driver (usually depends on the
kind of drive you have).

Do you remember what kind of crash you had?  Is your machine an
'LC040-base machine?  If so, you're probably hitting an FPE bug and not a
SCSI driver bug...

I hope this helps some.

Later.

-- 
Colin Wood                                 cwood@ichips.intel.com
Component Design Engineer - MD6                 Intel Corporation
-----------------------------------------------------------------
I speak only on my own behalf, not for my employer.