[jwhat]

Hi Weblacky,

my machine has 4GB RAM so memory location is different, but I can easily find the "ip27conf" area:

>> ?-192.168.XXX.XXX-L2>power up
>>
>> re-entering system console mode (001a01 CPU0), <CTRL_T> to escape to L2
>> Starting PROM Boot process
>> hubii_link_good: A-brick attached to module 001c01.
>> HUB at 0x0 attached as widget 0xa
>> 001c01/0xa/xbow_arb: nasid= 0x0 xbow_base= 0x9200000000000000
>> 001c01/0xa/xbow_arb: 622 master is 0xa
>> Check_master: link 10 is master
>> hubii_link_good: A-brick attached to module 001c01.
>> Check_master: link 10 is master
>>
>>
>> IP35 PROM SGI Version 6.211 built 04:16:18 PM Jan 25, 2008
>> built for bedrock rev. 1.1 or greater
>> running in IP34 mode
>> Running in DDR mode
>> Local master CPU A revision: f42
>> PROM length: 0x168648, BSS length: 0xa7a0, flash count: 16
>> Configured bedrock clock: 200.0 MHz
>> Status of local IO: 0x1 0x3fc0fff6403
>> Bedrock Rev: 2, Module: 1 (001c01) from Sys Ctlr
>> On PROM entry: ERR_EPC=0xc00000001fc02ac0 (0xc00000001fc02ac0)
>> Configuring memory
>> Local memory configured: 4096 MB (premium)
>> *** Warning: System controller debug switches are non-zero (0x10d)
>> *** Diag level set to None (2)
>> *** Info level set to verbose
>> *** Boot stop requested at Global (2)
>> before reading NICHub NIC: 0x52275dad
>> SR1 set to 0x0000081698349000
>> SR0 set to 0x0000000052275dad
>> Testing/Initializing memory ............... DONE
>> Copying PROM code to memory ............... Copy PROM (0x9000000018000000) to RAM (0x9600000001a00000), len 0x168648
>> Done
>> DONE
>> Skipping secondary cache diags
>> CPU A switching stack into UALIAS and invalidating D-cache
>> CPU A switching into node 0 cached RAM
>> CPU A running cached
>> Initializing kldir.
>> Done initializing kldir.
>> Initializing klconfig.
>> init_klcfg: nasid 0 start 9600000000030000 size 10000
>> Done initializing klconfig.
>> Discovering local IO ...................... Check_master: link 10 is master
>> Check_master: link 10 is master
>> DONE
>> CPU A initialized subnode
>> Discovering NUMAlink connectivity .........
>> Local hub NUMAlink is down.
>> *** Local network link down
>> DONE
>> Found 1 objects (1 hubs, 0 routers) in 5894 usec
>> Waiting for peers to complete discovery.... Discovery results:
>> ENTRY 0: HUB(52275dad)
>> NASID=-1 Mod=1 Flg=0x9500000 PROM=6.211 Route=N/A
>> MODULE=001c01 PARTITION=0 SPACE=RESET
>> Port 1 connection: Not connected
>> Port status: NF
>> DONE
>> ...
>> ...
>> ...
>> A 000 001c01:
>> A 000 001c01: *** Entering POD mode on node 0
>> A 000 001c01: POD SysCt Cac> la 0x9600000001a00068 8
>> A 000 001c01: 9600000001a00068: i p 2 7 c o n f
>> A 000 001c01: POD SysCt Cac> lb 0x9600000001a00068 32
>> A 000 001c01: 9600000001a00068: 69 70 32 37 63 6f 6e 66 00 00 00 00 2f af 08 00
>> A 000 001c01: 9600000001a00078: 00 00 00 00 0b eb c2 00 00 00 00 00 00 13 12 d0
>> A 000 001c01: POD SysCt Cac>

So can see that this is the memory region that corresponds to the "/usr/include/sys/SN/SN0/ip27config.h" header file found by vvuk where:
0x69703237636f6e66 == "ip27conf" area marker.

So issue now is if you poked data into this areas, can you get the machine to continue its boot process from here.... as typically in POD/CAC you so "reset" which results in reboot and reload into memory of the PROM.

Cheers from Oz,

jwhat/John.

[weblacky]

What instruction do we need to dump the entire struct (including the checksum)?

[jwhat]

Hi Weblacky,

you could get the entire dump by turning on logging in your terminal emulator and the simply dumping the entire loaded section:

>> Copying PROM code to memory ............... Copy PROM (0x9000000018000000) to RAM (0x9600000001a00000), len 0x168648

so: lb 0x9600000001a00000 0x168648

EDIT: Note the second argument is "COUNT" (in bytes in this case) so you can choose to dump as much or as little as you want.

But I would expect the dump would just be same as what you got via "flash -D" as it says it is just copying the PROM into RAM.

cheers from Oz,

