[x86-power-control]: press the power button for a long time that can't force turn off system power

[x86-power-control]: press the power button for a long time that can't force turn off system power

[Chris Chen (TPI)]

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

Hi all,

I am working on an ast2600 with Intel CPU.
The system power currently is able to turn on during Phosphor OpenBMC boot up after I completed works following:

  1.  enable ACPI in u-boot
  2.  set GPIOP0 ~ P3 pass-through in u-boot
  3.  porting ESPI driver from AST SDK v6.01 to linux-aspeed repository
  4.  add "&gpio0" with gpio-line-names which has POWER_BUTTON, POWER_OUT, SIO_S3, SIO_S5, etc. defintion in the dts, I think the "x86-power-control" repository required these.
  5.  append "x86-power-control" and "intel-ipmi-oem" repositories to image

However, I always only got the following logs when I pressed the power button for a long time (> 4s).
=====
power-control[263]: PowerControl: power button pressed
power-control[263]: powerStateOn: power button pressed event received
power-control[263]: Host0: Moving to "Graceful Transition to Off" state
power-control[263]: Graceful power-off timer started
=====

It doesn't occur "SIO_ONCONTROL value changed: 1 -> SIO power good de-assert event received", etc. operations and then to turn off the power.

Can anyone do me a favor to give me some clues for what I was wrong?


Thank you in advance for your help.

Regards,
Chris Chen


Legal Disclaimer :
The information contained in this message may be privileged and confidential. 
It is intended to be read only by the individual or entity to whom it is addressed 
or by their designee. If the reader of this message is not the intended recipient, 
you are on notice that any distribution of this message, in any form, 
is strictly prohibited. If you have received this message in error, 
please immediately notify the sender and delete or destroy any copy of this message!

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

Re: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Bills, Jason M]

On 7/23/2021 4:28 AM, Chris Chen (TPI) wrote:
> Hi all,
> 
> I am working on an ast2600 with Intel CPU.
> The system power currently is able to turn on during Phosphor OpenBMC 
> boot up after I completed works following:
> 
>  1. enable ACPI in u-boot
>  2. set GPIOP0 ~ P3 pass-through in u-boot
>  3. porting ESPI driver from AST SDK v6.01 to linux-aspeed repository
>  4. add "&gpio0" with gpio-line-names which has POWER_BUTTON, POWER_OUT,
>     SIO_S3, SIO_S5, etc. defintion in the dts, I think the
>     "x86-power-control" repository required these.
>  5. append "x86-power-control" and "intel-ipmi-oem" repositories to image
> 
> However, I always only got the following logs when I pressed the power 
> button for a long time (> 4s).
> =====
> power-control[263]: PowerControl: power button pressed
> power-control[263]: powerStateOn: power button pressed event received
> power-control[263]: Host0: Moving to "Graceful Transition to Off" state
> power-control[263]: Graceful power-off timer started
> =====
> 
> It doesn't occur "SIO_ONCONTROL value changed: 1 -> SIO power good 
> de-assert event received", etc. operations and then to turn off the power.
> 
> Can anyone do me a favor to give me some clues for what I was wrong?
Hi Chris,

Holding the power button should force a hardware shutdown.  The BMC only 
monitors this flow and doesn't participate.

Did your system shut down correctly and you just not see the logs in 
BMC?  Or, did the system stay on?

Thanks,
-Jason
> 
> 
> Thank you in advance for your help.
> 
> Regards,
> Chris Chen
> 
> Legal Disclaimer :
> The information contained in this message may be privileged and 
> confidential.
> It is intended to be read only by the individual or entity to whom it is 
> addressed
> or by their designee. If the reader of this message is not the intended 
> recipient,
> you are on notice that any distribution of this message, in any form,
> is strictly prohibited. If you have received this message in error,
> please immediately notify the sender and delete or destroy any copy of 
> this message!

回覆: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Chris Chen (TPI)]

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

Hi Jason,

Thanks for your prompt reply.

The system stays on, because I can hear the fan in PSU is still running and CPU heatsink is hot, besides, the log would show "Graceful power-off timer completed" and "Host0: Moving to "On" state" after 5 minutes. Here are all logs of the power-control for your reference. Hope this can provide more details.

