Tim Kelly wrote:
> Hi Bill,
> 
> 
>>Actually, the problem is that the boot loader is being overwritten by the
>>kernel. We've seen this before, and it's why we moved the boot loader. The
>>current bootloader is version 1.10.

Okay. My original problem was that I couldn't boot netbsd-GENERIC_MD.gz 
using bootloader 1.10. The error I get in that case is:

0 > boot hd:,\ofwboot.xcf ultra1:3,/netbsd-GENERIC_MD.gz load-size=cbcc 
adler32=b9d540de

loading XCOFF

tsize=c860 dsize=28c bsize=25c0 entry=e00000
SECTIONS:
.text    00e00000 00e00000 0000c860 000000e0
.data    00e0d000 00e0d000 0000028c 0000c940
.bss     00e0d290 00e0d290 000025c0 00000000
loading .text, done..
loading .data, done..
clearing .bss, done..

 >> NetBSD/macppc OpenFirmware Boot, Revision 1.10
 >> (autobuild@tgm.netbsd.org, Wed Oct  6 09:34:23 UTC 2004)
6873328\
DEFAULT CATCH!, code=900 at   %SRR0: 00e0219c   %SRR1: 00083030
  ok
0 > .registers
Client's Fix Pt Regs:
  00 0000000b 00e0eea4 00000000 ff1f86df 00018010 00e0ffa7 00e0ef5c 00000000
  08 ffffffec 6ce5f294 000002e0 0000000a 00000000 00000000 0000672a 5f93f294
  10 ffffffff 00000000 00000000 00e0f294 00000000 00000000 00000000 00000600
  18 00004010 00e0eeec 00e0f7d0 00007010 00000000 00001000 00003010 00018004
Special Regs:
     %IV: 00000700   %SRR0: 00e0219c   %SRR1: 00083030
     %CR: 40000088     %LR: 00e02188    %CTR: 00e02917    %XER: 00000000
    %DAR: 00e17000  %DSISR: 42000000   %SDR1: 3ffe0000
  ok


It turns out however, I can install RC2 using ofwboot.xcf version 1.6, 
but not 1.10. Then once it's installed, I can't boot RC2 using 1.6, but 
I can using 1.10 as you suggested.

Thanks for the help.

Kendall

> I missed that completely, by the way. With the bootloader I've been
> modifying I moved RELOC to 0x24000 in order to get it out of the way of the
> kernel, and I had forgotten that the GENERIC kernel had exceeded the
> 0x540000 limit between 0x100000 and the bootloader at 0x640000. But this
> was clearly what was happening:
> 
> 
>>>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
> 
> The size shows it's getting too large. Plus, since the exception was
> occuring after returning from a bl (branch and link), the attempt to
> restore the stack is toasted because it's been written over (also indicated
> by the fact that the PC is only 0x334 instructions into the bootloader).
> 
> 
>>>>I'll try using objdump when I get a chance. I don't have objdump under
>>>>macos x at the moment.
>>
>>Note you'll need NetBSD-specific versions of the tools. MacOS X uses a
>>different file format than NetBSD (MachO not ELF), so the standard Apple
>>tools probably won't be able to figure out what's going on.
> 
> 
> Minor clarification - the kernel is ELF, but the bootloader is XCOFF (and
> as an aside, OS X's bootloader is an XCOFF wrapped inside a CHRP script).
> 
> 
>>I think the debugging techniques described in this thread are very good,
>>however they won't help much with this error. They will, however, help
>>with other issues.
> 
> 
> Another thing I had to do with the stuff I'd been working with was add some
> code to (your) zs.c that would write to the output-device regardless of
> what this was. In particular, if the output-device is type "telnet" the
> bootloader and kernel feedback goes to the telnet session right up to when
> the ethernet chip is probed during autoconfiguration (I haven't tried it
> with a kernel with no ethernet support, might work even farther). This
> becomes really useful when the kernel can't log the dmesg.
> 
> http://dialectronics.com/OldWorldMacs/code/zs.c.db
> 
> Unfortunately I'm in the middle of hardware problems that have left me
> unable to merge my code with NetBSD so I can't provide diffs. However, the
> copy of zs.c is probably very close to what's already in the tree.
> 
> By the way, although I was working on OpenBSD, most of what I learned was
> from reading NetBSD's code and then reverse engineering OpenBSD's
> obfuscation. It is my hope that I can contribute something back.
> 
> tim
> 
> 
>