With the current system, booting on a PowerBook 520 panics with the 
message "Don't know how to relocate video!".

Analysis: This happens because the variable mac68k_vidlog has not
been initialized even though videoaddr has been set to 0x60000000 via the 
Booter's environment settings.

In get_mapping() in machdep.c there is some code that tries to handle
the PB500 video at 0x60000000, but when you look at bootstrap_mac68k(),
you'll notice that get_mapping() is only called on 68030 CPU's with
the MMU active.

Looking at locore.s around start reveals that on 68040's the MMU is
unconditionally turned off, and a zero-value is passed as the TC register
value to the tc parameter to bootstrap_mac68k.

Question: Why is the MMU(s) turned off for the 68040?

Experiment #1: I added the following code just after the call to 
pmap_bootstrap(), i.e. before the test of (mac68k_vidlog):

   if (videoaddr == 0x60000000) {
     u_long phys = 0x60000000;

     mac68k_vidlog = videoaddr;
     mac68k_vidphys = phys;
     mac68k_vidlen = 32768;
   }

This code is a stripped-down version of the corresponding code in 
get_mapping that did not get called.

Now the result is that the boot process dies silently after printing
the message "Video address 0x%x -> 0x%x.".

Remark: Whenever booting stops/disappears just after this message, a
more probable diagnosis is that booting fails when or after the MMU is
(re-)enabled in locore.s after the call to bootstrap_mac68k. This may 
show up as having the screen output go into the blue air...

Experiment #2: After playing a bit with printf's and reading code, I 
realized that the assignment to mac68k_vidlog and friends need to be done 
before calling pmap_bootstrap. I now moved the above cited code up after
the else part to the "if ((tc & 0x80000000..." test, i.e. just before
the assignment to nextpa.

Hurray, now the boot proceeds after the enabling of the MMU, and I get
more messages from the boot sequence, indicating that the pointer to the
video memory survives the bootstrapping of the MMU/page tables.

Question at this point: I think that the setting of mac68k_vidlog above 
is correct, but I am more doubtfull about mac68k_vidphys, but as the MMU
is disabled, (and by experiment), it looks as it might be correct to set 
it to the same as mac68k_vidlog, but someone with more understanding
of the MMU may correct me here. The value of mac68k_vidlen, I just stole
from get_mapping. This only works with the screen set to black-and-white, 
not with 4-bit gray scale.

Before committing this code to CVS, a better test for doing the above
cited assignments should be done -- the best I can think of right now is 
along the line:
   if (mmutype == MMU_68040 && videoaddr == 0x60000000) {
     /* try to identify Powerbook 520 internal video */
   ...
   }

After doing this, the boot process stops because the array cpu_models
does not contain an entry for the PB 520. To do this, I add a line

    #define MACH_MACPB520         72

to mac68k/include/cpu.h. This value is taken from the booter's dump
of the environment just before booting. I am not sure whether or not all 
the PB 500 series models have the same or different machine id's. If they 
all share the same value, the name of this macro could be MACH_MACPB500.

In the initialization of cpu_models[] in machdep.c, I add a line

	{MACH_MACPB520, "PowerBook", " 520 ", MACH_CLASSPB, &romvecs[8]},

where romvecs[8] is a present but currently unused entry for the PB500's.
After filling out the value of PmgrOp with 0x400d9302 to resolve 
complaints about trap A085 being undefined, I can now report that the PB 
520 boot sequence proceeds from the code in arch/mac68k/mac68k to main()
in kern/init_main, where i can see the result of a printf in the beginning
of this function.

The boot process still bombs very early with messages related to the 0x85
trap, i.e. PmgrOp, but I think that now is the time to report the current
status.

As I have noticed that on a running MacOS, the PB 520 has a RAM-based
patch to the ROM-based PmgrOp, we may end up with the unpatched version 
being un-usable, but let us hope that this is not the case.

Users with PB500 models other than the 520 could try to run the booter
without having to install any unix file system and even without a kernel
and just checking the "Show dialog & wait for OK before booting" and 
unchecking "No env dumps". If any model reports macos_video different 
from 0x60000000 or machineid different from 72, the code fragments cited 
in this message have to be augmented.

regards
Erik Bertelsen