=====
root@hudsonbay-obmc:~# journalctl | grep -e "power-control" -e "power control" -e "Power Control"
Jul 24 10:36:06 hudsonbay-obmc systemd[1]: Starting Intel Power Control...
Jul 24 10:36:09 hudsonbay-obmc power-control[198]: Start Chassis power control service...
Jul 24 10:36:09 hudsonbay-obmc systemd[1]: Started Intel Power Control.
Jul 24 10:36:09 hudsonbay-obmc power-control[198]: NMI_OUT set to 0
Jul 24 10:36:09 hudsonbay-obmc power-control[198]: POWER_OUT set to 1
Jul 24 10:36:09 hudsonbay-obmc power-control[198]: RESET_OUT set to 1
Jul 24 10:36:09 hudsonbay-obmc power-control[198]: NMI Source Property Monitor
Jul 24 10:36:09 hudsonbay-obmc power-control[198]: Initializing power state.
Jul 24 10:36:09 hudsonbay-obmc power-control[198]: Host0: Moving to "On" state
Jul 24 10:36:09 hudsonbay-obmc power-control[198]: POH timer started
Jul 24 10:36:38 hudsonbay-obmc power-control[198]: powerStateOn: POST Complete assert event received
Jul 24 10:36:38 hudsonbay-obmc power-control[198]: No action taken.
Jul 24 10:36:41 hudsonbay-obmc power-control[198]: powerStateOn: POST Complete de-assert event received
Jul 24 10:36:41 hudsonbay-obmc power-control[198]: Host0: Moving to "Check for Warm Reset" state
Jul 24 10:36:41 hudsonbay-obmc power-control[198]: Warm reset check timer started
Jul 24 10:36:41 hudsonbay-obmc power-control[198]: RestartCause set to xyz.openbmc_project.State.Host.RestartCause.SoftReset
Jul 24 10:36:41 hudsonbay-obmc power-control[198]: Host system DC power is off
Jul 24 10:36:41 hudsonbay-obmc power-control[198]: POH timer canceled
Jul 24 10:36:41 hudsonbay-obmc power-control[198]: failed to reset ACBoot property
Jul 24 10:36:42 hudsonbay-obmc power-control[198]: Warm reset check timer completed
Jul 24 10:36:42 hudsonbay-obmc power-control[198]: powerStateCheckForWarmReset: warm reset detected event received
Jul 24 10:36:42 hudsonbay-obmc power-control[198]: Host0: Moving to "On" state
Jul 24 10:36:42 hudsonbay-obmc power-control[198]: POH timer started
Jul 24 10:36:42 hudsonbay-obmc power-control[198]: Host system DC power is on
Jul 24 10:38:16 hudsonbay-obmc power-control[198]: powerStateOn: POST Complete assert event received
Jul 24 10:38:16 hudsonbay-obmc power-control[198]: No action taken.
Jul 24 10:38:34 hudsonbay-obmc power-control[198]: PowerControl: power button pressed
Jul 24 10:38:34 hudsonbay-obmc power-control[198]: powerStateOn: power button pressed event received
Jul 24 10:38:34 hudsonbay-obmc power-control[198]: Host0: Moving to "Graceful Transition to Off" state
Jul 24 10:38:34 hudsonbay-obmc power-control[198]: Graceful power-off timer started
Jul 24 10:43:34 hudsonbay-obmc power-control[198]: Graceful power-off timer completed
Jul 24 10:43:34 hudsonbay-obmc power-control[198]: powerStateGracefulTransitionToOff: graceful power-off timer expired event received
Jul 24 10:43:34 hudsonbay-obmc power-control[198]: Host0: Moving to "On" state
=====

Thanks.

Regards,
Chris Chen

________________________________
寄件者: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表 Bills, Jason M <jason.m.bills@linux.intel.com>
寄件日期: 2021年7月24日 上午 04:36
收件者: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: Re: [x86-power-control]: press the power button for a long time that can't force turn off system power



On 7/23/2021 4:28 AM, Chris Chen (TPI) wrote:
> Hi all,
>
> I am working on an ast2600 with Intel CPU.
> The system power currently is able to turn on during Phosphor OpenBMC
> boot up after I completed works following:
>
>  1. enable ACPI in u-boot
>  2. set GPIOP0 ~ P3 pass-through in u-boot
>  3. porting ESPI driver from AST SDK v6.01 to linux-aspeed repository
>  4. add "&gpio0" with gpio-line-names which has POWER_BUTTON, POWER_OUT,
>     SIO_S3, SIO_S5, etc. defintion in the dts, I think the
>     "x86-power-control" repository required these.
>  5. append "x86-power-control" and "intel-ipmi-oem" repositories to image
>
> However, I always only got the following logs when I pressed the power
> button for a long time (> 4s).
> =====
> power-control[263]: PowerControl: power button pressed
> power-control[263]: powerStateOn: power button pressed event received
> power-control[263]: Host0: Moving to "Graceful Transition to Off" state
> power-control[263]: Graceful power-off timer started
> =====
>
> It doesn't occur "SIO_ONCONTROL value changed: 1 -> SIO power good
> de-assert event received", etc. operations and then to turn off the power.
>
> Can anyone do me a favor to give me some clues for what I was wrong?
Hi Chris,

Holding the power button should force a hardware shutdown.  The BMC only
monitors this flow and doesn't participate.

Did your system shut down correctly and you just not see the logs in
BMC?  Or, did the system stay on?

Thanks,
-Jason
>
>
> Thank you in advance for your help.
>
> Regards,
> Chris Chen
>
> Legal Disclaimer :
> The information contained in this message may be privileged and
> confidential.
> It is intended to be read only by the individual or entity to whom it is
> addressed
> or by their designee. If the reader of this message is not the intended
> recipient,
> you are on notice that any distribution of this message, in any form,
> is strictly prohibited. If you have received this message in error,
> please immediately notify the sender and delete or destroy any copy of
> this message!

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

Re: 回覆: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Bills, Jason M]

On 7/23/2021 9:04 PM, Chris Chen (TPI) wrote:
> Hi Jason,
> 
> Thanks for your prompt reply.
> 
> The system stays on, because I can hear the fan in PSU is still running 
> and CPU heatsink is hot, besides, the log would show "Graceful power-off 
> timer completed" and "Host0: Moving to "On" state" after 5 minutes. Here 
> are all logs of the power-control for your reference. Hope this can 
> provide more details.
The BMC depends on PS_PWROK de-asserting to know that the system has 
shut down.  If the Graceful power-off timer is expiring, it means that 
the BMC didn't see PS_PWROK de-assert.

Holding the power button should cause the power button override forced 
shutdown in hardware.  It sounds like this isn't happening correctly on 
your system.  I'd suggest reaching out to your Intel representative to 
get help investigating what is happening in the hardware to prevent the 
power button override from fully shutting down the system.

