Hi,
just a quick update.
I got a ecoff boot image yesterday. Unfortunately it was stripped, and the
machine was unable to relocate. I hope to get another one.
sebastian
"Sebastian Reitenbach" <sebastia@l00-bugdead-prods.de> wrote:
quoted text > Miod Vallat <miod@online.fr> wrote:
> > > First, objcopy does not provide the target ecoff-littlemips. It took
me
quoted text > a
> > > while to get objcopy reconfigured on sparc64 and on i386. On sparc64
> objcopy
> > > says it is unable to change endianness, therefore I tried on i386 too,
> but
> > > there objcopy says "unable to determine file format".
> > >
> > > Do I can create a OpenBSD bsd.rd image in ecoff format where the Indy
at
quoted text > > > least will try to load and boot from that file? Or do I need to do
that
quoted text > on a
> > > SGI machine?
> >
> > You need to either build a OpenBSD/sgi cross toolchain (at least cross
> > binutils), or use an OpenBSD/sgi system, so that this target is
> > available.
> >
> > And even with this, you'll need to tinker with binutils configuration,
> > since ECOFF targets are not enabled on OpenBSD/sgi at the moment.
> Fortunately, as I don't have an idea how to create a cross compiler
> toolchain, and neither have a OpenBSD/sgi machine, someone else contacted
me
quoted text > and offered to create a ecoff based ramdisk. Then I'll see what happens.
>
> >
> > > I doubt that the Indy will boot, but I am just curious.
> >
> > Assuming the PROM doesn't disklike the kernel load address, the system
> > will run until it sets up its own trap vectors, since there are no tlb
> > refill handlers for R4k processors.
> well, in case, I get above mentioned ecoff image beginning to boot, do you
> have any pointer to the hardware documentation, that will explain the tlb
> refill handlers?
>
> >
> > Supporting the ``low-end'' 64 bit capable sgi models (i.e. Indigo R4k,
> > Indy and Indigo2) in 64 bit mode (except for the few hopeless R4000
> > flavours) is on my list, but low priority.
> Exactly my box is a Indigo with an R4k processor, so there is hope it will
> run OpenBSD in the future.
>
> Sebastian
