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