[jwhat]

Hi vvuk,

that is great thank you.

This confirms that we have found the right location where the CPU speed is stored.
And the acsi string marker "ip27conf" helps confirm this.

To your point about there being only 1 PROM that is true for single machines but not for a numalink'ed cluster.

Do you have more than 1 O350's ?

If so you could numalink them and see 2 x PROM being reported at boot.

Then you could pull the IO9 board and see if it now only reports 1 PROM on boot.

If this was the case then the PROM storage is on the STI chip (with the snaphat on top).

Also there is a 6.211 PROM for Fuel / O350 which is on a patch. I am not sure exactly which one it is...

>> # flash -v
>> setting default path_name to /usr/cpu/firmware
>> m001c01: Board EEPROM configuration values not available. Using PSC code.
>> m001c01: freq cpu 800000000 freq hub 200000000 mode 549baf85
>> NOTE: m001c01: prom file version 6.211 is the same as current version 6.211: prom not flashed


Cheers from Oz,


jwhat/John.

[weblacky]

My belief from the neko-hint of Debug mode was that it's either IN "registers" or at a specific memory location. And you'd fiddle with it using these: https://wiki.preterhuman.net/POD_Commands

I assumed memory offsets. I'm not totally following what you guys have found in Hex. Did you find a consistent storage location for some/all the flash variables for CPU?

[vvuk]

Hi vvuk,
To your point about there being only 1 PROM that is true for single machines but not for a numalink'ed cluster.

Do you have more than 1 O350's ?

If so you could numalink them and see 2 x PROM being reported at boot.

Then you could pull the IO9 board and see if it now only reports 1 PROM on boot.

Interesting; I'd expect 1 PROM per node board (so per o350, in this case).  But pulling an IO9 board and having it go down to one is surprising.  I have two, both with io9 boards; I should be getting an o350 cbrick soon though, sans io9.  Will check as that one is intended to be numalink'd with one of my current ones and removing an io9 is annoying :)

I'm trying to find some high rez pictures of an ip53 nodeboard; if I can't, i'll take some.  Should be possible to identify a 4MB eeprom or similar chip on there.  I wish I had taken a picture of the STI chip last time I replaced a snaphat!

Also there is a 6.211 PROM for Fuel / O350 which is on a patch. I am not sure exactly which one it is...

Ah right, good reminder! I actually just went through all the patches for 6.5.30 (well, the ones on the irixnet ftp server) and documented roughly what they do here: https://hackmd.io/KwkGm6T9QgGljpVRyLX0qQ  I think this is 7208, where the release notes just mention fixes to fibre channel connections in PROM.  I'd meant to update anyway, may as well be on the latest.

---

One more thing! So `ip27conf` is a nice clue, that leads to /usr/include/sys/SN/SN0/ip27config.h:

typedef struct ip27config_s {          /* KEEP IN SYNC w/ start.s & below  */
    uint                time_const;    /* Time constant                    */
    uint                r10k_mode;      /* R10k boot mode bits              */

    __uint64_t          magic;          /* CONFIG_MAGIC                    */

    __uint64_t          freq_cpu;      /* Hz                              */
    __uint64_t          freq_hub;      /* Hz                              */
    __uint64_t          freq_rtc;      /* Hz                              */

    uint                ecc_enable;    /* ECC enable flag                  */
    uint                fprom_cyc;      /* FPROM_CYC speed control          */

    uint                mach_type;      /* Inidicate SN0 (0) or Sn00 (1)    */

    uint                check_sum_adj;  /* Used after config hdr overlay    */
                                        /* to make the checksum 0 again    */
    uint                flash_count;    /* Value incr'd on each PROM flash  */
    uint                fprom_wr;      /* FPROM_WR speed control          */

    uint                pvers_vers;    /* Prom version number              */
    uint                pvers_rev;      /* Prom revision number            */
    uint                config_type;    /* To support special configurations
                                        * If bit 0 is set it means that
                                        * we are looking 12P4I config
                                        */
} ip27config_t;

