[weblacky]

Hi Kuba,
I am right on the cusp of trying a lot of these ideas. What I'm really interested in is whether information overlaps between the bedrock storage and the PROM.

But my biggest concern right now is the CPU speed being synchronized between firmware chips, if that information is in more than one place. This comes from the fact that using the flash command output from a couple of our posts you can see that it says "programming bedrock" and we know that inside the PROM dump from RAM there is a C structure that carries the variables of cache frequency, hub frequency, and CPU frequency at a minimum. Possibly even cache size.

It isn't fully known if there really is a vestigial storage area or if the information is merged from a bedrock source. So my initial concern is does the bedrock storage, that might be the third chip, which is designed for boot code storage, may contain the bedrock storage. Or maybe it doesn't. So what would happen if you were to change the flash image say for PROM while the bedrock is unchanged? I would assume the bedrock wins in what the CPU is actually configured with. So if the two aren't in sync is one able to say I "I'll defer to my partner" or whether you just have a totally messed up system if the bedrock & PROM storage are not in sync from CPU settings.

A part of me feels the L1 probably stands apart from this synchronization worry.

The bigger reason for worry is unless you have a client who had a bad PROM flash or something like that, who knows their own CPU speed, you might have to match all these together to get any CPU speed to work. If the client knows the original CPU speed you could probably leave the bedrock alone and simply program PROM with a copy of that CPU speed struct merged into the image before chip flashing.

So really my concern is about the bedrock, and the only reason I say that is we can get different PROM dumps using a dump command in for Irix and since this C struct has already been found that carries these CPU parameters we could just modify that section of the image as a secondary workflow from one firmware image, for PROM specifically. but since I have not yet taken a look at that boot code IC, third chip, if that isn't what we consider the bedrock storage then synchronizing the CPU speed is going to be a real pain!

Another idea I had but I'll definitely need help with this because I don't understand firmware and encoding as much as I should at the moment. Is to pull a PROM chip's final flash information off the bare chip and then also get the original PROM bin file from IRIX and compare the two and find out where the sections are different. We know that the PROM is customized during the flash routine and then written. I think that's going to be our opportunity to know what is set up when PROM is flash by simple comparison. We still may not know where that those values come from inside the bedrock, but at least we know how they would modify the PROM by comparing these two files. So if anyone can help track down the PROM bin images in IRIX and get them into a format that either the EPROM flasher or a normal hex editor can read without some weird problem then when I take dumps of these chips I have something to compare it to you and find the regions that are dissimilar. That'll tell us what information needs to be plugged in to custom flash a PROM chip. Then the problem becomes it's obviously synchronize from somewhere and they probably have to agree.

[ruckusman]

Great thread.
Some clues that may assist you with this.

If you get the datasheet for the atmel prom chip you will likely see that it has a protected mode which can be switched back off - in fact there was a SGI patch for the O2 PROM, as the previous PROM version allowed resetenv -f to rewrite the protected region, WHOOPSEE, I pity the poor user that discovered that bug, anyway...

I consider that there's a boot code which is processor independent which loads first, at least on the O2 for certain - then it obviously moves to higher regions of the chip and does the further testing and initialisation - this is where things like your full CPU setup reside.

Some of the PROM flash commands from the patches can be enlightening if you look at the entry points specified in those commands.

There's also good clues to be gained by just using binwalk on PROM image files - there's usually several easily identifiable elements which have clearly identified regions of where they flash to the atmel prom chip.
Binwalk doesn't work the same way on all PROM image files BTW.

I suspect, but cannot yet prove that because the atmel chips are written in segments with the extra space potentially loaded with zeros, they are after all designated as 8 x 512K.

So although a PROM image file for flashing may be 1.6MB on disk, it may likely occupy more space than that on the PROM chip - it would make it easier to code for a PROM if the code and data segments stay put and a change to one element (increasing size, or for instance adding support fo the 1600SW in the case of the O2) didn't necessitate re-writing the entire PROM code due all of the bits and pieces residing in different memory locations on the chip.

The binwalk output is also more revealing on the IPXX.ide files in this regard, than it is for many prom images as that protected code segment isn't in that image at all, so no file header information is there either.

A further clue is looking at the flash commands themselves, which usually specify an entry point for the code, so there's always the original 'boot' code remaining untouched, otherwise you've got a brick if it goes pear shaped.

Binwalk is also useful to look at the stand IPXX.ide files as these seem to be most of what would execute at boot with the diagmode set - thorough hardware tests.

The standalone tests do after all (re)initialise much of the hardware and run tests on that hardware.
Many that I have examined quickly have ESP32 flash images - potentially these are things like SCSI controller and graphics firmware.

Anyway, if you're looking to flash new chips then solder them, it would likely be necessary to read out an entire prom chip with an actual reader to obtain that first loaded 'boot' code.

Has anyone compared a prom.image with a dump obtained via the flash -D command to see if there's any 'extra' in the dump?

Also worth noting there's some worthwhile threads on eevblog regarding TSOP readers/burners - they're nowhere near as expensive as they used to be, with some of the reader/writer hardware and software, plus a set of clips that can be secured to a PROM in situ you may be able to write a chip as it exists - soldered onto the board.