[weblacky]

Hi Jwhat,
I think I already tried this. I can’t be 100% certain because it’s been pretty much a year now. I just took a look back through my saved L1 logs back when I was dealing with the fuel. I am pretty sure that I had specified debug to happen every time I did this but again it’s been a little while.

What happens is the SRAM cache diagnostic fails, which is literally the second or third thing that the PROM does once it’s bootstrapped from L1. After the failure the firmware immediately claims that it’s going to attempt to clear the cache with the power cycle and there’s nothing I can do about it. It then soft-resets and you end up back at the L1 auto power on prompt and then it does it again and again and again in a cycle. So from what I can see when I have the debug switch enabled it will not stop at the POD as it doesn’t get far enough in the code to offer it.

My assumption is that PROM runs on the main CPU because obviously it’s a boots strapping process. Because the cache fails the diagnostic it doesn’t believe it can reliably run any PROM code without a working cache. So my initial thoughts were that such an error is catastrophic to the stable running of the PROM, so there’s no diagnostic to be offered on what would be an unstable platform.

I’m pretty sure this is what I experienced looking back through my notes.

Although I think this is what we expected. I thought the previous claim wasn’t so much CaC mode but was using the primitive L1 memory commands to actually change shadowed from variables before bootstrap?

At least that’s what I thought we were close to before? I know we had already jointly seen the structure that has these variables in an in memory. But nobody had the guts to attempt in memory change of the structure. I understand because I refused do it as well given that I don’t have a sacrificial system.

But I more remember us getting close to simply changing the in-memory representation of the struct that carried the three variables we wanted to change.