jwhat/John.

[weblacky]

I was hoping for just the struct region, so that we could copy & paste other structs into the region...not entire prom.

[jwhat]

Hi Weblacky,

I transferred dump to Ubuntu and used "hexdump" to produce a "nicer" view. Here is full configuration section for 800 MHz CPU

00000060 00 00 00 15 54 9b af 85 69 70 32 37 63 6f 6e 66 |....T...ip27conf|
00000070 00 00 00 00 2f af 08 00 00 00 00 00 0b eb c2 00 |..../...........|
00000080 00 00 00 00 00 13 12 d0 00 00 00 01 00 00 00 10 |................|
00000090 00 00 00 02 00 00 00 ee 00 00 00 10 00 00 00 10 |................|
000000a0 00 00 00 06 00 00 00 d3 00 00 00 00 00 00 00 00 |................|

so putting this into ip27config.h :

#define CONFIG_INFO_OFFSET 0x60

typedef struct ip27config_s { /* KEEP IN SYNC w/ start.s & below */
uint time_const; /* Time constant */
/* 4 byes 0x15 == 21 */
uint r10k_mode; /* R10k boot mode bits */
/* 4 bytes 0x549baf85 == Reported via PO/CAC "cfg" Register */
__uint64_t magic; /* CONFIG_MAGIC */
/* 8 bytes 0x69703237636f6e66 = "ip27conf" */
__uint64_t freq_cpu; /* Hz */
/* 8 bytes 0x2faf0800 == 800,000 */
__uint64_t freq_hub; /* Hz */
/* 8 bytes 0x0bebc200 == 200,000 */
__uint64_t freq_rtc; /* Hz */
/* 8 byes 0x1312d0 == 1,250,000 */
uint ecc_enable; /* ECC enable flag */
/* 4 byes 0x01 == 1 */
uint fprom_cyc; /* FPROM_CYC speed control */
/* 4 byes 0x10 == 16 */
uint mach_type; /* Inidicate SN0 (0) or Sn00 (1) */
/ * 4 bytes 0x02 == 2 (== SN11) */
uint check_sum_adj; /* Used after config hdr overlay */
/* to make the checksum 0 again */
/* 4 bytes 0xee == 238 */
uint flash_count; /* Value incr'd on each PROM flash */
/* 4 bytes 0x10 == 16 (Number of flash counts */
uint fprom_wr; /* FPROM_WR speed control */
/* 4 bytes 0x10 == 16 */
uint pvers_vers; /* Prom version number */
/* 4 bytes 0x06 == 6 */
uint pvers_rev; /* Prom revision number */
/* 4 bytes 0xd3 == 211 */
uint config_type; /* To support special configurations
* If bit 0 is set it means that
* we are looking 12P4I config
*/
/* 4 bytes 0x0 == 0 */
} ip27config_t;


EDIT:

Also as per boot diags: copying PROM code to memory ............... Copy PROM (0x9000000018000000) to RAM (0x9600000001a00000), len 0x168648
You can read PROM via POD/CAC directly using address: 0x9000000018000000
So it maybe possible that you can also write directly to these memory locations using the corresponding store commands:

>> A 000 001c01: Store byte: sb ADDR [VAL [COUNT]]
>> A 000 001c01: Store half-word: sh ADDR [VAL [COUNT]]
>> A 000 001c01: Store word: sw ADDR [VAL [COUNT]]
>> A 000 001c01: Store double-word: sd ADDR [VAL [COUNT]]
>> A 000 001c01: Store and verify: sdv ADDR VAL


Cheers from Oz,


jwhat/John

[weblacky]

Yo All,
A question/comment has been put to me that gave me pause as to ANOTHER solution to this PIMM-change problem (900 Mhz-ers mostly), but also BAD flashes.  That's actually what the original comment was about, how would you cure a corrupted, interrupted, PROM flash, specifically on a Fuel Mainboard? 

They claim that they made the mistake of installing a PROM upgrade when they suspected they had a graphics card issue that caused the system to freeze up. But they assumed that the freezing was caused by specific feature of a graphics system when you run a graphics intensive program. So they shut everything off and just simply attempted to upgrade their PROM on the desktop console but apparently the system froze during this and the PROM has never been working since. I don't know if their L1 works, I assume it does, but I don't have the board at this time. But this user made a comment that they had investigated and they were fairly certain they knew where the PROM was actually being stored on the board.

I've been told that the two sticker-labelled chips near the lower XIO graphics slot IS the PROM...spread over two chips...perhaps interleaved...who knows, at this time.

   

Since the Atmel ID chip is separated, we KNOW the IDENTITY isn't embedded in the PROM image.  So what about grafting a pre-existing the PROM image from a donor system with the correct CPU (or at least a 500Mhz PIMM config)!  I don't have the equipment, currently, to do this but apparently they are just TSOP chips so soldering isn't an issue.

