Subject: upgrading bootblocks
To: None <port-macppc@NetBSD.org>
From: Chris Tribo <ctribo@college.dtcc.edu>
List: port-macppc
Date: 12/12/2004 12:55:55
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
>
>