Issue powering on - org.openbmc.control.Power & pgood_wait

Issue powering on - org.openbmc.control.Power & pgood_wait

[Stephen Boylan]

[-- Attachment #1: Type: text/plain, Size: 1936 bytes --]

Hello all,

On the board I'm using - based on the evb2500 phosphor build - I've run into an issue trying to power the system on. Here is what I've noticed occurring

A basic overview of the power on request - the AST2500 sends a PWR_ON signal to an FPGA to request that the server power on. The FPGA sends back PGOOD and powers on the system. If the FPGA receives a continuous PWR_ON signal for more than 4 seconds, it will immediately shut down the server.

When I momentarily press the power button on the server or issue an "ipmitool chassis power on" command I see the following occurring by monitoring the pin of each related signal

  1.  "power_up_outs" GPIOs get asserted as per the configuration from gpio_defs.json
  2.  The FPGA starts to power the system up and asserts it's PGOOD pin, tied to "power_good_in".
  3.  "power_up_outs" remain asserted and cross over the 4 second limit.
  4.  The FPGA de-asserts "power_good_in" and immediately turns the system off.
  5.  A short time after the FPGA de-asserts "power_good_in", the "reset_outs" pins are asserted.
  6.  The "power_up_outs" signals stay asserted for 30 seconds, until the pgood_wait service times out, then they de-assert.

Additionally I can view /org/openbmc/control/power0 and see pgood in the data change to reflect the state of the pin.

My understanding is that pgood_wait is meant to signal that pgood has been received and then de-assert the "power_up_outs", however this is not happening. I can also see a message via journalctl about it timing out.

Does anyone have any idea why despite me seeing the pin receive the signal, that pgood_wait isn't recognising the change and triggering?

If I manually drive the power_up_outs pins to high and low within 1 second, using something like "echo 1 > gpio#/value ; sleep 1 ; echo 0 > gpio#/value" then everything works fine and the system will power up.

Regards,
Stephen Boylan


[-- Attachment #2: Type: text/html, Size: 4267 bytes --]