At 6:37 PM -0700 10/6/04, Kendall Shaw wrote:
>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

While I would think this problem would appear more often, is it possible
that this is the same problem discussed before, that of the kernel loading
running over the bootloader? The 1.10 bootloader is linked at 0xe00000, and
as far as I can tell the GENERIC_MD kernel is linked at 0x800000, which
only leaves 6M of space, and the above size (6873328) is larger than that.
The comments about this are that netbsd-GENERIC_MD will boot with 1.07 (?),
which is linked at 0x640000, and therefore below the MD kernel, but not
with 1.10, which is linked above the kernel.

A few weeks back I asked if there was a reason to leave the MD kernel
linked at 0x800000, and Izumi said would be moved down to 0x100000,
consistent with GENERIC. Has this been done?

I tested the most recent netbsd-GENERIC_MD.gz file at releng.netbsd.org
against the bootloader I've modified to link to 0x24000. I did not
experience the above problem and got to the shell easily. When I booted
using the most recent ofwboot.xcf (1.10), I got a DEFAULT CATCH! of 0x0700.
The only difference in the two kernel files I used was the I have to
re-gzip files with gzip -9 in OpenBSD in order for the modified bootloader
to read the file (I'm working on identifying the problem). I posted a
re-gzipped MD file at

http://www.dialectronics.com/bootloader/netbsd-MD.gz

A copy of the modified bootloader I'm working on is at

http://www.dialectronics.com/bootloader/boot25a.xcf

It won't handle CPUs above 7400s (yet), and due to the decoupling of the
bootloader location from the kernel location, the absolute path to both
might have to be specified (this didn't show up in initial testing but for
some reason I had this problem the first time I tried to boot the above MD
file).

The main point is that I think the kernel loading is overrunning the
bootloader and perhaps instead of putting the bootloader linking address
above the kernels, put it below them, especially since the space below 1M
is rarely used other than for exception handling, as far as I can tell.
Moving it underneath might resolve this problem once and for all. :-)

tim