typedef struct {
    uint                r10k_mode;      /* R10k boot mode bits              */
    uint                freq_cpu;      /* Hz                              */
    uint                freq_hub;      /* Hz                              */
    char                fprom_cyc;      /* FPROM_CYC speed control          */
    char                mach_type;      /* Inidicate SN0 (0) or Sn00 (1)    */
    char                fprom_wr;      /* FPROM_WR speed control          */
} ip27config_modifiable_t;

CONFIG_MAGIC is 0x69703237636f6e66 -- which is "ip27conf"!  So we have the start of a ip27config_t struct at octal 0060.

So, if I were to decode my fuel's struct:

time_const = 0x00000015
r10k_mode = 0x549bad85
freq_cpu = 0x0000000029b92700 = 700_000_000
freq_hub = 0x000000000bebc200 = 200_000_000
freq_rtc = 0x00000000001312d0 = 1_250_000
ecc_enable = 0x00000001
fprom_cyc = 0x00000010
mach_type = 0x00000002 // comment says SN0 = 0, Sn00 = 1, so.. 2 = "Weird fuel mach" :D
check_sum_adj = 0x000000d5
flash_count = 0x00000008 // here's weblacky's flash count
fprom_wr = 0x00000010

// these 3 values are not in the "modifiable" struct, which makes sense
pvers_vers = 0x00000006 = 6
pvers_rev = 0x000000d2 = 210  // so 6.210
config_type = 0x00000000

so the modifiable portion of this does have the frequencies, and is actually intended to be modified.  the `check_sum_adj` field is used to correct the checksum -- looks like the intent is for the checksum to be 0, so the adj field is set to whatever is necessary to make the final checksum 0.  (What the checksum range is is TBD, but it should be possible to figure this out by just looking for ranges in the dump where the checksum is 0)

[jwhat]

Hi vvuk,

I have a couple of spare O350 "2U Interface" boards in my study, there is no evidence of any EEPROM chip (aside from DALLAS obviously) on them...
but I should qualify that by saying I am not an electrical engineer ;-)

So likely PROM is either on the IO9 or the CPU board.

I will see about taking picture of boards.

I got the boards from a very well known ex-Nekochaner (I will leave it him/her to reveal themselves ... ;-) ) as part of need to rapidly move to different country's due to COVID.
Unfortunately the boards got very smashed up in shipping and have very bent FAN pins and Caps knocked off, but putting then to use helping to repair and keep these machines running is a good use of them.

BTW if you have 2 x O350 you can link them directly via Numalink ports without R-Brick (Numalink router).
Your only need the Numalink Router if you want to connect together 3 or more machines.

Cheers,

jwhat/John

[vvuk]

Also, I should add -- I don't know that the POD commands will help. They can read/write values in memory, or otherwise mapped to memory. But this is stored on some kind of nvram, which is not necessarily going to be mapped in a way that can just be written directly. But, for example, I suspect if you read a doubleword via POD commands at 0x9000000100000068 I think you'll find 0x69703237636f6e66 . (in other words, "ld 0x9000000100000068" should read that number, or "la 0x9000000100000068" should show you "i p 2 7 c o n f"). But I don't know if that's the actual in-flash values (unlikely), or copied into memory at boot (more likely?)

[weblacky]

Also, I should add -- I don't know that the POD commands will help.  They can read/write values in memory, or otherwise mapped to memory.  But this is stored on some kind of nvram, which is not necessarily going to be mapped in a way that can just be written directly.  But, for example, I suspect if you read a doubleword via POD commands at 0x9000000100000068 I think you'll find 0x69703237636f6e66 .  (in other words, "ld 0x9000000100000068" should read that number,  or "la 0x9000000100000068" should show you "i p 2 7 c o n f").  But I don't know if that's the actual in-flash values (unlikely), or copied into memory at boot (more likely?)

The intention isn't permanency.  The intention is...OHHH GAWD MY PIMM IS GONE AND THIS NEW ONE IS THE WRONG SPEED AND MY BOARD IS TRAPPED...cough...cough...

The memory is usually copied from native storage into some kind of working storage, it's the change of this working storage that gets your mainboard boot with "hacked" CPU values...so you can then flash the REAL natives one and have a working fuel under Irix.  Trapped Fuel mainboards are always an issue.  POD mode was the "suggested" promise that perhaps you can do the change on a system where you're already painted into a corner.

