- TF-A - lists.trustedfirmware.org

[query] sbsa level 3 spec: non secure watchdog WS1 handling at EL3

by Sandeep Tripathy

Hi, Based on sbsa spec for level-3 firmware specification watchdog signals NS WS1 and S WS0 to be handled at EL3 firmware. I have some query on how TF-A plans to implement this. Ref: Excerpt DEN0029D_SBSA_6.0 https://developer.arm.com/documentation/den0029/d/?lang=en 3.2.3 Watchdogs The required behavior of watchdog signal 1 of the Non-secure watchdog is modified in level 3– firmware and is required to be routed as an SPI to the GIC. It is expected that this SPI be configured as an EL3 interrupt, directly targeting a single PE. A system compatible with level 3- firmware must implement a second watchdog, and is referred to as the Secure watchdog. It must have both its register frames mapped in the Secure memory address space and must not be aliased to the Non-secure address space. Watchdog Signal 0 of the Secure watchdog must be routed as an SPI to the GIC and it is expected this will be configured as an EL3 interrupt, directly targeting a single PE. Q1- What happens if core is stuck and interrupts are not taken. Non-secure watchdog will expire and ultimately results in a WS1 which is also not taken as the core is not responding. If WS1 were to another subsystem (eg: SCP) then it would take action. In current scheme is it the secure sbsa wdg expected to detect such hang ? Q2- How to handle sbsa watchdog interrupt at EL3. Please suggest if I should make a patch in following approach to start with. Or it has to be registered as a RAS priority exception. diff --git a/drivers/arm/sbsa/sbsa.c b/drivers/arm/sbsa/sbsa.c index 79c6f26..9683ef8 100644 --- a/drivers/arm/sbsa/sbsa.c +++ b/drivers/arm/sbsa/sbsa.c @@ -40,3 +40,26 @@ + +#define weak plat_sbsa_nt_wdog_ws1_handle +#define weak plat_sbsa_t_wdog_ws0_handle +void sbsa_wdog_handler(int id) +{ + if (id == SBSA_NT_WDG_WS1_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_nt_wdog_ws1_handle(); + } else if (id == SBSA_T_WDG_WS0_INT) { + /* PUBLISH_EVENT */ + plat_sbsa_t_wdog_ws0_handle(); + } + /* EOI and reset , log what else */ + psci_systrem_reset2(); +} + +void sbsa_wdog_hander_init(void) +{ +#if EXCEPTION_HANDLING_FRAMEWORK + ehf_register_priority_handler(SBSA_WDG_PRI, sbsa_wdog_handler); +#endif +} Thanks Sandeep

