Chris and I have made some progress on Chris' problem. The secondary
bootloader appears to have lost integrity on the disk. This causes junk to
be written into memory and then the CPU attempts to execute it.

I got Chris to send me the output from

%SRRO 10 - dis

after getting the CATCH in Open Firmware:

00E00030: 7C1683A6
00E00034: 7C1883A6
00E00038: 7C1A83A6
00E0003C: 7C1C83A6
00E00040: F1087064
00E00044: 0000A1A3
00E00048: 120E4657
00E0004C: 422C4A61
00E00050: 636B4861
00E00054: 6D6D6572
00E00058: 02011204
00E0005C: 73637369
00E00060: 011A1206
00E00064: 31303230
00E00068: 56310119
00E0006C: A5A50103
00E00070: 0113A501
00E00074: 11A50111
00E00078: 01120112

%SRR0 is the next instruction to be executed, and was always 0xE00040. I
ran this through a couple utilities in MacOS. The code looked off-track
from E00040 down.

 Disassembling PowerPC code from 086791D0
  No procedure name
            086791D0   mtibatu    0x03,r0                    ; IBAT3U =3D
0x0216 | 7C1683A6
            086791D4   mtspr      DBAT0U,r0                  ; 0x0218     |
7C1883A6
            086791D8   mtspr      DBAT1U,r0                  ; 0x021A     |
7C1A83A6
            086791DC   mtspr      DBAT2U,r0                  ; 0x021C     |
7C1C83A6 <--- our last real opcode

            086791E0   dc.l       0xF1087064                              |
=461087064
            086791E4   dc.l       0x0000A1A3                              |
0000A1A3
            086791E8   dc.l       0x120E4657                              |
120E4657
            086791EC   bdnzl+     $+0x4A60                   ; 0x0867DC4C |
422C4A61
            086791F0   ori        r11,r27,0x4861                          |
636B4861
            086791F4   xoris      r13,r11,0x6572                          |
6D6D6572
            086791F8   dc.l       0x02011204                              |
02011204
            086791FC   andi.      r3,r27,0x7369                           |
73637369
            08679200   dc.l       0x011A1206                              |
011A1206
            08679204   addic      r9,r16,0x3230                           |
31303230
            08679208   rlwinm.    r17,r17,0x00,0x04,0x0C                  |
56310119
            0867920C   lhzu       r13,0x0103(r5)                          |
A5A50103
            08679210   dc.l       0x0113A501                              |
0113A501
            08679214   dc.l       0x11A50111                              |
11A50111
            08679218   dc.l       0x01120112                              |
01120112

and another looked at in ascii:

|=16=C9=B6|=18=C9=B6|=1A=C9=B6|=1C=C9=B6=D2=08pd=00=00=B0=A3=12=0EFWB,JackHa=
mmer=02=01=12=04scsi=01=1A=12=061020V1=01=19**=01=03=01=13*=01=11*=01=11=01=
=12=01=12

He's seeing artifacts on the disk. In bootxx.c, this code is responsible
for loading the secondary bootloader into memory:

for (j =3D 0; j < bbinfo.bbi_block_count; j++) {
       if ((blk =3D bbinfo.bbi_block_table[j]) =3D=3D 0)
             break;
       putc('0' + j % 10);
       OF_seek(fd, (u_quad_t)blk * 512);
       OF_read(fd, addr, bbinfo.bbi_block_size);
       addr +=3D bbinfo.bbi_block_size;
}

The problem is that OF's read is a raw disk reader. It has no knowledge of
the file system underneath. When the replacement copy of ofwboot was moved
into place, the file system did not make it contiguous or overwrote it
later, and OF just read the number of bytes it was told to read.

I've seen this before, when doing a lot of kernel testing, where either the
bootloader or the kernel would get discontiguous. However, the problem
appears a tad more subtle. The first 64 bytes of the file are intact. It is
after this point that something else is present. This seems odd to me, that
a file would get broken up so early, and that it would use such a small
portion of the block fragment.

So I have a couple questions:

Does installboot check the contiguousness of the secondary bootloader?

Does installboot make a copy of the secondary bootloader somewhere, or does
it just record the blocks that the original resides in, and this is what
bootxx retrieves?

thanks in advance,
tim