> 
> =====
> root@hudsonbay-obmc:~# journalctl | grep -e "power-control" -e "power 
> control" -e "Power Control"
> Jul 24 10:36:06 hudsonbay-obmc systemd[1]: Starting Intel Power Control...
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: Start Chassis power 
> control service...
> Jul 24 10:36:09 hudsonbay-obmc systemd[1]: Started Intel Power Control.
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: NMI_OUT set to 0
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: POWER_OUT set to 1
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: RESET_OUT set to 1
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: NMI Source Property 
> Monitor
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: Initializing power state.
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: Host0: Moving to "On" 
> state
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: POH timer started
> Jul 24 10:36:38 hudsonbay-obmc power-control[198]: powerStateOn: POST 
> Complete assert event received
> Jul 24 10:36:38 hudsonbay-obmc power-control[198]: No action taken.
> Jul 24 10:36:41 hudsonbay-obmc power-control[198]: powerStateOn: POST 
> Complete de-assert event received
> Jul 24 10:36:41 hudsonbay-obmc power-control[198]: Host0: Moving to 
> "Check for Warm Reset" state
> Jul 24 10:36:41 hudsonbay-obmc power-control[198]: Warm reset check 
> timer started
> Jul 24 10:36:41 hudsonbay-obmc power-control[198]: RestartCause set to 
> xyz.openbmc_project.State.Host.RestartCause.SoftReset
> Jul 24 10:36:41 hudsonbay-obmc power-control[198]: Host system DC power 
> is off
> Jul 24 10:36:41 hudsonbay-obmc power-control[198]: POH timer canceled
> Jul 24 10:36:41 hudsonbay-obmc power-control[198]: failed to reset 
> ACBoot property
> Jul 24 10:36:42 hudsonbay-obmc power-control[198]: Warm reset check 
> timer completed
> Jul 24 10:36:42 hudsonbay-obmc power-control[198]: 
> powerStateCheckForWarmReset: warm reset detected event received
> Jul 24 10:36:42 hudsonbay-obmc power-control[198]: Host0: Moving to "On" 
> state
> Jul 24 10:36:42 hudsonbay-obmc power-control[198]: POH timer started
> Jul 24 10:36:42 hudsonbay-obmc power-control[198]: Host system DC power 
> is on
> Jul 24 10:38:16 hudsonbay-obmc power-control[198]: powerStateOn: POST 
> Complete assert event received
> Jul 24 10:38:16 hudsonbay-obmc power-control[198]: No action taken.
> Jul 24 10:38:34 hudsonbay-obmc power-control[198]: PowerControl: power 
> button pressed
> Jul 24 10:38:34 hudsonbay-obmc power-control[198]: powerStateOn: power 
> button pressed event received
> Jul 24 10:38:34 hudsonbay-obmc power-control[198]: Host0: Moving to 
> "Graceful Transition to Off" state
> Jul 24 10:38:34 hudsonbay-obmc power-control[198]: Graceful power-off 
> timer started
> Jul 24 10:43:34 hudsonbay-obmc power-control[198]: Graceful power-off 
> timer completed
> Jul 24 10:43:34 hudsonbay-obmc power-control[198]: 
> powerStateGracefulTransitionToOff: graceful power-off timer expired 
> event received
> Jul 24 10:43:34 hudsonbay-obmc power-control[198]: Host0: Moving to "On" 
> state
> =====
> 
> Thanks.
> 
> Regards,
> Chris Chen
> 
> ------------------------------------------------------------------------
> *寄件者:* openbmc <openbmc- 
> bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表 Bills, Jason M 
> <jason.m.bills@linux.intel.com>
> *寄件日期:* 2021年7月24日 上午 04:36
> *收件者:* openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
> *主旨:* Re: [x86-power-control]: press the power button for a long time 
> that can't force turn off system power
> 
> 
> On 7/23/2021 4:28 AM, Chris Chen (TPI) wrote:
>> Hi all,
>> 
>> I am working on an ast2600 with Intel CPU.
>> The system power currently is able to turn on during Phosphor OpenBMC 
>> boot up after I completed works following:
>> 
>>  1. enable ACPI in u-boot
>>  2. set GPIOP0 ~ P3 pass-through in u-boot
>>  3. porting ESPI driver from AST SDK v6.01 to linux-aspeed repository
>>  4. add "&gpio0" with gpio-line-names which has POWER_BUTTON, POWER_OUT,
>>     SIO_S3, SIO_S5, etc. defintion in the dts, I think the
>>     "x86-power-control" repository required these.
>>  5. append "x86-power-control" and "intel-ipmi-oem" repositories to image
>> 
>> However, I always only got the following logs when I pressed the power 
>> button for a long time (> 4s).
>> =====
>> power-control[263]: PowerControl: power button pressed
>> power-control[263]: powerStateOn: power button pressed event received
>> power-control[263]: Host0: Moving to "Graceful Transition to Off" state
>> power-control[263]: Graceful power-off timer started
>> =====
>> 
>> It doesn't occur "SIO_ONCONTROL value changed: 1 -> SIO power good 
>> de-assert event received", etc. operations and then to turn off the power.
>> 
>> Can anyone do me a favor to give me some clues for what I was wrong?
> Hi Chris,
> 
> Holding the power button should force a hardware shutdown.  The BMC only
> monitors this flow and doesn't participate.
> 
> Did your system shut down correctly and you just not see the logs in
> BMC?  Or, did the system stay on?
> 
> Thanks,
> -Jason
>> 
>> 
>> Thank you in advance for your help.
>> 
>> Regards,
>> Chris Chen
>> 
>> Legal Disclaimer :
>> The information contained in this message may be privileged and 
>> confidential.
>> It is intended to be read only by the individual or entity to whom it is 
>> addressed
>> or by their designee. If the reader of this message is not the intended 
>> recipient,
>> you are on notice that any distribution of this message, in any form,
>> is strictly prohibited. If you have received this message in error,
>> please immediately notify the sender and delete or destroy any copy of 
>> this message!

