: This would still have to be in ECOFF... as the boot PROM can only load
: ECOFF off either HD or NET. A disk boot loader is going to be
: required anyway in order to load the kernel off an ext2 partition on
: the HD, so that could load an ELF kernel, BUT then you'd still have to
: be able to compile an ECOFF kernel for those people who want to remote
: boot off the NET... so you may as well stick with ECOFF as the target.
It is ture the bootstrap would need to be in ECOFF. It is just a much
smaller chunk that would need to be in ECOFF. If you boot off the
net, you'd have to boot this code which would then boot the kernel. I
agree with your sigh. It sounds horrible and icky. It would be one
way to reduce the amount of code that needed to be ECOFF. However,
you have a point that I hadn't considered: If you need any, you might
as well not mess around with secondary oddities like this...
[[ Tangent :
As far as ext2 partitions go, ick. However, the ARCBIOS side of
the porting house has the same problem. ARCBIOS needs a FAT
partition to boot anything at all, even Windows NT. It is worse on
the ARCBIOS side because we need to have both the loader, the
kernel and any loadable modules needed to get the disks mounted
resident on the FAT partition, which may or may not be the same as
the root partition (and if not, there is a big potential for
version skew). It may be an operational ickyness (one that may be
solved by having /vmlinux a sym link to /fat/kernel or something
like that). However, it sounds like the same kind of problem...
: Hmmm... I don't think you understand me... I can use the GNU tool
: chain I compiled, provided I specify DEC Ultrix as the target. Ralf's
: compiled his tool chain for multiple targets, including a.out, ELF and
: ECOFF, but this ECOFF produces different ECOFF from that produced by
: my specifically-compiled-for-DEC-target set (for reasons that escape
: me at the moment :-)
I think that the problem is due to the fact that COFF and/or ECOFF
isn't necessarily the same on all platforms. ECOFF for linux takes
after its SGI background (as far as I can tell, Ralf will likely tell
me how I'm wrong :-), whereas DEC took a different approach. I recall
from looking at the sources (which I have offline at the moment :-(
that there were different command vectors for both sgi and linux and I
think DEC also. From that, I beleive that's where the problems lie...
It maybe that the MIPS port needs to have a different ECOFF target for
ARCBIOS and for DEC Boot proms. I've not looked at the actual
routines that are poitned to to know for sure...
I know that when I was writing software to hack the .o's to change
symbol names for licensing purposes in a past life that the
"DEC/Ultrix" COFF was significantly different than the SGI/Irix COFF
and the AIX COFF was just plain weird, but not as weird and off the
wall as the HP/UX COFF... That experience is what I'm basing most of
my comments on, so it is possible that it is something else all
I think we're saying the same thing here, namely that the toolchain
needs to grok both kinds of ECOFF, at least for the DECstation
ports. It may be something as trivially simple as a different magic
number with different headers on the files in question.... The COFF
standard is maddeningly non-standard that way :-).
Oh well, back to hacking icat, ils, iscan, etc to help recover my
damaged UFS disk...