#define INV_ODSY_MEMCFG_512

SGI hardware problems, solutions, tips, hacks, etc.
Forum rules
Any posts concerning pirated software or offering to buy/sell/trade commercial software are subject to removal.
User avatar
Dr. Dave
Posts: 2311
Joined: Fri Feb 13, 2004 10:37 pm
Location: Ottawa, Canada >burp<

Re: #define INV_ODSY_MEMCFG_512

Unread postby Dr. Dave » Fri May 29, 2009 7:52 pm

hamei wrote:
Dr. Dave wrote:

Code: Select all

Dudley 1# /usr/gfx/gfxinfo

Is your other Fuel Snidely or Sweet_Nell ? Don't tell me it's Horse :P


LOL - no, it's Snidely...
: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

User avatar
Dr. Dave
Posts: 2311
Joined: Fri Feb 13, 2004 10:37 pm
Location: Ottawa, Canada >burp<

Re: #define INV_ODSY_MEMCFG_512

Unread postby Dr. Dave » Fri May 29, 2009 9:33 pm

so I was cruising through odyssey.a with hexedit - and 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.
: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

User avatar
iKitsune
Posts: 504
Joined: Thu May 14, 2009 10:31 am
Location: Huntsville, Alabama, USA

Re: #define INV_ODSY_MEMCFG_512

Unread postby iKitsune » Fri May 29, 2009 10:18 pm

And that's where my usefulness runs out; when I had to choose between a soldering iron or a compiler, I took 'soldering iron'.
:O3000: :1600SW: :Indigo2IMP: :0300:

"Remember, if they can't find you handsome, they should at least find you handy."

User avatar
recondas
Moderator
Moderator
Posts: 5441
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: #define INV_ODSY_MEMCFG_512

Unread postby recondas » Sat May 30, 2009 12:25 pm

Dr. Dave - no matter where this ends up, your time and efforts are really appreciated - thank you.
***********************************************************************
Welcome to ARMLand - 0/0x0d00
running...(sherwood-root 0607201829)
* InfiniteReality/Reality Software, IRIX 6.5 Release *
***********************************************************************

mcblack
Posts: 65
Joined: Thu Feb 23, 2006 12:48 am
Location: Germany

Re: #define INV_ODSY_MEMCFG_512

Unread postby mcblack » Tue Jun 02, 2009 3:42 am

Just read this thread all trough ............

And I'm just ................

Blown away !!! :shock:

This would be a hell of an opportunity.


@Dr. Dave

Thanks for the time and risk you're putting into this project.

Best regards

McBlack
:Onyx2R: :Octane2: :O2: :Indigo2IMP: :1600SW: :1600SW:

User avatar
recondas
Moderator
Moderator
Posts: 5441
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: #define INV_ODSY_MEMCFG_512

Unread postby recondas » Tue Jun 02, 2009 5:58 am

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 *
***********************************************************************

User avatar
Dr. Dave
Posts: 2311
Joined: Fri Feb 13, 2004 10:37 pm
Location: Ottawa, Canada >burp<

Re: #define INV_ODSY_MEMCFG_512

Unread postby Dr. Dave » Tue Jun 02, 2009 2:29 pm

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

User avatar
bri3d
Posts: 669
Joined: Sat Jun 28, 2008 11:08 am
Location: Boulder, CO

Re: #define INV_ODSY_MEMCFG_512

Unread postby bri3d » Tue Jun 02, 2009 8:05 pm

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!

User avatar
foetz
Moderator
Moderator
Posts: 6575
Joined: Mon Apr 14, 2003 4:34 am
Contact:

Re: #define INV_ODSY_MEMCFG_512

Unread postby foetz » Tue Jun 02, 2009 8:26 pm

no matter where this ends it's a nice find anyway :P

User avatar
Dr. Dave
Posts: 2311
Joined: Fri Feb 13, 2004 10:37 pm
Location: Ottawa, Canada >burp<

Re: #define INV_ODSY_MEMCFG_512

Unread postby Dr. Dave » Tue Jun 02, 2009 11:02 pm

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

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: #define INV_ODSY_MEMCFG_512

Unread postby hamei » Wed Jun 03, 2009 9:23 pm

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 ....

User avatar
recondas
Moderator
Moderator
Posts: 5441
Joined: Sun Jun 06, 2004 5:55 pm
Location: NC - USA

Re: #define INV_ODSY_MEMCFG_512

Unread postby recondas » Thu Jun 04, 2009 4:58 pm

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 *
***********************************************************************

User avatar
Dr. Dave
Posts: 2311
Joined: Fri Feb 13, 2004 10:37 pm
Location: Ottawa, Canada >burp<

Re: #define INV_ODSY_MEMCFG_512

Unread postby Dr. Dave » Thu Jun 04, 2009 7:08 pm

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

User avatar
hamei
Posts: 10433
Joined: Tue Feb 24, 2004 4:10 pm
Location: over the rainbow

Re: #define INV_ODSY_MEMCFG_512

Unread postby hamei » Thu Jun 04, 2009 10:56 pm

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

User avatar
Geoman
Donor
Donor
Posts: 825
Joined: Thu May 26, 2005 3:37 am
Location: Munich, Germany
Contact:

Re: #define INV_ODSY_MEMCFG_512

Unread postby Geoman » Fri Jun 05, 2009 8:37 am

very interesting discovery! :shock:

how much potential there is inside these boards!
:Indy: :O2: :O2: :Indigo: :Indigo2IMP: :Octane: :Octane2: :Octane2:
SGI - the legend will never die!!


Return to “SGI: Hardware”

Who is online

Users browsing this forum: No registered users and 3 guests