[U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the standard power management and platform specific PSCI services. The purpose of this patchsets is to allow u-boot users to support their own platform specific secure SMC/PSCI services without making any SMC calls to ATF. This will benefit the users who need to use u-boot as the only bootloader and secure service provider without relying on ATF.
Below is a simple code example for adding your own PSCI functions:
#include <common.h> #include <errno.h> #include <asm/io.h> #include <asm/psci.h> #include <asm/secure.h>
#define PSCI_SMC64_FUNC_ID1 0xC2000001 #define PSCI_SMC64_FUNC_ID2 0xC2000002
static void __secure psci_plat_specific_func1(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 1 */ }
static void __secure psci_plat_specific_func2(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 2 */ }
DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, psci_plat_specific_func1); DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, psci_plat_specific_func2);
Ang, Chee Hong (1): ARMv8: Disable fwcall when PSCI is enabled
Chee Hong Ang (1): ARMv8: Allow SiP service extensions on top of PSCI code
arch/arm/cpu/armv8/Makefile | 2 ++ arch/arm/cpu/armv8/psci.S | 33 +++++++++++++++++++++++++++------ arch/arm/cpu/armv8/u-boot.lds | 4 ++++ arch/arm/include/asm/secure.h | 31 +++++++++++++++++++++++++++++++ 4 files changed, 64 insertions(+), 6 deletions(-)
From: Chee Hong Ang chee.hong.ang@intel.com
Allow PSCI layer to handle any SiP service functions added by platform vendors. PSCI layer will look for SiP service function in the SiP function table located in '._secure_svc_tbl_entries' section if the SMC function identifier is not found in the PSCI standard functions table. Use DECLARE_SECURE_SVC macro to declare and add platform specific SiP service function. This new section '._secure_svc_tbl_entries' is located next to '._secure.text' section. Refer to arch/arm/cpu/armv8/u-boot.lds.
Signed-off-by: Chee Hong Ang chee.hong.ang@intel.com --- arch/arm/cpu/armv8/psci.S | 33 +++++++++++++++++++++++++++------ arch/arm/cpu/armv8/u-boot.lds | 4 ++++ arch/arm/include/asm/secure.h | 31 +++++++++++++++++++++++++++++++ 3 files changed, 62 insertions(+), 6 deletions(-)
diff --git a/arch/arm/cpu/armv8/psci.S b/arch/arm/cpu/armv8/psci.S index 358df8f..fc42d80 100644 --- a/arch/arm/cpu/armv8/psci.S +++ b/arch/arm/cpu/armv8/psci.S @@ -8,6 +8,7 @@ #include <config.h> #include <linux/linkage.h> #include <asm/psci.h> +#include <asm/secure.h>
/* Default PSCI function, return -1, Not Implemented */ #define PSCI_DEFAULT(__fn) \ @@ -147,18 +148,38 @@ handle_psci: 3: mov x0, #ARM_PSCI_RET_NI psci_return
-unknown_smc_id: - ldr x0, =0xFFFFFFFF +/* + * Handle SiP service functions defined in SiP service function table. + * Use DECLARE_SECURE_SVC(_name, _id, _fn) to add platform specific SiP + * service function into the SiP service function table. + * SiP service function table is located in '._secure_svc_tbl_entries' section, + * which is next to '._secure.text' section. + */ +handle_svc: + adr x9, __secure_svc_tbl_start + adr x10, __secure_svc_tbl_end + subs x12, x10, x9 /* Get number of entries in table */ + b.eq 2f /* Make sure SiP function table is not empty */ + psci_enter +1: ldr x10, [x9] /* Load SiP function table */ + ldr x11, [x9, #8] + cmp w10, w0 + b.eq 2b /* SiP service function found */ + add x9, x9, #SECURE_SVC_TBL_OFFSET /* Move to next entry */ + subs x12, x12, #SECURE_SVC_TBL_OFFSET + b.eq 3b /* If reach the end, bail out */ + b 1b +2: ldr x0, =0xFFFFFFFF eret
handle_smc32: /* SMC function ID 0x84000000-0x8400001F: 32 bits PSCI */ ldr w9, =0x8400001F cmp w0, w9 - b.gt unknown_smc_id + b.gt handle_svc ldr w9, =0x84000000 cmp w0, w9 - b.lt unknown_smc_id + b.lt handle_svc
adr x9, _psci_32_table b handle_psci @@ -171,10 +192,10 @@ handle_smc64: /* SMC function ID 0xC4000000-0xC400001F: 64 bits PSCI */ ldr x9, =0xC400001F cmp x0, x9 - b.gt unknown_smc_id + b.gt handle_svc ldr x9, =0xC4000000 cmp x0, x9 - b.lt unknown_smc_id + b.lt handle_svc
adr x9, _psci_64_table b handle_psci diff --git a/arch/arm/cpu/armv8/u-boot.lds b/arch/arm/cpu/armv8/u-boot.lds index 53de80f..2554980 100644 --- a/arch/arm/cpu/armv8/u-boot.lds +++ b/arch/arm/cpu/armv8/u-boot.lds @@ -58,6 +58,10 @@ SECTIONS AT(ADDR(.__secure_start) + SIZEOF(.__secure_start)) { *(._secure.text) + . = ALIGN(8); + __secure_svc_tbl_start = .; + KEEP(*(._secure_svc_tbl_entries)) + __secure_svc_tbl_end = .; }
.secure_data : AT(LOADADDR(.secure_text) + SIZEOF(.secure_text)) diff --git a/arch/arm/include/asm/secure.h b/arch/arm/include/asm/secure.h index d23044a..50582c9 100644 --- a/arch/arm/include/asm/secure.h +++ b/arch/arm/include/asm/secure.h @@ -6,6 +6,37 @@ #define __secure __attribute__ ((section ("._secure.text"))) #define __secure_data __attribute__ ((section ("._secure.data")))
+#ifndef __ASSEMBLY__ + +typedef struct secure_svc_tbl { + u32 id; +#ifdef CONFIG_ARMV8_PSCI + u8 pad[4]; +#endif + void *func; +} secure_svc_tbl_t; + +/* + * Macro to declare a SiP function service in '_secure_svc_tbl_entries' section + */ +#define DECLARE_SECURE_SVC(_name, _id, _fn) \ + static const secure_svc_tbl_t __secure_svc_ ## _name \ + __attribute__((used, section("._secure_svc_tbl_entries"))) \ + = { \ + .id = _id, \ + .func = _fn } + +#else + +#ifdef CONFIG_ARMV8_PSCI +#define SECURE_SVC_TBL_OFFSET 16 +#else +#define SECURE_SVC_TBL_OFFSET 8 + +#endif + +#endif /* __ASSEMBLY__ */ + #if defined(CONFIG_ARMV7_SECURE_BASE) || defined(CONFIG_ARMV8_SECURE_BASE) /* * Warning, horror ahead.
On Tue, Feb 12, 2019 at 12:27:02AM -0800, chee.hong.ang@intel.com wrote:
From: Chee Hong Ang chee.hong.ang@intel.com
Allow PSCI layer to handle any SiP service functions added by platform vendors. PSCI layer will look for SiP service function in the SiP function table located in '._secure_svc_tbl_entries' section if the SMC function identifier is not found in the PSCI standard functions table. Use DECLARE_SECURE_SVC macro to declare and add platform specific SiP service function. This new section '._secure_svc_tbl_entries' is located next to '._secure.text' section. Refer to arch/arm/cpu/armv8/u-boot.lds.
Signed-off-by: Chee Hong Ang chee.hong.ang@intel.com
Applied to u-boot/master, thanks!
From: "Ang, Chee Hong" chee.hong.ang@intel.com
When PSCI is enabled, we are expecting U-Boot which now act as EL3 software will handle all the PSCI calls. We won't need fwcall as no further HVC or SMC are needed.
Signed-off-by: Ang, Chee Hong chee.hong.ang@intel.com --- arch/arm/cpu/armv8/Makefile | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile index 4c4b13c..ae6178f 100644 --- a/arch/arm/cpu/armv8/Makefile +++ b/arch/arm/cpu/armv8/Makefile @@ -18,7 +18,9 @@ endif obj-y += cache.o obj-y += tlb.o obj-y += transition.o +ifndef CONFIG_ARMV8_PSCI obj-y += fwcall.o +endif obj-y += cpu-dt.o obj-$(CONFIG_ARM_SMCCC) += smccc-call.o
On Tue, Feb 12, 2019 at 12:27:03AM -0800, chee.hong.ang@intel.com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
When PSCI is enabled, we are expecting U-Boot which now act as EL3 software will handle all the PSCI calls. We won't need fwcall as no further HVC or SMC are needed.
Signed-off-by: Ang, Chee Hong chee.hong.ang@intel.com
Applied to u-boot/master, thanks!
Hi Tom,
Any comments on this patch ?
Best Regards, Ang On Tue, 2019-02-12 at 00:27 -0800, chee.hong.ang@intel.com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the standard power management and platform specific PSCI services. The purpose of this patchsets is to allow u-boot users to support their own platform specific secure SMC/PSCI services without making any SMC calls to ATF. This will benefit the users who need to use u-boot as the only bootloader and secure service provider without relying on ATF.
Below is a simple code example for adding your own PSCI functions:
#include <common.h> #include <errno.h> #include <asm/io.h> #include <asm/psci.h> #include <asm/secure.h>
#define PSCI_SMC64_FUNC_ID1 0xC2000001 #define PSCI_SMC64_FUNC_ID2 0xC2000002
static void __secure psci_plat_specific_func1(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 1 */ }
static void __secure psci_plat_specific_func2(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 2 */ }
DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, psci_plat_specific_func1); DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, psci_plat_specific_func2);
Ang, Chee Hong (1): ARMv8: Disable fwcall when PSCI is enabled
Chee Hong Ang (1): ARMv8: Allow SiP service extensions on top of PSCI code
arch/arm/cpu/armv8/Makefile | 2 ++ arch/arm/cpu/armv8/psci.S | 33 +++++++++++++++++++++++++++------ arch/arm/cpu/armv8/u-boot.lds | 4 ++++ arch/arm/include/asm/secure.h | 31 +++++++++++++++++++++++++++++++ 4 files changed, 64 insertions(+), 6 deletions(-)
On Tue, 2019-02-12 at 00:27 -0800, chee.hong.ang@intel.com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Hi Tom/Albert,
Any comment on this patch ?
Best Regards, Ang
Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the standard power management and platform specific PSCI services. The purpose of this patchsets is to allow u-boot users to support their own platform specific secure SMC/PSCI services without making any SMC calls to ATF. This will benefit the users who need to use u-boot as the only bootloader and secure service provider without relying on ATF.
Below is a simple code example for adding your own PSCI functions:
#include <common.h> #include <errno.h> #include <asm/io.h> #include <asm/psci.h> #include <asm/secure.h>
#define PSCI_SMC64_FUNC_ID1 0xC2000001 #define PSCI_SMC64_FUNC_ID2 0xC2000002
static void __secure psci_plat_specific_func1(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 1 */ }
static void __secure psci_plat_specific_func2(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 2 */ }
DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, psci_plat_specific_func1); DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, psci_plat_specific_func2);
Ang, Chee Hong (1): ARMv8: Disable fwcall when PSCI is enabled
Chee Hong Ang (1): ARMv8: Allow SiP service extensions on top of PSCI code
arch/arm/cpu/armv8/Makefile | 2 ++ arch/arm/cpu/armv8/psci.S | 33 +++++++++++++++++++++++++++------ arch/arm/cpu/armv8/u-boot.lds | 4 ++++ arch/arm/include/asm/secure.h | 31 +++++++++++++++++++++++++++++++ 4 files changed, 64 insertions(+), 6 deletions(-)
On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang@intel.com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the standard power management and platform specific PSCI services. The purpose of this patchsets is to allow u-boot users to support their own platform specific secure SMC/PSCI services without making any SMC calls to ATF. This will benefit the users who need to use u-boot as the only bootloader and secure service provider without relying on ATF.
Below is a simple code example for adding your own PSCI functions:
#include <common.h> #include <errno.h> #include <asm/io.h> #include <asm/psci.h> #include <asm/secure.h>
#define PSCI_SMC64_FUNC_ID1 0xC2000001 #define PSCI_SMC64_FUNC_ID2 0xC2000002
static void __secure psci_plat_specific_func1(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 1 */ }
static void __secure psci_plat_specific_func2(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 2 */ }
DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, psci_plat_specific_func1); DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, psci_plat_specific_func2);
Ang, Chee Hong (1): ARMv8: Disable fwcall when PSCI is enabled
Chee Hong Ang (1): ARMv8: Allow SiP service extensions on top of PSCI code
Conceptually, I suppose this is a logical step. In specifics, would we want to make this functionality opt-in, or no, that doesn't make sense?
On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang@intel.com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the standard power management and platform specific PSCI services. The purpose of this patchsets is to allow u-boot users to support their own platform specific secure SMC/PSCI services without making any SMC calls to ATF. This will benefit the users who need to use u- boot as the only bootloader and secure service provider without relying on ATF.
Below is a simple code example for adding your own PSCI functions:
#include <common.h> #include <errno.h> #include <asm/io.h> #include <asm/psci.h> #include <asm/secure.h>
#define PSCI_SMC64_FUNC_ID1 0xC2000001 #define PSCI_SMC64_FUNC_ID2 0xC2000002
static void __secure psci_plat_specific_func1(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 1 */ }
static void __secure psci_plat_specific_func2(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 2 */ }
DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, psci_plat_specific_func1); DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, psci_plat_specific_func2);
Ang, Chee Hong (1): ARMv8: Disable fwcall when PSCI is enabled
Chee Hong Ang (1): ARMv8: Allow SiP service extensions on top of PSCI code
Conceptually, I suppose this is a logical step. In specifics, would we want to make this functionality opt-in, or no, that doesn't make sense?
Allowing user to add platform specific service is part of SMC/PSCI specification as specifed in ARM document (Table 2-1): http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_ SMC_Calling_Convention.pdf
So I think this functionality should be part of the standard PSCI/SMC implementation. Currently u-boot only support standard PSCI call which is: ---------------------------------------------- | 0x84000000-0x8400001F | PSCI 32-bit calls | | 0xC4000000-0xC400001F | PSCI 64-bit calls | ----------------------------------------------
My implementation do not affect or alter the behavior of any existing standard PSCI calls.
Users can simply add their own platform specific services by using the service call range as below: ---------------------------------------------------- | 0xC2000000-0xC200FFFF | SMC64: SiP Service Calls | | 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls | ----------------------------------------------------
For complete service call ranges please refer to Table 6-2 in the ARM document.
On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang@intel.com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the standard power management and platform specific PSCI services. The purpose of this patchsets is to allow u-boot users to support their own platform specific secure SMC/PSCI services without making any SMC calls to ATF. This will benefit the users who need to use u- boot as the only bootloader and secure service provider without relying on ATF.
Below is a simple code example for adding your own PSCI functions:
#include <common.h> #include <errno.h> #include <asm/io.h> #include <asm/psci.h> #include <asm/secure.h>
#define PSCI_SMC64_FUNC_ID1 0xC2000001 #define PSCI_SMC64_FUNC_ID2 0xC2000002
static void __secure psci_plat_specific_func1(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 1 */ }
static void __secure psci_plat_specific_func2(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 2 */ }
DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, psci_plat_specific_func1); DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, psci_plat_specific_func2);
Ang, Chee Hong (1): ARMv8: Disable fwcall when PSCI is enabled
Chee Hong Ang (1): ARMv8: Allow SiP service extensions on top of PSCI code
Conceptually, I suppose this is a logical step. In specifics, would we want to make this functionality opt-in, or no, that doesn't make sense?
Allowing user to add platform specific service is part of SMC/PSCI specification as specifed in ARM document (Table 2-1): http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_ SMC_Calling_Convention.pdf
So I think this functionality should be part of the standard PSCI/SMC implementation. Currently u-boot only support standard PSCI call which is:
| 0x84000000-0x8400001F | PSCI 32-bit calls | | 0xC4000000-0xC400001F | PSCI 64-bit calls |
My implementation do not affect or alter the behavior of any existing standard PSCI calls.
Users can simply add their own platform specific services by using the service call range as below:
| 0xC2000000-0xC200FFFF | SMC64: SiP Service Calls | | 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
For complete service call ranges please refer to Table 6-2 in the ARM document.
OK, thanks!
On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang@intel.com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the standard power management and platform specific PSCI services. The purpose of this patchsets is to allow u-boot users to support their own platform specific secure SMC/PSCI services without making any SMC calls to ATF. This will benefit the users who need to use u- boot as the only bootloader and secure service provider without relying on ATF.
Below is a simple code example for adding your own PSCI functions:
#include <common.h> #include <errno.h> #include <asm/io.h> #include <asm/psci.h> #include <asm/secure.h>
#define PSCI_SMC64_FUNC_ID1 0xC2000001 #define PSCI_SMC64_FUNC_ID2 0xC2000002
static void __secure psci_plat_specific_func1(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 1 */ }
static void __secure psci_plat_specific_func2(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 2 */ }
DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, psci_plat_specific_func1); DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, psci_plat_specific_func2);
Ang, Chee Hong (1): ARMv8: Disable fwcall when PSCI is enabled
Chee Hong Ang (1): ARMv8: Allow SiP service extensions on top of PSCI code
Conceptually, I suppose this is a logical step. In specifics, would we want to make this functionality opt-in, or no, that doesn't make sense?
Allowing user to add platform specific service is part of SMC/PSCI specification as specifed in ARM document (Table 2-1): http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN00 28B_ SMC_Calling_Convention.pdf
So I think this functionality should be part of the standard PSCI/SMC implementation. Currently u-boot only support standard PSCI call which is:
0x84000000-0x8400001F | PSCI 32-bit calls | 0xC4000000-0xC400001F | PSCI 64-bit calls |
My implementation do not affect or alter the behavior of any existing standard PSCI calls.
Users can simply add their own platform specific services by using the service call range as below:
0xC2000000-0xC200FFFF | SMC64: SiP Service Calls | 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
For complete service call ranges please refer to Table 6-2 in the ARM document.
OK, thanks!
Any chance this enhancement get accepted ? Thanks.
On Wed, Mar 13, 2019 at 08:10:31AM +0000, Ang, Chee Hong wrote:
On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang@intel.com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the standard power management and platform specific PSCI services. The purpose of this patchsets is to allow u-boot users to support their own platform specific secure SMC/PSCI services without making any SMC calls to ATF. This will benefit the users who need to use u- boot as the only bootloader and secure service provider without relying on ATF.
Below is a simple code example for adding your own PSCI functions:
#include <common.h> #include <errno.h> #include <asm/io.h> #include <asm/psci.h> #include <asm/secure.h>
#define PSCI_SMC64_FUNC_ID1 0xC2000001 #define PSCI_SMC64_FUNC_ID2 0xC2000002
static void __secure psci_plat_specific_func1(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 1 */ }
static void __secure psci_plat_specific_func2(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 2 */ }
DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, psci_plat_specific_func1); DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, psci_plat_specific_func2);
Ang, Chee Hong (1): ARMv8: Disable fwcall when PSCI is enabled
Chee Hong Ang (1): ARMv8: Allow SiP service extensions on top of PSCI code
Conceptually, I suppose this is a logical step. In specifics, would we want to make this functionality opt-in, or no, that doesn't make sense?
Allowing user to add platform specific service is part of SMC/PSCI specification as specifed in ARM document (Table 2-1): http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN00 28B_ SMC_Calling_Convention.pdf
So I think this functionality should be part of the standard PSCI/SMC implementation. Currently u-boot only support standard PSCI call which is:
0x84000000-0x8400001F | PSCI 32-bit calls | 0xC4000000-0xC400001F | PSCI 64-bit calls |
My implementation do not affect or alter the behavior of any existing standard PSCI calls.
Users can simply add their own platform specific services by using the service call range as below:
0xC2000000-0xC200FFFF | SMC64: SiP Service Calls | 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
For complete service call ranges please refer to Table 6-2 in the ARM document.
OK, thanks!
Any chance this enhancement get accepted ? Thanks.
After the current release, if there's no further comments.
On Wed, 2019-03-13 at 12:01 -0400, Tom Rini wrote:
On Wed, Mar 13, 2019 at 08:10:31AM +0000, Ang, Chee Hong wrote:
On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang@intel .com wrote:
From: "Ang, Chee Hong" chee.hong.ang@intel.com
Currently u-boot only support standard PSCI functions for power management and lack of convenient method to allow the users to extend the PSCI functions to support platform specific services. Most of the u-boot users still rely on ATF (ARM Trusted Firmware) to handle the standard power management and platform specific PSCI services. The purpose of this patchsets is to allow u-boot users to support their own platform specific secure SMC/PSCI services without making any SMC calls to ATF. This will benefit the users who need to use u- boot as the only bootloader and secure service provider without relying on ATF.
Below is a simple code example for adding your own PSCI functions:
#include <common.h> #include <errno.h> #include <asm/io.h> #include <asm/psci.h> #include <asm/secure.h>
#define PSCI_SMC64_FUNC_ID1 0xC2000001 #define PSCI_SMC64_FUNC_ID2 0xC2000002
static void __secure psci_plat_specific_func1(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 1 */ }
static void __secure psci_plat_specific_func2(unsigned long function_id) { /* Your code for handling the SMC/PSCI platform specific service 2 */ }
DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1, psci_plat_specific_func1); DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2, psci_plat_specific_func2);
Ang, Chee Hong (1): ARMv8: Disable fwcall when PSCI is enabled
Chee Hong Ang (1): ARMv8: Allow SiP service extensions on top of PSCI code
Conceptually, I suppose this is a logical step. In specifics, would we want to make this functionality opt-in, or no, that doesn't make sense?
Allowing user to add platform specific service is part of SMC/PSCI specification as specifed in ARM document (Table 2-1): http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_D EN00 28B_ SMC_Calling_Convention.pdf
So I think this functionality should be part of the standard PSCI/SMC implementation. Currently u-boot only support standard PSCI call which is:
0x84000000-0x8400001F | PSCI 32-bit calls | 0xC4000000-0xC400001F | PSCI 64-bit calls |
My implementation do not affect or alter the behavior of any existing standard PSCI calls.
Users can simply add their own platform specific services by using the service call range as below:
0xC2000000-0xC200FFFF | SMC64: SiP Service Calls | 0xC3000000-0xC300FFFF | SMC64: OEM Service Calls |
For complete service call ranges please refer to Table 6-2 in the ARM document.
OK, thanks!
Any chance this enhancement get accepted ? Thanks.
After the current release, if there's no further comments.
Hi Tom, Is this patch being merged into mainline ? Or you have any further concern or comments ? Thanks.
participants (3)
-
Ang, Chee Hong -
chee.hong.ang＠intel.com
-
Tom Rini