I'd like to think a programmer would simply map or intake the entire struct into memory and work with it...so perhaps there is a way of scanning using the POD commands for the identifying string you've found by using the Print Address function?

I get your point, they MAY have done a read-only mapping into EPROM to read the values, or who knows where they are copied to...and if they are mapped there may not be a "write" function to hold a copy in the mapping technique.  But a part of them thinks they'd HAVE to else all their diagnostic and advanced commands would be meaningless as they could not change anything for testing...which is actually was POD is for!?  So I'd like to think ALL these memory commands must be in working memory (ignoring native storage) and they may not be aligned to these prom offsets.

All good points, we're in the unknown after all.  But I'd hazard a guess it's worth the time to see what happens when you "get" a value that you want and try to "set" that same value and see if it takes and if it does...does it persist or does it change change working memory and native storage is unaffected?

Interesting stuff.

[jwhat]

Hi vvuk,

Booom!!

>>CONFIG_MAGIC is 0x69703237636f6e66 -- which is "ip27conf"! So we have the start of a ip27config_t struct at octal 0060.

I think you have found what we are looking for, in "/usr/include/sys/SN/SN0/ip27config.h" !!

If you look up in the discussion you can see the POD/CAC commands which seem to relate to writing into PROM.

The problem is that they only info in what you get from the POD/CAC help command, which is not much.

Awesome.

The really big question is can you somehow get the Fuel to boot into lower speed to allow you to zap the PROM before it goes into full boot cycle.

If so we have a way to save what might initially appear to be dead Fuel boards because they had faster CPU in them.

The other way would be to have a 900 MHZ Fuel PIMM lying around just for the sake of trying to rescue old board ...

I know I don't have such a PIMM ;-)

EDIT #1: I see Weblacky and I responded around the same time. He is thinking of memory ZAP, I am thinking PROM ZAP. Either way could work.... if it worked ;-)

EDIT #2: On POD/CAC there is actually 2 modes CAC == Cached , DEX == Dirty Exclusive (see: https://www.graphica.com.au/docs/origin-...ooklet.pdf page 174), This doco is also available on Web Archive. This might help in Memory (temp) vs persistent (prom) commands... just floating ideas here.

Cheers from Oz,

jwhat/John.

[weblacky]

Hi vvuk,
To your point about there being only 1 PROM that is true for single machines but not for a numalink'ed cluster.

Do you have more than 1 O350's ?

If so you could numalink them and see 2 x PROM being reported at boot.

Then you could pull the IO9 board and see if it now only reports 1 PROM on boot.

Interesting; I'd expect 1 PROM per node board (so per o350, in this case).  But pulling an IO9 board and having it go down to one is surprising.  I have two, both with io9 boards; I should be getting an o350 cbrick soon though, sans io9.  Will check as that one is intended to be numalink'd with one of my current ones and removing an io9 is annoying

I'm trying to find some high rez pictures of an ip53 nodeboard; if I can't, i'll take some.  Should be possible to identify a 4MB eeprom or similar chip on there.  I wish I had taken a picture of the STI chip last time I replaced a snaphat!

Also there is a 6.211 PROM for Fuel / O350 which is on a patch. I am not sure exactly which one it is...

Ah right, good reminder! I actually just went through all the patches for 6.5.30 (well, the ones on the irixnet ftp server) and documented roughly what they do here: https://hackmd.io/KwkGm6T9QgGljpVRyLX0qQ  I think this is 7208, where the release notes just mention fixes to fibre channel connections in PROM.  I'd meant to update anyway, may as well be on the latest.

---

One more thing! So `ip27conf` is a nice clue, that leads to /usr/include/sys/SN/SN0/ip27config.h:

