sun3x <=> sun3 switching

[Ted Kim ATW]

In article <1232 at brazos.Rice.edu> adoyle at bbn.com (Allan Doyle) writes:
>X-Sun-Spots-Digest: Volume 8, Issue 109, message 8 of 12
> ...
>Obviously, I'm getting bitten by boot code that was configured for a 68030
>with native MMU, or am I? What is going wrong here? How do I fix it?  Once
>I get the sucker to boot, what else is going to bite me. I noticed a bunch
>of symbolic links in /usr/shar/mdec that are CPU specific.

You will also have to change /boot and your boot block that is
installed with the installboot(8) program. Also you will want to run
with a different set of /usr/kvm stuff. 

>The real question is: How do I put the 280 CPU into the system with the
>shortest turnaround? The path of doing a new installation of 4.0.3 each
>time I swap CPUs will probably work but takes too long. (The client after
>all, likes short repair times...).

We have a similar problem switching between 3/60s and 3/80s. I don't
have a general solution, but here is what I do to cut down the work.
Get a sun3 /usr/kvm and a sun3x /usr/kvm and put them somewhere
convenient. Then make /usr/kvm a symbolic link to the appropriate
directory. When you want to switch put a new kernel in, a new boot,
switch the symbolic link and you are ready.  

Note that all the other processor specific stuff like /usr/mdec and
/usr/stand all are really symbolic links to /usr/kvm anyway, so those
are all handled automatically.  

Some things to watch out for:

1. I put the relocated /usr/kvm in the root under
   /export/exec/kvm/{sun3,sun3x}. Make sure you remove the normal
   symbolic links there and that you have enough space in
   your root before trying it.

2. In addition, the symbolic links (for processor types) in your
   relocated /usr/kvm have to be adjusted to point properly to 
   "true" and "false".	

3. You should be aware that the dynamically version of libkvm is in
   your relocated /usr/kvm. Therefore, your relocated kvm should be
   in a partition that is mounted early in booting like / or /usr.
   Otherwise you have to modify the /etc/rc* files.

Good luck! As in all experiments of this nature, you should very
careful and have a way to backout/recover. Otherwise, you may find
yourself with an unbootable system.

-ted

#include <disclaimer.h>

Ted Kim                           ARPAnet: tek at penzance.cs.ucla.edu
UCLA Computer Science Department  UUCP:    ...!ucbvax!cs.ucla.edu!tek
3804C Boelter Hall                PHONE:   (213) 206-8696
Los Angeles, CA 90024             ESPnet:  tek at ouija.board