--A6N2fC+uXW/VQSAv
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Dang. My original reply got munched...

On Fri, Nov 21, 2003 at 01:11:26AM -0500, Chris Tribo wrote:
> > 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.
>=20
> 	The non-executable stack changes in -current would be my guess,=20
> but, that's totally unfounded.

I doubt that. Those changes are to how the kernel executes user apps, not=
=20
how the loader operates.

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

Actually we do not use elf2ecoff at all. We use binutils to make=20
ofwboot.xcf. Note also that ecoff !=3D xcoff (though I'm not really sure=20
exactly how).

We make ofwboot.xcf by generating ofwboot.mrg, which is an elf file that
is ofwboot.elf with Xcoffextra.o as the first object in the file, with a
different entry point, and with a number of the sections shuffled around.
Xcoffextra.o defines a global which is the new entry point, and contains a
=2Elong pointing to _start, the normal entry point.

Next we turn ofwboot.mrg into ofwboot.xcf using objcopy to turn it into an=
=20
xcoff file. We also strip out .note and .comment sections in this step=20
too.

Finally we run fixcoff on ofwboot.xcf, which sets some header values the=20
OF loader cares about but which I couldn't get binutils to get right in=20
the above step. I can babble more about this more if anyone cares.

Oh, and about load-base, it's real-base that has to move for large=20
kernels. load-base has to move no matter what. We have however adjusted=20
things so that we can make use of the same load-base setting that MacOS X=
=20
uses, 600000.

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

All versions of OF can read XCOFF files. The problem is that they can only=
=20
load them from "file systems" that OF knows about. hfs support was not=20
added until version 3.X. However all versions can read from msdos file=20
systems and can netboot.

> (*) I have seen "Loading ELF" on an OpenFirmware 2.0f1 B revision ROM, bu=
t=20
> hangs immediately after this. I presume this was an intermediate=20
> development ROM image before 2.4 or 3.0 was branched at Apple, and is=20
> probably incomplete, or unusable. Apple has dropped support for OldWorld=
=20

2.0f1 is quite usable; my beige G3 has it and it has been booting NetBSD=20
almost daily for over 3 years. :-) I have however seen neither it nor 2.4=
=20
ever load an ELF file.

> (before 3.0) ROM revisions in OS X, I presume this is because they have=
=20
> removed the Apple XCOFF bootx loader from the tree in order to switch to=
=20
> all ELF code, but that doesn't seem to be the case either.

I'm not sure why they did it. The usb support might have been it too, and=
=20
OF 3.X is nicer to work with in general.

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

No, shrinking our kernels will do it. Heavy use of lkms (now that they=20
work on powerpc) would get things small enough to not need real-base to=20
move. Getting IPv6 and IPsec usable as lkms, and driver lkms, would do it=
=20
from what I've seen.

Take care,

Bill

--A6N2fC+uXW/VQSAv
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQE/w6V6Wz+3JHUci9cRAlFwAJ4ruO7/CqZFh6PHKm1lAgjl7pPjtQCeNu+c
HpdmYynwVnH5pISiOVwGE0Q=
=TW9u
-----END PGP SIGNATURE-----

--A6N2fC+uXW/VQSAv--