typedef struct ip27config_s {          /* KEEP IN SYNC w/ start.s & below  */
    uint                time_const;    /* Time constant                    */
    uint                r10k_mode;      /* R10k boot mode bits              */

    __uint64_t          magic;          /* CONFIG_MAGIC                    */

    __uint64_t          freq_cpu;      /* Hz                              */
    __uint64_t          freq_hub;      /* Hz                              */
    __uint64_t          freq_rtc;      /* Hz                              */

    uint                ecc_enable;    /* ECC enable flag                  */
    uint                fprom_cyc;      /* FPROM_CYC speed control          */

    uint                mach_type;      /* Inidicate SN0 (0) or Sn00 (1)    */

    uint                check_sum_adj;  /* Used after config hdr overlay    */
                                        /* to make the checksum 0 again    */
    uint                flash_count;    /* Value incr'd on each PROM flash  */
    uint                fprom_wr;      /* FPROM_WR speed control          */

    uint                pvers_vers;    /* Prom version number              */
    uint                pvers_rev;      /* Prom revision number            */
    uint                config_type;    /* To support special configurations
                                        * If bit 0 is set it means that
                                        * we are looking 12P4I config
                                        */
} ip27config_t;

typedef struct {
    uint                r10k_mode;      /* R10k boot mode bits              */
    uint                freq_cpu;      /* Hz                              */
    uint                freq_hub;      /* Hz                              */
    char                fprom_cyc;      /* FPROM_CYC speed control          */
    char                mach_type;      /* Inidicate SN0 (0) or Sn00 (1)    */
    char                fprom_wr;      /* FPROM_WR speed control          */
} ip27config_modifiable_t;

CONFIG_MAGIC is 0x69703237636f6e66 -- which is "ip27conf"!  So we have the start of a ip27config_t struct at octal 0060.

So, if I were to decode my fuel's struct:

time_const = 0x00000015
r10k_mode = 0x549bad85
freq_cpu = 0x00000000549bad85 = 700_000_000
freq_hub = 0x000000000bebc200 = 200_000_000
freq_rtc = 0x00000000001312d0 = 1_250_000
ecc_enable = 0x00000001
fprom_cyc = 0x00000010
mach_type = 0x00000002 // comment says SN0 = 0, Sn00 = 1, so.. 2 = "Weird fuel mach"
check_sum_adj = 0x000000d5
flash_count = 0x00000008 // here's weblacky's flash count
fprom_wr = 0x00000010

// these 3 values are not in the "modifiable" struct, which makes sense
pvers_vers = 0x00000006 = 6
pvers_rev = 0x000000d2 = 210  // so 6.210
config_type = 0x00000000

so the modifiable portion of this does have the frequencies, and is actually intended to be modified.  the `check_sum_adj` field is used to correct the checksum -- looks like the intent is for the checksum to be 0, so the adj field is set to whatever is necessary to make the final checksum 0.  (What the checksum range is is TBD, but it should be possible to figure this out by just looking for ranges in the dump where the checksum is 0)

When you said offset 0600, did you mean from your PROM dump?  Because if so, I'd image a dump of PROM is dump of WORKING MEMORY PROM and not storage PROM.  Can you give us more info on how you did that and or a screenshot of a hex editor with pointers to some of the offsets to guide us around?

Because we can CHEAT, we don't NEED to know all the interrelated points (like the CPU mode bits), we can deal in COMPLETE structs!  If you can isolate the region (dummy light kind of idea).  We can ask people to perform a command to dump and show only that region?  Then post them, while it would be a lot of manual typing, if we figured out the command syntax, you could then MANUALLY enter the entire struct section by hand either offset by offset or whatever in the memory functions and just overwrite your entire in-memory struct with a known working version from someone else with the correct PIMM!

If you detail it more, we can collect the data from other members (as long as someone figures out a one-liner command from irix to cut and paste) and start posting known sections.  If we get them all, over time, then anyone can just follow the syntax command directions and enter values from a posted list of CPU structs.  We don't have to intuit them, just know this is the place to overwrite with known values, am I wrong?

---

Hi vvuk,

Booom!!

>>CONFIG_MAGIC is 0x69703237636f6e66 -- which is "ip27conf"!  So we have the start of a ip27config_t struct at octal 0060.

I think you have found what we are looking for, in "/usr/include/sys/SN/SN0/ip27config.h" !!

If you look up in the discussion you can see the POD/CAC commands which seem to relate to writing into PROM.

