> So far I have only come to the conclusion that something breaks during
> compiling/linking of the ofwboot program and/or kernel. There have not
> been any changes in the actual ofwboot code, I think. Only in the tool
> chain and kernel.

	The non-executable stack changes in -current would be my guess, 
but, that's totally unfounded.

> And what is the story on xcoff vs. elf here? I have been looking for
> documentation on this but all I can find is description of how open

OpenFirmware before version 3 cannot load ELF code (*), and cannot boot 
large kernels without changing the load-base (**), or gzipped kernels. 
ofwboot.elf is "converted" to XCOFF by elf2ecoff. Some day we should be 
able to generate {E,X,}COFF without using this tool. That may be the 
problem, it may not.

OpenFirmware version 3 and later can load XCOFF and ELF code; but, not 
gzipped kernels. ofwboot.elf would be used in this case to load, for 
example, netbsd-foo_bar.gz 


(*) I have seen "Loading ELF" on an OpenFirmware 2.0f1 B revision ROM, but 
hangs immediately after this. I presume this was an intermediate 
development ROM image before 2.4 or 3.0 was branched at Apple, and is 
probably incomplete, or unusable. Apple has dropped support for OldWorld 
(before 3.0) ROM revisions in OS X, I presume this is because they have 
removed the Apple XCOFF bootx loader from the tree in order to switch to 
all ELF code, but that doesn't seem to be the case either.

(**) MacOS X boots without modifying the real-base, changing our entry 
points and/or telling openfirmware to go away should fix this, but cannot 
be done since we use OF as a video console.