> It should be relatively easy for SGI to build a MILO clone for their
> bootroms. It basically loads the kernel into memory, then jumps to
> it. The ARC BIOS stsuff is how it loads it in and sets some things
> up. You'd have to follow the tagging stuff that MILO scribbles into
> high memory somehow so that the kernel can read it out. Whether this
> is done in a separate boot loader or in your code is a grey area right
> now. The ARC BIOS is a crude DOS like environment that has been
> stripped down to allow files to be read off disk for the pruposes of
> booting and configuration. Some versions allow for TFTP file booting
> as well.
One of the design ideas in Milo was that there is a lowlevel library
containing the interface to the os. Milo itself uses the library
interface. The library interface again exports functions that look somewhat
like unix systemcalls. Stoned's version 0.27 of Milo will make this
difference much clearer. It might be a good idea to have one common
bootloader package for ARC, SGI and as many others as possible.
> SGI will likely also have to provide some way to read their file
> system if it isn't ext2fs. This can range from full kernel support to
> an mtools like program for writing something to a efs partition (I
> recall that's what sgi uses, and it isn't ufs, feel free to correct me
> if I'm wrong). Even if that was just used for the boot loader. Also,
> some disk layout issues are likely there because SGI doesn't use the
> standard DOS partition scheme. These may be answered by the
> Alpha/Sparc ports, so it might not be a big issue.
Btw - Linux 1.3.95 has a read-only implementation of UFS mainly for use
by Linux/Sparc. There are many variations of UFS in use. I dunno if the
Linux version is what SGI uses but anyway SGI's main filesystem are efs
and xfs in the future.
> : The libc implementation is based on the GNU libc which is available only
> : as ELF. My home sources are based on snapshot 960210; upgrading to the
> : newest libc will
> How does one joint this development effort? :-)
Aeh... I'll release this stuff rsn. I really need to rework this as
my libc port does no longer compile with newer kernel headers.
There is a mailing list for the port of GNU libc to Linux. If someone
wants to join just tell me.
> : R4000 and better many of the lowlevel functions have been written to be
> : SMP proof but again without SMP hardware and at this point of the project
> : SMP is nothing really invest my time in.
> SMP would be a fun project. All you need is an SMP MIPS box :-(.
Yes, and this is what I don't have :-(
> I know that MIPS has published a bunch of errata on the web, including
> ones for the R4000. Don't know if the 2.2 is one in the list or not,
> but will check my printed copies when I get home. None the less, it
> would be good to have more complete versions of these items if they
> were available. However, I just tried the address I have for this
> data, and I can't find it now.
I think the information isn't really complete.
> The cross compiler stuff is fairly easy to generate. For the SGI
> platform, it should go well. There is a howto generate cross
> compilers web page hanging off the Linux-MIPS howto page that should
> give you what you need to know to build the goofy things, should you
> require assistance. There are a numnber of minor gotchas, so you
> might want to glance there first.
Gimme an account on an SGI and you'll have the crossdevelopment a bit