The problem is that they only info in what you get from the POD/CAC help command, which is not much.

Awesome.

The really big question is can you somehow get the Fuel to boot into lower speed to allow you to zap the PROM before it goes into full boot cycle.

If so we have a way to save what might initially appear to be dead Fuel boards because they had faster CPU in them.

The other way would be to have a 900 MHZ Fuel PIMM lying around just for the sake of trying to rescue old board ...

I know I don't have such a PIMM ;-)

EDIT: I see Weblacky and I responded around the same time. He is thinking of memory ZAP, I am thinking PROM ZAP. Either way could work.... if it worked ;-)

Cheers from Oz,

jwhat/John.

Well POD IS POWER ON DIAGNOSTICS...the CPU hasn't started yet.  Am I wrong?  The L1 doesn't use the Main MIPS CPU, so change in POD are real as POD is before boot, yes?  So is there really a problem here?  Aren't we already before CPU boot?

[jwhat]

Hi Weblacky,

really good point:
"Well POD IS POWER ON DIAGNOSTICS...the CPU hasn't started yet. Am I wrong? The L1 doesn't use the Main MIPS CPU, so change in POD are real as POD is before boot, yes? So is there really a problem here? Aren't we already before CPU boot?"

My answer is I don't know... ;-)

But I think we are getting closer to be able to test and see....

Can you get POD mode with no CPU installed ?

If my 800 MHz Module was not in such a fragile state I would just pull it out and put back the 600 MHz and see what happened, but I would hate to break it :-(

Cheers from Oz,

jwhat/John.

[weblacky]

Hi Weblacky,

really good point:
"Well POD IS POWER ON DIAGNOSTICS...the CPU hasn't started yet.  Am I wrong?  The L1 doesn't use the Main MIPS CPU, so change in POD are real as POD is before boot, yes?  So is there really a problem here?  Aren't we already before CPU boot?"

My answer is I don't know... ;-)

But I think we are getting closer to be able to test and see....

Can you get POD mode with no CPU installed ?

If my 800 MHz Module was not in such a fragile state I would just pull it out and put back the 600 MHz and see what happened, but I would hate to break it :-(

Cheers from Oz,

jwhat/John.

I read on Neko-archive that someone DID manage to get into L1 once without a PIMM...But you won't want to...as you don't LIVE-connect a PIMM.  I still believe these are in-memory representations...NOT presisient (given the implication). You'd have to power-off to install the PIMM, thereby losing all your work.  Didn't someone on this thread prove that you can start L1 with an incorrect PIMM (somewhat)?  I mean wasn't there a post very recently when we were talking about the "flash" technique and all that user showed was a "MISMATCH" of CPU values as an L1 alert...but nothing happened (granted he was underclocked so he could still boot to OS). But it was my gut feeling you just get that error and either CRASH on OS boot or the L1 refuses to boot you to OS, due to mismatch?  One of the two..I didn't think having an incorrect PIMM config prevented you from getting to L1?

I will be in a position to try this (if my Fuel works) as I have a VRM to inspect on a 600 Mhz PIMM I got as a research project from user:Noguri, last year (or more ago).  The PIMM was claiming to suffer a low voltage rail on PIMM via ENV Monitoring, he swapped out the PIMM and claimed the error went away, so blamed PIMM.  I was wondering if perhaps it was the VRM components on the PIMM (like the Buck converter output cap being bad).  Once mine is working, I was going to check it out...as I can also replace the ENV chip if I want, no probs.  If I can get things to work.. I'd have a 700Mhz and a 600Mhz PIMM for use.

The hope was to replace ALL the SMD polyCaps and MAYBE the DS1780 (that reads this stuff) and see what the PIMM did.  Given SGI used the same Buck converter chip in many places in this series of SGI, it's all kind of templated.  So I was hoping to find a fairly easy answer (likely cooking the Poly SMD caps was my first thought as high ESR or bad output caps will LOWER buck converter output...slowly as cap changes or heats, unless very bad..then just immediately).

This is also my hope for our dreaded 1.8v AUX Tezro/Origin issue we both share...I think it's the SMD Polycap ESR dragging down the voltage converter...I also ready bought the cap for that!