> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Gutierrez,
> Hernan Ildefonso (Boise R&D, FW) via TF-A
> Sent: 24 June 2019 22:35
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] Armv8A Suspend/Resume reference code
>
> Hi,
>
> I am looking for reference code for ArmV8A core suspend/resume.
> Are there code references that are suggested to look for?
> Application notes to read?
>
Hi Hernan,
The PSCI Spec[1] specifies power management on ARM CPUs and this includes suspend and resume. The TF-A provides an implementation of PSCI with appropriate hooks to plug-in in platform specifics. There are documents in the `docs` folder which cover different aspects of PSCI implementation like PSCI topology [2], CPU specifics [3], and platform porting guide [4].
In terms of adding support for a new platform, it is most likely that all the architectural (as in ARMv8A reference manual) and the CPU specific power management as specified in the TRM are covered already (see lib/cpus/ folder for CPUs already supported). So it’s a matter of implementing the platform hooks as mentioned in the porting guide [4].
With respect to implementing platform hooks, the ARM reference platforms like FVP provide an example of how the hooks can be implemented (see fvp_pm.c/fvp_topology.c ). So if you platform is a GICv3 system and the power controller already uses SCMI as the protocol for communication, then most of the code in FVP can be reused for your platform.
Hope that provides a starting point for you to begin.
[1] http://infocenter.arm.com/help/topic/com.arm.doc.den0022d/Power_State_Coord…
[2] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/desi…
[3] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/desi… (see CPU specific operations framework)
[4] https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/gett… (see Power State Coordination Interface)
> Any pointers will be appreciated, thanks.
>
> Hernan
>
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
I am looking for reference code for ArmV8A core suspend/resume.
Are there code references that are suggested to look for?
Application notes to read?
Any pointers will be appreciated, thanks.
Hernan
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of Thor
> Thayer via TF-A
> Sent: 20 June 2019 09:05
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] Can 1 Core in EL3 elevate other 3 cores to EL3?
>
> Hi,
>
> I have a quad-core ARM64 Cortex-A53 where 1 core is executing in EL3 while
> the other 3 cores are in EL1. The 3 cores in EL1 are spinning in a WFI loop. The
> EL3 CPU transitioned to EL3 as a result of the PSCI RESET2 call from Linux.
>
> Is there a way for the EL3 core to switch the other cores into EL3 easily?
Hi Thor,
One way to do this to configure an IPI (SGI in GICv3 terminology) to be an EL3 interrupt (Group 0). Trigger this IPI from the first core to all the other 3 cores. This will cause the 3 cores to transition to EL3 to handle the EL3 interrupt and you will have to configure a suitable interrupt handler.
Implication of this new EL3 IPI is that it can also cause the core to transition to EL3 if triggered when executing in Secure world.
Also be aware that configuration of any EL3 interrupt will affect the routing model and change the behaviour of normal world interrupts when executing in Secure world. The secure world executing a "yielding" SMC request will get pre-empted on occurrence of normal world interrupt and the secure world may not get a chance to do a "controlled exit".
Usually the PSCI_RESET2 can work without all the cores being in EL3. Could you elaborate why the other cores need to be in EL3 for this reset?
>
> As far as I know, the communication between cores takes place through the IPI.
> Unfortunately, in my case, an SError has occurred that is masking the IPI.
>
If I understand correctly, the PSCI_RESET2 is being issued after the SError has happened on other cores. The EL3 IPI should cause these cores to transition to EL3 regardless of the interrupt mask state at lower Els.
> Thanks,
>
> Thor
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi,
I have a quad-core ARM64 Cortex-A53 where 1 core is executing in EL3
while the other 3 cores are in EL1. The 3 cores in EL1 are spinning in a
WFI loop. The EL3 CPU transitioned to EL3 as a result of the PSCI RESET2
call from Linux.
Is there a way for the EL3 core to switch the other cores into EL3 easily?
As far as I know, the communication between cores takes place through
the IPI. Unfortunately, in my case, an SError has occurred that is
masking the IPI.
Thanks,
Thor
> -----Original Message-----
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> On Behalf Of David
> Cerdeira via TF-A
> Sent: 04 June 2019 10:04
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] Arm trusted firmware reads wrong fip file from flash on
> hikey960v2
>
> Greetings,
> i’m having trouble getting arm trusted firmware to work on hikey960v2 I
> followed all the steps in this guide https://github.com/ARM-software/arm-
> trusted-firmware/blob/master/docs/plat/hikey960.rst,
> and the steps in https://optee.readthedocs.io/building/devices/hikey960.html
> The problem seems to be in reading the fip.bin, or rather the problem is
> writing the fip file as it seems it is not properly flashed.
> ATF bl2 fails to find the UUID of the BL2_SCP image in the fip.bin output by the
> build process, the fip file it reads from flash only has the BL31 and BL33 UUIDs.
>
> I tried checking older versions of ATF, as I figured it might be a problem in
> current versions, but the same problems occurred.
Hi David,
I don’t have much insight into platform specifics. One suggestion is to try with pre-built binaries and once they are working, replace with your custom ones. This page may help : http://releases.linaro.org/96boards/hikey/linaro/debian/15.11/
The Hikey Platform maintainers may be able to help more in this regard.
Best Regards
Soby Mathew
>
> At this moment I feel the problem is in the flashing step.
> I tried moving the partitions in the partition tables, as well as the value of the
> macro HIKEY960_FIP_BASE present in hikey960_def.h to match what I thought
> would be the writing position of the file in the partition, but without success.
>
> If anyone could give me any idea as to what the problem might be, that’d be
> great Best regards, David Cerdeira
> --
> TF-A mailing list
> TF-A(a)lists.trustedfirmware.org
> https://lists.trustedfirmware.org/mailman/listinfo/tf-a
Hi Jun,
Thank you for your patches.
We do not use this mailing list for patch submission/code review,
instead we use Gerrit. Could you please upload these patches on
review.trustedfirmware.org? The following wiki page might be helpful:
https://developer.trustedfirmware.org/w/tf_a/gerrit-getting-started/
Many thanks,
Sandrine Bailleux
Hello Abel,
What is the status of this workaround? I saw that you had a similar discussion at the kernel mailing list (https://lkml.org/lkml/2019/3/27/542) which, however, has been inactive for some time.
Do you still intend to pursue that solution? If you do so, please submit your patches to review.trustedfirmware.org under the "TF-A/trusted-firmware-a" project. To login you just need your GitHub account. You can find further information about contributions in https://git.trustedfirmware.org/TF-A/trusted-firmware-a.git/about/docs/proc…, especially the "Submitting Changes" section, or contact us here.
Kind regards,
John
--
John Tsichritzis | Graduate Software Engineer
Email: john.tsichritzis(a)arm.com<mailto:john.tsichritzis@arm.com>
110 Fulbourn Road, Cambridge, CB1 9NJ, United Kingdom
https://www.arm.com/
On 2019-03-27 15:35, Abel Vesa via TF-A wrote:
On 19-03-27 13:45:21, Soby Mathew wrote:
Hi Abel,
Thanks for the RFC. On the face of it, this is a new PSCI command that would need further discussion involving Architecture and Kernel teams.
I know this might be a pain. That's why I'm just asking for as many opinions on this as possible.
Just to summarize my understanding:
Currently any interrupt targeted to a suspended core can wake it up, but it seems that this mechanism is broken on i.MX8MQ and hence you need an explicit command to wake it. This assumes that one CPU is always ON within the system ready to poke the suspended CPU back to life. This assumption is not true always as it is legal for all the CPUs to be in suspend state at the same time.
That errata is specifically for IPIs. If all the cores are in suspend, any interrupt will be able to wake one of the cores. That's why the workaround suggested in that document works. But that workaround is waking up all the cores, that's why I added this poking mechanism which is per-core.
Adding the kernel team for their input.
JFYI, We do not intend to review patches via the mailing list and patches should be pushed as mentioned here:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…
Currently the project is in github but we expect to migrate to trustedfirmware.org in April.
Hmm, ok. Good to know.
Best Regards
Soby Mathew
-----Original Message-----
From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org><mailto:tf-a-bounces@lists.trustedfirmware.org> On Behalf Of Abel Vesa
via TF-A
Sent: 27 March 2019 12:16
To: tf-a(a)lists.trustedfirmware.org<mailto:tf-a@lists.trustedfirmware.org>
Subject: [TF-A] [RFC 0/2] psci: Add core wakeup operation
This is more like a workaround for platforms like i.MX8MQ that have an issue
related to the wake_request GIC signal integration.
See E11171 here:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.nxp.c…
The workaround mentioned in the document has the dissadvantage of waking
up all the sleeping cores instead of just one.
This patchset adds another psci op for core 'poking' (waking up).
On i.MX8MQ, the plat specific implementation writes the corresponding bits in
GPC to wake up independently each core.
Abel Vesa (2):
psci: Add cpu wake operation
plat: imx8mq: Trigger SW power up per core
include/lib/psci/psci.h | 3 +++
lib/psci/psci_main.c | 17 +++++++++++++++++
lib/psci/psci_setup.c | 2 ++
plat/imx/imx8m/imx8mq/gpc.c | 7 +++++++
plat/imx/imx8m/imx8mq/imx8mq_psci.c | 8 ++++++++
plat/imx/imx8m/include/gpc.h | 2 ++
6 files changed, 39 insertions(+)
--
2.7.4
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org<mailto:TF-A@lists.trustedfirmware.org>
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.tru…
Greetings,
i’m having trouble getting arm trusted firmware to work on hikey960v2
I followed all the steps in this guide
https://github.com/ARM-software/arm-trusted-firmware/blob/master/docs/plat/…,
and the steps in https://optee.readthedocs.io/building/devices/hikey960.html
The problem seems to be in reading the fip.bin, or rather the problem is
writing the fip file as it seems it is not properly flashed.
ATF bl2 fails to find the UUID of the BL2_SCP image in the fip.bin output
by the build process, the fip file it reads from flash only has the BL31
and BL33 UUIDs.
I tried checking older versions of ATF, as I figured it might be a problem
in current versions, but the same problems occurred.
At this moment I feel the problem is in the flashing step.
I tried moving the partitions in the partition tables, as well as the value
of the macro HIKEY960_FIP_BASE present in hikey960_def.h to match what I
thought would be the writing position of the file in the partition, but
without success.
If anyone could give me any idea as to what the problem might be, that’d be
great
Best regards,
David Cerdeira
