I've tested both methods and I got the same results for both of them having "i2c off" in both cases.
Were you able to find the problem?
I filed this as bug 328, http://marcbug.scc-dc.com/bugzilla3/show_bug.cgi?id=328 I haven't seen any updates to the bug, but Bugzilla is the best place to follow progress. You can add yourself to the CC list for bug 328.
Both methods involve using RCCE to set a new voltage. The i2c on/off just determines who can read the voltage. One method had i2c on and the other has i2c off. In both methods I set the voltage with a RCCE program, and RCCE doesn't care what i2c is set to. I don't understand what you mean when you say "having i2c off in both cases."
When i2c is off, one should be able to read it from the FPGA register. This is running the status program on a core.
When i2c is on, one should be able to read the voltage with the BMC status command.
I can read the voltage with both methods. However, when I read with the status program, I see the voltage appear in the wrong place. Namely, I drop the voltage in VCC4 and the status program shows me the voltage change in VCC5. I think the change really does occur in VCC4.
Welcome to the BMC server of marc101bmc!
You are participant #1
Access to I²C power bus is currently routed to BMC
I²C access now switched to FPGA.
All environment information is stale from now on!
I²C access now switched back to BMC.
All environment information will be uptodate in a few seconds.
What I wanted to say is that I don't see this behavior and that for me it works fine and shows the same results for both configurations and ways of reading.
And I tried with i2c off for fpga reading and i2c on for bmc reading. Having different voltage values in each voltage island I don't see a change in the order when reading with the different methods. I think it should be a problem of the code you are using to read the voltage.
For the FPGA I use these addresses
I was using the status.c code provided with the download. Are you using your own version? If so, can you post what you are using? In any case I'll rerun my test and see if I can reproduce.
Has anyone else tried running the status program?
Hi Ted, have you noticed that all the voltages are exactly shifted by one slot between your outputs, wrapping around from 7 to 0? It's not obvious at first sight as the values are not represented in the same number of digits. To me it sounds like someone made a classic "off by one" error in one of the programs or interfaces.
sccBmc status RCCE status program (changed order)
OPVR VCC0: 1.0948 V <--> Info: - OPVR VCC1: 1.095 V
OPVR VCC1: 1.0941 V <--> Info: - OPVR VCC2: 1.094 V
OPVR VCC2: 1.0913 V <--> Info: - OPVR VCC3: 1.091 V
OPVR VCC3: 1.0934 V <--> Info: - OPVR VCC4: 1.094 V
OPVR VCC4: 0.8420 V <--> Info: - OPVR VCC5: 0.842 V
OPVR VCC5: 1.0896 V <--> Info: - OPVR VCC7: 1.090 V
OPVR VCC7: 1.0872 V <--> Info: - OPVR VCC0: 1.087 V
Also kind of weird there's no VCC6, but there is a VCC7...
VCC2 and VCC6 are the same ... that's why VCC6 is not listed. Both 2 and 6 represent the entire mesh.
The SCC numbers the power domains different from RCCE
RCCE: 3 RCCE: 4 RCCE: 5
SCC: 0 SCC: 1 SCC: 3
RCCE: 0 RCCE: 1 RCCE: 2
SCC: 4 SCC: 5 SCC: 7
I attached a pdf that shows the test I ran. I still see the problem I originally reported. I'm using the status.c that came with the original download. I have not modified it. I have read the status.c and do not see an problem with it. But it does report voltage changed in the wrong domain.
Enric, do you see something different on your system for this very same test? Are you using the provided status program or did you write your own. If you are using your own, can you post it?
bug328.pdf 124.9 K
Ok, I reproduced your experiment and you are right.
Readings from the FPGA are shifted, either the mapping or the manual should be changed.
I'll subscribe to the bug to see if something is done.
Addr Real Voltage
Vcc0 0x8400 -> VCC7
Vcc1 0x8404 -> VCC0
Vcc2 0x8408 -> VCC1
Vcc3 0x840C -> VCC2
Vcc4 0x8410 -> VCC3
Vcc5 0x8414 -> VCC4
Vcc7 0x8418 -> VCC5