I also don't know the chips because the stickers cover them presently.  But MAYBE taking a late-version PROM image (same board part number required?) and over writing those two chips (identically with the pair from a donor) and then boot the system and perform an all clear...but would it work?

The L1 can obviously run with ANY misconfigured CPU, so we KNOW that data isn't intermingled.  So a previous L1 with a grafted PROM image should be Okay as it should learn its ID from the atmel chip under a full reset of ALL NVRAM data.

What do you think?  

I'm also starting to wonder if you COMBINE the "data dumps" from this thread with real ripped PROM images and if someone can read the last PROM upgrade patch upgrade file (IRIX Patch 7208: IP35 PROM) as a firmware image ...maybe we can sectionally find differences and similarities to:

1. Are all PROM images exactly the same with JUST the CPU CONFIG struct difference...or is there more?
   
2. Are these just small sections where, given enough images to play with, we can find out how to change or patch sections...then write directly to the chips?
   
3. Will simple, full, untouched transplant of chips or their images...without modification of any kind...work?
   
4. Does this mean we can providing pre-flashed chips (on 500Mhz settings of course) as a product for people to attempt removal and installation after a bad flash, PIMM screw-up, or other unseen issue for Fuel?
   

Thoughts, knowledge, comments?

[jwhat]

Hi Weblackly,

from recollection, pretty sure we did comparison of dumps for different “speed setting” proms dumps and we know that just the identified area that maps to definitions of the ip27config.h are critical areas.

To test the theory of PROM chip, could you just remove the stickers from the damaged Fuel board I sent you?

Having PROM distributed over two chips sounds highly unlikely to me… if those are the chips then it would seem more likely, that there is some redundancy mechanism.

But this is all speculation… ;-)

cheers from Oz,

jwhat/John

[jan-jaap]

The two PROM chips could well be the CPU PROM and IO PROM. On IP27, the CPU PROMs were on the nodeboards and the IO PROM on the IO6/IO6G. On a Fuel they are both on the mainboard but architecturally it's close to IP27 so they may simply have kept the dual chips.

[weblacky]

The two PROM chips could well be the CPU PROM and IO PROM. On IP27, the CPU PROMs were on the nodeboards and the IO PROM on the IO6/IO6G. On a Fuel they are both on the mainboard but architecturally it's close to IP27 so they may simply have kept the dual chips.

This was my exact thinking in formulating my response. But I wasn't sure if architectures like the Tezro might have one chip on the IO9 controller and the other chip on the main board. Obviously Fuel is a single board device in that regard, but same family so same overall component needs during design. So my brain was leading me there.

The programming output from the flash command does talk about programming the bedrock, so perhaps one of them is the programming for the bedrock?

But that being said, I think the concept might hold water. After all, we're talking about recovering a mainboard so as long as it's the same revision, one would think a complete overwrite would still be OK.

I can see a partial rewrite might have compatibility issues or segment update issues, but perhaps a total replacement where everything was chill with the donor might still be a thing. It's definitely going to be on my "look into" list.

[kubatyszko]

The two PROM chips could well be the CPU PROM and IO PROM. On IP27, the CPU PROMs were on the nodeboards and the IO PROM on the IO6/IO6G. On a Fuel they are both on the mainboard but architecturally it's close to IP27 so they may simply have kept the dual chips.

This was my exact thinking in formulating my response. But I wasn't sure if architectures like the Tezro might have one chip on the IO9 controller and the other chip on the main board. Obviously Fuel is a single board device in that regard, but same family so same overall component needs during design. So my brain was leading me there.

The programming output from the flash command does talk about programming the bedrock, so perhaps one of them is the programming for the bedrock?

But that being said, I think the concept might hold water. After all, we're talking about recovering a mainboard so as long as it's the same revision, one would think a complete overwrite would still be OK.

I can see a partial rewrite might have compatibility issues or segment update issues, but perhaps a total replacement where everything was chill with the donor might still be a thing. It's definitely going to be on my "look into" list.

Hmm, given that there's just a handful of revisions, all we really need to get this working is a set of "flashable" PROM images for 500Mhz PIMM for every revision.
Then it's all about replacing those 2 or 3 chips on the board with flashed versions.
There are 3 chips, 2 are on top near the PCI slots, labeled "L1 PROM" and "IP35 PROM". The third chip is on the underside, directly below the IP35 PROM - that might be the backup PROM.
This may be even easier - replace only one chip, BACKUP?, with a 500Mhz PIMM version, boot the machine (set which PROM image in L1 , I vaguely recall it was possible) and then use standard flash tool to do the rest of the repair.

Understandably, this is not the same as doing it purely via L1 or CAC commands, and rather invasive (needs soldering), but it's a small price to pay to "unbrick" a motherboard isn't it ?

Cheers