Subject: Re: UFS root, how? was Re: 2.0 rc1 default catch
To: None <port-macppc@netbsd.org>
From: Kendall Shaw <queshaw@pacbell.net>
List: port-macppc
Date: 10/06/2004 10:16:08
Tim Kelly wrote:
> Use http://developer.apple.com/technotes/tn/tn2004.html to learn how to
> telnet into Open Firmware.

Thanks.

> Capture your telnet session and after the catch
> (which is being invoked by OF's exception handler at 0x0300, DSI or bad
> data address), type
> 
> .registers
> 
> in Open Firmware. That'll show the current PC (%SRR0), the link register
> and the registers the current instruction was trying to access.

The result was:

0 > boot hd:,\ofwboot.xcf netbsd load-size=e148 adler32=db640f80

loading XCOFF

tsize=cbc0 dsize=14a8 bsize=2670 entry=640000
SECTIONS:
.text    00640000 00640000 0000cbc0 000000e0
.data    0064d000 0064d000 000014a8 0000cca0
.bss     0064e4a8 0064e4a8 00002670 00000000
loading .text, done..
loading .data, done..
clearing .bss, done..

>> NetBSD/macppc OpenFirmware Boot, Revision 1.6
>> (autobuild@tgm.daemon.org, Sun Sep  8 21:53:46 UTC 2002)
4917880+334992 [247424+225003
DEFAULT CATCH!, code=300 at   %SRR0: 00640334   %SRR1: 00003030
  ok
0 > .registers
Client's Fix Pt Regs:
  00 00000000 00650194 00000000 0064d094 0063f0b4 00036eeb 006501bc 00000000
  08 00000000 00650000 00000000 ffffffff 00000040 00000000 00000000 00000000
  10 00000000 00000000 00100000 00602708 006504ac 00000000 00000012 00000000
  18 00000000 0060273c 0000003d 00000000 00036eeb 0063f0b4 006501bc 0064d094
Special Regs:
     %IV: 00000000   %SRR0: 00640334   %SRR1: 00003030
     %CR: 20000004     %LR: 00640334    %CTR: 00000000    %XER: 20000000
    %DAR: 00658000  %DSISR: 42000000   %SDR1: 3ffe0000
  ok
0 >

> By the way, I have found that otherwise perfectly fine kernels, especially
> RAMDISK/INSTALL ones, will give 0x0300 and 0x0400 exceptions if they are
> fragmented in MSDOS or HFS formatted partitions. OF reads the disk raw and
> knows enough of the two file systems to find the start and end points of
> the file. It doesn't stop to check for contiguousness.

I've had what I think was the same error when the kernel file was in the 
root of newly created file systems. For example, I ran newfs, then 
mounted the file system under macos x and copied the kernel there. When 
I mounted the file system macos X created a file in the directory, but I 
would think new files added to an otherwise empty file system would be 
contigous.

I'll try using objdump when I get a chance. I don't have objdump under 
macos x at the moment.

Kendall