RE: 回覆: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Chris Chen (TPI)]

Hi Jason and others,

I think I figured out the problem is the GPIOP0 and GPIOP1 passthrough was not set after system booting up. However, as I mentioned when rising the question, I have already set GPIOP0 and P1 passthrough in u-boot, it for now looks like was been turned off during Kernel or OpenBMC application running up. Can you please give me a clue why the GPIO passthrough would be turned off or where should I need to add passthrough setting again?

Thanks.

Regards,
Chris Chen

-----Original Message-----
From: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> On Behalf Of Bills, Jason M
Sent: Tuesday, July 27, 2021 12:47 AM
To: openbmc@lists.ozlabs.org
Subject: Re: 回覆: [x86-power-control]: press the power button for a long time that can't force turn off system power



On 7/23/2021 9:04 PM, Chris Chen (TPI) wrote:
> Hi Jason,
> 
> Thanks for your prompt reply.
> 
> The system stays on, because I can hear the fan in PSU is still 
> running and CPU heatsink is hot, besides, the log would show "Graceful 
> power-off timer completed" and "Host0: Moving to "On" state" after 5 
> minutes. Here are all logs of the power-control for your reference. 
> Hope this can provide more details.
The BMC depends on PS_PWROK de-asserting to know that the system has shut down.  If the Graceful power-off timer is expiring, it means that the BMC didn't see PS_PWROK de-assert.

Holding the power button should cause the power button override forced shutdown in hardware.  It sounds like this isn't happening correctly on your system.  I'd suggest reaching out to your Intel representative to get help investigating what is happening in the hardware to prevent the power button override from fully shutting down the system.

> 
> =====
> root@hudsonbay-obmc:~# journalctl | grep -e "power-control" -e "power 
> control" -e "Power Control"
> Jul 24 10:36:06 hudsonbay-obmc systemd[1]: Starting Intel Power Control...
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: Start Chassis power 
> control service...
> Jul 24 10:36:09 hudsonbay-obmc systemd[1]: Started Intel Power Control.
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: NMI_OUT set to 0 
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: POWER_OUT set to 1 
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: RESET_OUT set to 1 
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: NMI Source Property 
> Monitor Jul 24 10:36:09 hudsonbay-obmc power-control[198]: 
> Initializing power state.
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: Host0: Moving to "On" 
> state
> Jul 24 10:36:09 hudsonbay-obmc power-control[198]: POH timer started 
> Jul 24 10:36:38 hudsonbay-obmc power-control[198]: powerStateOn: POST 
> Complete assert event received Jul 24 10:36:38 hudsonbay-obmc 
> power-control[198]: No action taken.
> Jul 24 10:36:41 hudsonbay-obmc power-control[198]: powerStateOn: POST 
> Complete de-assert event received Jul 24 10:36:41 hudsonbay-obmc 
> power-control[198]: Host0: Moving to "Check for Warm Reset" state Jul 
> 24 10:36:41 hudsonbay-obmc power-control[198]: Warm reset check timer 
> started Jul 24 10:36:41 hudsonbay-obmc power-control[198]: 
> RestartCause set to 
> xyz.openbmc_project.State.Host.RestartCause.SoftReset
> Jul 24 10:36:41 hudsonbay-obmc power-control[198]: Host system DC 
> power is off Jul 24 10:36:41 hudsonbay-obmc power-control[198]: POH 
> timer canceled Jul 24 10:36:41 hudsonbay-obmc power-control[198]: 
> failed to reset ACBoot property Jul 24 10:36:42 hudsonbay-obmc 
> power-control[198]: Warm reset check timer completed Jul 24 10:36:42 
> hudsonbay-obmc power-control[198]:
> powerStateCheckForWarmReset: warm reset detected event received Jul 24 
> 10:36:42 hudsonbay-obmc power-control[198]: Host0: Moving to "On"
> state
> Jul 24 10:36:42 hudsonbay-obmc power-control[198]: POH timer started 
> Jul 24 10:36:42 hudsonbay-obmc power-control[198]: Host system DC 
> power is on Jul 24 10:38:16 hudsonbay-obmc power-control[198]: 
> powerStateOn: POST Complete assert event received Jul 24 10:38:16 
> hudsonbay-obmc power-control[198]: No action taken.
> Jul 24 10:38:34 hudsonbay-obmc power-control[198]: PowerControl: power 
> button pressed Jul 24 10:38:34 hudsonbay-obmc power-control[198]: 
> powerStateOn: power button pressed event received Jul 24 10:38:34 
> hudsonbay-obmc power-control[198]: Host0: Moving to "Graceful 
> Transition to Off" state Jul 24 10:38:34 hudsonbay-obmc 
> power-control[198]: Graceful power-off timer started Jul 24 10:43:34 
> hudsonbay-obmc power-control[198]: Graceful power-off timer completed 
> Jul 24 10:43:34 hudsonbay-obmc power-control[198]:
> powerStateGracefulTransitionToOff: graceful power-off timer expired 
> event received Jul 24 10:43:34 hudsonbay-obmc power-control[198]: 
> Host0: Moving to "On"
> state
> =====
> 
> Thanks.
> 
> Regards,
> Chris Chen
> 
> ----------------------------------------------------------------------
> --
> *寄件者:* openbmc <openbmc-
> bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表 Bills, Jason M
> <jason.m.bills@linux.intel.com>
> *寄件日期:* 2021年7月24日 上午 04:36
> *收件者:* openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
> *主旨:* Re: [x86-power-control]: press the power button for a long time 
> that can't force turn off system power
> 
> 
> On 7/23/2021 4:28 AM, Chris Chen (TPI) wrote:
>> Hi all,
>> 
>> I am working on an ast2600 with Intel CPU.
>> The system power currently is able to turn on during Phosphor OpenBMC 
>> boot up after I completed works following:
>> 
>>  1. enable ACPI in u-boot
>>  2. set GPIOP0 ~ P3 pass-through in u-boot
>>  3. porting ESPI driver from AST SDK v6.01 to linux-aspeed repository
>>  4. add "&gpio0" with gpio-line-names which has POWER_BUTTON, 
>>POWER_OUT,
>>     SIO_S3, SIO_S5, etc. defintion in the dts, I think the
>>     "x86-power-control" repository required these.
>>  5. append "x86-power-control" and "intel-ipmi-oem" repositories to 
>>image
>> 
>> However, I always only got the following logs when I pressed the 
>> power button for a long time (> 4s).
>> =====
>> power-control[263]: PowerControl: power button pressed
>> power-control[263]: powerStateOn: power button pressed event received
>> power-control[263]: Host0: Moving to "Graceful Transition to Off" 
>> state
>> power-control[263]: Graceful power-off timer started =====
>> 
>> It doesn't occur "SIO_ONCONTROL value changed: 1 -> SIO power good 
>> de-assert event received", etc. operations and then to turn off the power.
>> 
>> Can anyone do me a favor to give me some clues for what I was wrong?
> Hi Chris,
> 
> Holding the power button should force a hardware shutdown.  The BMC 
> only monitors this flow and doesn't participate.
> 
> Did your system shut down correctly and you just not see the logs in 
> BMC?  Or, did the system stay on?
> 
> Thanks,
> -Jason
>> 
>> 
>> Thank you in advance for your help.
>> 
>> Regards,
>> Chris Chen
>> 
>> Legal Disclaimer :
>> The information contained in this message may be privileged and 
>> confidential.
>> It is intended to be read only by the individual or entity to whom it 
>> is addressed or by their designee. If the reader of this message is 
>> not the intended recipient, you are on notice that any distribution 
>> of this message, in any form, is strictly prohibited. If you have 
>> received this message in error, please immediately notify the sender 
>> and delete or destroy any copy of this message!

