[jan-jaap]

Another thing to note: Octane also has flashable PROM and does not need to be “re-flashed” like Fuel to accommodate CPU swaps. So I think it’s PROM is also on the CPU module.

Not true, it's on the system board. But the SysAD speed between CPU and mainboard is nearly/completely constant across all Octane CPU models which leaves only the multiplier between SysAD speed and CPU core speed. And that's simply hardcoded on the CPU module.

Simple and bulletproof. They should have kept that design...

[jwhat]

Hi Jan-Jaap,

yes right you are, I was also mulling over how the Octane let you overclock by swapping oscillators and resistors (back in the day) .

Dug up the Octane/O2 architecture paper (via SGI Depot this time ;-) ) this morning.

The XBOW ASIC is on the system board as is the RAM, so its more Fuel like than the O350.

So there should be a corresponding PROM on the Octane Board, which I can easily pull and inspect.

I might also do some Fuel / O350 POD/DEX/CAC exploration to see if I can see anything that relates to reading / writing to the PROM.

EDIT #1: Here is likely POD/CAC commands that relate to this (taken from log I captured a while back):

>> A 000 001c01: POD SysCt Cac> ?
>> A 000 001c01: Commands may be separated by semicolons, grouped with
>> A 000 001c01: curly braces, and used in nested loop constructs.
>> ...
>> ...
>> A 000 001c01: Miscellaneous
>> A 000 001c01: Show PROM version: version
>> A 000 001c01: Display help: help [CMDNAME]
>> A 000 001c01: Read hub NIC: nic [n:NODE]
>> A 000 001c01: Prgm remote PROM: flash NODE [...]
>> A 000 001c01: Prgm remote PROM with values: fflash NODE [...]
>> A 000 001c01: Prgm modebits with values: setmodebits NODE [...]
>> ...
>> ...
>> A 000 001c01: System Controller
>> A 000 001c01: System ctlr cmd: sc ["STRING"]
>> A 000 001c01: Wr sysctlr nvram: scw ADDR [VAL [COUNT]]
>> A 000 001c01: Rd sysctlr nvram: scr ADDR [COUNT]
>> A 000 001c01: Rd sysctlr dbgsw: dips
>> A 000 001c01: Set/get debug sw: dbg [VIRT_VAL PHYS_VAL]
>> A 000 001c01: Set/get password: pas ["PASW"]
>> A 000 001c01: Set/get module #: module [NUM]
>> A 000 001c01: Set/get partition #: partition [NUM]
>> A 000 001c01: Get module NIC: modnic

#EDIT #2: To try to see what is going on when the flash happens, I did PROM dumps (flash -D) and flash down to 600 and then another dump and flash back up to 800 and other dump.

All the prom dumps have same size, irrespective of CPU speed:
>> -rw-r--r-- 1 root sys 4194304 Oct 31 14:36 ip35prom.img.dump.600
>> -rw-r--r-- 1 root sys 4194304 Oct 31 14:27 ip35prom.img.dump.800.1
>> -rw-r--r-- 1 root sys 4194304 Oct 31 14:51 ip35prom.img.dump.800.2

There is a difference in the two 800 Mhz hex dumps ("od -x -v <PROM-DUMP"> of PROM even though these are for the same CPU Speed:
>> % diff prom-800-01.hex prom-800-02.hex
>> % diff prom-800-01.hex prom-800-02.hex
>> 10c10
>> < 0000220 0000 0002 0000 00f0 0000 000e 0000 0010
>> ---
>> > 0000220 0000 0002 0000 00ee 0000 0010 0000 0010

There are three differences across 800 / 600 PROM Dump:
>> % diff prom-800-01.hex prom-600-01.hex
>> 7,8c7,8
>> < 0000140 0000 0015 549b af85 6970 3237 636f 6e66
>> < 0000160 0000 0000 2faf 0800 0000 0000 0beb c200
>> ---
>> > 0000140 0000 0015 549b ab85 6970 3237 636f 6e66
>> > 0000160 0000 0000 23c3 4600 0000 0000 0beb c200
>> 10c10
>> < 0000220 0000 0002 0000 00f0 0000 000e 0000 0010
>> ---
>> > 0000220 0000 0002 0000 00ad 0000 000f 0000 0010

So taking away the difference @ offset 220 you get:
>> % diff prom-800-01.hex prom-600-01.hex
>> 7,8c7,8
>> < 0000140 0000 0015 549b af85 6970 3237 636f 6e66
>> < 0000160 0000 0000 2faf 0800 0000 0000 0beb c200
>> ---
>> > 0000140 0000 0015 549b ab85 6970 3237 636f 6e66
>> > 0000160 0000 0000 23c3 4600 0000 0000 0beb c200

So for:
600 -> 800 @ 140C AB -> AF
@ 169 3c34600 -> FAF0800

initial look at this I can see a few small diffs and one has 800 and the other 600..
So expect that stuffing these difference into PROM POD/CAC could work... but I am not going to risk this..


Cheers from Oz,

jwhat/John.

[jan-jaap]

This is good stuff!

Actually, I still wonder if a 600MHz won't simply work (at the correct speed) when installed on a board set for 800. If not, flashing a chip (even if it means removing it from the mainboard) is probably easier than finding a CPU module at the correct speed, especially for the rare 800 and 900MHz chips.

In other words: a mainboard flashed for a speed you can't find a CPU for anymore doesn't need to be lost. And that's good.

Oh, and I understand that you don't want to risk your system, especially with a damaged connector. I probably wouldn't either.

[weblacky]

I cannot seem to get the formatting write but hopefully you see what I mean.

Doing some math, I think I know what one of the 800 MHz diff values is for. I swear I’m terrible at math and have no idea how I saw this :-).

