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.

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