Re: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Andrew Jeffery]

Hi Chris,

On Mon, 16 Aug 2021, at 13:22, Chris Chen (TPI) wrote:
> Hi Jason and others,
> 
> I think I figured out the problem is the GPIOP0 and GPIOP1 passthrough 
> was not set after system booting up. However, as I mentioned when 
> rising the question, I have already set GPIOP0 and P1 passthrough in 
> u-boot, it for now looks like was been turned off during Kernel or 
> OpenBMC application running up. Can you please give me a clue why the 
> GPIO passthrough would be turned off or where should I need to add 
> passthrough setting again?
> 

If the kernel is disabling it you might be able to find the cause with 
CONFIG_DEBUG_PINCTRL=y and the pinctrl attributes in debugfs. Having 
said that, the upstream kernel hasn't been taught about SCU510[28] on 
the 2600, so if it is touching it then it's doing so via out-of-tree 
patches.

Andrew

回覆: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Chris Chen (TPI)]

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

Hi Andrew,

Thanks for your hint (CONFIG_DEBUG_PINCTRL=y) that let me see where the passthrough setting was disabled.
======
[   11.631044] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: request pin 120 (AB22) for 1e780000.gpio:120
[   11.631064] Muxing pin 120 for GPIO
[   11.631071] Disabling signal PWM8 for PWM8
[   11.631087] Want SCU41C[0x01000000]=0x1, got 0x0 from 0x000000C0
[   11.631094] Disabling signal THRUIN0 for THRU0
[   11.631102] Want SCU4BC[0x01000000]=0x1, got 0x1 from 0x0F000000
[   11.631118] Want SCU4BC[0x01000000]=0x0, got 0x0 from 0x0E000000
[   11.631124] Enabling signal GPIOP0 for GPIOP0
======

But something strange is the logs seems from "x86-power-control" package because it would not appear after I commented out partial code as below in the package.
Could you or others tell me why, please? I mean did I miss any configurations or code changes or anything when using the "x86-power-control" package?

#if 0 //Added by Chris for testing
    // Request POWER_BUTTON GPIO events
    if (!powerButtonName.empty())
    {
        if (!requestGPIOEvents(powerButtonName, powerButtonHandler,
                               powerButtonLine, powerButtonEvent))
        {
            return -1;
        }
    }
    else
    {
        phosphor::logging::log<phosphor::logging::level::ERR>(
            "powerButton name should be configured from json config file");
        return -1;
    }
#endif //Added by Chris for testing

