Stephen Ma wrote:
> 
> Makoto> 0 > boot fd:netbsd.xcf loading XCOFF
> Makoto> tsize=BFB0 dsize=9D4 bsize=16D0 entry=20000
> Makoto> SECTIONS:
> Makoto> .text     00020000 00020000 0000BFB0 00000124
> Makoto> .data     0002C000 0002C000 000009D4 0000C0D4
> Makoto> .bss      0002C9D8 0002C9D8 000016D0 00000000
> Makoto> .note     0002E490 0002E490 00000028 0000CAA8
> Makoto> netbsd    00000000 00000000 000FF250 0000CAD0
> Makoto> loading .text, done..
> Makoto> loading .data, done..
> Makoto> clearing .bss, done..
> Makoto> NetBSD/powerpc OpenFirmware Boot, Revision 1.3
> Makoto> (drow@mindcryme, Sat Jan 10 00:38:29 EST 1998)
> Makoto> Beginning image search.
> Makoto> Found image at 0x40fc.
> Makoto> Inline kernel at 0x10ad0, length 0xff250.
> Makoto> Header loaded at 0x3ffc48.
> 
> Ummm. I think we may have some overlapping memory regions.

Thanks a lot - I was beginning to wonder what was wrong :) That header 
address is simply bizzare (sp?), by the way - &hdr is in the local 
variable space for the function.  What the heck is it doing above 
0x30000 or so?  (Not that I think that's the problem, but it's 
confusing).

> The image of the kernel begins at 0x10ad0, and has length 0xff250, so
> it's going to overlap with the boot code (loading at 0x20000, up to
> 0x2e0a8 ish). Presumably the xcoff loader is dumb enough to overwrite
> parts of the boot image, so we've corrupted the netbsd segment.
> 
> Problem #2: The end of the netbsd image is at 0x10bd20. Since the
> kernel loads at 0x100000, that's also going to get overwritten as we
> load the kernel.

So close, and yet so far...

> Possible work-arounds: Move the boot loader to execute around
> 0x110000, make netbsd load at 0x120000 (I'm not sure if it'll execute
> from there, though).


Easy enough to do.  These would need to be changed:

KERNBASE in /sys/arch/powerpc/include/param.h .  As far as I can tell it 
is never used, either by name or by value, in our boot code - it's 
possible I missed something, though.

The value in ${SYSTEM_LD} in the Makefile.

The definition of RELOC in the ofwboot Makefile.


If my other idea fails, I'll try this.  We could also do as LinuxPPC 
does and map out some other memory with the BATs early on for the 
kernel; however, the changes involved may be too drastic.


> Alternatively, you may be able to fiddle around with "load-base"
> config variable....


Indeed.  IF the loader honors this value, setting it to 500000 will cure 
all our ills.  I invite you all to try this - I'm not at home at the 
moment.

Eventually, I will try to add libz support.  Thank you for pointing out 
to me that libz was what I was talking about; I knew it rang a bell - I 
see it every time I link ofwboot, even though it is currently unused (? 
It have a function I don't know about?).

Dan