[jwhat]

Hi Indy99,

yes it was a while back.

I remember the Dr Dave days when we where doing physical CPU oscillator swaps with Octane CPU modules to squeeze a bit of extra grunt from our machines.

I still have "custody" of Dual 600 Octane2 from those days and thought I would never need anything more.

But then O350 (Origin / Onyx) prices went to the floor and I was doing some work with company in media business so ended up with some O350's and now a Fuel.

So now have lots of experience with these machines in addition to my Octane knowlege.

Funny how just before Peter turned off Nekochan, I was still updating threads on some things that had not been resolved for over 10 years, during which I did next to no IRIX / SGI stuff.

On this one, I think we will get it closed out pretty shortly.

I did a "flash -f" test on my Fuel, but it returned message saying that all parameter where ok, so without plugging in a faster CPU module I would have to resort to an "flash -F" to force update...

ALL THOSE CAPITAL AND WARNINGS do make you a little nervous, but I took plunge on a number of high risk L1 commands to get my O350 running as unless you do this it is likely we will never get to bottom of some of this stuff.

I was thinking of doing "flash -F" to just check that it come up with prompting questions and then just ctrl c out before apply update in first instance.

EDIT #1: Here is dry run...

>> pink 1# flash -f
>> No proms need flashing
>> pink 2# flash -f -v
>> setting default path_name to /usr/cpu/firmware
>> No proms need flashing
>> pink 3# flash -f -V
>>  Prom version 6.211
>> No proms need flashing
>> pink 4# flash -F -V
>>  Prom version 6.211
>> No proms need flashing

So not able to get prompt for inputs ..

EDIT #2: ok so have to override using -o flag

>> pink 6# flash -o -f -V
>> Enter CPU frequency (MHZ): [400] 600
>> Enter Hub frequency (MHZ): [200] 200
>> Enter cache size (in MBs): [4] 4
>> Enter machine type (0)SN1 (1)SN10 (2)SN11 (3)SN12:
>> If flash is killed in the middle of execution, the machine
>>  will freeze after it is reset.  continuing...
>> Invalid input... Try again.
>> Enter machine type (0)SN1 (1)SN10 (2)SN11 (3)SN12: SN11
>> Invalid input... Try again.
>> Enter machine type (0)SN1 (1)SN10 (2)SN11 (3)SN12: 2
>> Info for prom at /hw/module/001c01/node/prom
>>  Prom version 6.211
>> pink 7#

NOTE the machine type is reported at boot:

>> pink 7# cd /var/adm
>> pink 9# grep SN SYSLOG
>> Oct  4 02:33:10 6A:pink unix: Selecting SN11
>> Oct  4 03:38:37 6A:pink unix: Selecting SN11
>> Oct  4 03:43:25 6A:pink unix: Selecting SN11
>> ...
>> Feb  5 16:40:45 6A:pink unix: Selecting SN11
>> Feb  6 11:35:36 6A:pink unix: Selecting SN11

Deep inhale ....
pink (my Fuel) rebooted up ok .
I can now wipe sweat bead off brow
I think we now know how to do this from bootable machine..
As per Hamei advise for board that has been flashed for higher CPU the only known way to recover is to put back higher frequency CPU and then boot and flash to lower setting and then replace CPU.

Also documented on my blog just in case we loose info again.

Cheers from Oz,


jwhat/John

[weblacky]

Yes, a big thank you for the effort and taking the risk. No documentation claims there would be prompts, so that solves the syntax issue, but of course what to say was another thing.

Thanks for opening this up for others!

[jwhat]

Yes, a big thank you for the effort and taking the risk.  No documentation claims there would be prompts, so that solves the syntax issue, but of course what to say was another thing.

Thanks for opening this up for others!

no problems Weblacky, driven by self interest ;-)

Also found this old nekochan reference:

"You don't tell the L1 anything, you have to program the PROM prior to powering the system down. Easiest method is using the flash -f option within IRIX or it can be done within POD mode, but that's more risky for the inexperienced user. Have a look at the man page for flash and it should help you."

It is easier to find the answer when you know the answer ... ;-)

tjsgifan == TJ @ 3-Systems / Servero (in UK), if you do a bit of ferreting.

So if you are interested in how to do this via POD rather than IRIX then he might be able to provide some guidance.

Cheers from Oz,


jwhat/John

[weblacky]

That's what I referenced when I started the thread. Flash -f....that's all the concrete info. The POD stuff...I've looked and I found zero other references to it. Just that one sentence, so "grain of salt".

[weblacky]