Another, last time I forgot to say that I have tried to use "devmem 0x1e6e24BC 32 0x0F000000" to set passthrough back manually and the power button works fine. This is why I think the passthrough was gone after the system booting up.

Regards,
Chris Chen


________________________________
寄件者: Andrew Jeffery <andrew@aj.id.au>
寄件日期: 2021年8月16日 下午 02:30
收件者: Chris Chen (TPI) <Chris.Chen3@flex.com>; Bills, Jason M <jason.m.bills@linux.intel.com>; openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: Re: [x86-power-control]: press the power button for a long time that can't force turn off system power

Hi Chris,

On Mon, 16 Aug 2021, at 13:22, Chris Chen (TPI) wrote:
> Hi Jason and others,
>
> I think I figured out the problem is the GPIOP0 and GPIOP1 passthrough
> was not set after system booting up. However, as I mentioned when
> rising the question, I have already set GPIOP0 and P1 passthrough in
> u-boot, it for now looks like was been turned off during Kernel or
> OpenBMC application running up. Can you please give me a clue why the
> GPIO passthrough would be turned off or where should I need to add
> passthrough setting again?
>

If the kernel is disabling it you might be able to find the cause with
CONFIG_DEBUG_PINCTRL=y and the pinctrl attributes in debugfs. Having
said that, the upstream kernel hasn't been taught about SCU510[28] on
the 2600, so if it is touching it then it's doing so via out-of-tree
patches.

Andrew

Legal Disclaimer :
The information contained in this message may be privileged and confidential. 
It is intended to be read only by the individual or entity to whom it is addressed 
or by their designee. If the reader of this message is not the intended recipient, 
you are on notice that any distribution of this message, in any form, 
is strictly prohibited. If you have received this message in error, 
please immediately notify the sender and delete or destroy any copy of this message!

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

Re: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Andrew Jeffery]

On Mon, 16 Aug 2021, at 20:15, Chris Chen (TPI) wrote:
>  Hi Andrew,
> 
> Thanks for your hint (CONFIG_DEBUG_PINCTRL=y) that let me see where the 
> passthrough setting was disabled.
> ======
> [   11.631044] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: request pin 
> 120 (AB22) for 1e780000.gpio:120 
> [   11.631064] Muxing pin 120 for GPIO
> [   11.631071] Disabling signal PWM8 for PWM8
> [   11.631087] Want SCU41C[0x01000000]=0x1, got 0x0 from 0x000000C0
> [   11.631094] Disabling signal THRUIN0 for THRU0
> [   11.631102] Want SCU4BC[0x01000000]=0x1, got 0x1 from 0x0F000000
> [   11.631118] Want SCU4BC[0x01000000]=0x0, got 0x0 from 0x0E000000
> [   11.631124] Enabling signal GPIOP0 for GPIOP0
> ======
> 
> But something strange is the logs seems from "x86-power-control" 
> package because it would not appear after I commented out partial code 
> as below in the package.
> Could you or others tell me why, please? I mean did I miss any 
> configurations or code changes or anything when using the 
> "x86-power-control" package?
> 
> #if 0 //Added by Chris for testing 
>     // Request POWER_BUTTON GPIO events
>     if (!powerButtonName.empty())
>     {
>         if (!requestGPIOEvents(powerButtonName, powerButtonHandler,
>                                powerButtonLine, powerButtonEvent))
>         {
>             return -1;
>         }
>     }
>     else
>     {
>         phosphor::logging::log<phosphor::logging::level::ERR>(
>             "powerButton name should be configured from json config file");
>         return -1;
>     }
> #endif //Added by Chris for testing

Requesting the pin as GPIO removes the pass-through mux configuration.

If you want the pass-through behaviour when you obtain the pin as a 
GPIO then you need to also do that in software by requesting the GPIOP1 
pin and setting it to the state of the GPIOP0 pin when GPIOP0 changes.

This is a limitation of the kernel, though I'm open to ideas on how to 
avoid it.

Separately, I encourage you to encourage the author of the kernel patch 
that added pass-through support to send their changes upstream.

> 
> Another, last time I forgot to say that I have tried to use "devmem 
> 0x1e6e24BC 32 0x0F000000" to set passthrough back manually and the 
> power button works fine. This is why I think the passthrough was gone 
> after the system booting up.

I think it's possible to sense the input pin state even in the 
pass-through configuration, but at the point where you request the GPIO 
via pinctrl we've lost the intent of the request and the mux 
configuration mustn't assume any particular mode of use. As such it 
disables the pass-through mode and puts GPIOP0 in regular GPIO mode.

> Legal Disclaimer :
> The information contained in this message may be privileged and 
> confidential. 
> It is intended to be read only by the individual or entity to whom it 
> is addressed 
> or by their designee. If the reader of this message is not the intended 
> recipient, 
> you are on notice that any distribution of this message, in any form, 
> is strictly prohibited. If you have received this message in error, 
> please immediately notify the sender and delete or destroy any copy of 
> this message!

On a separate note, please don't include these disclaimers on mail sent 
to the mailing list.

Andrew

RE: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Chris Chen (TPI)]

Hi Andrew,

That means I'm able to choose one of following 2 options to achieve pass-through behavior when I using x86-power-control package, is my understanding correct?

1. Add code to re-enable GPIOP0 and GPIOP1 into a pass-through function after they are requested as a GPIO function in the x86-power-control package. (Or maybe to create a script with "devmem > 0x1e6e24BC 32 0x0F000000" command that will be run automatically after system up to change register directly.)

