SGI: Hardware

#define INV_ODSY_MEMCFG_512 - Page 2

Dr. Dave wrote: I'm starting to get the feeling that the memory size, CAS, banks, etc. are stored in the config EEPROM on the Vpro board, and that everything seems to reference it from there, reading it through the I2C bus on the card. Since it looks like things are statically linked, more than likely the EEPROM would have to be read and reprogrammed to sort this out.


This project may still have potential.

Who here has the ability to access and copy the contents of the EEPROMs on VPRo board?

bri3d mentioned to me he might be able to sort out the differences if someone could provide him with two copies of the EEPROMs from the 030-1826-00x V10 and the 030-1726-00x V12 <he doesn't have physical access to either board>.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
Hi, was thinking about that. Suspiciously, I'd bet that that 8-pin connector nearby is implicated in this process, but at worst case you'd just have to unsolder the EEPROM, read, and decode the data. If I was designing one of these boards, I'd try to make it easy to grab a blank one from inventory, install the correct profile, put on the appropriate V10 or V12 part number, and ship it.

I'll have a look at part numbers tonight and see if I can figure out what's going on.
:O3000: <> :O3000: :O2000: :Tezro: :Fuel: x2+ :Octane2: :Octane: x3 :1600SW: x2 :O2: x2+ :Indigo2IMP: :Indigo2: x2 :Indigo: x3 :Indy: x2+

Once you step up to the big iron, you learn all about physics, electrical standards, and first aid - usually all in the same day
Cool - yeah, if someone gives me some EEPROM dumps I can probably sort things out - I've got some experience with goofing around with EEPROMs, and I can't imagine they're very obfuscated.

BTW - some marginally relevant info from the LinuxMIPS Wiki - there's a Number in a Can on the card, I doubt it's used to identify model though. Ideally we'll never have to touch those controller init registers (SDRAM initialization usually sucks enough to be hard to disassemble, so I'm hoping we can just convince the driver that the card is a V12 at the lowest possible level and then let the driver do the rest).

LinuxMIPS wrote: There is also a standard issue SGI MicroLAN controller at 0x0010dc used to identify the card through its NIC. Equally unsurprising is the set of XIO widget registers at 0x000000. There are also some other registers, still unknown, that are extensively utilized during the initialization sequence and are probably related to SDRAM controller initialization. Possibly also DMA is realized in these registers.


Re: hacking - LOL as well, you make it sound like a bad thing! Sure, it's a "hack" per se, but no licenses are being violated and nothing is being illegally transferred - there's nothing wrong with (or illegal about) using this hardware to its fullest potential!
no matter where this ends it's a nice find anyway :P
r-a-c.de
I'm guessing U13, the Atmel 24c04 I2C serial EEPROM chip is the culprit.
:O3000: <> :O3000: :O2000: :Tezro: :Fuel: x2+ :Octane2: :Octane: x3 :1600SW: x2 :O2: x2+ :Indigo2IMP: :Indigo2: x2 :Indigo: x3 :Indy: x2+

Once you step up to the big iron, you learn all about physics, electrical standards, and first aid - usually all in the same day
iKitsune wrote: And where I come from, boy, copies ain't got no rights.

:D It's pretty hard to read about Solomon Linda and retain much respect for copyright holders. Patents have also been really abused ... in many cases it's just legalized extortion. Or extortion through legality, to put it more accurately.

Anyway, I was thinking that before we got really carried away, someone with a late-model V12 and V10 and some Arctic Silver should pop the heat sinks off and check out the markings on the underling chips. Just in case they are different ....
To help this discussion maintain its original focus, I split the issue on the moral aspects of reprogramming an EEPROM to a separate topic. That discussion can be followed here: viewtopic.php?f=1&t=16721042
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************
hamei wrote: Anyway, I was thinking that before we got really carried away, someone with a late-model V12 and V10 and some Arctic Silver should pop the heat sinks off and check out the markings on the underling chips. Just in case they are different ....


I'd guess not, actually. Gfxinfo always reports the version of the chip the same, and in comparing an Octane V8 and V12, the boards are identical, which leads me to believe that the taxonomy is:

32MB board vs. 128 MB board.
Slow ASIC vs. fast ASIC
EEPROM tells the driver which to configure
Stick on appropriate part number
Bill customer

It just appears in the case of the late-model Fuel V10's that the 32MB vs. 128 MB board distinction went away over the life of the product.
:O3000: <> :O3000: :O2000: :Tezro: :Fuel: x2+ :Octane2: :Octane: x3 :1600SW: x2 :O2: x2+ :Indigo2IMP: :Indigo2: x2 :Indigo: x3 :Indy: x2+

Once you step up to the big iron, you learn all about physics, electrical standards, and first aid - usually all in the same day
Dr. Dave wrote: It just appears in the case of the late-model Fuel V10's that the 32MB vs. 128 MB board distinction went away over the life of the product.

.. and there was no slow ASIC, so all we're left with is an EEPROM difference, dui ma ?

What does the E in EEPROM mean ? :D
very interesting discovery! :shock:

how much potential there is inside these boards!
:Octane2: 2xR12000 400MHz, 4GB RAM, V12
SGI - the legend will never die!!