> It is true 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...
Yes. Fortunately the DEC system boots a bootloader out of the first n
(16?) blocks of the disk, so only the boot loader need know about
where to find the kernel. In my mind, this boot loader is just a
modified version of lilo...
> 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.
Yeah - typical DEC, eh?
> 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 believe 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 pointed 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...
Never mind my own experiences with Apollo COFF... :-)
> I think we're saying the same thing here, namely that the tool chain
> 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 :-).
Yep - I'm sure that with the right amount of fussing with GNU config
files, we could build gcc/binutils that knew about all formats: a.out,
ELF, ECOFF, ECOFF-DEC... at least, I sincerely hope we can so that we
have a single consistent development tool chain.
> Oh well, back to hacking icat, ils, iscan, etc to help recover my
> damaged UFS disk...
My commiserations and hopes for a speedy recovery :-) I had my system
corrupt itself nicely over New Year, so I empathise completely. It's
taken me 3 weeks to completely reconstruct my environment <sigh>
I wish that one day back-up devices of 1-4G will be as cheap as the
Paul M. Antoine, Net: email@example.com
Softway Pty Ltd WWW: www.softway.com.au
PO Box 305, Strawberry Hills, NSW 2012, Australia Tel: +61 2 698 2322
Level 2, 79 Myrtle St, Chippendale, NSW 2008, Australia Fax: +61 2 699 9174
"It is the lack of acceptance of diversity which threatens to
destroy society, NOT the free expression of it." - Me.