2. Modify pinctrl in Kernel that will not disable GPIOP0 and GPIOP1's pass-through function if they already are configured as a pass-through when they are requesting as a GPIO function.


Regards,
Chris Chen

-----Original Message-----
From: Andrew Jeffery <andrew@aj.id.au> 
Sent: Tuesday, August 17, 2021 9:58 AM
To: Chris Chen (TPI) <Chris.Chen3@flex.com>; Bills, Jason M <jason.m.bills@linux.intel.com>; openbmc@lists.ozlabs.org
Subject: Re: [x86-power-control]: press the power button for a long time that can't force turn off system power

On Mon, 16 Aug 2021, at 20:15, Chris Chen (TPI) wrote:
>  Hi Andrew,
> 
> Thanks for your hint (CONFIG_DEBUG_PINCTRL=y) that let me see where 
> the passthrough setting was disabled.
> ======
> [   11.631044] aspeed-g6-pinctrl 1e6e2000.syscon:pinctrl: request pin 
> 120 (AB22) for 1e780000.gpio:120 
> [   11.631064] Muxing pin 120 for GPIO
> [   11.631071] Disabling signal PWM8 for PWM8
> [   11.631087] Want SCU41C[0x01000000]=0x1, got 0x0 from 0x000000C0
> [   11.631094] Disabling signal THRUIN0 for THRU0
> [   11.631102] Want SCU4BC[0x01000000]=0x1, got 0x1 from 0x0F000000
> [   11.631118] Want SCU4BC[0x01000000]=0x0, got 0x0 from 0x0E000000
> [   11.631124] Enabling signal GPIOP0 for GPIOP0
> ======
> 
> But something strange is the logs seems from "x86-power-control" 
> package because it would not appear after I commented out partial code 
> as below in the package.
> Could you or others tell me why, please? I mean did I miss any 
> configurations or code changes or anything when using the 
> "x86-power-control" package?
> 
> #if 0 //Added by Chris for testing 
>     // Request POWER_BUTTON GPIO events
>     if (!powerButtonName.empty())
>     {
>         if (!requestGPIOEvents(powerButtonName, powerButtonHandler,
>                                powerButtonLine, powerButtonEvent))
>         {
>             return -1;
>         }
>     }
>     else
>     {
>         phosphor::logging::log<phosphor::logging::level::ERR>(
>             "powerButton name should be configured from json config file");
>         return -1;
>     }
> #endif //Added by Chris for testing

Requesting the pin as GPIO removes the pass-through mux configuration.

If you want the pass-through behaviour when you obtain the pin as a GPIO then you need to also do that in software by requesting the GPIOP1 pin and setting it to the state of the GPIOP0 pin when GPIOP0 changes.

This is a limitation of the kernel, though I'm open to ideas on how to avoid it.

Separately, I encourage you to encourage the author of the kernel patch that added pass-through support to send their changes upstream.

> 
> Another, last time I forgot to say that I have tried to use "devmem 
> 0x1e6e24BC 32 0x0F000000" to set passthrough back manually and the 
> power button works fine. This is why I think the passthrough was gone 
> after the system booting up.

I think it's possible to sense the input pin state even in the pass-through configuration, but at the point where you request the GPIO via pinctrl we've lost the intent of the request and the mux configuration mustn't assume any particular mode of use. As such it disables the pass-through mode and puts GPIOP0 in regular GPIO mode.

> Legal Disclaimer :
> The information contained in this message may be privileged and 
> confidential.
> It is intended to be read only by the individual or entity to whom it 
> is addressed or by their designee. If the reader of this message is 
> not the intended recipient, you are on notice that any distribution of 
> this message, in any form, is strictly prohibited. If you have 
> received this message in error, please immediately notify the sender 
> and delete or destroy any copy of this message!

On a separate note, please don't include these disclaimers on mail sent to the mailing list.

Andrew

Re: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Andrew Jeffery]

Hi Chris,

On Tue, 17 Aug 2021, at 20:47, Chris Chen (TPI) wrote:
> Hi Andrew,
> 
> That means I'm able to choose one of following 2 options to achieve 
> pass-through behavior when I using x86-power-control package, is my 
> understanding correct?
> 
> 1. Add code to re-enable GPIOP0 and GPIOP1 into a pass-through function 
> after they are requested as a GPIO function in the x86-power-control 
> package. (Or maybe to create a script with "devmem > 0x1e6e24BC 32 
> 0x0F000000" command that will be run automatically after system up to 
> change register directly.)

This is a hack and should be a last resort. Even then I'd avoid it.

Certainly you should avoid shipping with /dev/mem enabled.

> 
> 2. Modify pinctrl in Kernel that will not disable GPIOP0 and GPIOP1's 
> pass-through function if they already are configured as a pass-through 
> when they are requesting as a GPIO function.

Perhaps, though maybe you should follow up on whether you can drive 
GPIOP1 when it's in pass-through mode. My recollection is you cannot, 
at least for the AST2500 and earlier, in which case both P0 and P1 are 
effectively inputs for the purpose of the GPIO controller despite P1 
being a physical output. This behaviour is probably more confusing than 
it is helpful.

There's also option 3 which is to emulate the pass-through in software, 
as I outlined in my previous email.

Hope that helps,

Andrew

Re: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Bills, Jason M]