00f0 vs 00ee = If my math is right, this is a counter going backwards from 255 (ff). It seems to correlate with your number of flashes if I guessed your order. Because originally your post said “flashed 14 times before”, well the max hex value is FF, so if you subtract 14,15,16,17 etc. you end up with the values your showing in and order that seems to fit your flashing sequence.

255-14=241
255-15=240 (00f0)
255-16=239
255-17=238 (00EE)

If I’m right, it’s likely a counter that when you reach 1 or 0, it will stop you claiming you’ve used up the reliable flashing writes? In other words maybe the designers placed a 255 flashing limit for whatever flash they used?

Tell me if you think that math works. I’d image the rest is a CRC or other kind or checksum/rolling counter to verify firmware image integrity on a basic level?

I swear it just came to me, tell me if you think I’m on to something.

[jwhat]

Hi Weblacky,

I think you are onto something there, as each flash is recorded, and the only place to persist this is back in the PROM, smart thinking 99.

Here is the order of flashes and their count:

[800: 14 -> 15] 0000220 0000 0002 0000 00f0 0000 000e 0000 0010
[600: 15 -> 16] 0000220 0000 0002 0000 00ad 0000 000f 0000 0010
[800: 16 -> 17] 0000220 0000 0002 0000 00ee 0000 0010 0000 0010

So you are right, but it is incrementing, rather than decrementing! (6th column of dump values): 000e -> 000f -> 0010

The pattern on the other (forth column of dump values) is not quite right: [800 - FO (240)] -> [600 - AD (173)] -> [800 - EE (238)] , so if it was decrementing then the middle 600 flash would be Decimal 239 as you say, but it is decimal 173 ...

So this likely represents something else... I could do another cycle of down to 600 then back up to 800 and see if pattern is more apparent.

Care to take a guess on? :

[800: 14 -> 15] 0000160 0000 2faf 0800 0000 0000 0beb c200
[600: 15 -> 16] 0000160 0000 23c3 4600 0000 0000 0beb c200
[800: 16 -> 17] 0000160 0000 2faf 0800 0000 0000 0beb c200

If the last 3 hex in column three are: 800 -> 600 -> 800 then it is binary coded decimal...

The flash has 4 variables: CPU Speed, Hub Speed, Cache Size & Machine Type (SN11 / 2), noting that:
800 -> 320 (Hex)
200 -> C8 (Hex)
4 -> 4 (Hex) ;-)
"SN11" => 53 4E 31 31

Maybe someone could do dump on other speeds (500/700/900) so we can see these and help to find pattern...

To dump PROM: "flash -D" will dump to /usr/cpu/firmware directory with .dump suffix
To get hex: "od -xv <BIN-DUMP> > <HEX-FILE>"

Cheers from Oz,

jwhat/John

[jwhat]

Hi Weblacky and others,

going back to start of this thread where people where looking at the small socketed chip on the Fuel system board (and the O350 IO9 board):



I have looked at the Fuel board and this chip is an:  "ATEM 116 24C04 PC27 C", which is a 4K (512 x 8) Bit, 2.7 - 5.5 Volt EEPROM

So it can only hold 512 Bytes of data, but the Fuel PROM flash reports writing: "Writing 1476168 bytes of data ...".

So again I do not think this is the PROM flash chip, as how could I squash around 1.5M Bytes (1,476,168) into 512 Bytes or have I got chip sizing wrong ?

Cheers from Oz,

jwhat/John

[weblacky]

What I was told about this chip is, it at least carries the System Host ID, that you COULD move that chip between Fuels and get the same system Host ID you had before for software licensing and such (I could be wrong, but that's what's out there) if you had to trade systems.

[jwhat]

Hi Weblacky,

thanks for that, it make good sense as the Fuel system ID corresponds to the Ethernet MAC address for ef0 interface (and the IO9 board on the O350 also has Ethernet port, though systems ID is over-written by the one that is programmed via L1 / L2). From Fuel:

>> # lmhostid
>> lmhostid - Copyright © 1989-2003 by Macrovision Corporation. All rights reserved.
>> The FLEXlm host ID of this machine is "691052a1"

