[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?