On 8/17/2021 5:30 AM, Andrew Jeffery wrote:
> Hi Chris,
> 
> On Tue, 17 Aug 2021, at 20:47, Chris Chen (TPI) wrote:
>> Hi Andrew,
>>
>> That means I'm able to choose one of following 2 options to achieve
>> pass-through behavior when I using x86-power-control package, is my
>> understanding correct?
>>
>> 1. Add code to re-enable GPIOP0 and GPIOP1 into a pass-through function
>> after they are requested as a GPIO function in the x86-power-control
>> package. (Or maybe to create a script with "devmem > 0x1e6e24BC 32
>> 0x0F000000" command that will be run automatically after system up to
>> change register directly.)
> 
> This is a hack and should be a last resort. Even then I'd avoid it.
> 
> Certainly you should avoid shipping with /dev/mem enabled.
> 
>>
>> 2. Modify pinctrl in Kernel that will not disable GPIOP0 and GPIOP1's
>> pass-through function if they already are configured as a pass-through
>> when they are requesting as a GPIO function.
> 
> Perhaps, though maybe you should follow up on whether you can drive
> GPIOP1 when it's in pass-through mode. My recollection is you cannot,
> at least for the AST2500 and earlier, in which case both P0 and P1 are
> effectively inputs for the purpose of the GPIO controller despite P1
> being a physical output. This behaviour is probably more confusing than
> it is helpful.
> 
> There's also option 3 which is to emulate the pass-through in software,
> as I outlined in my previous email.
This is some of the configuration that I have on my system where the 
pass-through is working correctly in x86-power-control:

I have one kernel patch that selects the "pass-through" pin 
configuration on startup: 
https://github.com/Intel-BMC/linux/commit/8fe1ac31c13a0e8443c665394112ba407c90ae70.

In x86-power-control, I have the POWER_BUTTON GPIO mapped to GPIOP2, and 
I'm able to claim and monitor that GPIO without affecting the 
pass-through status.

I have POWER_OUT mapped to GPIOP3 which cannot be held in 
x86-power-control as it disables the pass-through when claimed.  So, it 
is always released after the power-control action is completed.

Thanks,
-Jason

> 
> Hope that helps,
> 
> Andrew
> 

回覆: [x86-power-control]: press the power button for a long time that can't force turn off system power

[Chris Chen (TPI)]

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

Hi Andrew,

Understood. Thanks for your explanation.


Hi Jason,

I will take it a shot. Thanks for your sharing.


Regards,
Chris Chen
________________________________
寄件者: openbmc <openbmc-bounces+chris.chen3=flex.com@lists.ozlabs.org> 代表 Bills, Jason M <jason.m.bills@linux.intel.com>
寄件日期: 2021年8月18日 上午 03:04
收件者: openbmc@lists.ozlabs.org <openbmc@lists.ozlabs.org>
主旨: Re: [x86-power-control]: press the power button for a long time that can't force turn off system power



On 8/17/2021 5:30 AM, Andrew Jeffery wrote:
> Hi Chris,
>
> On Tue, 17 Aug 2021, at 20:47, Chris Chen (TPI) wrote:
>> Hi Andrew,
>>
>> That means I'm able to choose one of following 2 options to achieve
>> pass-through behavior when I using x86-power-control package, is my
>> understanding correct?
>>
>> 1. Add code to re-enable GPIOP0 and GPIOP1 into a pass-through function
>> after they are requested as a GPIO function in the x86-power-control
>> package. (Or maybe to create a script with "devmem > 0x1e6e24BC 32
>> 0x0F000000" command that will be run automatically after system up to
>> change register directly.)
>
> This is a hack and should be a last resort. Even then I'd avoid it.
>
> Certainly you should avoid shipping with /dev/mem enabled.
>
>>
>> 2. Modify pinctrl in Kernel that will not disable GPIOP0 and GPIOP1's
>> pass-through function if they already are configured as a pass-through
>> when they are requesting as a GPIO function.
>
> Perhaps, though maybe you should follow up on whether you can drive
> GPIOP1 when it's in pass-through mode. My recollection is you cannot,
> at least for the AST2500 and earlier, in which case both P0 and P1 are
> effectively inputs for the purpose of the GPIO controller despite P1
> being a physical output. This behaviour is probably more confusing than
> it is helpful.
>
> There's also option 3 which is to emulate the pass-through in software,
> as I outlined in my previous email.
This is some of the configuration that I have on my system where the
pass-through is working correctly in x86-power-control:

I have one kernel patch that selects the "pass-through" pin
configuration on startup:
https://urldefense.com/v3/__https://github.com/Intel-BMC/linux/commit/8fe1ac31c13a0e8443c665394112ba407c90ae70__;!!HSntlCg!Ep_IWFI6dHqTAFsDwLYoJ0JYl3PjsE2hcEJQFIkNt1nDgHL9PvJEAWMmDWtE4az1$ .

In x86-power-control, I have the POWER_BUTTON GPIO mapped to GPIOP2, and
I'm able to claim and monitor that GPIO without affecting the
pass-through status.

I have POWER_OUT mapped to GPIOP3 which cannot be held in
x86-power-control as it disables the pass-through when claimed.  So, it
is always released after the power-control action is completed.

Thanks,
-Jason

>
> Hope that helps,
>
> Andrew
>

Legal Disclaimer :
The information contained in this message may be privileged and confidential. 
It is intended to be read only by the individual or entity to whom it is addressed 
or by their designee. If the reader of this message is not the intended recipient, 
you are on notice that any distribution of this message, in any form, 
is strictly prohibited. If you have received this message in error, 
please immediately notify the sender and delete or destroy any copy of this message!

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