[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[chee.hong.ang at intel.com]

From: "Ang, Chee Hong" <chee.hong.ang@intel.com>

New U-boot flow with ARM Trusted Firmware (ATF) support:
SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)

SPL loads the u-boot.itb which consist of:
1) u-boot-nodtb.bin (U-Boot Proper image)
2) u-boot.dtb (U-Boot Proper DTB)
3) bl31.bin (ATF-BL31 image)

Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)

Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
register accesses and mailbox communications with Secure Device Manager
(SDM).

Steps to build the U-Boot with ATF support:
1) Build U-Boot
2) Build ATF BL31
3) Copy ATF BL31 binary image into U-Boot's root folder
4) "make u-boot.itb" to generate u-boot.itb

These patchsets have dependency on:
[U-Boot,v8,00/19] Add Intel Agilex SoC support: 
https://patchwork.ozlabs.org/cover/1201373/

Chee Hong Ang (19):
  arm: socfpga: add fit source file for pack itb with ATF
  arm: socfpga: Add function for checking description from FIT image
  arm: socfpga: Load FIT image with ATF support
  arm: socfpga: Override 'lowlevel_init' to support ATF
  configs: socfpga: Enable FIT image loading with ATF support
  arm: socfpga: Disable "spin-table" method for booting Linux
  arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
  arm: socfpga: Define SMC function identifiers for PSCI SiP services
  arm: socfpga: Add secure register access helper functions for SoC
    64bits
  arm: socfpga: Secure register access for clock manager (SoC 64bits)
  arm: socfpga: Secure register access in PHY mode setup
  arm: socfpga: Secure register access for reading PLL frequency
  mmc: dwmmc: socfpga: Secure register access in MMC driver
  net: designware: socfpga: Secure register access in MAC driver
  arm: socfpga: Secure register access in Reset Manager driver
  arm: socfpga: stratix10: Initialize timer in SPL
  arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
  arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
    status
  sysreset: socfpga: Invoke PSCI call for COLD reset

Dalon Westergreen (1):
  configs: stratix10: Remove CONFIG_OF_EMBED

 arch/arm/mach-socfpga/Kconfig                      |   2 -
 arch/arm/mach-socfpga/Makefile                     |   4 +
 arch/arm/mach-socfpga/board.c                      |  10 +
 arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
 arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
 arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
 .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
 arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
 arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
 arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
 arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
 arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
 arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
 board/altera/soc64/its/fit_spl_atf.its             |  51 +++
 configs/socfpga_agilex_defconfig                   |   8 +-
 configs/socfpga_stratix10_defconfig                |   9 +-
 drivers/fpga/stratix10.c                           | 261 ++++----------
 drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
 drivers/net/dwmac_socfpga.c                        |   5 +-
 drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
 include/configs/socfpga_soc64_common.h             |   2 +-
 include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
 22 files changed, 732 insertions(+), 243 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
 create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
 create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
 create mode 100644 board/altera/soc64/its/fit_spl_atf.its
 create mode 100644 include/linux/intel-smc.h

-- 
2.7.4

[U-Boot] [PATCH v1 01/20] configs: stratix10: Remove CONFIG_OF_EMBED

[chee.hong.ang at intel.com]

From: Dalon Westergreen <dalon.westergreen@intel.com>

CONFIG_OF_EMBED was primarily enabled to support the stratix10
spl hex file requirements.  Since this option now produces a
warning during build, and the spl hex can be created using
alternate methods, CONFIG_OF_EMBED is no longer needed.

Signed-off-by: Dalon Westergreen <dalon.westergreen@intel.com>
Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 configs/socfpga_stratix10_defconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/configs/socfpga_stratix10_defconfig b/configs/socfpga_stratix10_defconfig
index e41588b..903d17b 100644
--- a/configs/socfpga_stratix10_defconfig
+++ b/configs/socfpga_stratix10_defconfig
@@ -28,7 +28,6 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
-CONFIG_OF_EMBED=y
 CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
-- 
2.7.4

[U-Boot] [PATCH v1 02/20] arm: socfpga: add fit source file for pack itb with ATF

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Generate a FIT image for Intel SOCFPGA(64bits) which
include U-boot proper, ATF and DTB for U-boot proper.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 board/altera/soc64/its/fit_spl_atf.its | 51 ++++++++++++++++++++++++++++++++++
 1 file changed, 51 insertions(+)
 create mode 100644 board/altera/soc64/its/fit_spl_atf.its

diff --git a/board/altera/soc64/its/fit_spl_atf.its b/board/altera/soc64/its/fit_spl_atf.its
new file mode 100644
index 0000000..bbc6a86
--- /dev/null
+++ b/board/altera/soc64/its/fit_spl_atf.its
@@ -0,0 +1,51 @@
+/*
+ * Copyright (C) 2019 Intel Corporation. All rights reserved
+ *
+ * SPDX-License-Identifier: GPL-2.0
+ */
+
+/dts-v1/;
+
+/ {
+	description = "FIT image with U-Boot proper, ATF bl31, DTB";
+	#address-cells = <1>;
+
+	images {
+		uboot {
+			description = "U-Boot (64-bit)";
+			data = /incbin/("../../../../u-boot-nodtb.bin");
+			type = "standalone";
+			os = "U-Boot";
+			arch = "arm64";
+			compression = "none";
+			load = <0x00200000>;
+		};
+		atf {
+			description = "ARM Trusted Firmware";
+			data = /incbin/("../../../../bl31.bin");
+			type = "firmware";
+			os = "arm-trusted-firmware";
+			arch = "arm64";
+			compression = "none";
+			load = <0x00001000>;
+			entry = <0x00001000>;
+		};
+
+		fdt {
+			description = "Stratix 10 flat device-tree";
+			data = /incbin/("../../../../u-boot.dtb");
+			type = "flat_dt";
+			compression = "none";
+		};
+	};
+
+	configurations {
+		default = "conf";
+		conf {
+			description = "Intel Stratix 10";
+			firmware = "atf";
+			loadables = "uboot";
+			fdt = "fdt";
+		};
+	};
+};
-- 
2.7.4

[U-Boot] [PATCH v1 03/20] arm: socfpga: Add function for checking description from FIT image

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Add board_fit_config_name_match() for matching board name with
device tree files in FIT image. This will ensure correct DTB
file is loaded for different board type. Currently, we are not
supporting multiple device tree files in FIT image therefore this
function basically do nothing for now.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/board.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index 7c8c05c..1830e2c 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -86,3 +86,13 @@ int g_dnl_board_usb_cable_connected(void)
 	return 1;
 }
 #endif
+
+#ifdef CONFIG_SPL_BUILD
+int board_fit_config_name_match(const char *name)
+{
+	/* Just empty function now - can't decide what to choose */
+	debug("%s: %s\n", __func__, name);
+
+	return 0;
+}
+#endif
-- 
2.7.4

[U-Boot] [PATCH v1 04/20] arm: socfpga: Load FIT image with ATF support

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Instead of loading u-boot proper image (u-boot.img), SPL
now loads FIT image (u-boot.itb) which includes u-boot
proper, ATF and u-boot proper's DTB.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 include/configs/socfpga_soc64_common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/configs/socfpga_soc64_common.h b/include/configs/socfpga_soc64_common.h
index 4b27483..28ab014 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -198,6 +198,6 @@ unsigned int cm_get_l4_sys_free_clk_hz(void);
 
 /* SPL SDMMC boot support */
 #define CONFIG_SYS_MMCSD_FS_BOOT_PARTITION	1
-#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME		"u-boot.img"
+#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME		"u-boot.itb"
 
 #endif	/* __CONFIG_SOCFPGA_SOC64_COMMON_H__ */
-- 
2.7.4

[U-Boot] [PATCH v1 05/20] arm: socfpga: Override 'lowlevel_init' to support ATF

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Override 'lowlevel_init' to support booting ATF from SPL
on Intel SOCFPGA (64bits) platforms.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/Makefile        |  2 ++
 arch/arm/mach-socfpga/lowlevel_init.S | 48 +++++++++++++++++++++++++++++++++++
 2 files changed, 50 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 418f543..3310e92 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -29,6 +29,7 @@ endif
 
 ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
 obj-y	+= clock_manager_s10.o
+obj-y	+= lowlevel_init.o
 obj-y	+= mailbox_s10.o
 obj-y	+= misc_s10.o
 obj-y	+= mmu-arm64_s10.o
@@ -41,6 +42,7 @@ endif
 
 ifdef CONFIG_TARGET_SOCFPGA_AGILEX
 obj-y	+= clock_manager_agilex.o
+obj-y	+= lowlevel_init.o
 obj-y	+= mailbox_s10.o
 obj-y	+= misc_s10.o
 obj-y	+= mmu-arm64_s10.o
diff --git a/arch/arm/mach-socfpga/lowlevel_init.S b/arch/arm/mach-socfpga/lowlevel_init.S
new file mode 100644
index 0000000..2fb2f3c
--- /dev/null
+++ b/arch/arm/mach-socfpga/lowlevel_init.S
@@ -0,0 +1,48 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2019, Intel Corporation
+ */
+
+#include <asm-offsets.h>
+#include <config.h>
+#include <linux/linkage.h>
+#include <asm/macro.h>
+
+ENTRY(lowlevel_init)
+	mov	x29, lr			/* Save LR */
+
+#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3)
+	branch_if_slave x0, 2f
+
+	ldr	x0, =GICD_BASE
+	bl	gic_init_secure
+#ifdef CONFIG_SPL_BUILD
+	b	2f
+#else
+	b	3f
+#endif
+
+#if defined(CONFIG_GICV3)
+	ldr	x0, =GICR_BASE
+	bl	gic_init_secure_percpu
+#elif defined(CONFIG_GICV2)
+	ldr	x0, =GICD_BASE
+	ldr	x1, =GICC_BASE
+	bl	gic_init_secure_percpu
+#endif
+#endif
+
+2:
+#ifdef CONFIG_SPL_BUILD
+	ldr	x4, =CPU_RELEASE_ADDR
+	ldr	x5, [x4]
+	cbz	x5, checkslavecpu
+	br	x5
+checkslavecpu:
+	branch_if_slave x0, 2b
+#endif
+
+3:
+	mov	lr, x29			/* Restore LR */
+	ret
+ENDPROC(lowlevel_init)
-- 
2.7.4

[U-Boot] [PATCH v1 06/20] configs: socfpga: Enable FIT image loading with ATF support

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

SPL now loads ATF (BL31), U-Boot proper and DTB from FIT
image. The new boot flow with ATF support is as follow:

SPL -> ATF (BL31) -> U-Boot proper -> OS (Linux)

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 configs/socfpga_agilex_defconfig    | 8 +++++++-
 configs/socfpga_stratix10_defconfig | 8 +++++++-
 2 files changed, 14 insertions(+), 2 deletions(-)

diff --git a/configs/socfpga_agilex_defconfig b/configs/socfpga_agilex_defconfig
index cdb9396..48c1bd6 100644
--- a/configs/socfpga_agilex_defconfig
+++ b/configs/socfpga_agilex_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SOCFPGA=y
-CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_TEXT_BASE=0x200000
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0x200
@@ -9,10 +9,16 @@ CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y
 CONFIG_IDENT_STRING="socfpga_agilex"
 CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_TEXT_BASE=0xFFE00000
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_SOURCE="board/altera/soc64/its/fit_spl_atf.its"
 CONFIG_BOOTDELAY=5
+CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x3c00000
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="SOCFPGA_AGILEX # "
 CONFIG_CMD_MEMTEST=y
diff --git a/configs/socfpga_stratix10_defconfig b/configs/socfpga_stratix10_defconfig
index 903d17b..c3d6e68 100644
--- a/configs/socfpga_stratix10_defconfig
+++ b/configs/socfpga_stratix10_defconfig
@@ -1,6 +1,6 @@
 CONFIG_ARM=y
 CONFIG_ARCH_SOCFPGA=y
-CONFIG_SYS_TEXT_BASE=0x1000
+CONFIG_SYS_TEXT_BASE=0x200000
 CONFIG_SYS_MALLOC_F_LEN=0x2000
 CONFIG_ENV_SIZE=0x1000
 CONFIG_ENV_OFFSET=0x200
@@ -9,9 +9,15 @@ CONFIG_TARGET_SOCFPGA_STRATIX10_SOCDK=y
 CONFIG_IDENT_STRING="socfpga_stratix10"
 CONFIG_SPL_FS_FAT=y
 CONFIG_SPL_TEXT_BASE=0xFFE00000
+CONFIG_FIT=y
+CONFIG_SPL_LOAD_FIT=y
+CONFIG_SPL_FIT_SOURCE="board/altera/soc64/its/fit_spl_atf.its"
 CONFIG_BOOTDELAY=5
+CONFIG_SPL_LEGACY_IMAGE_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SYS_SPI_U_BOOT_OFFS=0x3C00000
+CONFIG_SPL_ATF=y
+CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y
 CONFIG_HUSH_PARSER=y
 CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # "
 CONFIG_CMD_MEMTEST=y
-- 
2.7.4

[U-Boot] [PATCH v1 07/20] arm: socfpga: Disable "spin-table" method for booting Linux

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Standard PSCI function "CPU_ON" provided by ATF is now used
by Linux kernel to bring up the secondary CPUs to enable
SMP booting in Linux on SoC 64bits platform.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/Kconfig | 2 --
 1 file changed, 2 deletions(-)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 969698c..6549033 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -33,7 +33,6 @@ config TARGET_SOCFPGA_AGILEX
 	bool
 	select ARMV8_MULTIENTRY
 	select ARMV8_SET_SMPEN
-	select ARMV8_SPIN_TABLE
 	select CLK
 	select NCORE_CACHE
 	select SPL_CLK if SPL
@@ -77,7 +76,6 @@ config TARGET_SOCFPGA_STRATIX10
 	bool
 	select ARMV8_MULTIENTRY
 	select ARMV8_SET_SMPEN
-	select ARMV8_SPIN_TABLE
 	select FPGA_STRATIX10
 
 choice
-- 
2.7.4

[U-Boot] [PATCH v1 08/20] arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Allow U-Boot proper running in non-secure mode (EL2) to invoke
SMC call to ATF's PSCI runtime services such as System Manager's
registers access, 2nd phase bitstream FPGA reconfiguration,
Remote System Update (RSU) and etc.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/include/mach/misc.h |  3 +++
 arch/arm/mach-socfpga/misc_s10.c          | 26 ++++++++++++++++++++++++++
 2 files changed, 29 insertions(+)

diff --git a/arch/arm/mach-socfpga/include/mach/misc.h b/arch/arm/mach-socfpga/include/mach/misc.h
index f6de1cc..b939250 100644
--- a/arch/arm/mach-socfpga/include/mach/misc.h
+++ b/arch/arm/mach-socfpga/include/mach/misc.h
@@ -43,4 +43,7 @@ void do_bridge_reset(int enable, unsigned int mask);
 void socfpga_pl310_clear(void);
 void socfpga_get_managers_addr(void);
 
+#ifdef CONFIG_ARM_SMCCC
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len);
+#endif
 #endif /* _SOCFPGA_MISC_H_ */
diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index a3f5b43..2d63175 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -164,3 +164,29 @@ void do_bridge_reset(int enable, unsigned int mask)
 
 	socfpga_bridges_reset(enable);
 }
+
+#ifdef CONFIG_ARM_SMCCC
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len)
+{
+	int i;
+	struct pt_regs regs;
+
+	memset(&regs, 0, sizeof(regs));
+
+	regs.regs[0] = func_id;
+
+	if (args) {
+		for (i = 0; i < arg_len; i++)
+			regs.regs[i + 1] = args[i];
+	}
+
+	smc_call(&regs);
+
+	if (ret_arg) {
+		for (i = 0; i < ret_len; i++)
+			ret_arg[i] = regs.regs[i + 1];
+	}
+
+	return regs.regs[0];
+}
+#endif
-- 
2.7.4

[U-Boot] [PATCH v1 09/20] arm: socfpga: Define SMC function identifiers for PSCI SiP services

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

This header file defines the Secure Monitor Call (SMC) message
protocol for ATF (BL31) PSCI runtime services. It includes all
the PSCI SiP function identifiers for the secure runtime services
provided by ATF. The secure runtime services include System Manager's
registers access, 2nd phase bitstream FPGA reconfiguration, Remote
System Update (RSU) and etc.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 include/linux/intel-smc.h | 374 ++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 374 insertions(+)
 create mode 100644 include/linux/intel-smc.h

diff --git a/include/linux/intel-smc.h b/include/linux/intel-smc.h
new file mode 100644
index 0000000..27710ac
--- /dev/null
+++ b/include/linux/intel-smc.h
@@ -0,0 +1,374 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2017-2018, Intel Corporation
+ */
+
+#ifndef __INTEL_SMC_H
+#define __INTEL_SMC_H
+
+#include <linux/arm-smccc.h>
+#include <linux/bitops.h>
+
+/*
+ * This file defines the Secure Monitor Call (SMC) message protocol used for
+ * service layer driver in normal world (EL1) to communicate with secure
+ * monitor software in Secure Monitor Exception Level 3 (EL3).
+ *
+ * This file is shared with secure firmware (FW) which is out of kernel tree.
+ *
+ * An ARM SMC instruction takes a function identifier and up to 6 64-bit
+ * register values as arguments, and can return up to 4 64-bit register
+ * value. The operation of the secure monitor is determined by the parameter
+ * values passed in through registers.
+
+ * EL1 and EL3 communicates pointer as physical address rather than the
+ * virtual address.
+ */
+
+/*
+ * Functions specified by ARM SMC Calling convention:
+ *
+ * FAST call executes atomic operations, returns when the requested operation
+ * has completed.
+ * STD call starts a operation which can be preempted by a non-secure
+ * interrupt. The call can return before the requested operation has
+ * completed.
+ *
+ * a0..a7 is used as register names in the descriptions below, on arm32
+ * that translates to r0..r7 and on arm64 to w0..w7.
+ */
+
+#define INTEL_SIP_SMC_STD_CALL_VAL(func_num) \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_64, \
+	ARM_SMCCC_OWNER_SIP, (func_num))
+
+#define INTEL_SIP_SMC_FAST_CALL_VAL(func_num) \
+	ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \
+	ARM_SMCCC_OWNER_SIP, (func_num))
+
+/*
+ * Return values in INTEL_SIP_SMC_* call
+ *
+ * INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION:
+ * Secure monitor software doesn't recognize the request.
+ *
+ * INTEL_SIP_SMC_STATUS_OK:
+ * FPGA configuration completed successfully,
+ * In case of FPGA configuration write operation, it means secure monitor
+ * software can accept the next chunk of FPGA configuration data.
+ *
+ * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY:
+ * In case of FPGA configuration write operation, it means secure monitor
+ * software is still processing previous data & can't accept the next chunk
+ * of data. Service driver needs to issue
+ * INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE call to query the
+ * completed block(s).
+ *
+ * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR:
+ * There is error during the FPGA configuration process.
+ *
+ * INTEL_SIP_SMC_REG_ERROR:
+ * There is error during a read or write operation of the protected
+ * registers.
+ */
+#define INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION		0xFFFFFFFF
+#define INTEL_SIP_SMC_STATUS_OK				0x0
+#define INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY		0x1
+#define INTEL_SIP_SMC_FPGA_CONFIG_STATUS_REJECTED       0x2
+#define INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR		0x4
+#define INTEL_SIP_SMC_REG_ERROR				0x5
+#define INTEL_SIP_SMC_RSU_ERROR				0x7
+
+/*
+ * Request INTEL_SIP_SMC_FPGA_CONFIG_START
+ *
+ * Sync call used by service driver at EL1 to request the FPGA in EL3 to
+ * be prepare to receive a new configuration.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_FPGA_CONFIG_START.
+ * a1: flag for full or partial configuration
+ *    0 full reconfiguration.
+ *    1 partial reconfiguration.
+ * a2-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK, or INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR.
+ * a1-3: not used.
+ */
+#define INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START	1
+#define INTEL_SIP_SMC_FPGA_CONFIG_START \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START)
+
+/*
+ * Request INTEL_SIP_SMC_FPGA_CONFIG_WRITE
+ *
+ * Async call used by service driver at EL1 to provide FPGA configuration data
+ * to secure world.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_FPGA_CONFIG_WRITE.
+ * a1: 64bit physical address of the configuration data memory block
+ * a2: Size of configuration data block.
+ * a3-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY or
+ * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR.
+ * a1: 64bit physical address of 1st completed memory block if any completed
+ * block, otherwise zero value.
+ * a2: 64bit physical address of 2nd completed memory block if any completed
+ * block, otherwise zero value.
+ * a3: 64bit physical address of 3rd completed memory block if any completed
+ * block, otherwise zero value.
+ */
+#define INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_WRITE	2
+#define INTEL_SIP_SMC_FPGA_CONFIG_WRITE \
+	INTEL_SIP_SMC_STD_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_WRITE)
+
+/*
+ * Request INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE
+ *
+ * Sync call used by service driver at EL1 to track the completed write
+ * transactions. This request is called after INTEL_SIP_SMC_FPGA_CONFIG_WRITE
+ * call returns INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE.
+ * a1-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY or
+ * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR.
+ * a1: 64bit physical address of 1st completed memory block.
+ * a2: 64bit physical address of 2nd completed memory block if
+ * any completed block, otherwise zero value.
+ * a3: 64bit physical address of 3rd completed memory block if
+ * any completed block, otherwise zero value.
+ */
+#define INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_COMPLETED_WRITE	3
+#define INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE \
+INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_COMPLETED_WRITE)
+
+/*
+ * Request INTEL_SIP_SMC_FPGA_CONFIG_ISDONE
+ *
+ * Sync call used by service driver at EL1 to inform secure world that all
+ * data are sent, to check whether or not the secure world had completed
+ * the FPGA configuration process.
+ * Set 1 in 2nd argument (a1) to query the status of the first phase FPGA
+ * configuration by sending MBOX_CONFIG_STATUS to SDM. Otherwise this sync
+ * call always query the status of 2nd phase FPGA reconfiguration by sending
+ * MBOX_RECONFIG_STATUS to SDM.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_FPGA_CONFIG_ISDONE.
+ * a1: set 1 to send MBOX_CONFIG_STATUS otherwise send MBOX_RECONFIG_STATUS
+ * a2-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK, INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY or
+ * INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR.
+ * a1-3: not used.
+ */
+#define INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_ISDONE	4
+#define INTEL_SIP_SMC_FPGA_CONFIG_ISDONE \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_ISDONE)
+
+/*
+ * Request INTEL_SIP_SMC_FPGA_CONFIG_GET_MEM
+ *
+ * Sync call used by service driver at EL1 to query the physical address of
+ * memory block reserved by secure monitor software.
+ *
+ * Call register usage:
+ * a0:INTEL_SIP_SMC_FPGA_CONFIG_GET_MEM.
+ * a1-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK or INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR.
+ * a1: start of physical address of reserved memory block.
+ * a2: size of reserved memory block.
+ * a3: not used.
+ */
+#define INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_GET_MEM	5
+#define INTEL_SIP_SMC_FPGA_CONFIG_GET_MEM \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_GET_MEM)
+
+/*
+ * Request INTEL_SIP_SMC_REG_READ
+ *
+ * Read a protected register using SMCCC
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_REG_READ.
+ * a1: register address.
+ * a2-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK or INTEL_SIP_SMC_REG_ERROR.
+ * a1: Value in the register
+ * a2-3: not used.
+ */
+#define INTEL_SIP_SMC_FUNCID_REG_READ	7
+#define INTEL_SIP_SMC_REG_READ \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_REG_READ)
+
+/*
+ * Request INTEL_SIP_SMC_REG_WRITE
+ *
+ * Write a protected register using SMCCC
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_REG_WRITE.
+ * a1: register address
+ * a2: value to program into register.
+ * a3-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK or INTEL_SIP_SMC_REG_ERROR.
+ * a1-3: not used.
+ */
+#define INTEL_SIP_SMC_FUNCID_REG_WRITE	8
+#define INTEL_SIP_SMC_REG_WRITE \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_REG_WRITE)
+
+/*
+ * Request INTEL_SIP_SMC_FUNCID_REG_UPDATE
+ *
+ * Update one or more bits in a protected register using a
+ * read-modify-write operation.
+ *
+ * Call register usage:
+ * a0: INTEL_SIP_SMC_REG_UPDATE.
+ * a1: register address
+ * a2: Write Mask.
+ * a3: Value to write.
+ * a4-7: not used.
+ *
+ * Return status:
+ * a0: INTEL_SIP_SMC_STATUS_OK or INTEL_SIP_SMC_REG_ERROR.
+ * a1-3: Not used.
+ */
+#define INTEL_SIP_SMC_FUNCID_REG_UPDATE	9
+#define INTEL_SIP_SMC_REG_UPDATE \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_REG_UPDATE)
+
+/*
+ * Request INTEL_SIP_SMC_RSU_STATUS
+ *
+ * Sync call used by service driver at EL1 to query the RSU status
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_RSU_STATUS
+ * a1-7 not used
+ *
+ * Return status
+ * a0: Current Image
+ * a1: Last Failing Image
+ * a2: Version [width 32 bit] | State [width 32 bit]
+ * a3: Error details [width 32 bit] | Error location [width 32 bit]
+ *
+ * Or
+ *
+ * a0: INTEL_SIP_SMC_RSU_ERROR
+ */
+#define INTEL_SIP_SMC_FUNCID_RSU_STATUS	11
+#define INTEL_SIP_SMC_RSU_STATUS \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_RSU_STATUS)
+
+/*
+ * Request INTEL_SIP_SMC_RSU_UPDATE
+ *
+ * Sync call used by service driver at EL1 to tell you next reboot is RSU_UPDATE
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_RSU_UPDATE
+ * a1 64bit physical address of the configuration data memory in flash
+ * a2-7 not used
+ *
+ * Return status
+ * a0 INTEL_SIP_SMC_STATUS_OK
+ */
+#define INTEL_SIP_SMC_FUNCID_RSU_UPDATE	12
+#define INTEL_SIP_SMC_RSU_UPDATE \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_RSU_UPDATE)
+
+/*
+ * Request INTEL_SIP_SMC_ECC_DBE
+ *
+ * Sync call used by service driver at EL1 alert EL3 that a Double Bit
+ * ECC error has occurred.
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_ECC_DBE
+ * a1 SysManager Double Bit Error value
+ * a2-7 not used
+ *
+ * Return status
+ * a0 INTEL_SIP_SMC_STATUS_OK
+ */
+#define INTEL_SIP_SMC_FUNCID_ECC_DBE	13
+#define INTEL_SIP_SMC_ECC_DBE \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_ECC_DBE)
+
+/*
+ * Request INTEL_SIP_SMC_RSU_NOTIFY
+ *
+ * Sync call used by service driver at EL1 to report HPS software execution
+ * stage
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_RSU_NOTIFY
+ * a1 32bit HPS software execution stage
+ * a2-7 not used
+ *
+ * Return status
+ * a0 INTEL_SIP_SMC_STATUS_OK or INTEL_SIP_SMC_REG_ERROR.
+ */
+#define INTEL_SIP_SMC_FUNCID_RSU_NOTIFY	14
+#define INTEL_SIP_SMC_RSU_NOTIFY \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_RSU_NOTIFY)
+
+/*
+ * Request INTEL_SIP_SMC_RSU_RETRY_COUNTER
+ *
+ * Sync call used by service driver at EL1 to query the RSU retry counter
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_RSU_RETRY_COUNTER
+ * a1-7 not used
+ *
+ * Return status
+ * a0 INTEL_SIP_SMC_STATUS_OK or INTEL_SIP_SMC_RSU_ERROR.
+ * a1 retry counter
+ */
+#define INTEL_SIP_SMC_FUNCID_RSU_RETRY_COUNTER	15
+#define INTEL_SIP_SMC_RSU_RETRY_COUNTER \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_RSU_RETRY_COUNTER)
+
+/*
+ * Request INTEL_SIP_SMC_MBOX_SEND_CMD
+ *
+ * Sync call used by service driver at EL1 to send mailbox command to SDM
+ *
+ * Call register usage:
+ * a0 INTEL_SIP_SMC_MBOX_SEND_CMD
+ * a1 Mailbox command
+ * a2 64bit physical address pointer to command's arguments
+ * a3 Length of the argument
+ * a4 Urgent command enable = 1 / disable = 0
+ * a5 64bit physical address pointer to a buffer for receiving responses
+ * a6 Length of the buffer
+ *
+ * Return status
+ * a0 INTEL_SIP_SMC_STATUS_OK or INTEL_SIP_SMC_RSU_ERROR.
+ * a1 Status of mailbox response
+ * a2 64bit physical address pointer to a buffer for receiving responses
+ * a3 Received length in the buffer
+ */
+#define INTEL_SIP_SMC_FUNCID_MBOX_SEND_CMD     30
+#define INTEL_SIP_SMC_MBOX_SEND_CMD \
+	INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_MBOX_SEND_CMD)
+
+#endif
-- 
2.7.4

[U-Boot] [PATCH v1 10/20] arm: socfpga: Add secure register access helper functions for SoC 64bits

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

These secure register access functions allow U-Boot proper running
at EL2 (non-secure) to access System Manager's secure registers
by calling the ATF's PSCI runtime services (EL3/secure). If these
helper functions are called from secure mode (EL3), the helper
function will direct access the secure registers without calling
the ATF's PSCI runtime services.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/Makefile                     |  2 +
 .../mach-socfpga/include/mach/secure_reg_helper.h  | 20 +++++++
 arch/arm/mach-socfpga/secure_reg_helper.c          | 67 ++++++++++++++++++++++
 3 files changed, 89 insertions(+)
 create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
 create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 3310e92..4b46b65 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -34,6 +34,7 @@ obj-y	+= mailbox_s10.o
 obj-y	+= misc_s10.o
 obj-y	+= mmu-arm64_s10.o
 obj-y	+= reset_manager_s10.o
+obj-y	+= secure_reg_helper.o
 obj-y	+= system_manager_s10.o
 obj-y	+= timer_s10.o
 obj-y	+= wrap_pinmux_config_s10.o
@@ -47,6 +48,7 @@ obj-y	+= mailbox_s10.o
 obj-y	+= misc_s10.o
 obj-y	+= mmu-arm64_s10.o
 obj-y	+= reset_manager_s10.o
+obj-y	+= secure_reg_helper.o
 obj-y	+= system_manager_s10.o
 obj-y	+= timer_s10.o
 obj-y	+= wrap_pinmux_config_s10.o
diff --git a/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h b/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
new file mode 100644
index 0000000..0dc6534
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
@@ -0,0 +1,20 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2019 Intel Corporation <www.intel.com>
+ *
+ */
+
+#ifndef	_SECURE_REG_HELPER_H_
+#define	_SECURE_REG_HELPER_H_
+
+#ifdef CONFIG_ARM_SMCCC
+u32 socfpga_secure_reg_read32(phys_addr_t reg_addr);
+void socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr);
+void socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32 val);
+#else
+#define socfpga_secure_reg_read32	readl
+#define socfpga_secure_reg_write32	writel
+#define socfpga_secure_reg_update32	clrsetbits_le32
+#endif
+
+#endif /* _SECURE_REG_HELPER_H_ */
diff --git a/arch/arm/mach-socfpga/secure_reg_helper.c b/arch/arm/mach-socfpga/secure_reg_helper.c
new file mode 100644
index 0000000..2968fab
--- /dev/null
+++ b/arch/arm/mach-socfpga/secure_reg_helper.c
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2019 Intel Corporation <www.intel.com>
+ *
+ */
+
+#include <common.h>
+#include <asm/io.h>
+#include <asm/system.h>
+#include <asm/arch/misc.h>
+#include <linux/intel-smc.h>
+
+u32 socfpga_secure_reg_read32(phys_addr_t reg_addr)
+{
+	int ret;
+	u64 ret_arg;
+	u64 args[1];
+
+	if (current_el() == 3)
+		return readl(reg_addr);
+
+	args[0] = (u64)reg_addr;
+	ret = invoke_smc(INTEL_SIP_SMC_REG_READ, args, 1, &ret_arg, 1);
+	if (ret) {
+		/* SMC call return error */
+		hang();
+	}
+
+	return ret_arg;
+}
+
+void socfpga_secure_reg_write32(u32 val, phys_addr_t reg_addr)
+{
+	int ret;
+	u64 args[2];
+
+	if (current_el() == 3) {
+		writel(val, (u32 *)reg_addr);
+	} else {
+		args[0] = (u64)reg_addr;
+		args[1] = val;
+		ret = invoke_smc(INTEL_SIP_SMC_REG_WRITE, args, 2, NULL, 0);
+		if (ret) {
+			/* SMC call return error */
+			hang();
+		}
+	}
+}
+
+void socfpga_secure_reg_update32(phys_addr_t reg_addr, u32 mask, u32 val)
+{
+	int ret;
+	u64 args[3];
+
+	if (current_el() == 3) {
+		clrsetbits_le32(reg_addr, mask, val);
+	} else {
+		args[0] = (u64)reg_addr;
+		args[1] = mask;
+		args[2] = val;
+		ret = invoke_smc(INTEL_SIP_SMC_REG_UPDATE, args, 3, NULL, 0);
+		if (ret) {
+			/* SMC call return error */
+			hang();
+		}
+	}
+}
-- 
2.7.4

[U-Boot] [PATCH v1 11/20] arm: socfpga: Secure register access for clock manager (SoC 64bits)

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Allow clock manager driver to access the System Manager's Boot
Scratch Register 0 in non-secure mode (EL2) on SoC 64bits platform.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/clock_manager_agilex.c | 5 +++--
 arch/arm/mach-socfpga/clock_manager_s10.c    | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-socfpga/clock_manager_agilex.c b/arch/arm/mach-socfpga/clock_manager_agilex.c
index 791066d..3a2c80f 100644
--- a/arch/arm/mach-socfpga/clock_manager_agilex.c
+++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
@@ -11,6 +11,7 @@
 #include <asm/arch/system_manager.h>
 #include <asm/io.h>
 #include <dt-bindings/clock/agilex-clock.h>
+#include <asm/arch/secure_reg_helper.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -64,8 +65,8 @@ unsigned int cm_get_l4_sys_free_clk_hz(void)
 
 u32 cm_get_qspi_controller_clk_hz(void)
 {
-	return readl(socfpga_get_sysmgr_addr() +
-		     SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
+	return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+					 SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
 }
 
 void cm_print_clock_quick_summary(void)
diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c b/arch/arm/mach-socfpga/clock_manager_s10.c
index 05e4212..02578cc 100644
--- a/arch/arm/mach-socfpga/clock_manager_s10.c
+++ b/arch/arm/mach-socfpga/clock_manager_s10.c
@@ -9,6 +9,7 @@
 #include <asm/arch/clock_manager.h>
 #include <asm/arch/handoff_s10.h>
 #include <asm/arch/system_manager.h>
+#include <asm/arch/secure_reg_helper.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -385,8 +386,8 @@ unsigned int cm_get_l4_sp_clk_hz(void)
 
 unsigned int cm_get_qspi_controller_clk_hz(void)
 {
-	return readl(socfpga_get_sysmgr_addr() +
-		     SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
+	return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+					 SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
 }
 
 unsigned int cm_get_spi_controller_clk_hz(void)
-- 
2.7.4

[U-Boot] [PATCH v1 12/20] arm: socfpga: Secure register access in PHY mode setup

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Allow access to System Manager's EMAC control register from
non-secure mode during PHY mode setup.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/misc_s10.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index 2d63175..894753e 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -18,6 +18,7 @@
 #include <asm/pl310.h>
 #include <linux/libfdt.h>
 #include <asm/arch/mailbox_s10.h>
+#include <asm/arch/secure_reg_helper.h>
 
 #include <dt-bindings/reset/altr,rst-mgr-s10.h>
 
@@ -65,9 +66,9 @@ static u32 socfpga_phymode_setup(u32 gmac_index, const char *phymode)
 	else
 		return -EINVAL;
 
-	clrsetbits_le32(socfpga_get_sysmgr_addr() + SYSMGR_SOC64_EMAC0 +
-			gmac_index,
-			SYSMGR_EMACGRP_CTRL_PHYSEL_MASK, modereg);
+	socfpga_secure_reg_update32(socfpga_get_sysmgr_addr() +
+				    SYSMGR_SOC64_EMAC0 + gmac_index,
+				    SYSMGR_EMACGRP_CTRL_PHYSEL_MASK, modereg);
 
 	return 0;
 }
-- 
2.7.4

[U-Boot] [PATCH v1 13/20] arm: socfpga: Secure register access for reading PLL frequency

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Allow reading external oscillator and FPGA clock's frequency from
System Manager's Boot Scratch Register 1 and Boot Scratch Register 2
in non-secure mode (EL2) on SoC 64bits platform.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/wrap_pll_config_s10.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-socfpga/wrap_pll_config_s10.c b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
index 3da8579..7bd92d0 100644
--- a/arch/arm/mach-socfpga/wrap_pll_config_s10.c
+++ b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
@@ -9,6 +9,7 @@
 #include <asm/io.h>
 #include <asm/arch/handoff_s10.h>
 #include <asm/arch/system_manager.h>
+#include <asm/arch/secure_reg_helper.h>
 
 const struct cm_config * const cm_get_default_config(void)
 {
@@ -39,8 +40,8 @@ const unsigned int cm_get_osc_clk_hz(void)
 	writel(clock,
 	       socfpga_get_sysmgr_addr() + SYSMGR_SOC64_BOOT_SCRATCH_COLD1);
 #endif
-	return readl(socfpga_get_sysmgr_addr() +
-		     SYSMGR_SOC64_BOOT_SCRATCH_COLD1);
+	return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+					 SYSMGR_SOC64_BOOT_SCRATCH_COLD1);
 }
 
 const unsigned int cm_get_intosc_clk_hz(void)
@@ -56,6 +57,6 @@ const unsigned int cm_get_fpga_clk_hz(void)
 	writel(clock,
 	       socfpga_get_sysmgr_addr() + SYSMGR_SOC64_BOOT_SCRATCH_COLD2);
 #endif
-	return readl(socfpga_get_sysmgr_addr() +
-		     SYSMGR_SOC64_BOOT_SCRATCH_COLD2);
+	return socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+					 SYSMGR_SOC64_BOOT_SCRATCH_COLD2);
 }
-- 
2.7.4

[U-Boot] [PATCH v1 14/20] mmc: dwmmc: socfpga: Secure register access in MMC driver

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Allow MMC driver to access System Manager's SDMMC control
register in non-secure mode (EL2).

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 drivers/mmc/socfpga_dw_mmc.c | 7 +++++--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index 568a3e7..b856a0b 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -5,6 +5,7 @@
 
 #include <common.h>
 #include <asm/arch/clock_manager.h>
+#include <asm/arch/secure_reg_helper.h>
 #include <asm/arch/system_manager.h>
 #include <clk.h>
 #include <dm.h>
@@ -56,10 +57,12 @@ static void socfpga_dwmci_clksel(struct dwmci_host *host)
 
 	debug("%s: drvsel %d smplsel %d\n", __func__,
 	      priv->drvsel, priv->smplsel);
-	writel(sdmmc_mask, socfpga_get_sysmgr_addr() + SYSMGR_SDMMC);
+	socfpga_secure_reg_write32(sdmmc_mask, socfpga_get_sysmgr_addr() +
+				   SYSMGR_SDMMC);
 
 	debug("%s: SYSMGR_SDMMCGRP_CTRL_REG = 0x%x\n", __func__,
-		readl(socfpga_get_sysmgr_addr() + SYSMGR_SDMMC));
+	      socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+	      SYSMGR_SDMMC));
 
 	/* Enable SDMMC clock */
 	setbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
-- 
2.7.4

[U-Boot] [PATCH v1 15/20] net: designware: socfpga: Secure register access in MAC driver

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Allow MAC driver to access System Manager's EMAC control
registers in non-secure mode.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 drivers/net/dwmac_socfpga.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/net/dwmac_socfpga.c b/drivers/net/dwmac_socfpga.c
index b7bf5db..ae747ca 100644
--- a/drivers/net/dwmac_socfpga.c
+++ b/drivers/net/dwmac_socfpga.c
@@ -16,6 +16,7 @@
 #include "designware.h"
 
 #include <asm/arch/system_manager.h>
+#include <asm/arch/secure_reg_helper.h>
 
 struct dwmac_socfpga_platdata {
 	struct dw_eth_pdata	dw_eth_pdata;
@@ -96,8 +97,8 @@ static int dwmac_socfpga_probe(struct udevice *dev)
 	reset_assert_bulk(&reset_bulk);
 
 	modemask = SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << pdata->reg_shift;
-	clrsetbits_le32(pdata->phy_intf, modemask,
-			modereg << pdata->reg_shift);
+	socfpga_secure_reg_update32((phys_addr_t)pdata->phy_intf, modemask,
+				    modereg << pdata->reg_shift);
 
 	reset_release_bulk(&reset_bulk);
 
-- 
2.7.4

[U-Boot] [PATCH v1 16/20] arm: socfpga: Secure register access in Reset Manager driver

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Allow socfpga_bridges_reset() function in Reset Manager driver to
access System Manager's register in non-secure mode (EL2).

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/reset_manager_s10.c | 31 ++++++++++++++++++-------------
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/arch/arm/mach-socfpga/reset_manager_s10.c b/arch/arm/mach-socfpga/reset_manager_s10.c
index c743077..d03f121 100644
--- a/arch/arm/mach-socfpga/reset_manager_s10.c
+++ b/arch/arm/mach-socfpga/reset_manager_s10.c
@@ -7,6 +7,7 @@
 #include <common.h>
 #include <asm/io.h>
 #include <asm/arch/reset_manager.h>
+#include <asm/arch/secure_reg_helper.h>
 #include <asm/arch/system_manager.h>
 #include <dt-bindings/reset/altr,rst-mgr-s10.h>
 
@@ -56,34 +57,37 @@ void socfpga_bridges_reset(int enable)
 {
 	if (enable) {
 		/* clear idle request to all bridges */
-		setbits_le32(socfpga_get_sysmgr_addr() +
-			     SYSMGR_SOC64_NOC_IDLEREQ_CLR, ~0);
+		socfpga_secure_reg_update32(socfpga_get_sysmgr_addr() +
+					    SYSMGR_SOC64_NOC_IDLEREQ_CLR,
+					    ~0, ~0);
 
 		/* Release all bridges from reset state */
 		clrbits_le32(socfpga_get_rstmgr_addr() + RSTMGR_SOC64_BRGMODRST,
 			     ~0);
 
 		/* Poll until all idleack to 0 */
-		while (readl(socfpga_get_sysmgr_addr() +
-			     SYSMGR_SOC64_NOC_IDLEACK))
+		while (socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+						 SYSMGR_SOC64_NOC_IDLEACK))
 			;
 	} else {
 		/* set idle request to all bridges */
-		writel(~0,
-		       socfpga_get_sysmgr_addr() +
-		       SYSMGR_SOC64_NOC_IDLEREQ_SET);
+		socfpga_secure_reg_write32(~0, socfpga_get_sysmgr_addr() +
+					   SYSMGR_SOC64_NOC_IDLEREQ_SET);
 
 		/* Enable the NOC timeout */
-		writel(1, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_TIMEOUT);
+		socfpga_secure_reg_write32(1, socfpga_get_sysmgr_addr() +
+					   SYSMGR_SOC64_NOC_TIMEOUT);
 
 		/* Poll until all idleack to 1 */
-		while ((readl(socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_IDLEACK) ^
-			(SYSMGR_NOC_H2F_MSK | SYSMGR_NOC_LWH2F_MSK)))
+		while ((socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+		       SYSMGR_SOC64_NOC_IDLEACK) ^ (SYSMGR_NOC_H2F_MSK |
+		       SYSMGR_NOC_LWH2F_MSK)))
 			;
 
 		/* Poll until all idlestatus to 1 */
-		while ((readl(socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_IDLESTATUS) ^
-			(SYSMGR_NOC_H2F_MSK | SYSMGR_NOC_LWH2F_MSK)))
+		while ((socfpga_secure_reg_read32(socfpga_get_sysmgr_addr() +
+		       SYSMGR_SOC64_NOC_IDLESTATUS) ^ (SYSMGR_NOC_H2F_MSK |
+		       SYSMGR_NOC_LWH2F_MSK)))
 			;
 
 		/* Reset all bridges (except NOR DDR scheduler & F2S) */
@@ -92,7 +96,8 @@ void socfpga_bridges_reset(int enable)
 			       RSTMGR_BRGMODRST_FPGA2SOC_MASK));
 
 		/* Disable NOC timeout */
-		writel(0, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_TIMEOUT);
+		socfpga_secure_reg_write32(0, socfpga_get_sysmgr_addr() +
+					   SYSMGR_SOC64_NOC_TIMEOUT);
 	}
 }
 
-- 
2.7.4

[U-Boot] [PATCH v1 17/20] arm: socfpga: stratix10: Initialize timer in SPL

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Initialize timer in SPL running in secure mode (EL3)
and skip timer initialization in U-Boot proper running in
non-secure mode (EL2).

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/timer_s10.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-socfpga/timer_s10.c b/arch/arm/mach-socfpga/timer_s10.c
index 5723789..0fa56c3 100644
--- a/arch/arm/mach-socfpga/timer_s10.c
+++ b/arch/arm/mach-socfpga/timer_s10.c
@@ -13,6 +13,7 @@
  */
 int timer_init(void)
 {
+#ifdef CONFIG_SPL_BUILD
 	int enable = 0x3;	/* timer enable + output signal masked */
 	int loadval = ~0;
 
@@ -21,6 +22,6 @@ int timer_init(void)
 	/* enable processor pysical counter */
 	asm volatile("msr cntp_ctl_el0, %0" : : "r" (enable));
 	asm volatile("msr cntp_tval_el0, %0" : : "r" (loadval));
-
+#endif
 	return 0;
 }
-- 
2.7.4

[U-Boot] [PATCH v1 18/20] arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Refactor the FPGA recpnfiguration driver to call the ATF's PSCI
runtime services as it no longer handles the Secure Device Manager
(SDM) mailbox communication and FPGA reconfiguration logic.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 drivers/fpga/stratix10.c | 261 +++++++++++------------------------------------
 1 file changed, 59 insertions(+), 202 deletions(-)

diff --git a/drivers/fpga/stratix10.c b/drivers/fpga/stratix10.c
index d8e3250..44a427d 100644
--- a/drivers/fpga/stratix10.c
+++ b/drivers/fpga/stratix10.c
@@ -2,92 +2,16 @@
 /*
  * Copyright (C) 2018 Intel Corporation <www.intel.com>
  */
-
 #include <common.h>
 #include <altera.h>
-#include <asm/arch/mailbox_s10.h>
+#include <asm/arch/misc.h>
+#include <linux/intel-smc.h>
+
+#define BITSTREAM_CHUNK_SIZE				0xFFFF0
 
 #define RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS		60000
 #define RECONFIG_STATUS_INTERVAL_DELAY_US		1000000
-
-static const struct mbox_cfgstat_state {
-	int			err_no;
-	const char		*error_name;
-} mbox_cfgstat_state[] = {
-	{MBOX_CFGSTAT_STATE_IDLE, "FPGA in idle mode."},
-	{MBOX_CFGSTAT_STATE_CONFIG, "FPGA in config mode."},
-	{MBOX_CFGSTAT_STATE_FAILACK, "Acknowledgment failed!"},
-	{MBOX_CFGSTAT_STATE_ERROR_INVALID, "Invalid bitstream!"},
-	{MBOX_CFGSTAT_STATE_ERROR_CORRUPT, "Corrupted bitstream!"},
-	{MBOX_CFGSTAT_STATE_ERROR_AUTH, "Authentication failed!"},
-	{MBOX_CFGSTAT_STATE_ERROR_CORE_IO, "I/O error!"},
-	{MBOX_CFGSTAT_STATE_ERROR_HARDWARE, "Hardware error!"},
-	{MBOX_CFGSTAT_STATE_ERROR_FAKE, "Fake error!"},
-	{MBOX_CFGSTAT_STATE_ERROR_BOOT_INFO, "Error in boot info!"},
-	{MBOX_CFGSTAT_STATE_ERROR_QSPI_ERROR, "Error in QSPI!"},
-	{MBOX_RESP_ERROR, "Mailbox general error!"},
-	{-ETIMEDOUT, "I/O timeout error"},
-	{-1, "Unknown error!"}
-};
-
-#define MBOX_CFGSTAT_MAX ARRAY_SIZE(mbox_cfgstat_state)
-
-static const char *mbox_cfgstat_to_str(int err)
-{
-	int i;
-
-	for (i = 0; i < MBOX_CFGSTAT_MAX - 1; i++) {
-		if (mbox_cfgstat_state[i].err_no == err)
-			return mbox_cfgstat_state[i].error_name;
-	}
-
-	return mbox_cfgstat_state[MBOX_CFGSTAT_MAX - 1].error_name;
-}
-
-/*
- * Add the ongoing transaction's command ID into pending list and return
- * the command ID for next transfer.
- */
-static u8 add_transfer(u32 *xfer_pending_list, size_t list_size, u8 id)
-{
-	int i;
-
-	for (i = 0; i < list_size; i++) {
-		if (xfer_pending_list[i])
-			continue;
-		xfer_pending_list[i] = id;
-		debug("ID(%d) added to transaction pending list\n", id);
-		/*
-		 * Increment command ID for next transaction.
-		 * Valid command ID (4 bits) is from 1 to 15.
-		 */
-		id = (id % 15) + 1;
-		break;
-	}
-
-	return id;
-}
-
-/*
- * Check whether response ID match the command ID in the transfer
- * pending list. If a match is found in the transfer pending list,
- * it clears the transfer pending list and return the matched
- * command ID.
- */
-static int get_and_clr_transfer(u32 *xfer_pending_list, size_t list_size,
-				u8 id)
-{
-	int i;
-
-	for (i = 0; i < list_size; i++) {
-		if (id != xfer_pending_list[i])
-			continue;
-		xfer_pending_list[i] = 0;
-		return id;
-	}
-
-	return 0;
-}
+#define RECONFIG_STATUS_POLL_RETRY_MAX			100
 
 /*
  * Polling the FPGA configuration status.
@@ -99,11 +23,13 @@ static int reconfig_status_polling_resp(void)
 	unsigned long start = get_timer(0);
 
 	while (1) {
-		ret = mbox_get_fpga_config_status(MBOX_RECONFIG_STATUS);
+		ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE, NULL, 0,
+				 NULL, 0);
+
 		if (!ret)
 			return 0;	/* configuration success */
 
-		if (ret != MBOX_CFGSTAT_STATE_CONFIG)
+		if (ret != INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY)
 			return ret;
 
 		if (get_timer(start) > RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS)
@@ -116,125 +42,59 @@ static int reconfig_status_polling_resp(void)
 	return -ETIMEDOUT;
 }
 
-static u32 get_resp_hdr(u32 *r_index, u32 *w_index, u32 *resp_count,
-			u32 *resp_buf, u32 buf_size, u32 client_id)
-{
-	u32 buf[MBOX_RESP_BUFFER_SIZE];
-	u32 mbox_hdr;
-	u32 resp_len;
-	u32 hdr_len;
-	u32 i;
-
-	if (*resp_count < buf_size) {
-		u32 rcv_len_max = buf_size - *resp_count;
-
-		if (rcv_len_max > MBOX_RESP_BUFFER_SIZE)
-			rcv_len_max = MBOX_RESP_BUFFER_SIZE;
-		resp_len = mbox_rcv_resp(buf, rcv_len_max);
-
-		for (i = 0; i < resp_len; i++) {
-			resp_buf[(*w_index)++] = buf[i];
-			*w_index %= buf_size;
-			(*resp_count)++;
-		}
-	}
-
-	/* No response in buffer */
-	if (*resp_count == 0)
-		return 0;
-
-	mbox_hdr = resp_buf[*r_index];
-
-	hdr_len = MBOX_RESP_LEN_GET(mbox_hdr);
-
-	/* Insufficient header length to return a mailbox header */
-	if ((*resp_count - 1) < hdr_len)
-		return 0;
-
-	*r_index += (hdr_len + 1);
-	*r_index %= buf_size;
-	*resp_count -= (hdr_len + 1);
-
-	/* Make sure response belongs to us */
-	if (MBOX_RESP_CLIENT_GET(mbox_hdr) != client_id)
-		return 0;
-
-	return mbox_hdr;
-}
-
-/* Send bit stream data to SDM via RECONFIG_DATA mailbox command */
-static int send_reconfig_data(const void *rbf_data, size_t rbf_size,
-			      u32 xfer_max, u32 buf_size_max)
+static int send_bistream(const void *rbf_data, size_t rbf_size)
 {
-	u32 response_buffer[MBOX_RESP_BUFFER_SIZE];
-	u32 xfer_pending[MBOX_RESP_BUFFER_SIZE];
-	u32 resp_rindex = 0;
-	u32 resp_windex = 0;
-	u32 resp_count = 0;
+	int i;
+	u64 res_buf[3];
+	u64 args[2];
 	u32 xfer_count = 0;
-	int resp_err = 0;
-	u8 cmd_id = 1;
-	u32 args[3];
-	int ret;
-
-	debug("SDM xfer_max = %d\n", xfer_max);
-	debug("SDM buf_size_max = %x\n\n", buf_size_max);
-
-	memset(xfer_pending, 0, sizeof(xfer_pending));
+	int ret, wr_ret = 0, retry = 0;
+	size_t buf_size = (rbf_size > BITSTREAM_CHUNK_SIZE) ?
+				BITSTREAM_CHUNK_SIZE : rbf_size;
 
 	while (rbf_size || xfer_count) {
-		if (!resp_err && rbf_size && xfer_count < xfer_max) {
-			args[0] = MBOX_ARG_DESC_COUNT(1);
-			args[1] = (u64)rbf_data;
-			if (rbf_size >= buf_size_max) {
-				args[2] = buf_size_max;
-				rbf_size -= buf_size_max;
-				rbf_data += buf_size_max;
-			} else {
-				args[2] = (u64)rbf_size;
-				rbf_size = 0;
-			}
+		if (!wr_ret && rbf_size) {
+			args[0] = (u64)rbf_data;
+			args[1] = buf_size;
+			wr_ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_WRITE,
+					    args, 2, NULL, 0);
 
-			resp_err = mbox_send_cmd_only(cmd_id, MBOX_RECONFIG_DATA,
-						 MBOX_CMD_INDIRECT, 3, args);
-			if (!resp_err) {
-				xfer_count++;
-				cmd_id = add_transfer(xfer_pending,
-						      MBOX_RESP_BUFFER_SIZE,
-						      cmd_id);
-			}
-			puts(".");
-		} else {
-			u32 resp_hdr = get_resp_hdr(&resp_rindex, &resp_windex,
-						    &resp_count,
-						    response_buffer,
-						    MBOX_RESP_BUFFER_SIZE,
-						    MBOX_CLIENT_ID_UBOOT);
+			debug("wr_ret = %d, rbf_data = %p, buf_size = %08lx\n",
+			      wr_ret, rbf_data, buf_size);
 
-			/*
-			 * If no valid response header found or
-			 * non-zero length from RECONFIG_DATA
-			 */
-			if (!resp_hdr || MBOX_RESP_LEN_GET(resp_hdr))
+			if (wr_ret == INTEL_SIP_SMC_FPGA_CONFIG_STATUS_REJECTED)
 				continue;
 
-			/* Check for response's status */
-			if (!resp_err) {
-				resp_err = MBOX_RESP_ERR_GET(resp_hdr);
-				debug("Response error code: %08x\n", resp_err);
-			}
+			rbf_size -= buf_size;
+			rbf_data += buf_size;
 
-			ret = get_and_clr_transfer(xfer_pending,
-						   MBOX_RESP_BUFFER_SIZE,
-						   MBOX_RESP_ID_GET(resp_hdr));
-			if (ret) {
-				/* Claim and reuse the ID */
-				cmd_id = (u8)ret;
-				xfer_count--;
-			}
+			if (buf_size >= rbf_size)
+				buf_size = rbf_size;
 
-			if (resp_err && !xfer_count)
-				return resp_err;
+			xfer_count++;
+			puts(".");
+		} else {
+			ret = invoke_smc(
+				INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE,
+				NULL, 0, res_buf, 3);
+			if (!ret) {
+				for (i = 0; i < 3; i++) {
+					if (!res_buf[i])
+						break;
+					xfer_count--;
+					wr_ret = 0;
+					retry = 0;
+				}
+			} else if (ret !=
+				   INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY)
+				return ret;
+			else if (!xfer_count)
+				return INTEL_SIP_SMC_FPGA_CONFIG_STATUS_ERROR;
+
+			if (++retry >= RECONFIG_STATUS_POLL_RETRY_MAX)
+				return -ETIMEDOUT;
+
+			udelay(20000);
 		}
 	}
 
@@ -248,21 +108,19 @@ static int send_reconfig_data(const void *rbf_data, size_t rbf_size,
 int stratix10_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size)
 {
 	int ret;
-	u32 resp_len = 2;
-	u32 resp_buf[2];
 
-	debug("Sending MBOX_RECONFIG...\n");
-	ret = mbox_send_cmd(MBOX_ID_UBOOT, MBOX_RECONFIG, MBOX_CMD_DIRECT, 0,
-			    NULL, 0, &resp_len, resp_buf);
+	debug("Invoking FPGA_CONFIG_START...\n");
+
+	ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_START, NULL, 0, NULL, 0);
+
 	if (ret) {
 		puts("Failure in RECONFIG mailbox command!\n");
 		return ret;
 	}
 
-	ret = send_reconfig_data(rbf_data, rbf_size, resp_buf[0], resp_buf[1]);
+	ret = send_bistream(rbf_data, rbf_size);
 	if (ret) {
-		printf("RECONFIG_DATA error: %08x, %s\n", ret,
-		       mbox_cfgstat_to_str(ret));
+		printf("Error sending bitstream!\n");
 		return ret;
 	}
 
@@ -272,8 +130,7 @@ int stratix10_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size)
 	debug("Polling with MBOX_RECONFIG_STATUS...\n");
 	ret = reconfig_status_polling_resp();
 	if (ret) {
-		printf("RECONFIG_STATUS Error: %08x, %s\n", ret,
-		       mbox_cfgstat_to_str(ret));
+		printf("FPGA reconfiguration failed!");
 		return ret;
 	}
 
-- 
2.7.4

[U-Boot] [PATCH v1 19/20] arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config status

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Since SSBL is now running in non-secure mode (EL2), do_bridge_reset()
no longer send mailbox commands to SDM directly to query the status
of the FPGA configuration. Now, it invokes SMC service calls to ATF
(running at EL3) to perform the query.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 arch/arm/mach-socfpga/misc_s10.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-socfpga/misc_s10.c
index 894753e..2bef4ec 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_s10.c
@@ -17,6 +17,7 @@
 #include <asm/arch/misc.h>
 #include <asm/pl310.h>
 #include <linux/libfdt.h>
+#include <linux/intel-smc.h>
 #include <asm/arch/mailbox_s10.h>
 #include <asm/arch/secure_reg_helper.h>
 
@@ -154,10 +155,17 @@ void do_bridge_reset(int enable, unsigned int mask)
 {
 	/* Check FPGA status before bridge enable */
 	if (enable) {
-		int ret = mbox_get_fpga_config_status(MBOX_RECONFIG_STATUS);
+		u64 arg = 1;
 
-		if (ret && ret != MBOX_CFGSTAT_STATE_CONFIG)
-			ret = mbox_get_fpga_config_status(MBOX_CONFIG_STATUS);
+		/* Send MBOX_RECONFIG_STATUS to SDM */
+		int ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE, NULL, 0,
+				 NULL, 0);
+
+		if (ret && ret != INTEL_SIP_SMC_FPGA_CONFIG_STATUS_BUSY) {
+			/* Send MBOX_CONFIG_STATUS to SDM */
+			ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE,
+					 &arg, 1, NULL, 0);
+		}
 
 		if (ret)
 			return;
-- 
2.7.4

[U-Boot] [PATCH v1 20/20] sysreset: socfpga: Invoke PSCI call for COLD reset

[chee.hong.ang at intel.com]

From: Chee Hong Ang <chee.hong.ang@intel.com>

Instead of sending mailbox command to trigger COLD reset, sysreset driver
now call "SYSTEM_RESET" PSCI runtime service provided by ATF to trigger
COLD reset.

Signed-off-by: Chee Hong Ang <chee.hong.ang@intel.com>
---
 drivers/sysreset/sysreset_socfpga_s10.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/sysreset/sysreset_socfpga_s10.c b/drivers/sysreset/sysreset_socfpga_s10.c
index 9837aad..96cf61e 100644
--- a/drivers/sysreset/sysreset_socfpga_s10.c
+++ b/drivers/sysreset/sysreset_socfpga_s10.c
@@ -8,13 +8,11 @@
 #include <dm.h>
 #include <errno.h>
 #include <sysreset.h>
-#include <asm/arch/mailbox_s10.h>
 
 static int socfpga_sysreset_request(struct udevice *dev,
 				    enum sysreset_t type)
 {
-	puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
-	mbox_reset_cold();
+	psci_system_reset();
 	return -EINPROGRESS;
 }
 
-- 
2.7.4

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com> wrote:
>
> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
>
> New U-boot flow with ARM Trusted Firmware (ATF) support:
> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)

Adding support for ATF means that using U-Boot on Stratix10 and Agilex without
ATF keeps working, right?

>
> SPL loads the u-boot.itb which consist of:
> 1) u-boot-nodtb.bin (U-Boot Proper image)
> 2) u-boot.dtb (U-Boot Proper DTB)
> 3) bl31.bin (ATF-BL31 image)
>
> Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
>
> Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
> register accesses and mailbox communications with Secure Device Manager
> (SDM).
>
> Steps to build the U-Boot with ATF support:
> 1) Build U-Boot
> 2) Build ATF BL31
> 3) Copy ATF BL31 binary image into U-Boot's root folder
> 4) "make u-boot.itb" to generate u-boot.itb
>
> These patchsets have dependency on:
> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> https://patchwork.ozlabs.org/cover/1201373/
>
> Chee Hong Ang (19):
>   arm: socfpga: add fit source file for pack itb with ATF
>   arm: socfpga: Add function for checking description from FIT image
>   arm: socfpga: Load FIT image with ATF support
>   arm: socfpga: Override 'lowlevel_init' to support ATF
>   configs: socfpga: Enable FIT image loading with ATF support
>   arm: socfpga: Disable "spin-table" method for booting Linux
>   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
>   arm: socfpga: Define SMC function identifiers for PSCI SiP services
>   arm: socfpga: Add secure register access helper functions for SoC
>     64bits
>   arm: socfpga: Secure register access for clock manager (SoC 64bits)
>   arm: socfpga: Secure register access in PHY mode setup
>   arm: socfpga: Secure register access for reading PLL frequency
>   mmc: dwmmc: socfpga: Secure register access in MMC driver
>   net: designware: socfpga: Secure register access in MAC driver
>   arm: socfpga: Secure register access in Reset Manager driver
>   arm: socfpga: stratix10: Initialize timer in SPL
>   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
>   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
>     status
>   sysreset: socfpga: Invoke PSCI call for COLD reset
>
> Dalon Westergreen (1):
>   configs: stratix10: Remove CONFIG_OF_EMBED

This one is included in another series already:
https://patchwork.ozlabs.org/user/todo/uboot/?series=132976

Does this mean that one will be abandonen?
So the combined hex output part of that series is not required any more?

Regards,
Simon

>
>  arch/arm/mach-socfpga/Kconfig                      |   2 -
>  arch/arm/mach-socfpga/Makefile                     |   4 +
>  arch/arm/mach-socfpga/board.c                      |  10 +
>  arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
>  arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
>  arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
>  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
>  arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
>  arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
>  arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
>  arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
>  arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
>  arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
>  board/altera/soc64/its/fit_spl_atf.its             |  51 +++
>  configs/socfpga_agilex_defconfig                   |   8 +-
>  configs/socfpga_stratix10_defconfig                |   9 +-
>  drivers/fpga/stratix10.c                           | 261 ++++----------
>  drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
>  drivers/net/dwmac_socfpga.c                        |   5 +-
>  drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
>  include/configs/socfpga_soc64_common.h             |   2 +-
>  include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
>  22 files changed, 732 insertions(+), 243 deletions(-)
>  create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
>  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
>  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
>  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
>  create mode 100644 include/linux/intel-smc.h
>
> --
> 2.7.4
>

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com> wrote:
> >
> > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> >
> > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> 
> Adding support for ATF means that using U-Boot on Stratix10 and Agilex without
> ATF keeps working, right?
ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> >
> > SPL loads the u-boot.itb which consist of:
> > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > 2) u-boot.dtb (U-Boot Proper DTB)
> > 3) bl31.bin (ATF-BL31 image)
> >
> > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> >
> > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> > SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
> > register accesses and mailbox communications with Secure Device
> > Manager (SDM).
> >
> > Steps to build the U-Boot with ATF support:
> > 1) Build U-Boot
> > 2) Build ATF BL31
> > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > 4) "make u-boot.itb" to generate u-boot.itb
> >
> > These patchsets have dependency on:
> > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > https://patchwork.ozlabs.org/cover/1201373/
> >
> > Chee Hong Ang (19):
> >   arm: socfpga: add fit source file for pack itb with ATF
> >   arm: socfpga: Add function for checking description from FIT image
> >   arm: socfpga: Load FIT image with ATF support
> >   arm: socfpga: Override 'lowlevel_init' to support ATF
> >   configs: socfpga: Enable FIT image loading with ATF support
> >   arm: socfpga: Disable "spin-table" method for booting Linux
> >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> >   arm: socfpga: Add secure register access helper functions for SoC
> >     64bits
> >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> >   arm: socfpga: Secure register access in PHY mode setup
> >   arm: socfpga: Secure register access for reading PLL frequency
> >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> >   net: designware: socfpga: Secure register access in MAC driver
> >   arm: socfpga: Secure register access in Reset Manager driver
> >   arm: socfpga: stratix10: Initialize timer in SPL
> >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> >     status
> >   sysreset: socfpga: Invoke PSCI call for COLD reset
> >
> > Dalon Westergreen (1):
> >   configs: stratix10: Remove CONFIG_OF_EMBED
> 
> This one is included in another series already:
> https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> 
> Does this mean that one will be abandonen?
> So the combined hex output part of that series is not required any more?
> 
> Regards,
> Simon
> 
> >
> >  arch/arm/mach-socfpga/Kconfig                      |   2 -
> >  arch/arm/mach-socfpga/Makefile                     |   4 +
> >  arch/arm/mach-socfpga/board.c                      |  10 +
> >  arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> >  arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> >  arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> >  arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> >  arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> >  arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> >  arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> >  arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> >  arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> >  board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> >  configs/socfpga_agilex_defconfig                   |   8 +-
> >  configs/socfpga_stratix10_defconfig                |   9 +-
> >  drivers/fpga/stratix10.c                           | 261 ++++----------
> >  drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> >  drivers/net/dwmac_socfpga.c                        |   5 +-
> >  drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> >  include/configs/socfpga_soc64_common.h             |   2 +-
> >  include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
> >  22 files changed, 732 insertions(+), 243 deletions(-)  create mode
> > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> >  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> >  create mode 100644 include/linux/intel-smc.h
> >
> > --
> > 2.7.4
> >

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong <chee.hong.ang@intel.com> wrote:
>
> > On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com> wrote:
> > >
> > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > >
> > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> >
> > Adding support for ATF means that using U-Boot on Stratix10 and Agilex without
> > ATF keeps working, right?
> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.

Is there a technical requirement for that?

Regard,
Simon

> > >
> > > SPL loads the u-boot.itb which consist of:
> > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > 3) bl31.bin (ATF-BL31 image)
> > >
> > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > >
> > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> > > SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
> > > register accesses and mailbox communications with Secure Device
> > > Manager (SDM).
> > >
> > > Steps to build the U-Boot with ATF support:
> > > 1) Build U-Boot
> > > 2) Build ATF BL31
> > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > 4) "make u-boot.itb" to generate u-boot.itb
> > >
> > > These patchsets have dependency on:
> > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > https://patchwork.ozlabs.org/cover/1201373/
> > >
> > > Chee Hong Ang (19):
> > >   arm: socfpga: add fit source file for pack itb with ATF
> > >   arm: socfpga: Add function for checking description from FIT image
> > >   arm: socfpga: Load FIT image with ATF support
> > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > >   configs: socfpga: Enable FIT image loading with ATF support
> > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > >   arm: socfpga: Add secure register access helper functions for SoC
> > >     64bits
> > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > >   arm: socfpga: Secure register access in PHY mode setup
> > >   arm: socfpga: Secure register access for reading PLL frequency
> > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > >   net: designware: socfpga: Secure register access in MAC driver
> > >   arm: socfpga: Secure register access in Reset Manager driver
> > >   arm: socfpga: stratix10: Initialize timer in SPL
> > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> > >     status
> > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > >
> > > Dalon Westergreen (1):
> > >   configs: stratix10: Remove CONFIG_OF_EMBED
> >
> > This one is included in another series already:
> > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> >
> > Does this mean that one will be abandonen?
> > So the combined hex output part of that series is not required any more?
> >
> > Regards,
> > Simon
> >
> > >
> > >  arch/arm/mach-socfpga/Kconfig                      |   2 -
> > >  arch/arm/mach-socfpga/Makefile                     |   4 +
> > >  arch/arm/mach-socfpga/board.c                      |  10 +
> > >  arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > >  arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > >  arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > >  arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > >  arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > >  arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > >  arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > >  arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > >  arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > >  board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > >  configs/socfpga_agilex_defconfig                   |   8 +-
> > >  configs/socfpga_stratix10_defconfig                |   9 +-
> > >  drivers/fpga/stratix10.c                           | 261 ++++----------
> > >  drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > >  drivers/net/dwmac_socfpga.c                        |   5 +-
> > >  drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > >  include/configs/socfpga_soc64_common.h             |   2 +-
> > >  include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
> > >  22 files changed, 732 insertions(+), 243 deletions(-)  create mode
> > > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > >  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> > >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > >  create mode 100644 include/linux/intel-smc.h
> > >
> > > --
> > > 2.7.4
> > >

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong <chee.hong.ang@intel.com>
> wrote:
> >
> > > On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com> wrote:
> > > >
> > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > >
> > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> > >
> > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > Agilex without ATF keeps working, right?
> > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> 
> Is there a technical requirement for that?
Yes. We are using ATF to provide PSCI services such as system reset (COLD reset),
CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure services such as mailbox
communications with Secure Device Manager and accessing the System Manager registers
which are secure.
Without PSCI services, we are able to boot until U-Boot proper only. Currently, our U-Boot in
mainline doesn't boot to Linux due to these missing PSCI services.
Another reason is we have another boot flow which is using ATF + UEFI. So now we are
re-using the PSCI services from ATF so that now U-Boot and UEFI share the same ATF-BL31
image so that we don't have to reimplement another sets of PSCI services for U-Boot again.
This will greatly reduce our engineering efforts.
> 
> Regard,
> Simon
> 
> > > >
> > > > SPL loads the u-boot.itb which consist of:
> > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > 3) bl31.bin (ATF-BL31 image)
> > > >
> > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > >
> > > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> > > > SMC/PSCI calls provided by ATF to perform COLD reset, System
> > > > Manager register accesses and mailbox communications with Secure
> > > > Device Manager (SDM).
> > > >
> > > > Steps to build the U-Boot with ATF support:
> > > > 1) Build U-Boot
> > > > 2) Build ATF BL31
> > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > >
> > > > These patchsets have dependency on:
> > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > https://patchwork.ozlabs.org/cover/1201373/
> > > >
> > > > Chee Hong Ang (19):
> > > >   arm: socfpga: add fit source file for pack itb with ATF
> > > >   arm: socfpga: Add function for checking description from FIT image
> > > >   arm: socfpga: Load FIT image with ATF support
> > > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > > >   configs: socfpga: Enable FIT image loading with ATF support
> > > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > > >   arm: socfpga: Add secure register access helper functions for SoC
> > > >     64bits
> > > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > > >   arm: socfpga: Secure register access in PHY mode setup
> > > >   arm: socfpga: Secure register access for reading PLL frequency
> > > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > >   net: designware: socfpga: Secure register access in MAC driver
> > > >   arm: socfpga: Secure register access in Reset Manager driver
> > > >   arm: socfpga: stratix10: Initialize timer in SPL
> > > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> > > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> > > >     status
> > > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > > >
> > > > Dalon Westergreen (1):
> > > >   configs: stratix10: Remove CONFIG_OF_EMBED
> > >
> > > This one is included in another series already:
> > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > >
> > > Does this mean that one will be abandonen?
> > > So the combined hex output part of that series is not required any more?
> > >
> > > Regards,
> > > Simon
> > >
> > > >
> > > >  arch/arm/mach-socfpga/Kconfig                      |   2 -
> > > >  arch/arm/mach-socfpga/Makefile                     |   4 +
> > > >  arch/arm/mach-socfpga/board.c                      |  10 +
> > > >  arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > > >  arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > > >  arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > > >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > >  arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > > >  arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > > >  arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > > >  arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > > >  arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > > >  arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > > >  board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > > >  configs/socfpga_agilex_defconfig                   |   8 +-
> > > >  configs/socfpga_stratix10_defconfig                |   9 +-
> > > >  drivers/fpga/stratix10.c                           | 261 ++++----------
> > > >  drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > > >  drivers/net/dwmac_socfpga.c                        |   5 +-
> > > >  drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > > >  include/configs/socfpga_soc64_common.h             |   2 +-
> > > >  include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
> > > >  22 files changed, 732 insertions(+), 243 deletions(-)  create
> > > > mode
> > > > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > > >  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> > > >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > > >  create mode 100644 include/linux/intel-smc.h
> > > >
> > > > --
> > > > 2.7.4
> > > >

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > <chee.hong.ang@intel.com>
> > wrote:
> > >
> > > > On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com> wrote:
> > > > >
> > > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > >
> > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > > > > (EL1)
> > > >
> > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > Agilex without ATF keeps working, right?
> > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> >
> > Is there a technical requirement for that?
> Yes. We are using ATF to provide PSCI services such as system reset (COLD reset),
> CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure services such as
> mailbox communications with Secure Device Manager and accessing the System
> Manager registers which are secure.
> Without PSCI services, we are able to boot until U-Boot proper only. Currently,
> our U-Boot in mainline doesn't boot to Linux due to these missing PSCI services.
> Another reason is we have another boot flow which is using ATF + UEFI. So now
> we are re-using the PSCI services from ATF so that now U-Boot and UEFI share
> the same ATF-BL31 image so that we don't have to reimplement another sets of
> PSCI services for U-Boot again.
> This will greatly reduce our engineering efforts.
> >
> > Regard,
> > Simon
> >
> > > > >
> > > > > SPL loads the u-boot.itb which consist of:
> > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > 3) bl31.bin (ATF-BL31 image)
> > > > >
> > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > > >
> > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it
> > > > > invokes SMC/PSCI calls provided by ATF to perform COLD reset,
> > > > > System Manager register accesses and mailbox communications with
> > > > > Secure Device Manager (SDM).
> > > > >
> > > > > Steps to build the U-Boot with ATF support:
> > > > > 1) Build U-Boot
> > > > > 2) Build ATF BL31
> > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > > >
> > > > > These patchsets have dependency on:
> > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > > https://patchwork.ozlabs.org/cover/1201373/
> > > > >
> > > > > Chee Hong Ang (19):
> > > > >   arm: socfpga: add fit source file for pack itb with ATF
> > > > >   arm: socfpga: Add function for checking description from FIT image
> > > > >   arm: socfpga: Load FIT image with ATF support
> > > > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > > > >   configs: socfpga: Enable FIT image loading with ATF support
> > > > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > > > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > > > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > > > >   arm: socfpga: Add secure register access helper functions for SoC
> > > > >     64bits
> > > > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > > > >   arm: socfpga: Secure register access in PHY mode setup
> > > > >   arm: socfpga: Secure register access for reading PLL frequency
> > > > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > > >   net: designware: socfpga: Secure register access in MAC driver
> > > > >   arm: socfpga: Secure register access in Reset Manager driver
> > > > >   arm: socfpga: stratix10: Initialize timer in SPL
> > > > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> > > > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> > > > >     status
> > > > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > >
> > > > > Dalon Westergreen (1):
> > > > >   configs: stratix10: Remove CONFIG_OF_EMBED
> > > >
> > > > This one is included in another series already:
> > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > >
> > > > Does this mean that one will be abandonen?
> > > > So the combined hex output part of that series is not required any more?
Sorry, I missed this part.
Thanks for reminding the patches from Dalon.
These patchsets needed Dalon's previous patches to work. Especially the patch to remove
"CONFIG_OF_EMBED" from the defconfig file. I didn't know whether these patches will get
accepted to mainline or not. If you are basically OK with those patches from Dalon. I will remove
Dalon's patch from my patchsets when submitting the next patchsets.
> > > >
> > > > Regards,
> > > > Simon
> > > >
> > > > >
> > > > >  arch/arm/mach-socfpga/Kconfig                      |   2 -
> > > > >  arch/arm/mach-socfpga/Makefile                     |   4 +
> > > > >  arch/arm/mach-socfpga/board.c                      |  10 +
> > > > >  arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > > > >  arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > > > >  arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > > > >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > > >  arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > > > >  arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > > > >  arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > > > >  arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > > > >  arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > > > >  arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > > > >  board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > > > >  configs/socfpga_agilex_defconfig                   |   8 +-
> > > > >  configs/socfpga_stratix10_defconfig                |   9 +-
> > > > >  drivers/fpga/stratix10.c                           | 261 ++++----------
> > > > >  drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > > > >  drivers/net/dwmac_socfpga.c                        |   5 +-
> > > > >  drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > > > >  include/configs/socfpga_soc64_common.h             |   2 +-
> > > > >  include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
> > > > >  22 files changed, 732 insertions(+), 243 deletions(-)  create
> > > > > mode
> > > > > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > > >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > > > >  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> > > > >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > > > >  create mode 100644 include/linux/intel-smc.h
> > > > >
> > > > > --
> > > > > 2.7.4
> > > > >

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong <chee.hong.ang@intel.com> wrote:
>
> > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong <chee.hong.ang@intel.com>
> > wrote:
> > >
> > > > On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com> wrote:
> > > > >
> > > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > >
> > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> > > >
> > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > Agilex without ATF keeps working, right?
> > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> >
> > Is there a technical requirement for that?
> Yes. We are using ATF to provide PSCI services such as system reset (COLD reset),
> CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure services such as mailbox
> communications with Secure Device Manager and accessing the System Manager registers
> which are secure.
> Without PSCI services, we are able to boot until U-Boot proper only. Currently, our U-Boot in
> mainline doesn't boot to Linux due to these missing PSCI services.
> Another reason is we have another boot flow which is using ATF + UEFI. So now we are
> re-using the PSCI services from ATF so that now U-Boot and UEFI share the same ATF-BL31
> image so that we don't have to reimplement another sets of PSCI services for U-Boot again.
> This will greatly reduce our engineering efforts.

Hmm, thanks for the explanation.

I don't really think I can review this, given the lack of knowledge about that
PSCI stuff.

I must say it seems strange to me that U-Boot would have to rely on ATF though.
How do other platforms implement this? Shouldn't PSCI be generic or is it
really platform specific? If it's generic, isn't that a dupliation of code if
you implement e.g. a reset driver for Stratix10 but call into PSCI?

Regards,
Simon

> >
> > Regard,
> > Simon
> >
> > > > >
> > > > > SPL loads the u-boot.itb which consist of:
> > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > 3) bl31.bin (ATF-BL31 image)
> > > > >
> > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > > >
> > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> > > > > SMC/PSCI calls provided by ATF to perform COLD reset, System
> > > > > Manager register accesses and mailbox communications with Secure
> > > > > Device Manager (SDM).
> > > > >
> > > > > Steps to build the U-Boot with ATF support:
> > > > > 1) Build U-Boot
> > > > > 2) Build ATF BL31
> > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > > >
> > > > > These patchsets have dependency on:
> > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > > https://patchwork.ozlabs.org/cover/1201373/
> > > > >
> > > > > Chee Hong Ang (19):
> > > > >   arm: socfpga: add fit source file for pack itb with ATF
> > > > >   arm: socfpga: Add function for checking description from FIT image
> > > > >   arm: socfpga: Load FIT image with ATF support
> > > > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > > > >   configs: socfpga: Enable FIT image loading with ATF support
> > > > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > > > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > > > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > > > >   arm: socfpga: Add secure register access helper functions for SoC
> > > > >     64bits
> > > > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > > > >   arm: socfpga: Secure register access in PHY mode setup
> > > > >   arm: socfpga: Secure register access for reading PLL frequency
> > > > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > > >   net: designware: socfpga: Secure register access in MAC driver
> > > > >   arm: socfpga: Secure register access in Reset Manager driver
> > > > >   arm: socfpga: stratix10: Initialize timer in SPL
> > > > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> > > > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> > > > >     status
> > > > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > >
> > > > > Dalon Westergreen (1):
> > > > >   configs: stratix10: Remove CONFIG_OF_EMBED
> > > >
> > > > This one is included in another series already:
> > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > >
> > > > Does this mean that one will be abandonen?
> > > > So the combined hex output part of that series is not required any more?
> > > >
> > > > Regards,
> > > > Simon
> > > >
> > > > >
> > > > >  arch/arm/mach-socfpga/Kconfig                      |   2 -
> > > > >  arch/arm/mach-socfpga/Makefile                     |   4 +
> > > > >  arch/arm/mach-socfpga/board.c                      |  10 +
> > > > >  arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > > > >  arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > > > >  arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > > > >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > > >  arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > > > >  arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > > > >  arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > > > >  arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > > > >  arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > > > >  arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > > > >  board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > > > >  configs/socfpga_agilex_defconfig                   |   8 +-
> > > > >  configs/socfpga_stratix10_defconfig                |   9 +-
> > > > >  drivers/fpga/stratix10.c                           | 261 ++++----------
> > > > >  drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > > > >  drivers/net/dwmac_socfpga.c                        |   5 +-
> > > > >  drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > > > >  include/configs/socfpga_soc64_common.h             |   2 +-
> > > > >  include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
> > > > >  22 files changed, 732 insertions(+), 243 deletions(-)  create
> > > > > mode
> > > > > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > > >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > > > >  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> > > > >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > > > >  create mode 100644 include/linux/intel-smc.h
> > > > >
> > > > > --
> > > > > 2.7.4
> > > > >

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong <chee.hong.ang@intel.com>
> wrote:
> >
> > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > <chee.hong.ang@intel.com>
> > > wrote:
> > > >
> > > > > On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com> wrote:
> > > > > >
> > > > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > > >
> > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > > > > > (EL1)
> > > > >
> > > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > > Agilex without ATF keeps working, right?
> > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > >
> > > Is there a technical requirement for that?
> > Yes. We are using ATF to provide PSCI services such as system reset
> > (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure
> > services such as mailbox communications with Secure Device Manager and
> > accessing the System Manager registers which are secure.
> > Without PSCI services, we are able to boot until U-Boot proper only.
> > Currently, our U-Boot in mainline doesn't boot to Linux due to these missing
> PSCI services.
> > Another reason is we have another boot flow which is using ATF + UEFI.
> > So now we are re-using the PSCI services from ATF so that now U-Boot
> > and UEFI share the same ATF-BL31 image so that we don't have to
> reimplement another sets of PSCI services for U-Boot again.
> > This will greatly reduce our engineering efforts.
> 
> Hmm, thanks for the explanation.
> 
> I don't really think I can review this, given the lack of knowledge about that PSCI
> stuff.
I believe you can review it.
Have you briefly gone through the patches ? It has nothing to do with the PSCI stuff.
It just call the invoke_smc() function to call the ATF's PSCI functions. Those PSCI 
functions in ATF will do the rest.
> 
> I must say it seems strange to me that U-Boot would have to rely on ATF though.
> How do other platforms implement this? Shouldn't PSCI be generic or is it really
> platform specific? If it's generic, isn't that a dupliation of code if you implement
> e.g. a reset driver for Stratix10 but call into PSCI?
It's not strange at all.  A lot of U-Boot users already using this boot flow (ATF + U-Boot).
Yes. PSCI is a generic software interface which encapsulate the platform specific code.
Let me give you a good example in one of your sysreset driver you have implemented for S10.

#include <dm.h>
#include <errno.h>
#include <sysreset.h>
-#include <asm/arch/mailbox_s10.h>
 
 static int socfpga_sysreset_request(struct udevice *dev,
  				    enum sysreset_t type)
 {
 -	puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
 -	mbox_reset_cold();
 +	psci_system_reset();
  	return -EINPROGRESS;
 }
 
Above is the changes in one of my patchsets, the sysreset driver for S10
used to call mbox_reset_cold() to send mailbox message to Secure Device Manager
(SDM) to trigger COLD reset.
Calling 'mbox_reset_cold()' means you are calling platform specific code in
the sysreset driver to perform COLD reset. What if method to trigger COLD reset is changed in new platform ?
We have to change the sysreset driver code to support another new platform.
If this function call is replaced with "psci_system_reset()", we don't have to change the code
at all because all the platform specific code for COLD reset is now reside in ATF because this function
just invoke the PSCI function provided by ATF. You just have to replace the ATF binary with the new
implementation for the new platform. We can re-use this sysreset driver for
any platform that support ATF. In fact, it makes our U-Boot driver code more 'generic' because PSCI
interface stay the same. BTW, Linux also call PSCI functions to perform COLD reset. By using ATF,
U-Boot and Linux share the same COLD reset service provided by ATF. It actually reduce
code duplication.

I think you are aware of we are working to move the mailbox driver code away from arch to drivers.
You will see that a lot of those mailbox functions will be removed from the mailbox driver.
One of them is 'mbox_reset_cold()' which you called in sysreset driver for S10.

> Regards,
> Simon
> 
> > >
> > > Regard,
> > > Simon
> > >
> > > > > >
> > > > > > SPL loads the u-boot.itb which consist of:
> > > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > > 3) bl31.bin (ATF-BL31 image)
> > > > > >
> > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > > > >
> > > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it
> > > > > > invokes SMC/PSCI calls provided by ATF to perform COLD reset,
> > > > > > System Manager register accesses and mailbox communications
> > > > > > with Secure Device Manager (SDM).
> > > > > >
> > > > > > Steps to build the U-Boot with ATF support:
> > > > > > 1) Build U-Boot
> > > > > > 2) Build ATF BL31
> > > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > > > >
> > > > > > These patchsets have dependency on:
> > > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > > > https://patchwork.ozlabs.org/cover/1201373/
> > > > > >
> > > > > > Chee Hong Ang (19):
> > > > > >   arm: socfpga: add fit source file for pack itb with ATF
> > > > > >   arm: socfpga: Add function for checking description from FIT image
> > > > > >   arm: socfpga: Load FIT image with ATF support
> > > > > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > > > > >   configs: socfpga: Enable FIT image loading with ATF support
> > > > > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > > > > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > > > > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > > > > >   arm: socfpga: Add secure register access helper functions for SoC
> > > > > >     64bits
> > > > > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > > > > >   arm: socfpga: Secure register access in PHY mode setup
> > > > > >   arm: socfpga: Secure register access for reading PLL frequency
> > > > > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > > > >   net: designware: socfpga: Secure register access in MAC driver
> > > > > >   arm: socfpga: Secure register access in Reset Manager driver
> > > > > >   arm: socfpga: stratix10: Initialize timer in SPL
> > > > > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> > > > > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA
> config
> > > > > >     status
> > > > > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > > >
> > > > > > Dalon Westergreen (1):
> > > > > >   configs: stratix10: Remove CONFIG_OF_EMBED
> > > > >
> > > > > This one is included in another series already:
> > > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > > >
> > > > > Does this mean that one will be abandonen?
> > > > > So the combined hex output part of that series is not required any more?
> > > > >
> > > > > Regards,
> > > > > Simon
> > > > >
> > > > > >
> > > > > >  arch/arm/mach-socfpga/Kconfig                      |   2 -
> > > > > >  arch/arm/mach-socfpga/Makefile                     |   4 +
> > > > > >  arch/arm/mach-socfpga/board.c                      |  10 +
> > > > > >  arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > > > > >  arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > > > > >  arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > > > > >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > > > >  arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > > > > >  arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > > > > >  arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > > > > >  arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > > > > >  arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > > > > >  arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > > > > >  board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > > > > >  configs/socfpga_agilex_defconfig                   |   8 +-
> > > > > >  configs/socfpga_stratix10_defconfig                |   9 +-
> > > > > >  drivers/fpga/stratix10.c                           | 261 ++++----------
> > > > > >  drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > > > > >  drivers/net/dwmac_socfpga.c                        |   5 +-
> > > > > >  drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > > > > >  include/configs/socfpga_soc64_common.h             |   2 +-
> > > > > >  include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
> > > > > >  22 files changed, 732 insertions(+), 243 deletions(-)  create
> > > > > > mode
> > > > > > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > > > >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > > > > >  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> > > > > >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > > > > >  create mode 100644 include/linux/intel-smc.h
> > > > > >
> > > > > > --
> > > > > > 2.7.4
> > > > > >

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong <chee.hong.ang@intel.com> wrote:
>
> > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong <chee.hong.ang@intel.com>
> > wrote:
> > >
> > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > > <chee.hong.ang@intel.com>
> > > > wrote:
> > > > >
> > > > > > On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com> wrote:
> > > > > > >
> > > > > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > > > >
> > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > > > > > > (EL1)
> > > > > >
> > > > > > Adding support for ATF means that using U-Boot on Stratix10 and
> > > > > > Agilex without ATF keeps working, right?
> > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > > >
> > > > Is there a technical requirement for that?
> > > Yes. We are using ATF to provide PSCI services such as system reset
> > > (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and other secure
> > > services such as mailbox communications with Secure Device Manager and
> > > accessing the System Manager registers which are secure.
> > > Without PSCI services, we are able to boot until U-Boot proper only.
> > > Currently, our U-Boot in mainline doesn't boot to Linux due to these missing
> > PSCI services.
> > > Another reason is we have another boot flow which is using ATF + UEFI.
> > > So now we are re-using the PSCI services from ATF so that now U-Boot
> > > and UEFI share the same ATF-BL31 image so that we don't have to
> > reimplement another sets of PSCI services for U-Boot again.
> > > This will greatly reduce our engineering efforts.
> >
> > Hmm, thanks for the explanation.
> >
> > I don't really think I can review this, given the lack of knowledge about that PSCI
> > stuff.
> I believe you can review it.
> Have you briefly gone through the patches ? It has nothing to do with the PSCI stuff.
> It just call the invoke_smc() function to call the ATF's PSCI functions. Those PSCI
> functions in ATF will do the rest.

No, not yet. But see below.

> >
> > I must say it seems strange to me that U-Boot would have to rely on ATF though.
> > How do other platforms implement this? Shouldn't PSCI be generic or is it really
> > platform specific? If it's generic, isn't that a dupliation of code if you implement
> > e.g. a reset driver for Stratix10 but call into PSCI?
> It's not strange at all.  A lot of U-Boot users already using this boot flow (ATF + U-Boot).

Just because other boards do this doesn't mean it's not strange. Wasn't there
some kind of discussion around that PSCI stuff to make it available from U-Boot?
What's wrong with that way?

In my opinion, you're reducing functionality in U-Boot by making ATF a
requirement.

And by saying "I can't review this", I mean this looks like a
questionable way to me
and I'm not the one to say if a U-Boot board should go this way or not.

> Yes. PSCI is a generic software interface which encapsulate the platform specific code.
> Let me give you a good example in one of your sysreset driver you have implemented for S10.
>
> #include <dm.h>
> #include <errno.h>
> #include <sysreset.h>
> -#include <asm/arch/mailbox_s10.h>
>
>  static int socfpga_sysreset_request(struct udevice *dev,
>                                     enum sysreset_t type)
>  {
>  -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>  -      mbox_reset_cold();
>  +      psci_system_reset();

So this is not an socfgpa_s10 specific driver any more, right?

>         return -EINPROGRESS;
>  }
>
> Above is the changes in one of my patchsets, the sysreset driver for S10
> used to call mbox_reset_cold() to send mailbox message to Secure Device Manager
> (SDM) to trigger COLD reset.
> Calling 'mbox_reset_cold()' means you are calling platform specific code in
> the sysreset driver to perform COLD reset. What if method to trigger COLD reset is changed in new platform ?
> We have to change the sysreset driver code to support another new platform.
> If this function call is replaced with "psci_system_reset()", we don't have to change the code
> at all because all the platform specific code for COLD reset is now reside in ATF because this function
> just invoke the PSCI function provided by ATF. You just have to replace the ATF binary with the new
> implementation for the new platform. We can re-use this sysreset driver for
> any platform that support ATF. In fact, it makes our U-Boot driver code more 'generic' because PSCI
> interface stay the same. BTW, Linux also call PSCI functions to perform COLD reset. By using ATF,
> U-Boot and Linux share the same COLD reset service provided by ATF. It actually reduce
> code duplication.

What I meant was code duplication inside the U-Boot tree (having one
driver for each
arch but in effect all those drivers will call into the same psci function).

What you're doing is to move this code from U-Boot open U-Boot sources
to possibly
closed source ATF sources. But we've already had that discussion, I think...

Regards,
Simon

>
> I think you are aware of we are working to move the mailbox driver code away from arch to drivers.
> You will see that a lot of those mailbox functions will be removed from the mailbox driver.
> One of them is 'mbox_reset_cold()' which you called in sysreset driver for S10.
>
> > Regards,
> > Simon
> >
> > > >
> > > > Regard,
> > > > Simon
> > > >
> > > > > > >
> > > > > > > SPL loads the u-boot.itb which consist of:
> > > > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > > > 3) bl31.bin (ATF-BL31 image)
> > > > > > >
> > > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> > > > > > >
> > > > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it
> > > > > > > invokes SMC/PSCI calls provided by ATF to perform COLD reset,
> > > > > > > System Manager register accesses and mailbox communications
> > > > > > > with Secure Device Manager (SDM).
> > > > > > >
> > > > > > > Steps to build the U-Boot with ATF support:
> > > > > > > 1) Build U-Boot
> > > > > > > 2) Build ATF BL31
> > > > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > > > > >
> > > > > > > These patchsets have dependency on:
> > > > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > > > > https://patchwork.ozlabs.org/cover/1201373/
> > > > > > >
> > > > > > > Chee Hong Ang (19):
> > > > > > >   arm: socfpga: add fit source file for pack itb with ATF
> > > > > > >   arm: socfpga: Add function for checking description from FIT image
> > > > > > >   arm: socfpga: Load FIT image with ATF support
> > > > > > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > > > > > >   configs: socfpga: Enable FIT image loading with ATF support
> > > > > > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > > > > > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > > > > > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > > > > > >   arm: socfpga: Add secure register access helper functions for SoC
> > > > > > >     64bits
> > > > > > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > > > > > >   arm: socfpga: Secure register access in PHY mode setup
> > > > > > >   arm: socfpga: Secure register access for reading PLL frequency
> > > > > > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > > > > >   net: designware: socfpga: Secure register access in MAC driver
> > > > > > >   arm: socfpga: Secure register access in Reset Manager driver
> > > > > > >   arm: socfpga: stratix10: Initialize timer in SPL
> > > > > > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> > > > > > >   arm: socfpga: Bridge reset now invokes SMC calls to query FPGA
> > config
> > > > > > >     status
> > > > > > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > > > >
> > > > > > > Dalon Westergreen (1):
> > > > > > >   configs: stratix10: Remove CONFIG_OF_EMBED
> > > > > >
> > > > > > This one is included in another series already:
> > > > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > > > >
> > > > > > Does this mean that one will be abandonen?
> > > > > > So the combined hex output part of that series is not required any more?
> > > > > >
> > > > > > Regards,
> > > > > > Simon
> > > > > >
> > > > > > >
> > > > > > >  arch/arm/mach-socfpga/Kconfig                      |   2 -
> > > > > > >  arch/arm/mach-socfpga/Makefile                     |   4 +
> > > > > > >  arch/arm/mach-socfpga/board.c                      |  10 +
> > > > > > >  arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > > > > > >  arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > > > > > >  arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > > > > > >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > > > > >  arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > > > > > >  arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > > > > > >  arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > > > > > >  arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > > > > > >  arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > > > > > >  arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > > > > > >  board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > > > > > >  configs/socfpga_agilex_defconfig                   |   8 +-
> > > > > > >  configs/socfpga_stratix10_defconfig                |   9 +-
> > > > > > >  drivers/fpga/stratix10.c                           | 261 ++++----------
> > > > > > >  drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > > > > > >  drivers/net/dwmac_socfpga.c                        |   5 +-
> > > > > > >  drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > > > > > >  include/configs/socfpga_soc64_common.h             |   2 +-
> > > > > > >  include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
> > > > > > >  22 files changed, 732 insertions(+), 243 deletions(-)  create
> > > > > > > mode
> > > > > > > 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > > > > >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > > > > > >  create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> > > > > > >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > > > > > >  create mode 100644 include/linux/intel-smc.h
> > > > > > >
> > > > > > > --
> > > > > > > 2.7.4
> > > > > > >

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong <chee.hong.ang@intel.com>
> wrote:
> >
> > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > > <chee.hong.ang@intel.com>
> > > wrote:
> > > >
> > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > > > <chee.hong.ang@intel.com>
> > > > > wrote:
> > > > > >
> > > > > > > On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com>
> wrote:
> > > > > > > >
> > > > > > > > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > > > > >
> > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
> > > > > > > > Linux
> > > > > > > > (EL1)
> > > > > > >
> > > > > > > Adding support for ATF means that using U-Boot on Stratix10
> > > > > > > and Agilex without ATF keeps working, right?
> > > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > > > >
> > > > > Is there a technical requirement for that?
> > > > Yes. We are using ATF to provide PSCI services such as system
> > > > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> > > > other secure services such as mailbox communications with Secure
> > > > Device Manager and accessing the System Manager registers which are
> secure.
> > > > Without PSCI services, we are able to boot until U-Boot proper only.
> > > > Currently, our U-Boot in mainline doesn't boot to Linux due to
> > > > these missing
> > > PSCI services.
> > > > Another reason is we have another boot flow which is using ATF + UEFI.
> > > > So now we are re-using the PSCI services from ATF so that now
> > > > U-Boot and UEFI share the same ATF-BL31 image so that we don't
> > > > have to
> > > reimplement another sets of PSCI services for U-Boot again.
> > > > This will greatly reduce our engineering efforts.
> > >
> > > Hmm, thanks for the explanation.
> > >
> > > I don't really think I can review this, given the lack of knowledge
> > > about that PSCI stuff.
> > I believe you can review it.
> > Have you briefly gone through the patches ? It has nothing to do with the PSCI
> stuff.
> > It just call the invoke_smc() function to call the ATF's PSCI
> > functions. Those PSCI functions in ATF will do the rest.
> 
> No, not yet. But see below.
> 
> > >
> > > I must say it seems strange to me that U-Boot would have to rely on ATF
> though.
> > > How do other platforms implement this? Shouldn't PSCI be generic or
> > > is it really platform specific? If it's generic, isn't that a
> > > dupliation of code if you implement e.g. a reset driver for Stratix10 but call
> into PSCI?
> > It's not strange at all.  A lot of U-Boot users already using this boot flow (ATF +
> U-Boot).
> 
> Just because other boards do this doesn't mean it's not strange. Wasn't there
> some kind of discussion around that PSCI stuff to make it available from U-Boot?
> What's wrong with that way?
Our downstream U-Boot branch is already implemented the PSCI stuffs in U-Boot.
I tried to upstream my PSCI code:
https://lists.denx.de/pipermail/u-boot/2019-May/368822.html

Marek pointed me to this thread:
https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html

He had a point. He suggested maybe we can implement the PSCI stuffs in SPL/TPL. I took a look at the U-Boot code and found out
ATF is already well supported. Why don't we just use the PSCI code from ATF rather than re-implementing the PSCI code again in SPL/TPL.
It will save our effort to maintain two PSCI code in U-Boot and ATF while we already have the ATF PSCI implementation to support UEFI.
> 
> In my opinion, you're reducing functionality in U-Boot by making ATF a
> requirement.
> 
> And by saying "I can't review this", I mean this looks like a questionable way to
> me and I'm not the one to say if a U-Boot board should go this way or not.
I understand. Btw, who should I include to review this ?
> 
> > Yes. PSCI is a generic software interface which encapsulate the platform
> specific code.
> > Let me give you a good example in one of your sysreset driver you have
> implemented for S10.
> >
> > #include <dm.h>
> > #include <errno.h>
> > #include <sysreset.h>
> > -#include <asm/arch/mailbox_s10.h>
> >
> >  static int socfpga_sysreset_request(struct udevice *dev,
> >                                     enum sysreset_t type)  {
> >  -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> >  -      mbox_reset_cold();
> >  +      psci_system_reset();
> 
> So this is not an socfgpa_s10 specific driver any more, right?
> 
> >         return -EINPROGRESS;
> >  }
> >
> > Above is the changes in one of my patchsets, the sysreset driver for
> > S10 used to call mbox_reset_cold() to send mailbox message to Secure
> > Device Manager
> > (SDM) to trigger COLD reset.
> > Calling 'mbox_reset_cold()' means you are calling platform specific
> > code in the sysreset driver to perform COLD reset. What if method to trigger
> COLD reset is changed in new platform ?
> > We have to change the sysreset driver code to support another new platform.
> > If this function call is replaced with "psci_system_reset()", we don't
> > have to change the code at all because all the platform specific code
> > for COLD reset is now reside in ATF because this function just invoke
> > the PSCI function provided by ATF. You just have to replace the ATF
> > binary with the new implementation for the new platform. We can re-use
> > this sysreset driver for any platform that support ATF. In fact, it
> > makes our U-Boot driver code more 'generic' because PSCI interface
> > stay the same. BTW, Linux also call PSCI functions to perform COLD reset. By
> using ATF, U-Boot and Linux share the same COLD reset service provided by ATF.
> It actually reduce code duplication.
> 
> What I meant was code duplication inside the U-Boot tree (having one driver for
> each arch but in effect all those drivers will call into the same psci function).
Can different archs share the same driver if the driver code is common to those platforms ?

> What you're doing is to move this code from U-Boot open U-Boot sources to
> possibly closed source ATF sources. But we've already had that discussion, I
> think...
Our PSCI implementation in ATF is open source:
https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/intel/soc

> 
> Regards,
> Simon
> 
> >
> > I think you are aware of we are working to move the mailbox driver code away
> from arch to drivers.
> > You will see that a lot of those mailbox functions will be removed from the
> mailbox driver.
> > One of them is 'mbox_reset_cold()' which you called in sysreset driver for S10.
> >
> > > Regards,
> > > Simon
> > >
> > > > >
> > > > > Regard,
> > > > > Simon
> > > > >
> > > > > > > >
> > > > > > > > SPL loads the u-boot.itb which consist of:
> > > > > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > > > > 3) bl31.bin (ATF-BL31 image)
> > > > > > > >
> > > > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
> > > > > > > > Agilex)
> > > > > > > >
> > > > > > > > Now, U-Boot Proper is running in non-secure mode (EL2), it
> > > > > > > > invokes SMC/PSCI calls provided by ATF to perform COLD
> > > > > > > > reset, System Manager register accesses and mailbox
> > > > > > > > communications with Secure Device Manager (SDM).
> > > > > > > >
> > > > > > > > Steps to build the U-Boot with ATF support:
> > > > > > > > 1) Build U-Boot
> > > > > > > > 2) Build ATF BL31
> > > > > > > > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > > > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > > > > > >
> > > > > > > > These patchsets have dependency on:
> > > > > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > > > > > https://patchwork.ozlabs.org/cover/1201373/
> > > > > > > >
> > > > > > > > Chee Hong Ang (19):
> > > > > > > >   arm: socfpga: add fit source file for pack itb with ATF
> > > > > > > >   arm: socfpga: Add function for checking description from FIT
> image
> > > > > > > >   arm: socfpga: Load FIT image with ATF support
> > > > > > > >   arm: socfpga: Override 'lowlevel_init' to support ATF
> > > > > > > >   configs: socfpga: Enable FIT image loading with ATF support
> > > > > > > >   arm: socfpga: Disable "spin-table" method for booting Linux
> > > > > > > >   arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > > > > > > >   arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > > > > > > >   arm: socfpga: Add secure register access helper functions for SoC
> > > > > > > >     64bits
> > > > > > > >   arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > > > > > > >   arm: socfpga: Secure register access in PHY mode setup
> > > > > > > >   arm: socfpga: Secure register access for reading PLL frequency
> > > > > > > >   mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > > > > > >   net: designware: socfpga: Secure register access in MAC driver
> > > > > > > >   arm: socfpga: Secure register access in Reset Manager driver
> > > > > > > >   arm: socfpga: stratix10: Initialize timer in SPL
> > > > > > > >   arm: socfpga: stratix10: Refactor FPGA reconfig driver to support
> ATF
> > > > > > > >   arm: socfpga: Bridge reset now invokes SMC calls to
> > > > > > > > query FPGA
> > > config
> > > > > > > >     status
> > > > > > > >   sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > > > > >
> > > > > > > > Dalon Westergreen (1):
> > > > > > > >   configs: stratix10: Remove CONFIG_OF_EMBED
> > > > > > >
> > > > > > > This one is included in another series already:
> > > > > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > > > > >
> > > > > > > Does this mean that one will be abandonen?
> > > > > > > So the combined hex output part of that series is not required any
> more?
> > > > > > >
> > > > > > > Regards,
> > > > > > > Simon
> > > > > > >
> > > > > > > >
> > > > > > > >  arch/arm/mach-socfpga/Kconfig                      |   2 -
> > > > > > > >  arch/arm/mach-socfpga/Makefile                     |   4 +
> > > > > > > >  arch/arm/mach-socfpga/board.c                      |  10 +
> > > > > > > >  arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > > > > > > >  arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > > > > > > >  arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > > > > > > >  .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > > > > > >  arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > > > > > > >  arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > > > > > > >  arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > > > > > > >  arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > > > > > > >  arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > > > > > > >  arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > > > > > > >  board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > > > > > > >  configs/socfpga_agilex_defconfig                   |   8 +-
> > > > > > > >  configs/socfpga_stratix10_defconfig                |   9 +-
> > > > > > > >  drivers/fpga/stratix10.c                           | 261 ++++----------
> > > > > > > >  drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > > > > > > >  drivers/net/dwmac_socfpga.c                        |   5 +-
> > > > > > > >  drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > > > > > > >  include/configs/socfpga_soc64_common.h             |   2 +-
> > > > > > > >  include/linux/intel-smc.h                          | 374
> +++++++++++++++++++++
> > > > > > > >  22 files changed, 732 insertions(+), 243 deletions(-)
> > > > > > > > create mode
> > > > > > > > 100644
> > > > > > > > arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > > > > > >  create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > > > > > > >  create mode 100644
> > > > > > > > arch/arm/mach-socfpga/secure_reg_helper.c
> > > > > > > >  create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > > > > > > >  create mode 100644 include/linux/intel-smc.h
> > > > > > > >
> > > > > > > > --
> > > > > > > > 2.7.4
> > > > > > > >

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
>> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong <chee.hong.ang@intel.com>
>> wrote:
>>>
>>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
>>>> <chee.hong.ang@intel.com>
>>>> wrote:
>>>>>
>>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
>>>>>> <chee.hong.ang@intel.com>
>>>>>> wrote:
>>>>>>>
>>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com>
>> wrote:
>>>>>>>>>
>>>>>>>>> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
>>>>>>>>>
>>>>>>>>> New U-boot flow with ARM Trusted Firmware (ATF) support:
>>>>>>>>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
>>>>>>>>> Linux
>>>>>>>>> (EL1)
>>>>>>>>
>>>>>>>> Adding support for ATF means that using U-Boot on Stratix10
>>>>>>>> and Agilex without ATF keeps working, right?
>>>>>>> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
>>>>>>
>>>>>> Is there a technical requirement for that?
>>>>> Yes. We are using ATF to provide PSCI services such as system
>>>>> reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
>>>>> other secure services such as mailbox communications with Secure
>>>>> Device Manager and accessing the System Manager registers which are
>> secure.
>>>>> Without PSCI services, we are able to boot until U-Boot proper only.
>>>>> Currently, our U-Boot in mainline doesn't boot to Linux due to
>>>>> these missing
>>>> PSCI services.
>>>>> Another reason is we have another boot flow which is using ATF + UEFI.
>>>>> So now we are re-using the PSCI services from ATF so that now
>>>>> U-Boot and UEFI share the same ATF-BL31 image so that we don't
>>>>> have to
>>>> reimplement another sets of PSCI services for U-Boot again.
>>>>> This will greatly reduce our engineering efforts.
>>>>
>>>> Hmm, thanks for the explanation.
>>>>
>>>> I don't really think I can review this, given the lack of knowledge
>>>> about that PSCI stuff.
>>> I believe you can review it.
>>> Have you briefly gone through the patches ? It has nothing to do with the PSCI
>> stuff.
>>> It just call the invoke_smc() function to call the ATF's PSCI
>>> functions. Those PSCI functions in ATF will do the rest.
>>
>> No, not yet. But see below.
>>
>>>>
>>>> I must say it seems strange to me that U-Boot would have to rely on ATF
>> though.
>>>> How do other platforms implement this? Shouldn't PSCI be generic or
>>>> is it really platform specific? If it's generic, isn't that a
>>>> dupliation of code if you implement e.g. a reset driver for Stratix10 but call
>> into PSCI?
>>> It's not strange at all.  A lot of U-Boot users already using this boot flow (ATF +
>> U-Boot).
>>
>> Just because other boards do this doesn't mean it's not strange. Wasn't there
>> some kind of discussion around that PSCI stuff to make it available from U-Boot?
>> What's wrong with that way?
> Our downstream U-Boot branch is already implemented the PSCI stuffs in U-Boot.
> I tried to upstream my PSCI code:
> https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> 
> Marek pointed me to this thread:
> https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html
> 
> He had a point. He suggested maybe we can implement the PSCI stuffs in SPL/TPL. I took a look at the U-Boot code and found out
> ATF is already well supported. Why don't we just use the PSCI code from ATF rather than re-implementing the PSCI code again in SPL/TPL.
> It will save our effort to maintain two PSCI code in U-Boot and ATF while we already have the ATF PSCI implementation to support UEFI.

It seems to me we do have working code in U-Boot, what's missing is 
"only" to turn it ino PSCI?

And given U-Boot aims to support UEFI (kind of?), I'd rather argue: why 
do you need ATF at all?

Indeed, having the same code in both seems like double effort for 
maintenance.

>>
>> In my opinion, you're reducing functionality in U-Boot by making ATF a
>> requirement.
>>
>> And by saying "I can't review this", I mean this looks like a questionable way to
>> me and I'm not the one to say if a U-Boot board should go this way or not.
> I understand. Btw, who should I include to review this ?
>>
>>> Yes. PSCI is a generic software interface which encapsulate the platform
>> specific code.
>>> Let me give you a good example in one of your sysreset driver you have
>> implemented for S10.
>>>
>>> #include <dm.h>
>>> #include <errno.h>
>>> #include <sysreset.h>
>>> -#include <asm/arch/mailbox_s10.h>
>>>
>>>   static int socfpga_sysreset_request(struct udevice *dev,
>>>                                      enum sysreset_t type)  {
>>>   -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>>>   -      mbox_reset_cold();
>>>   +      psci_system_reset();

And coming back on this, the sysreset driver won't work in SPL any more, 
right?

>>
>> So this is not an socfgpa_s10 specific driver any more, right?
>>
>>>          return -EINPROGRESS;
>>>   }
>>>
>>> Above is the changes in one of my patchsets, the sysreset driver for
>>> S10 used to call mbox_reset_cold() to send mailbox message to Secure
>>> Device Manager
>>> (SDM) to trigger COLD reset.
>>> Calling 'mbox_reset_cold()' means you are calling platform specific
>>> code in the sysreset driver to perform COLD reset. What if method to trigger
>> COLD reset is changed in new platform ?
>>> We have to change the sysreset driver code to support another new platform.
>>> If this function call is replaced with "psci_system_reset()", we don't
>>> have to change the code at all because all the platform specific code
>>> for COLD reset is now reside in ATF because this function just invoke
>>> the PSCI function provided by ATF. You just have to replace the ATF
>>> binary with the new implementation for the new platform. We can re-use
>>> this sysreset driver for any platform that support ATF. In fact, it
>>> makes our U-Boot driver code more 'generic' because PSCI interface
>>> stay the same. BTW, Linux also call PSCI functions to perform COLD reset. By
>> using ATF, U-Boot and Linux share the same COLD reset service provided by ATF.
>> It actually reduce code duplication.
>>
>> What I meant was code duplication inside the U-Boot tree (having one driver for
>> each arch but in effect all those drivers will call into the same psci function).
> Can different archs share the same driver if the driver code is common to those platforms ?

I don't know why not. However, you then need a different way to select 
this driver: you clearly cannot use DT compatibles as this DT entry does 
not in any way stand for what you make the driver binding to it execute.

Instead, I would think of a way to make your PSCI-aware U-Boot proper 
use a generic PSCI-reset driver instead of the one matching the 
devicetree. And then keep in mind you still need the DT-matching driver 
in SPL. Thinking about it, having a driver in SPL you don't use in 
U-Boot proper is probably not done, yet, as well.

> 
>> What you're doing is to move this code from U-Boot open U-Boot sources to
>> possibly closed source ATF sources. But we've already had that discussion, I
>> think...
> Our PSCI implementation in ATF is open source:
> https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/intel/soc

Well, open source... Without implying anything: it's BSD, so it's open 
source as long as Intel wants it to be open source and nothing prevents 
the next manager from keeping additions or even bugfixes closed source. 
For whatever reasons might come.


Regards,
Simon

> 
>>
>> Regards,
>> Simon
>>
>>>
>>> I think you are aware of we are working to move the mailbox driver code away
>> from arch to drivers.
>>> You will see that a lot of those mailbox functions will be removed from the
>> mailbox driver.
>>> One of them is 'mbox_reset_cold()' which you called in sysreset driver for S10.
>>>
>>>> Regards,
>>>> Simon
>>>>
>>>>>>
>>>>>> Regard,
>>>>>> Simon
>>>>>>
>>>>>>>>>
>>>>>>>>> SPL loads the u-boot.itb which consist of:
>>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
>>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
>>>>>>>>> 3) bl31.bin (ATF-BL31 image)
>>>>>>>>>
>>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
>>>>>>>>> Agilex)
>>>>>>>>>
>>>>>>>>> Now, U-Boot Proper is running in non-secure mode (EL2), it
>>>>>>>>> invokes SMC/PSCI calls provided by ATF to perform COLD
>>>>>>>>> reset, System Manager register accesses and mailbox
>>>>>>>>> communications with Secure Device Manager (SDM).
>>>>>>>>>
>>>>>>>>> Steps to build the U-Boot with ATF support:
>>>>>>>>> 1) Build U-Boot
>>>>>>>>> 2) Build ATF BL31
>>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root folder
>>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
>>>>>>>>>
>>>>>>>>> These patchsets have dependency on:
>>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
>>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
>>>>>>>>>
>>>>>>>>> Chee Hong Ang (19):
>>>>>>>>>    arm: socfpga: add fit source file for pack itb with ATF
>>>>>>>>>    arm: socfpga: Add function for checking description from FIT
>> image
>>>>>>>>>    arm: socfpga: Load FIT image with ATF support
>>>>>>>>>    arm: socfpga: Override 'lowlevel_init' to support ATF
>>>>>>>>>    configs: socfpga: Enable FIT image loading with ATF support
>>>>>>>>>    arm: socfpga: Disable "spin-table" method for booting Linux
>>>>>>>>>    arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
>>>>>>>>>    arm: socfpga: Define SMC function identifiers for PSCI SiP services
>>>>>>>>>    arm: socfpga: Add secure register access helper functions for SoC
>>>>>>>>>      64bits
>>>>>>>>>    arm: socfpga: Secure register access for clock manager (SoC 64bits)
>>>>>>>>>    arm: socfpga: Secure register access in PHY mode setup
>>>>>>>>>    arm: socfpga: Secure register access for reading PLL frequency
>>>>>>>>>    mmc: dwmmc: socfpga: Secure register access in MMC driver
>>>>>>>>>    net: designware: socfpga: Secure register access in MAC driver
>>>>>>>>>    arm: socfpga: Secure register access in Reset Manager driver
>>>>>>>>>    arm: socfpga: stratix10: Initialize timer in SPL
>>>>>>>>>    arm: socfpga: stratix10: Refactor FPGA reconfig driver to support
>> ATF
>>>>>>>>>    arm: socfpga: Bridge reset now invokes SMC calls to
>>>>>>>>> query FPGA
>>>> config
>>>>>>>>>      status
>>>>>>>>>    sysreset: socfpga: Invoke PSCI call for COLD reset
>>>>>>>>>
>>>>>>>>> Dalon Westergreen (1):
>>>>>>>>>    configs: stratix10: Remove CONFIG_OF_EMBED
>>>>>>>>
>>>>>>>> This one is included in another series already:
>>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
>>>>>>>>
>>>>>>>> Does this mean that one will be abandonen?
>>>>>>>> So the combined hex output part of that series is not required any
>> more?
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Simon
>>>>>>>>
>>>>>>>>>
>>>>>>>>>   arch/arm/mach-socfpga/Kconfig                      |   2 -
>>>>>>>>>   arch/arm/mach-socfpga/Makefile                     |   4 +
>>>>>>>>>   arch/arm/mach-socfpga/board.c                      |  10 +
>>>>>>>>>   arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
>>>>>>>>>   arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
>>>>>>>>>   arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
>>>>>>>>>   .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
>>>>>>>>>   arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
>>>>>>>>>   arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
>>>>>>>>>   arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
>>>>>>>>>   arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
>>>>>>>>>   arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
>>>>>>>>>   arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
>>>>>>>>>   board/altera/soc64/its/fit_spl_atf.its             |  51 +++
>>>>>>>>>   configs/socfpga_agilex_defconfig                   |   8 +-
>>>>>>>>>   configs/socfpga_stratix10_defconfig                |   9 +-
>>>>>>>>>   drivers/fpga/stratix10.c                           | 261 ++++----------
>>>>>>>>>   drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
>>>>>>>>>   drivers/net/dwmac_socfpga.c                        |   5 +-
>>>>>>>>>   drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
>>>>>>>>>   include/configs/socfpga_soc64_common.h             |   2 +-
>>>>>>>>>   include/linux/intel-smc.h                          | 374
>> +++++++++++++++++++++
>>>>>>>>>   22 files changed, 732 insertions(+), 243 deletions(-)
>>>>>>>>> create mode
>>>>>>>>> 100644
>>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
>>>>>>>>>   create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
>>>>>>>>>   create mode 100644
>>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
>>>>>>>>>   create mode 100644 board/altera/soc64/its/fit_spl_atf.its
>>>>>>>>>   create mode 100644 include/linux/intel-smc.h
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> 2.7.4
>>>>>>>>>

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
> >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> >> <chee.hong.ang@intel.com>
> >> wrote:
> >>>
> >>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> >>>> <chee.hong.ang@intel.com>
> >>>> wrote:
> >>>>>
> >>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> >>>>>> <chee.hong.ang@intel.com>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com>
> >> wrote:
> >>>>>>>>>
> >>>>>>>>> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> >>>>>>>>>
> >>>>>>>>> New U-boot flow with ARM Trusted Firmware (ATF) support:
> >>>>>>>>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> >>>>>>>>> (EL1)
> >>>>>>>>
> >>>>>>>> Adding support for ATF means that using U-Boot on Stratix10 and
> >>>>>>>> Agilex without ATF keeps working, right?
> >>>>>>> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> >>>>>>
> >>>>>> Is there a technical requirement for that?
> >>>>> Yes. We are using ATF to provide PSCI services such as system
> >>>>> reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> >>>>> other secure services such as mailbox communications with Secure
> >>>>> Device Manager and accessing the System Manager registers which
> >>>>> are
> >> secure.
> >>>>> Without PSCI services, we are able to boot until U-Boot proper only.
> >>>>> Currently, our U-Boot in mainline doesn't boot to Linux due to
> >>>>> these missing
> >>>> PSCI services.
> >>>>> Another reason is we have another boot flow which is using ATF + UEFI.
> >>>>> So now we are re-using the PSCI services from ATF so that now
> >>>>> U-Boot and UEFI share the same ATF-BL31 image so that we don't
> >>>>> have to
> >>>> reimplement another sets of PSCI services for U-Boot again.
> >>>>> This will greatly reduce our engineering efforts.
> >>>>
> >>>> Hmm, thanks for the explanation.
> >>>>
> >>>> I don't really think I can review this, given the lack of knowledge
> >>>> about that PSCI stuff.
> >>> I believe you can review it.
> >>> Have you briefly gone through the patches ? It has nothing to do
> >>> with the PSCI
> >> stuff.
> >>> It just call the invoke_smc() function to call the ATF's PSCI
> >>> functions. Those PSCI functions in ATF will do the rest.
> >>
> >> No, not yet. But see below.
> >>
> >>>>
> >>>> I must say it seems strange to me that U-Boot would have to rely on
> >>>> ATF
> >> though.
> >>>> How do other platforms implement this? Shouldn't PSCI be generic or
> >>>> is it really platform specific? If it's generic, isn't that a
> >>>> dupliation of code if you implement e.g. a reset driver for
> >>>> Stratix10 but call
> >> into PSCI?
> >>> It's not strange at all.  A lot of U-Boot users already using this
> >>> boot flow (ATF +
> >> U-Boot).
> >>
> >> Just because other boards do this doesn't mean it's not strange.
> >> Wasn't there some kind of discussion around that PSCI stuff to make it
> available from U-Boot?
> >> What's wrong with that way?
> > Our downstream U-Boot branch is already implemented the PSCI stuffs in U-
> Boot.
> > I tried to upstream my PSCI code:
> > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> >
> > Marek pointed me to this thread:
> > https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html
> >
> > He had a point. He suggested maybe we can implement the PSCI stuffs in
> > SPL/TPL. I took a look at the U-Boot code and found out ATF is already well
> supported. Why don't we just use the PSCI code from ATF rather than re-
> implementing the PSCI code again in SPL/TPL.
> > It will save our effort to maintain two PSCI code in U-Boot and ATF while we
> already have the ATF PSCI implementation to support UEFI.
> 
> It seems to me we do have working code in U-Boot, what's missing is "only" to
> turn it ino PSCI?
Existing PSCI framework in U-Boot provide a way for us to turn the code into a PSCI handler
by just adding a '__secure' keyword before the function name. See:
https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga/mailbox_s10.c

Below is one of the functions that has 2 versions. One 'live' in a normal code section and another
one will be relocated to "__secure" section (for PSCI). You can see that 2 same functions
are duplicated for normal code section and PSCI section.

int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
		  u8 urgent, u32 *resp_buf_len, u32 *resp_buf)
{
	return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
			       resp_buf_len, resp_buf);
}

int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
				u32 *arg, u8 urgent, u32 *resp_buf_len,
				u32 *resp_buf)
{
	return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
			       resp_buf_len, resp_buf);
}

Those functions that are needed by PSCI runtime need to be duplicated for "__secure" section.
U-Boot Proper will copy and relocate the PSCI code in "__secure" section to a location before booting
Linux whereby they can be called by Linux. Using the PSCI framework, U-Boot proper is not able to call
any PSCI functions because PSCI code is not available until U-Boot proper ready to boot Linux.
So that's the reason we need to have 2 sets of code in U-Boot. One for SPL/U-Boot and another one for
PSCI section which is used by Linux.
Currently we have 2 implementations for FPGA reconfiguration driver in our downstream branch.
One for SPL/U-Boot and another one for Linux (PSCI). FPGA reconfiguration driver for U-Boot is already
upstreamed but I don't think I can get the FPGA reconfiguration for the PSCI part upstreamed.
They are 2 sets of different code for the same purpose. But that is what we have done in downstream
to make sure we can support Linux.

BTW, we are going to get rid of those duplicated code for PSCI after we switch to ATF boot flow.
> 
> And given U-Boot aims to support UEFI (kind of?), I'd rather argue: why do you
> need ATF at all?

No, U-Boot does not aim to support UEFI. We have 2 boot flows that don't mix:

1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux

2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux

These two boot flows now share the same code base (ATF-BL31).
> 
> Indeed, having the same code in both seems like double effort for maintenance.
> 
> >>
> >> In my opinion, you're reducing functionality in U-Boot by making ATF
> >> a requirement.
> >>
> >> And by saying "I can't review this", I mean this looks like a
> >> questionable way to me and I'm not the one to say if a U-Boot board should
> go this way or not.
> > I understand. Btw, who should I include to review this ?
> >>
> >>> Yes. PSCI is a generic software interface which encapsulate the
> >>> platform
> >> specific code.
> >>> Let me give you a good example in one of your sysreset driver you
> >>> have
> >> implemented for S10.
> >>>
> >>> #include <dm.h>
> >>> #include <errno.h>
> >>> #include <sysreset.h>
> >>> -#include <asm/arch/mailbox_s10.h>
> >>>
> >>>   static int socfpga_sysreset_request(struct udevice *dev,
> >>>                                      enum sysreset_t type)  {
> >>>   -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> >>>   -      mbox_reset_cold();
> >>>   +      psci_system_reset();
> 
> And coming back on this, the sysreset driver won't work in SPL any more, right?
You brought a very good point. See my comment at the bottom.
> 
> >>
> >> So this is not an socfgpa_s10 specific driver any more, right?
This driver code can be renamed to more generic name such as socfpga_soc64.c.
So that it can be shared by both Stratix10 and Agilex.
> >>
> >>>          return -EINPROGRESS;
> >>>   }
> >>>
> >>> Above is the changes in one of my patchsets, the sysreset driver for
> >>> S10 used to call mbox_reset_cold() to send mailbox message to Secure
> >>> Device Manager
> >>> (SDM) to trigger COLD reset.
> >>> Calling 'mbox_reset_cold()' means you are calling platform specific
> >>> code in the sysreset driver to perform COLD reset. What if method to
> >>> trigger
> >> COLD reset is changed in new platform ?
> >>> We have to change the sysreset driver code to support another new
> platform.
> >>> If this function call is replaced with "psci_system_reset()", we
> >>> don't have to change the code at all because all the platform
> >>> specific code for COLD reset is now reside in ATF because this
> >>> function just invoke the PSCI function provided by ATF. You just
> >>> have to replace the ATF binary with the new implementation for the
> >>> new platform. We can re-use this sysreset driver for any platform
> >>> that support ATF. In fact, it makes our U-Boot driver code more
> >>> 'generic' because PSCI interface stay the same. BTW, Linux also call
> >>> PSCI functions to perform COLD reset. By
> >> using ATF, U-Boot and Linux share the same COLD reset service provided by
> ATF.
> >> It actually reduce code duplication.
> >>
> >> What I meant was code duplication inside the U-Boot tree (having one
> >> driver for each arch but in effect all those drivers will call into the same psci
> function).
> > Can different archs share the same driver if the driver code is common to
> those platforms ?
> 
> I don't know why not. However, you then need a different way to select this
> driver: you clearly cannot use DT compatibles as this DT entry does not in any
> way stand for what you make the driver binding to it execute.
> 
> Instead, I would think of a way to make your PSCI-aware U-Boot proper use a
> generic PSCI-reset driver instead of the one matching the devicetree. And then
> keep in mind you still need the DT-matching driver in SPL. Thinking about it,
> having a driver in SPL you don't use in U-Boot proper is probably not done, yet,
> as well.
I don't have any problem with this approach (PSCI-reset driver) but it is very easy to support SPL and U-Boot proper
in the same driver by just checking the current exception level. Please take a look at the code below.

#include <dm.h>
#include <errno.h>
#include <sysreset.h>
#include <asm/arch/mailbox_s10.h>

static int socfpga_sysreset_request(struct udevice *dev,
                                     enum sysreset_t type)  {
-      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
+      If (current_el() == 3)
+                mbox_reset_cold();
+      else
+                psci_system_reset();
        return -EINPROGRESS;
}

We can make the sysreset driver compatible in SPL and U-Boot proper by just checking the current exception level.
If it's EL3 (secure), we knew SPL is running and otherwise U-Boot proper (EL2, non-secure) is running.
Or we can make a small generic function like below and call it from sysreset driver code:

void soc64_cold_reset(void)
{
      If (current_el() == 3)
                mbox_reset_cold();
      else
                psci_system_reset();
}

> 
> >
> >> What you're doing is to move this code from U-Boot open U-Boot
> >> sources to possibly closed source ATF sources. But we've already had
> >> that discussion, I think...
> > Our PSCI implementation in ATF is open source:
> > https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/
> > intel/soc
> 
> Well, open source... Without implying anything: it's BSD, so it's open source as
> long as Intel wants it to be open source and nothing prevents the next manager
> from keeping additions or even bugfixes closed source.
> For whatever reasons might come.
> 
> 
> Regards,
> Simon
> 
> >
> >>
> >> Regards,
> >> Simon
> >>
> >>>
> >>> I think you are aware of we are working to move the mailbox driver
> >>> code away
> >> from arch to drivers.
> >>> You will see that a lot of those mailbox functions will be removed
> >>> from the
> >> mailbox driver.
> >>> One of them is 'mbox_reset_cold()' which you called in sysreset driver for
> S10.
> >>>
> >>>> Regards,
> >>>> Simon
> >>>>
> >>>>>>
> >>>>>> Regard,
> >>>>>> Simon
> >>>>>>
> >>>>>>>>>
> >>>>>>>>> SPL loads the u-boot.itb which consist of:
> >>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
> >>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
> >>>>>>>>> 3) bl31.bin (ATF-BL31 image)
> >>>>>>>>>
> >>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
> >>>>>>>>> Agilex)
> >>>>>>>>>
> >>>>>>>>> Now, U-Boot Proper is running in non-secure mode (EL2), it
> >>>>>>>>> invokes SMC/PSCI calls provided by ATF to perform COLD reset,
> >>>>>>>>> System Manager register accesses and mailbox communications
> >>>>>>>>> with Secure Device Manager (SDM).
> >>>>>>>>>
> >>>>>>>>> Steps to build the U-Boot with ATF support:
> >>>>>>>>> 1) Build U-Boot
> >>>>>>>>> 2) Build ATF BL31
> >>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root folder
> >>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
> >>>>>>>>>
> >>>>>>>>> These patchsets have dependency on:
> >>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> >>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
> >>>>>>>>>
> >>>>>>>>> Chee Hong Ang (19):
> >>>>>>>>>    arm: socfpga: add fit source file for pack itb with ATF
> >>>>>>>>>    arm: socfpga: Add function for checking description from
> >>>>>>>>> FIT
> >> image
> >>>>>>>>>    arm: socfpga: Load FIT image with ATF support
> >>>>>>>>>    arm: socfpga: Override 'lowlevel_init' to support ATF
> >>>>>>>>>    configs: socfpga: Enable FIT image loading with ATF support
> >>>>>>>>>    arm: socfpga: Disable "spin-table" method for booting Linux
> >>>>>>>>>    arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> >>>>>>>>>    arm: socfpga: Define SMC function identifiers for PSCI SiP services
> >>>>>>>>>    arm: socfpga: Add secure register access helper functions for SoC
> >>>>>>>>>      64bits
> >>>>>>>>>    arm: socfpga: Secure register access for clock manager (SoC 64bits)
> >>>>>>>>>    arm: socfpga: Secure register access in PHY mode setup
> >>>>>>>>>    arm: socfpga: Secure register access for reading PLL frequency
> >>>>>>>>>    mmc: dwmmc: socfpga: Secure register access in MMC driver
> >>>>>>>>>    net: designware: socfpga: Secure register access in MAC driver
> >>>>>>>>>    arm: socfpga: Secure register access in Reset Manager driver
> >>>>>>>>>    arm: socfpga: stratix10: Initialize timer in SPL
> >>>>>>>>>    arm: socfpga: stratix10: Refactor FPGA reconfig driver to
> >>>>>>>>> support
> >> ATF
> >>>>>>>>>    arm: socfpga: Bridge reset now invokes SMC calls to query
> >>>>>>>>> FPGA
> >>>> config
> >>>>>>>>>      status
> >>>>>>>>>    sysreset: socfpga: Invoke PSCI call for COLD reset
> >>>>>>>>>
> >>>>>>>>> Dalon Westergreen (1):
> >>>>>>>>>    configs: stratix10: Remove CONFIG_OF_EMBED
> >>>>>>>>
> >>>>>>>> This one is included in another series already:
> >>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> >>>>>>>>
> >>>>>>>> Does this mean that one will be abandonen?
> >>>>>>>> So the combined hex output part of that series is not required
> >>>>>>>> any
> >> more?
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Simon
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>   arch/arm/mach-socfpga/Kconfig                      |   2 -
> >>>>>>>>>   arch/arm/mach-socfpga/Makefile                     |   4 +
> >>>>>>>>>   arch/arm/mach-socfpga/board.c                      |  10 +
> >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> >>>>>>>>>   arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> >>>>>>>>>   .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> >>>>>>>>>   arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> >>>>>>>>>   arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> >>>>>>>>>   arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> >>>>>>>>>   arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> >>>>>>>>>   arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> >>>>>>>>>   arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> >>>>>>>>>   board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> >>>>>>>>>   configs/socfpga_agilex_defconfig                   |   8 +-
> >>>>>>>>>   configs/socfpga_stratix10_defconfig                |   9 +-
> >>>>>>>>>   drivers/fpga/stratix10.c                           | 261 ++++----------
> >>>>>>>>>   drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> >>>>>>>>>   drivers/net/dwmac_socfpga.c                        |   5 +-
> >>>>>>>>>   drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> >>>>>>>>>   include/configs/socfpga_soc64_common.h             |   2 +-
> >>>>>>>>>   include/linux/intel-smc.h                          | 374
> >> +++++++++++++++++++++
> >>>>>>>>>   22 files changed, 732 insertions(+), 243 deletions(-) create
> >>>>>>>>> mode
> >>>>>>>>> 100644
> >>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> >>>>>>>>>   create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> >>>>>>>>>   create mode 100644
> >>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
> >>>>>>>>>   create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> >>>>>>>>>   create mode 100644 include/linux/intel-smc.h
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> 2.7.4
> >>>>>>>>>

[U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong <chee.hong.ang@intel.com> wrote:
>
> > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
> > >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> > >> <chee.hong.ang@intel.com>
> > >> wrote:
> > >>>
> > >>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > >>>> <chee.hong.ang@intel.com>
> > >>>> wrote:
> > >>>>>
> > >>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > >>>>>> <chee.hong.ang@intel.com>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com>
> > >> wrote:
> > >>>>>>>>>
> > >>>>>>>>> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > >>>>>>>>>
> > >>>>>>>>> New U-boot flow with ARM Trusted Firmware (ATF) support:
> > >>>>>>>>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux
> > >>>>>>>>> (EL1)
> > >>>>>>>>
> > >>>>>>>> Adding support for ATF means that using U-Boot on Stratix10 and
> > >>>>>>>> Agilex without ATF keeps working, right?
> > >>>>>>> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > >>>>>>
> > >>>>>> Is there a technical requirement for that?
> > >>>>> Yes. We are using ATF to provide PSCI services such as system
> > >>>>> reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> > >>>>> other secure services such as mailbox communications with Secure
> > >>>>> Device Manager and accessing the System Manager registers which
> > >>>>> are
> > >> secure.
> > >>>>> Without PSCI services, we are able to boot until U-Boot proper only.
> > >>>>> Currently, our U-Boot in mainline doesn't boot to Linux due to
> > >>>>> these missing
> > >>>> PSCI services.
> > >>>>> Another reason is we have another boot flow which is using ATF + UEFI.
> > >>>>> So now we are re-using the PSCI services from ATF so that now
> > >>>>> U-Boot and UEFI share the same ATF-BL31 image so that we don't
> > >>>>> have to
> > >>>> reimplement another sets of PSCI services for U-Boot again.
> > >>>>> This will greatly reduce our engineering efforts.
> > >>>>
> > >>>> Hmm, thanks for the explanation.
> > >>>>
> > >>>> I don't really think I can review this, given the lack of knowledge
> > >>>> about that PSCI stuff.
> > >>> I believe you can review it.
> > >>> Have you briefly gone through the patches ? It has nothing to do
> > >>> with the PSCI
> > >> stuff.
> > >>> It just call the invoke_smc() function to call the ATF's PSCI
> > >>> functions. Those PSCI functions in ATF will do the rest.
> > >>
> > >> No, not yet. But see below.
> > >>
> > >>>>
> > >>>> I must say it seems strange to me that U-Boot would have to rely on
> > >>>> ATF
> > >> though.
> > >>>> How do other platforms implement this? Shouldn't PSCI be generic or
> > >>>> is it really platform specific? If it's generic, isn't that a
> > >>>> dupliation of code if you implement e.g. a reset driver for
> > >>>> Stratix10 but call
> > >> into PSCI?
> > >>> It's not strange at all.  A lot of U-Boot users already using this
> > >>> boot flow (ATF +
> > >> U-Boot).
> > >>
> > >> Just because other boards do this doesn't mean it's not strange.
> > >> Wasn't there some kind of discussion around that PSCI stuff to make it
> > available from U-Boot?
> > >> What's wrong with that way?
> > > Our downstream U-Boot branch is already implemented the PSCI stuffs in U-
> > Boot.
> > > I tried to upstream my PSCI code:
> > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> > >
> > > Marek pointed me to this thread:
> > > https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html
> > >
> > > He had a point. He suggested maybe we can implement the PSCI stuffs in
> > > SPL/TPL. I took a look at the U-Boot code and found out ATF is already well
> > supported. Why don't we just use the PSCI code from ATF rather than re-
> > implementing the PSCI code again in SPL/TPL.
> > > It will save our effort to maintain two PSCI code in U-Boot and ATF while we
> > already have the ATF PSCI implementation to support UEFI.
> >
> > It seems to me we do have working code in U-Boot, what's missing is "only" to
> > turn it ino PSCI?
> Existing PSCI framework in U-Boot provide a way for us to turn the code into a PSCI handler
> by just adding a '__secure' keyword before the function name. See:
> https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga/mailbox_s10.c
>
> Below is one of the functions that has 2 versions. One 'live' in a normal code section and another
> one will be relocated to "__secure" section (for PSCI). You can see that 2 same functions
> are duplicated for normal code section and PSCI section.
>
> int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
>                   u8 urgent, u32 *resp_buf_len, u32 *resp_buf)
> {
>         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
>                                resp_buf_len, resp_buf);
> }
>
> int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
>                                 u32 *arg, u8 urgent, u32 *resp_buf_len,
>                                 u32 *resp_buf)
> {
>         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
>                                resp_buf_len, resp_buf);
> }
>
> Those functions that are needed by PSCI runtime need to be duplicated for "__secure" section.
> U-Boot Proper will copy and relocate the PSCI code in "__secure" section to a location before booting
> Linux whereby they can be called by Linux. Using the PSCI framework, U-Boot proper is not able to call
> any PSCI functions because PSCI code is not available until U-Boot proper ready to boot Linux.
> So that's the reason we need to have 2 sets of code in U-Boot. One for SPL/U-Boot and another one for
> PSCI section which is used by Linux.
> Currently we have 2 implementations for FPGA reconfiguration driver in our downstream branch.
> One for SPL/U-Boot and another one for Linux (PSCI). FPGA reconfiguration driver for U-Boot is already
> upstreamed but I don't think I can get the FPGA reconfiguration for the PSCI part upstreamed.
> They are 2 sets of different code for the same purpose. But that is what we have done in downstream
> to make sure we can support Linux.
>
> BTW, we are going to get rid of those duplicated code for PSCI after we switch to ATF boot flow.

I think we have already discussed why that style is bad and unstable.

The correct thing to do would be to compile an SPL style binary from the U-Boot
sources that can replace ATF-BL31, not this messy __secure thing.

I can see others (rockchip, TI, NXP?) might in part rely on ATF as well, but
speaking for socfpga, if you must insist on using ATF, I would be happy if you
could do it in a way that does not reduce existing functionality in U-Boot.

> >
> > And given U-Boot aims to support UEFI (kind of?), I'd rather argue: why do you
> > need ATF at all?
>
> No, U-Boot does not aim to support UEFI. We have 2 boot flows that don't mix:

Really? Or do you mean you don't aim to support EFI boot using U-Boot?
I don't know that (U)EFI stuff too well, yet, but I was under the
impression that
Heinrich et. al. do want U-Boot to support UEFI?

>
> 1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux
>
> 2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux
>
> These two boot flows now share the same code base (ATF-BL31).
> >
> > Indeed, having the same code in both seems like double effort for maintenance.
> >
> > >>
> > >> In my opinion, you're reducing functionality in U-Boot by making ATF
> > >> a requirement.
> > >>
> > >> And by saying "I can't review this", I mean this looks like a
> > >> questionable way to me and I'm not the one to say if a U-Boot board should
> > go this way or not.
> > > I understand. Btw, who should I include to review this ?
> > >>
> > >>> Yes. PSCI is a generic software interface which encapsulate the
> > >>> platform
> > >> specific code.
> > >>> Let me give you a good example in one of your sysreset driver you
> > >>> have
> > >> implemented for S10.
> > >>>
> > >>> #include <dm.h>
> > >>> #include <errno.h>
> > >>> #include <sysreset.h>
> > >>> -#include <asm/arch/mailbox_s10.h>
> > >>>
> > >>>   static int socfpga_sysreset_request(struct udevice *dev,
> > >>>                                      enum sysreset_t type)  {
> > >>>   -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > >>>   -      mbox_reset_cold();
> > >>>   +      psci_system_reset();
> >
> > And coming back on this, the sysreset driver won't work in SPL any more, right?
> You brought a very good point. See my comment at the bottom.
> >
> > >>
> > >> So this is not an socfgpa_s10 specific driver any more, right?
> This driver code can be renamed to more generic name such as socfpga_soc64.c.
> So that it can be shared by both Stratix10 and Agilex.
> > >>
> > >>>          return -EINPROGRESS;
> > >>>   }
> > >>>
> > >>> Above is the changes in one of my patchsets, the sysreset driver for
> > >>> S10 used to call mbox_reset_cold() to send mailbox message to Secure
> > >>> Device Manager
> > >>> (SDM) to trigger COLD reset.
> > >>> Calling 'mbox_reset_cold()' means you are calling platform specific
> > >>> code in the sysreset driver to perform COLD reset. What if method to
> > >>> trigger
> > >> COLD reset is changed in new platform ?
> > >>> We have to change the sysreset driver code to support another new
> > platform.
> > >>> If this function call is replaced with "psci_system_reset()", we
> > >>> don't have to change the code at all because all the platform
> > >>> specific code for COLD reset is now reside in ATF because this
> > >>> function just invoke the PSCI function provided by ATF. You just
> > >>> have to replace the ATF binary with the new implementation for the
> > >>> new platform. We can re-use this sysreset driver for any platform
> > >>> that support ATF. In fact, it makes our U-Boot driver code more
> > >>> 'generic' because PSCI interface stay the same. BTW, Linux also call
> > >>> PSCI functions to perform COLD reset. By
> > >> using ATF, U-Boot and Linux share the same COLD reset service provided by
> > ATF.
> > >> It actually reduce code duplication.
> > >>
> > >> What I meant was code duplication inside the U-Boot tree (having one
> > >> driver for each arch but in effect all those drivers will call into the same psci
> > function).
> > > Can different archs share the same driver if the driver code is common to
> > those platforms ?
> >
> > I don't know why not. However, you then need a different way to select this
> > driver: you clearly cannot use DT compatibles as this DT entry does not in any
> > way stand for what you make the driver binding to it execute.
> >
> > Instead, I would think of a way to make your PSCI-aware U-Boot proper use a
> > generic PSCI-reset driver instead of the one matching the devicetree. And then
> > keep in mind you still need the DT-matching driver in SPL. Thinking about it,
> > having a driver in SPL you don't use in U-Boot proper is probably not done, yet,
> > as well.
> I don't have any problem with this approach (PSCI-reset driver) but it is very easy to support SPL and U-Boot proper
> in the same driver by just checking the current exception level. Please take a look at the code below.
>
> #include <dm.h>
> #include <errno.h>
> #include <sysreset.h>
> #include <asm/arch/mailbox_s10.h>
>
> static int socfpga_sysreset_request(struct udevice *dev,
>                                      enum sysreset_t type)  {
> -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> +      If (current_el() == 3)

Hard-coding the EL here seems quite a hack?

> +                mbox_reset_cold();
> +      else
> +                psci_system_reset();
>         return -EINPROGRESS;
> }
>
> We can make the sysreset driver compatible in SPL and U-Boot proper by just checking the current exception level.
> If it's EL3 (secure), we knew SPL is running and otherwise U-Boot proper (EL2, non-secure) is running.

So you compile all the PSCI stuff into SPL although never using it?

I'd still prefer to have DT-compat matched drivers implementing the hardware
access.
Then you can instantiate different drivers in U-Boot proper if you want to use
PSCI, not the hardware. Having DT-compat matched drivers do something
completely different (issuing PSCI calls instead of accessing the hardware they
matched on) seems wrong.

Regards,
Simon

> Or we can make a small generic function like below and call it from sysreset driver code:
>
> void soc64_cold_reset(void)
> {
>       If (current_el() == 3)
>                 mbox_reset_cold();
>       else
>                 psci_system_reset();
> }
>
> >
> > >
> > >> What you're doing is to move this code from U-Boot open U-Boot
> > >> sources to possibly closed source ATF sources. But we've already had
> > >> that discussion, I think...
> > > Our PSCI implementation in ATF is open source:
> > > https://github.com/ARM-software/arm-trusted-firmware/tree/master/plat/
> > > intel/soc
> >
> > Well, open source... Without implying anything: it's BSD, so it's open source as
> > long as Intel wants it to be open source and nothing prevents the next manager
> > from keeping additions or even bugfixes closed source.
> > For whatever reasons might come.
> >
> >
> > Regards,
> > Simon
> >
> > >
> > >>
> > >> Regards,
> > >> Simon
> > >>
> > >>>
> > >>> I think you are aware of we are working to move the mailbox driver
> > >>> code away
> > >> from arch to drivers.
> > >>> You will see that a lot of those mailbox functions will be removed
> > >>> from the
> > >> mailbox driver.
> > >>> One of them is 'mbox_reset_cold()' which you called in sysreset driver for
> > S10.
> > >>>
> > >>>> Regards,
> > >>>> Simon
> > >>>>
> > >>>>>>
> > >>>>>> Regard,
> > >>>>>> Simon
> > >>>>>>
> > >>>>>>>>>
> > >>>>>>>>> SPL loads the u-boot.itb which consist of:
> > >>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
> > >>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
> > >>>>>>>>> 3) bl31.bin (ATF-BL31 image)
> > >>>>>>>>>
> > >>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
> > >>>>>>>>> Agilex)
> > >>>>>>>>>
> > >>>>>>>>> Now, U-Boot Proper is running in non-secure mode (EL2), it
> > >>>>>>>>> invokes SMC/PSCI calls provided by ATF to perform COLD reset,
> > >>>>>>>>> System Manager register accesses and mailbox communications
> > >>>>>>>>> with Secure Device Manager (SDM).
> > >>>>>>>>>
> > >>>>>>>>> Steps to build the U-Boot with ATF support:
> > >>>>>>>>> 1) Build U-Boot
> > >>>>>>>>> 2) Build ATF BL31
> > >>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root folder
> > >>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
> > >>>>>>>>>
> > >>>>>>>>> These patchsets have dependency on:
> > >>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > >>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
> > >>>>>>>>>
> > >>>>>>>>> Chee Hong Ang (19):
> > >>>>>>>>>    arm: socfpga: add fit source file for pack itb with ATF
> > >>>>>>>>>    arm: socfpga: Add function for checking description from
> > >>>>>>>>> FIT
> > >> image
> > >>>>>>>>>    arm: socfpga: Load FIT image with ATF support
> > >>>>>>>>>    arm: socfpga: Override 'lowlevel_init' to support ATF
> > >>>>>>>>>    configs: socfpga: Enable FIT image loading with ATF support
> > >>>>>>>>>    arm: socfpga: Disable "spin-table" method for booting Linux
> > >>>>>>>>>    arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> > >>>>>>>>>    arm: socfpga: Define SMC function identifiers for PSCI SiP services
> > >>>>>>>>>    arm: socfpga: Add secure register access helper functions for SoC
> > >>>>>>>>>      64bits
> > >>>>>>>>>    arm: socfpga: Secure register access for clock manager (SoC 64bits)
> > >>>>>>>>>    arm: socfpga: Secure register access in PHY mode setup
> > >>>>>>>>>    arm: socfpga: Secure register access for reading PLL frequency
> > >>>>>>>>>    mmc: dwmmc: socfpga: Secure register access in MMC driver
> > >>>>>>>>>    net: designware: socfpga: Secure register access in MAC driver
> > >>>>>>>>>    arm: socfpga: Secure register access in Reset Manager driver
> > >>>>>>>>>    arm: socfpga: stratix10: Initialize timer in SPL
> > >>>>>>>>>    arm: socfpga: stratix10: Refactor FPGA reconfig driver to
> > >>>>>>>>> support
> > >> ATF
> > >>>>>>>>>    arm: socfpga: Bridge reset now invokes SMC calls to query
> > >>>>>>>>> FPGA
> > >>>> config
> > >>>>>>>>>      status
> > >>>>>>>>>    sysreset: socfpga: Invoke PSCI call for COLD reset
> > >>>>>>>>>
> > >>>>>>>>> Dalon Westergreen (1):
> > >>>>>>>>>    configs: stratix10: Remove CONFIG_OF_EMBED
> > >>>>>>>>
> > >>>>>>>> This one is included in another series already:
> > >>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > >>>>>>>>
> > >>>>>>>> Does this mean that one will be abandonen?
> > >>>>>>>> So the combined hex output part of that series is not required
> > >>>>>>>> any
> > >> more?
> > >>>>>>>>
> > >>>>>>>> Regards,
> > >>>>>>>> Simon
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>   arch/arm/mach-socfpga/Kconfig                      |   2 -
> > >>>>>>>>>   arch/arm/mach-socfpga/Makefile                     |   4 +
> > >>>>>>>>>   arch/arm/mach-socfpga/board.c                      |  10 +
> > >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > >>>>>>>>>   arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > >>>>>>>>>   .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > >>>>>>>>>   arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > >>>>>>>>>   arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > >>>>>>>>>   arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > >>>>>>>>>   arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > >>>>>>>>>   arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > >>>>>>>>>   arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > >>>>>>>>>   board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > >>>>>>>>>   configs/socfpga_agilex_defconfig                   |   8 +-
> > >>>>>>>>>   configs/socfpga_stratix10_defconfig                |   9 +-
> > >>>>>>>>>   drivers/fpga/stratix10.c                           | 261 ++++----------
> > >>>>>>>>>   drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > >>>>>>>>>   drivers/net/dwmac_socfpga.c                        |   5 +-
> > >>>>>>>>>   drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > >>>>>>>>>   include/configs/socfpga_soc64_common.h             |   2 +-
> > >>>>>>>>>   include/linux/intel-smc.h                          | 374
> > >> +++++++++++++++++++++
> > >>>>>>>>>   22 files changed, 732 insertions(+), 243 deletions(-) create
> > >>>>>>>>> mode
> > >>>>>>>>> 100644
> > >>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > >>>>>>>>>   create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > >>>>>>>>>   create mode 100644
> > >>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
> > >>>>>>>>>   create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > >>>>>>>>>   create mode 100644 include/linux/intel-smc.h
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> 2.7.4
> > >>>>>>>>>
>

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong <chee.hong.ang@intel.com>
> wrote:
> >
> > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
> > > >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> > > >> <chee.hong.ang@intel.com>
> > > >> wrote:
> > > >>>
> > > >>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > > >>>> <chee.hong.ang@intel.com>
> > > >>>> wrote:
> > > >>>>>
> > > >>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > >>>>>> <chee.hong.ang@intel.com>
> > > >>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com>
> > > >> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > >>>>>>>>>
> > > >>>>>>>>> New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > >>>>>>>>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
> > > >>>>>>>>> Linux
> > > >>>>>>>>> (EL1)
> > > >>>>>>>>
> > > >>>>>>>> Adding support for ATF means that using U-Boot on Stratix10
> > > >>>>>>>> and Agilex without ATF keeps working, right?
> > > >>>>>>> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > > >>>>>>
> > > >>>>>> Is there a technical requirement for that?
> > > >>>>> Yes. We are using ATF to provide PSCI services such as system
> > > >>>>> reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> > > >>>>> other secure services such as mailbox communications with
> > > >>>>> Secure Device Manager and accessing the System Manager
> > > >>>>> registers which are
> > > >> secure.
> > > >>>>> Without PSCI services, we are able to boot until U-Boot proper only.
> > > >>>>> Currently, our U-Boot in mainline doesn't boot to Linux due to
> > > >>>>> these missing
> > > >>>> PSCI services.
> > > >>>>> Another reason is we have another boot flow which is using ATF +
> UEFI.
> > > >>>>> So now we are re-using the PSCI services from ATF so that now
> > > >>>>> U-Boot and UEFI share the same ATF-BL31 image so that we don't
> > > >>>>> have to
> > > >>>> reimplement another sets of PSCI services for U-Boot again.
> > > >>>>> This will greatly reduce our engineering efforts.
> > > >>>>
> > > >>>> Hmm, thanks for the explanation.
> > > >>>>
> > > >>>> I don't really think I can review this, given the lack of
> > > >>>> knowledge about that PSCI stuff.
> > > >>> I believe you can review it.
> > > >>> Have you briefly gone through the patches ? It has nothing to do
> > > >>> with the PSCI
> > > >> stuff.
> > > >>> It just call the invoke_smc() function to call the ATF's PSCI
> > > >>> functions. Those PSCI functions in ATF will do the rest.
> > > >>
> > > >> No, not yet. But see below.
> > > >>
> > > >>>>
> > > >>>> I must say it seems strange to me that U-Boot would have to
> > > >>>> rely on ATF
> > > >> though.
> > > >>>> How do other platforms implement this? Shouldn't PSCI be
> > > >>>> generic or is it really platform specific? If it's generic,
> > > >>>> isn't that a dupliation of code if you implement e.g. a reset
> > > >>>> driver for
> > > >>>> Stratix10 but call
> > > >> into PSCI?
> > > >>> It's not strange at all.  A lot of U-Boot users already using
> > > >>> this boot flow (ATF +
> > > >> U-Boot).
> > > >>
> > > >> Just because other boards do this doesn't mean it's not strange.
> > > >> Wasn't there some kind of discussion around that PSCI stuff to
> > > >> make it
> > > available from U-Boot?
> > > >> What's wrong with that way?
> > > > Our downstream U-Boot branch is already implemented the PSCI
> > > > stuffs in U-
> > > Boot.
> > > > I tried to upstream my PSCI code:
> > > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> > > >
> > > > Marek pointed me to this thread:
> > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html
> > > >
> > > > He had a point. He suggested maybe we can implement the PSCI
> > > > stuffs in SPL/TPL. I took a look at the U-Boot code and found out
> > > > ATF is already well
> > > supported. Why don't we just use the PSCI code from ATF rather than
> > > re- implementing the PSCI code again in SPL/TPL.
> > > > It will save our effort to maintain two PSCI code in U-Boot and
> > > > ATF while we
> > > already have the ATF PSCI implementation to support UEFI.
> > >
> > > It seems to me we do have working code in U-Boot, what's missing is
> > > "only" to turn it ino PSCI?
> > Existing PSCI framework in U-Boot provide a way for us to turn the
> > code into a PSCI handler by just adding a '__secure' keyword before the
> function name. See:
> > https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga
> > /mailbox_s10.c
> >
> > Below is one of the functions that has 2 versions. One 'live' in a
> > normal code section and another one will be relocated to "__secure"
> > section (for PSCI). You can see that 2 same functions are duplicated for normal
> code section and PSCI section.
> >
> > int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
> >                   u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
> >         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
> >                                resp_buf_len, resp_buf); }
> >
> > int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
> >                                 u32 *arg, u8 urgent, u32 *resp_buf_len,
> >                                 u32 *resp_buf) {
> >         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
> >                                resp_buf_len, resp_buf); }
> >
> > Those functions that are needed by PSCI runtime need to be duplicated for
> "__secure" section.
> > U-Boot Proper will copy and relocate the PSCI code in "__secure"
> > section to a location before booting Linux whereby they can be called
> > by Linux. Using the PSCI framework, U-Boot proper is not able to call any PSCI
> functions because PSCI code is not available until U-Boot proper ready to boot
> Linux.
> > So that's the reason we need to have 2 sets of code in U-Boot. One for
> > SPL/U-Boot and another one for PSCI section which is used by Linux.
> > Currently we have 2 implementations for FPGA reconfiguration driver in our
> downstream branch.
> > One for SPL/U-Boot and another one for Linux (PSCI). FPGA
> > reconfiguration driver for U-Boot is already upstreamed but I don't think I can
> get the FPGA reconfiguration for the PSCI part upstreamed.
> > They are 2 sets of different code for the same purpose. But that is
> > what we have done in downstream to make sure we can support Linux.
> >
> > BTW, we are going to get rid of those duplicated code for PSCI after we switch
> to ATF boot flow.
> 
> I think we have already discussed why that style is bad and unstable.
> 
> The correct thing to do would be to compile an SPL style binary from the U-Boot
> sources that can replace ATF-BL31, not this messy __secure thing.
> 
> I can see others (rockchip, TI, NXP?) might in part rely on ATF as well, but
> speaking for socfpga, if you must insist on using ATF, I would be happy if you
> could do it in a way that does not reduce existing functionality in U-Boot.
Please do 'git grep CONFIG_SPL_ATF' and you will have some idea who are using the ATF
with U-Boot. You can know which platforms are using the ATF by looking at the name
of the defconfig files.

BTW, what makes you think this ATF method reduce the existing functionality in U-Boot ?
I don't really get that. I would like to know more to see what I can do to ease your concern.
> 
> > >
> > > And given U-Boot aims to support UEFI (kind of?), I'd rather argue:
> > > why do you need ATF at all?
> >
> > No, U-Boot does not aim to support UEFI. We have 2 boot flows that don't
> mix:
> 
> Really? Or do you mean you don't aim to support EFI boot using U-Boot?
> I don't know that (U)EFI stuff too well, yet, but I was under the impression that
> Heinrich et. al. do want U-Boot to support UEFI?
Yes. Currently, we have no plan to support (U)EFI boot with U-Boot.
Anyway, I am not working on UEFI boot flow. That's the work from another team.
> 
> >
> > 1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux
> >
> > 2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux
> >
> > These two boot flows now share the same code base (ATF-BL31).
> > >
> > > Indeed, having the same code in both seems like double effort for
> maintenance.
> > >
> > > >>
> > > >> In my opinion, you're reducing functionality in U-Boot by making
> > > >> ATF a requirement.
> > > >>
> > > >> And by saying "I can't review this", I mean this looks like a
> > > >> questionable way to me and I'm not the one to say if a U-Boot
> > > >> board should
> > > go this way or not.
> > > > I understand. Btw, who should I include to review this ?
> > > >>
> > > >>> Yes. PSCI is a generic software interface which encapsulate the
> > > >>> platform
> > > >> specific code.
> > > >>> Let me give you a good example in one of your sysreset driver
> > > >>> you have
> > > >> implemented for S10.
> > > >>>
> > > >>> #include <dm.h>
> > > >>> #include <errno.h>
> > > >>> #include <sysreset.h>
> > > >>> -#include <asm/arch/mailbox_s10.h>
> > > >>>
> > > >>>   static int socfpga_sysreset_request(struct udevice *dev,
> > > >>>                                      enum sysreset_t type)  {
> > > >>>   -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > > >>>   -      mbox_reset_cold();
> > > >>>   +      psci_system_reset();
> > >
> > > And coming back on this, the sysreset driver won't work in SPL any more,
> right?
> > You brought a very good point. See my comment at the bottom.
> > >
> > > >>
> > > >> So this is not an socfgpa_s10 specific driver any more, right?
> > This driver code can be renamed to more generic name such as
> socfpga_soc64.c.
> > So that it can be shared by both Stratix10 and Agilex.
> > > >>
> > > >>>          return -EINPROGRESS;
> > > >>>   }
> > > >>>
> > > >>> Above is the changes in one of my patchsets, the sysreset driver
> > > >>> for
> > > >>> S10 used to call mbox_reset_cold() to send mailbox message to
> > > >>> Secure Device Manager
> > > >>> (SDM) to trigger COLD reset.
> > > >>> Calling 'mbox_reset_cold()' means you are calling platform
> > > >>> specific code in the sysreset driver to perform COLD reset. What
> > > >>> if method to trigger
> > > >> COLD reset is changed in new platform ?
> > > >>> We have to change the sysreset driver code to support another
> > > >>> new
> > > platform.
> > > >>> If this function call is replaced with "psci_system_reset()", we
> > > >>> don't have to change the code at all because all the platform
> > > >>> specific code for COLD reset is now reside in ATF because this
> > > >>> function just invoke the PSCI function provided by ATF. You just
> > > >>> have to replace the ATF binary with the new implementation for
> > > >>> the new platform. We can re-use this sysreset driver for any
> > > >>> platform that support ATF. In fact, it makes our U-Boot driver
> > > >>> code more 'generic' because PSCI interface stay the same. BTW,
> > > >>> Linux also call PSCI functions to perform COLD reset. By
> > > >> using ATF, U-Boot and Linux share the same COLD reset service
> > > >> provided by
> > > ATF.
> > > >> It actually reduce code duplication.
> > > >>
> > > >> What I meant was code duplication inside the U-Boot tree (having
> > > >> one driver for each arch but in effect all those drivers will
> > > >> call into the same psci
> > > function).
> > > > Can different archs share the same driver if the driver code is
> > > > common to
> > > those platforms ?
> > >
> > > I don't know why not. However, you then need a different way to
> > > select this
> > > driver: you clearly cannot use DT compatibles as this DT entry does
> > > not in any way stand for what you make the driver binding to it execute.
> > >
> > > Instead, I would think of a way to make your PSCI-aware U-Boot
> > > proper use a generic PSCI-reset driver instead of the one matching
> > > the devicetree. And then keep in mind you still need the DT-matching
> > > driver in SPL. Thinking about it, having a driver in SPL you don't
> > > use in U-Boot proper is probably not done, yet, as well.
> > I don't have any problem with this approach (PSCI-reset driver) but it
> > is very easy to support SPL and U-Boot proper in the same driver by just
> checking the current exception level. Please take a look at the code below.
> >
> > #include <dm.h>
> > #include <errno.h>
> > #include <sysreset.h>
> > #include <asm/arch/mailbox_s10.h>
> >
> > static int socfpga_sysreset_request(struct udevice *dev,
> >                                      enum sysreset_t type)  {
> > -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > +      If (current_el() == 3)
> 
> Hard-coding the EL here seems quite a hack?
> 
> > +                mbox_reset_cold();
> > +      else
> > +                psci_system_reset();
> >         return -EINPROGRESS;
> > }
> >
> > We can make the sysreset driver compatible in SPL and U-Boot proper by just
> checking the current exception level.
> > If it's EL3 (secure), we knew SPL is running and otherwise U-Boot proper (EL2,
> non-secure) is running.
> 
> So you compile all the PSCI stuff into SPL although never using it?
The PSCI stuff is just a very thin layer (interface to PSCI/SMC call) since real work is done in ATF.
Or we can do it in compile time:
#ifdef CONFIG_SPL_BUILD
     // do it in normal way
#else
    // invoke PSCI call
#endif
> 
> I'd still prefer to have DT-compat matched drivers implementing the hardware
> access.
> Then you can instantiate different drivers in U-Boot proper if you want to use
> PSCI, not the hardware. Having DT-compat matched drivers do something
> completely different (issuing PSCI calls instead of accessing the hardware they
> matched on) seems wrong.
OK.
> 
> Regards,
> Simon
> 
> > Or we can make a small generic function like below and call it from sysreset
> driver code:
> >
> > void soc64_cold_reset(void)
> > {
> >       If (current_el() == 3)
> >                 mbox_reset_cold();
> >       else
> >                 psci_system_reset();
> > }
> >
> > >
> > > >
> > > >> What you're doing is to move this code from U-Boot open U-Boot
> > > >> sources to possibly closed source ATF sources. But we've already
> > > >> had that discussion, I think...
> > > > Our PSCI implementation in ATF is open source:
> > > > https://github.com/ARM-software/arm-trusted-firmware/tree/master/p
> > > > lat/
> > > > intel/soc
> > >
> > > Well, open source... Without implying anything: it's BSD, so it's
> > > open source as long as Intel wants it to be open source and nothing
> > > prevents the next manager from keeping additions or even bugfixes closed
> source.
> > > For whatever reasons might come.
> > >
> > >
> > > Regards,
> > > Simon
> > >
> > > >
> > > >>
> > > >> Regards,
> > > >> Simon
> > > >>
> > > >>>
> > > >>> I think you are aware of we are working to move the mailbox
> > > >>> driver code away
> > > >> from arch to drivers.
> > > >>> You will see that a lot of those mailbox functions will be
> > > >>> removed from the
> > > >> mailbox driver.
> > > >>> One of them is 'mbox_reset_cold()' which you called in sysreset
> > > >>> driver for
> > > S10.
> > > >>>
> > > >>>> Regards,
> > > >>>> Simon
> > > >>>>
> > > >>>>>>
> > > >>>>>> Regard,
> > > >>>>>> Simon
> > > >>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> SPL loads the u-boot.itb which consist of:
> > > >>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > >>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
> > > >>>>>>>>> 3) bl31.bin (ATF-BL31 image)
> > > >>>>>>>>>
> > > >>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
> > > >>>>>>>>> Agilex)
> > > >>>>>>>>>
> > > >>>>>>>>> Now, U-Boot Proper is running in non-secure mode (EL2), it
> > > >>>>>>>>> invokes SMC/PSCI calls provided by ATF to perform COLD
> > > >>>>>>>>> reset, System Manager register accesses and mailbox
> > > >>>>>>>>> communications with Secure Device Manager (SDM).
> > > >>>>>>>>>
> > > >>>>>>>>> Steps to build the U-Boot with ATF support:
> > > >>>>>>>>> 1) Build U-Boot
> > > >>>>>>>>> 2) Build ATF BL31
> > > >>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > >>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
> > > >>>>>>>>>
> > > >>>>>>>>> These patchsets have dependency on:
> > > >>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > >>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
> > > >>>>>>>>>
> > > >>>>>>>>> Chee Hong Ang (19):
> > > >>>>>>>>>    arm: socfpga: add fit source file for pack itb with ATF
> > > >>>>>>>>>    arm: socfpga: Add function for checking description
> > > >>>>>>>>> from FIT
> > > >> image
> > > >>>>>>>>>    arm: socfpga: Load FIT image with ATF support
> > > >>>>>>>>>    arm: socfpga: Override 'lowlevel_init' to support ATF
> > > >>>>>>>>>    configs: socfpga: Enable FIT image loading with ATF support
> > > >>>>>>>>>    arm: socfpga: Disable "spin-table" method for booting Linux
> > > >>>>>>>>>    arm: socfpga: Add SMC helper function for Intel SOCFPGA
> (64bits)
> > > >>>>>>>>>    arm: socfpga: Define SMC function identifiers for PSCI SiP
> services
> > > >>>>>>>>>    arm: socfpga: Add secure register access helper functions for
> SoC
> > > >>>>>>>>>      64bits
> > > >>>>>>>>>    arm: socfpga: Secure register access for clock manager (SoC
> 64bits)
> > > >>>>>>>>>    arm: socfpga: Secure register access in PHY mode setup
> > > >>>>>>>>>    arm: socfpga: Secure register access for reading PLL frequency
> > > >>>>>>>>>    mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > >>>>>>>>>    net: designware: socfpga: Secure register access in MAC driver
> > > >>>>>>>>>    arm: socfpga: Secure register access in Reset Manager driver
> > > >>>>>>>>>    arm: socfpga: stratix10: Initialize timer in SPL
> > > >>>>>>>>>    arm: socfpga: stratix10: Refactor FPGA reconfig driver
> > > >>>>>>>>> to support
> > > >> ATF
> > > >>>>>>>>>    arm: socfpga: Bridge reset now invokes SMC calls to
> > > >>>>>>>>> query FPGA
> > > >>>> config
> > > >>>>>>>>>      status
> > > >>>>>>>>>    sysreset: socfpga: Invoke PSCI call for COLD reset
> > > >>>>>>>>>
> > > >>>>>>>>> Dalon Westergreen (1):
> > > >>>>>>>>>    configs: stratix10: Remove CONFIG_OF_EMBED
> > > >>>>>>>>
> > > >>>>>>>> This one is included in another series already:
> > > >>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > >>>>>>>>
> > > >>>>>>>> Does this mean that one will be abandonen?
> > > >>>>>>>> So the combined hex output part of that series is not
> > > >>>>>>>> required any
> > > >> more?
> > > >>>>>>>>
> > > >>>>>>>> Regards,
> > > >>>>>>>> Simon
> > > >>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>   arch/arm/mach-socfpga/Kconfig                      |   2 -
> > > >>>>>>>>>   arch/arm/mach-socfpga/Makefile                     |   4 +
> > > >>>>>>>>>   arch/arm/mach-socfpga/board.c                      |  10 +
> > > >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > > >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > > >>>>>>>>>   arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > > >>>>>>>>>   .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > >>>>>>>>>   arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > > >>>>>>>>>   arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > > >>>>>>>>>   arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > > >>>>>>>>>   arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > > >>>>>>>>>   arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > > >>>>>>>>>   arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > > >>>>>>>>>   board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > > >>>>>>>>>   configs/socfpga_agilex_defconfig                   |   8 +-
> > > >>>>>>>>>   configs/socfpga_stratix10_defconfig                |   9 +-
> > > >>>>>>>>>   drivers/fpga/stratix10.c                           | 261 ++++----------
> > > >>>>>>>>>   drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > > >>>>>>>>>   drivers/net/dwmac_socfpga.c                        |   5 +-
> > > >>>>>>>>>   drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > > >>>>>>>>>   include/configs/socfpga_soc64_common.h             |   2 +-
> > > >>>>>>>>>   include/linux/intel-smc.h                          | 374
> > > >> +++++++++++++++++++++
> > > >>>>>>>>>   22 files changed, 732 insertions(+), 243 deletions(-)
> > > >>>>>>>>> create mode
> > > >>>>>>>>> 100644
> > > >>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > >>>>>>>>>   create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > > >>>>>>>>>   create mode 100644
> > > >>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
> > > >>>>>>>>>   create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > > >>>>>>>>>   create mode 100644 include/linux/intel-smc.h
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> 2.7.4
> > > >>>>>>>>>
> >

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Dalon L Westergreen]

On Tue, 2019-12-03 at 14:45 +0000, Ang, Chee Hong wrote:
> > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong <
> > chee.hong.ang at intel.com
> > >
> > wrote:
> > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
> > > > > > On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> > > > > > <
> > > > > > chee.hong.ang at intel.com
> > > > > > >
> > > > > > wrote:
> > > > > > > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > > > > > > > <
> > > > > > > > chee.hong.ang at intel.com
> > > > > > > > >
> > > > > > > > wrote:
> > > > > > > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > > > > > > > > <
> > > > > > > > > > chee.hong.ang at intel.com
> > > > > > > > > > >
> > > > > > > > > > wrote:
> > > > > > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM <
> > > > > > > > > > > > chee.hong.ang at intel.com
> > > > > > > > > > > > >
> > > > > > 
> > > > > > wrote:
> > > > > > > > > > > > > From: "Ang, Chee Hong" <
> > > > > > > > > > > > > chee.hong.ang at intel.com
> > > > > > > > > > > > > >
> > > > > > > > > > > > > 
> > > > > > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF)
> > > > > > > > > > > > > support:
> > > > > > > > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
> > > > > > > > > > > > > Linux
> > > > > > > > > > > > > (EL1)
> > > > > > > > > > > > 
> > > > > > > > > > > > Adding support for ATF means that using U-Boot on
> > > > > > > > > > > > Stratix10
> > > > > > > > > > > > and Agilex without ATF keeps working, right?
> > > > > > > > > > > 
> > > > > > > > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot
> > > > > > > > > > > to work.
> > > > > > > > > > 
> > > > > > > > > > Is there a technical requirement for that?
> > > > > > > > > 
> > > > > > > > > Yes. We are using ATF to provide PSCI services such as system
> > > > > > > > > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> > > > > > > > > other secure services such as mailbox communications with
> > > > > > > > > Secure Device Manager and accessing the System Manager
> > > > > > > > > registers which are
> > > > > > 
> > > > > > secure.
> > > > > > > > > Without PSCI services, we are able to boot until U-Boot proper
> > > > > > > > > only.
> > > > > > > > > Currently, our U-Boot in mainline doesn't boot to Linux due to
> > > > > > > > > these missing
> > > > > > > > 
> > > > > > > > PSCI services.
> > > > > > > > > Another reason is we have another boot flow which is using ATF
> > > > > > > > > +
> > 
> > UEFI.
> > > > > > > > > So now we are re-using the PSCI services from ATF so that now
> > > > > > > > > U-Boot and UEFI share the same ATF-BL31 image so that we don't
> > > > > > > > > have to
> > > > > > > > 
> > > > > > > > reimplement another sets of PSCI services for U-Boot again.
> > > > > > > > > This will greatly reduce our engineering efforts.
> > > > > > > > 
> > > > > > > > Hmm, thanks for the explanation.
> > > > > > > > 
> > > > > > > > I don't really think I can review this, given the lack of
> > > > > > > > knowledge about that PSCI stuff.
> > > > > > > 
> > > > > > > I believe you can review it.
> > > > > > > Have you briefly gone through the patches ? It has nothing to do
> > > > > > > with the PSCI
> > > > > > 
> > > > > > stuff.
> > > > > > > It just call the invoke_smc() function to call the ATF's PSCI
> > > > > > > functions. Those PSCI functions in ATF will do the rest.
> > > > > > 
> > > > > > No, not yet. But see below.
> > > > > > 
> > > > > > > > I must say it seems strange to me that U-Boot would have to
> > > > > > > > rely on ATF
> > > > > > 
> > > > > > though.
> > > > > > > > How do other platforms implement this? Shouldn't PSCI be
> > > > > > > > generic or is it really platform specific? If it's generic,
> > > > > > > > isn't that a dupliation of code if you implement e.g. a reset
> > > > > > > > driver for
> > > > > > > > Stratix10 but call
> > > > > > 
> > > > > > into PSCI?
> > > > > > > It's not strange at all.  A lot of U-Boot users already using
> > > > > > > this boot flow (ATF +
> > > > > > 
> > > > > > U-Boot).
> > > > > > 
> > > > > > Just because other boards do this doesn't mean it's not strange.
> > > > > > Wasn't there some kind of discussion around that PSCI stuff to
> > > > > > make it
> > > > 
> > > > available from U-Boot?
> > > > > > What's wrong with that way?
> > > > > 
> > > > > Our downstream U-Boot branch is already implemented the PSCI
> > > > > stuffs in U-
> > > > 
> > > > Boot.
> > > > > I tried to upstream my PSCI code:
> > > > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> > > > > 
> > > > > 
> > > > > Marek pointed me to this thread:
> > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html
> > > > > 
> > > > > 
> > > > > He had a point. He suggested maybe we can implement the PSCI
> > > > > stuffs in SPL/TPL. I took a look at the U-Boot code and found out
> > > > > ATF is already well
> > > > 
> > > > supported. Why don't we just use the PSCI code from ATF rather than
> > > > re- implementing the PSCI code again in SPL/TPL.
> > > > > It will save our effort to maintain two PSCI code in U-Boot and
> > > > > ATF while we
> > > > 
> > > > already have the ATF PSCI implementation to support UEFI.
> > > > 
> > > > It seems to me we do have working code in U-Boot, what's missing is
> > > > "only" to turn it ino PSCI?
> > > 
> > > Existing PSCI framework in U-Boot provide a way for us to turn the
> > > code into a PSCI handler by just adding a '__secure' keyword before the
> > 
> > function name. See:
> > > https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga
> > > 
> > > /mailbox_s10.c
> > > 
> > > Below is one of the functions that has 2 versions. One 'live' in a
> > > normal code section and another one will be relocated to "__secure"
> > > section (for PSCI). You can see that 2 same functions are duplicated for
> > > normal
> > 
> > code section and PSCI section.
> > > int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
> > >                   u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
> > >         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
> > > urgent,
> > >                                resp_buf_len, resp_buf); }
> > > 
> > > int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
> > >                                 u32 *arg, u8 urgent, u32 *resp_buf_len,
> > >                                 u32 *resp_buf) {
> > >         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
> > > urgent,
> > >                                resp_buf_len, resp_buf); }
> > > 
> > > Those functions that are needed by PSCI runtime need to be duplicated for
> > 
> > "__secure" section.
> > > U-Boot Proper will copy and relocate the PSCI code in "__secure"
> > > section to a location before booting Linux whereby they can be called
> > > by Linux. Using the PSCI framework, U-Boot proper is not able to call any
> > > PSCI
> > 
> > functions because PSCI code is not available until U-Boot proper ready to
> > boot
> > Linux.
> > > So that's the reason we need to have 2 sets of code in U-Boot. One for
> > > SPL/U-Boot and another one for PSCI section which is used by Linux.
> > > Currently we have 2 implementations for FPGA reconfiguration driver in our
> > 
> > downstream branch.
> > > One for SPL/U-Boot and another one for Linux (PSCI). FPGA
> > > reconfiguration driver for U-Boot is already upstreamed but I don't think
> > > I can
> > 
> > get the FPGA reconfiguration for the PSCI part upstreamed.
> > > They are 2 sets of different code for the same purpose. But that is
> > > what we have done in downstream to make sure we can support Linux.
> > > 
> > > BTW, we are going to get rid of those duplicated code for PSCI after we
> > > switch
> > 
> > to ATF boot flow.
> > 
> > I think we have already discussed why that style is bad and unstable.
> > 
> > The correct thing to do would be to compile an SPL style binary from the U-
> > Boot
> > sources that can replace ATF-BL31, not this messy __secure thing.
> > 
> > I can see others (rockchip, TI, NXP?) might in part rely on ATF as well, but
> > speaking for socfpga, if you must insist on using ATF, I would be happy if
> > you
> > could do it in a way that does not reduce existing functionality in U-Boot.
> 
> Please do 'git grep CONFIG_SPL_ATF' and you will have some idea who are using
> the ATF
> with U-Boot. You can know which platforms are using the ATF by looking at the
> name
> of the defconfig files.
> 
> BTW, what makes you think this ATF method reduce the existing functionality in
> U-Boot ?
> I don't really get that. I would like to know more to see what I can do to
> ease your concern.
> > > > And given U-Boot aims to support UEFI (kind of?), I'd rather argue:
> > > > why do you need ATF at all?
> > > 
> > > No, U-Boot does not aim to support UEFI. We have 2 boot flows that don't
> > 
> > mix:
> > 
> > Really? Or do you mean you don't aim to support EFI boot using U-Boot?
> > I don't know that (U)EFI stuff too well, yet, but I was under the impression
> > that
> > Heinrich et. al. do want U-Boot to support UEFI?
> 
> Yes. Currently, we have no plan to support (U)EFI boot with U-Boot.
> Anyway, I am not working on UEFI boot flow. That's the work from another team.

I need to point out a miscommunication on going in this thread.  Ang is
referring to the UEFI bootloader that currently supports socfpga devices,
Simon is referring to EFI support in uboot which we should move to support
and test in uboot as it is commonly used for arm64 boot, by fedora for example.

https://github.com/altera-opensource/uefi-socfpga

--dalon

> > > 1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux
> > > 
> > > 2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux
> > > 
> > > These two boot flows now share the same code base (ATF-BL31).
> > > > Indeed, having the same code in both seems like double effort for
> > 
> > maintenance.
> > > > > > In my opinion, you're reducing functionality in U-Boot by making
> > > > > > ATF a requirement.
> > > > > > 
> > > > > > And by saying "I can't review this", I mean this looks like a
> > > > > > questionable way to me and I'm not the one to say if a U-Boot
> > > > > > board should
> > > > 
> > > > go this way or not.
> > > > > I understand. Btw, who should I include to review this ?
> > > > > > > Yes. PSCI is a generic software interface which encapsulate the
> > > > > > > platform
> > > > > > 
> > > > > > specific code.
> > > > > > > Let me give you a good example in one of your sysreset driver
> > > > > > > you have
> > > > > > 
> > > > > > implemented for S10.
> > > > > > > #include <dm.h>
> > > > > > > #include <errno.h>
> > > > > > > #include <sysreset.h>
> > > > > > > -#include <asm/arch/mailbox_s10.h>
> > > > > > > 
> > > > > > >   static int socfpga_sysreset_request(struct udevice *dev,
> > > > > > >                                      enum sysreset_t type)  {
> > > > > > >   -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > > > > > >   -      mbox_reset_cold();
> > > > > > >   +      psci_system_reset();
> > > > 
> > > > And coming back on this, the sysreset driver won't work in SPL any more,
> > 
> > right?
> > > You brought a very good point. See my comment at the bottom.
> > > > > > So this is not an socfgpa_s10 specific driver any more, right?
> > > 
> > > This driver code can be renamed to more generic name such as
> > 
> > socfpga_soc64.c.
> > > So that it can be shared by both Stratix10 and Agilex.
> > > > > > >          return -EINPROGRESS;
> > > > > > >   }
> > > > > > > 
> > > > > > > Above is the changes in one of my patchsets, the sysreset driver
> > > > > > > for
> > > > > > > S10 used to call mbox_reset_cold() to send mailbox message to
> > > > > > > Secure Device Manager
> > > > > > > (SDM) to trigger COLD reset.
> > > > > > > Calling 'mbox_reset_cold()' means you are calling platform
> > > > > > > specific code in the sysreset driver to perform COLD reset. What
> > > > > > > if method to trigger
> > > > > > 
> > > > > > COLD reset is changed in new platform ?
> > > > > > > We have to change the sysreset driver code to support another
> > > > > > > new
> > > > 
> > > > platform.
> > > > > > > If this function call is replaced with "psci_system_reset()", we
> > > > > > > don't have to change the code at all because all the platform
> > > > > > > specific code for COLD reset is now reside in ATF because this
> > > > > > > function just invoke the PSCI function provided by ATF. You just
> > > > > > > have to replace the ATF binary with the new implementation for
> > > > > > > the new platform. We can re-use this sysreset driver for any
> > > > > > > platform that support ATF. In fact, it makes our U-Boot driver
> > > > > > > code more 'generic' because PSCI interface stay the same. BTW,
> > > > > > > Linux also call PSCI functions to perform COLD reset. By
> > > > > > 
> > > > > > using ATF, U-Boot and Linux share the same COLD reset service
> > > > > > provided by
> > > > 
> > > > ATF.
> > > > > > It actually reduce code duplication.
> > > > > > 
> > > > > > What I meant was code duplication inside the U-Boot tree (having
> > > > > > one driver for each arch but in effect all those drivers will
> > > > > > call into the same psci
> > > > 
> > > > function).
> > > > > Can different archs share the same driver if the driver code is
> > > > > common to
> > > > 
> > > > those platforms ?
> > > > 
> > > > I don't know why not. However, you then need a different way to
> > > > select this
> > > > driver: you clearly cannot use DT compatibles as this DT entry does
> > > > not in any way stand for what you make the driver binding to it execute.
> > > > 
> > > > Instead, I would think of a way to make your PSCI-aware U-Boot
> > > > proper use a generic PSCI-reset driver instead of the one matching
> > > > the devicetree. And then keep in mind you still need the DT-matching
> > > > driver in SPL. Thinking about it, having a driver in SPL you don't
> > > > use in U-Boot proper is probably not done, yet, as well.
> > > 
> > > I don't have any problem with this approach (PSCI-reset driver) but it
> > > is very easy to support SPL and U-Boot proper in the same driver by just
> > 
> > checking the current exception level. Please take a look at the code below.
> > > #include <dm.h>
> > > #include <errno.h>
> > > #include <sysreset.h>
> > > #include <asm/arch/mailbox_s10.h>
> > > 
> > > static int socfpga_sysreset_request(struct udevice *dev,
> > >                                      enum sysreset_t type)  {
> > > -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > > +      If (current_el() == 3)
> > 
> > Hard-coding the EL here seems quite a hack?
> > 
> > > +                mbox_reset_cold();
> > > +      else
> > > +                psci_system_reset();
> > >         return -EINPROGRESS;
> > > }
> > > 
> > > We can make the sysreset driver compatible in SPL and U-Boot proper by
> > > just
> > 
> > checking the current exception level.
> > > If it's EL3 (secure), we knew SPL is running and otherwise U-Boot proper
> > > (EL2,
> > 
> > non-secure) is running.
> > 
> > So you compile all the PSCI stuff into SPL although never using it?
> 
> The PSCI stuff is just a very thin layer (interface to PSCI/SMC call) since
> real work is done in ATF.
> Or we can do it in compile time:
> #ifdef CONFIG_SPL_BUILD
>      // do it in normal way
> #else
>     // invoke PSCI call
> #endif
> > I'd still prefer to have DT-compat matched drivers implementing the hardware
> > access.
> > Then you can instantiate different drivers in U-Boot proper if you want to
> > use
> > PSCI, not the hardware. Having DT-compat matched drivers do something
> > completely different (issuing PSCI calls instead of accessing the hardware
> > they
> > matched on) seems wrong.
> 
> OK.
> > Regards,
> > Simon
> > 
> > > Or we can make a small generic function like below and call it from
> > > sysreset
> > 
> > driver code:
> > > void soc64_cold_reset(void)
> > > {
> > >       If (current_el() == 3)
> > >                 mbox_reset_cold();
> > >       else
> > >                 psci_system_reset();
> > > }
> > > 
> > > > > > What you're doing is to move this code from U-Boot open U-Boot
> > > > > > sources to possibly closed source ATF sources. But we've already
> > > > > > had that discussion, I think...
> > > > > 
> > > > > Our PSCI implementation in ATF is open source:
> > > > > https://github.com/ARM-software/arm-trusted-firmware/tree/master/p
> > > > > 
> > > > > lat/
> > > > > intel/soc
> > > > 
> > > > Well, open source... Without implying anything: it's BSD, so it's
> > > > open source as long as Intel wants it to be open source and nothing
> > > > prevents the next manager from keeping additions or even bugfixes closed
> > 
> > source.
> > > > For whatever reasons might come.
> > > > 
> > > > 
> > > > Regards,
> > > > Simon
> > > > 
> > > > > > Regards,
> > > > > > Simon
> > > > > > 
> > > > > > > I think you are aware of we are working to move the mailbox
> > > > > > > driver code away
> > > > > > 
> > > > > > from arch to drivers.
> > > > > > > You will see that a lot of those mailbox functions will be
> > > > > > > removed from the
> > > > > > 
> > > > > > mailbox driver.
> > > > > > > One of them is 'mbox_reset_cold()' which you called in sysreset
> > > > > > > driver for
> > > > 
> > > > S10.
> > > > > > > > Regards,
> > > > > > > > Simon
> > > > > > > > 
> > > > > > > > > > Regard,
> > > > > > > > > > Simon
> > > > > > > > > > 
> > > > > > > > > > > > > SPL loads the u-boot.itb which consist of:
> > > > > > > > > > > > > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > > > > > > > > > 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > > > > > > > > > 3) bl31.bin (ATF-BL31 image)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
> > > > > > > > > > > > > Agilex)
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Now, U-Boot Proper is running in non-secure mode
> > > > > > > > > > > > > (EL2), it
> > > > > > > > > > > > > invokes SMC/PSCI calls provided by ATF to perform COLD
> > > > > > > > > > > > > reset, System Manager register accesses and mailbox
> > > > > > > > > > > > > communications with Secure Device Manager (SDM).
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Steps to build the U-Boot with ATF support:
> > > > > > > > > > > > > 1) Build U-Boot
> > > > > > > > > > > > > 2) Build ATF BL31
> > > > > > > > > > > > > 3) Copy ATF BL31 binary image into U-Boot's root
> > > > > > > > > > > > > folder
> > > > > > > > > > > > > 4) "make u-boot.itb" to generate u-boot.itb
> > > > > > > > > > > > > 
> > > > > > > > > > > > > These patchsets have dependency on:
> > > > > > > > > > > > > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > > > > > > > > > > https://patchwork.ozlabs.org/cover/1201373/
> > > > > > > > > > > > > 
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Chee Hong Ang (19):
> > > > > > > > > > > > >    arm: socfpga: add fit source file for pack itb with
> > > > > > > > > > > > > ATF
> > > > > > > > > > > > >    arm: socfpga: Add function for checking description
> > > > > > > > > > > > > from FIT
> > > > > > 
> > > > > > image
> > > > > > > > > > > > >    arm: socfpga: Load FIT image with ATF support
> > > > > > > > > > > > >    arm: socfpga: Override 'lowlevel_init' to support
> > > > > > > > > > > > > ATF
> > > > > > > > > > > > >    configs: socfpga: Enable FIT image loading with ATF
> > > > > > > > > > > > > support
> > > > > > > > > > > > >    arm: socfpga: Disable "spin-table" method for
> > > > > > > > > > > > > booting Linux
> > > > > > > > > > > > >    arm: socfpga: Add SMC helper function for Intel
> > > > > > > > > > > > > SOCFPGA
> > 
> > (64bits)
> > > > > > > > > > > > >    arm: socfpga: Define SMC function identifiers for
> > > > > > > > > > > > > PSCI SiP
> > 
> > services
> > > > > > > > > > > > >    arm: socfpga: Add secure register access helper
> > > > > > > > > > > > > functions for
> > 
> > SoC
> > > > > > > > > > > > >      64bits
> > > > > > > > > > > > >    arm: socfpga: Secure register access for clock
> > > > > > > > > > > > > manager (SoC
> > 
> > 64bits)
> > > > > > > > > > > > >    arm: socfpga: Secure register access in PHY mode
> > > > > > > > > > > > > setup
> > > > > > > > > > > > >    arm: socfpga: Secure register access for reading
> > > > > > > > > > > > > PLL frequency
> > > > > > > > > > > > >    mmc: dwmmc: socfpga: Secure register access in MMC
> > > > > > > > > > > > > driver
> > > > > > > > > > > > >    net: designware: socfpga: Secure register access in
> > > > > > > > > > > > > MAC driver
> > > > > > > > > > > > >    arm: socfpga: Secure register access in Reset
> > > > > > > > > > > > > Manager driver
> > > > > > > > > > > > >    arm: socfpga: stratix10: Initialize timer in SPL
> > > > > > > > > > > > >    arm: socfpga: stratix10: Refactor FPGA reconfig
> > > > > > > > > > > > > driver
> > > > > > > > > > > > > to support
> > > > > > 
> > > > > > ATF
> > > > > > > > > > > > >    arm: socfpga: Bridge reset now invokes SMC calls to
> > > > > > > > > > > > > query FPGA
> > > > > > > > 
> > > > > > > > config
> > > > > > > > > > > > >      status
> > > > > > > > > > > > >    sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > > > > > > > > > > 
> > > > > > > > > > > > > Dalon Westergreen (1):
> > > > > > > > > > > > >    configs: stratix10: Remove CONFIG_OF_EMBED
> > > > > > > > > > > > 
> > > > > > > > > > > > This one is included in another series already:
> > > > > > > > > > > > https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > Does this mean that one will be abandonen?
> > > > > > > > > > > > So the combined hex output part of that series is not
> > > > > > > > > > > > required any
> > > > > > 
> > > > > > more?
> > > > > > > > > > > > Regards,
> > > > > > > > > > > > Simon
> > > > > > > > > > > > 
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/Kconfig                      |   2 -
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/Makefile                     |   4 +
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/board.c                      |  10 +
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/clock_manager_agilex.c       |   5 +-
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/clock_manager_s10.c          |   5 +-
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/include/mach/misc.h          |   3 +
> > > > > > > > > > > > >   .../mach-
> > > > > > > > > > > > > socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/lowlevel_init.S              |  48 +++
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/misc_s10.c                   |  47 ++-
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/reset_manager_s10.c          |  31 +-
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/secure_reg_helper.c          |  67 ++++
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/timer_s10.c                  |   3 +-
> > > > > > > > > > > > >   arch/arm/mach-
> > > > > > > > > > > > > socfpga/wrap_pll_config_s10.c        |   9 +-
> > > > > > > > > > > > >  
> > > > > > > > > > > > > board/altera/soc64/its/fit_spl_atf.its             |  
> > > > > > > > > > > > > 51 +++
> > > > > > > > > > > > >  
> > > > > > > > > > > > > configs/socfpga_agilex_defconfig                   |  
> > > > > > > > > > > > >  8 +-
> > > > > > > > > > > > >  
> > > > > > > > > > > > > configs/socfpga_stratix10_defconfig                |  
> > > > > > > > > > > > >  9 +-
> > > > > > > > > > > > >   drivers/fpga/stratix10.c                           |
> > > > > > > > > > > > > 261 ++++----------
> > > > > > > > > > > > >  
> > > > > > > > > > > > > drivers/mmc/socfpga_dw_mmc.c                       |  
> > > > > > > > > > > > >  7 +-
> > > > > > > > > > > > >  
> > > > > > > > > > > > > drivers/net/dwmac_socfpga.c                        |  
> > > > > > > > > > > > >  5 +-
> > > > > > > > > > > > >  
> > > > > > > > > > > > > drivers/sysreset/sysreset_socfpga_s10.c            |  
> > > > > > > > > > > > >  4 +-
> > > > > > > > > > > > >  
> > > > > > > > > > > > > include/configs/socfpga_soc64_common.h             |  
> > > > > > > > > > > > >  2 +-
> > > > > > > > > > > > >   include/linux/intel-smc.h                          | 
> > > > > > > > > > > > > 374
> > > > > > 
> > > > > > +++++++++++++++++++++
> > > > > > > > > > > > >   22 files changed, 732 insertions(+), 243 deletions(-
> > > > > > > > > > > > > )
> > > > > > > > > > > > > create mode
> > > > > > > > > > > > > 100644
> > > > > > > > > > > > > arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > > > > > > > > > > >   create mode 100644 arch/arm/mach-
> > > > > > > > > > > > > socfpga/lowlevel_init.S
> > > > > > > > > > > > >   create mode 100644
> > > > > > > > > > > > > arch/arm/mach-socfpga/secure_reg_helper.c
> > > > > > > > > > > > >   create mode 100644
> > > > > > > > > > > > > board/altera/soc64/its/fit_spl_atf.its
> > > > > > > > > > > > >   create mode 100644 include/linux/intel-smc.h
> > > > > > > > > > > > > 
> > > > > > > > > > > > > --
> > > > > > > > > > > > > 2.7.4
> > > > > > > > > > > > > 

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

Am 03.12.2019 um 15:59 schrieb Dalon L Westergreen:
> 
> 
> On Tue, 2019-12-03 at 14:45 +0000, Ang, Chee Hong wrote:
>>> On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong <
>>> chee.hong.ang at intel.com
>>>>
>>> wrote:
>>>>> Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
>>>>>>> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
>>>>>>> <
>>>>>>> chee.hong.ang at intel.com
>>>>>>>>
>>>>>>> wrote:
>>>>>>>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
>>>>>>>>> <
>>>>>>>>> chee.hong.ang at intel.com
>>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
>>>>>>>>>>> <
>>>>>>>>>>> chee.hong.ang at intel.com
>>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM <
>>>>>>>>>>>>> chee.hong.ang at intel.com
>>>>>>>>>>>>>>
>>>>>>>
>>>>>>> wrote:
>>>>>>>>>>>>>> From: "Ang, Chee Hong" <
>>>>>>>>>>>>>> chee.hong.ang at intel.com
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> New U-boot flow with ARM Trusted Firmware (ATF)
>>>>>>>>>>>>>> support:
>>>>>>>>>>>>>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
>>>>>>>>>>>>>> Linux
>>>>>>>>>>>>>> (EL1)
>>>>>>>>>>>>>
>>>>>>>>>>>>> Adding support for ATF means that using U-Boot on
>>>>>>>>>>>>> Stratix10
>>>>>>>>>>>>> and Agilex without ATF keeps working, right?
>>>>>>>>>>>>
>>>>>>>>>>>> ATF is needed in order for Stratix10 and Agilex's U-Boot
>>>>>>>>>>>> to work.
>>>>>>>>>>>
>>>>>>>>>>> Is there a technical requirement for that?
>>>>>>>>>>
>>>>>>>>>> Yes. We are using ATF to provide PSCI services such as system
>>>>>>>>>> reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
>>>>>>>>>> other secure services such as mailbox communications with
>>>>>>>>>> Secure Device Manager and accessing the System Manager
>>>>>>>>>> registers which are
>>>>>>>
>>>>>>> secure.
>>>>>>>>>> Without PSCI services, we are able to boot until U-Boot proper
>>>>>>>>>> only.
>>>>>>>>>> Currently, our U-Boot in mainline doesn't boot to Linux due to
>>>>>>>>>> these missing
>>>>>>>>>
>>>>>>>>> PSCI services.
>>>>>>>>>> Another reason is we have another boot flow which is using ATF
>>>>>>>>>> +
>>>
>>> UEFI.
>>>>>>>>>> So now we are re-using the PSCI services from ATF so that now
>>>>>>>>>> U-Boot and UEFI share the same ATF-BL31 image so that we don't
>>>>>>>>>> have to
>>>>>>>>>
>>>>>>>>> reimplement another sets of PSCI services for U-Boot again.
>>>>>>>>>> This will greatly reduce our engineering efforts.
>>>>>>>>>
>>>>>>>>> Hmm, thanks for the explanation.
>>>>>>>>>
>>>>>>>>> I don't really think I can review this, given the lack of
>>>>>>>>> knowledge about that PSCI stuff.
>>>>>>>>
>>>>>>>> I believe you can review it.
>>>>>>>> Have you briefly gone through the patches ? It has nothing to do
>>>>>>>> with the PSCI
>>>>>>>
>>>>>>> stuff.
>>>>>>>> It just call the invoke_smc() function to call the ATF's PSCI
>>>>>>>> functions. Those PSCI functions in ATF will do the rest.
>>>>>>>
>>>>>>> No, not yet. But see below.
>>>>>>>
>>>>>>>>> I must say it seems strange to me that U-Boot would have to
>>>>>>>>> rely on ATF
>>>>>>>
>>>>>>> though.
>>>>>>>>> How do other platforms implement this? Shouldn't PSCI be
>>>>>>>>> generic or is it really platform specific? If it's generic,
>>>>>>>>> isn't that a dupliation of code if you implement e.g. a reset
>>>>>>>>> driver for
>>>>>>>>> Stratix10 but call
>>>>>>>
>>>>>>> into PSCI?
>>>>>>>> It's not strange at all.  A lot of U-Boot users already using
>>>>>>>> this boot flow (ATF +
>>>>>>>
>>>>>>> U-Boot).
>>>>>>>
>>>>>>> Just because other boards do this doesn't mean it's not strange.
>>>>>>> Wasn't there some kind of discussion around that PSCI stuff to
>>>>>>> make it
>>>>>
>>>>> available from U-Boot?
>>>>>>> What's wrong with that way?
>>>>>>
>>>>>> Our downstream U-Boot branch is already implemented the PSCI
>>>>>> stuffs in U-
>>>>>
>>>>> Boot.
>>>>>> I tried to upstream my PSCI code:
>>>>>> https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
>>>>>>
>>>>>>
>>>>>> Marek pointed me to this thread:
>>>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html
>>>>>>
>>>>>>
>>>>>> He had a point. He suggested maybe we can implement the PSCI
>>>>>> stuffs in SPL/TPL. I took a look at the U-Boot code and found out
>>>>>> ATF is already well
>>>>>
>>>>> supported. Why don't we just use the PSCI code from ATF rather than
>>>>> re- implementing the PSCI code again in SPL/TPL.
>>>>>> It will save our effort to maintain two PSCI code in U-Boot and
>>>>>> ATF while we
>>>>>
>>>>> already have the ATF PSCI implementation to support UEFI.
>>>>>
>>>>> It seems to me we do have working code in U-Boot, what's missing is
>>>>> "only" to turn it ino PSCI?
>>>>
>>>> Existing PSCI framework in U-Boot provide a way for us to turn the
>>>> code into a PSCI handler by just adding a '__secure' keyword before the
>>>
>>> function name. See:
>>>> https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga
>>>>
>>>> /mailbox_s10.c
>>>>
>>>> Below is one of the functions that has 2 versions. One 'live' in a
>>>> normal code section and another one will be relocated to "__secure"
>>>> section (for PSCI). You can see that 2 same functions are duplicated for
>>>> normal
>>>
>>> code section and PSCI section.
>>>> int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
>>>>                    u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
>>>>          return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
>>>> urgent,
>>>>                                 resp_buf_len, resp_buf); }
>>>>
>>>> int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
>>>>                                  u32 *arg, u8 urgent, u32 *resp_buf_len,
>>>>                                  u32 *resp_buf) {
>>>>          return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
>>>> urgent,
>>>>                                 resp_buf_len, resp_buf); }
>>>>
>>>> Those functions that are needed by PSCI runtime need to be duplicated for
>>>
>>> "__secure" section.
>>>> U-Boot Proper will copy and relocate the PSCI code in "__secure"
>>>> section to a location before booting Linux whereby they can be called
>>>> by Linux. Using the PSCI framework, U-Boot proper is not able to call any
>>>> PSCI
>>>
>>> functions because PSCI code is not available until U-Boot proper ready to
>>> boot
>>> Linux.
>>>> So that's the reason we need to have 2 sets of code in U-Boot. One for
>>>> SPL/U-Boot and another one for PSCI section which is used by Linux.
>>>> Currently we have 2 implementations for FPGA reconfiguration driver in our
>>>
>>> downstream branch.
>>>> One for SPL/U-Boot and another one for Linux (PSCI). FPGA
>>>> reconfiguration driver for U-Boot is already upstreamed but I don't think
>>>> I can
>>>
>>> get the FPGA reconfiguration for the PSCI part upstreamed.
>>>> They are 2 sets of different code for the same purpose. But that is
>>>> what we have done in downstream to make sure we can support Linux.
>>>>
>>>> BTW, we are going to get rid of those duplicated code for PSCI after we
>>>> switch
>>>
>>> to ATF boot flow.
>>>
>>> I think we have already discussed why that style is bad and unstable.
>>>
>>> The correct thing to do would be to compile an SPL style binary from the U-
>>> Boot
>>> sources that can replace ATF-BL31, not this messy __secure thing.
>>>
>>> I can see others (rockchip, TI, NXP?) might in part rely on ATF as well, but
>>> speaking for socfpga, if you must insist on using ATF, I would be happy if
>>> you
>>> could do it in a way that does not reduce existing functionality in U-Boot.
>>
>> Please do 'git grep CONFIG_SPL_ATF' and you will have some idea who are using
>> the ATF
>> with U-Boot. You can know which platforms are using the ATF by looking at the
>> name
>> of the defconfig files.
>>
>> BTW, what makes you think this ATF method reduce the existing functionality in
>> U-Boot ?
>> I don't really get that. I would like to know more to see what I can do to
>> ease your concern.
>>>>> And given U-Boot aims to support UEFI (kind of?), I'd rather argue:
>>>>> why do you need ATF at all?
>>>>
>>>> No, U-Boot does not aim to support UEFI. We have 2 boot flows that don't
>>>
>>> mix:
>>>
>>> Really? Or do you mean you don't aim to support EFI boot using U-Boot?
>>> I don't know that (U)EFI stuff too well, yet, but I was under the impression
>>> that
>>> Heinrich et. al. do want U-Boot to support UEFI?
>>
>> Yes. Currently, we have no plan to support (U)EFI boot with U-Boot.
>> Anyway, I am not working on UEFI boot flow. That's the work from another team.
> 
> I need to point out a miscommunication on going in this thread.  Ang is
> referring to the UEFI bootloader that currently supports socfpga devices,
> Simon is referring to EFI support in uboot which we should move to support
> and test in uboot as it is commonly used for arm64 boot, by fedora for example.
> 
> https://github.com/altera-opensource/uefi-socfpga

I'm not sure I get the difference. What's this uefi-socfpga, what does 
it and where in the below 1) and 2) would it be located?

Distributions like Fedora would use things like Grub, right? I thought 
that should work with U-Boot, too (once it's done)?

Regards,
Simon

> 
> --dalon
> 
>>>> 1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux
>>>>
>>>> 2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux
>>>>
>>>> These two boot flows now share the same code base (ATF-BL31).
>>>>> Indeed, having the same code in both seems like double effort for
>>>
>>> maintenance.
>>>>>>> In my opinion, you're reducing functionality in U-Boot by making
>>>>>>> ATF a requirement.
>>>>>>>
>>>>>>> And by saying "I can't review this", I mean this looks like a
>>>>>>> questionable way to me and I'm not the one to say if a U-Boot
>>>>>>> board should
>>>>>
>>>>> go this way or not.
>>>>>> I understand. Btw, who should I include to review this ?
>>>>>>>> Yes. PSCI is a generic software interface which encapsulate the
>>>>>>>> platform
>>>>>>>
>>>>>>> specific code.
>>>>>>>> Let me give you a good example in one of your sysreset driver
>>>>>>>> you have
>>>>>>>
>>>>>>> implemented for S10.
>>>>>>>> #include <dm.h>
>>>>>>>> #include <errno.h>
>>>>>>>> #include <sysreset.h>
>>>>>>>> -#include <asm/arch/mailbox_s10.h>
>>>>>>>>
>>>>>>>>    static int socfpga_sysreset_request(struct udevice *dev,
>>>>>>>>                                       enum sysreset_t type)  {
>>>>>>>>    -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>>>>>>>>    -      mbox_reset_cold();
>>>>>>>>    +      psci_system_reset();
>>>>>
>>>>> And coming back on this, the sysreset driver won't work in SPL any more,
>>>
>>> right?
>>>> You brought a very good point. See my comment at the bottom.
>>>>>>> So this is not an socfgpa_s10 specific driver any more, right?
>>>>
>>>> This driver code can be renamed to more generic name such as
>>>
>>> socfpga_soc64.c.
>>>> So that it can be shared by both Stratix10 and Agilex.
>>>>>>>>           return -EINPROGRESS;
>>>>>>>>    }
>>>>>>>>
>>>>>>>> Above is the changes in one of my patchsets, the sysreset driver
>>>>>>>> for
>>>>>>>> S10 used to call mbox_reset_cold() to send mailbox message to
>>>>>>>> Secure Device Manager
>>>>>>>> (SDM) to trigger COLD reset.
>>>>>>>> Calling 'mbox_reset_cold()' means you are calling platform
>>>>>>>> specific code in the sysreset driver to perform COLD reset. What
>>>>>>>> if method to trigger
>>>>>>>
>>>>>>> COLD reset is changed in new platform ?
>>>>>>>> We have to change the sysreset driver code to support another
>>>>>>>> new
>>>>>
>>>>> platform.
>>>>>>>> If this function call is replaced with "psci_system_reset()", we
>>>>>>>> don't have to change the code at all because all the platform
>>>>>>>> specific code for COLD reset is now reside in ATF because this
>>>>>>>> function just invoke the PSCI function provided by ATF. You just
>>>>>>>> have to replace the ATF binary with the new implementation for
>>>>>>>> the new platform. We can re-use this sysreset driver for any
>>>>>>>> platform that support ATF. In fact, it makes our U-Boot driver
>>>>>>>> code more 'generic' because PSCI interface stay the same. BTW,
>>>>>>>> Linux also call PSCI functions to perform COLD reset. By
>>>>>>>
>>>>>>> using ATF, U-Boot and Linux share the same COLD reset service
>>>>>>> provided by
>>>>>
>>>>> ATF.
>>>>>>> It actually reduce code duplication.
>>>>>>>
>>>>>>> What I meant was code duplication inside the U-Boot tree (having
>>>>>>> one driver for each arch but in effect all those drivers will
>>>>>>> call into the same psci
>>>>>
>>>>> function).
>>>>>> Can different archs share the same driver if the driver code is
>>>>>> common to
>>>>>
>>>>> those platforms ?
>>>>>
>>>>> I don't know why not. However, you then need a different way to
>>>>> select this
>>>>> driver: you clearly cannot use DT compatibles as this DT entry does
>>>>> not in any way stand for what you make the driver binding to it execute.
>>>>>
>>>>> Instead, I would think of a way to make your PSCI-aware U-Boot
>>>>> proper use a generic PSCI-reset driver instead of the one matching
>>>>> the devicetree. And then keep in mind you still need the DT-matching
>>>>> driver in SPL. Thinking about it, having a driver in SPL you don't
>>>>> use in U-Boot proper is probably not done, yet, as well.
>>>>
>>>> I don't have any problem with this approach (PSCI-reset driver) but it
>>>> is very easy to support SPL and U-Boot proper in the same driver by just
>>>
>>> checking the current exception level. Please take a look at the code below.
>>>> #include <dm.h>
>>>> #include <errno.h>
>>>> #include <sysreset.h>
>>>> #include <asm/arch/mailbox_s10.h>
>>>>
>>>> static int socfpga_sysreset_request(struct udevice *dev,
>>>>                                       enum sysreset_t type)  {
>>>> -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>>>> +      If (current_el() == 3)
>>>
>>> Hard-coding the EL here seems quite a hack?
>>>
>>>> +                mbox_reset_cold();
>>>> +      else
>>>> +                psci_system_reset();
>>>>          return -EINPROGRESS;
>>>> }
>>>>
>>>> We can make the sysreset driver compatible in SPL and U-Boot proper by
>>>> just
>>>
>>> checking the current exception level.
>>>> If it's EL3 (secure), we knew SPL is running and otherwise U-Boot proper
>>>> (EL2,
>>>
>>> non-secure) is running.
>>>
>>> So you compile all the PSCI stuff into SPL although never using it?
>>
>> The PSCI stuff is just a very thin layer (interface to PSCI/SMC call) since
>> real work is done in ATF.
>> Or we can do it in compile time:
>> #ifdef CONFIG_SPL_BUILD
>>       // do it in normal way
>> #else
>>      // invoke PSCI call
>> #endif
>>> I'd still prefer to have DT-compat matched drivers implementing the hardware
>>> access.
>>> Then you can instantiate different drivers in U-Boot proper if you want to
>>> use
>>> PSCI, not the hardware. Having DT-compat matched drivers do something
>>> completely different (issuing PSCI calls instead of accessing the hardware
>>> they
>>> matched on) seems wrong.
>>
>> OK.
>>> Regards,
>>> Simon
>>>
>>>> Or we can make a small generic function like below and call it from
>>>> sysreset
>>>
>>> driver code:
>>>> void soc64_cold_reset(void)
>>>> {
>>>>        If (current_el() == 3)
>>>>                  mbox_reset_cold();
>>>>        else
>>>>                  psci_system_reset();
>>>> }
>>>>
>>>>>>> What you're doing is to move this code from U-Boot open U-Boot
>>>>>>> sources to possibly closed source ATF sources. But we've already
>>>>>>> had that discussion, I think...
>>>>>>
>>>>>> Our PSCI implementation in ATF is open source:
>>>>>> https://github.com/ARM-software/arm-trusted-firmware/tree/master/p
>>>>>>
>>>>>> lat/
>>>>>> intel/soc
>>>>>
>>>>> Well, open source... Without implying anything: it's BSD, so it's
>>>>> open source as long as Intel wants it to be open source and nothing
>>>>> prevents the next manager from keeping additions or even bugfixes closed
>>>
>>> source.
>>>>> For whatever reasons might come.
>>>>>
>>>>>
>>>>> Regards,
>>>>> Simon
>>>>>
>>>>>>> Regards,
>>>>>>> Simon
>>>>>>>
>>>>>>>> I think you are aware of we are working to move the mailbox
>>>>>>>> driver code away
>>>>>>>
>>>>>>> from arch to drivers.
>>>>>>>> You will see that a lot of those mailbox functions will be
>>>>>>>> removed from the
>>>>>>>
>>>>>>> mailbox driver.
>>>>>>>> One of them is 'mbox_reset_cold()' which you called in sysreset
>>>>>>>> driver for
>>>>>
>>>>> S10.
>>>>>>>>> Regards,
>>>>>>>>> Simon
>>>>>>>>>
>>>>>>>>>>> Regard,
>>>>>>>>>>> Simon
>>>>>>>>>>>
>>>>>>>>>>>>>> SPL loads the u-boot.itb which consist of:
>>>>>>>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
>>>>>>>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
>>>>>>>>>>>>>> 3) bl31.bin (ATF-BL31 image)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
>>>>>>>>>>>>>> Agilex)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Now, U-Boot Proper is running in non-secure mode
>>>>>>>>>>>>>> (EL2), it
>>>>>>>>>>>>>> invokes SMC/PSCI calls provided by ATF to perform COLD
>>>>>>>>>>>>>> reset, System Manager register accesses and mailbox
>>>>>>>>>>>>>> communications with Secure Device Manager (SDM).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Steps to build the U-Boot with ATF support:
>>>>>>>>>>>>>> 1) Build U-Boot
>>>>>>>>>>>>>> 2) Build ATF BL31
>>>>>>>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root
>>>>>>>>>>>>>> folder
>>>>>>>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> These patchsets have dependency on:
>>>>>>>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
>>>>>>>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Chee Hong Ang (19):
>>>>>>>>>>>>>>     arm: socfpga: add fit source file for pack itb with
>>>>>>>>>>>>>> ATF
>>>>>>>>>>>>>>     arm: socfpga: Add function for checking description
>>>>>>>>>>>>>> from FIT
>>>>>>>
>>>>>>> image
>>>>>>>>>>>>>>     arm: socfpga: Load FIT image with ATF support
>>>>>>>>>>>>>>     arm: socfpga: Override 'lowlevel_init' to support
>>>>>>>>>>>>>> ATF
>>>>>>>>>>>>>>     configs: socfpga: Enable FIT image loading with ATF
>>>>>>>>>>>>>> support
>>>>>>>>>>>>>>     arm: socfpga: Disable "spin-table" method for
>>>>>>>>>>>>>> booting Linux
>>>>>>>>>>>>>>     arm: socfpga: Add SMC helper function for Intel
>>>>>>>>>>>>>> SOCFPGA
>>>
>>> (64bits)
>>>>>>>>>>>>>>     arm: socfpga: Define SMC function identifiers for
>>>>>>>>>>>>>> PSCI SiP
>>>
>>> services
>>>>>>>>>>>>>>     arm: socfpga: Add secure register access helper
>>>>>>>>>>>>>> functions for
>>>
>>> SoC
>>>>>>>>>>>>>>       64bits
>>>>>>>>>>>>>>     arm: socfpga: Secure register access for clock
>>>>>>>>>>>>>> manager (SoC
>>>
>>> 64bits)
>>>>>>>>>>>>>>     arm: socfpga: Secure register access in PHY mode
>>>>>>>>>>>>>> setup
>>>>>>>>>>>>>>     arm: socfpga: Secure register access for reading
>>>>>>>>>>>>>> PLL frequency
>>>>>>>>>>>>>>     mmc: dwmmc: socfpga: Secure register access in MMC
>>>>>>>>>>>>>> driver
>>>>>>>>>>>>>>     net: designware: socfpga: Secure register access in
>>>>>>>>>>>>>> MAC driver
>>>>>>>>>>>>>>     arm: socfpga: Secure register access in Reset
>>>>>>>>>>>>>> Manager driver
>>>>>>>>>>>>>>     arm: socfpga: stratix10: Initialize timer in SPL
>>>>>>>>>>>>>>     arm: socfpga: stratix10: Refactor FPGA reconfig
>>>>>>>>>>>>>> driver
>>>>>>>>>>>>>> to support
>>>>>>>
>>>>>>> ATF
>>>>>>>>>>>>>>     arm: socfpga: Bridge reset now invokes SMC calls to
>>>>>>>>>>>>>> query FPGA
>>>>>>>>>
>>>>>>>>> config
>>>>>>>>>>>>>>       status
>>>>>>>>>>>>>>     sysreset: socfpga: Invoke PSCI call for COLD reset
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dalon Westergreen (1):
>>>>>>>>>>>>>>     configs: stratix10: Remove CONFIG_OF_EMBED
>>>>>>>>>>>>>
>>>>>>>>>>>>> This one is included in another series already:
>>>>>>>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Does this mean that one will be abandonen?
>>>>>>>>>>>>> So the combined hex output part of that series is not
>>>>>>>>>>>>> required any
>>>>>>>
>>>>>>> more?
>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>> Simon
>>>>>>>>>>>>>
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/Kconfig                      |   2 -
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/Makefile                     |   4 +
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/board.c                      |  10 +
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/clock_manager_agilex.c       |   5 +-
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/clock_manager_s10.c          |   5 +-
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/include/mach/misc.h          |   3 +
>>>>>>>>>>>>>>    .../mach-
>>>>>>>>>>>>>> socfpga/include/mach/secure_reg_helper.h  |  20 ++
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/lowlevel_init.S              |  48 +++
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/misc_s10.c                   |  47 ++-
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/reset_manager_s10.c          |  31 +-
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/secure_reg_helper.c          |  67 ++++
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/timer_s10.c                  |   3 +-
>>>>>>>>>>>>>>    arch/arm/mach-
>>>>>>>>>>>>>> socfpga/wrap_pll_config_s10.c        |   9 +-
>>>>>>>>>>>>>>   
>>>>>>>>>>>>>> board/altera/soc64/its/fit_spl_atf.its             |
>>>>>>>>>>>>>> 51 +++
>>>>>>>>>>>>>>   
>>>>>>>>>>>>>> configs/socfpga_agilex_defconfig                   |
>>>>>>>>>>>>>>   8 +-
>>>>>>>>>>>>>>   
>>>>>>>>>>>>>> configs/socfpga_stratix10_defconfig                |
>>>>>>>>>>>>>>   9 +-
>>>>>>>>>>>>>>    drivers/fpga/stratix10.c                           |
>>>>>>>>>>>>>> 261 ++++----------
>>>>>>>>>>>>>>   
>>>>>>>>>>>>>> drivers/mmc/socfpga_dw_mmc.c                       |
>>>>>>>>>>>>>>   7 +-
>>>>>>>>>>>>>>   
>>>>>>>>>>>>>> drivers/net/dwmac_socfpga.c                        |
>>>>>>>>>>>>>>   5 +-
>>>>>>>>>>>>>>   
>>>>>>>>>>>>>> drivers/sysreset/sysreset_socfpga_s10.c            |
>>>>>>>>>>>>>>   4 +-
>>>>>>>>>>>>>>   
>>>>>>>>>>>>>> include/configs/socfpga_soc64_common.h             |
>>>>>>>>>>>>>>   2 +-
>>>>>>>>>>>>>>    include/linux/intel-smc.h                          |
>>>>>>>>>>>>>> 374
>>>>>>>
>>>>>>> +++++++++++++++++++++
>>>>>>>>>>>>>>    22 files changed, 732 insertions(+), 243 deletions(-
>>>>>>>>>>>>>> )
>>>>>>>>>>>>>> create mode
>>>>>>>>>>>>>> 100644
>>>>>>>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
>>>>>>>>>>>>>>    create mode 100644 arch/arm/mach-
>>>>>>>>>>>>>> socfpga/lowlevel_init.S
>>>>>>>>>>>>>>    create mode 100644
>>>>>>>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
>>>>>>>>>>>>>>    create mode 100644
>>>>>>>>>>>>>> board/altera/soc64/its/fit_spl_atf.its
>>>>>>>>>>>>>>    create mode 100644 include/linux/intel-smc.h
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> 2.7.4
>>>>>>>>>>>>>>
> 

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Tom Rini]

On Tue, Dec 03, 2019 at 09:09:48PM +0100, Simon Goldschmidt wrote:
> Am 03.12.2019 um 15:59 schrieb Dalon L Westergreen:
> > 
> > 
> > On Tue, 2019-12-03 at 14:45 +0000, Ang, Chee Hong wrote:
> > > > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong <
> > > > chee.hong.ang at intel.com
> > > > > 
> > > > wrote:
> > > > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
> > > > > > > > On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> > > > > > > > <
> > > > > > > > chee.hong.ang at intel.com
> > > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > > > > > > > > > <
> > > > > > > > > > chee.hong.ang at intel.com
> > > > > > > > > > > 
> > > > > > > > > > wrote:
> > > > > > > > > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > > > > > > > > > > <
> > > > > > > > > > > > chee.hong.ang at intel.com
> > > > > > > > > > > > > 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM <
> > > > > > > > > > > > > > chee.hong.ang at intel.com
> > > > > > > > > > > > > > > 
> > > > > > > > 
> > > > > > > > wrote:
> > > > > > > > > > > > > > > From: "Ang, Chee Hong" <
> > > > > > > > > > > > > > > chee.hong.ang at intel.com
> > > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > 
> > > > > > > > > > > > > > > New U-boot flow with ARM Trusted Firmware (ATF)
> > > > > > > > > > > > > > > support:
> > > > > > > > > > > > > > > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
> > > > > > > > > > > > > > > Linux
> > > > > > > > > > > > > > > (EL1)
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > > Adding support for ATF means that using U-Boot on
> > > > > > > > > > > > > > Stratix10
> > > > > > > > > > > > > > and Agilex without ATF keeps working, right?
> > > > > > > > > > > > > 
> > > > > > > > > > > > > ATF is needed in order for Stratix10 and Agilex's U-Boot
> > > > > > > > > > > > > to work.
> > > > > > > > > > > > 
> > > > > > > > > > > > Is there a technical requirement for that?
> > > > > > > > > > > 
> > > > > > > > > > > Yes. We are using ATF to provide PSCI services such as system
> > > > > > > > > > > reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> > > > > > > > > > > other secure services such as mailbox communications with
> > > > > > > > > > > Secure Device Manager and accessing the System Manager
> > > > > > > > > > > registers which are
> > > > > > > > 
> > > > > > > > secure.
> > > > > > > > > > > Without PSCI services, we are able to boot until U-Boot proper
> > > > > > > > > > > only.
> > > > > > > > > > > Currently, our U-Boot in mainline doesn't boot to Linux due to
> > > > > > > > > > > these missing
> > > > > > > > > > 
> > > > > > > > > > PSCI services.
> > > > > > > > > > > Another reason is we have another boot flow which is using ATF
> > > > > > > > > > > +
> > > > 
> > > > UEFI.
> > > > > > > > > > > So now we are re-using the PSCI services from ATF so that now
> > > > > > > > > > > U-Boot and UEFI share the same ATF-BL31 image so that we don't
> > > > > > > > > > > have to
> > > > > > > > > > 
> > > > > > > > > > reimplement another sets of PSCI services for U-Boot again.
> > > > > > > > > > > This will greatly reduce our engineering efforts.
> > > > > > > > > > 
> > > > > > > > > > Hmm, thanks for the explanation.
> > > > > > > > > > 
> > > > > > > > > > I don't really think I can review this, given the lack of
> > > > > > > > > > knowledge about that PSCI stuff.
> > > > > > > > > 
> > > > > > > > > I believe you can review it.
> > > > > > > > > Have you briefly gone through the patches ? It has nothing to do
> > > > > > > > > with the PSCI
> > > > > > > > 
> > > > > > > > stuff.
> > > > > > > > > It just call the invoke_smc() function to call the ATF's PSCI
> > > > > > > > > functions. Those PSCI functions in ATF will do the rest.
> > > > > > > > 
> > > > > > > > No, not yet. But see below.
> > > > > > > > 
> > > > > > > > > > I must say it seems strange to me that U-Boot would have to
> > > > > > > > > > rely on ATF
> > > > > > > > 
> > > > > > > > though.
> > > > > > > > > > How do other platforms implement this? Shouldn't PSCI be
> > > > > > > > > > generic or is it really platform specific? If it's generic,
> > > > > > > > > > isn't that a dupliation of code if you implement e.g. a reset
> > > > > > > > > > driver for
> > > > > > > > > > Stratix10 but call
> > > > > > > > 
> > > > > > > > into PSCI?
> > > > > > > > > It's not strange at all.  A lot of U-Boot users already using
> > > > > > > > > this boot flow (ATF +
> > > > > > > > 
> > > > > > > > U-Boot).
> > > > > > > > 
> > > > > > > > Just because other boards do this doesn't mean it's not strange.
> > > > > > > > Wasn't there some kind of discussion around that PSCI stuff to
> > > > > > > > make it
> > > > > > 
> > > > > > available from U-Boot?
> > > > > > > > What's wrong with that way?
> > > > > > > 
> > > > > > > Our downstream U-Boot branch is already implemented the PSCI
> > > > > > > stuffs in U-
> > > > > > 
> > > > > > Boot.
> > > > > > > I tried to upstream my PSCI code:
> > > > > > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> > > > > > > 
> > > > > > > 
> > > > > > > Marek pointed me to this thread:
> > > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html
> > > > > > > 
> > > > > > > 
> > > > > > > He had a point. He suggested maybe we can implement the PSCI
> > > > > > > stuffs in SPL/TPL. I took a look at the U-Boot code and found out
> > > > > > > ATF is already well
> > > > > > 
> > > > > > supported. Why don't we just use the PSCI code from ATF rather than
> > > > > > re- implementing the PSCI code again in SPL/TPL.
> > > > > > > It will save our effort to maintain two PSCI code in U-Boot and
> > > > > > > ATF while we
> > > > > > 
> > > > > > already have the ATF PSCI implementation to support UEFI.
> > > > > > 
> > > > > > It seems to me we do have working code in U-Boot, what's missing is
> > > > > > "only" to turn it ino PSCI?
> > > > > 
> > > > > Existing PSCI framework in U-Boot provide a way for us to turn the
> > > > > code into a PSCI handler by just adding a '__secure' keyword before the
> > > > 
> > > > function name. See:
> > > > > https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga
> > > > > 
> > > > > /mailbox_s10.c
> > > > > 
> > > > > Below is one of the functions that has 2 versions. One 'live' in a
> > > > > normal code section and another one will be relocated to "__secure"
> > > > > section (for PSCI). You can see that 2 same functions are duplicated for
> > > > > normal
> > > > 
> > > > code section and PSCI section.
> > > > > int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
> > > > >                    u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
> > > > >          return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
> > > > > urgent,
> > > > >                                 resp_buf_len, resp_buf); }
> > > > > 
> > > > > int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
> > > > >                                  u32 *arg, u8 urgent, u32 *resp_buf_len,
> > > > >                                  u32 *resp_buf) {
> > > > >          return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
> > > > > urgent,
> > > > >                                 resp_buf_len, resp_buf); }
> > > > > 
> > > > > Those functions that are needed by PSCI runtime need to be duplicated for
> > > > 
> > > > "__secure" section.
> > > > > U-Boot Proper will copy and relocate the PSCI code in "__secure"
> > > > > section to a location before booting Linux whereby they can be called
> > > > > by Linux. Using the PSCI framework, U-Boot proper is not able to call any
> > > > > PSCI
> > > > 
> > > > functions because PSCI code is not available until U-Boot proper ready to
> > > > boot
> > > > Linux.
> > > > > So that's the reason we need to have 2 sets of code in U-Boot. One for
> > > > > SPL/U-Boot and another one for PSCI section which is used by Linux.
> > > > > Currently we have 2 implementations for FPGA reconfiguration driver in our
> > > > 
> > > > downstream branch.
> > > > > One for SPL/U-Boot and another one for Linux (PSCI). FPGA
> > > > > reconfiguration driver for U-Boot is already upstreamed but I don't think
> > > > > I can
> > > > 
> > > > get the FPGA reconfiguration for the PSCI part upstreamed.
> > > > > They are 2 sets of different code for the same purpose. But that is
> > > > > what we have done in downstream to make sure we can support Linux.
> > > > > 
> > > > > BTW, we are going to get rid of those duplicated code for PSCI after we
> > > > > switch
> > > > 
> > > > to ATF boot flow.
> > > > 
> > > > I think we have already discussed why that style is bad and unstable.
> > > > 
> > > > The correct thing to do would be to compile an SPL style binary from the U-
> > > > Boot
> > > > sources that can replace ATF-BL31, not this messy __secure thing.
> > > > 
> > > > I can see others (rockchip, TI, NXP?) might in part rely on ATF as well, but
> > > > speaking for socfpga, if you must insist on using ATF, I would be happy if
> > > > you
> > > > could do it in a way that does not reduce existing functionality in U-Boot.
> > > 
> > > Please do 'git grep CONFIG_SPL_ATF' and you will have some idea who are using
> > > the ATF
> > > with U-Boot. You can know which platforms are using the ATF by looking at the
> > > name
> > > of the defconfig files.
> > > 
> > > BTW, what makes you think this ATF method reduce the existing functionality in
> > > U-Boot ?
> > > I don't really get that. I would like to know more to see what I can do to
> > > ease your concern.
> > > > > > And given U-Boot aims to support UEFI (kind of?), I'd rather argue:
> > > > > > why do you need ATF at all?
> > > > > 
> > > > > No, U-Boot does not aim to support UEFI. We have 2 boot flows that don't
> > > > 
> > > > mix:
> > > > 
> > > > Really? Or do you mean you don't aim to support EFI boot using U-Boot?
> > > > I don't know that (U)EFI stuff too well, yet, but I was under the impression
> > > > that
> > > > Heinrich et. al. do want U-Boot to support UEFI?
> > > 
> > > Yes. Currently, we have no plan to support (U)EFI boot with U-Boot.
> > > Anyway, I am not working on UEFI boot flow. That's the work from another team.
> > 
> > I need to point out a miscommunication on going in this thread.  Ang is
> > referring to the UEFI bootloader that currently supports socfpga devices,
> > Simon is referring to EFI support in uboot which we should move to support
> > and test in uboot as it is commonly used for arm64 boot, by fedora for example.
> > 
> > https://github.com/altera-opensource/uefi-socfpga
> 
> I'm not sure I get the difference. What's this uefi-socfpga, what does it
> and where in the below 1) and 2) would it be located?

It's the altera tree of EDK II / Tianocore.  That is to say, a full UEFI
implementation as the firmware.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20191203/efcce78d/attachment.sig>

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

On Tue, Dec 3, 2019 at 3:45 PM Ang, Chee Hong <chee.hong.ang@intel.com> wrote:
>
> > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong <chee.hong.ang@intel.com>
> > wrote:
> > >
> > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
> > > > >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> > > > >> <chee.hong.ang@intel.com>
> > > > >> wrote:
> > > > >>>
> > > > >>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > > > >>>> <chee.hong.ang@intel.com>
> > > > >>>> wrote:
> > > > >>>>>
> > > > >>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > > >>>>>> <chee.hong.ang@intel.com>
> > > > >>>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com>
> > > > >> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > >>>>>>>>>
> > > > >>>>>>>>> New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > >>>>>>>>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
> > > > >>>>>>>>> Linux
> > > > >>>>>>>>> (EL1)
> > > > >>>>>>>>
> > > > >>>>>>>> Adding support for ATF means that using U-Boot on Stratix10
> > > > >>>>>>>> and Agilex without ATF keeps working, right?
> > > > >>>>>>> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > > > >>>>>>
> > > > >>>>>> Is there a technical requirement for that?
> > > > >>>>> Yes. We are using ATF to provide PSCI services such as system
> > > > >>>>> reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in Linux) and
> > > > >>>>> other secure services such as mailbox communications with
> > > > >>>>> Secure Device Manager and accessing the System Manager
> > > > >>>>> registers which are
> > > > >> secure.
> > > > >>>>> Without PSCI services, we are able to boot until U-Boot proper only.
> > > > >>>>> Currently, our U-Boot in mainline doesn't boot to Linux due to
> > > > >>>>> these missing
> > > > >>>> PSCI services.
> > > > >>>>> Another reason is we have another boot flow which is using ATF +
> > UEFI.
> > > > >>>>> So now we are re-using the PSCI services from ATF so that now
> > > > >>>>> U-Boot and UEFI share the same ATF-BL31 image so that we don't
> > > > >>>>> have to
> > > > >>>> reimplement another sets of PSCI services for U-Boot again.
> > > > >>>>> This will greatly reduce our engineering efforts.
> > > > >>>>
> > > > >>>> Hmm, thanks for the explanation.
> > > > >>>>
> > > > >>>> I don't really think I can review this, given the lack of
> > > > >>>> knowledge about that PSCI stuff.
> > > > >>> I believe you can review it.
> > > > >>> Have you briefly gone through the patches ? It has nothing to do
> > > > >>> with the PSCI
> > > > >> stuff.
> > > > >>> It just call the invoke_smc() function to call the ATF's PSCI
> > > > >>> functions. Those PSCI functions in ATF will do the rest.
> > > > >>
> > > > >> No, not yet. But see below.
> > > > >>
> > > > >>>>
> > > > >>>> I must say it seems strange to me that U-Boot would have to
> > > > >>>> rely on ATF
> > > > >> though.
> > > > >>>> How do other platforms implement this? Shouldn't PSCI be
> > > > >>>> generic or is it really platform specific? If it's generic,
> > > > >>>> isn't that a dupliation of code if you implement e.g. a reset
> > > > >>>> driver for
> > > > >>>> Stratix10 but call
> > > > >> into PSCI?
> > > > >>> It's not strange at all.  A lot of U-Boot users already using
> > > > >>> this boot flow (ATF +
> > > > >> U-Boot).
> > > > >>
> > > > >> Just because other boards do this doesn't mean it's not strange.
> > > > >> Wasn't there some kind of discussion around that PSCI stuff to
> > > > >> make it
> > > > available from U-Boot?
> > > > >> What's wrong with that way?
> > > > > Our downstream U-Boot branch is already implemented the PSCI
> > > > > stuffs in U-
> > > > Boot.
> > > > > I tried to upstream my PSCI code:
> > > > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> > > > >
> > > > > Marek pointed me to this thread:
> > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.html
> > > > >
> > > > > He had a point. He suggested maybe we can implement the PSCI
> > > > > stuffs in SPL/TPL. I took a look at the U-Boot code and found out
> > > > > ATF is already well
> > > > supported. Why don't we just use the PSCI code from ATF rather than
> > > > re- implementing the PSCI code again in SPL/TPL.
> > > > > It will save our effort to maintain two PSCI code in U-Boot and
> > > > > ATF while we
> > > > already have the ATF PSCI implementation to support UEFI.
> > > >
> > > > It seems to me we do have working code in U-Boot, what's missing is
> > > > "only" to turn it ino PSCI?
> > > Existing PSCI framework in U-Boot provide a way for us to turn the
> > > code into a PSCI handler by just adding a '__secure' keyword before the
> > function name. See:
> > > https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-socfpga
> > > /mailbox_s10.c
> > >
> > > Below is one of the functions that has 2 versions. One 'live' in a
> > > normal code section and another one will be relocated to "__secure"
> > > section (for PSCI). You can see that 2 same functions are duplicated for normal
> > code section and PSCI section.
> > >
> > > int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
> > >                   u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
> > >         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
> > >                                resp_buf_len, resp_buf); }
> > >
> > > int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
> > >                                 u32 *arg, u8 urgent, u32 *resp_buf_len,
> > >                                 u32 *resp_buf) {
> > >         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
> > >                                resp_buf_len, resp_buf); }
> > >
> > > Those functions that are needed by PSCI runtime need to be duplicated for
> > "__secure" section.
> > > U-Boot Proper will copy and relocate the PSCI code in "__secure"
> > > section to a location before booting Linux whereby they can be called
> > > by Linux. Using the PSCI framework, U-Boot proper is not able to call any PSCI
> > functions because PSCI code is not available until U-Boot proper ready to boot
> > Linux.
> > > So that's the reason we need to have 2 sets of code in U-Boot. One for
> > > SPL/U-Boot and another one for PSCI section which is used by Linux.
> > > Currently we have 2 implementations for FPGA reconfiguration driver in our
> > downstream branch.
> > > One for SPL/U-Boot and another one for Linux (PSCI). FPGA
> > > reconfiguration driver for U-Boot is already upstreamed but I don't think I can
> > get the FPGA reconfiguration for the PSCI part upstreamed.
> > > They are 2 sets of different code for the same purpose. But that is
> > > what we have done in downstream to make sure we can support Linux.
> > >
> > > BTW, we are going to get rid of those duplicated code for PSCI after we switch
> > to ATF boot flow.
> >
> > I think we have already discussed why that style is bad and unstable.
> >
> > The correct thing to do would be to compile an SPL style binary from the U-Boot
> > sources that can replace ATF-BL31, not this messy __secure thing.
> >
> > I can see others (rockchip, TI, NXP?) might in part rely on ATF as well, but
> > speaking for socfpga, if you must insist on using ATF, I would be happy if you
> > could do it in a way that does not reduce existing functionality in U-Boot.
> Please do 'git grep CONFIG_SPL_ATF' and you will have some idea who are using the ATF
> with U-Boot. You can know which platforms are using the ATF by looking at the name
> of the defconfig files.

That's where I found Rockchip, TI and NXP. I see I missed Xilinx.

>
> BTW, what makes you think this ATF method reduce the existing functionality in U-Boot ?
> I don't really get that. I would like to know more to see what I can do to ease your concern.

You're making U-Boot (GPL-licensed) depend on ATF (BSD-licensed). That's my
main concern.

Then, you're making the whole build more complicated by having to build 2
independent projects (in matching versions, as they share at least one header
file).

I'd say it would be more straightforward to integrate PSCI services into
U-Boot. I know that comes at the expense of someone taking the time to fix
U-Boot PSCI support from "__secure" to a proper way. But I think the result
would be cleaner.

Added to that, with what you told me so far, you reduce U-Boot functionality
by making the existing drivers in U-Boot proper require PSCI services, so
U-Boot won't run standalone if you decide to not use ATF.

> >
> > > >
> > > > And given U-Boot aims to support UEFI (kind of?), I'd rather argue:
> > > > why do you need ATF at all?
> > >
> > > No, U-Boot does not aim to support UEFI. We have 2 boot flows that don't
> > mix:
> >
> > Really? Or do you mean you don't aim to support EFI boot using U-Boot?
> > I don't know that (U)EFI stuff too well, yet, but I was under the impression that
> > Heinrich et. al. do want U-Boot to support UEFI?
> Yes. Currently, we have no plan to support (U)EFI boot with U-Boot.
> Anyway, I am not working on UEFI boot flow. That's the work from another team.
> >
> > >
> > > 1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux
> > >
> > > 2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux
> > >
> > > These two boot flows now share the same code base (ATF-BL31).
> > > >
> > > > Indeed, having the same code in both seems like double effort for
> > maintenance.
> > > >
> > > > >>
> > > > >> In my opinion, you're reducing functionality in U-Boot by making
> > > > >> ATF a requirement.
> > > > >>
> > > > >> And by saying "I can't review this", I mean this looks like a
> > > > >> questionable way to me and I'm not the one to say if a U-Boot
> > > > >> board should
> > > > go this way or not.
> > > > > I understand. Btw, who should I include to review this ?
> > > > >>
> > > > >>> Yes. PSCI is a generic software interface which encapsulate the
> > > > >>> platform
> > > > >> specific code.
> > > > >>> Let me give you a good example in one of your sysreset driver
> > > > >>> you have
> > > > >> implemented for S10.
> > > > >>>
> > > > >>> #include <dm.h>
> > > > >>> #include <errno.h>
> > > > >>> #include <sysreset.h>
> > > > >>> -#include <asm/arch/mailbox_s10.h>
> > > > >>>
> > > > >>>   static int socfpga_sysreset_request(struct udevice *dev,
> > > > >>>                                      enum sysreset_t type)  {
> > > > >>>   -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > > > >>>   -      mbox_reset_cold();
> > > > >>>   +      psci_system_reset();
> > > >
> > > > And coming back on this, the sysreset driver won't work in SPL any more,
> > right?
> > > You brought a very good point. See my comment at the bottom.
> > > >
> > > > >>
> > > > >> So this is not an socfgpa_s10 specific driver any more, right?
> > > This driver code can be renamed to more generic name such as
> > socfpga_soc64.c.
> > > So that it can be shared by both Stratix10 and Agilex.
> > > > >>
> > > > >>>          return -EINPROGRESS;
> > > > >>>   }
> > > > >>>
> > > > >>> Above is the changes in one of my patchsets, the sysreset driver
> > > > >>> for
> > > > >>> S10 used to call mbox_reset_cold() to send mailbox message to
> > > > >>> Secure Device Manager
> > > > >>> (SDM) to trigger COLD reset.
> > > > >>> Calling 'mbox_reset_cold()' means you are calling platform
> > > > >>> specific code in the sysreset driver to perform COLD reset. What
> > > > >>> if method to trigger
> > > > >> COLD reset is changed in new platform ?
> > > > >>> We have to change the sysreset driver code to support another
> > > > >>> new
> > > > platform.
> > > > >>> If this function call is replaced with "psci_system_reset()", we
> > > > >>> don't have to change the code at all because all the platform
> > > > >>> specific code for COLD reset is now reside in ATF because this
> > > > >>> function just invoke the PSCI function provided by ATF. You just
> > > > >>> have to replace the ATF binary with the new implementation for
> > > > >>> the new platform. We can re-use this sysreset driver for any
> > > > >>> platform that support ATF. In fact, it makes our U-Boot driver
> > > > >>> code more 'generic' because PSCI interface stay the same. BTW,
> > > > >>> Linux also call PSCI functions to perform COLD reset. By
> > > > >> using ATF, U-Boot and Linux share the same COLD reset service
> > > > >> provided by
> > > > ATF.
> > > > >> It actually reduce code duplication.
> > > > >>
> > > > >> What I meant was code duplication inside the U-Boot tree (having
> > > > >> one driver for each arch but in effect all those drivers will
> > > > >> call into the same psci
> > > > function).
> > > > > Can different archs share the same driver if the driver code is
> > > > > common to
> > > > those platforms ?
> > > >
> > > > I don't know why not. However, you then need a different way to
> > > > select this
> > > > driver: you clearly cannot use DT compatibles as this DT entry does
> > > > not in any way stand for what you make the driver binding to it execute.
> > > >
> > > > Instead, I would think of a way to make your PSCI-aware U-Boot
> > > > proper use a generic PSCI-reset driver instead of the one matching
> > > > the devicetree. And then keep in mind you still need the DT-matching
> > > > driver in SPL. Thinking about it, having a driver in SPL you don't
> > > > use in U-Boot proper is probably not done, yet, as well.
> > > I don't have any problem with this approach (PSCI-reset driver) but it
> > > is very easy to support SPL and U-Boot proper in the same driver by just
> > checking the current exception level. Please take a look at the code below.
> > >
> > > #include <dm.h>
> > > #include <errno.h>
> > > #include <sysreset.h>
> > > #include <asm/arch/mailbox_s10.h>
> > >
> > > static int socfpga_sysreset_request(struct udevice *dev,
> > >                                      enum sysreset_t type)  {
> > > -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > > +      If (current_el() == 3)
> >
> > Hard-coding the EL here seems quite a hack?
> >
> > > +                mbox_reset_cold();
> > > +      else
> > > +                psci_system_reset();
> > >         return -EINPROGRESS;
> > > }
> > >
> > > We can make the sysreset driver compatible in SPL and U-Boot proper by just
> > checking the current exception level.
> > > If it's EL3 (secure), we knew SPL is running and otherwise U-Boot proper (EL2,
> > non-secure) is running.
> >
> > So you compile all the PSCI stuff into SPL although never using it?
> The PSCI stuff is just a very thin layer (interface to PSCI/SMC call) since real work is done in ATF.
> Or we can do it in compile time:
> #ifdef CONFIG_SPL_BUILD
>      // do it in normal way
> #else
>     // invoke PSCI call
> #endif
> >
> > I'd still prefer to have DT-compat matched drivers implementing the hardware
> > access.
> > Then you can instantiate different drivers in U-Boot proper if you want to use
> > PSCI, not the hardware. Having DT-compat matched drivers do something
> > completely different (issuing PSCI calls instead of accessing the hardware they
> > matched on) seems wrong.
> OK.
> >
> > Regards,
> > Simon
> >
> > > Or we can make a small generic function like below and call it from sysreset
> > driver code:
> > >
> > > void soc64_cold_reset(void)
> > > {
> > >       If (current_el() == 3)
> > >                 mbox_reset_cold();
> > >       else
> > >                 psci_system_reset();
> > > }
> > >
> > > >
> > > > >
> > > > >> What you're doing is to move this code from U-Boot open U-Boot
> > > > >> sources to possibly closed source ATF sources. But we've already
> > > > >> had that discussion, I think...
> > > > > Our PSCI implementation in ATF is open source:
> > > > > https://github.com/ARM-software/arm-trusted-firmware/tree/master/p
> > > > > lat/
> > > > > intel/soc
> > > >
> > > > Well, open source... Without implying anything: it's BSD, so it's
> > > > open source as long as Intel wants it to be open source and nothing
> > > > prevents the next manager from keeping additions or even bugfixes closed
> > source.
> > > > For whatever reasons might come.
> > > >
> > > >
> > > > Regards,
> > > > Simon
> > > >
> > > > >
> > > > >>
> > > > >> Regards,
> > > > >> Simon
> > > > >>
> > > > >>>
> > > > >>> I think you are aware of we are working to move the mailbox
> > > > >>> driver code away
> > > > >> from arch to drivers.
> > > > >>> You will see that a lot of those mailbox functions will be
> > > > >>> removed from the
> > > > >> mailbox driver.
> > > > >>> One of them is 'mbox_reset_cold()' which you called in sysreset
> > > > >>> driver for
> > > > S10.
> > > > >>>
> > > > >>>> Regards,
> > > > >>>> Simon
> > > > >>>>
> > > > >>>>>>
> > > > >>>>>> Regard,
> > > > >>>>>> Simon
> > > > >>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>> SPL loads the u-boot.itb which consist of:
> > > > >>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > >>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
> > > > >>>>>>>>> 3) bl31.bin (ATF-BL31 image)
> > > > >>>>>>>>>
> > > > >>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
> > > > >>>>>>>>> Agilex)
> > > > >>>>>>>>>
> > > > >>>>>>>>> Now, U-Boot Proper is running in non-secure mode (EL2), it
> > > > >>>>>>>>> invokes SMC/PSCI calls provided by ATF to perform COLD
> > > > >>>>>>>>> reset, System Manager register accesses and mailbox
> > > > >>>>>>>>> communications with Secure Device Manager (SDM).
> > > > >>>>>>>>>
> > > > >>>>>>>>> Steps to build the U-Boot with ATF support:
> > > > >>>>>>>>> 1) Build U-Boot
> > > > >>>>>>>>> 2) Build ATF BL31
> > > > >>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root folder
> > > > >>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
> > > > >>>>>>>>>
> > > > >>>>>>>>> These patchsets have dependency on:
> > > > >>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > >>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
> > > > >>>>>>>>>
> > > > >>>>>>>>> Chee Hong Ang (19):
> > > > >>>>>>>>>    arm: socfpga: add fit source file for pack itb with ATF
> > > > >>>>>>>>>    arm: socfpga: Add function for checking description
> > > > >>>>>>>>> from FIT
> > > > >> image
> > > > >>>>>>>>>    arm: socfpga: Load FIT image with ATF support
> > > > >>>>>>>>>    arm: socfpga: Override 'lowlevel_init' to support ATF
> > > > >>>>>>>>>    configs: socfpga: Enable FIT image loading with ATF support
> > > > >>>>>>>>>    arm: socfpga: Disable "spin-table" method for booting Linux
> > > > >>>>>>>>>    arm: socfpga: Add SMC helper function for Intel SOCFPGA
> > (64bits)
> > > > >>>>>>>>>    arm: socfpga: Define SMC function identifiers for PSCI SiP
> > services
> > > > >>>>>>>>>    arm: socfpga: Add secure register access helper functions for
> > SoC
> > > > >>>>>>>>>      64bits
> > > > >>>>>>>>>    arm: socfpga: Secure register access for clock manager (SoC
> > 64bits)
> > > > >>>>>>>>>    arm: socfpga: Secure register access in PHY mode setup
> > > > >>>>>>>>>    arm: socfpga: Secure register access for reading PLL frequency
> > > > >>>>>>>>>    mmc: dwmmc: socfpga: Secure register access in MMC driver
> > > > >>>>>>>>>    net: designware: socfpga: Secure register access in MAC driver
> > > > >>>>>>>>>    arm: socfpga: Secure register access in Reset Manager driver
> > > > >>>>>>>>>    arm: socfpga: stratix10: Initialize timer in SPL
> > > > >>>>>>>>>    arm: socfpga: stratix10: Refactor FPGA reconfig driver
> > > > >>>>>>>>> to support
> > > > >> ATF
> > > > >>>>>>>>>    arm: socfpga: Bridge reset now invokes SMC calls to
> > > > >>>>>>>>> query FPGA
> > > > >>>> config
> > > > >>>>>>>>>      status
> > > > >>>>>>>>>    sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > >>>>>>>>>
> > > > >>>>>>>>> Dalon Westergreen (1):
> > > > >>>>>>>>>    configs: stratix10: Remove CONFIG_OF_EMBED
> > > > >>>>>>>>
> > > > >>>>>>>> This one is included in another series already:
> > > > >>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=132976
> > > > >>>>>>>>
> > > > >>>>>>>> Does this mean that one will be abandonen?
> > > > >>>>>>>> So the combined hex output part of that series is not
> > > > >>>>>>>> required any
> > > > >> more?
> > > > >>>>>>>>
> > > > >>>>>>>> Regards,
> > > > >>>>>>>> Simon
> > > > >>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>>   arch/arm/mach-socfpga/Kconfig                      |   2 -
> > > > >>>>>>>>>   arch/arm/mach-socfpga/Makefile                     |   4 +
> > > > >>>>>>>>>   arch/arm/mach-socfpga/board.c                      |  10 +
> > > > >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > > > >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > > > >>>>>>>>>   arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > > > >>>>>>>>>   .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> > > > >>>>>>>>>   arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > > > >>>>>>>>>   arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > > > >>>>>>>>>   arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > > > >>>>>>>>>   arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> > > > >>>>>>>>>   arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > > > >>>>>>>>>   arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > > > >>>>>>>>>   board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > > > >>>>>>>>>   configs/socfpga_agilex_defconfig                   |   8 +-
> > > > >>>>>>>>>   configs/socfpga_stratix10_defconfig                |   9 +-
> > > > >>>>>>>>>   drivers/fpga/stratix10.c                           | 261 ++++----------
> > > > >>>>>>>>>   drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > > > >>>>>>>>>   drivers/net/dwmac_socfpga.c                        |   5 +-
> > > > >>>>>>>>>   drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > > > >>>>>>>>>   include/configs/socfpga_soc64_common.h             |   2 +-
> > > > >>>>>>>>>   include/linux/intel-smc.h                          | 374
> > > > >> +++++++++++++++++++++
> > > > >>>>>>>>>   22 files changed, 732 insertions(+), 243 deletions(-)
> > > > >>>>>>>>> create mode
> > > > >>>>>>>>> 100644
> > > > >>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > > >>>>>>>>>   create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> > > > >>>>>>>>>   create mode 100644
> > > > >>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
> > > > >>>>>>>>>   create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > > > >>>>>>>>>   create mode 100644 include/linux/intel-smc.h
> > > > >>>>>>>>>
> > > > >>>>>>>>> --
> > > > >>>>>>>>> 2.7.4
> > > > >>>>>>>>>
> > >

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> On Tue, Dec 3, 2019 at 3:45 PM Ang, Chee Hong <chee.hong.ang@intel.com>
> wrote:
> >
> > > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong
> > > <chee.hong.ang@intel.com>
> > > wrote:
> > > >
> > > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
> > > > > >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> > > > > >> <chee.hong.ang@intel.com>
> > > > > >> wrote:
> > > > > >>>
> > > > > >>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> > > > > >>>> <chee.hong.ang@intel.com>
> > > > > >>>> wrote:
> > > > > >>>>>
> > > > > >>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > > > > >>>>>> <chee.hong.ang@intel.com>
> > > > > >>>>>> wrote:
> > > > > >>>>>>>
> > > > > >>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM
> > > > > >>>>>>>> <chee.hong.ang@intel.com>
> > > > > >> wrote:
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> New U-boot flow with ARM Trusted Firmware (ATF) support:
> > > > > >>>>>>>>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
> > > > > >>>>>>>>> Linux
> > > > > >>>>>>>>> (EL1)
> > > > > >>>>>>>>
> > > > > >>>>>>>> Adding support for ATF means that using U-Boot on
> > > > > >>>>>>>> Stratix10 and Agilex without ATF keeps working, right?
> > > > > >>>>>>> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> > > > > >>>>>>
> > > > > >>>>>> Is there a technical requirement for that?
> > > > > >>>>> Yes. We are using ATF to provide PSCI services such as
> > > > > >>>>> system reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in
> > > > > >>>>> Linux) and other secure services such as mailbox
> > > > > >>>>> communications with Secure Device Manager and accessing
> > > > > >>>>> the System Manager registers which are
> > > > > >> secure.
> > > > > >>>>> Without PSCI services, we are able to boot until U-Boot proper
> only.
> > > > > >>>>> Currently, our U-Boot in mainline doesn't boot to Linux
> > > > > >>>>> due to these missing
> > > > > >>>> PSCI services.
> > > > > >>>>> Another reason is we have another boot flow which is using
> > > > > >>>>> ATF +
> > > UEFI.
> > > > > >>>>> So now we are re-using the PSCI services from ATF so that
> > > > > >>>>> now U-Boot and UEFI share the same ATF-BL31 image so that
> > > > > >>>>> we don't have to
> > > > > >>>> reimplement another sets of PSCI services for U-Boot again.
> > > > > >>>>> This will greatly reduce our engineering efforts.
> > > > > >>>>
> > > > > >>>> Hmm, thanks for the explanation.
> > > > > >>>>
> > > > > >>>> I don't really think I can review this, given the lack of
> > > > > >>>> knowledge about that PSCI stuff.
> > > > > >>> I believe you can review it.
> > > > > >>> Have you briefly gone through the patches ? It has nothing
> > > > > >>> to do with the PSCI
> > > > > >> stuff.
> > > > > >>> It just call the invoke_smc() function to call the ATF's
> > > > > >>> PSCI functions. Those PSCI functions in ATF will do the rest.
> > > > > >>
> > > > > >> No, not yet. But see below.
> > > > > >>
> > > > > >>>>
> > > > > >>>> I must say it seems strange to me that U-Boot would have to
> > > > > >>>> rely on ATF
> > > > > >> though.
> > > > > >>>> How do other platforms implement this? Shouldn't PSCI be
> > > > > >>>> generic or is it really platform specific? If it's generic,
> > > > > >>>> isn't that a dupliation of code if you implement e.g. a
> > > > > >>>> reset driver for
> > > > > >>>> Stratix10 but call
> > > > > >> into PSCI?
> > > > > >>> It's not strange at all.  A lot of U-Boot users already
> > > > > >>> using this boot flow (ATF +
> > > > > >> U-Boot).
> > > > > >>
> > > > > >> Just because other boards do this doesn't mean it's not strange.
> > > > > >> Wasn't there some kind of discussion around that PSCI stuff
> > > > > >> to make it
> > > > > available from U-Boot?
> > > > > >> What's wrong with that way?
> > > > > > Our downstream U-Boot branch is already implemented the PSCI
> > > > > > stuffs in U-
> > > > > Boot.
> > > > > > I tried to upstream my PSCI code:
> > > > > > https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> > > > > >
> > > > > > Marek pointed me to this thread:
> > > > > > https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.ht
> > > > > > ml
> > > > > >
> > > > > > He had a point. He suggested maybe we can implement the PSCI
> > > > > > stuffs in SPL/TPL. I took a look at the U-Boot code and found
> > > > > > out ATF is already well
> > > > > supported. Why don't we just use the PSCI code from ATF rather
> > > > > than
> > > > > re- implementing the PSCI code again in SPL/TPL.
> > > > > > It will save our effort to maintain two PSCI code in U-Boot
> > > > > > and ATF while we
> > > > > already have the ATF PSCI implementation to support UEFI.
> > > > >
> > > > > It seems to me we do have working code in U-Boot, what's missing
> > > > > is "only" to turn it ino PSCI?
> > > > Existing PSCI framework in U-Boot provide a way for us to turn the
> > > > code into a PSCI handler by just adding a '__secure' keyword
> > > > before the
> > > function name. See:
> > > > https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-soc
> > > > fpga
> > > > /mailbox_s10.c
> > > >
> > > > Below is one of the functions that has 2 versions. One 'live' in a
> > > > normal code section and another one will be relocated to "__secure"
> > > > section (for PSCI). You can see that 2 same functions are
> > > > duplicated for normal
> > > code section and PSCI section.
> > > >
> > > > int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
> > > >                   u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
> > > >         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
> > > >                                resp_buf_len, resp_buf); }
> > > >
> > > > int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
> > > >                                 u32 *arg, u8 urgent, u32 *resp_buf_len,
> > > >                                 u32 *resp_buf) {
> > > >         return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
> > > >                                resp_buf_len, resp_buf); }
> > > >
> > > > Those functions that are needed by PSCI runtime need to be
> > > > duplicated for
> > > "__secure" section.
> > > > U-Boot Proper will copy and relocate the PSCI code in "__secure"
> > > > section to a location before booting Linux whereby they can be
> > > > called by Linux. Using the PSCI framework, U-Boot proper is not
> > > > able to call any PSCI
> > > functions because PSCI code is not available until U-Boot proper
> > > ready to boot Linux.
> > > > So that's the reason we need to have 2 sets of code in U-Boot. One
> > > > for SPL/U-Boot and another one for PSCI section which is used by Linux.
> > > > Currently we have 2 implementations for FPGA reconfiguration
> > > > driver in our
> > > downstream branch.
> > > > One for SPL/U-Boot and another one for Linux (PSCI). FPGA
> > > > reconfiguration driver for U-Boot is already upstreamed but I
> > > > don't think I can
> > > get the FPGA reconfiguration for the PSCI part upstreamed.
> > > > They are 2 sets of different code for the same purpose. But that
> > > > is what we have done in downstream to make sure we can support Linux.
> > > >
> > > > BTW, we are going to get rid of those duplicated code for PSCI
> > > > after we switch
> > > to ATF boot flow.
> > >
> > > I think we have already discussed why that style is bad and unstable.
> > >
> > > The correct thing to do would be to compile an SPL style binary from
> > > the U-Boot sources that can replace ATF-BL31, not this messy __secure thing.
> > >
> > > I can see others (rockchip, TI, NXP?) might in part rely on ATF as
> > > well, but speaking for socfpga, if you must insist on using ATF, I
> > > would be happy if you could do it in a way that does not reduce existing
> functionality in U-Boot.
> > Please do 'git grep CONFIG_SPL_ATF' and you will have some idea who
> > are using the ATF with U-Boot. You can know which platforms are using
> > the ATF by looking at the name of the defconfig files.
> 
> That's where I found Rockchip, TI and NXP. I see I missed Xilinx.
> 
> >
> > BTW, what makes you think this ATF method reduce the existing functionality
> in U-Boot ?
> > I don't really get that. I would like to know more to see what I can do to ease
> your concern.
> 
> You're making U-Boot (GPL-licensed) depend on ATF (BSD-licensed). That's my
> main concern.
> 
> Then, you're making the whole build more complicated by having to build 2
> independent projects (in matching versions, as they share at least one header
> file).
> 
> I'd say it would be more straightforward to integrate PSCI services into U-Boot. I
> know that comes at the expense of someone taking the time to fix U-Boot PSCI
> support from "__secure" to a proper way. But I think the result would be cleaner.
> 
> Added to that, with what you told me so far, you reduce U-Boot functionality by
> making the existing drivers in U-Boot proper require PSCI services, so U-Boot
> won't run standalone if you decide to not use ATF.
We are trying to combine the best of both worlds (SPL/U-Boot + ATF) where
we get to enjoy the existing benefits of using U-Boot and solid/well implemented
PSCI services + ARMv8 extensions from ATF.
Linux depends on those standard PSCI services such as CPU hotplug and etc and
they are well implemented in ATF to avoid race conditions when waking/suspending
the CPU cores. Besides, ATF also provide various ARMv8 extensions (such as RAS) to OS.
So using ATF with U-Boot is much more than just PSCI.

Beside the time/effort needed to fix the existing U-Boot PSCI issue, having a solid and well implemented PSCI
services and ARMv8 extensions in U-Boot is another huge effort. We also need to ensure these
implementations are well maintained and up to date with the PSCI/ARMv8 extensions specification from time to time.

From U-Boot perspective, you have made some valid points.
We understand using ATF with U-Boot do come with a cost.
So far, the whole discussion only revolved around the issues/impact between ATF and U-Boot. 
Let's not forget the fact that ultimately most users will end up in OS environment (Linux) after
SPL & U-Boot proper and this is what ATF do best by providing well implemented
PSCI services and ARMv8 extensions to Linux. It might not be your concern.
But that's the benefits we see and I personally think this is one of the main reasons ATF support gets enabled in U-Boot.
> 
> > >
> > > > >
> > > > > And given U-Boot aims to support UEFI (kind of?), I'd rather argue:
> > > > > why do you need ATF at all?
> > > >
> > > > No, U-Boot does not aim to support UEFI. We have 2 boot flows that
> > > > don't
> > > mix:
> > >
> > > Really? Or do you mean you don't aim to support EFI boot using U-Boot?
> > > I don't know that (U)EFI stuff too well, yet, but I was under the
> > > impression that Heinrich et. al. do want U-Boot to support UEFI?
> > Yes. Currently, we have no plan to support (U)EFI boot with U-Boot.
> > Anyway, I am not working on UEFI boot flow. That's the work from another
> team.
> > >
> > > >
> > > > 1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux
> > > >
> > > > 2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux
> > > >
> > > > These two boot flows now share the same code base (ATF-BL31).
> > > > >
> > > > > Indeed, having the same code in both seems like double effort
> > > > > for
> > > maintenance.
> > > > >
> > > > > >>
> > > > > >> In my opinion, you're reducing functionality in U-Boot by
> > > > > >> making ATF a requirement.
> > > > > >>
> > > > > >> And by saying "I can't review this", I mean this looks like a
> > > > > >> questionable way to me and I'm not the one to say if a U-Boot
> > > > > >> board should
> > > > > go this way or not.
> > > > > > I understand. Btw, who should I include to review this ?
> > > > > >>
> > > > > >>> Yes. PSCI is a generic software interface which encapsulate
> > > > > >>> the platform
> > > > > >> specific code.
> > > > > >>> Let me give you a good example in one of your sysreset
> > > > > >>> driver you have
> > > > > >> implemented for S10.
> > > > > >>>
> > > > > >>> #include <dm.h>
> > > > > >>> #include <errno.h>
> > > > > >>> #include <sysreset.h>
> > > > > >>> -#include <asm/arch/mailbox_s10.h>
> > > > > >>>
> > > > > >>>   static int socfpga_sysreset_request(struct udevice *dev,
> > > > > >>>                                      enum sysreset_t type)  {
> > > > > >>>   -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > > > > >>>   -      mbox_reset_cold();
> > > > > >>>   +      psci_system_reset();
> > > > >
> > > > > And coming back on this, the sysreset driver won't work in SPL
> > > > > any more,
> > > right?
> > > > You brought a very good point. See my comment at the bottom.
> > > > >
> > > > > >>
> > > > > >> So this is not an socfgpa_s10 specific driver any more, right?
> > > > This driver code can be renamed to more generic name such as
> > > socfpga_soc64.c.
> > > > So that it can be shared by both Stratix10 and Agilex.
> > > > > >>
> > > > > >>>          return -EINPROGRESS;
> > > > > >>>   }
> > > > > >>>
> > > > > >>> Above is the changes in one of my patchsets, the sysreset
> > > > > >>> driver for
> > > > > >>> S10 used to call mbox_reset_cold() to send mailbox message
> > > > > >>> to Secure Device Manager
> > > > > >>> (SDM) to trigger COLD reset.
> > > > > >>> Calling 'mbox_reset_cold()' means you are calling platform
> > > > > >>> specific code in the sysreset driver to perform COLD reset.
> > > > > >>> What if method to trigger
> > > > > >> COLD reset is changed in new platform ?
> > > > > >>> We have to change the sysreset driver code to support
> > > > > >>> another new
> > > > > platform.
> > > > > >>> If this function call is replaced with
> > > > > >>> "psci_system_reset()", we don't have to change the code at
> > > > > >>> all because all the platform specific code for COLD reset is
> > > > > >>> now reside in ATF because this function just invoke the PSCI
> > > > > >>> function provided by ATF. You just have to replace the ATF
> > > > > >>> binary with the new implementation for the new platform. We
> > > > > >>> can re-use this sysreset driver for any platform that
> > > > > >>> support ATF. In fact, it makes our U-Boot driver code more
> > > > > >>> 'generic' because PSCI interface stay the same. BTW, Linux
> > > > > >>> also call PSCI functions to perform COLD reset. By
> > > > > >> using ATF, U-Boot and Linux share the same COLD reset service
> > > > > >> provided by
> > > > > ATF.
> > > > > >> It actually reduce code duplication.
> > > > > >>
> > > > > >> What I meant was code duplication inside the U-Boot tree
> > > > > >> (having one driver for each arch but in effect all those
> > > > > >> drivers will call into the same psci
> > > > > function).
> > > > > > Can different archs share the same driver if the driver code
> > > > > > is common to
> > > > > those platforms ?
> > > > >
> > > > > I don't know why not. However, you then need a different way to
> > > > > select this
> > > > > driver: you clearly cannot use DT compatibles as this DT entry
> > > > > does not in any way stand for what you make the driver binding to it
> execute.
> > > > >
> > > > > Instead, I would think of a way to make your PSCI-aware U-Boot
> > > > > proper use a generic PSCI-reset driver instead of the one
> > > > > matching the devicetree. And then keep in mind you still need
> > > > > the DT-matching driver in SPL. Thinking about it, having a
> > > > > driver in SPL you don't use in U-Boot proper is probably not done, yet, as
> well.
> > > > I don't have any problem with this approach (PSCI-reset driver)
> > > > but it is very easy to support SPL and U-Boot proper in the same
> > > > driver by just
> > > checking the current exception level. Please take a look at the code below.
> > > >
> > > > #include <dm.h>
> > > > #include <errno.h>
> > > > #include <sysreset.h>
> > > > #include <asm/arch/mailbox_s10.h>
> > > >
> > > > static int socfpga_sysreset_request(struct udevice *dev,
> > > >                                      enum sysreset_t type)  {
> > > > -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> > > > +      If (current_el() == 3)
> > >
> > > Hard-coding the EL here seems quite a hack?
> > >
> > > > +                mbox_reset_cold();
> > > > +      else
> > > > +                psci_system_reset();
> > > >         return -EINPROGRESS;
> > > > }
> > > >
> > > > We can make the sysreset driver compatible in SPL and U-Boot
> > > > proper by just
> > > checking the current exception level.
> > > > If it's EL3 (secure), we knew SPL is running and otherwise U-Boot
> > > > proper (EL2,
> > > non-secure) is running.
> > >
> > > So you compile all the PSCI stuff into SPL although never using it?
> > The PSCI stuff is just a very thin layer (interface to PSCI/SMC call) since real
> work is done in ATF.
> > Or we can do it in compile time:
> > #ifdef CONFIG_SPL_BUILD
> >      // do it in normal way
> > #else
> >     // invoke PSCI call
> > #endif
> > >
> > > I'd still prefer to have DT-compat matched drivers implementing the
> > > hardware access.
> > > Then you can instantiate different drivers in U-Boot proper if you
> > > want to use PSCI, not the hardware. Having DT-compat matched drivers
> > > do something completely different (issuing PSCI calls instead of
> > > accessing the hardware they matched on) seems wrong.
> > OK.
> > >
> > > Regards,
> > > Simon
> > >
> > > > Or we can make a small generic function like below and call it
> > > > from sysreset
> > > driver code:
> > > >
> > > > void soc64_cold_reset(void)
> > > > {
> > > >       If (current_el() == 3)
> > > >                 mbox_reset_cold();
> > > >       else
> > > >                 psci_system_reset(); }
> > > >
> > > > >
> > > > > >
> > > > > >> What you're doing is to move this code from U-Boot open
> > > > > >> U-Boot sources to possibly closed source ATF sources. But
> > > > > >> we've already had that discussion, I think...
> > > > > > Our PSCI implementation in ATF is open source:
> > > > > > https://github.com/ARM-software/arm-trusted-firmware/tree/mast
> > > > > > er/p
> > > > > > lat/
> > > > > > intel/soc
> > > > >
> > > > > Well, open source... Without implying anything: it's BSD, so
> > > > > it's open source as long as Intel wants it to be open source and
> > > > > nothing prevents the next manager from keeping additions or even
> > > > > bugfixes closed
> > > source.
> > > > > For whatever reasons might come.
> > > > >
> > > > >
> > > > > Regards,
> > > > > Simon
> > > > >
> > > > > >
> > > > > >>
> > > > > >> Regards,
> > > > > >> Simon
> > > > > >>
> > > > > >>>
> > > > > >>> I think you are aware of we are working to move the mailbox
> > > > > >>> driver code away
> > > > > >> from arch to drivers.
> > > > > >>> You will see that a lot of those mailbox functions will be
> > > > > >>> removed from the
> > > > > >> mailbox driver.
> > > > > >>> One of them is 'mbox_reset_cold()' which you called in
> > > > > >>> sysreset driver for
> > > > > S10.
> > > > > >>>
> > > > > >>>> Regards,
> > > > > >>>> Simon
> > > > > >>>>
> > > > > >>>>>>
> > > > > >>>>>> Regard,
> > > > > >>>>>> Simon
> > > > > >>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> SPL loads the u-boot.itb which consist of:
> > > > > >>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
> > > > > >>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
> > > > > >>>>>>>>> 3) bl31.bin (ATF-BL31 image)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
> > > > > >>>>>>>>> Agilex)
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Now, U-Boot Proper is running in non-secure mode
> > > > > >>>>>>>>> (EL2), it invokes SMC/PSCI calls provided by ATF to
> > > > > >>>>>>>>> perform COLD reset, System Manager register accesses
> > > > > >>>>>>>>> and mailbox communications with Secure Device Manager
> (SDM).
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Steps to build the U-Boot with ATF support:
> > > > > >>>>>>>>> 1) Build U-Boot
> > > > > >>>>>>>>> 2) Build ATF BL31
> > > > > >>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root
> > > > > >>>>>>>>> folder
> > > > > >>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> These patchsets have dependency on:
> > > > > >>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > > > > >>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Chee Hong Ang (19):
> > > > > >>>>>>>>>    arm: socfpga: add fit source file for pack itb with ATF
> > > > > >>>>>>>>>    arm: socfpga: Add function for checking description
> > > > > >>>>>>>>> from FIT
> > > > > >> image
> > > > > >>>>>>>>>    arm: socfpga: Load FIT image with ATF support
> > > > > >>>>>>>>>    arm: socfpga: Override 'lowlevel_init' to support ATF
> > > > > >>>>>>>>>    configs: socfpga: Enable FIT image loading with ATF support
> > > > > >>>>>>>>>    arm: socfpga: Disable "spin-table" method for booting Linux
> > > > > >>>>>>>>>    arm: socfpga: Add SMC helper function for Intel
> > > > > >>>>>>>>> SOCFPGA
> > > (64bits)
> > > > > >>>>>>>>>    arm: socfpga: Define SMC function identifiers for
> > > > > >>>>>>>>> PSCI SiP
> > > services
> > > > > >>>>>>>>>    arm: socfpga: Add secure register access helper
> > > > > >>>>>>>>> functions for
> > > SoC
> > > > > >>>>>>>>>      64bits
> > > > > >>>>>>>>>    arm: socfpga: Secure register access for clock
> > > > > >>>>>>>>> manager (SoC
> > > 64bits)
> > > > > >>>>>>>>>    arm: socfpga: Secure register access in PHY mode setup
> > > > > >>>>>>>>>    arm: socfpga: Secure register access for reading PLL
> frequency
> > > > > >>>>>>>>>    mmc: dwmmc: socfpga: Secure register access in MMC
> driver
> > > > > >>>>>>>>>    net: designware: socfpga: Secure register access in MAC
> driver
> > > > > >>>>>>>>>    arm: socfpga: Secure register access in Reset Manager
> driver
> > > > > >>>>>>>>>    arm: socfpga: stratix10: Initialize timer in SPL
> > > > > >>>>>>>>>    arm: socfpga: stratix10: Refactor FPGA reconfig
> > > > > >>>>>>>>> driver to support
> > > > > >> ATF
> > > > > >>>>>>>>>    arm: socfpga: Bridge reset now invokes SMC calls to
> > > > > >>>>>>>>> query FPGA
> > > > > >>>> config
> > > > > >>>>>>>>>      status
> > > > > >>>>>>>>>    sysreset: socfpga: Invoke PSCI call for COLD reset
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> Dalon Westergreen (1):
> > > > > >>>>>>>>>    configs: stratix10: Remove CONFIG_OF_EMBED
> > > > > >>>>>>>>
> > > > > >>>>>>>> This one is included in another series already:
> > > > > >>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=13
> > > > > >>>>>>>> 2976
> > > > > >>>>>>>>
> > > > > >>>>>>>> Does this mean that one will be abandonen?
> > > > > >>>>>>>> So the combined hex output part of that series is not
> > > > > >>>>>>>> required any
> > > > > >> more?
> > > > > >>>>>>>>
> > > > > >>>>>>>> Regards,
> > > > > >>>>>>>> Simon
> > > > > >>>>>>>>
> > > > > >>>>>>>>>
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/Kconfig                      |   2 -
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/Makefile                     |   4 +
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/board.c                      |  10 +
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> > > > > >>>>>>>>>   .../mach-socfpga/include/mach/secure_reg_helper.h  |  20
> ++
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/secure_reg_helper.c          |  67
> ++++
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> > > > > >>>>>>>>>   arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> > > > > >>>>>>>>>   board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> > > > > >>>>>>>>>   configs/socfpga_agilex_defconfig                   |   8 +-
> > > > > >>>>>>>>>   configs/socfpga_stratix10_defconfig                |   9 +-
> > > > > >>>>>>>>>   drivers/fpga/stratix10.c                           | 261 ++++----------
> > > > > >>>>>>>>>   drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> > > > > >>>>>>>>>   drivers/net/dwmac_socfpga.c                        |   5 +-
> > > > > >>>>>>>>>   drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> > > > > >>>>>>>>>   include/configs/socfpga_soc64_common.h             |   2 +-
> > > > > >>>>>>>>>   include/linux/intel-smc.h                          | 374
> > > > > >> +++++++++++++++++++++
> > > > > >>>>>>>>>   22 files changed, 732 insertions(+), 243
> > > > > >>>>>>>>> deletions(-) create mode
> > > > > >>>>>>>>> 100644
> > > > > >>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> > > > > >>>>>>>>>   create mode 100644 arch/arm/mach-
> socfpga/lowlevel_init.S
> > > > > >>>>>>>>>   create mode 100644
> > > > > >>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
> > > > > >>>>>>>>>   create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > > > > >>>>>>>>>   create mode 100644 include/linux/intel-smc.h
> > > > > >>>>>>>>>
> > > > > >>>>>>>>> --
> > > > > >>>>>>>>> 2.7.4
> > > > > >>>>>>>>>
> > > >

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

Am 03.12.2019 um 19:31 schrieb Ang, Chee Hong:
>> On Tue, Dec 3, 2019 at 3:45 PM Ang, Chee Hong <chee.hong.ang@intel.com>
>> wrote:
>>>
>>>> On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong
>>>> <chee.hong.ang@intel.com>
>>>> wrote:
>>>>>
>>>>>> Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
>>>>>>>> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
>>>>>>>> <chee.hong.ang@intel.com>
>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
>>>>>>>>>> <chee.hong.ang@intel.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
>>>>>>>>>>>> <chee.hong.ang@intel.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM
>>>>>>>>>>>>>> <chee.hong.ang@intel.com>
>>>>>>>> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> New U-boot flow with ARM Trusted Firmware (ATF) support:
>>>>>>>>>>>>>>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
>>>>>>>>>>>>>>> Linux
>>>>>>>>>>>>>>> (EL1)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Adding support for ATF means that using U-Boot on
>>>>>>>>>>>>>> Stratix10 and Agilex without ATF keeps working, right?
>>>>>>>>>>>>> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
>>>>>>>>>>>>
>>>>>>>>>>>> Is there a technical requirement for that?
>>>>>>>>>>> Yes. We are using ATF to provide PSCI services such as
>>>>>>>>>>> system reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in
>>>>>>>>>>> Linux) and other secure services such as mailbox
>>>>>>>>>>> communications with Secure Device Manager and accessing
>>>>>>>>>>> the System Manager registers which are
>>>>>>>> secure.
>>>>>>>>>>> Without PSCI services, we are able to boot until U-Boot proper
>> only.
>>>>>>>>>>> Currently, our U-Boot in mainline doesn't boot to Linux
>>>>>>>>>>> due to these missing
>>>>>>>>>> PSCI services.
>>>>>>>>>>> Another reason is we have another boot flow which is using
>>>>>>>>>>> ATF +
>>>> UEFI.
>>>>>>>>>>> So now we are re-using the PSCI services from ATF so that
>>>>>>>>>>> now U-Boot and UEFI share the same ATF-BL31 image so that
>>>>>>>>>>> we don't have to
>>>>>>>>>> reimplement another sets of PSCI services for U-Boot again.
>>>>>>>>>>> This will greatly reduce our engineering efforts.
>>>>>>>>>>
>>>>>>>>>> Hmm, thanks for the explanation.
>>>>>>>>>>
>>>>>>>>>> I don't really think I can review this, given the lack of
>>>>>>>>>> knowledge about that PSCI stuff.
>>>>>>>>> I believe you can review it.
>>>>>>>>> Have you briefly gone through the patches ? It has nothing
>>>>>>>>> to do with the PSCI
>>>>>>>> stuff.
>>>>>>>>> It just call the invoke_smc() function to call the ATF's
>>>>>>>>> PSCI functions. Those PSCI functions in ATF will do the rest.
>>>>>>>>
>>>>>>>> No, not yet. But see below.
>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> I must say it seems strange to me that U-Boot would have to
>>>>>>>>>> rely on ATF
>>>>>>>> though.
>>>>>>>>>> How do other platforms implement this? Shouldn't PSCI be
>>>>>>>>>> generic or is it really platform specific? If it's generic,
>>>>>>>>>> isn't that a dupliation of code if you implement e.g. a
>>>>>>>>>> reset driver for
>>>>>>>>>> Stratix10 but call
>>>>>>>> into PSCI?
>>>>>>>>> It's not strange at all.  A lot of U-Boot users already
>>>>>>>>> using this boot flow (ATF +
>>>>>>>> U-Boot).
>>>>>>>>
>>>>>>>> Just because other boards do this doesn't mean it's not strange.
>>>>>>>> Wasn't there some kind of discussion around that PSCI stuff
>>>>>>>> to make it
>>>>>> available from U-Boot?
>>>>>>>> What's wrong with that way?
>>>>>>> Our downstream U-Boot branch is already implemented the PSCI
>>>>>>> stuffs in U-
>>>>>> Boot.
>>>>>>> I tried to upstream my PSCI code:
>>>>>>> https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
>>>>>>>
>>>>>>> Marek pointed me to this thread:
>>>>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.ht
>>>>>>> ml
>>>>>>>
>>>>>>> He had a point. He suggested maybe we can implement the PSCI
>>>>>>> stuffs in SPL/TPL. I took a look at the U-Boot code and found
>>>>>>> out ATF is already well
>>>>>> supported. Why don't we just use the PSCI code from ATF rather
>>>>>> than
>>>>>> re- implementing the PSCI code again in SPL/TPL.
>>>>>>> It will save our effort to maintain two PSCI code in U-Boot
>>>>>>> and ATF while we
>>>>>> already have the ATF PSCI implementation to support UEFI.
>>>>>>
>>>>>> It seems to me we do have working code in U-Boot, what's missing
>>>>>> is "only" to turn it ino PSCI?
>>>>> Existing PSCI framework in U-Boot provide a way for us to turn the
>>>>> code into a PSCI handler by just adding a '__secure' keyword
>>>>> before the
>>>> function name. See:
>>>>> https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-soc
>>>>> fpga
>>>>> /mailbox_s10.c
>>>>>
>>>>> Below is one of the functions that has 2 versions. One 'live' in a
>>>>> normal code section and another one will be relocated to "__secure"
>>>>> section (for PSCI). You can see that 2 same functions are
>>>>> duplicated for normal
>>>> code section and PSCI section.
>>>>>
>>>>> int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
>>>>>                    u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
>>>>>          return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
>>>>>                                 resp_buf_len, resp_buf); }
>>>>>
>>>>> int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
>>>>>                                  u32 *arg, u8 urgent, u32 *resp_buf_len,
>>>>>                                  u32 *resp_buf) {
>>>>>          return mbox_send_cmd_common(id, cmd, is_indirect, len, arg, urgent,
>>>>>                                 resp_buf_len, resp_buf); }
>>>>>
>>>>> Those functions that are needed by PSCI runtime need to be
>>>>> duplicated for
>>>> "__secure" section.
>>>>> U-Boot Proper will copy and relocate the PSCI code in "__secure"
>>>>> section to a location before booting Linux whereby they can be
>>>>> called by Linux. Using the PSCI framework, U-Boot proper is not
>>>>> able to call any PSCI
>>>> functions because PSCI code is not available until U-Boot proper
>>>> ready to boot Linux.
>>>>> So that's the reason we need to have 2 sets of code in U-Boot. One
>>>>> for SPL/U-Boot and another one for PSCI section which is used by Linux.
>>>>> Currently we have 2 implementations for FPGA reconfiguration
>>>>> driver in our
>>>> downstream branch.
>>>>> One for SPL/U-Boot and another one for Linux (PSCI). FPGA
>>>>> reconfiguration driver for U-Boot is already upstreamed but I
>>>>> don't think I can
>>>> get the FPGA reconfiguration for the PSCI part upstreamed.
>>>>> They are 2 sets of different code for the same purpose. But that
>>>>> is what we have done in downstream to make sure we can support Linux.
>>>>>
>>>>> BTW, we are going to get rid of those duplicated code for PSCI
>>>>> after we switch
>>>> to ATF boot flow.
>>>>
>>>> I think we have already discussed why that style is bad and unstable.
>>>>
>>>> The correct thing to do would be to compile an SPL style binary from
>>>> the U-Boot sources that can replace ATF-BL31, not this messy __secure thing.
>>>>
>>>> I can see others (rockchip, TI, NXP?) might in part rely on ATF as
>>>> well, but speaking for socfpga, if you must insist on using ATF, I
>>>> would be happy if you could do it in a way that does not reduce existing
>> functionality in U-Boot.
>>> Please do 'git grep CONFIG_SPL_ATF' and you will have some idea who
>>> are using the ATF with U-Boot. You can know which platforms are using
>>> the ATF by looking at the name of the defconfig files.
>>
>> That's where I found Rockchip, TI and NXP. I see I missed Xilinx.
>>
>>>
>>> BTW, what makes you think this ATF method reduce the existing functionality
>> in U-Boot ?
>>> I don't really get that. I would like to know more to see what I can do to ease
>> your concern.
>>
>> You're making U-Boot (GPL-licensed) depend on ATF (BSD-licensed). That's my
>> main concern.
>>
>> Then, you're making the whole build more complicated by having to build 2
>> independent projects (in matching versions, as they share at least one header
>> file).
>>
>> I'd say it would be more straightforward to integrate PSCI services into U-Boot. I
>> know that comes at the expense of someone taking the time to fix U-Boot PSCI
>> support from "__secure" to a proper way. But I think the result would be cleaner.
>>
>> Added to that, with what you told me so far, you reduce U-Boot functionality by
>> making the existing drivers in U-Boot proper require PSCI services, so U-Boot
>> won't run standalone if you decide to not use ATF.
> We are trying to combine the best of both worlds (SPL/U-Boot + ATF) where
> we get to enjoy the existing benefits of using U-Boot and solid/well implemented
> PSCI services + ARMv8 extensions from ATF.
> Linux depends on those standard PSCI services such as CPU hotplug and etc and
> they are well implemented in ATF to avoid race conditions when waking/suspending
> the CPU cores. Besides, ATF also provide various ARMv8 extensions (such as RAS) to OS.
> So using ATF with U-Boot is much more than just PSCI.
> 
> Beside the time/effort needed to fix the existing U-Boot PSCI issue, having a solid and well implemented PSCI
> services and ARMv8 extensions in U-Boot is another huge effort. We also need to ensure these
> implementations are well maintained and up to date with the PSCI/ARMv8 extensions specification from time to time.
> 
>  From U-Boot perspective, you have made some valid points.
> We understand using ATF with U-Boot do come with a cost.
> So far, the whole discussion only revolved around the issues/impact between ATF and U-Boot.
> Let's not forget the fact that ultimately most users will end up in OS environment (Linux) after
> SPL & U-Boot proper and this is what ATF do best by providing well implemented
> PSCI services and ARMv8 extensions to Linux. It might not be your concern.

As you might have noticed, I'm using gen5 with Linux at the moment and 
might at some point in the future be migrating to a 64-bit ARM, so that 
might well be S10/Agilex or some kind of stripped down version of that, 
you never know. So yes, in the future, this might be my concern :-)

> But that's the benefits we see and I personally think this is one of the main reasons ATF support gets enabled in U-Boot.

I don't want to hold you back from using ATF + U-Boot. I only say I'm 
not convinced stripping down U-Boot functionality with that move is the 
way to go.

And I think it would be better to hard-code this at compile time (given 
the knowledge SPL -> raw, U-Boot -> via ATF) than evaluating EL.

Keeping that aside, what's the "secure" benefit of allowing register 
read/write/modify access via invoke_smc vs. directly modifying registers?

Regards,
Simon

>>
>>>>
>>>>>>
>>>>>> And given U-Boot aims to support UEFI (kind of?), I'd rather argue:
>>>>>> why do you need ATF at all?
>>>>>
>>>>> No, U-Boot does not aim to support UEFI. We have 2 boot flows that
>>>>> don't
>>>> mix:
>>>>
>>>> Really? Or do you mean you don't aim to support EFI boot using U-Boot?
>>>> I don't know that (U)EFI stuff too well, yet, but I was under the
>>>> impression that Heinrich et. al. do want U-Boot to support UEFI?
>>> Yes. Currently, we have no plan to support (U)EFI boot with U-Boot.
>>> Anyway, I am not working on UEFI boot flow. That's the work from another
>> team.
>>>>
>>>>>
>>>>> 1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux
>>>>>
>>>>> 2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux
>>>>>
>>>>> These two boot flows now share the same code base (ATF-BL31).
>>>>>>
>>>>>> Indeed, having the same code in both seems like double effort
>>>>>> for
>>>> maintenance.
>>>>>>
>>>>>>>>
>>>>>>>> In my opinion, you're reducing functionality in U-Boot by
>>>>>>>> making ATF a requirement.
>>>>>>>>
>>>>>>>> And by saying "I can't review this", I mean this looks like a
>>>>>>>> questionable way to me and I'm not the one to say if a U-Boot
>>>>>>>> board should
>>>>>> go this way or not.
>>>>>>> I understand. Btw, who should I include to review this ?
>>>>>>>>
>>>>>>>>> Yes. PSCI is a generic software interface which encapsulate
>>>>>>>>> the platform
>>>>>>>> specific code.
>>>>>>>>> Let me give you a good example in one of your sysreset
>>>>>>>>> driver you have
>>>>>>>> implemented for S10.
>>>>>>>>>
>>>>>>>>> #include <dm.h>
>>>>>>>>> #include <errno.h>
>>>>>>>>> #include <sysreset.h>
>>>>>>>>> -#include <asm/arch/mailbox_s10.h>
>>>>>>>>>
>>>>>>>>>    static int socfpga_sysreset_request(struct udevice *dev,
>>>>>>>>>                                       enum sysreset_t type)  {
>>>>>>>>>    -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>>>>>>>>>    -      mbox_reset_cold();
>>>>>>>>>    +      psci_system_reset();
>>>>>>
>>>>>> And coming back on this, the sysreset driver won't work in SPL
>>>>>> any more,
>>>> right?
>>>>> You brought a very good point. See my comment at the bottom.
>>>>>>
>>>>>>>>
>>>>>>>> So this is not an socfgpa_s10 specific driver any more, right?
>>>>> This driver code can be renamed to more generic name such as
>>>> socfpga_soc64.c.
>>>>> So that it can be shared by both Stratix10 and Agilex.
>>>>>>>>
>>>>>>>>>           return -EINPROGRESS;
>>>>>>>>>    }
>>>>>>>>>
>>>>>>>>> Above is the changes in one of my patchsets, the sysreset
>>>>>>>>> driver for
>>>>>>>>> S10 used to call mbox_reset_cold() to send mailbox message
>>>>>>>>> to Secure Device Manager
>>>>>>>>> (SDM) to trigger COLD reset.
>>>>>>>>> Calling 'mbox_reset_cold()' means you are calling platform
>>>>>>>>> specific code in the sysreset driver to perform COLD reset.
>>>>>>>>> What if method to trigger
>>>>>>>> COLD reset is changed in new platform ?
>>>>>>>>> We have to change the sysreset driver code to support
>>>>>>>>> another new
>>>>>> platform.
>>>>>>>>> If this function call is replaced with
>>>>>>>>> "psci_system_reset()", we don't have to change the code at
>>>>>>>>> all because all the platform specific code for COLD reset is
>>>>>>>>> now reside in ATF because this function just invoke the PSCI
>>>>>>>>> function provided by ATF. You just have to replace the ATF
>>>>>>>>> binary with the new implementation for the new platform. We
>>>>>>>>> can re-use this sysreset driver for any platform that
>>>>>>>>> support ATF. In fact, it makes our U-Boot driver code more
>>>>>>>>> 'generic' because PSCI interface stay the same. BTW, Linux
>>>>>>>>> also call PSCI functions to perform COLD reset. By
>>>>>>>> using ATF, U-Boot and Linux share the same COLD reset service
>>>>>>>> provided by
>>>>>> ATF.
>>>>>>>> It actually reduce code duplication.
>>>>>>>>
>>>>>>>> What I meant was code duplication inside the U-Boot tree
>>>>>>>> (having one driver for each arch but in effect all those
>>>>>>>> drivers will call into the same psci
>>>>>> function).
>>>>>>> Can different archs share the same driver if the driver code
>>>>>>> is common to
>>>>>> those platforms ?
>>>>>>
>>>>>> I don't know why not. However, you then need a different way to
>>>>>> select this
>>>>>> driver: you clearly cannot use DT compatibles as this DT entry
>>>>>> does not in any way stand for what you make the driver binding to it
>> execute.
>>>>>>
>>>>>> Instead, I would think of a way to make your PSCI-aware U-Boot
>>>>>> proper use a generic PSCI-reset driver instead of the one
>>>>>> matching the devicetree. And then keep in mind you still need
>>>>>> the DT-matching driver in SPL. Thinking about it, having a
>>>>>> driver in SPL you don't use in U-Boot proper is probably not done, yet, as
>> well.
>>>>> I don't have any problem with this approach (PSCI-reset driver)
>>>>> but it is very easy to support SPL and U-Boot proper in the same
>>>>> driver by just
>>>> checking the current exception level. Please take a look at the code below.
>>>>>
>>>>> #include <dm.h>
>>>>> #include <errno.h>
>>>>> #include <sysreset.h>
>>>>> #include <asm/arch/mailbox_s10.h>
>>>>>
>>>>> static int socfpga_sysreset_request(struct udevice *dev,
>>>>>                                       enum sysreset_t type)  {
>>>>> -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
>>>>> +      If (current_el() == 3)
>>>>
>>>> Hard-coding the EL here seems quite a hack?
>>>>
>>>>> +                mbox_reset_cold();
>>>>> +      else
>>>>> +                psci_system_reset();
>>>>>          return -EINPROGRESS;
>>>>> }
>>>>>
>>>>> We can make the sysreset driver compatible in SPL and U-Boot
>>>>> proper by just
>>>> checking the current exception level.
>>>>> If it's EL3 (secure), we knew SPL is running and otherwise U-Boot
>>>>> proper (EL2,
>>>> non-secure) is running.
>>>>
>>>> So you compile all the PSCI stuff into SPL although never using it?
>>> The PSCI stuff is just a very thin layer (interface to PSCI/SMC call) since real
>> work is done in ATF.
>>> Or we can do it in compile time:
>>> #ifdef CONFIG_SPL_BUILD
>>>       // do it in normal way
>>> #else
>>>      // invoke PSCI call
>>> #endif
>>>>
>>>> I'd still prefer to have DT-compat matched drivers implementing the
>>>> hardware access.
>>>> Then you can instantiate different drivers in U-Boot proper if you
>>>> want to use PSCI, not the hardware. Having DT-compat matched drivers
>>>> do something completely different (issuing PSCI calls instead of
>>>> accessing the hardware they matched on) seems wrong.
>>> OK.
>>>>
>>>> Regards,
>>>> Simon
>>>>
>>>>> Or we can make a small generic function like below and call it
>>>>> from sysreset
>>>> driver code:
>>>>>
>>>>> void soc64_cold_reset(void)
>>>>> {
>>>>>        If (current_el() == 3)
>>>>>                  mbox_reset_cold();
>>>>>        else
>>>>>                  psci_system_reset(); }
>>>>>
>>>>>>
>>>>>>>
>>>>>>>> What you're doing is to move this code from U-Boot open
>>>>>>>> U-Boot sources to possibly closed source ATF sources. But
>>>>>>>> we've already had that discussion, I think...
>>>>>>> Our PSCI implementation in ATF is open source:
>>>>>>> https://github.com/ARM-software/arm-trusted-firmware/tree/mast
>>>>>>> er/p
>>>>>>> lat/
>>>>>>> intel/soc
>>>>>>
>>>>>> Well, open source... Without implying anything: it's BSD, so
>>>>>> it's open source as long as Intel wants it to be open source and
>>>>>> nothing prevents the next manager from keeping additions or even
>>>>>> bugfixes closed
>>>> source.
>>>>>> For whatever reasons might come.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Simon
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Simon
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I think you are aware of we are working to move the mailbox
>>>>>>>>> driver code away
>>>>>>>> from arch to drivers.
>>>>>>>>> You will see that a lot of those mailbox functions will be
>>>>>>>>> removed from the
>>>>>>>> mailbox driver.
>>>>>>>>> One of them is 'mbox_reset_cold()' which you called in
>>>>>>>>> sysreset driver for
>>>>>> S10.
>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Simon
>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Regard,
>>>>>>>>>>>> Simon
>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> SPL loads the u-boot.itb which consist of:
>>>>>>>>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
>>>>>>>>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
>>>>>>>>>>>>>>> 3) bl31.bin (ATF-BL31 image)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
>>>>>>>>>>>>>>> Agilex)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Now, U-Boot Proper is running in non-secure mode
>>>>>>>>>>>>>>> (EL2), it invokes SMC/PSCI calls provided by ATF to
>>>>>>>>>>>>>>> perform COLD reset, System Manager register accesses
>>>>>>>>>>>>>>> and mailbox communications with Secure Device Manager
>> (SDM).
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Steps to build the U-Boot with ATF support:
>>>>>>>>>>>>>>> 1) Build U-Boot
>>>>>>>>>>>>>>> 2) Build ATF BL31
>>>>>>>>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root
>>>>>>>>>>>>>>> folder
>>>>>>>>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> These patchsets have dependency on:
>>>>>>>>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
>>>>>>>>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Chee Hong Ang (19):
>>>>>>>>>>>>>>>     arm: socfpga: add fit source file for pack itb with ATF
>>>>>>>>>>>>>>>     arm: socfpga: Add function for checking description
>>>>>>>>>>>>>>> from FIT
>>>>>>>> image
>>>>>>>>>>>>>>>     arm: socfpga: Load FIT image with ATF support
>>>>>>>>>>>>>>>     arm: socfpga: Override 'lowlevel_init' to support ATF
>>>>>>>>>>>>>>>     configs: socfpga: Enable FIT image loading with ATF support
>>>>>>>>>>>>>>>     arm: socfpga: Disable "spin-table" method for booting Linux
>>>>>>>>>>>>>>>     arm: socfpga: Add SMC helper function for Intel
>>>>>>>>>>>>>>> SOCFPGA
>>>> (64bits)
>>>>>>>>>>>>>>>     arm: socfpga: Define SMC function identifiers for
>>>>>>>>>>>>>>> PSCI SiP
>>>> services
>>>>>>>>>>>>>>>     arm: socfpga: Add secure register access helper
>>>>>>>>>>>>>>> functions for
>>>> SoC
>>>>>>>>>>>>>>>       64bits
>>>>>>>>>>>>>>>     arm: socfpga: Secure register access for clock
>>>>>>>>>>>>>>> manager (SoC
>>>> 64bits)
>>>>>>>>>>>>>>>     arm: socfpga: Secure register access in PHY mode setup
>>>>>>>>>>>>>>>     arm: socfpga: Secure register access for reading PLL
>> frequency
>>>>>>>>>>>>>>>     mmc: dwmmc: socfpga: Secure register access in MMC
>> driver
>>>>>>>>>>>>>>>     net: designware: socfpga: Secure register access in MAC
>> driver
>>>>>>>>>>>>>>>     arm: socfpga: Secure register access in Reset Manager
>> driver
>>>>>>>>>>>>>>>     arm: socfpga: stratix10: Initialize timer in SPL
>>>>>>>>>>>>>>>     arm: socfpga: stratix10: Refactor FPGA reconfig
>>>>>>>>>>>>>>> driver to support
>>>>>>>> ATF
>>>>>>>>>>>>>>>     arm: socfpga: Bridge reset now invokes SMC calls to
>>>>>>>>>>>>>>> query FPGA
>>>>>>>>>> config
>>>>>>>>>>>>>>>       status
>>>>>>>>>>>>>>>     sysreset: socfpga: Invoke PSCI call for COLD reset
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dalon Westergreen (1):
>>>>>>>>>>>>>>>     configs: stratix10: Remove CONFIG_OF_EMBED
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This one is included in another series already:
>>>>>>>>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=13
>>>>>>>>>>>>>> 2976
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Does this mean that one will be abandonen?
>>>>>>>>>>>>>> So the combined hex output part of that series is not
>>>>>>>>>>>>>> required any
>>>>>>>> more?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>> Simon
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/Kconfig                      |   2 -
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/Makefile                     |   4 +
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/board.c                      |  10 +
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
>>>>>>>>>>>>>>>    .../mach-socfpga/include/mach/secure_reg_helper.h  |  20
>> ++
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/secure_reg_helper.c          |  67
>> ++++
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
>>>>>>>>>>>>>>>    arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
>>>>>>>>>>>>>>>    board/altera/soc64/its/fit_spl_atf.its             |  51 +++
>>>>>>>>>>>>>>>    configs/socfpga_agilex_defconfig                   |   8 +-
>>>>>>>>>>>>>>>    configs/socfpga_stratix10_defconfig                |   9 +-
>>>>>>>>>>>>>>>    drivers/fpga/stratix10.c                           | 261 ++++----------
>>>>>>>>>>>>>>>    drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
>>>>>>>>>>>>>>>    drivers/net/dwmac_socfpga.c                        |   5 +-
>>>>>>>>>>>>>>>    drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
>>>>>>>>>>>>>>>    include/configs/socfpga_soc64_common.h             |   2 +-
>>>>>>>>>>>>>>>    include/linux/intel-smc.h                          | 374
>>>>>>>> +++++++++++++++++++++
>>>>>>>>>>>>>>>    22 files changed, 732 insertions(+), 243
>>>>>>>>>>>>>>> deletions(-) create mode
>>>>>>>>>>>>>>> 100644
>>>>>>>>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
>>>>>>>>>>>>>>>    create mode 100644 arch/arm/mach-
>> socfpga/lowlevel_init.S
>>>>>>>>>>>>>>>    create mode 100644
>>>>>>>>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
>>>>>>>>>>>>>>>    create mode 100644 board/altera/soc64/its/fit_spl_atf.its
>>>>>>>>>>>>>>>    create mode 100644 include/linux/intel-smc.h
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> 2.7.4
>>>>>>>>>>>>>>>
>>>>>

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> Am 03.12.2019 um 19:31 schrieb Ang, Chee Hong:
> >> On Tue, Dec 3, 2019 at 3:45 PM Ang, Chee Hong
> >> <chee.hong.ang@intel.com>
> >> wrote:
> >>>
> >>>> On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong
> >>>> <chee.hong.ang@intel.com>
> >>>> wrote:
> >>>>>
> >>>>>> Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong:
> >>>>>>>> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong
> >>>>>>>> <chee.hong.ang@intel.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> >>>>>>>>>> <chee.hong.ang@intel.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> >>>>>>>>>>>> <chee.hong.ang@intel.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM <chee.hong.ang@intel.com>
> >>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> New U-boot flow with ARM Trusted Firmware (ATF) support:
> >>>>>>>>>>>>>>> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) ->
> >>>>>>>>>>>>>>> Linux
> >>>>>>>>>>>>>>> (EL1)
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Adding support for ATF means that using U-Boot on
> >>>>>>>>>>>>>> Stratix10 and Agilex without ATF keeps working, right?
> >>>>>>>>>>>>> ATF is needed in order for Stratix10 and Agilex's U-Boot to work.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Is there a technical requirement for that?
> >>>>>>>>>>> Yes. We are using ATF to provide PSCI services such as
> >>>>>>>>>>> system reset (COLD reset), CPU_ON/CPU_OFF (CPU hotplug in
> >>>>>>>>>>> Linux) and other secure services such as mailbox
> >>>>>>>>>>> communications with Secure Device Manager and accessing the
> >>>>>>>>>>> System Manager registers which are
> >>>>>>>> secure.
> >>>>>>>>>>> Without PSCI services, we are able to boot until U-Boot
> >>>>>>>>>>> proper
> >> only.
> >>>>>>>>>>> Currently, our U-Boot in mainline doesn't boot to Linux due
> >>>>>>>>>>> to these missing
> >>>>>>>>>> PSCI services.
> >>>>>>>>>>> Another reason is we have another boot flow which is using
> >>>>>>>>>>> ATF +
> >>>> UEFI.
> >>>>>>>>>>> So now we are re-using the PSCI services from ATF so that
> >>>>>>>>>>> now U-Boot and UEFI share the same ATF-BL31 image so that we
> >>>>>>>>>>> don't have to
> >>>>>>>>>> reimplement another sets of PSCI services for U-Boot again.
> >>>>>>>>>>> This will greatly reduce our engineering efforts.
> >>>>>>>>>>
> >>>>>>>>>> Hmm, thanks for the explanation.
> >>>>>>>>>>
> >>>>>>>>>> I don't really think I can review this, given the lack of
> >>>>>>>>>> knowledge about that PSCI stuff.
> >>>>>>>>> I believe you can review it.
> >>>>>>>>> Have you briefly gone through the patches ? It has nothing to
> >>>>>>>>> do with the PSCI
> >>>>>>>> stuff.
> >>>>>>>>> It just call the invoke_smc() function to call the ATF's PSCI
> >>>>>>>>> functions. Those PSCI functions in ATF will do the rest.
> >>>>>>>>
> >>>>>>>> No, not yet. But see below.
> >>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> I must say it seems strange to me that U-Boot would have to
> >>>>>>>>>> rely on ATF
> >>>>>>>> though.
> >>>>>>>>>> How do other platforms implement this? Shouldn't PSCI be
> >>>>>>>>>> generic or is it really platform specific? If it's generic,
> >>>>>>>>>> isn't that a dupliation of code if you implement e.g. a reset
> >>>>>>>>>> driver for
> >>>>>>>>>> Stratix10 but call
> >>>>>>>> into PSCI?
> >>>>>>>>> It's not strange at all.  A lot of U-Boot users already using
> >>>>>>>>> this boot flow (ATF +
> >>>>>>>> U-Boot).
> >>>>>>>>
> >>>>>>>> Just because other boards do this doesn't mean it's not strange.
> >>>>>>>> Wasn't there some kind of discussion around that PSCI stuff to
> >>>>>>>> make it
> >>>>>> available from U-Boot?
> >>>>>>>> What's wrong with that way?
> >>>>>>> Our downstream U-Boot branch is already implemented the PSCI
> >>>>>>> stuffs in U-
> >>>>>> Boot.
> >>>>>>> I tried to upstream my PSCI code:
> >>>>>>> https://lists.denx.de/pipermail/u-boot/2019-May/368822.html
> >>>>>>>
> >>>>>>> Marek pointed me to this thread:
> >>>>>>> https://www.mail-archive.com/u-boot at lists.denx.de/msg319458.ht
> >>>>>>> ml
> >>>>>>>
> >>>>>>> He had a point. He suggested maybe we can implement the PSCI
> >>>>>>> stuffs in SPL/TPL. I took a look at the U-Boot code and found
> >>>>>>> out ATF is already well
> >>>>>> supported. Why don't we just use the PSCI code from ATF rather
> >>>>>> than
> >>>>>> re- implementing the PSCI code again in SPL/TPL.
> >>>>>>> It will save our effort to maintain two PSCI code in U-Boot and
> >>>>>>> ATF while we
> >>>>>> already have the ATF PSCI implementation to support UEFI.
> >>>>>>
> >>>>>> It seems to me we do have working code in U-Boot, what's missing
> >>>>>> is "only" to turn it ino PSCI?
> >>>>> Existing PSCI framework in U-Boot provide a way for us to turn the
> >>>>> code into a PSCI handler by just adding a '__secure' keyword
> >>>>> before the
> >>>> function name. See:
> >>>>> https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/mach-soc
> >>>>> fpga
> >>>>> /mailbox_s10.c
> >>>>>
> >>>>> Below is one of the functions that has 2 versions. One 'live' in a
> >>>>> normal code section and another one will be relocated to "__secure"
> >>>>> section (for PSCI). You can see that 2 same functions are
> >>>>> duplicated for normal
> >>>> code section and PSCI section.
> >>>>>
> >>>>> int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32 *arg,
> >>>>>                    u8 urgent, u32 *resp_buf_len, u32 *resp_buf) {
> >>>>>          return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
> urgent,
> >>>>>                                 resp_buf_len, resp_buf); }
> >>>>>
> >>>>> int __secure mbox_send_cmd_psci(u8 id, u32 cmd, u8 is_indirect, u32 len,
> >>>>>                                  u32 *arg, u8 urgent, u32 *resp_buf_len,
> >>>>>                                  u32 *resp_buf) {
> >>>>>          return mbox_send_cmd_common(id, cmd, is_indirect, len, arg,
> urgent,
> >>>>>                                 resp_buf_len, resp_buf); }
> >>>>>
> >>>>> Those functions that are needed by PSCI runtime need to be
> >>>>> duplicated for
> >>>> "__secure" section.
> >>>>> U-Boot Proper will copy and relocate the PSCI code in "__secure"
> >>>>> section to a location before booting Linux whereby they can be
> >>>>> called by Linux. Using the PSCI framework, U-Boot proper is not
> >>>>> able to call any PSCI
> >>>> functions because PSCI code is not available until U-Boot proper
> >>>> ready to boot Linux.
> >>>>> So that's the reason we need to have 2 sets of code in U-Boot. One
> >>>>> for SPL/U-Boot and another one for PSCI section which is used by Linux.
> >>>>> Currently we have 2 implementations for FPGA reconfiguration
> >>>>> driver in our
> >>>> downstream branch.
> >>>>> One for SPL/U-Boot and another one for Linux (PSCI). FPGA
> >>>>> reconfiguration driver for U-Boot is already upstreamed but I
> >>>>> don't think I can
> >>>> get the FPGA reconfiguration for the PSCI part upstreamed.
> >>>>> They are 2 sets of different code for the same purpose. But that
> >>>>> is what we have done in downstream to make sure we can support Linux.
> >>>>>
> >>>>> BTW, we are going to get rid of those duplicated code for PSCI
> >>>>> after we switch
> >>>> to ATF boot flow.
> >>>>
> >>>> I think we have already discussed why that style is bad and unstable.
> >>>>
> >>>> The correct thing to do would be to compile an SPL style binary
> >>>> from the U-Boot sources that can replace ATF-BL31, not this messy
> __secure thing.
> >>>>
> >>>> I can see others (rockchip, TI, NXP?) might in part rely on ATF as
> >>>> well, but speaking for socfpga, if you must insist on using ATF, I
> >>>> would be happy if you could do it in a way that does not reduce
> >>>> existing
> >> functionality in U-Boot.
> >>> Please do 'git grep CONFIG_SPL_ATF' and you will have some idea who
> >>> are using the ATF with U-Boot. You can know which platforms are
> >>> using the ATF by looking at the name of the defconfig files.
> >>
> >> That's where I found Rockchip, TI and NXP. I see I missed Xilinx.
> >>
> >>>
> >>> BTW, what makes you think this ATF method reduce the existing
> >>> functionality
> >> in U-Boot ?
> >>> I don't really get that. I would like to know more to see what I can
> >>> do to ease
> >> your concern.
> >>
> >> You're making U-Boot (GPL-licensed) depend on ATF (BSD-licensed).
> >> That's my main concern.
> >>
> >> Then, you're making the whole build more complicated by having to
> >> build 2 independent projects (in matching versions, as they share at
> >> least one header file).
> >>
> >> I'd say it would be more straightforward to integrate PSCI services
> >> into U-Boot. I know that comes at the expense of someone taking the
> >> time to fix U-Boot PSCI support from "__secure" to a proper way. But I think
> the result would be cleaner.
> >>
> >> Added to that, with what you told me so far, you reduce U-Boot
> >> functionality by making the existing drivers in U-Boot proper require
> >> PSCI services, so U-Boot won't run standalone if you decide to not use ATF.
> > We are trying to combine the best of both worlds (SPL/U-Boot + ATF)
> > where we get to enjoy the existing benefits of using U-Boot and
> > solid/well implemented PSCI services + ARMv8 extensions from ATF.
> > Linux depends on those standard PSCI services such as CPU hotplug and
> > etc and they are well implemented in ATF to avoid race conditions when
> > waking/suspending the CPU cores. Besides, ATF also provide various ARMv8
> extensions (such as RAS) to OS.
> > So using ATF with U-Boot is much more than just PSCI.
> >
> > Beside the time/effort needed to fix the existing U-Boot PSCI issue,
> > having a solid and well implemented PSCI services and ARMv8 extensions
> > in U-Boot is another huge effort. We also need to ensure these
> implementations are well maintained and up to date with the PSCI/ARMv8
> extensions specification from time to time.
> >
> >  From U-Boot perspective, you have made some valid points.
> > We understand using ATF with U-Boot do come with a cost.
> > So far, the whole discussion only revolved around the issues/impact between
> ATF and U-Boot.
> > Let's not forget the fact that ultimately most users will end up in OS
> > environment (Linux) after SPL & U-Boot proper and this is what ATF do
> > best by providing well implemented PSCI services and ARMv8 extensions to
> Linux. It might not be your concern.
> 
> As you might have noticed, I'm using gen5 with Linux at the moment and might
> at some point in the future be migrating to a 64-bit ARM, so that might well be
> S10/Agilex or some kind of stripped down version of that, you never know. So
> yes, in the future, this might be my concern :-)
> 
> > But that's the benefits we see and I personally think this is one of the main
> reasons ATF support gets enabled in U-Boot.
> 
> I don't want to hold you back from using ATF + U-Boot. I only say I'm not
> convinced stripping down U-Boot functionality with that move is the way to go.
> 
> And I think it would be better to hard-code this at compile time (given the
> knowledge SPL -> raw, U-Boot -> via ATF) than evaluating EL.
OK. It makes sense to do it in compile time since the execution state is known
ahead.
> 
> Keeping that aside, what's the "secure" benefit of allowing register
> read/write/modify access via invoke_smc vs. directly modifying registers?
There are 2 hardware zones in Stratix10/Agilex which always require the processor
running in secure mode (EL3) when accessing these registers:
1) System Manager
https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/topic/dwh1505406933720.html
2) Mailbox exchange between HPS and SDM
https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/topic/ndu1505406178722.html
https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/topic/eay1505406180801.html

Accessing registers in (1) running in non-secure mode (EL2) trigger "System Error" exception and
(2) will not trigger any exception but no effects on read/write accesses. Reading registers from (2)
return ZERO.

There are a couple of registers in (1) that control the behaviour of SDMMC/NAND/EMACx/USBx and etc.
These registers are accessed in some of the SDMMC/EMAC drivers running in U-Boot proper & Linux as well.
Therefore, they need SMC/PSCI call to access these registers via ATF which is running in secure mode (EL3).

Currently, we don't expose all the registers in (1) and non-secure mode will only have access to a portion of
registers which are required by the drivers.  We can also control the read/write access of the individual bits
in certain registers as well but we are not currently imposing any read/write restrictions on those exposed registers.
All registers that are exposed to non-secure mode allow full access.
The basic idea is to let SPL perform the proper critical hardware setup and U-Boot proper/Linux running at later stage
will not be able to simply mess with those critical system manager registers in bad ways.
For mailbox IP, code running in U-Boot proper/Linux will not be able to mess up the command/message exchange
between ARM processor (HPS) and Secure Device Manager (SDM). It provides basic protection for our SDM from directly
being attacked.
In terms of  "secure" benefit, I think these are the 2 basic "protection" and "access control" we have right now.
> 
> Regards,
> Simon
> 
> >>
> >>>>
> >>>>>>
> >>>>>> And given U-Boot aims to support UEFI (kind of?), I'd rather argue:
> >>>>>> why do you need ATF at all?
> >>>>>
> >>>>> No, U-Boot does not aim to support UEFI. We have 2 boot flows that
> >>>>> don't
> >>>> mix:
> >>>>
> >>>> Really? Or do you mean you don't aim to support EFI boot using U-Boot?
> >>>> I don't know that (U)EFI stuff too well, yet, but I was under the
> >>>> impression that Heinrich et. al. do want U-Boot to support UEFI?
> >>> Yes. Currently, we have no plan to support (U)EFI boot with U-Boot.
> >>> Anyway, I am not working on UEFI boot flow. That's the work from
> >>> another
> >> team.
> >>>>
> >>>>>
> >>>>> 1) U-Boot -> ATF-BL31 -> U-Boot Proper -> Linux
> >>>>>
> >>>>> 2) ATF-BL2 -> ATF-BL31 -> UEFI -> Other OSes or Linux
> >>>>>
> >>>>> These two boot flows now share the same code base (ATF-BL31).
> >>>>>>
> >>>>>> Indeed, having the same code in both seems like double effort for
> >>>> maintenance.
> >>>>>>
> >>>>>>>>
> >>>>>>>> In my opinion, you're reducing functionality in U-Boot by
> >>>>>>>> making ATF a requirement.
> >>>>>>>>
> >>>>>>>> And by saying "I can't review this", I mean this looks like a
> >>>>>>>> questionable way to me and I'm not the one to say if a U-Boot
> >>>>>>>> board should
> >>>>>> go this way or not.
> >>>>>>> I understand. Btw, who should I include to review this ?
> >>>>>>>>
> >>>>>>>>> Yes. PSCI is a generic software interface which encapsulate
> >>>>>>>>> the platform
> >>>>>>>> specific code.
> >>>>>>>>> Let me give you a good example in one of your sysreset
> >>>>>>>>> driver you have
> >>>>>>>> implemented for S10.
> >>>>>>>>>
> >>>>>>>>> #include <dm.h>
> >>>>>>>>> #include <errno.h>
> >>>>>>>>> #include <sysreset.h>
> >>>>>>>>> -#include <asm/arch/mailbox_s10.h>
> >>>>>>>>>
> >>>>>>>>>    static int socfpga_sysreset_request(struct udevice *dev,
> >>>>>>>>>                                       enum sysreset_t type)  {
> >>>>>>>>>    -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> >>>>>>>>>    -      mbox_reset_cold();
> >>>>>>>>>    +      psci_system_reset();
> >>>>>>
> >>>>>> And coming back on this, the sysreset driver won't work in SPL
> >>>>>> any more,
> >>>> right?
> >>>>> You brought a very good point. See my comment at the bottom.
> >>>>>>
> >>>>>>>>
> >>>>>>>> So this is not an socfgpa_s10 specific driver any more, right?
> >>>>> This driver code can be renamed to more generic name such as
> >>>> socfpga_soc64.c.
> >>>>> So that it can be shared by both Stratix10 and Agilex.
> >>>>>>>>
> >>>>>>>>>           return -EINPROGRESS;
> >>>>>>>>>    }
> >>>>>>>>>
> >>>>>>>>> Above is the changes in one of my patchsets, the sysreset
> >>>>>>>>> driver for
> >>>>>>>>> S10 used to call mbox_reset_cold() to send mailbox message
> >>>>>>>>> to Secure Device Manager
> >>>>>>>>> (SDM) to trigger COLD reset.
> >>>>>>>>> Calling 'mbox_reset_cold()' means you are calling platform
> >>>>>>>>> specific code in the sysreset driver to perform COLD reset.
> >>>>>>>>> What if method to trigger
> >>>>>>>> COLD reset is changed in new platform ?
> >>>>>>>>> We have to change the sysreset driver code to support
> >>>>>>>>> another new
> >>>>>> platform.
> >>>>>>>>> If this function call is replaced with
> >>>>>>>>> "psci_system_reset()", we don't have to change the code at
> >>>>>>>>> all because all the platform specific code for COLD reset is
> >>>>>>>>> now reside in ATF because this function just invoke the PSCI
> >>>>>>>>> function provided by ATF. You just have to replace the ATF
> >>>>>>>>> binary with the new implementation for the new platform. We
> >>>>>>>>> can re-use this sysreset driver for any platform that
> >>>>>>>>> support ATF. In fact, it makes our U-Boot driver code more
> >>>>>>>>> 'generic' because PSCI interface stay the same. BTW, Linux
> >>>>>>>>> also call PSCI functions to perform COLD reset. By
> >>>>>>>> using ATF, U-Boot and Linux share the same COLD reset service
> >>>>>>>> provided by
> >>>>>> ATF.
> >>>>>>>> It actually reduce code duplication.
> >>>>>>>>
> >>>>>>>> What I meant was code duplication inside the U-Boot tree
> >>>>>>>> (having one driver for each arch but in effect all those
> >>>>>>>> drivers will call into the same psci
> >>>>>> function).
> >>>>>>> Can different archs share the same driver if the driver code
> >>>>>>> is common to
> >>>>>> those platforms ?
> >>>>>>
> >>>>>> I don't know why not. However, you then need a different way to
> >>>>>> select this
> >>>>>> driver: you clearly cannot use DT compatibles as this DT entry
> >>>>>> does not in any way stand for what you make the driver binding to it
> >> execute.
> >>>>>>
> >>>>>> Instead, I would think of a way to make your PSCI-aware U-Boot
> >>>>>> proper use a generic PSCI-reset driver instead of the one
> >>>>>> matching the devicetree. And then keep in mind you still need
> >>>>>> the DT-matching driver in SPL. Thinking about it, having a
> >>>>>> driver in SPL you don't use in U-Boot proper is probably not done, yet, as
> >> well.
> >>>>> I don't have any problem with this approach (PSCI-reset driver)
> >>>>> but it is very easy to support SPL and U-Boot proper in the same
> >>>>> driver by just
> >>>> checking the current exception level. Please take a look at the code below.
> >>>>>
> >>>>> #include <dm.h>
> >>>>> #include <errno.h>
> >>>>> #include <sysreset.h>
> >>>>> #include <asm/arch/mailbox_s10.h>
> >>>>>
> >>>>> static int socfpga_sysreset_request(struct udevice *dev,
> >>>>>                                       enum sysreset_t type)  {
> >>>>> -      puts("Mailbox: Issuing mailbox cmd REBOOT_HPS\n");
> >>>>> +      If (current_el() == 3)
> >>>>
> >>>> Hard-coding the EL here seems quite a hack?
> >>>>
> >>>>> +                mbox_reset_cold();
> >>>>> +      else
> >>>>> +                psci_system_reset();
> >>>>>          return -EINPROGRESS;
> >>>>> }
> >>>>>
> >>>>> We can make the sysreset driver compatible in SPL and U-Boot
> >>>>> proper by just
> >>>> checking the current exception level.
> >>>>> If it's EL3 (secure), we knew SPL is running and otherwise U-Boot
> >>>>> proper (EL2,
> >>>> non-secure) is running.
> >>>>
> >>>> So you compile all the PSCI stuff into SPL although never using it?
> >>> The PSCI stuff is just a very thin layer (interface to PSCI/SMC call) since real
> >> work is done in ATF.
> >>> Or we can do it in compile time:
> >>> #ifdef CONFIG_SPL_BUILD
> >>>       // do it in normal way
> >>> #else
> >>>      // invoke PSCI call
> >>> #endif
> >>>>
> >>>> I'd still prefer to have DT-compat matched drivers implementing the
> >>>> hardware access.
> >>>> Then you can instantiate different drivers in U-Boot proper if you
> >>>> want to use PSCI, not the hardware. Having DT-compat matched drivers
> >>>> do something completely different (issuing PSCI calls instead of
> >>>> accessing the hardware they matched on) seems wrong.
> >>> OK.
> >>>>
> >>>> Regards,
> >>>> Simon
> >>>>
> >>>>> Or we can make a small generic function like below and call it
> >>>>> from sysreset
> >>>> driver code:
> >>>>>
> >>>>> void soc64_cold_reset(void)
> >>>>> {
> >>>>>        If (current_el() == 3)
> >>>>>                  mbox_reset_cold();
> >>>>>        else
> >>>>>                  psci_system_reset(); }
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>>> What you're doing is to move this code from U-Boot open
> >>>>>>>> U-Boot sources to possibly closed source ATF sources. But
> >>>>>>>> we've already had that discussion, I think...
> >>>>>>> Our PSCI implementation in ATF is open source:
> >>>>>>> https://github.com/ARM-software/arm-trusted-firmware/tree/mast
> >>>>>>> er/p
> >>>>>>> lat/
> >>>>>>> intel/soc
> >>>>>>
> >>>>>> Well, open source... Without implying anything: it's BSD, so
> >>>>>> it's open source as long as Intel wants it to be open source and
> >>>>>> nothing prevents the next manager from keeping additions or even
> >>>>>> bugfixes closed
> >>>> source.
> >>>>>> For whatever reasons might come.
> >>>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Simon
> >>>>>>
> >>>>>>>
> >>>>>>>>
> >>>>>>>> Regards,
> >>>>>>>> Simon
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>> I think you are aware of we are working to move the mailbox
> >>>>>>>>> driver code away
> >>>>>>>> from arch to drivers.
> >>>>>>>>> You will see that a lot of those mailbox functions will be
> >>>>>>>>> removed from the
> >>>>>>>> mailbox driver.
> >>>>>>>>> One of them is 'mbox_reset_cold()' which you called in
> >>>>>>>>> sysreset driver for
> >>>>>> S10.
> >>>>>>>>>
> >>>>>>>>>> Regards,
> >>>>>>>>>> Simon
> >>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Regard,
> >>>>>>>>>>>> Simon
> >>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> SPL loads the u-boot.itb which consist of:
> >>>>>>>>>>>>>>> 1) u-boot-nodtb.bin (U-Boot Proper image)
> >>>>>>>>>>>>>>> 2) u-boot.dtb (U-Boot Proper DTB)
> >>>>>>>>>>>>>>> 3) bl31.bin (ATF-BL31 image)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Supported Platform: Intel SoCFPGA 64bits (Stratix10 &
> >>>>>>>>>>>>>>> Agilex)
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Now, U-Boot Proper is running in non-secure mode
> >>>>>>>>>>>>>>> (EL2), it invokes SMC/PSCI calls provided by ATF to
> >>>>>>>>>>>>>>> perform COLD reset, System Manager register accesses
> >>>>>>>>>>>>>>> and mailbox communications with Secure Device Manager
> >> (SDM).
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Steps to build the U-Boot with ATF support:
> >>>>>>>>>>>>>>> 1) Build U-Boot
> >>>>>>>>>>>>>>> 2) Build ATF BL31
> >>>>>>>>>>>>>>> 3) Copy ATF BL31 binary image into U-Boot's root
> >>>>>>>>>>>>>>> folder
> >>>>>>>>>>>>>>> 4) "make u-boot.itb" to generate u-boot.itb
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> These patchsets have dependency on:
> >>>>>>>>>>>>>>> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> >>>>>>>>>>>>>>> https://patchwork.ozlabs.org/cover/1201373/
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Chee Hong Ang (19):
> >>>>>>>>>>>>>>>     arm: socfpga: add fit source file for pack itb with ATF
> >>>>>>>>>>>>>>>     arm: socfpga: Add function for checking description
> >>>>>>>>>>>>>>> from FIT
> >>>>>>>> image
> >>>>>>>>>>>>>>>     arm: socfpga: Load FIT image with ATF support
> >>>>>>>>>>>>>>>     arm: socfpga: Override 'lowlevel_init' to support ATF
> >>>>>>>>>>>>>>>     configs: socfpga: Enable FIT image loading with ATF
> support
> >>>>>>>>>>>>>>>     arm: socfpga: Disable "spin-table" method for booting
> Linux
> >>>>>>>>>>>>>>>     arm: socfpga: Add SMC helper function for Intel
> >>>>>>>>>>>>>>> SOCFPGA
> >>>> (64bits)
> >>>>>>>>>>>>>>>     arm: socfpga: Define SMC function identifiers for
> >>>>>>>>>>>>>>> PSCI SiP
> >>>> services
> >>>>>>>>>>>>>>>     arm: socfpga: Add secure register access helper
> >>>>>>>>>>>>>>> functions for
> >>>> SoC
> >>>>>>>>>>>>>>>       64bits
> >>>>>>>>>>>>>>>     arm: socfpga: Secure register access for clock
> >>>>>>>>>>>>>>> manager (SoC
> >>>> 64bits)
> >>>>>>>>>>>>>>>     arm: socfpga: Secure register access in PHY mode setup
> >>>>>>>>>>>>>>>     arm: socfpga: Secure register access for reading PLL
> >> frequency
> >>>>>>>>>>>>>>>     mmc: dwmmc: socfpga: Secure register access in MMC
> >> driver
> >>>>>>>>>>>>>>>     net: designware: socfpga: Secure register access in MAC
> >> driver
> >>>>>>>>>>>>>>>     arm: socfpga: Secure register access in Reset Manager
> >> driver
> >>>>>>>>>>>>>>>     arm: socfpga: stratix10: Initialize timer in SPL
> >>>>>>>>>>>>>>>     arm: socfpga: stratix10: Refactor FPGA reconfig
> >>>>>>>>>>>>>>> driver to support
> >>>>>>>> ATF
> >>>>>>>>>>>>>>>     arm: socfpga: Bridge reset now invokes SMC calls to
> >>>>>>>>>>>>>>> query FPGA
> >>>>>>>>>> config
> >>>>>>>>>>>>>>>       status
> >>>>>>>>>>>>>>>     sysreset: socfpga: Invoke PSCI call for COLD reset
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Dalon Westergreen (1):
> >>>>>>>>>>>>>>>     configs: stratix10: Remove CONFIG_OF_EMBED
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> This one is included in another series already:
> >>>>>>>>>>>>>> https://patchwork.ozlabs.org/user/todo/uboot/?series=13
> >>>>>>>>>>>>>> 2976
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Does this mean that one will be abandonen?
> >>>>>>>>>>>>>> So the combined hex output part of that series is not
> >>>>>>>>>>>>>> required any
> >>>>>>>> more?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>> Simon
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/Kconfig                      |   2 -
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/Makefile                     |   4 +
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/board.c                      |  10 +
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/clock_manager_agilex.c       |   5
> +-
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> >>>>>>>>>>>>>>>    .../mach-socfpga/include/mach/secure_reg_helper.h  |  20
> >> ++
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/secure_reg_helper.c          |  67
> >> ++++
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> >>>>>>>>>>>>>>>    arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> >>>>>>>>>>>>>>>    board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> >>>>>>>>>>>>>>>    configs/socfpga_agilex_defconfig                   |   8 +-
> >>>>>>>>>>>>>>>    configs/socfpga_stratix10_defconfig                |   9 +-
> >>>>>>>>>>>>>>>    drivers/fpga/stratix10.c                           | 261 ++++----------
> >>>>>>>>>>>>>>>    drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> >>>>>>>>>>>>>>>    drivers/net/dwmac_socfpga.c                        |   5 +-
> >>>>>>>>>>>>>>>    drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> >>>>>>>>>>>>>>>    include/configs/socfpga_soc64_common.h             |   2 +-
> >>>>>>>>>>>>>>>    include/linux/intel-smc.h                          | 374
> >>>>>>>> +++++++++++++++++++++
> >>>>>>>>>>>>>>>    22 files changed, 732 insertions(+), 243
> >>>>>>>>>>>>>>> deletions(-) create mode
> >>>>>>>>>>>>>>> 100644
> >>>>>>>>>>>>>>> arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
> >>>>>>>>>>>>>>>    create mode 100644 arch/arm/mach-
> >> socfpga/lowlevel_init.S
> >>>>>>>>>>>>>>>    create mode 100644
> >>>>>>>>>>>>>>> arch/arm/mach-socfpga/secure_reg_helper.c
> >>>>>>>>>>>>>>>    create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> >>>>>>>>>>>>>>>    create mode 100644 include/linux/intel-smc.h
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>> 2.7.4
> >>>>>>>>>>>>>>>
> >>>>>

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Simon Goldschmidt]

Am 02.12.2019 um 11:25 schrieb chee.hong.ang at intel.com:
> From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> 
> New U-boot flow with ARM Trusted Firmware (ATF) support:
> SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> 
> SPL loads the u-boot.itb which consist of:
> 1) u-boot-nodtb.bin (U-Boot Proper image)
> 2) u-boot.dtb (U-Boot Proper DTB)
> 3) bl31.bin (ATF-BL31 image)
> 
> Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> 
> Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
> register accesses and mailbox communications with Secure Device Manager
> (SDM).
> 
> Steps to build the U-Boot with ATF support:
> 1) Build U-Boot
> 2) Build ATF BL31
> 3) Copy ATF BL31 binary image into U-Boot's root folder
> 4) "make u-boot.itb" to generate u-boot.itb
> 
> These patchsets have dependency on:
> [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> https://patchwork.ozlabs.org/cover/1201373/

BTW, does this series supersede these wo:
https://patchwork.ozlabs.org/user/todo/uboot/?series=106463
https://patchwork.ozlabs.org/user/todo/uboot/?series=106465

I'm just updating my patchwork todo list...

Regards,
Simon

> 
> Chee Hong Ang (19):
>    arm: socfpga: add fit source file for pack itb with ATF
>    arm: socfpga: Add function for checking description from FIT image
>    arm: socfpga: Load FIT image with ATF support
>    arm: socfpga: Override 'lowlevel_init' to support ATF
>    configs: socfpga: Enable FIT image loading with ATF support
>    arm: socfpga: Disable "spin-table" method for booting Linux
>    arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
>    arm: socfpga: Define SMC function identifiers for PSCI SiP services
>    arm: socfpga: Add secure register access helper functions for SoC
>      64bits
>    arm: socfpga: Secure register access for clock manager (SoC 64bits)
>    arm: socfpga: Secure register access in PHY mode setup
>    arm: socfpga: Secure register access for reading PLL frequency
>    mmc: dwmmc: socfpga: Secure register access in MMC driver
>    net: designware: socfpga: Secure register access in MAC driver
>    arm: socfpga: Secure register access in Reset Manager driver
>    arm: socfpga: stratix10: Initialize timer in SPL
>    arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
>    arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
>      status
>    sysreset: socfpga: Invoke PSCI call for COLD reset
> 
> Dalon Westergreen (1):
>    configs: stratix10: Remove CONFIG_OF_EMBED
> 
>   arch/arm/mach-socfpga/Kconfig                      |   2 -
>   arch/arm/mach-socfpga/Makefile                     |   4 +
>   arch/arm/mach-socfpga/board.c                      |  10 +
>   arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
>   arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
>   arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
>   .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
>   arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
>   arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
>   arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
>   arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
>   arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
>   arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
>   board/altera/soc64/its/fit_spl_atf.its             |  51 +++
>   configs/socfpga_agilex_defconfig                   |   8 +-
>   configs/socfpga_stratix10_defconfig                |   9 +-
>   drivers/fpga/stratix10.c                           | 261 ++++----------
>   drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
>   drivers/net/dwmac_socfpga.c                        |   5 +-
>   drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
>   include/configs/socfpga_soc64_common.h             |   2 +-
>   include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
>   22 files changed, 732 insertions(+), 243 deletions(-)
>   create mode 100644 arch/arm/mach-socfpga/include/mach/secure_reg_helper.h
>   create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
>   create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
>   create mode 100644 board/altera/soc64/its/fit_spl_atf.its
>   create mode 100644 include/linux/intel-smc.h
> 

[PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot

[Ang, Chee Hong]

> Am 02.12.2019 um 11:25 schrieb chee.hong.ang at intel.com:
> > From: "Ang, Chee Hong" <chee.hong.ang@intel.com>
> >
> > New U-boot flow with ARM Trusted Firmware (ATF) support:
> > SPL (EL3) -> ATF-BL31 (EL3) -> U-Boot Proper (EL2) -> Linux (EL1)
> >
> > SPL loads the u-boot.itb which consist of:
> > 1) u-boot-nodtb.bin (U-Boot Proper image)
> > 2) u-boot.dtb (U-Boot Proper DTB)
> > 3) bl31.bin (ATF-BL31 image)
> >
> > Supported Platform: Intel SoCFPGA 64bits (Stratix10 & Agilex)
> >
> > Now, U-Boot Proper is running in non-secure mode (EL2), it invokes
> > SMC/PSCI calls provided by ATF to perform COLD reset, System Manager
> > register accesses and mailbox communications with Secure Device
> > Manager (SDM).
> >
> > Steps to build the U-Boot with ATF support:
> > 1) Build U-Boot
> > 2) Build ATF BL31
> > 3) Copy ATF BL31 binary image into U-Boot's root folder
> > 4) "make u-boot.itb" to generate u-boot.itb
> >
> > These patchsets have dependency on:
> > [U-Boot,v8,00/19] Add Intel Agilex SoC support:
> > https://patchwork.ozlabs.org/cover/1201373/
> 
> BTW, does this series supersede these wo:
> https://patchwork.ozlabs.org/user/todo/uboot/?series=106463
> https://patchwork.ozlabs.org/user/todo/uboot/?series=106465
Yes. These 2 patches are quite dated as they are using "__secure" section method for PSCI code.
> 
> I'm just updating my patchwork todo list...
> 
> Regards,
> Simon
> 
> >
> > Chee Hong Ang (19):
> >    arm: socfpga: add fit source file for pack itb with ATF
> >    arm: socfpga: Add function for checking description from FIT image
> >    arm: socfpga: Load FIT image with ATF support
> >    arm: socfpga: Override 'lowlevel_init' to support ATF
> >    configs: socfpga: Enable FIT image loading with ATF support
> >    arm: socfpga: Disable "spin-table" method for booting Linux
> >    arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> >    arm: socfpga: Define SMC function identifiers for PSCI SiP services
> >    arm: socfpga: Add secure register access helper functions for SoC
> >      64bits
> >    arm: socfpga: Secure register access for clock manager (SoC 64bits)
> >    arm: socfpga: Secure register access in PHY mode setup
> >    arm: socfpga: Secure register access for reading PLL frequency
> >    mmc: dwmmc: socfpga: Secure register access in MMC driver
> >    net: designware: socfpga: Secure register access in MAC driver
> >    arm: socfpga: Secure register access in Reset Manager driver
> >    arm: socfpga: stratix10: Initialize timer in SPL
> >    arm: socfpga: stratix10: Refactor FPGA reconfig driver to support ATF
> >    arm: socfpga: Bridge reset now invokes SMC calls to query FPGA config
> >      status
> >    sysreset: socfpga: Invoke PSCI call for COLD reset
> >
> > Dalon Westergreen (1):
> >    configs: stratix10: Remove CONFIG_OF_EMBED
> >
> >   arch/arm/mach-socfpga/Kconfig                      |   2 -
> >   arch/arm/mach-socfpga/Makefile                     |   4 +
> >   arch/arm/mach-socfpga/board.c                      |  10 +
> >   arch/arm/mach-socfpga/clock_manager_agilex.c       |   5 +-
> >   arch/arm/mach-socfpga/clock_manager_s10.c          |   5 +-
> >   arch/arm/mach-socfpga/include/mach/misc.h          |   3 +
> >   .../mach-socfpga/include/mach/secure_reg_helper.h  |  20 ++
> >   arch/arm/mach-socfpga/lowlevel_init.S              |  48 +++
> >   arch/arm/mach-socfpga/misc_s10.c                   |  47 ++-
> >   arch/arm/mach-socfpga/reset_manager_s10.c          |  31 +-
> >   arch/arm/mach-socfpga/secure_reg_helper.c          |  67 ++++
> >   arch/arm/mach-socfpga/timer_s10.c                  |   3 +-
> >   arch/arm/mach-socfpga/wrap_pll_config_s10.c        |   9 +-
> >   board/altera/soc64/its/fit_spl_atf.its             |  51 +++
> >   configs/socfpga_agilex_defconfig                   |   8 +-
> >   configs/socfpga_stratix10_defconfig                |   9 +-
> >   drivers/fpga/stratix10.c                           | 261 ++++----------
> >   drivers/mmc/socfpga_dw_mmc.c                       |   7 +-
> >   drivers/net/dwmac_socfpga.c                        |   5 +-
> >   drivers/sysreset/sysreset_socfpga_s10.c            |   4 +-
> >   include/configs/socfpga_soc64_common.h             |   2 +-
> >   include/linux/intel-smc.h                          | 374 +++++++++++++++++++++
> >   22 files changed, 732 insertions(+), 243 deletions(-)
> >   create mode 100644 arch/arm/mach-
> socfpga/include/mach/secure_reg_helper.h
> >   create mode 100644 arch/arm/mach-socfpga/lowlevel_init.S
> >   create mode 100644 arch/arm/mach-socfpga/secure_reg_helper.c
> >   create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> >   create mode 100644 include/linux/intel-smc.h
> >