Hi All,
Ian from SGI Depot UK emailed me early this morning to touch base, he added he found a post-it note during his cleanup with notes on the Fuel PIMM change (I had asked him last year if he had notes on this, he said he'd look out for them). His Note read:

FUEL CPU SWAP:
flash -o -f
HUB: 200MHz
Machine Type: 2 (SN11)

So I think this solves the rest of the flash-based info? Hub is 200Mhz, machine type is 2. This appears to jive with jwhat's findings/post. So I guess the only obstacle is needing to know the cache size on your CPU PIMM to accomplish this?

If anyone gets more info. Please post, whether it's a part's list with parameters or the rumored "POD method" the archive hints at...also any research on programming/defaulting PROMs to 500Mhz for boards separated from their PIMMS.

[weblacky]

Hi All,
I just bought a dead Fuel (hopefully it will ship soon). So I revisited this thread. I noticed one element that wasn’t confirmed, that I heard somewhere, about PIMM down-grades:

Can I run a higher speed PIMM on flashed, lower speed settings, i.e. can I take a 700 MHz Fuel with PIMM installed and working, flash for a 500 MHz PIMM and the existing 700 Mhz PIMM will boot and run fine…at 500 Mhz?

I ask this because, years ago, I was given the impression (via online statements I cannot, now, locate) that Fuel boards set for lower speed PIMMs could still have a higher PIMM thrown in, work, and be then flashed to the new correct speed.

Is this true?

My personal reason for asking is, if I get the dead Fuel I just bought, the owner claimed it’s a 700 MHz (no proof, could be anything?). I have a 600Mhz PIMM that needs repair given to me by a user here.

If the system boots after my efforts. I wanted to “down clock it” to work on this problem PIMM. Should that not give fruit, I need to go back to the original PIMM (assuming it’s faster, for now). So I need an escape hatch to not paint myself into a corner!

Anyone out there brave enough (that maybe has two fuels) that can down-clock a higher speed fuel to a lower speed and be able to use their other PIMM to go backwards if this info proves false?

I thought this was common knowledge, but I don’t see proof. I assumed it was true because then it would make sense that SGI might ship 500 MHz flashed replacement Fuel main boards (back in the day) and the field tech would install and then run the system, then just type in the flash command to update it to the final customer clock speed.

Anyone have first hand knowledge of this for PIMM swapping?

Thanks!

[vvuk]

Just a random bit that I recently went through -- I picked up a Fuel that the owner said was 600 MHz. hinv in both PROM and IRIX said 600 MHz, however during PROM boot, a warning that looked like this showed up:

*** Module 001c01 CPU configuration values mismatch.

The CPU configuration values from board EEPROM/PSC did not match
on 1 module(s). Please reflash the PROM image on the above listed module(s).

I eventually did a "flash -o" from IRIX and the flash process picked up and showed a 700MHz speed; on reboot, the Fuel came back as 700MHz. So, up-clocking should be automatic via "flash -o", and hinv values seem to only report what is stored in PROM, not the other way around.

If someone is able to downgrade a working Fuel to a slower speed, it might be useful to grab a dumb of the nvram before and after, to see what's changed. But I don't think this is in the nvram, as I have a bad timekeeper module and nvram changes don't survive (they're always reset back to default values).

[weblacky]

Just a random bit that I recently went through -- I picked up a Fuel that the owner said was 600 MHz.  hinv in both PROM and IRIX said 600 MHz, however during PROM boot, a warning that looked like this showed up:

*** Module 001c01 CPU configuration values mismatch.

The CPU configuration values from board EEPROM/PSC did not match
on 1 module(s). Please reflash the PROM image on the above listed module(s).

I eventually did a "flash -o" from IRIX and the flash process picked up and showed a 700MHz speed; on reboot, the Fuel came back as 700MHz.  So, up-clocking should be automatic via "flash -o", and hinv values seem to only report what is stored in PROM, not the other way around.

If someone is able to downgrade a working Fuel to a slower speed, it might be useful to grab a dumb of the nvram before and after, to see what's changed.  But I don't think this is in the nvram, as I have a bad timekeeper module and nvram changes don't survive (they're always reset back to default values).

So to confirm, your system was totally usable, other than the PROM notification, and booted Irix just fine and all that with the lower speed settings?

That sounds like what I was told, way back (but never told of PROM warnings).

Thanks for posting!

[vvuk]

So to confirm, your system was totally usable, other than the PROM notification, and booted Irix just fine and all that with the lower speed settings?

That sounds like what I was told, way back (but never told of PROM warnings).

Correct, yep.  It was throwing some other weird errors that were 99% likely due to a bad SCSI hard drive connected and/or bad PSU.  Errors all went away after I replaced those two (but the prom warning stayed until I reflashed).

[jwhat]

Hi Weblacky & other SGI'ers,

I have finally got chance to do this for real, as I swapped out my 600 MHz PIMM for 800 MHz PIMM today.

Here is log:

