Forwarding this on behalf of Tim.

And it may be that my disk has a bad sector there, maybe I'll try a =20
different HD?

Begin forwarded message:

> From: Tim Kelly <hockey@dialectronics.com>
> Date: December 11, 2004 9:55:22 AM EST
> To: Chris Tribo <ctribo@college.dtcc.edu>
> Subject: Re: upgrading bootblocks
>
> Chris,
> I'm having a lot of problems getting email out. I've tried three times =
=20
> to
> get the post to the macppc list, but it nevers gets there. If you get =20=

> this,
> can you post, please? Someone might have a quick answer.
>
> thanks,
> tim
>
> (This is a second resend - I apologize if the first two later show up. =
=20
> I am
> having problems with my ISp's STMP server. If you have sent me an =20
> email and
> I have not responded, please let me know.)
>
> Chris and I have made some progress on Chris' problem. The secondary
> bootloader appears to have lost integrity on the disk. This causes =20
> 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. =
=20
> 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  =
=20
>    |
> 7C1883A6
>             086791D8   mtspr      DBAT1U,r0                  ; 0x021A  =
=20
>    |
> 7C1A83A6
>             086791DC   mtspr      DBAT2U,r0                  ; 0x021C  =
=20
>    |
> 7C1C83A6 <--- our last real opcode
>
>             086791E0   dc.l       0xF1087064                           =
=20
>    |
> F1087064
>             086791E4   dc.l       0x0000A1A3                           =
=20
>    |
> 0000A1A3
>             086791E8   dc.l       0x120E4657                           =
=20
>    |
> 120E4657
>             086791EC   bdnzl+     $+0x4A60                   ; =20
> 0x0867DC4C |
> 422C4A61
>             086791F0   ori        r11,r27,0x4861                       =
=20
>    |
> 636B4861
>             086791F4   xoris      r13,r11,0x6572                       =
=20
>    |
> 6D6D6572
>             086791F8   dc.l       0x02011204                           =
=20
>    |
> 02011204
>             086791FC   andi.      r3,r27,0x7369                        =
=20
>    |
> 73637369
>             08679200   dc.l       0x011A1206                           =
=20
>    |
> 011A1206
>             08679204   addic      r9,r16,0x3230                        =
=20
>    |
> 31303230
>             08679208   rlwinm.    r17,r17,0x00,0x04,0x0C               =
=20
>    |
> 56310119
>             0867920C   lhzu       r13,0x0103(r5)                       =
=20
>    |
> A5A50103
>             08679210   dc.l       0x0113A501                           =
=20
>    |
> 0113A501
>             08679214   dc.l       0x11A50111                           =
=20
>    |
> 11A50111
>             08679218   dc.l       0x01120112                           =
=20
>    |
> 01120112
>
> and another looked at in ascii:
>
> =
|=16=C9=B6|=18=C9=B6|=1A=C9=B6|=1C=C9=B6=D2=08pd=80=80=B0=A3=12=0EFWB,Jack=
Hammer=02=01=12=04scsi=01=1A=12=061020V1=01=19**=01=03=01=13*=01=11*=01=20=

> =11=01=12=01=12
>
> He's seeing artifacts on the disk. In bootxx.c, this code is =20
> 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 =20
> knowledge of
> the file system underneath. When the replacement copy of ofwboot was =20=

> 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 =20
> 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. =20=

> It is
> after this point that something else is present. This seems odd to me, =
=20
> 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 =
=20
> does
> it just record the blocks that the original resides in, and this is =20=

> what
> bootxx retrieves?
>
> thanks in advance,
> tim
>
>