prom start

prom start

[folkert]

Hi,

Is this mailing list also meant for generic mips questions? (if not: any
suggestions for one that is?)

If so: I'mm experimenting a bit with mips, specifically on SGI hardware
(Indigo). Now it seems all mips systems have the prom at 0xbfc00000. But
how does it start? The first 0x3c0 bytes seem to be nonsense. Somewhere
on the web I found that 0xbfc00884 is the starting point but after
single stepping 5 instructions, the program counter jumps to 0x00000000
so I don't think that's the right one either. Also, reading the first 4
bytes from bfc00000 and using that as a pointer seems to be invalid too:
0bf000f0.
Anyone with insights regarding the booting of the prom on sgi systems?


Regards,

Folkert van Heusden

Re: prom start

[Joshua Kinard]

[-- Attachment #1: Type: text/plain, Size: 1830 bytes --]

On 02/06/2013 11:05 AM, folkert wrote:
> Hi,
> 
> Is this mailing list also meant for generic mips questions? (if not: any
> suggestions for one that is?)
> 
> If so: I'mm experimenting a bit with mips, specifically on SGI hardware
> (Indigo). Now it seems all mips systems have the prom at 0xbfc00000. But
> how does it start? The first 0x3c0 bytes seem to be nonsense. Somewhere
> on the web I found that 0xbfc00884 is the starting point but after
> single stepping 5 instructions, the program counter jumps to 0x00000000
> so I don't think that's the right one either. Also, reading the first 4
> bytes from bfc00000 and using that as a pointer seems to be invalid too:
> 0bf000f0.
> Anyone with insights regarding the booting of the prom on sgi systems?
> 
> 
> Regards,
> 
> Folkert van Heusden

The first Indigo?  IP12?  Or the Indigo2 series (IP22, IP26, or IP28)?

ARCS (the SGI prom) is a bit of black magic and voodoo.  It also terrifies
the priests of Ancient Mu.

You might want to hunt down copies of the PROM images for other SGI systems,
such as IP22, IP32 (O2), IP30 (Octane) (the latter two are on certain IRIX
media) and analyze those in a disassembler and see if you can discern
something from there.

You might also try gxemul and see if it can boot one of those proms (it's a
machine emulator like Qemu, but has some code tailored to SGI hardware in
it).  Might give you some additional insight.

Would be curious about your results if you can learn anything else from it
via your own work.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 834 bytes --]

Re: prom start

[Ralf Baechle]

On Wed, Feb 06, 2013 at 05:05:10PM +0100, folkert wrote:

> Is this mailing list also meant for generic mips questions? (if not: any
> suggestions for one that is?)
> 
> If so: I'mm experimenting a bit with mips, specifically on SGI hardware
> (Indigo). Now it seems all mips systems have the prom at 0xbfc00000. But
> how does it start? The first 0x3c0 bytes seem to be nonsense. Somewhere
> on the web I found that 0xbfc00884 is the starting point but after
> single stepping 5 instructions, the program counter jumps to 0x00000000
> so I don't think that's the right one either. Also, reading the first 4
> bytes from bfc00000 and using that as a pointer seems to be invalid too:
> 0bf000f0.
> Anyone with insights regarding the booting of the prom on sgi systems?

All MIPS processors start execution at 0xbfc00000 after a hardware reset
or NMI.  0xbfc00884 is not an address that has any specific meaning in
the processor architecture itself.  I think it's being used in the GXemul
documentation just for sake of an example.

If your disassembler defaults to like MIPS I / R3000 it won't disassemble
all instructions for the MIPS III R4000 processor.  I'd expect some
cache initialization code right at 0xbfc00000 and that could would be
affected.

  Ralf

Re: prom start

[folkert]

Hi,

> > Is this mailing list also meant for generic mips questions? (if not: any
> > suggestions for one that is?)
> > 
> > If so: I'mm experimenting a bit with mips, specifically on SGI hardware
> > (Indigo). Now it seems all mips systems have the prom at 0xbfc00000. But
> > how does it start? The first 0x3c0 bytes seem to be nonsense. Somewhere
> > on the web I found that 0xbfc00884 is the starting point but after
> > single stepping 5 instructions, the program counter jumps to 0x00000000
> > so I don't think that's the right one either. Also, reading the first 4
> > bytes from bfc00000 and using that as a pointer seems to be invalid too:
> > 0bf000f0.
> > Anyone with insights regarding the booting of the prom on sgi systems?
> 
> All MIPS processors start execution at 0xbfc00000 after a hardware reset
> or NMI.  0xbfc00884 is not an address that has any specific meaning in
> the processor architecture itself.  I think it's being used in the GXemul
> documentation just for sake of an example.

Yes that seems to be the case. If I start at 0xbfc00000 it looks
meaningful.

> If your disassembler defaults to like MIPS I / R3000 it won't disassemble
> all instructions for the MIPS III R4000 processor.  I'd expect some
> cache initialization code right at 0xbfc00000 and that could would be
> affected.

I'm not entirely sure yet. My D-A (well, an emulator to be honest)
implements the mips as described in MD00086 (by Mips technologies) of
June 2003 and at the bottom that document acknowledges the MIPS R3000,
4000, 5000 and 10000.

It's really fun to do, writing that mips code. All new to me. I'm at the
point that it emulates enough of the prom that it reaches points where
it gets even more interesting: undocumented hardware (0xbfa00030 and
0xbfa01004 anyone?) and fiddeling with COP0.



Folkert van Heusden

-- 
Curious about the inner workings of your car? Then check O2OO: it'll
tell you all that there is to know about your car's engine!
http://www.vanheusden.com/O2OO/
----------------------------------------------------------------------
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com