Re running the most recent current kernel, I had written:

> Well I tried it.  With the most recent GENERIC 82 kernel (22/08/98) I get:
> 
> == START ==
> 
> Bootstrapping NetBSD/mac68k.
> Getting mapping from MMU.
> System RAM: 10452992 bytes in 2552 pages.
>      Low = 0x0, high = 0x9f8000
>   no internal video at address 0 -- videoaddr is 0xfee09a80.
> Done.
> Bootstrapping the pmap system.
> Pmap bootstrapped.
> Moving ROMBase from 0x40a00000 tp 0x9fa000.
> Video address 0xfee09a80 -> 0xbfaa80.
> 
> == STOP ==
> 
> Then I have to hit the bong button ...

Now I can compile my own kernels, I tried something.

I put 2 printf statements either side of the final line on 
pmap_bootstrap.c - that's the one that actually resets the videraddr 
variable to 0xbfaa80.  Only the first line is printed.  the second never 
appears on the screen.

[Of course, this could be for other reasons, but given the lack of a 
debugger, it's the only way I could think of to get extra information.]

With the C2 kernel, I have:

== START ==
 
Bootstrapping NetBSD/mac68k.
Getting mapping from MMU.
System RAM: 10452992 bytes in 2552 pages.
     Low = 0x0, high = 0x9f8000
  Classic II video (0xfee09a80) internal video at addr 0xfee09a80 (phys 
0x9f9a80), len 0x8000.
Done.
Bootstrapping the pmap system.
Pmap bootstrapped.
Moving ROMBase from 0x40a00000 to 0x9f9000.
Video address 0xfee09a80 -> 0xbf9a80.

== STOP ==

and the boot continues from there.  The slight differences in addresses 
in the above are red herrings as the upper was with current and the lower 
was with the C2 kernel, which is based on the 1.3.2 code.  If I boot with 
the 1.3.2 kernel, I get exactly the same addresses as the lower, but it 
still hangs.

I then replaced the line in machdep.c that prints out the "no internal 
video" with one to output the mac68k_vidlen variable.  But when I 
recompiled, I get:

On-board video at addr 0xfee09a80 (phys 0xfee09a80), len 0x5580

This wasn't the line I expected and comes from earlier in the machdep.c 
code.  Very strange - why does adding a printf line lower in the routine 
force if to output this line (something that it should have anyway as the 
Classic II should have the mac68k_vidlen variable set).  The last time I 
saw this behaviour it was due to an incorrectly called routine writing to 
inappropriate memory locations as it searched for arguments it hadn't 
been provided with and hence screwing up some data - but that was 
Fortran, not C :-(

Should I read any significance that the len variable is differenct from 
the 0x8000 above? Well, I forced it by setting the mac68k_vidlen variable 
to 32768 just before the nubus stuff is done.  That got the same length I 
was expecting (0x8000) but didn't cure the problem.

By the way, the reason it is 0x8000 and not 0x5580 is that mac68k_vidlen 
is set to 21888 (512x342 bits in bytes) using the definitions earlier in 
the file but check_video then changes this to 32768.  This confirms my 
previous assertion that one of (and indeed the only one I could find) 
between the 1.2 IntVid code and the 1.3.2 code is a call to check_video 
is missing in the latter for cases which are "on-board video".  Setting 
mac68k_vidlen is the only side effect calling check_video does.  So why 
doesn't it work????

As an act of desparation, I put in a call to check_video:

mac68k_vidlen = 32768;
if (mac68k_vidlen > 0 ) {
  check_video("Classic II", 21888, 21888);

Still no life.

Sorry about the length.  Does this help anyone?  Where should I look next?

Yours,

Andrew



* ---------------------------------------------------------------------- *
Running NetBSD version 1.3.2 on a Classic II
See http://www.foakes.demon.co.uk/NetBSD.html for details