4 years, 7 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 2 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 2 of 2 defect(s) ** CID 361485: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 54 in wait_for_done() ________________________________________________________________________________________________________ *** CID 361485: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 54 in wait_for_done() 48 49 static int wait_for_done(uint16_t apid) 50 { 51 unsigned int timeout = 100; 52 53 while (timeout-- != 0U) { >>> CID 361485: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "apid" with type "uint16_t" (16 bits, unsigned) is promoted in "207618056 + 65536 * apid" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "207618056 + 65536 * apid" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 54 uint32_t status = mmio_read_32(REG_ARB_STATUS(apid)); 55 if ((status & ARB_STATUS_DONE) != 0U) { 56 if ((status & ARB_STATUS_FAILURE) != 0U || 57 (status & ARB_STATUS_DENIED) != 0U || 58 (status & ARB_STATUS_DROPPED) != 0U) { 59 return status & 0xff; ** CID 361484: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 72 in arb_command() ________________________________________________________________________________________________________ *** CID 361484: Integer handling issues (SIGN_EXTENSION) /plat/qti/common/src/spmi_arb.c: 72 in arb_command() 66 return ARB_FAKE_STATUS_TIMEOUT; 67 } 68 69 static void arb_command(uint16_t apid, uint8_t opcode, uint32_t addr, 70 uint8_t bytes) 71 { >>> CID 361484: Integer handling issues (SIGN_EXTENSION) >>> Suspicious implicit sign extension: "apid" with type "uint16_t" (16 bits, unsigned) is promoted in "207618048 + 65536 * apid" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "207618048 + 65536 * apid" is greater than 0x7FFFFFFF, the upper bits of the result will all be 1. 72 mmio_write_32(REG_ARB_CMD(apid), (uint32_t)opcode << 27 | 73 (addr & 0xff) << 4 | (bytes - 1)); 74 } 75 76 int spmi_arb_read8(uint32_t addr) 77 { ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 7 months

1
0
0 0

Re: [TF-A] TF-A Gerrit access permissions currently broken.

by Joanna Farley

Things should be back to normal. Joanna From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Joanna Farley via TF-A <tf-a(a)lists.trustedfirmware.org> Reply to: Joanna Farley <Joanna.Farley(a)arm.com> Date: Wednesday, 26 August 2020 at 12:51 To: "tf-a(a)lists.trustedfirmware.org" <tf-a(a)lists.trustedfirmware.org> Subject: [TF-A] TF-A Gerrit access permissions currently broken. Just to inform project contributors that people may find their gerrit access rights may be broken at this time. I have raised a support request with the trustedfirmware.org support team. Joanna

4 years, 7 months

1
0
0 0

TF-A Gerrit access permissions currently broken.

by Joanna Farley

Just to inform project contributors that people may find their gerrit access rights may be broken at this time. I have raised a support request with the trustedfirmware.org support team. Joanna

4 years, 7 months

1
0
0 0

TF-A Tech Forum Agenda @ Thr 27th August 2020 16:00-1700 BST

by Joanna Farley

Hi All, The next TF-A Tech Forum is scheduled for Thu 27th August 2020 16:00 – 17:00 (BST). A reoccurring meeting invite has been sent out to the subscribers of this TF-A mailing list. If you don’t have this please let me know. Agenda: * TF-A Errata Process – Presented by Bipin Ravi * Bug Review Committee (BRC) & Categorization of Errata * Software Developers Errata Notice (SDEN) & Product Errata Notice (PEN) * What TF-A Implements * How TF-A Implements * Testing If TF-A contributors have anything they wish to present at any future TF-A tech forum please contact me to have that scheduled. Previous sessions, both recording and presentation material can be found on the trustedfirmware.org TF-A Technical meeting webpage: https://www.trustedfirmware.org/meetings/tf-a-technical-forum/ A scheduling tracking page is also available to help track sessions suggested and being prepared: https://developer.trustedfirmware.org/w/tf_a/tf-a-tech-forum-scheduling/ Final decisions on what will be presented will be shared a few days before the next meeting and shared on the TF-A mailing list. Thanks Joanna

4 years, 7 months

1
0
0 0

Re: [TF-A] [RFC] Api to power down all cores

by Varun Wadekar

<Cc alias> -----Original Message----- From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> Sent: Tuesday, August 25, 2020 8:59 AM To: Varun Wadekar <vwadekar(a)nvidia.com>; Soby Mathew <Soby.Mathew(a)arm.com> Subject: RE: [TF-A] [RFC] Api to power down all cores Thanks, I will use callback as param to get rid of the 'plat*'. 'void psci_stop_other_cores(void (*stop_func)(uregister_t mpidr))' Platform can call like .. psci_stop_other_cores(ipi_send_stop); I will update the patch tomorrow. This api is not invoked by psci generic functions. So I think that should suffice your concern. Anyways I will take care any other suggestions. IPI implementation is under flag 'IPI_SUPPORT'. https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5323/ Thanks Sandeep > -----Original Message----- > From: Varun Wadekar [mailto:vwadekar@nvidia.com] > Sent: Tuesday, August 25, 2020 9:11 AM > To: Soby Mathew; Sandeep Tripathy > Subject: RE: [TF-A] [RFC] Api to power down all cores > > Hi, > > In addition to the suggestions already posted, we should provide a > build flag or dynamic knob to allow platforms to disable this feature. > > -Varun > > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Soby > Mathew via TF-A > Sent: Friday, August 21, 2020 3:57 AM > To: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> > Cc: tf-a(a)lists.trustedfirmware.org > Subject: Re: [TF-A] [RFC] Api to power down all cores > > External email: Use caution opening links or attachments > > > Hi Sandeep, > Thanks for the clarification. I too think this has general utility and > since you need access to internal PSCI data to perform the > functionality , exporting a utility function from PSCI for platforms > to invoke seems the right thing to do. > The small concern I have is using the `plat_*` namespace as this is a > utility function invoked by the platform and another porting layer > beneath it seems out of place. > > I would suggest to add a parameter to stop_other_cores(), this could > be either the IPI number or a callback function to trigger the IPI. > This allows to provide the platform specific details without `plat_*` > API. > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: Sandeep Tripathy <sandeep.tripathy(a)broadcom.com> > > Sent: 21 August 2020 07:17 > > To: Soby Mathew <Soby.Mathew(a)arm.com> > > Cc: tf-a(a)lists.trustedfirmware.org > > Subject: RE: [TF-A] [RFC] Api to power down all cores > > > > Hi Soby, > > I realize using term 'PSCI API' in rfc tag is misleading like Achin > > mentioned in gerrit. > > > > Here I wanted to have a generic API to 'stop_other_cores' in > > secure world. > > The usage is platform firmware specific. > > Implementation of 'stop_other_cores' depends on a generic 'IPI' > > support > (1). > > It leverages the existing EHF. So I feel it is not adding and > > complexity or overhead in normal execution path. > > > > 'stop_other_cores' API implementation depends on some psci private > > functions to traverse the pd nodes and extract MPIDRs for target pe > > list. That was the reason to put the function within psci lib. So > > there are > two things. > > 1- Does this idea of 'stop_other_core' api qualify to be generic > > 2- Does a generic IPI layer make sense > > > > Thanks > > Sandeep > > > -----Original Message----- > > > From: Soby Mathew [mailto:Soby.Mathew@arm.com] > > > Sent: Thursday, August 20, 2020 8:54 PM > > > To: Sandeep Tripathy > > > Cc: tf-a(a)lists.trustedfirmware.org > > > Subject: RE: [TF-A] [RFC] psci: api to power down all cores > > > > > > Hi Sandeep, > > > Just to understand better, if there is a secure side > > > panic/watchdog interrupt, then the secure side is already able to > > > do such an intervention without the availability of a PSCI API to the NS side. > > > > > > In case the NS world has crashed, then PSCI_SYSTEM_RESET and > > > PSCI_SYSTEM_OFF APIs can be invoked which then does the > > > appropriate actions. From my reading, the PSCI specification > > > doesn't prevent firmware implementation of the reset and off API's > > > from doing the kind of implementation as per your proposal. > > > > I intend to do 'stop_other_cores' in platform extension of > > 'plat_system_resetx()', secure side watchdog expiry/ > > plat_panic_handler(). > > > > > > > > Best Regards > > > Soby Mathew > > > > > > > -----Original Message----- > > > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > > > Sandeep > > > > Tripathy via TF-A > > > > Sent: 19 August 2020 16:42 > > > > To: tf-a(a)lists.trustedfirmware.org > > > > Subject: [TF-A] [RFC] psci: api to power down all cores > > > > > > > > Hi, > > > > I am proposing to have a generic api in psci lib which can be > > > > used to > > > force > > > > power down all other cores from any initiating core analogous to > > > > 'smp_cpu_stop' in linux. It is immune to interrupt lock by > > > > EL1/EL2 software. > > > > > > > > Platforms may use this api in case of secure side panic, secure > > > > watchdog interrupt handling or if required in certain types of > > > > warm resets. The usage > > > is > > > > platform dependent. > > > > > > > > This depends on a generic implementation of secure IPI (1) which > > > > uses EHF > > > to > > > > handle IPI at platform defined priority. We probably require > > > > more types of secure IPIs. > > > > > > > > Please review the series > > > > Ref: > > > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5 > > > > 32 > > > > 4 > > > > > > > > diff --git a/lib/psci/psci_system_off.c > > > > b/lib/psci/psci_system_off.c index > > > > 141d69e..011aaa6 100644 > > > > --- a/lib/psci/psci_system_off.c > > > > +++ b/lib/psci/psci_system_off.c > > > > @@ -10,10 +10,44 @@ > > > > #include <arch_helpers.h> > > > > #include <common/debug.h> > > > > #include <drivers/console.h> > > > > +#include <drivers/delay_timer.h> > > > > #include <plat/common/platform.h> > > > > > > > > #include "psci_private.h" > > > > > > > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define > > > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > > > + > > > > +#if IMAGE_BL31 > > > > +void psci_stop_other_cores(void) { #define > > > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > > > + > > > > +#if IMAGE_BL31 > > > > +void psci_stop_other_cores(void) { > > > > + int idx, this_cpu_idx, cnt; > > > > + > > > > + this_cpu_idx = plat_my_core_pos(); > > > > + > > > > + /* Raise G0 IPI cpustop to all cores but self */ > > > > + for (idx = 0; idx < psci_plat_core_count; idx++) { > > > > + if ((idx != this_cpu_idx) && > > > > + (psci_get_aff_info_state_by_idx(idx) == > > > > AFF_STATE_ON)) { > > > > + > > > > plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); > > > > + } > > > > + } > > > > + > > > > + /* Wait for others cores to shutdown */ > > > > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; > > > > + cnt++) > > > { > > > > + if (psci_is_last_on_cpu()) > > > > + break; > > > > + mdelay(1); > > > > + } > > > > + > > > > + if (!psci_is_last_on_cpu()) { > > > > + WARN("Failed to stop all cores!\n"); > > > > + psci_print_power_domain_map(); > > > > + } > > > > +} > > > > +#endif > > > > + > > > > > > > > (1) > > > > RFC: ipi: add ipi feature > > > > Ref: > > > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > > > a/+/5323/1 > > > > > > > > Thanks > > > > Sandeep > > > > -- > > > > TF-A mailing list > > > > TF-A(a)lists.trustedfirmware.org > > > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 7 months

1
0
0 0

[Request for review] Downstream patches from Tegra repos

by Varun Wadekar

Hello team, Requesting reviews for the latest patches [1] form our internal repos for Tegra platforms. I have updated the verification steps for each patch in the comments to help answer some questions. Thanks in advance. -Varun [1] https://review.trustedfirmware.org/q/topic:%22tegra-downstream-08252020%22+…

4 years, 7 months

1
0
0 0

New Defects reported by Coverity Scan for ARM-software/arm-trusted-firmware

by scan-admin＠coverity.com

Hi, Please find the latest report on new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. 1 new defect(s) introduced to ARM-software/arm-trusted-firmware found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 361456: Memory - illegal accesses (NEGATIVE_RETURNS) /services/std_svc/spmd/spmd_main.c: 49 in spmd_get_context_by_mpidr() ________________________________________________________________________________________________________ *** CID 361456: Memory - illegal accesses (NEGATIVE_RETURNS) /services/std_svc/spmd/spmd_main.c: 49 in spmd_get_context_by_mpidr() 43 44 /******************************************************************************* 45 * SPM Core context on CPU based on mpidr. 46 ******************************************************************************/ 47 spmd_spm_core_context_t *spmd_get_context_by_mpidr(uint64_t mpidr) 48 { >>> CID 361456: Memory - illegal accesses (NEGATIVE_RETURNS) >>> Using variable "plat_core_pos_by_mpidr(mpidr)" as an index to array "spm_core_context". 49 return &spm_core_context[plat_core_pos_by_mpidr(mpidr)]; 50 } 51 52 /******************************************************************************* 53 * SPM Core context on current CPU get helper. 54 ******************************************************************************/ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

4 years, 7 months

1
0
0 0

Re: [TF-A] [RFC] Api to power down all cores

by Sandeep Tripathy

Hi Soby, I realize using term 'PSCI API' in rfc tag is misleading like Achin mentioned in gerrit. Here I wanted to have a generic API to 'stop_other_cores' in secure world. The usage is platform firmware specific. Implementation of 'stop_other_cores' depends on a generic 'IPI' support (1). It leverages the existing EHF. So I feel it is not adding and complexity or overhead in normal execution path. 'stop_other_cores' API implementation depends on some psci private functions to traverse the pd nodes and extract MPIDRs for target pe list. That was the reason to put the function within psci lib. So there are two things. 1- Does this idea of 'stop_other_core' api qualify to be generic 2- Does a generic IPI layer make sense Thanks Sandeep > -----Original Message----- > From: Soby Mathew [mailto:Soby.Mathew@arm.com] > Sent: Thursday, August 20, 2020 8:54 PM > To: Sandeep Tripathy > Cc: tf-a(a)lists.trustedfirmware.org > Subject: RE: [TF-A] [RFC] psci: api to power down all cores > > Hi Sandeep, > Just to understand better, if there is a secure side panic/watchdog > interrupt, > then the secure side is already able to do such an intervention without > the > availability of a PSCI API to the NS side. > > In case the NS world has crashed, then PSCI_SYSTEM_RESET and > PSCI_SYSTEM_OFF APIs can be invoked which then does the appropriate > actions. From my reading, the PSCI specification doesn't prevent firmware > implementation of the reset and off API's from doing the kind of > implementation as per your proposal. I intend to do 'stop_other_cores' in platform extension of 'plat_system_resetx()', secure side watchdog expiry/ plat_panic_handler(). > > Best Regards > Soby Mathew > > > -----Original Message----- > > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of > Sandeep > > Tripathy via TF-A > > Sent: 19 August 2020 16:42 > > To: tf-a(a)lists.trustedfirmware.org > > Subject: [TF-A] [RFC] psci: api to power down all cores > > > > Hi, > > I am proposing to have a generic api in psci lib which can be used to > force > > power down all other cores from any initiating core analogous to > > 'smp_cpu_stop' in linux. It is immune to interrupt lock by EL1/EL2 > > software. > > > > Platforms may use this api in case of secure side panic, secure watchdog > > interrupt handling or if required in certain types of warm resets. The > > usage > is > > platform dependent. > > > > This depends on a generic implementation of secure IPI (1) which uses > > EHF > to > > handle IPI at platform defined priority. We probably require more types > > of > > secure IPIs. > > > > Please review the series > > Ref: > > https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5324 > > > > diff --git a/lib/psci/psci_system_off.c b/lib/psci/psci_system_off.c > > index > > 141d69e..011aaa6 100644 > > --- a/lib/psci/psci_system_off.c > > +++ b/lib/psci/psci_system_off.c > > @@ -10,10 +10,44 @@ > > #include <arch_helpers.h> > > #include <common/debug.h> > > #include <drivers/console.h> > > +#include <drivers/delay_timer.h> > > #include <plat/common/platform.h> > > > > #include "psci_private.h" > > > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define > > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > + > > +#if IMAGE_BL31 > > +void psci_stop_other_cores(void) > > +{ > > +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > > + > > +#if IMAGE_BL31 > > +void psci_stop_other_cores(void) > > +{ > > + int idx, this_cpu_idx, cnt; > > + > > + this_cpu_idx = plat_my_core_pos(); > > + > > + /* Raise G0 IPI cpustop to all cores but self */ > > + for (idx = 0; idx < psci_plat_core_count; idx++) { > > + if ((idx != this_cpu_idx) && > > + (psci_get_aff_info_state_by_idx(idx) == > > AFF_STATE_ON)) { > > + > > plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); > > + } > > + } > > + > > + /* Wait for others cores to shutdown */ > > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; cnt++) > { > > + if (psci_is_last_on_cpu()) > > + break; > > + mdelay(1); > > + } > > + > > + if (!psci_is_last_on_cpu()) { > > + WARN("Failed to stop all cores!\n"); > > + psci_print_power_domain_map(); > > + } > > +} > > +#endif > > + > > > > (1) > > RFC: ipi: add ipi feature > > Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware- > a/+/5323/1 > > > > Thanks > > Sandeep > > -- > > TF-A mailing list > > TF-A(a)lists.trustedfirmware.org > > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 8 months

2
1
0 0

Re: [TF-A] [RFC] psci: api to power down all cores

by Soby Mathew

Hi Sandeep, Just to understand better, if there is a secure side panic/watchdog interrupt, then the secure side is already able to do such an intervention without the availability of a PSCI API to the NS side. In case the NS world has crashed, then PSCI_SYSTEM_RESET and PSCI_SYSTEM_OFF APIs can be invoked which then does the appropriate actions. From my reading, the PSCI specification doesn't prevent firmware implementation of the reset and off API's from doing the kind of implementation as per your proposal. Best Regards Soby Mathew > -----Original Message----- > From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Sandeep > Tripathy via TF-A > Sent: 19 August 2020 16:42 > To: tf-a(a)lists.trustedfirmware.org > Subject: [TF-A] [RFC] psci: api to power down all cores > > Hi, > I am proposing to have a generic api in psci lib which can be used to force > power down all other cores from any initiating core analogous to > 'smp_cpu_stop' in linux. It is immune to interrupt lock by EL1/EL2 software. > > Platforms may use this api in case of secure side panic, secure watchdog > interrupt handling or if required in certain types of warm resets. The usage is > platform dependent. > > This depends on a generic implementation of secure IPI (1) which uses EHF to > handle IPI at platform defined priority. We probably require more types of > secure IPIs. > > Please review the series > Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5324 > > diff --git a/lib/psci/psci_system_off.c b/lib/psci/psci_system_off.c index > 141d69e..011aaa6 100644 > --- a/lib/psci/psci_system_off.c > +++ b/lib/psci/psci_system_off.c > @@ -10,10 +10,44 @@ > #include <arch_helpers.h> > #include <common/debug.h> > #include <drivers/console.h> > +#include <drivers/delay_timer.h> > #include <plat/common/platform.h> > > #include "psci_private.h" > > +#ifndef PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS #define > +PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > + > +#if IMAGE_BL31 > +void psci_stop_other_cores(void) > +{ > +#define PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS 1000 #endif > + > +#if IMAGE_BL31 > +void psci_stop_other_cores(void) > +{ > + int idx, this_cpu_idx, cnt; > + > + this_cpu_idx = plat_my_core_pos(); > + > + /* Raise G0 IPI cpustop to all cores but self */ > + for (idx = 0; idx < psci_plat_core_count; idx++) { > + if ((idx != this_cpu_idx) && > + (psci_get_aff_info_state_by_idx(idx) == AFF_STATE_ON)) { > + plat_ipi_send_cpu_stop(psci_cpu_pd_nodes[idx].mpidr); > + } > + } > + > + /* Wait for others cores to shutdown */ > + for (cnt = 0; cnt < PLAT_CORES_PWRDWN_WAIT_TIMEOUT_MS; cnt++) { > + if (psci_is_last_on_cpu()) > + break; > + mdelay(1); > + } > + > + if (!psci_is_last_on_cpu()) { > + WARN("Failed to stop all cores!\n"); > + psci_print_power_domain_map(); > + } > +} > +#endif > + > > (1) > RFC: ipi: add ipi feature > Ref: https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/5323/1 > > Thanks > Sandeep > -- > TF-A mailing list > TF-A(a)lists.trustedfirmware.org > https://lists.trustedfirmware.org/mailman/listinfo/tf-a

4 years, 8 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

TF-A