6 ms·

Reverse Engineering the Prom for the SGI O2

117 points by mattst88 8mo ago

nebula8804 8mo ago
I often see superbly restored SGI equipment at VCF and also own a few SGI equipment that I hope to get to some point in my life but I have never seen any interesting new software or usage of these machines other than the stock "cool" demo programs(The file manager, the gears demo and others running at the same time). Is there any actual cool homebrew occuring on these platforms?
- foldor 8mo ago
  I'm not aware of any cool homebrew, but there is a certain level of cool being able to compile the code for some N64 games using the original IDO compiler on original hardware. You can even compile one of the many decompiled games like Super Mario 64, Banjo Kazooie and more that all will produce the exact binary shipped on the cartridge byte for byte, all from reverse engineered work to create byte matching equivalent C code.
  - ThatGuyRaion 8mo ago
    It runs like arse though. I'm working on some OpenGL stuff at least.
- spijdar 8mo ago
  Yes! I don't use my O2 a lot (I think the PSU is flaky, and I'm not super interested in IRIX), but I'm aware of at least https://forums.sgi.sh/index.php https://forums.sgi.sh/index.php, among other similar sites, full of people porting/developing software for IRIX. It's a pretty active community for a 90s workstation platform, the most active one I'm aware of!
- tyfighter 8mo ago
  I think the lack of a real usable emulator for SGIs is holding back any kind of homebrew. I say this as one of the developer's that got SGI Indy emulation working in MAME. Yes, it works, but it's too slow and too old to be usable. I spent some time after the MAME effort working on a custom high performance emulator for Crimson/Onyx/Reality Engine, but I've kind of burned out again. Maybe some day if I'm really driven again, and had help. I've done most of the reverse engineering already, it's just a lot of code. I think that if a high performance, usable emulator for some of the big systems existed I think some of the old software might be rediscovered and show up on the internet.
  - rngfnby 8mo ago
    I think the problem was that the machines were always very expensive, even used. My Fuel has an SSD and Id use it daily except: - It's loud - It's single core - It's a furnace - It's very very loud It has a fairly modern Emacs, ssh and a non distracting UX. The browser is the only real thing that is too old to be useful, feature and performance wise, but that's just bonus points productivity wise (besides, rdesktop into a modern machine and you can watch youtube) If I had a 900 MHz O2 loaded with RAM, and an SSD (SCSI SSD, ha!) it'd probably be my daily driver.
    - theodric 8mo ago
      I have a 600MHz RM7k O2, and my 700MHz R16k Fuel blows it out of the water. The O2 isn't that quiet or that quick even with upgrades! What SSD are you running? I'm still on 10k SCSI drives selected for the quietness of their bearings.
      - rngfnby 8mo ago
        Right now I cant get to the machine (off, in the basement) but it is some run-of-the-mill SATA drives using a SATA expansion card. It works great but I just use it for /opt since I ran out time to move more of the machine into it. You cant boot off the SSD, so I still use a SCSI but you can replace that too if you boot the SGI off the network. Silent SGI: Having gotten rid of the SCSI drives completely w/ the network boot, you can put a modern, more silent, PSU [1] (but hurry, ones w/ enough current on 5V (?) are rare), and then replace the GPU and CPU fans and turn of environmental monitoring. [1] i had to replace mine; my 500 MHz Fuel is notorious for bad psu
        ThatGuyRaion 8mo ago
        Do not turn off environmental monitoring. That's for debugging only. That's how people are cooking the video cards. Please get your fuel /properly/ repaired by say weblacky on irixnet. The reason why? With env monitoring off, the system won't respond to overheating on the graphics card and it'll cook it alive. The fuel has notoriously bad airflow (air doesn't move right angles)
- jrmcauliffe 8mo ago
  The main watering hole for the hobbyist community around these machines vanished from the internet a while back, taking the forums and info around porting software with it.. I guess some of it is available via wayback etc.
  - ThatGuyRaion 8mo ago
    Ummmm... https://irixnet.org/ https://irixnet.org/ http://nekonomicon.irixnet.org/ http://nekonomicon.irixnet.org/ -- Nekochan backup
- ThatGuyRaion 8mo ago
  Where do I start? If you want OpenGL demos, well, they exist. An example I made: https://forums.irixnet.org/thread-4796.html https://forums.irixnet.org/thread-4796.html You want newer FOSS? https://nekoware.me https://nekoware.me Every quarter I update it.
userbinator 8mo ago
In the PC world this would be known as "BIOS modding". The first two instructions looked legitimate, but the third looked unlikely to be a real instruction. Given that the first appears to be a branch, that's not surprising. When disassembling, not following the flow will likely not give you anything meaningful. If the author is reading this: have you tried Ghidra? That said, this seems a lot simpler than PC BIOSes in structure, as the latter are usually written in a combination of C and Asm (I can see why no one wanted to write MIPS Asm) and are self-extracting compressed archives.
- nathan_douglas 8mo ago
  > I can see why no one wanted to write MIPS Asm At least in comparison to x86 assembly, MIPS assembly seemed very elegant and rich to me at the time. I wanna say that MIP R4K had 32 integer registers and 16/32 double- or single-precision float registers, but don't quote me on that. Either way, it was an embarrassment of riches :)
hinkley 8mo ago
Oh, the PROM, not the prom.
- mattst88 8mo ago
  Yes, I submitted it as "PROM". I have no idea why it has been changed.
  - MBCook 8mo ago
    I think it’s to prevent SHOUTY TITLES. I also think there are some hardcoded acronyms that are safe.
the_biot 8mo ago
Awesome work! Enriching the disassembly with known constants and labels is great, great stuff. As somebody else suggested, try Ghidra's decompiler. It produces very sloppy C code, but still reads faster than assembly most of the time. Now enriching Ghidra's decompiler output to clean up the C code, that would be a neat trick, and one that Ghidra isn't doing.
- mattst88 8mo ago
  Thanks! I'll give Ghidra a try!
- rasz 8mo ago
  >Enriching the disassembly with known constants and labels is great speaking of PC BIOSes there is/was a great disassembler called Sourcer https://corexor.wordpress.com/2015/12/09/sourcer-and-windows-source/ https://corexor.wordpress.com/2015/12/09/sourcer-and-windows... with its Bios Preprocessor producing very readable sources full of comments and enumerated hardware IO. Author of Sourcer Frank van Gilluwe also wrote a somewhat companion book "The Undocumented PC, A Programmer's Guide to I/O, CPUs, and Fixed Memory Areas".
- mattst88 8mo ago
  I've loaded the PROM in Ghidra. The ability to decompile to C is great. I looked at some particular parts of the PROM that took a while to understand to see if I could have understood them quicker with Ghidra. In particular, the part of `sloader` that searches for the `post1` and `firmware` sections and then calls `post1(&firmware)`. Given that I already understand how this works, I can see that this is happening from the decompiled C, but the lack of labels, comments, etc really hampers my ability to understand from the decompiled C alone. This might all be down to inexperience with the tool. The ability to iteratively add a label, rerun the decompiler, reread the decompiled assembly, make more inferences was really the key to building an understanding for me. Another aspect I'm unsure how to handle in Ghidra is that the base address differs between sections of the firmware. E.g. the `firmware` section is copied to RAM and executed from `0x81000000`. It's not clear to me how to configure this in a granular way, rather than a single base address for the whole PROM image.
unixhero 8mo ago
I for one is awaiting for the world to completely decompile and or reverse engineering the IBM mainframe microcodes for all their machines. Number 1 because Mainframes without the microcode is sent to the junkyard.
- ThatGuyRaion 8mo ago
  "We weep for the blood of a bird, but not for the blood of a fish. Blessed are those with a voice." Applies here. SGI hardware holds interest because "ooh pretty animations/GL". IBM is great stuff, but it's all workhorses.
Animats 8mo ago
The successor to SGI, after several acquisitions and bankruptcies, is Hewlett Packard Enterprise. There's a forum for abandoned HP products.[1] The SGI O2 has been mentioned, but not in recent years. [1] https://community.hpe.com https://community.hpe.com
ThatGuyRaion 8mo ago
Nice work Matt.

117 points by mattst88 8mo ago

I often see superbly restored SGI equipment at VCF and also own a few SGI equipment that I hope to get to some point in my life but I have never seen any interesting new software or usage of these machines other than the stock "cool" demo programs(The file manager, the gears demo and others running at the same time). Is there any actual cool homebrew occuring on these platforms?

foldor 8mo ago
I'm not aware of any cool homebrew, but there is a certain level of cool being able to compile the code for some N64 games using the original IDO compiler on original hardware. You can even compile one of the many decompiled games like Super Mario 64, Banjo Kazooie and more that all will produce the exact binary shipped on the cartridge byte for byte, all from reverse engineered work to create byte matching equivalent C code.
- ThatGuyRaion 8mo ago
  It runs like arse though. I'm working on some OpenGL stuff at least.
spijdar 8mo ago
Yes! I don't use my O2 a lot (I think the PSU is flaky, and I'm not super interested in IRIX), but I'm aware of at least https://forums.sgi.sh/index.php https://forums.sgi.sh/index.php, among other similar sites, full of people porting/developing software for IRIX. It's a pretty active community for a 90s workstation platform, the most active one I'm aware of!
tyfighter 8mo ago
I think the lack of a real usable emulator for SGIs is holding back any kind of homebrew. I say this as one of the developer's that got SGI Indy emulation working in MAME. Yes, it works, but it's too slow and too old to be usable. I spent some time after the MAME effort working on a custom high performance emulator for Crimson/Onyx/Reality Engine, but I've kind of burned out again. Maybe some day if I'm really driven again, and had help. I've done most of the reverse engineering already, it's just a lot of code. I think that if a high performance, usable emulator for some of the big systems existed I think some of the old software might be rediscovered and show up on the internet.
- rngfnby 8mo ago
  I think the problem was that the machines were always very expensive, even used. My Fuel has an SSD and Id use it daily except: - It's loud - It's single core - It's a furnace - It's very very loud It has a fairly modern Emacs, ssh and a non distracting UX. The browser is the only real thing that is too old to be useful, feature and performance wise, but that's just bonus points productivity wise (besides, rdesktop into a modern machine and you can watch youtube) If I had a 900 MHz O2 loaded with RAM, and an SSD (SCSI SSD, ha!) it'd probably be my daily driver.
  - theodric 8mo ago
    I have a 600MHz RM7k O2, and my 700MHz R16k Fuel blows it out of the water. The O2 isn't that quiet or that quick even with upgrades! What SSD are you running? I'm still on 10k SCSI drives selected for the quietness of their bearings.
    - rngfnby 8mo ago
      Right now I cant get to the machine (off, in the basement) but it is some run-of-the-mill SATA drives using a SATA expansion card. It works great but I just use it for /opt since I ran out time to move more of the machine into it. You cant boot off the SSD, so I still use a SCSI but you can replace that too if you boot the SGI off the network. Silent SGI: Having gotten rid of the SCSI drives completely w/ the network boot, you can put a modern, more silent, PSU [1] (but hurry, ones w/ enough current on 5V (?) are rare), and then replace the GPU and CPU fans and turn of environmental monitoring. [1] i had to replace mine; my 500 MHz Fuel is notorious for bad psu
      - ThatGuyRaion 8mo ago
        Do not turn off environmental monitoring. That's for debugging only. That's how people are cooking the video cards. Please get your fuel /properly/ repaired by say weblacky on irixnet. The reason why? With env monitoring off, the system won't respond to overheating on the graphics card and it'll cook it alive. The fuel has notoriously bad airflow (air doesn't move right angles)
jrmcauliffe 8mo ago
The main watering hole for the hobbyist community around these machines vanished from the internet a while back, taking the forums and info around porting software with it.. I guess some of it is available via wayback etc.
- ThatGuyRaion 8mo ago
  Ummmm... https://irixnet.org/ https://irixnet.org/ http://nekonomicon.irixnet.org/ http://nekonomicon.irixnet.org/ -- Nekochan backup
ThatGuyRaion 8mo ago
Where do I start? If you want OpenGL demos, well, they exist. An example I made: https://forums.irixnet.org/thread-4796.html https://forums.irixnet.org/thread-4796.html You want newer FOSS? https://nekoware.me https://nekoware.me Every quarter I update it.

userbinator 8mo ago

In the PC world this would be known as "BIOS modding". The first two instructions looked legitimate, but the third looked unlikely to be a real instruction. Given that the first appears to be a branch, that's not surprising. When disassembling, not following the flow will likely not give you anything meaningful. If the author is reading this: have you tried Ghidra? That said, this seems a lot simpler than PC BIOSes in structure, as the latter are usually written in a combination of C and Asm (I can see why no one wanted to write MIPS Asm) and are self-extracting compressed archives.

nathan_douglas 8mo ago
> I can see why no one wanted to write MIPS Asm At least in comparison to x86 assembly, MIPS assembly seemed very elegant and rich to me at the time. I wanna say that MIP R4K had 32 integer registers and 16/32 double- or single-precision float registers, but don't quote me on that. Either way, it was an embarrassment of riches :)

hinkley 8mo ago

Oh, the PROM, not the prom.

mattst88 8mo ago
Yes, I submitted it as "PROM". I have no idea why it has been changed.
- MBCook 8mo ago
  I think it’s to prevent SHOUTY TITLES. I also think there are some hardcoded acronyms that are safe.

the_biot 8mo ago

Awesome work! Enriching the disassembly with known constants and labels is great, great stuff. As somebody else suggested, try Ghidra's decompiler. It produces very sloppy C code, but still reads faster than assembly most of the time. Now enriching Ghidra's decompiler output to clean up the C code, that would be a neat trick, and one that Ghidra isn't doing.

mattst88 8mo ago
Thanks! I'll give Ghidra a try!
rasz 8mo ago
>Enriching the disassembly with known constants and labels is great speaking of PC BIOSes there is/was a great disassembler called Sourcer https://corexor.wordpress.com/2015/12/09/sourcer-and-windows-source/ https://corexor.wordpress.com/2015/12/09/sourcer-and-windows... with its Bios Preprocessor producing very readable sources full of comments and enumerated hardware IO. Author of Sourcer Frank van Gilluwe also wrote a somewhat companion book "The Undocumented PC, A Programmer's Guide to I/O, CPUs, and Fixed Memory Areas".
mattst88 8mo ago
I've loaded the PROM in Ghidra. The ability to decompile to C is great. I looked at some particular parts of the PROM that took a while to understand to see if I could have understood them quicker with Ghidra. In particular, the part of `sloader` that searches for the `post1` and `firmware` sections and then calls `post1(&firmware)`. Given that I already understand how this works, I can see that this is happening from the decompiled C, but the lack of labels, comments, etc really hampers my ability to understand from the decompiled C alone. This might all be down to inexperience with the tool. The ability to iteratively add a label, rerun the decompiler, reread the decompiled assembly, make more inferences was really the key to building an understanding for me. Another aspect I'm unsure how to handle in Ghidra is that the base address differs between sections of the firmware. E.g. the `firmware` section is copied to RAM and executed from `0x81000000`. It's not clear to me how to configure this in a granular way, rather than a single base address for the whole PROM image.

unixhero 8mo ago

I for one is awaiting for the world to completely decompile and or reverse engineering the IBM mainframe microcodes for all their machines. Number 1 because Mainframes without the microcode is sent to the junkyard.

ThatGuyRaion 8mo ago
"We weep for the blood of a bird, but not for the blood of a fish. Blessed are those with a voice." Applies here. SGI hardware holds interest because "ooh pretty animations/GL". IBM is great stuff, but it's all workhorses.

Animats 8mo ago

The successor to SGI, after several acquisitions and bankruptcies, is Hewlett Packard Enterprise. There's a forum for abandoned HP products.[1] The SGI O2 has been mentioned, but not in recent years. [1] https://community.hpe.com https://community.hpe.com

ThatGuyRaion 8mo ago

Nice work Matt.