Last edited by:
  Amy Fasnacht  8-Nov-83 11:44:28
  Dennis Grundler:  2-Sep-84 16:06:36, add copyright notice.

 	Copyright (C) 1983 by Xerox Corporation.  All rights reserved.

                     DEBUGGING FLOPPY BOOTING
	     
	     

The general idea involved in debugging booting is that the boot code and Initial code are copied into IOP RAM using Burdock and executed.

The boot code, which normally resides in the EProms, consists of the Phase0 CP microcode and the IOP modules BootMain, BootSubs, StartIOPBootRAM, PreBootSimple, and AltBoot.  The IOP portion of FloppyInitial.db is IOPInit.asm.  We can bind together these sections of code using BootEPromRAMIOPInit.cfg.

We load this code into IOP RAM using FloppyBoot.burdock.  The layout in IOP memory is then like this:

      0    - 1FFF  EProm
      2000 - 2FFF  Phase0 microcode
      3000 - 37FF  Unused
      3800 - 4000  IOPInit
      4000 - 477A  Unused
      477B - 51CF  Boot code - BootMain, BootSubs, StartIOPBootRAM, PreBootSimple, AltBoot
      51D0 - 5BCF  Floppy buffers
      51B0 - 5FFF  Reserved

The Phase0 microcode will be moved into control store, and can thus be overwritten.  The floppy buffers are used throughout the booting sequence until the time that Domino begins execution, and can never be overwritten.  Execution is started by the command file at BootGo, the beginning of the boot code.  This runs the boot IOP code, which fetches FloppyInitial.db off the floppy and loads the IOP portion of it into location 3000 hex in IOP memory.  Memory now looks like this:

  0    - 1FFF  EProm
  2000 - 2FFF  Unused
  3000 - 37FF  IOPInitial from floppy
  3800 - 3FFF  IOPInitial loaded with Burdock
  477B - 51CF  Boot code
  51D0 - 5BCF  floppy buffers
  5BD0 - 5FFF  reserved
  
We do not want to execute this Initial, but want to execute the Initial that we have placed in memory at location 3800 using Burdock.  When Burdock has hit the DoLastBlock breakpoint for the second time, we manually load 3800 into StartIOPAddress and StartIOPAddress+1 before continuing.  Notice that the version  of IOPInit which is to be debugged is the one loaded through Burdock.  The IOPInit contained on the floppy is never executed.

Initial jumps back into boot code to interpret Mesa.db.  It processes the boot blocks contained in Mesa.db, and loads the IOP with Domino code starting at location 2000.  Domino overwrites both of the Initials that are in IOP memory, but we no longer need them at this point.  We must not load Domino code past location 477A, or we will overwrite the code which is presently executing.  When Domino has been loaded into IOP memory, we begin executing Domino, and the boot sequence continues.  Since Domino has not been loaded through Burdock, we cannot debug Domino symbolically.  Our debugging ability ends at the point where Domino starts executing. 

A normal-sized Domino will not fit in the locations 2000-477A.  To find the length of Domino, consult DominoBind.log.  As Buffer.asm does not contain any code, the starting address of Buffer is the first available location after the code in Domino.  This location must be less than 477A for this debugging scheme to work.  It is probably necessary to create a special SmallDomino.bin, which contains enough Domino code to run a generic system (without RS232C, for example), but is small enough to fit into the above space.  We can make a Mesa.db containing this Domino and install it on the floppy for testing.  If using a SmallDomino is impossible, another alternative is to use a regular Domino, but shrink the size of the boot code for testing.  For example, the boot code pertaining to diagnostic booting or booting of alternate devices could be eliminated for debugging of generic floppy booting.  The amount of space freed by this kind of editing is minimal.