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