>> # flash -o -f -v
>> setting default path_name to /usr/cpu/firmware
>> Enter CPU frequency (MHZ): [400] 800
>> Enter Hub frequency (MHZ): [200] 200
>> Enter cache size (in MBs): [4] 4
>> Enter machine type (0)SN1 (1)SN10 (2)SN11 (3)SN12: 2
>> m001c01: freq cpu 800000000 freq hub 200000000 mode 549baf85
>> m001c01: Flashed this prom 14 times
>> m001c01: Flashing prom data in file /usr/cpu/firmware/ip35prom.img
>> m001c01: to device /hw/module/001c01/node/prom
>> m001c01: > Manufacturer code: 0x00
>> m001c01: > Device code : 0x00
>> m001c01: > Erasing code sectors (30 to 40 seconds)
>> m001c01: > Erasure complete and verified
>> m001c01: PROM Header contains:
>> m001c01: Magic: 0x4a464b535743534d
>> m001c01: Version: 6.211
>> m001c01: Length: 0x169648
>> m001c01: Segments: 1
>> m001c01: Segment 0:
>> m001c01: Name: ip35prom
>> m001c01: Flags: 0x10
>> m001c01: Offset: 0x1000
>> m001c01: Entry: 0xc00000001fc00000
>> m001c01: Ld Addr: 0xc00000001fc00000
>> m001c01: True Length: 0x168648
>> m001c01: True sum: 0x84ae700
>> m001c01: > Programming Bedrock PROM
>> m001c01: > Writing 1476168 bytes of data ...
>> m001c01: > 0/168648 ........
>> m001c01: > 8000/168648 ........
>> m001c01: > 10000/168648 ........
>> m001c01: > 18000/168648 ........
>> m001c01: > 20000/168648 ........
>> m001c01: > 28000/168648 ........
>> m001c01: > 30000/168648 ........
>> m001c01: > 38000/168648 ........
>> m001c01: > 40000/168648 ........
>> m001c01: > 48000/168648 ........
>> m001c01: > 50000/168648 ........
>> m001c01: > 58000/168648 ........
>> m001c01: > 60000/168648 ........
>> m001c01: > 68000/168648 ........
>> m001c01: > 70000/168648 ........
>> m001c01: > 78000/168648 ........
>> m001c01: > 80000/168648 ........
>> m001c01: > 88000/168648 ........
>> m001c01: > 90000/168648 ........
>> m001c01: > 98000/168648 ........
>> m001c01: > a0000/168648 ........
>> m001c01: > a8000/168648 ........
>> m001c01: > b0000/168648 ........
>> m001c01: > b8000/168648 ........
>> m001c01: > c0000/168648 ........
>> m001c01: > c8000/168648 ........
>> m001c01: > d0000/168648 ........
>> m001c01: > d8000/168648 ........
>> m001c01: > e0000/168648 ........
>> m001c01: > e8000/168648 ........
>> m001c01: > f0000/168648 ........
>> m001c01: > f8000/168648 ........
>> m001c01: > 100000/168648 ........
>> m001c01: > 108000/168648 ........
>> m001c01: > 110000/168648 ........
>> m001c01: > 118000/168648 ........
>> m001c01: > 120000/168648 ........
>> m001c01: > 128000/168648 ........
>> m001c01: > 130000/168648 ........
>> m001c01: > 138000/168648 ........
>> m001c01: > 140000/168648 ........
>> m001c01: > 148000/168648 ........
>> m001c01: > 150000/168648 ........
>> m001c01: > 158000/168648 ........
>> m001c01: > 160000/168648 ........
>> m001c01: > 168000/168648 .
>> m001c01: > 168648/168648
>> m001c01: > Programmed and verified
>> Prom version 6.211
>> m001c01: Verifying:
>> m001c01: cpu speed 800000000
>> m001c01: hub speed 200000000
>> m001c01: other configuration information also verified
>> m001c01: Compare of file data to in core prom data succeeded
>> # reboot

On reboot machine reported via hinv as 800...

>> % hinv -mv
>> Location: /hw/module/001c01/node
>> IP34 Board: barcode MSM019 part 030-1707-003 rev -H
>> Location: /hw/module/001c01/node/cpubus/0
>> IP34PIMM Board: barcode NPJ858 part 030-1932-001 rev -B
>> Location: /hw/module/001c01/Ibrick/xtalk/13
>> ASTODY Board: barcode MNT914 part 030-1726-003 rev -E
>> Location: /hw/module/001c01/Ibrick/xtalk/14
>> IP34 Board: barcode MSM019 part 030-1707-003 rev -H
>> Location: /hw/module/001c01/Ibrick/xtalk/15
>> IP34 Board: barcode MSM019 part 030-1707-003 rev -H
>> 1 800 MHZ IP35 Processor
>> CPU: MIPS R16000 Processor Chip Revision: 2.2
>> FPU: MIPS R16010 Floating Point Chip Revision: 2.2
>> CPU 0 at Module 001c01/Slot 0/Slice A: 800 Mhz MIPS R16000 Processor Chip (enabled)
>> Processor revision: 2.2. Scache: Size 4 MB Speed 400 Mhz Tap 0xa
>> Main memory size: 4096 Mbytes
>> Instruction cache size: 32 Kbytes
>> Data cache size: 32 Kbytes
>> Secondary unified instruction/data cache size: 4 Mbytes

So I am one happy camper ;-)

Cheers from Oz,

jwhat/John.