> Hello,
> 
> I'm trying to understand the logic behind the allocation of the OF_buf.  As best I can tell, ofppc/locore.S and macppc/locore.S both just grab some space sitting at the end of the .data segment.
> 
> Unfortunatly PSIM exactly allocates the data/bss segment and the OF_buf ends up with an unmapped VM address.  I get the feeling that the code is assuming that the stack will be placed directly after .bss.

It was pointed out that some systems map things 1:1 at startup.  The 
following may also be relevant:

locore.S goes through the sequence:

	call ofw_init()
		this saves the open firmware's VM state
		(the program is being started in virtual mode)
	find the address of &end
	OF_buf = (end + 0xfff) & ~0xfff
		i.e. page aligned just beyond &end

That puts the buffer on the page just beyond text/data.  Since PSIM 
doesn't map things 1:1, that page won't be in the OF's address space.

Does anyone know what the Mac's OF does to the VM when it passes control 
to the kernel?

Assuming this is declared a ``bug'', I'm wondering why space for OF_buf 
isn't simply included in the kernel's .bss like was done for other bits 
of the OF <-> kernel interface code.

enjoy,
Andrew