+Ulf Hansson <ulf.hansson(a)linaro.org> and +Jens Wiklander
<jens.wiklander(a)linaro.org>, who are able to help with testing.
Hi Sudeep and Jacky,
I wanted to clarify our use case for suspend-to-idle. For mobile and other
battery-powered devices, the key capability we need isn't just the ability
to enter s2idle, but also reaching equivalent power savings in s2idle
compared to suspend-to-RAM. Essentially, if all CPU cores are idle, we want
to be able to drop into the deepest low-power state that is just as
energy-efficient as suspend-to-RAM, but without hot-unplugging and plugging
the CPUs, which means they need to be able to resume in their idle loops.
To achieve this, we're planning to leverage the hierarchical power domain
representation in the device tree [1], which is currently limited to be
used in OS-initiated mode by the PSCI CPUIdle driver [2].
Thanks!
Wing
[1]
https://elixir.bootlin.com/linux/latest/source/Documentation/devicetree/bin…
[2]
https://elixir.bootlin.com/linux/latest/source/drivers/cpuidle/cpuidle-psci…
On Mon, Nov 21, 2022 at 2:50 AM Jacky Bai <ping.bai(a)nxp.com> wrote:
> suspend-to-idle normally means linux ‘freeze’ mode. For this mode, nothing
> related to PSCI OSI support.
>
>
>
> BR
> Jacky Bai
>
> *From:* Sudeep Holla via TF-A <tf-a(a)lists.trustedfirmware.org>
> *Sent:* 2022年11月21日 18:38
> *To:* Wing Li <wingers(a)google.com>
> *Cc:* Dan Handley <Dan.Handley(a)arm.com>; Okash Khawaja <okash(a)google.com>;
> tf-a(a)lists.trustedfirmware.org; tf-a-tests(a)lists.trustedfirmware.org;
> Sudeep Holla <sudeep.holla(a)arm.com>
> *Subject:* [TF-A] Re: PSCI OS-initiated mode
>
>
>
>
>
>
>
> On Mon, Nov 21, 2022 at 2:51 AM Wing Li via TF-A <
> tf-a(a)lists.trustedfirmware.org> wrote:
>
> Hi Dan and Varun,
>
> Our motivation for adding OS-initiated mode is because it's required by
> the Linux PSCI CPUIdle driver to enable support for suspend-to-idle [1].
>
>
>
> That is not correct. If anything is broken or not working, it needs to be
> fixed. Adding platform support for
>
> OSI just to support suspend-to-idle is a completely wrong approach. Can
> you let me know what is not
>
> working or how is it broken ?
>
Hi Dan and Varun,
Our motivation for adding OS-initiated mode is because it's required by the
Linux PSCI CPUIdle driver to enable support for suspend-to-idle [1].
I tested the topic [2] on the FVP_Base_RevC-2xAEMvA platform with and
without setting ARM_RECOM_STATE_ID_ENC, and am happy to report all the
existing and new tests passed in both cases!
I uploaded a design proposal in a new CL [3]. The design allows platforms
to support any number of power states. Regarding impact on the min_latency
values, our team hasn't yet begun integrating our platform with Linux or
any HLOS, and don't have any data to provide at this moment.
Thanks!
Wing
[1]
https://elixir.bootlin.com/linux/latest/source/drivers/cpuidle/cpuidle-psci…
[2] https://review.trustedfirmware.org/q/topic:psci-osi
[3] https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/17896
On Tue, Nov 15, 2022 at 8:20 AM Varun Wadekar <vwadekar(a)nvidia.com> wrote:
> Hi,
>
>
>
> Usually, platforms have multiple power states behind the CPU_SUSPEND PSCI
> call. Did you consider these for your design? If yes, it would be
> interesting to see the prediction accuracy of the OSI model versus the PI
> model. Also do you see any impact on the min_latency values with the OSI
> model?
>
>
>
> By, the way do you have a top level design for the proposal?
>
>
>
> -Varun
>
>
>
> *From:* Dan Handley via TF-A <tf-a(a)lists.trustedfirmware.org>
> *Sent:* Monday, 14 November 2022 5:50 PM
> *To:* Wing Li <wingers(a)google.com>; Okash Khawaja <okash(a)google.com>
> *Cc:* tf-a(a)lists.trustedfirmware.org; tf-a-tests(a)lists.trustedfirmware.org
> *Subject:* [TF-A] Re: PSCI OS-initiated mode
>
>
>
> *External email: Use caution opening links or attachments*
>
>
>
> Hi Wing/Okash
>
>
>
> I know what OSI mode is supposed to deliver in theory – I just haven’t
> seen any compelling evidence of its benefit in practice. If you can share
> any evidence (even anecdotal) that would be great, although it’s not
> essential for these patches to proceed.
>
>
>
> However, we are going to need some upstream platform(s) to exercise the
> new functionality. This can be a model platform, e.g. the Base FVP, not
> necessarily real hw. Are you able to at least get this running locally on
> Base FVP? I’m sure others can help with adding a config to the OpenCI.
>
>
>
> Regards
>
>
> Dan.
>
>
>
> *From:* Wing Li <wingers(a)google.com>
> *Sent:* 11 November 2022 18:34
> *To:* Okash Khawaja <okash(a)google.com>
> *Cc:* Dan Handley <Dan.Handley(a)arm.com>; tf-a(a)lists.trustedfirmware.org;
> tf-a-tests(a)lists.trustedfirmware.org
> *Subject:* Re: [TF-A] Re: PSCI OS-initiated mode
>
>
>
> Hi Dan,
>
> Thanks for your feedback!
>
> I've tested these patches with our platform, but have not tested with any
> upstream platforms. I added tests for the OS-initiated mode code path in
> TF-A-Tests [1] that we can run against upstream platforms to verify. I'm
> not sure how I can get a hold of an upstream platform board; it'd be much
> appreciated if perhaps maintainers of upstream platforms could help run the
> tests?
>
> In theory, any platform that supports CPU_SUSPEND would be able to support
> both platform-coordinated mode and OS-initiated mode, since the power state
> coordination happens either in the PSCI library implementation or in an
> HLOS.
>
> Wing
>
> [1] https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/17684
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
>
>
>
> On Fri, Nov 11, 2022 at 9:43 AM Okash Khawaja <okash(a)google.com> wrote:
>
> Hi Dan,
>
> The idea with OSI mode is that HLOS will have more awareness about
> power sequences and hence will be able to optimise power usage better
> (e.g. using heuristics) if it had more control. This means having HLOS
> which contains right modules for a specific platform and specific use
> case, if we want to do a power/perf comparison between OSI and
> plat-coordinated modes.
>
> On Fri, Nov 11, 2022 at 5:08 PM Dan Handley via TF-A
> <tf-a(a)lists.trustedfirmware.org> wrote:
> >
> > Hi Wing
> >
> > Thanks for your contribution. Are there any upstream platforms that
> these patches have been tested with? If so, it would be good to have
> visibility of the sw stack under test. Ideally, there would be at least 1
> platform that supported both platform-coordinated mode and OS-initiated
> mode, so that a fair power/performance comparison can be done.
> >
> >
> >
> > Regards
> >
> > Dan.
> >
> >
> >
> > From: Wing Li via TF-A <tf-a(a)lists.trustedfirmware.org>
> > Sent: 10 November 2022 05:53
> > To: tf-a(a)lists.trustedfirmware.org; tf-a-tests(a)lists.trustedfirmware.org
> > Subject: [TF-A] PSCI OS-initiated mode
> >
> >
> >
> > Hi,
> >
> > The PSCI specification defines two different power state coordination
> modes for CPU_SUSPEND that can be used to put a core or a group of cores
> into a low-power state. These modes are the platform-coordinated mode
> (default) and the OS-initiated mode (optional). OS-initiated mode is
> currently not supported by TF-A, while both modes are supported by the
> Linux Kernel.
> >
> > Requesting reviews for the patches [1] adding support for OS-initiated
> mode in TF-A and the corresponding tests in TF-A-Tests. Any feedback and
> comments are much appreciated.
> >
> > Thanks in advance!
> >
> > Wing
> >
> > [1] https://review.trustedfirmware.org/q/topic:psci-osi
> <https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Freview.tr…>
> >
> > --
> > TF-A mailing list -- tf-a(a)lists.trustedfirmware.org
> > To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org
>
>
Hi Dan,
Thanks for your feedback!
I've tested these patches with our platform, but have not tested with any
upstream platforms. I added tests for the OS-initiated mode code path in
TF-A-Tests [1] that we can run against upstream platforms to verify. I'm
not sure how I can get a hold of an upstream platform board; it'd be much
appreciated if perhaps maintainers of upstream platforms could help run the
tests?
In theory, any platform that supports CPU_SUSPEND would be able to support
both platform-coordinated mode and OS-initiated mode, since the power state
coordination happens either in the PSCI library implementation or in an
HLOS.
Wing
[1] https://review.trustedfirmware.org/c/TF-A/tf-a-tests/+/17684
On Fri, Nov 11, 2022 at 9:43 AM Okash Khawaja <okash(a)google.com> wrote:
> Hi Dan,
>
> The idea with OSI mode is that HLOS will have more awareness about
> power sequences and hence will be able to optimise power usage better
> (e.g. using heuristics) if it had more control. This means having HLOS
> which contains right modules for a specific platform and specific use
> case, if we want to do a power/perf comparison between OSI and
> plat-coordinated modes.
>
> On Fri, Nov 11, 2022 at 5:08 PM Dan Handley via TF-A
> <tf-a(a)lists.trustedfirmware.org> wrote:
> >
> > Hi Wing
> >
> > Thanks for your contribution. Are there any upstream platforms that
> these patches have been tested with? If so, it would be good to have
> visibility of the sw stack under test. Ideally, there would be at least 1
> platform that supported both platform-coordinated mode and OS-initiated
> mode, so that a fair power/performance comparison can be done.
> >
> >
> >
> > Regards
> >
> > Dan.
> >
> >
> >
> > From: Wing Li via TF-A <tf-a(a)lists.trustedfirmware.org>
> > Sent: 10 November 2022 05:53
> > To: tf-a(a)lists.trustedfirmware.org; tf-a-tests(a)lists.trustedfirmware.org
> > Subject: [TF-A] PSCI OS-initiated mode
> >
> >
> >
> > Hi,
> >
> > The PSCI specification defines two different power state coordination
> modes for CPU_SUSPEND that can be used to put a core or a group of cores
> into a low-power state. These modes are the platform-coordinated mode
> (default) and the OS-initiated mode (optional). OS-initiated mode is
> currently not supported by TF-A, while both modes are supported by the
> Linux Kernel.
> >
> > Requesting reviews for the patches [1] adding support for OS-initiated
> mode in TF-A and the corresponding tests in TF-A-Tests. Any feedback and
> comments are much appreciated.
> >
> > Thanks in advance!
> >
> > Wing
> >
> > [1] https://review.trustedfirmware.org/q/topic:psci-osi
> >
> > --
> > TF-A mailing list -- tf-a(a)lists.trustedfirmware.org
> > To unsubscribe send an email to tf-a-leave(a)lists.trustedfirmware.org
>
Hi,
The PSCI specification defines two different power state coordination modes
for CPU_SUSPEND that can be used to put a core or a group of cores into a
low-power state. These modes are the platform-coordinated mode (default)
and the OS-initiated mode (optional). OS-initiated mode is currently not
supported by TF-A, while both modes are supported by the Linux Kernel.
Requesting reviews for the patches [1] adding support for OS-initiated mode
in TF-A and the corresponding tests in TF-A-Tests. Any feedback and
comments are much appreciated.
Thanks in advance!
Wing
[1] https://review.trustedfirmware.org/q/topic:psci-osi
Hi all --
I was wondering what the intended procedure was for adding and running
platform-specific TF-A tests?
I see a plat/ directory in the tf-a-test/tftf/tests directory, so I assume
I should use that, but I don't see a way to actually point to it normally.
Has anyone tried this before?
I did get it working in a hacky way[0], but I was hoping that there was an
intended path.
My use-case is to test some platform-specific hardware from TF-A.
Thanks!
Ross
[0] I added a `tests-platform.mk` pseudo test that looks in the plat
directory for a platform.mk, just like for finding the platform's .c
sources. Then it looks for the test pointed to by PLAT_TESTS.
Hi,
We are trying to create a secure partition based on cactus.
In cactus_main.c there is a mapping of rxtx region for SPM_VM_ID_FIRST + 2. In our case, there would be just one sp and so we are doing the same for SPM_VM_ID_FIRST itself but it goes into panic.
On checking TF-A code, in file spmd_main.c the request FFA_RXTX_MAP_SMC64 is not allowed to be invoked from secure world. So, in any case when CONFIGURE_AND_MAP_MAILBOX which internally calls ffa_rxtx_map and which further invokes smc for FFA_RXTX_MAP_SMC64, it will always fail.
So should the RXTX mailbox always be mapped from Normal World? If that is the correct understanding, then we are confused with the use of CONFIGURE_AND_MAP_MAILBOX in cactus_main.c
The purpose for setting up this RXTX channel is mainly because cactus memory sharing test requires it and we are writing a small test to share memory from non-secure world.
Any clarity, suggestions would be helpful.
Regards,
Samarth
Thanks Oliver,
Actually, I want to simply use the Cactus OS as the initial test
environment, and finally replace it. Because Cactus is easier to understand
(but OP-TEE is more complex).
Also, I want to use the Hafnium (with SEL2 extension) to manage the
multiple Cactus OSes, and route the "SMC" calls to the corresponding OS.
According to your words, I think I should
(1) Create a service to receive SMC calls from Normal World OS, which
includes specific smc_fid, like this.
DECLARE_RT_SVC(
helloworld,
OEN_TAP_START,
OEN_TAP_END,
SMC_TYPE_FAST,
arm_arch_helloworld_init,
arm_arch_helloworld_smc_handler
);
(2) In the handler, "ERET" it to Hafnium, and then "ERET" to specific
Cactus OSes according to the smc_fid
(3) Modify the Cactus OS to handle it.
Is it right? If NOT, I may consider to use OP-TEE.
Sincerely,
Wang Chenxu
Olivier Deprez <Olivier.Deprez(a)arm.com> 于2021年9月27日周一 下午3:37写道：
> Hi,
>
> Few background questions to understand the request better:
> -Is the intent to enable the SEL2 arch extension, or use the legacy model
> without secure virtualization?
> -Do you intend to use Cactus as an initial test environment with a final
> goal is to replace it by a real TOS?
> -If the ask is about how to write a TA, did you consider existing
> solutions like OP-TEE and relevant documentation?
>
> In general TA refers to a SW component running at SEL0 on top of a TOS at
> SEL1.
> What you call "Cactus OS" is really just a sample test payload running at
> SEL1.
> It's not a TOS in terms of loading Trusted Applications, providing
> services (system calls), managing memory and IPC.
>
> The starting point should be the FF-A specification (
> https://developer.arm.com/documentation/den0077/latest/).
> You can repurpose Cactus to host a service at SEL1, which can be called by
> the NWd (TFTF test framework).
> There is normally no need to modify EL3.
>
> The below sample illustrate the message passing between TFTF at NS EL2,
> and Cactus at SEL1:
> TFTF:
> https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/tftf/tests/runtime…
> cactus:
> https://git.trustedfirmware.org/TF-A/tf-a-tests.git/tree/spm/cactus/cactus_…
>
> Please also have a look at the component documentation:
>
> https://trustedfirmware-a.readthedocs.io/en/latest/components/secure-partit…
>
> Depending on what you want to achieve, there are also solutions around
> SEL0 partitions (not involving a TOS), or the Trusted Services project.
>
> Regards,
> Olivier.
>
> ________________________________________
> From: TF-A <tf-a-bounces(a)lists.trustedfirmware.org> on behalf of Chenxu
> Wang via TF-A <tf-a(a)lists.trustedfirmware.org>
> Sent: 27 September 2021 05:44
> To: tf-a(a)lists.trustedfirmware.org
> Subject: [TF-A] How to write a Trsuted Application?
>
> Hi all,
>
> I want to write a TA which will be called from the Normal World and be
> handled by a specific Trusted OS. Currently, I am using 3 Cactus OS
> (provided by TF-A-Tests) in SEL1, and a Hafnium in SEL2. Here is my partial
> building cmd
>
> make CROSS_COMPILE=aarch64-none-elf- SPD=spmd CTX_INCLUDE_EL2_REGS=1
> ARM_ARCH_MINOR=4 PLAT=fvp DEBUG=1
> BL33=../tf-a-tests/build/fvp/debug/tftf.bin
> BL32=../hafnium/out/reference/secure_aem_v8a_fvp_clang/hafnium.bin
> SP_LAYOUT_FILE=../tf-a-tests/build/fvp/debug/sp_layout.json all fip
>
> I have created some EL3 services at services/std_svc, but have not created
> a TA.
> In my view, to call the TA, I think I should pass (1) the ID of the TA
> (but I am not sure how to get the ID) (2) several parameters, which may be
> loaded into registers. Here may be a calling process.
>
> ldr x0,=0xdeadbeef // loading ID
> ldr x1,=0x11111 // input parameters
> ldr x2,=0x22222 // input parameters
> smc #0
>
> Then I think I should write a corresponding handler (of the TA) in Cactus
> OS. When we call "smc #0", EL3 will trap it, and route it to a specific TA.
>
> However, I don't know how to do it. Can you provide some useful examples?
>
> Sincerely,
> Wang Chenxu
>
Hi all,
I want to write a TA which will be called from the Normal World and be
handled by specific Cactus OS.
Specifically, to call the TA, I think I should pass (1) the ID of the TA
(but I am not sure how to get the ID) (2) several parameters, which may be
loaded into registers. Here may be a calling process.
ldr x0,=0xdeadbeef // loading ID
ldr x1,=0x11111 // input parameters
ldr x2,=0x22222 // input parameters
smc #0
Then I think I should write a corresponding handler (of the TA) in Cactus
OS. When we call "smc #0", EL3 will trap it, and route it to a specific TA.
However, I don't know how to do it. Can you provide some useful examples?
Sincerely,
Wang Chenxu