>> # netstat -ian                                                                                             
>> Name  Mtu  Network        Address            Ipkts Ierrs    Opkts Oerrs  Coll
>> tg1    1500  192.168.XXX    192.168.XXX.153      377    0      85    0    0
>>                             224.0.0.1         
>>                             239.7.7.0         
>>                             224.2.127.255     
>>                             224.0.0.9         
>>                             224.0.1.1         
>>                             224.2.127.254     
>>                             08:00:69:14:7d:d8
>> ef0    1500  192.168.XXX      192.168.XXX.132      980    0      330    0    0
>>                             224.0.0.1         
>>                             224.0.0.9         
>>                             08:00:69:10:52:a1
>> cl0*  57344 none            none                  0    0        0    0    0
>> lo0    32992 127            127.0.0.1          20027    0    20027    0    0
>>                             224.0.0.1

>> # l1cmd serial
>> BSN: MSM019    SSN: 08:00:69:10:52:A1    Time: 11/02/2021 05:06:08 GMT  Security: OFF
>> Public Key data in EEPROM is invalid

So location of Bedrock PROM is still TBD...

BTW, looking forward to seeing positive result with your Fuel repair, which looks like it is going really well.
I see you have moved Fuel from "want" to "have" in your signature ;-)

Cheers from Oz,

jwhat/John

[weblacky]

You noticed that! Haha...yeah I figured since the mainboard works...it's a Fuel. Mainboard has a tab-broken fan connector (still works but I'll need to replace that too).

Yeah I need to get things in order for a real boot...I'll obviously keep the thread updated!

[vvuk]

Replying here from the other thread, since this is more relevant here :)

---

I guess what I'm saying is AFAIK that there's only one PROM for IP35 machines, but stored in different locations.  Apologies if this is all fully known, just working through my own mental model:

- for IP35, there's only one PROM image

- for different machines it's stored in different locations: either the CPU boards or the system board.  This seems to be confirmed by the flash man page: "flash allows a user to manage the flash PROMs on the IO and CPU boards of Origin systems, the base system board on OCTANE systems and CPU boards on the SGI Origin 3000 server series".  On previous versions it does look like there was a copy on the IO board (confirmed later in the man page; the ip35prom image is the only one that's even installed on any ip35 hardware), but doesn't seem to be the case for ip35.  This is also why changing the cpu node board can change prom version on o350.

- Fuel is not mentioned here; it seems they went back to putting it on the CPU board (which is what I was getting at with the l1 prom commands -- that _is_ this PROM, the L1 is saying it's on the node board in an O350 and it can't see it on the fuel, because it's on the system board).

- I think on the Octane, PROM is not on the cpu boards, but some signaling that is read early on (maybe even pre-PROM) ends up setting cpu frequency.  They really should have kept this, but maybe couldn't because the Fuel is sort of a "stripped down" ip35 design.

- latest version is 6.210 for IP35.

- The dump from flash -D is not sufficient for flashing back; it's missing a header (flash -d -P ip35prom.img shows good info, flash -d -P ip35prom.img.dump shows garbage).  It seems to be a raw dump of the flash chip, though; e.g. there's a lot of log data at the end of one of my dumps (from the fuel).

- the dump from both systems is 4MB; implies to me that there's a 4MB flash chip somewhere on the board :)  (Base ip35 image is only 1.5MB)

- a few bit differences early in the dump, and then starting at 0x3e0000 (i.e. last 128kb of the flash chip), looks like maybe some variables, and then log data.  e.g. o350 has PLLWARCntA, PLLWARCntB, both have PLOI and LastModule.

For the dump -- my Fuel is 700Mhz.  Here's what I have at octal 160 and 220 offsets:

(for reference from previous dumps -- are they missing 2 zero bytes at the start of each sequence?:)
[800: 14 -> 15] 0000160 0000 2faf 0800 0000 0000 0beb c200
[600: 15 -> 16] 0000160 0000 23c3 4600 0000 0000 0beb c200
[800: 16 -> 17] 0000160 0000 2faf 0800 0000 0000 0beb c200

(including 0140, as the string "ip27conf" appears immediately before these values)
..............  0000140 0000 0015 549b ad85 6970 3237 636f 6e66
.................... \0  \0  \0 025  T 233 255 205  i  p  2  7  c  o  n  f
..............  0000160 0000 0000 29b9 2700 0000 0000 0beb c200

o350 (4x700):
.............. 0000140 0000 0015 549c ad85 6970 3237 636f 6e66
..................... \0  \0  \0 025  T 234 255 205  i  p  2  7  c  o  n  f
.............. 0000160 0000 0000 29b9 2700 0000 0000 0beb c200

This value is where the cpu frequency is stored (at offset 0162 / 0x72):
0x29b92700 == 700000000 (note identical value on both 700MHz systems)
0x2faf0800 == 800000000
0x23c34600 == 600000000

The later region for completeness:

(for reference from previous dumps:)
[800: 14 -> 15] 0000220 0000 0002 0000 00f0 0000 000e 0000 0010
[600: 15 -> 16] 0000220 0000 0002 0000 00ad 0000 000f 0000 0010
[800: 16 -> 17] 0000220 0000 0002 0000 00ee 0000 0010 0000 0010

mine, 700Mhz:
..............  0000220 0000 0002 0000 00d5 0000 0008 0000 0010

o350 for comparison (4x700):
..............  0000220 0000 0000 0000 00c3 0000 001b 0000 0010

There may be checksums or other values though, so it might not be as simple as just changing the frequency value.