RE: [PATCH v1 00/16] Enable ARM Trusted Firmware for U-Boot
Chee Hong Ang mailto:chee.hong@intel.com>> schrieb
am Mo., 17. Aug. 2020, 06:34:
Repost of the following patchs:
https://lists.denx.de/pipermail/u-boot/2020-March/402705.html
> If this is a repost, please send as such instead of sending as a new series
> v1.
Sorry, please ignore the repost. This patch series has some new changes which I
think should be new series itself.
> Regards,
> Simon
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:
arm: socfpga: soc64: Add timeout waiting for NOC idle ACK
https://lists.denx.de/pipermail/u-boot/2020-August/423029.html
Rename Stratix10 FPGA driver and support Agilex
https://lists.denx.de/pipermail/u-boot/2020-August/422798.html
SoCFPGA mailbox driver fixes and enhancements
https://lists.denx.de/pipermail/u-boot/2020-August/423140.html
arm: socfpga: soc64: Initialize timer in SPL only
https://lists.denx.de/pipermail/u-boot/2020-July/419692.html
arm: socfpga: soc64: Remove PHY interface setup from misc arch init
https://lists.denx.de/pipermail/u-boot/2020-July/419690.html
Enable sysreset support for SoCFPGA SoC64 platforms
https://lists.denx.de/pipermail/u-boot/2020-August/422509.html
arm: socfpga: soc64: Disable CONFIG_PSCI_RESET
https://lists.denx.de/pipermail/u-boot/2020-August/423373.html
Chee Hong Ang (16):
arm: socfpga: soc64: Remove CONFIG_OF_EMBED
arm: socfpga: soc64: Add FIT generator script for pack itb with ATF
arm: socfpga: Add function for checking description from FIT image
arm: socfpga: soc64: Load FIT image with ATF support
arm: socfpga: soc64: Override 'lowlevel_init' to support ATF
arm: socfpga: Disable "spin-table" method for booting Linux
arm: socfpga: soc64: Add SMC helper function for Intel SOCFPGA
(64bits)
arm: socfpga: soc64: Define SMC function identifiers for PSCI SiP
services
mmc: dwmmc: socfpga: Add ATF support for MMC driver
net: designware: socfpga: Add ATF support for MAC driver
arm: socfpga: soc64: Add ATF support for Reset Manager driver
arm: socfpga: soc64: Add ATF support for FPGA reconfig driver
arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to
mbox_reset_cold()
arm: socfpga: soc64: SSBL shall not setup stack on OCRAM
arm: socfpga: soc64: Skip handoff data access in SSBL
configs: socfpga: Add defconfig for Agilex and Stratix 10 with ATF
support
arch/arm/mach-socfpga/Kconfig | 2 -
arch/arm/mach-socfpga/Makefile| 4 +
arch/arm/mach-socfpga/board.c | 12 +-
arch/arm/mach-socfpga/include/mach/smc_api.h | 13 +
arch/arm/mach-socfpga/lowlevel_init_soc64.S | 76 +++
arch/arm/mach-socfpga/mailbox_s10.c | 5 +
arch/arm/mach-socfpga/reset_manager_s10.c | 10 +
arch/arm/mach-socfpga/smc_api.c | 56 ++
arch/arm/mach-socfpga/wrap_pll_config_s10.c | 3 +-
board/altera/soc64/fit_spl_atf.sh | 91 +++
...defconfig => socfpga_agilex_atf_defconfig} | 25 +-
configs/socfpga_agilex_defconfig | 1 -
...config => socfpga_stratix10_atf_defconfig} | 25 +-
configs/socfpga_stratix10_defconfig | 1 -
drivers/fpga/intel_sdm_mb.c | 139 +
drivers/mmc/socfpga_dw_mmc.c | 20 +
drivers/net/dwmac_socfpga.c | 43 +-
include/configs/socfpga_soc64_common.h| 9 +
include/linux/intel-smc.h | 573 ++
19 files changed, 1078 insertions(+), 30 deletions(-)
create mode 100644 arch/arm/mach-socfpga/include/mach/smc_api.h
create mode 100644 arch/arm/mach-socfpga/lowlevel_init_soc64.S
create mode 100644 arch/arm/mach-socfpga/smc_api.c
create mode 100755 board/altera/soc64/fit_spl_atf.sh
copy configs/{socfpga_agilex_defconfig => socfpga_agilex_atf_defconfig} (77%)
copy configs/{socfpga_stratix10_defconfig => socfpga_stratix10_atf_defconfig}
(80%)
create mode 100644 include/linux/intel-smc.h
--
2.19.0
RE: [PATCH v2] Makefile: socfpga: Generate spl/u-boot-splx4.sfp with 4 SPL images
> On 8/11/20 10:01 AM, Chee Hong Ang wrote: > > Generate spl/u-boot-splx4.sfp which consist of 4 SPL images required > > for booting up Cyclone5/Arria10. > > > > For Cyclone5 using NAND flash image layout for 128 KB memory blocks, > > 'make u-boot-with-nand-spl.sfp' to generate spl/u-boot-nand-splx4.sfp > > which contains four 128KB SPL images (each 64KB SPL is followed by > > 64KB of zero-padding). > > > > Signed-off-by: Chee Hong Ang > > --- > > What changed between V1 and V2 ? Changelog is missing. In V2, 'make u-boot-with-nand-spl.sfp' will generate spl/u-boot-nand-splx4.sfp which contains 4 x (SPL + 64KB padding). Commit message already mentioned how to generate this SFP file with 64Kb padding for each SPL in SFP. > > > Makefile | 11 +++ > > 1 file changed, 7 insertions(+), 4 deletions(-) > > > > diff --git a/Makefile b/Makefile > > index 4483a9b..f4631f1 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -1582,8 +1582,9 @@ u-boot.spr: spl/u-boot-spl.img u-boot.img FORCE > > ifneq ($(CONFIG_ARCH_SOCFPGA),) quiet_cmd_socboot = SOCBOOT $@ > > cmd_socboot = cat spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > > - spl/u-boot-spl.sfp spl/u-boot-spl.sfp \ > > - u-boot.img > $@ || rm -f $@ > > + spl/u-boot-spl.sfp \ > > + spl/u-boot-spl.sfp > spl/u-boot-splx4.sfp ; \ > > + cat spl/u-boot-splx4.sfp u-boot.img > $@ || rm -f $@ > > u-boot-with-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE > > $(call if_changed,socboot) > > Also, now that I look at it, if you want to generate some new target, it > should be a Makefile target, just like u-boot-with-spl.sfp is a Makefile > target. > So then you can do make . There is already a target 'u-boot-with-nand-spl.sfp' in Makefile: u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE $(call if_changed,socnandboot) V2 patch contains the following changes as well which are missing in this email thread: @@ -1592,8 +1593,10 @@ cmd_socnandboot = dd if=/dev/zero of=spl/u-boot-spl.pad bs=64 count=1024 ; \ cat spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - spl/u-boot-spl.sfp spl/u-boot-spl.pad \ - u-boot.img > $@ || rm -f $@ spl/u-boot-spl.pad + spl/u-boot-spl.sfp \ + spl/u-boot-spl.pad > spl/u-boot-nand-splx4.sfp ; \ + cat spl/u-boot-nand-splx4.sfp u-boot.img > $@ || \ + rm -f $@ spl/u-boot-spl.pad u-boot-with-nand-spl.sfp: spl/u-boot-spl.sfp u-boot.img FORCE $(call if_changed,socnandboot)
RE: [PATCH v1] spi: cadence_qspi: Probe fail if QSPI clock is not set
> Hi,
>
> On 05/08/20 3:48 pm, Chee Hong Ang wrote:
> > If the QSPI clock is not set (read as 0), QSPI driver probe shall fail
> > and prevent further QSPI access.
> >
> > Signed-off-by: Chee Hong Ang
> > ---
> > drivers/spi/cadence_qspi.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/spi/cadence_qspi.c b/drivers/spi/cadence_qspi.c
> > index 1e85749209..3bb5c7031d 100644
> > --- a/drivers/spi/cadence_qspi.c
> > +++ b/drivers/spi/cadence_qspi.c
> > @@ -170,6 +170,9 @@ static int cadence_spi_probe(struct udevice *bus)
> > struct clk clk;
> > int ret;
> >
> > + if (!CONFIG_CQSPI_REF_CLK)
> > + return -ENODEV;
> > +
>
> This seems broken to me...
>
> Most platforms have moved away from passing clk freq via CONFIG_ and are
> using more scalable DT or platdata approach where freq is obtained via
I think the proper way to resolve this is to change our clock driver to DM.
Thanks.
> clk_get_*() APIs... See few lines below:
>
> if (plat->ref_clk_hz == 0) {
> ret = clk_get_by_index(bus, 0, );
> if (ret) {
> #ifdef CONFIG_CQSPI_REF_CLK
> plat->ref_clk_hz = CONFIG_CQSPI_REF_CLK; #else
> return ret;
> #endif
> } else {
> plat->ref_clk_hz = clk_get_rate();
> clk_free();
> if (IS_ERR_VALUE(plat->ref_clk_hz))
> return plat->ref_clk_hz;
> }
> }
>
> So there is no need to make CONFIG_CQSPI_REF_CLK mandatory.
> Probe may fail only when CONFIG_CQSPI_REF_CLK is undefined and there is
> no reference to a valid clk device either.
>
>
> > priv->regbase = plat->regbase;
> > priv->ahbbase = plat->ahbbase;
> >
> >
>
> Regards
> Vignesh
RE: [PATCH v1] sysreset: socfpga: agilex: Enable sysreset support
> > -Original Message- > > From: Ang, Chee Hong > > Sent: Wednesday, August 5, 2020 5:54 PM > > To: u-boot@lists.denx.de > > Cc: Marek Vasut ; Simon Goldschmidt > > ; Tom Rini ; See, > > Chin Liang ; Tan, Ley Foon > > ; Ang, Chee Hong ; > > Chee, Tien Fong ; Lim, Elly Siew Chin > > > > Subject: [PATCH v1] sysreset: socfpga: agilex: Enable sysreset support > > > > Enable sysreset support for Agilex platform. > > > > Signed-off-by: Chee Hong Ang > > --- > > arch/arm/Kconfig | 2 +- > > drivers/sysreset/Kconfig | 6 +++--- > > 2 files changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index > > 6b8a32c38d..105b5f08a9 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -991,7 +991,7 @@ config ARCH_SOCFPGA > > select SYS_THUMB_BUILD if TARGET_SOCFPGA_GEN5 || > > TARGET_SOCFPGA_ARRIA10 > > select SYSRESET > > select SYSRESET_SOCFPGA if TARGET_SOCFPGA_GEN5 || > > TARGET_SOCFPGA_ARRIA10 > > - select SYSRESET_SOCFPGA_S10 if TARGET_SOCFPGA_STRATIX10 > > + select SYSRESET_SOCFPGA_S10 if TARGET_SOCFPGA_STRATIX10 || > > +TARGET_SOCFPGA_AGILEX > > imply CMD_DM > > imply CMD_MTDPARTS > > imply CRC32_VERIFY > > diff --git a/drivers/sysreset/Kconfig b/drivers/sysreset/Kconfig index > > 6ebc90e1d3..d886d1c933 100644 > > --- a/drivers/sysreset/Kconfig > > +++ b/drivers/sysreset/Kconfig > > @@ -80,11 +80,11 @@ config SYSRESET_SOCFPGA > > (Cyclone 5, Arria 5 and Arria 10). > > > > config SYSRESET_SOCFPGA_S10 > > This can change to _SOC64. Do I need to change the source file from drivers/sysreset/sysreset_socfpga_s10.c to drivers/sysreset/sysreset_socfpga_soc64.c as well ? drivers/sysreset/makefile has this: obj-$(CONFIG_SYSRESET_SOCFPGA_S10) += sysreset_socfpga_s10.o > > > > - bool "Enable support for Intel SOCFPGA Stratix 10" > > - depends on ARCH_SOCFPGA && TARGET_SOCFPGA_STRATIX10 > > + bool "Enable support for Intel SOCFPGA SoC64 family > > (Stratix10/Agilex)" > > + depends on ARCH_SOCFPGA && (TARGET_SOCFPGA_STRATIX10 || > > +TARGET_SOCFPGA_AGILEX) > > Regards > Ley Foon > > >
RE: [PATCH v1 3/4] clk: agilex: Handle clock configuration differently in SPL and U-Boot proper
> > From: Ang, Chee Hong > > Sent: Friday, July 10, 2020 8:55 PM > > To: u-boot@lists.denx.de > > Cc: Marek Vasut ; Simon Goldschmidt > > ; See, Chin Liang > > ; Tan, Ley Foon ; > > Ang, Chee Hong > > Subject: [PATCH v1 3/4] clk: agilex: Handle clock configuration > > differently in SPL and U-Boot proper > > > > Since warm reset may optionally set the CLock Manager to'boot mode', > > the clock driver should always force the Agilex's Clock Manager to 'boot > mode' > > before the clock driver start configuring the Clock Manager in SPL. > > In SSBL, clock driver will skip the Clock Manager configuration if > > it's already being setup by SPL (Clock Manager NOT in 'boot > > mode') to prevent any inaccurate clocking issues happened on HPS > > peripherals such as UART, MAC and etc. > > > > Signed-off-by: Chee Hong Ang > > --- > > drivers/clk/altera/clk-agilex.c | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/drivers/clk/altera/clk-agilex.c > > b/drivers/clk/altera/clk-agilex.c index b5cf187364..c83eb2efb9 100644 > > --- a/drivers/clk/altera/clk-agilex.c > > +++ b/drivers/clk/altera/clk-agilex.c > > @@ -171,6 +171,16 @@ static void clk_basic_init(struct udevice *dev, > > if (!cfg) > > return; > > > > +#ifdef CONFIG_SPL_BUILD > > + /* Always force clock manager into boot mode before any > > configuration */ > > + clk_write_ctrl(plat, > > + CM_REG_READL(plat, CLKMGR_CTRL) | > > CLKMGR_CTRL_BOOTMODE); #else > "#else" is at the end of line, is this patch display issue or coding issue? Only happen in display. Code is fine. > > > Regards > Ley Foon
RE: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
> On Fri, Apr 3, 2020 at 6:56 AM Ang, Chee Hong > wrote: > > > > > On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong > > > > > > wrote: > > > > > On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote: > > > > > > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass > wrote: > > > > > > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko > > > > > > > > > > > > > This reverts commit > > > 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. > > > > > > Adding SoCFPGA folks to this thread as the first commit > > > > > (82de42fa1468) is also breaking platforms there and then their > > > > > fix for that problem is also causing problems, if I follow right. > > > > > > > Yes. This commit (82de42fa1468) breaks our A10 platform. > > > > I did submit similar patch to move some init code from > > > > ofdata_to_platdata() to > > > probe() for our clock driver as well. > > > > Check out the thread here: > > > > https://lists.denx.de/pipermail/u-boot/2020-April/405252.html > > > > > > I see half or less of the messages in the thread by above link. > > > Can you summarize what should have been done in order to fix this? > > 1) Fix in the driver (broken by this commit: 82de42fa1468) by moving some > code from ofdata_to_platdata() to probe(). > > 2) Fix the DM core. > > Simon and Marek were discussing about these 2 options. > > Perhaps Simon can help shed some light here. > > I have a question. Does revert of > 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c makes any difference to > SoCFPGA? This commit: 82de42fa1468 break our SoCFPGA A10 clock driver. This commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c does not affect our SoCFPGA platforms. We just want to know which way to go. Fixing our A10 clock driver or fix the DM core. Seems like this commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c go with option 1 (fixing the driver). > > -- > With Best Regards, > Andy Shevchenko
RE: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
> On Thu, Apr 2, 2020 at 7:28 PM Ang, Chee Hong > wrote: > > > On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote: > > > > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass wrote: > > > > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko > > > wrote: > > > > > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote: > > > > > > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko > > > wrote: > > > > > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng > > > > > > > > > > > wrote: > > > > > > > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > The commit breaks serial console on the Intel Edison. > > > > > > > > > > > > > > > > > > > > This reverts commit > 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. > > > > > > > > > > > > > > > > > > > > Signed-off-by: Andy Shevchenko > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > drivers/serial/ns16550.c | 40 > > > > > > > > > > > > > > > > > > > > 1 file changed, 12 insertions(+), 28 deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > > > > Could you please spend some time to investigate why this > > > > > > > > > breaks Intel > > > Edison? > > > > > > > > > > > > > > > > > > Reverting this patch would mean we break other boards > > > > > > > > > too as Wolfgang's patch wanted to fix the breakage in > > > > > > > > > the first place. Much appreciated! > > > > > > > > > > > > > > > > I guess I'm wrong person here. The DM code is a complete > > > > > > > > black box to > > > me. > > > > > > > > Nevertheless, I may test any provided fix / debug / etc patch by > request. > > > > > > > > > > > > > > > > And I think it's fair to investigate by the one who made a > > > > > > > > regression in the first place. > > > > > > > > > > > > > > Given that we have conflicting breakages, we need to debug Edison. > > > > > > > > > > > > I would glad to test any suggested change or debug patch! > > > > > > > > > > > > > Does it enable the debug UART? > > > > > > > > > > > > If I am not mistaken, it does not. > > > > > > > > > > Looks like you are right. If you know the address you could do > > > > > that > > > > > - see minnowmax for an example. > > > > > > > > Please suggest what's the best approach to proceed. > > > > > > Adding SoCFPGA folks to this thread as the first commit > > > (82de42fa1468) is also breaking platforms there and then their fix > > > for that problem is also causing problems, if I follow right. > > > Yes. This commit (82de42fa1468) breaks our A10 platform. > > I did submit similar patch to move some init code from ofdata_to_platdata() > > to > probe() for our clock driver as well. > > Check out the thread here: > > https://lists.denx.de/pipermail/u-boot/2020-April/405252.html > > I see half or less of the messages in the thread by above link. > Can you summarize what should have been done in order to fix this? 1) Fix in the driver (broken by this commit: 82de42fa1468) by moving some code from ofdata_to_platdata() to probe(). 2) Fix the DM core. Simon and Marek were discussing about these 2 options. Perhaps Simon can help shed some light here. > > -- > With Best Regards, > Andy Shevchenko
RE: [PATCH v2 1/2] serial: ns16550: Revert "Move PCI access from ofdata_to_platdata() to probe()"
> On Thu, Apr 02, 2020 at 12:55:14PM +0800, Bin Meng wrote: > > Hi Simon, Andy, > > > > On Thu, Apr 2, 2020 at 1:55 AM Simon Glass wrote: > > > > > > Hi Andy, > > > > > > On Wed, 1 Apr 2020 at 11:39, Andy Shevchenko > wrote: > > > > > > > > On Wed, Apr 01, 2020 at 10:56:26AM -0600, Simon Glass wrote: > > > > > Hi Andy, > > > > > > > > > > On Wed, 1 Apr 2020 at 08:45, Andy Shevchenko > wrote: > > > > > > > > > > > > On Wed, Apr 1, 2020 at 5:32 PM Bin Meng > wrote: > > > > > > > On Wed, Apr 1, 2020 at 9:58 PM Andy Shevchenko > > > > > > > wrote: > > > > > > > > > > > > > > > > The commit breaks serial console on the Intel Edison. > > > > > > > > > > > > > > > > This reverts commit 720f9e1fdb0c92d3fd16e1bfc25bcbd35612675c. > > > > > > > > > > > > > > > > Signed-off-by: Andy Shevchenko > > > > > > > > > > > > > > > > --- > > > > > > > > drivers/serial/ns16550.c | 40 > > > > > > > > > > > > > > > > 1 file changed, 12 insertions(+), 28 deletions(-) > > > > > > > > > > > > > > > > > > > > > > Could you please spend some time to investigate why this breaks > > > > > > > Intel > Edison? > > > > > > > > > > > > > > Reverting this patch would mean we break other boards too as > > > > > > > Wolfgang's patch wanted to fix the breakage in the first > > > > > > > place. Much appreciated! > > > > > > > > > > > > I guess I'm wrong person here. The DM code is a complete black box > > > > > > to > me. > > > > > > Nevertheless, I may test any provided fix / debug / etc patch by > > > > > > request. > > > > > > > > > > > > And I think it's fair to investigate by the one who made a > > > > > > regression in the first place. > > > > > > > > > > Given that we have conflicting breakages, we need to debug Edison. > > > > > > > > I would glad to test any suggested change or debug patch! > > > > > > > > > Does it enable the debug UART? > > > > > > > > If I am not mistaken, it does not. > > > > > > Looks like you are right. If you know the address you could do that > > > - see minnowmax for an example. > > > > Please suggest what's the best approach to proceed. > > Adding SoCFPGA folks to this thread as the first commit (82de42fa1468) is also > breaking platforms there and then their fix for that problem is also causing > problems, if I follow right. > > -- > Tom Yes. This commit (82de42fa1468) breaks our A10 platform. I did submit similar patch to move some init code from ofdata_to_platdata() to probe() for our clock driver as well. Check out the thread here: https://lists.denx.de/pipermail/u-boot/2020-April/405252.html
RE: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function
> On 4/2/20 4:34 AM, Simon Glass wrote: > > Hi, > > > > On Tue, 31 Mar 2020 at 20:33, Ang, Chee Hong > wrote: > >> > >>> Hi Marek, > >>> > >>> On Wed, 11 Mar 2020 at 05:55, Marek Vasut wrote: > >>>> > >>>> On 3/11/20 12:50 PM, Simon Glass wrote: > >>>>> Hi, > >>>> > >>>> Hi, > >>>> > >>>>> On Mon, 9 Mar 2020 at 02:22, wrote: > >>>>>> > >>>>>> From: Chee Hong Ang > >>>>>> > >>>>>> This commit (82de42fa14682d408da935adfb0f935354c5008f) calls > >>>>>> child's > >>>>>> ofdata_to_platdata() method before the parent is probed in dm core. > >>>>>> This has caused the driver no longer able to get the correct > >>>>>> parent clock's register base in the ofdata_to_platdata() method > >>>>>> because the parent clocks will only be probed after the child's > ofdata_to_platdata(). > >>>>>> To resolve this, the clock parent's register base will only be > >>>>>> retrieved by the child in probe() method instead of > >>>>>> ofdata_to_platdata(). > >>>>> > >>>>> I think one thing that is going on here is that DM allows ofdata > >>>>> to be read for a device before its parent devices have been read, > >>>>> but it requires that parent devices be probed before their children. > >>>> > >>>> This seems wrong. The clock driver should be able to instantiate > >>>> devices and read their ofdata without probing them. That is one of > >>>> the core design principles of the DM. > >>> > >>> That's a different question. Yes you can read ofdata without probing a > device. > >>> That's why we have two methods. > >>> > >>> The point I am making is that at present there is no requirement > >>> that a parent's ofdata be read before a child's ofdata is read. But > >>> there is a requirement that a parent be probed before a child is probed. > >>> > >>>> > >>>>> The idea is that it should be possible to read the ofdata for a > >>>>> node without needing to have done so for parents. But perhaps this > >>>>> assumption is too brave? > >>>> > >>>> Why is it brave ? That's how it always was, the DT is already > >>>> there, so why wouldn't you be able to read it. > >>> > >>> That was my thinking too. But we are finding in a few situations > >>> that the child's ofdata depends on the parent's. For example, the > >>> parent may have a base address, or a range mapping, or something > >>> else that is needed for the child to correctly get its base address, etc. > >>> > >>>> > >>>>> I suspect we could change this, so that > >>>>> device_ofdata_to_platdata() first calls itself on its parent. > >>>>> > >>>>> I can think of various reasons why this change might be desirable. > >>>> > >>>> I think this is how it worked before already. > >>> > >>> Well effectively, yes, because ofdata and probe were joined together. > > > >> Simon, do you have plan to fix this DM core issue ? > > > > I'm not sure it definitely should be changed. But I'll do a patch and > > see how it looks. > > Do I understand it correctly that the patch > 82de42fa14682d408da935adfb0f935354c5008f actually completely breaks > SoCFPGA ? Then I would say this is a release blocker ? Yes. A10 SPL won't boot at all. It crashes during the clock manager setup.
RE: [PATCH v5 00/17] Enable ARM Trusted Firmware for U-Boot
Hi Marek/Simon,
Can you please help review and comment on this patchsets ?
> Any comment on this v5 patchsets ?
>
> > From: "Ang, Chee Hong"
> >
> > v5 changes:
> > This is another revision without the System Manager driver to handle
> > the secure/non-secure access. DW MAC and MMC drivers will make direct
> > calls to the high-level API to ATF if it's running in EL2 on
> > Stratix10/Agilex otherwise these drivers work as it is.
> >
> > [PATCH v5 08/17] arm: socfpga: Define SMC function identifiers for
> > PSCI SiP services
> > - Add documentation for high-level API supported by ATF:
> > - INTEL_SIP_SMC_FUNCID_HPS_SET_PHYINTF (For setting PHY interface)
> > - INTEL_SIP_SMC_FUNCID_HPS_SET_SDMMC_CCLK (For setting SDMMC
> clock
> > phase)
> >
> > [PATCH v5 10/17] mmc: dwmmc: socfpga: Add ATF support for MMC driver
> > - Call 'INTEL_SIP_SMC_FUNCID_HPS_SET_SDMMC_CCLK' if U-Boot running in
> > EL2 (non-secure)
> >
> > [PATCH v5 11/17] net: designware: socfpga: Add ATF support for MAC
> > driver
> > - Call 'INTEL_SIP_SMC_FUNCID_HPS_SET_PHYINTF' if U-Boot running in EL2
> > (non-secure)
> >
> > [PATCH v5 17/17] configs: socfpga: Add defconfig for Agilex and
> > Stratix 10 with ATF support
> > - Keep the existing Stratix10/Agilex defconfigs and add new defconfigs
> > with ATF support
> >
> > v4:
> > https://lists.denx.de/pipermail/u-boot/2020-March/402289.html
> >
> > These patchsets have dependency on:
> > https://lists.denx.de/pipermail/u-boot/2019-September/384906.html
> >
> > Ang, Chee Hong (1):
> > configs: socfpga: Add defconfig for Agilex and Stratix 10 with ATF
> > support
> >
> > Chee Hong Ang (16):
> > configs: agilex: Remove CONFIG_OF_EMBED
> > 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
> > 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: soc64: Remove PHY interface setup from misc arch init
> > mmc: dwmmc: socfpga: Add ATF support for MMC driver
> > net: designware: socfpga: Add ATF support for MAC driver
> > arm: socfpga: Add ATF support for Reset Manager driver
> > arm: socfpga: stratix10: Initialize timer in SPL
> > arm: socfpga: Add ATF support to query FPGA configuration status
> > arm: socfpga: stratix10: Add ATF support for FPGA reconfig driver
> > arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to
> > mbox_reset_cold()
> >
> > arch/arm/mach-socfpga/Kconfig | 2 -
> > arch/arm/mach-socfpga/Makefile | 2 +
> > arch/arm/mach-socfpga/board.c | 10 +
> > arch/arm/mach-socfpga/include/mach/misc.h | 3 +
> > arch/arm/mach-socfpga/lowlevel_init_64.S | 81
> > arch/arm/mach-socfpga/mailbox_s10.c| 4 +
> > arch/arm/mach-socfpga/misc_s10.c | 121 ++
> > arch/arm/mach-socfpga/reset_manager_s10.c | 10 +
> > arch/arm/mach-socfpga/timer_s10.c | 3 +-
> > board/altera/soc64/its/fit_spl_atf.its | 52 +++
> > ...ilex_defconfig => socfpga_agilex_atf_defconfig} | 8 +-
> > configs/socfpga_agilex_defconfig | 1 -
> > ...x_defconfig => socfpga_stratix10_atf_defconfig} | 23 +-
> > drivers/fpga/stratix10.c | 141 ++-
> > drivers/mmc/socfpga_dw_mmc.c | 21 +
> > drivers/net/dwmac_socfpga.c| 43 +-
> > include/configs/socfpga_soc64_common.h | 4 +
> > include/linux/intel-smc.h | 445
> > +
> > 18 files changed, 871 insertions(+), 103 deletions(-) create mode
> > 100644 arch/arm/mach-socfpga/lowlevel_init_64.S
> > create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> > copy configs/{socfpga_agilex_defconfig =>
> > socfpga_agilex_atf_defconfig}
> > (87%) copy configs/{socfpga_agilex_defconfig =>
> > socfpga_stratix10_atf_defconfig} (68%) create mode 100644
> > include/linux/intel-smc.h
> >
> > --
> > 2.7.4
RE: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function
> Hi Marek, > > On Wed, 11 Mar 2020 at 05:55, Marek Vasut wrote: > > > > On 3/11/20 12:50 PM, Simon Glass wrote: > > > Hi, > > > > Hi, > > > > > On Mon, 9 Mar 2020 at 02:22, wrote: > > >> > > >> From: Chee Hong Ang > > >> > > >> This commit (82de42fa14682d408da935adfb0f935354c5008f) calls > > >> child's > > >> ofdata_to_platdata() method before the parent is probed in dm core. > > >> This has caused the driver no longer able to get the correct parent > > >> clock's register base in the ofdata_to_platdata() method because > > >> the parent clocks will only be probed after the child's > > >> ofdata_to_platdata(). > > >> To resolve this, the clock parent's register base will only be > > >> retrieved by the child in probe() method instead of ofdata_to_platdata(). > > > > > > I think one thing that is going on here is that DM allows ofdata to > > > be read for a device before its parent devices have been read, but > > > it requires that parent devices be probed before their children. > > > > This seems wrong. The clock driver should be able to instantiate > > devices and read their ofdata without probing them. That is one of the > > core design principles of the DM. > > That's a different question. Yes you can read ofdata without probing a device. > That's why we have two methods. > > The point I am making is that at present there is no requirement that a > parent's > ofdata be read before a child's ofdata is read. But there is a requirement > that a > parent be probed before a child is probed. > > > > > > The idea is that it should be possible to read the ofdata for a node > > > without needing to have done so for parents. But perhaps this > > > assumption is too brave? > > > > Why is it brave ? That's how it always was, the DT is already there, > > so why wouldn't you be able to read it. > > That was my thinking too. But we are finding in a few situations that the > child's > ofdata depends on the parent's. For example, the parent may have a base > address, or a range mapping, or something else that is needed for the child to > correctly get its base address, etc. > > > > > > I suspect we could change this, so that device_ofdata_to_platdata() > > > first calls itself on its parent. > > > > > > I can think of various reasons why this change might be desirable. > > > > I think this is how it worked before already. > > Well effectively, yes, because ofdata and probe were joined together. > > Regards, > Simon Simon, do you have plan to fix this DM core issue ?
RE: [PATCH v5 00/17] Enable ARM Trusted Firmware for U-Boot
Any comment on this v5 patchsets ?
> From: "Ang, Chee Hong"
>
> v5 changes:
> This is another revision without the System Manager driver to handle the
> secure/non-secure access. DW MAC and MMC drivers will make direct calls to
> the high-level API to ATF if it's running in EL2 on Stratix10/Agilex
> otherwise these
> drivers work as it is.
>
> [PATCH v5 08/17] arm: socfpga: Define SMC function identifiers for PSCI SiP
> services
> - Add documentation for high-level API supported by ATF:
> - INTEL_SIP_SMC_FUNCID_HPS_SET_PHYINTF (For setting PHY interface)
> - INTEL_SIP_SMC_FUNCID_HPS_SET_SDMMC_CCLK (For setting SDMMC clock
> phase)
>
> [PATCH v5 10/17] mmc: dwmmc: socfpga: Add ATF support for MMC driver
> - Call 'INTEL_SIP_SMC_FUNCID_HPS_SET_SDMMC_CCLK' if U-Boot running in
> EL2 (non-secure)
>
> [PATCH v5 11/17] net: designware: socfpga: Add ATF support for MAC driver
> - Call 'INTEL_SIP_SMC_FUNCID_HPS_SET_PHYINTF' if U-Boot running in EL2
> (non-secure)
>
> [PATCH v5 17/17] configs: socfpga: Add defconfig for Agilex and Stratix 10
> with
> ATF support
> - Keep the existing Stratix10/Agilex defconfigs and add new defconfigs with
> ATF
> support
>
> v4:
> https://lists.denx.de/pipermail/u-boot/2020-March/402289.html
>
> These patchsets have dependency on:
> https://lists.denx.de/pipermail/u-boot/2019-September/384906.html
>
> Ang, Chee Hong (1):
> configs: socfpga: Add defconfig for Agilex and Stratix 10 with ATF
> support
>
> Chee Hong Ang (16):
> configs: agilex: Remove CONFIG_OF_EMBED
> 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
> 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: soc64: Remove PHY interface setup from misc arch init
> mmc: dwmmc: socfpga: Add ATF support for MMC driver
> net: designware: socfpga: Add ATF support for MAC driver
> arm: socfpga: Add ATF support for Reset Manager driver
> arm: socfpga: stratix10: Initialize timer in SPL
> arm: socfpga: Add ATF support to query FPGA configuration status
> arm: socfpga: stratix10: Add ATF support for FPGA reconfig driver
> arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to
> mbox_reset_cold()
>
> arch/arm/mach-socfpga/Kconfig | 2 -
> arch/arm/mach-socfpga/Makefile | 2 +
> arch/arm/mach-socfpga/board.c | 10 +
> arch/arm/mach-socfpga/include/mach/misc.h | 3 +
> arch/arm/mach-socfpga/lowlevel_init_64.S | 81
> arch/arm/mach-socfpga/mailbox_s10.c| 4 +
> arch/arm/mach-socfpga/misc_s10.c | 121 ++
> arch/arm/mach-socfpga/reset_manager_s10.c | 10 +
> arch/arm/mach-socfpga/timer_s10.c | 3 +-
> board/altera/soc64/its/fit_spl_atf.its | 52 +++
> ...ilex_defconfig => socfpga_agilex_atf_defconfig} | 8 +-
> configs/socfpga_agilex_defconfig | 1 -
> ...x_defconfig => socfpga_stratix10_atf_defconfig} | 23 +-
> drivers/fpga/stratix10.c | 141 ++-
> drivers/mmc/socfpga_dw_mmc.c | 21 +
> drivers/net/dwmac_socfpga.c| 43 +-
> include/configs/socfpga_soc64_common.h | 4 +
> include/linux/intel-smc.h | 445
> +
> 18 files changed, 871 insertions(+), 103 deletions(-) create mode 100644
> arch/arm/mach-socfpga/lowlevel_init_64.S
> create mode 100644 board/altera/soc64/its/fit_spl_atf.its
> copy configs/{socfpga_agilex_defconfig => socfpga_agilex_atf_defconfig}
> (87%) copy configs/{socfpga_agilex_defconfig =>
> socfpga_stratix10_atf_defconfig} (68%) create mode 100644
> include/linux/intel-smc.h
>
> --
> 2.7.4
RE: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager driver
> On 3/11/20 8:03 AM, Ang, Chee Hong wrote: > >> On 3/11/20 7:35 AM, Ang, Chee Hong wrote: > >> [...] > >> > >>>>>> Hmm, so you're just using misc_ops to still issue generic writes. > >>>>>> From the discussion with Marek in the last version, I would have > >>>>>> thought you wanted to create a higher level API instead of still > >>>>>> tunnelling > >>>> reads and writes? > >>>> > >>>> Any response to this? > >>> Sorry, I missed this one > >>> Actually I have created higher level API in ATF but I switch back to > >>> generic writes because the higher level API in ATF doesn't apply to > >>> Gen5/A10 > >> platforms. > >> > >> ATF doesn't apply to Gen5/A10 either though ? > >> > >>> Here is what I will do in my revision in system manager driver: > >>> 1) drop misc_read/misc_write and use misc_ioctl instead in system > >>> manager > >>> 2) misc_ioctl() will support configuring EMAC/SDMMC > >>> 3) For SoC64 running at EL2 (non-secure), misc_iotctl() will invoke > >>> the ATF's 'high level' API > >>> 4) For Gen/A10 and SoC64 running at EL3 (secure), the driver just > >>> configure the EMAC/SDMMC registers in misc_iotcl() Is this better ? > >> Can't you configure everything in secure-mode and just not configure > >> anything anymore in non-secure mode ? > > Yes. I can move all these configurations to SPL(secure mode) and remove them > from EMAC/SDMMC drivers. > > This will affect all platforms even Gen5/A10 even they don’t have the secure > access problems. > > Gen5/A10 are always in "secure" mode. > > > All Gen5/A10/S10/Agilex share the same EMAC/SDMMC drivers. > > Surely you can abstract this away somehow, e.g. with some function which is > compiled-out on Gen5/A10, while it's compiled-in on Agilex and tells you > whether you're in EL2/EL3 mode. That's right. We have Gen5/A10 always in "secure" mode and S10/Agilex can be in either "secure" or "non-secure" mode. All of them share the same DW MMC/MAC drivers. In all platforms, EMAC driver only active in U-Boot proper but not SPL. This is not an issue for Gen5/A10 as SPL/U-Boot proper all run in "secure" mode. But this is not the case for S10/Agilex, EMAC driver is active only in U-Boot proper which can be EL2 or EL3 depending whether you include ATF support. So the MAC driver has to somehow handle this PHY configuration in EL2 and EL3. > > > For EMAC driver such as 'drivers/net/dwmac_socfpga.c', moving the PHY > > settings into SPL will leave this EMAC driver just asserting reset to EMAC > controller and nothing else. > > EMAC node has to be enabled for SPL device tree as well for MAC PHY > configuration. > > If you think it is OK to split the SDMMC clock and EMAC PHY > > configuration from SDMMC and EMAC drivers and put them in SPL, we can go > this way. > > I can just drop the 'system manager' driver and all those high level APIs > > in ATF. > > If this is only about clock/PHY configuration, can't the clock/PHY driver for > agilex just handle the EL2/EL3 stuff transparently ? This is the clock phase settings specific to SDMMC controller. That's why it is being configured in SDMCC driver instead of clock driver. There is no PHY driver for EMAC PHY. It's current being handled in DW MAC driver 'drivers/net/dwmac_socfpga.c'. > -- > Best regards, > Marek Vasut
RE: [PATCH v4 14/21] arch: arm: socfpga: Add 'altr, sysmgr-syscon' for MMC node in device tree
> -Original Message-
> From: Simon Goldschmidt
> Sent: Wednesday, March 11, 2020 1:06 AM
> To: Ang, Chee Hong ; u-boot@lists.denx.de
> Cc: Marek Vasut ; See, Chin Liang ;
> Tan, Ley Foon ; Westergreen, Dalon
> ; Gong, Richard
> Subject: Re: [PATCH v4 14/21] arch: arm: socfpga: Add 'altr,sysmgr-syscon' for
> MMC node in device tree
>
> Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com:
> > From: Chee Hong Ang
> >
> > In device tree for all socfpga platforms, a phandle to System Manager
> > ('altr,sysmgr-syscon') is needed for MMC node to enable the MMC driver
> > to configure the SDMMC's clock phase shift via System Manager driver
> > (altera_sysmgr).
> > This phandle specifies the offset of the SDMCC control register in
> > System Manager, start of bit field for drvsel and start of bit field
> > for smplsel.
> >
> > Signed-off-by: Chee Hong Ang
> > ---
> > arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi| 1 +
> > arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 1 +
> > arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi| 1 +
> > arch/arm/dts/socfpga_cyclone5.dtsi | 1 +
> > arch/arm/dts/socfpga_stratix10.dtsi | 1 -
> > arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi | 7 +++
> > arch/arm/dts/socfpga_stratix10_socdk.dts | 2 --
>
> This looks strange. I would have expected you add the 'syscon' entry to the
> base
> dtsi files (and to the ones in Linux, too, btw). But you're adding it to "-u-
> boot.dtsi" files, too. Why?
Where to add new device tree entry is rather confusing to me.
Linux SDMMC driver doesn't set the SDMMC clock. So this only
applicable to U-Boot only.
I thought "-u-boot-dtsi" is the place where we should put those
device tree entries that are only applicable to U-Boot only ?
>
> Regards,
> Simon
>
> > 7 files changed, 11 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> > b/arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> > index 1908be4..56fd7d9 100644
> > --- a/arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> > +++ b/arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi
> > @@ -34,6 +34,7 @@
> > {
> > drvsel = <3>;
> > smplsel = <0>;
> > + altr,sysmgr-syscon = < 0x28 0 4>;
> > u-boot,dm-pre-reloc;
> > };
> >
> > diff --git a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > index d6b6c2d..887673b 100644
> > --- a/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > +++ b/arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts
> > @@ -44,6 +44,7 @@
> > cap-sd-highspeed;
> > broken-cd;
> > bus-width = <4>;
> > + altr,sysmgr-syscon = < 0x28 0 4>;
> > };
> >
> > {
> > diff --git a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > index dfaff4c..d2189f1 100644
> > --- a/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > +++ b/arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi
> > @@ -20,6 +20,7 @@
> > };
> >
> > {
> > + altr,sysmgr-syscon = < 0x108 0 3>;
> > u-boot,dm-pre-reloc;
> > };
> >
> > diff --git a/arch/arm/dts/socfpga_cyclone5.dtsi
> > b/arch/arm/dts/socfpga_cyclone5.dtsi
> > index 319a71e..c309681 100644
> > --- a/arch/arm/dts/socfpga_cyclone5.dtsi
> > +++ b/arch/arm/dts/socfpga_cyclone5.dtsi
> > @@ -23,6 +23,7 @@
> > bus-width = <4>;
> > cap-mmc-highspeed;
> > cap-sd-highspeed;
> > + altr,sysmgr-syscon = < 0x108 0 3>;
> > };
> >
> > sysmgr@ffd08000 {
> > diff --git a/arch/arm/dts/socfpga_stratix10.dtsi
> > b/arch/arm/dts/socfpga_stratix10.dtsi
> > index a8e61cf..9c89065 100755
> > --- a/arch/arm/dts/socfpga_stratix10.dtsi
> > +++ b/arch/arm/dts/socfpga_stratix10.dtsi
> > @@ -228,7 +228,6 @@
> > interrupts = <0 96 4>;
> > fifo-depth = <0x400>;
> > resets = < SDMMC_RESET>, <
> SDMMC_OCP_RESET>;
> > - u-boot,dm-pre-reloc;
> > status = "disabled";
> > };
> >
> > diff --git a/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
> > b/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
> > index a903040..ca91b40 100755
> > --- a/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
> > +++ b/arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi
> > @@ -28,6 +28,13 @@
> > u-boot,dm-pre-reloc;
> > };
> >
> > + {
> > + drvsel = <3>;
> > + smplsel = <0>;
> > + altr,sysmgr-syscon = < 0x28 0 4>;
> > + u-boot,dm-pre-reloc;
> > +};
> > +
> > {
> > u-boot,dm-pre-reloc;
> > };
> > diff --git a/arch/arm/dts/socfpga_stratix10_socdk.dts
> > b/arch/arm/dts/socfpga_stratix10_socdk.dts
> > index b7b48a5..ff6e1b2 100755
> > --- a/arch/arm/dts/socfpga_stratix10_socdk.dts
> > +++ b/arch/arm/dts/socfpga_stratix10_socdk.dts
> > @@ -91,8 +91,6 @@
> > cap-mmc-highspeed;
> > broken-cd;
> > bus-width = <4>;
> > - drvsel = <3>;
> > - smplsel = <0>;
> > };
> >
> > {
> >
RE: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager driver
> On 3/11/20 7:35 AM, Ang, Chee Hong wrote: > [...] > > >>>> Hmm, so you're just using misc_ops to still issue generic writes. > >>>> From the discussion with Marek in the last version, I would have > >>>> thought you wanted to create a higher level API instead of still > >>>> tunnelling > >> reads and writes? > >> > >> Any response to this? > > Sorry, I missed this one > > Actually I have created higher level API in ATF but I switch back to > > generic writes because the higher level API in ATF doesn't apply to Gen5/A10 > platforms. > > ATF doesn't apply to Gen5/A10 either though ? > > > Here is what I will do in my revision in system manager driver: > > 1) drop misc_read/misc_write and use misc_ioctl instead in system > > manager > > 2) misc_ioctl() will support configuring EMAC/SDMMC > > 3) For SoC64 running at EL2 (non-secure), misc_iotctl() will invoke > > the ATF's 'high level' API > > 4) For Gen/A10 and SoC64 running at EL3 (secure), the driver just > > configure the EMAC/SDMMC registers in misc_iotcl() Is this better ? > Can't you configure everything in secure-mode and just not configure anything > anymore in non-secure mode ? Yes. I can move all these configurations to SPL(secure mode) and remove them from EMAC/SDMMC drivers. This will affect all platforms even Gen5/A10 even they don’t have the secure access problems. All Gen5/A10/S10/Agilex share the same EMAC/SDMMC drivers. For EMAC driver such as 'drivers/net/dwmac_socfpga.c', moving the PHY settings into SPL will leave this EMAC driver just asserting reset to EMAC controller and nothing else. EMAC node has to be enabled for SPL device tree as well for MAC PHY configuration. If you think it is OK to split the SDMMC clock and EMAC PHY configuration from SDMMC and EMAC drivers and put them in SPL, we can go this way. I can just drop the 'system manager' driver and all those high level APIs in ATF. > > -- > Best regards, > Marek Vasut
RE: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager driver
> Am 10.03.2020 um 17:42 schrieb Ang, Chee Hong:
> >> -Original Message-
> >> From: Simon Goldschmidt
> >> Sent: Wednesday, March 11, 2020 12:17 AM
> >> To: Ang, Chee Hong
> >> Cc: u-boot@lists.denx.de; Marek Vasut ; See, Chin
> >> Liang ; Tan, Ley Foon
> >> ; Westergreen, Dalon
> >> ; Gong, Richard
> >> Subject: Re: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System
> >> Manager driver
> >>
> >> Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com:
> >>> From: Chee Hong Ang
> >>>
> >>> This driver (misc uclass) handle the read/write access to System
> >>> Manager. For 64 bits platforms, processor needs to be in secure mode
> >>> to has write access to most of the System Manager's registers
> >>> (except boot scratch registers). When the processor is running in
> >>> EL2 (non-secure), this driver will invoke the SMC call to ATF to
> >>> perform write access to the System Manager's registers.
> >>> All other drivers that require access to System Manager should go
> >>> through this driver.
> >>>
> >>> Signed-off-by: Chee Hong Ang
> >>> ---
> >>> drivers/misc/Makefile| 1 +
> >>> drivers/misc/altera_sysmgr.c | 115
> >>> +++
> >>> 2 files changed, 116 insertions(+)
> >>> create mode 100644 drivers/misc/altera_sysmgr.c
> >>>
> >>> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
> >>> 2b843de..9fa2411 100644
> >>> --- a/drivers/misc/Makefile
> >>> +++ b/drivers/misc/Makefile
> >>> @@ -29,6 +29,7 @@ endif
> >>> endif
> >>> obj-$(CONFIG_ALI152X) += ali512x.o
> >>> obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
> >>> +obj-$(CONFIG_ARCH_SOCFPGA) += altera_sysmgr.o
> >>> obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
> >>> obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
> >>> obj-$(CONFIG_DS4510) += ds4510.o
> >>> diff --git a/drivers/misc/altera_sysmgr.c
> >>> b/drivers/misc/altera_sysmgr.c new file mode 100644 index
> >>> 000..b36ecae
> >>> --- /dev/null
> >>> +++ b/drivers/misc/altera_sysmgr.c
> >>
> >> I think this file should have something in the name specifying it is for
> s10/agilex.
> >> I will post a misc/sysmgr for gen5 that needs a specific name, too
> > Gen5/A10/S10/Agilex are using same DW MMC/MAC drivers and these drivers
> access system manager.
> > Therefore, this driver is enabled for all platforms. Gen5/A10, S10/Agilex
> > all are
> using it.
> > Can I know what does your gen5 sysmgr driver do ?
> > I can change the name to avoid conflict but Gen5 will have 2 sysmgr drivers
> > for
> different purposes.
> > Are you OK with that ?
> >>
> >>> @@ -0,0 +1,115 @@
> >>> +// SPDX-License-Identifier: GPL-2.0+
> >>> +/*
> >>> + * Copyright (C) 2020 Intel Corporation */
> >>> +
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +#include
> >>> +
> >>> +#define IS_OUT_OF_SYSMGR(addr, range) ((addr) > (range))
> >>> +
> >>> +struct altera_sysmgr_priv {
> >>> + fdt_addr_t base_addr;
> >>> + fdt_addr_t base_size;
> >>> +};
> >>> +
> >>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) static
> >>> +int
> >>> +secure_write32(u32 val, fdt_addr_t addr) {
> >>> + int ret;
> >>> + u64 args[2];
> >>> +
> >>> + args[0] = (u64)addr;
> >>> + args[1] = val;
> >>> + ret = invoke_smc(INTEL_SIP_SMC_REG_WRITE, args, 2, NULL, 0);
> >>
> >> Hmm, so you're just using misc_ops to still issue generic writes.
> >> From the discussion with Marek in the last version, I would have
> >> thought you wanted to create a higher level API instead of still tunnelling
> reads and writes?
>
> Any response to this?
Sorry, I missed this one
Actually I have created higher level API in ATF but I switch back to generic
writes
because the higher level API in ATF doesn't apply to Gen5/A10 platforms.
Here is what I will do in my revision in system manager driver:
1) drop misc_read/misc_write and use misc_ioctl instead in system manager
2
RE: [PATCH v4 12/21] arch: arm: socfpga: Enable driver model for misc drivers.
> Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com: > > From: Chee Hong Ang > > > > Enable this misc driver model for 'altera_sysmgr' driver for socfpga > > platforms. > > > > Signed-off-by: Chee Hong Ang > > --- > > arch/arm/Kconfig | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig index > > 8d9f7fc..4ee8ae0 100644 > > --- a/arch/arm/Kconfig > > +++ b/arch/arm/Kconfig > > @@ -937,9 +937,11 @@ config ARCH_SOCFPGA > > select DM > > select DM_SERIAL > > select ENABLE_ARM_SOC_BOOT0_HOOK if TARGET_SOCFPGA_GEN5 || > > TARGET_SOCFPGA_ARRIA10 > > + select MISC > > Please don't 'select' this. You prevent building smaller configs that don't > need it. > Please use 'imply' instead. OK. > > > select OF_CONTROL > > select SPL_DM_RESET if DM_RESET > > select SPL_DM_SERIAL > > + select SPL_DRIVERS_MISC_SUPPORT > > Especially this one makes gen5 SPL uneccessary large. I will use 'imply' for this as well. > > Regards, > Simon > > > select SPL_LIBCOMMON_SUPPORT > > select SPL_LIBGENERIC_SUPPORT > > select SPL_NAND_SUPPORT if SPL_NAND_DENALI > >
RE: [PATCH v4 00/21] Enable ARM Trusted Firmware for U-Boot
> Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com: > > From: "Ang, Chee Hong" > > > > v4 changes: > > [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager > > - Add System Manager driver (UCLASS_MISC) to handle secure access for > > SoC64 > > > > [PATCH v4 13/21] mmc: dwmmc: socfpga: MMC driver access System > Manager via 'altera_sysmgr' > > - DW MMC driver access System Manager via the System Manager driver > > > > [PATCH v4 14/21] arch: arm: socfpga: Add 'altr,sysmgr-syscon' for MMC > > - DW MMC driver get DRVSEL & SMPLSEL clock settings from device tree > > > > [PATCH v4 15/21] net: designware: socfpga: MAC driver access System via > 'altera_sysmgr' > > - DW MAC driver access System Manager via the System Manager driver > > > > v3: > > https://lists.denx.de/pipermail/u-boot/2020-February/400986.html > > > > These patchsets have dependency on: > > https://lists.denx.de/pipermail/u-boot/2019-September/384906.html > > > > Chee Hong Ang (21): > > configs: agilex: Remove CONFIG_OF_EMBED > > 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: soc64: Remove PHY interface setup from misc arch init > > misc: altera_sysmgr: Add Altera System Manager driver > > arch: arm: socfpga: Enable driver model for misc drivers. > > mmc: dwmmc: socfpga: MMC driver access System Manager via > > 'altera_sysmgr' > > arch: arm: socfpga: Add 'altr,sysmgr-syscon' for MMC node in device > > tree > > net: designware: socfpga: MAC driver access System Manager via > > 'altera_sysmgr' > > arm: socfpga: Add ATF support for Reset Manager driver > > arm: socfpga: stratix10: Initialize timer in SPL > > arm: socfpga: Add ATF support to query FPGA configuration status > > arm: socfpga: stratix10: Add ATF support for FPGA reconfig driver > > arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to > > mbox_reset_cold() > > configs: socfpga: Add defconfig for Agilex and Stratix 10 without ATF > > support > > Are you sure building all previously existing defconfigs keeps working with > every > single commit here? If not, that would break 'git bisect' in the future... I will test this. > > I have the feeling that things might be broken in between - escpecially since > you're adding the 'old' "without ATF" defconfig in the last patch. > I think it would make more sense to keep the old defconfig name, keep it > building correctly throughout this series and add a "with ATF" defconfig at > the > end. That way, you ensure existing usages keep working. OK. > > Regards, > Simon > > > > > arch/arm/Kconfig | 2 + > > arch/arm/dts/socfpga_agilex_socdk-u-boot.dtsi | 1 + > > arch/arm/dts/socfpga_arria10_socdk_sdmmc.dts | 1 + > > arch/arm/dts/socfpga_arria5_socdk-u-boot.dtsi | 1 + > > arch/arm/dts/socfpga_cyclone5.dtsi | 1 + > > arch/arm/dts/socfpga_stratix10.dtsi| 1 - > > arch/arm/dts/socfpga_stratix10_socdk-u-boot.dtsi | 7 + > > arch/arm/dts/socfpga_stratix10_socdk.dts | 2 - > > arch/arm/mach-socfpga/Kconfig | 2 - > > arch/arm/mach-socfpga/Makefile | 2 + > > arch/arm/mach-socfpga/board.c | 10 + > > arch/arm/mach-socfpga/include/mach/misc.h | 3 + > > arch/arm/mach-socfpga/lowlevel_init_64.S | 81 + > > arch/arm/mach-socfpga/mailbox_s10.c| 4 + > > arch/arm/mach-socfpga/misc_s10.c | 121 ++- > > arch/arm/mach-socfpga/reset_manager_s10.c | 10 + > > arch/arm/mach-socfpga/timer_s10.c | 3 +- > > board/altera/soc64/its/fit_spl_atf.its | 52 +++ > > configs/socfpga_agilex_defconfig | 8 +- > > ...lex_defconfig => socfpga_agilex_nofw_defconfig} | 2 +- > > configs/socfpga_stratix10_defconfig| 7 +- > > ..._defconfig => socfpga_stratix10_nofw_defconfig}
RE: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager driver
> -Original Message-
> From: Simon Goldschmidt
> Sent: Wednesday, March 11, 2020 12:17 AM
> To: Ang, Chee Hong
> Cc: u-boot@lists.denx.de; Marek Vasut ; See, Chin Liang
> ; Tan, Ley Foon ;
> Westergreen, Dalon ; Gong, Richard
>
> Subject: Re: [PATCH v4 11/21] misc: altera_sysmgr: Add Altera System Manager
> driver
>
> Am 09.03.2020 um 10:07 schrieb chee.hong@intel.com:
> > From: Chee Hong Ang
> >
> > This driver (misc uclass) handle the read/write access to System
> > Manager. For 64 bits platforms, processor needs to be in secure mode
> > to has write access to most of the System Manager's registers (except
> > boot scratch registers). When the processor is running in EL2
> > (non-secure), this driver will invoke the SMC call to ATF to perform
> > write access to the System Manager's registers.
> > All other drivers that require access to System Manager should go
> > through this driver.
> >
> > Signed-off-by: Chee Hong Ang
> > ---
> > drivers/misc/Makefile| 1 +
> > drivers/misc/altera_sysmgr.c | 115
> > +++
> > 2 files changed, 116 insertions(+)
> > create mode 100644 drivers/misc/altera_sysmgr.c
> >
> > diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile index
> > 2b843de..9fa2411 100644
> > --- a/drivers/misc/Makefile
> > +++ b/drivers/misc/Makefile
> > @@ -29,6 +29,7 @@ endif
> > endif
> > obj-$(CONFIG_ALI152X) += ali512x.o
> > obj-$(CONFIG_ALTERA_SYSID) += altera_sysid.o
> > +obj-$(CONFIG_ARCH_SOCFPGA) += altera_sysmgr.o
> > obj-$(CONFIG_ATSHA204A) += atsha204a-i2c.o
> > obj-$(CONFIG_CBMEM_CONSOLE) += cbmem_console.o
> > obj-$(CONFIG_DS4510) += ds4510.o
> > diff --git a/drivers/misc/altera_sysmgr.c
> > b/drivers/misc/altera_sysmgr.c new file mode 100644 index
> > 000..b36ecae
> > --- /dev/null
> > +++ b/drivers/misc/altera_sysmgr.c
>
> I think this file should have something in the name specifying it is for
> s10/agilex.
> I will post a misc/sysmgr for gen5 that needs a specific name, too
Gen5/A10/S10/Agilex are using same DW MMC/MAC drivers and these drivers access
system manager.
Therefore, this driver is enabled for all platforms. Gen5/A10, S10/Agilex all
are using it.
Can I know what does your gen5 sysmgr driver do ?
I can change the name to avoid conflict but Gen5 will have 2 sysmgr drivers for
different purposes.
Are you OK with that ?
>
> > @@ -0,0 +1,115 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2020 Intel Corporation */
> > +
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +#include
> > +
> > +#define IS_OUT_OF_SYSMGR(addr, range) ((addr) > (range))
> > +
> > +struct altera_sysmgr_priv {
> > + fdt_addr_t base_addr;
> > + fdt_addr_t base_size;
> > +};
> > +
> > +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) static int
> > +secure_write32(u32 val, fdt_addr_t addr) {
> > + int ret;
> > + u64 args[2];
> > +
> > + args[0] = (u64)addr;
> > + args[1] = val;
> > + ret = invoke_smc(INTEL_SIP_SMC_REG_WRITE, args, 2, NULL, 0);
>
> Hmm, so you're just using misc_ops to still issue generic writes. From the
> discussion with Marek in the last version, I would have thought you wanted to
> create a higher level API instead of still tunnelling reads and writes?
>
> In my gen5 series to abstract the gen5 sysmgr, I have used 'ioctl' and 'call'
> from
> misc_ops to have an API.
>
> Regards,
> Simon
>
> > + if (ret)
> > + return -EIO;
> > +
> > + return 0;
> > +}
> > +#endif
> > +
> > +static int write32(u32 val, fdt_addr_t addr) { #if
> > +!defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
> > + return secure_write32(val, addr);
> > +#else
> > + writel(val, addr);
> > +
> > + return 0;
> > +#endif
> > +}
> > +
> > +static int altera_sysmgr_read(struct udevice *dev,
> > +int offset, void *buf, int size) {
> > + struct altera_sysmgr_priv *priv = dev_get_priv(dev);
> > + fdt_addr_t addr = priv->base_addr + offset;
> > +
> > + if (IS_OUT_OF_SYSMGR(addr, priv->base_addr + priv->base_size - size))
> > + return -EINVAL;
> > +
> > + if (size != sizeof(u32))
> > + return -EIO;
> > +
> > + *(u32 *)buf = readl(addr);
> > +
> > + return 0;
>
RE: [PATCH v1 1/2] clk: socfpga: Read the clock parent's register base in probe function
> On 3/9/20 9:21 AM, chee.hong@intel.com wrote:
> > From: Chee Hong Ang
> >
> > This commit (82de42fa14682d408da935adfb0f935354c5008f) calls child's
> > ofdata_to_platdata() method before the parent is probed in dm core.
> > This has caused the driver no longer able to get the correct parent
> > clock's register base in the ofdata_to_platdata() method because the
> > parent clocks will only be probed after the child's ofdata_to_platdata().
> > To resolve this, the clock parent's register base will only be
> > retrieved by the child in probe() method instead of ofdata_to_platdata().
>
> You should be able to bind the drivers and resolve their register offsets
> without
> probing them, so this look more like a bug in the driver core ?
The problem is the children clock driver need to resolve/derive their register
base
from their clock parents. With this new change, clock parents are still not yet
being initialized when the children clock drivers need to resolve their
register base
from their parent.
A10 is not booting in mainline due to this issue.
I can't think of a better way to fix this. Should we fix the clock driver
itself or the
DM core ?
>
> > Signed-off-by: Chee Hong Ang
> > ---
> > drivers/clk/altera/clk-arria10.c | 40
> > ++--
> > 1 file changed, 18 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/clk/altera/clk-arria10.c
> > b/drivers/clk/altera/clk-arria10.c
> > index affeb31..b7eed94 100644
> > --- a/drivers/clk/altera/clk-arria10.c
> > +++ b/drivers/clk/altera/clk-arria10.c
> > @@ -274,6 +274,8 @@ static int socfpga_a10_clk_bind(struct udevice
> > *dev) static int socfpga_a10_clk_probe(struct udevice *dev) {
> > struct socfpga_a10_clk_platdata *plat = dev_get_platdata(dev);
> > + struct socfpga_a10_clk_platdata *pplat;
> > + struct udevice *pdev;
> > const void *fdt = gd->fdt_blob;
> > int offset = dev_of_offset(dev);
> >
> > @@ -281,6 +283,21 @@ static int socfpga_a10_clk_probe(struct udevice
> > *dev)
> >
> > socfpga_a10_handoff_workaround(dev);
> >
> > + if (!fdt_node_check_compatible(fdt, offset, "altr,clk-mgr")) {
> > + plat->regs = devfdt_get_addr(dev);
> > + } else {
> > + pdev = dev_get_parent(dev);
> > + if (!pdev)
> > + return -ENODEV;
> > +
> > + pplat = dev_get_platdata(pdev);
> > + if (!pplat)
> > + return -EINVAL;
> > +
> > + plat->ctl_reg = dev_read_u32_default(dev, "reg", 0x0);
> > + plat->regs = pplat->regs;
> > + }
> > +
> > if (!fdt_node_check_compatible(fdt, offset,
> >"altr,socfpga-a10-pll-clock")) {
> > /* Main PLL has 3 upstream clock */ @@ -304,29 +321,8 @@
> static int
> > socfpga_a10_clk_probe(struct udevice *dev) static int
> > socfpga_a10_ofdata_to_platdata(struct udevice *dev) {
> > struct socfpga_a10_clk_platdata *plat = dev_get_platdata(dev);
> > - struct socfpga_a10_clk_platdata *pplat;
> > - struct udevice *pdev;
> > - const void *fdt = gd->fdt_blob;
> > unsigned int divreg[3], gatereg[2];
> > - int ret, offset = dev_of_offset(dev);
> > - u32 regs;
> > -
> > - regs = dev_read_u32_default(dev, "reg", 0x0);
> > -
> > - if (!fdt_node_check_compatible(fdt, offset, "altr,clk-mgr")) {
> > - plat->regs = devfdt_get_addr(dev);
> > - } else {
> > - pdev = dev_get_parent(dev);
> > - if (!pdev)
> > - return -ENODEV;
> > -
> > - pplat = dev_get_platdata(pdev);
> > - if (!pplat)
> > - return -EINVAL;
> > -
> > - plat->ctl_reg = regs;
> > - plat->regs = pplat->regs;
> > - }
> > + int ret;
> >
> > plat->type = SOCFPGA_A10_CLK_UNKNOWN_CLK;
> >
> >
>
>
> --
> Best regards,
> Marek Vasut
RE: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
Ang, Chee Hong mailto:chee.hong@intel.com>> schrieb am Fr., 28. Feb. 2020, 03:53: > > On 2/24/20 3:21 AM, Ang, Chee Hong wrote: > > [...] > > > > >>>>> Currently, we have like 20+ secure registers allowed access by > > >>>>> drivers running in non-secure mode (U-Boot proper / Linux). > > >>>>> I don't think we want to define and maintain those high level > > >>>>> interfaces for each of those secure register accesses in ATF and > > >>>>> U-Boot. > > >>>> > > >>>> See above. > > >>> OK. Then these secure access register should be set up in SPL (EL3). > > >>> U-Boot drivers shouldn't access them at all because the driver may > > >>> be running in SPL(EL3) and in U-Boot proper (EL2) too. > > >>> I can take a look at those drivers accessing secure registers and > > >>> try to move/decouple those secure access from U-Boot drivers to > > >>> SPL > > >>> (EL3) then we no longer need those secure register access functions. > > >> > > >> I think that would be great, no ? > > > Since the SDMMC/DWMAC drivers read the device tree to configure the > > > behaviour of the hardware via the secure registers. I think it > > > should still be part of the driver instead of configuring the > > > hardware in different places. I have proposed using ATF's high-level > > > APIs to achieve this > > when the driver is running in EL2. > > > I have already proposed this in other email threads. > > > Are you OK with this approach ? > > > > I think something more high level might be a good idea here. > What do you mean by 'more high level' ? > We handle this in SPL (EL3) ? > > Since you are the author of this 'drivers/net/dwmac_socfpga.c': > https://gitlab.denx.de/u-boot/u- > boot/blob/master/drivers/net/dwmac_socfpga.c#L101 > https://gitlab.denx.de/u-boot/u- > boot/blob/master/arch/arm/dts/socfpga_stratix10.dtsi#L98 > > Your driver selects the PHY interface (RGMII/RMII and etc) using the following > register (part of System Manager): > https://www.intel.com/content/www/us/en/programmable/hps/stratix- > 10/hps.html#topic/jng1505406892594.html > > I personally think this PHY interface select for EMACx shouldn't be part of > System Manager. > I don't see the security benefits here by making this PHY interface select as > 'secure zone' register. > > Same applies to DW MMC driver as well: > https://gitlab.denx.de/u-boot/u- > boot/blob/master/drivers/mmc/socfpga_dw_mmc.c#L60 > > It sets the following register in System Manager (secure zone) to configure > the > SDMMC clocks: > https://www.intel.com/content/www/us/en/programmable/hps/stratix- > 10/hps.html#topic/gil1505406886282.html > > Don't you think these things should be part of driver itself as what we are > doing > now instead of removing these from drivers and place them in SPL (EL3)? These 2 drivers that access the system manager: drivers/mmc/socfpga_dw_mmc.c - MMC driver access System Manager's 'SDMMC' register to set clock phase https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/topic/gil1505406886282.html drivers/net/dwmac_socfpga.c - MAC driver access System Manager's 'EMACx' registers to set MAC's PHY interface: https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/hps.html#topic/jng1505406892594.html Gen5/Arria10/Stratix10 & Agilex all using these drivers. They do not cause any issue in Gen5/Arria10 because there is no 'secure zone' in System Manager. For Stratix10 & Agilex, it has issue with U-Boot proper running in EL2. I don't think is good idea to separate those System Manager access from these 2 drivers and move them to SPL as they are shared by all SOCFPGA platforms. I think the proper way to resolve this is we add a new System Manager driver under 'drivers/misc'. The device type should be 'UCLASS_MISC'. >I have a pending patchset that adds such a sysmgr driver at least for gen5. I >haven't published it yet because the whole >series as one makes gen5 SRAM >overlow, but maybe that part can be split out... > >Regards, >Simon Thanks. I am working on the changes. I will need to test that out to make sure the new sysmgr driver works on all socfpga platforms. Will let you guys review whether this is a better/cleaner solution to handle the system manager access. Then we make changes to those drivers (SDMMC/MAC) to access the System Manager through the System Manager driver by using 'misc_read(dev...)' & 'misc_write(dev...)' The System Manager driver should decide whether to access those 'secure zone' registers directly
RE: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
> > On 2/24/20 3:21 AM, Ang, Chee Hong wrote: > > [...] > > > > >>>>> Currently, we have like 20+ secure registers allowed access by > > >>>>> drivers running in non-secure mode (U-Boot proper / Linux). > > >>>>> I don't think we want to define and maintain those high level > > >>>>> interfaces for each of those secure register accesses in ATF and > > >>>>> U-Boot. > > >>>> > > >>>> See above. > > >>> OK. Then these secure access register should be set up in SPL (EL3). > > >>> U-Boot drivers shouldn't access them at all because the driver may > > >>> be running in SPL(EL3) and in U-Boot proper (EL2) too. > > >>> I can take a look at those drivers accessing secure registers and > > >>> try to move/decouple those secure access from U-Boot drivers to > > >>> SPL > > >>> (EL3) then we no longer need those secure register access functions. > > >> > > >> I think that would be great, no ? > > > Since the SDMMC/DWMAC drivers read the device tree to configure the > > > behaviour of the hardware via the secure registers. I think it > > > should still be part of the driver instead of configuring the > > > hardware in different places. I have proposed using ATF's high-level > > > APIs to achieve this > > when the driver is running in EL2. > > > I have already proposed this in other email threads. > > > Are you OK with this approach ? > > > > I think something more high level might be a good idea here. > What do you mean by 'more high level' ? > We handle this in SPL (EL3) ? > > Since you are the author of this 'drivers/net/dwmac_socfpga.c': > https://gitlab.denx.de/u-boot/u- > boot/blob/master/drivers/net/dwmac_socfpga.c#L101 > https://gitlab.denx.de/u-boot/u- > boot/blob/master/arch/arm/dts/socfpga_stratix10.dtsi#L98 > > Your driver selects the PHY interface (RGMII/RMII and etc) using the following > register (part of System Manager): > https://www.intel.com/content/www/us/en/programmable/hps/stratix- > 10/hps.html#topic/jng1505406892594.html > > I personally think this PHY interface select for EMACx shouldn't be part of > System Manager. > I don't see the security benefits here by making this PHY interface select as > 'secure zone' register. > > Same applies to DW MMC driver as well: > https://gitlab.denx.de/u-boot/u- > boot/blob/master/drivers/mmc/socfpga_dw_mmc.c#L60 > > It sets the following register in System Manager (secure zone) to configure > the > SDMMC clocks: > https://www.intel.com/content/www/us/en/programmable/hps/stratix- > 10/hps.html#topic/gil1505406886282.html > > Don't you think these things should be part of driver itself as what we are > doing > now instead of removing these from drivers and place them in SPL (EL3)? These 2 drivers that access the system manager: drivers/mmc/socfpga_dw_mmc.c - MMC driver access System Manager's 'SDMMC' register to set clock phase https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/topic/gil1505406886282.html drivers/net/dwmac_socfpga.c - MAC driver access System Manager's 'EMACx' registers to set MAC's PHY interface: https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/hps.html#topic/jng1505406892594.html Gen5/Arria10/Stratix10 & Agilex all using these drivers. They do not cause any issue in Gen5/Arria10 because there is no 'secure zone' in System Manager. For Stratix10 & Agilex, it has issue with U-Boot proper running in EL2. I don't think is good idea to separate those System Manager access from these 2 drivers and move them to SPL as they are shared by all SOCFPGA platforms. I think the proper way to resolve this is we add a new System Manager driver under 'drivers/misc'. The device type should be 'UCLASS_MISC'. Then we make changes to those drivers (SDMMC/MAC) to access the System Manager through the System Manager driver by using 'misc_read(dev...)' & 'misc_write(dev...)' The System Manager driver should decide whether to access those 'secure zone' registers directly in EL3 or making SMC call to ATF to access the System Manager if it's running in EL2. Linux has similar MAC driver running in EL1 (non-secure) accessing System Manager: https://elixir.bootlin.com/linux/v5.5/source/drivers/net/ethernet/stmicro/stmmac/dwmac-socfpga.c#L302 Linux MAC driver access System Manager via this 'altr,system_manager' driver: https://elixir.bootlin.com/linux/v5.5/source/drivers/mfd/altera-sysmgr.c#L44 System Manager driver will make SMC/PSCI call to ATF to access the System Manager's registers.
RE: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
> On 2/24/20 3:21 AM, Ang, Chee Hong wrote: > [...] > > >>>>> Currently, we have like 20+ secure registers allowed access by > >>>>> drivers running in non-secure mode (U-Boot proper / Linux). > >>>>> I don't think we want to define and maintain those high level > >>>>> interfaces for each of those secure register accesses in ATF and U-Boot. > >>>> > >>>> See above. > >>> OK. Then these secure access register should be set up in SPL (EL3). > >>> U-Boot drivers shouldn't access them at all because the driver may > >>> be running in SPL(EL3) and in U-Boot proper (EL2) too. > >>> I can take a look at those drivers accessing secure registers and > >>> try to move/decouple those secure access from U-Boot drivers to SPL > >>> (EL3) then we no longer need those secure register access functions. > >> > >> I think that would be great, no ? > > Since the SDMMC/DWMAC drivers read the device tree to configure the > > behaviour of the hardware via the secure registers. I think it should > > still be part of the driver instead of configuring the hardware in > > different places. I have proposed using ATF's high-level APIs to achieve > > this > when the driver is running in EL2. > > I have already proposed this in other email threads. > > Are you OK with this approach ? > > I think something more high level might be a good idea here. What do you mean by 'more high level' ? We handle this in SPL (EL3) ? Since you are the author of this 'drivers/net/dwmac_socfpga.c': https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/net/dwmac_socfpga.c#L101 https://gitlab.denx.de/u-boot/u-boot/blob/master/arch/arm/dts/socfpga_stratix10.dtsi#L98 Your driver selects the PHY interface (RGMII/RMII and etc) using the following register (part of System Manager): https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/hps.html#topic/jng1505406892594.html I personally think this PHY interface select for EMACx shouldn't be part of System Manager. I don't see the security benefits here by making this PHY interface select as 'secure zone' register. Same applies to DW MMC driver as well: https://gitlab.denx.de/u-boot/u-boot/blob/master/drivers/mmc/socfpga_dw_mmc.c#L60 It sets the following register in System Manager (secure zone) to configure the SDMMC clocks: https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/hps.html#topic/gil1505406886282.html Don't you think these things should be part of driver itself as what we are doing now instead of removing these from drivers and place them in SPL (EL3)?
RE: [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC 64bits)
Ang, Chee Hong mailto:chee.hong@intel.com>>
schrieb am Sa., 22. Feb. 2020, 06:30:
> From: Chee Hong Ang mailto:chee.hong@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
> mailto:chee.hong@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 4ee2b7b..e5a0998 100644
> --- a/arch/arm/mach-socfpga/clock_manager_agilex.c
> +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -65,8 +66,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
> #include
> #include
> +#include
>
> 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
>SPL reads the clock info from handoff table (OCRAM) and write
>the clock info into the System Manager's boot scratch register.
>U-Boot proper will read from the System Manager's boot scratch
>register to get the clock info in case the handoff table (OCRAM)
>is no longer available.
>After some investigations, the handoff table in OCRAM should be preserved
>for warm boot. In other words, this handoff table should be left untouched.
>SPL and U-Boot should directly read the clock info from handoff table in OCRAM.
>Therefore, U-Boot proper no longer need to read the clock info from
>System Manager's boot scratch register (secure zone) from non-secure world
>(EL2).
>I don't think that's a good idea: for security reasons, SPL memory should not
>be accessible from EL2 if it is required/used for the next reboot.
>
>Regards,
>Simon
Right. I think I will have to go for proper high-level API in ATF for EL2 to
query the clock frequency:
INTEL_SIP_SMC_CLK_GET_QSPI
I found out System Manager is read only in EL2 and read/write in EL3.
Will drop this patch.
No change required since it only read back from System Manager’s registers.
>So reading these registers is allowed in EL2? I would have expected all access
>is blocked? Is this specified somewhere, or will it be?
>
>Regards,
>Simon
Yes. I know this is confusing.
I would have expected the read access be blocked as well. Unfortunately, this
is not the case.
Let me clarify further:
Here is a list of Stratix10 System Manager’s register map:
https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/hps.html#topic/dwh1505406933720.html
Any R/W registers between ‘siliconid1’ to ‘mpu’ are READ-ONLY in EL2. But are
read/writable in EL3.
If you click into one of these R/W registers:
You will see a notice like this:
Access: RW
Access mode: PRIVILEGEMODE | SECURE
Note: The processor must make a secure, privileged bus access to this register.
It just said this register is read/writable in EL3 but it doesn’t specify it is
read-only in EL2.
I did some tests to read from these registers in EL2. It worked.
It crashed the U-Boot with ‘SError’ exception if I tried to write something
into one of these registers.
For registers after ‘mpu’ which are ‘boot_scratch_cold0’ – ‘boot_scratch_cold9’:
If you click into one of this boot scratch registers:
https://www.intel.com/content/www/us/en/programmable/hps/stratix-10/hps.html#topic/lom1505406925262.html
You don’t see any requirement about the processor need to be in secure mode to
access this register.
Previously I mentioned these registers are read-only in EL2.
They are actually read/writable in EL2 and EL3. Sorry for the misinformation
The clock manager drivers are writing/reading clock settings into these boot
scratch registers
so changes are not necessary for EL2.
In summary, although ‘boot_scratch_cold0’ – ‘boot_scratch_cold9’ registers are
part of
System Manager, but they are not marked as ‘secure zone’.
I missed this when working on this ATF flow :(
RE: [PATCH v2 13/21] arm: socfpga: Secure register access for reading PLL frequency
> > > On 2/22/20 11:05 AM, Ang, Chee Hong wrote:
> > > >>> From: Chee Hong Ang
> > > >>>
> > > >>> 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
> > > >>> ---
> > > >>> 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
> > > >>> #include #include
> > > >>>
> > > >>> +#include
> > > >>>
> > > >>> 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
> > > >> This clock info could be directly read from the handoff table
> > > >> (OCRAM) instead of the System Manager's boot scratch register
> > > >> (secure
> > zone).
> > > >> Please refer to my full explanation in my previous email reply:
> > > >> [PATCH v2 11/21] arm: socfpga: Secure register access for clock
> > > >> manager (SoC
> > > >> 64bits)
> > > > Simon raised a good security concern on this approach. I will drop
> > > > this
> > > approach.
> > > > Will go for high-level APIs in ATF for clock queries:
> > > > INTEL_SIP_SMC_CLK_GET_OSC
> > > > INTEL_SIP_SMC_CLK_GET_FPGA
> > >
> > > Can't you have a clock driver read out the clock tree once and then
> > > have all the drivers in U-Boot just get clock settings from the clock
> > > driver?
> In 'wrap_pll_config_s10.c':
> cm_get_osc_clk_hz()
> cm_get_intosc_clk_hz()
> cm_get_fpga_clk_hz()
>
> All the clock settings returned by S10/Agilex clock manager drivers derived
> from
> these 3 clock sources (listed above) then all other U-Boot drivers get the
> clock
> settings from the clock driver.
>
> Can you help clarify what do you mean by "read out the clock tree once" ?
>
> Anyway, there will be only one high-level API for reading the OSC/FPGA/QSPI
> clock sources depending on which clock source chosen by caller.
>
> Please ignore my reply below.
> > Yes. This could be part of the clock driver (clock_manager_s10 /
> > agilex.c) instead of scattering around in different places.
Please ignore all my replies above. Will drop this patch.
System Manager is read only in EL2 and read/write in EL3.
No change required since it only read back from System Manager’s registers.
RE: [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC 64bits)
From: Ang, Chee Hong
Sent: Saturday, February 22, 2020 6:00 PM
To: Simon Goldschmidt
Cc: U-Boot Mailing List ; Marek Vasut ;
See, Chin Liang ; Tan, Ley Foon
; Westergreen, Dalon ;
Gong, Richard
Subject: RE: [PATCH v2 11/21] arm: socfpga: Secure register access for clock
manager (SoC 64bits)
Ang, Chee Hong mailto:chee.hong@intel.com>>
schrieb am Sa., 22. Feb. 2020, 06:30:
> From: Chee Hong Ang mailto:chee.hong@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
> mailto:chee.hong@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 4ee2b7b..e5a0998 100644
> --- a/arch/arm/mach-socfpga/clock_manager_agilex.c
> +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -65,8 +66,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
> #include
> #include
> +#include
>
> 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
>SPL reads the clock info from handoff table (OCRAM) and write
>the clock info into the System Manager's boot scratch register.
>U-Boot proper will read from the System Manager's boot scratch
>register to get the clock info in case the handoff table (OCRAM)
>is no longer available.
>After some investigations, the handoff table in OCRAM should be preserved
>for warm boot. In other words, this handoff table should be left untouched.
>SPL and U-Boot should directly read the clock info from handoff table in OCRAM.
>Therefore, U-Boot proper no longer need to read the clock info from
>System Manager's boot scratch register (secure zone) from non-secure world
>(EL2).
>I don't think that's a good idea: for security reasons, SPL memory should not
>be accessible from EL2 if it is required/used for the next reboot.
>
>Regards,
>Simon
Right. I think I will have to go for proper high-level API in ATF for EL2 to
query the clock frequency:
INTEL_SIP_SMC_CLK_GET_QSPI
I found out System Manager is read only in EL2 and read/write in EL3.
Will drop this patch.
No change required since it only read back from System Manager’s registers.
RE: [PATCH v2 13/21] arm: socfpga: Secure register access for reading PLL frequency
> > On 2/22/20 11:05 AM, Ang, Chee Hong wrote:
> > >>> From: Chee Hong Ang
> > >>>
> > >>> 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
> > >>> ---
> > >>> 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
> > >>> #include #include
> > >>>
> > >>> +#include
> > >>>
> > >>> 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
> > >> This clock info could be directly read from the handoff table
> > >> (OCRAM) instead of the System Manager's boot scratch register (secure
> zone).
> > >> Please refer to my full explanation in my previous email reply:
> > >> [PATCH v2 11/21] arm: socfpga: Secure register access for clock
> > >> manager (SoC
> > >> 64bits)
> > > Simon raised a good security concern on this approach. I will drop
> > > this
> > approach.
> > > Will go for high-level APIs in ATF for clock queries:
> > > INTEL_SIP_SMC_CLK_GET_OSC
> > > INTEL_SIP_SMC_CLK_GET_FPGA
> >
> > Can't you have a clock driver read out the clock tree once and then
> > have all the drivers in U-Boot just get clock settings from the clock
> > driver?
In 'wrap_pll_config_s10.c':
cm_get_osc_clk_hz()
cm_get_intosc_clk_hz()
cm_get_fpga_clk_hz()
All the clock settings returned by S10/Agilex clock manager drivers derived
from these 3 clock sources (listed above) then all other U-Boot drivers get the
clock
settings from the clock driver.
Can you help clarify what do you mean by "read out the clock tree once" ?
Anyway, there will be only one high-level API for reading the OSC/FPGA/QSPI
clock
sources depending on which clock source chosen by caller.
Please ignore my reply below.
> Yes. This could be part of the clock driver (clock_manager_s10 / agilex.c)
> instead
> of scattering around in different places.
RE: [PATCH v2 01/21] configs: agilex: Remove CONFIG_OF_EMBED
> On 2/21/20 7:15 PM, Ang, Chee Hong wrote: > >> On 2/20/20 6:04 PM, Westergreen, Dalon wrote: > >> > >> Please fix your mailer, it makes your reply completely unreadable. > >> > >>> On Thu, 2020-02-20 at 17:44 +0100, Marek Vasut wrote: > >>> > >>> On 2/20/20 3:12 AM, Ang, Chee Hong wrote: > >>> > >>> On 2/19/20 1:25 PM, > >>> > >>> <mailto:chee.hong@intel.com> > >>> > >>> chee.hong@intel.com > >>> > >>> wrote: > >>> > >>> From: Chee Hong Ang < > >>> > >>> <mailto:chee.hong@intel.com> > >>> > >>> chee.hong@intel.com > >>> > >>>> > >>> > >>> > >>> CONFIG_OF_EMBED was primarily enabled to support the agilex 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. > >> > >> OK, so this patch removes functionality. > >> Can that functionality be retained ? Or what can be done here? > > The functionality is no longer required. > > Because you always depend on ATF now ? No. We have 2 different defconfigs in the patchset, one use ATF one without ATF. Both no longer using CONFIG_OF_EMBED and they worked fine.
RE: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
> On 2/21/20 8:06 PM, Ang, Chee Hong wrote: > >> On 2/21/20 7:01 PM, Ang, Chee Hong wrote: > >>>> On 2/20/20 6:54 PM, Ang, Chee Hong wrote: > >>>>>> On 2/20/20 3:02 AM, Ang, Chee Hong wrote: > >>>>>> [...] > >>>>>>>>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) > >>>>>>>>> +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_update32clrsetbits_le32 > >>>>>>>>> +#endif > >>>>>>>> > >>>>>>>> I think I don't understand how this is supposed to work. Would > >>>>>>>> every place in U- Boot have to be patched to call these functions > >>>>>>>> now ? > >>>>>>> > >>>>>>> Not every register access need this. Only those accessing > >>>>>>> registers in secure zone such as 'System Manager' registers need > >>>>>>> to call > >> this. > >>>>>>> It's basically determine whether the driver should issue > >>>>>>> SMC/PSCI call if it's running in EL2 (non-secure) or access the > >>>>>>> registers directly by simply using > >>>>>> readl/writel and etc if it's running in EL3 (secure). > >>>>>>> Accessing those registers in secure zone in non-secure mode > >>>>>>> (EL2) will cause > >>>>>> SError exception. > >>>>>>> So we can determine this behaviour in compile time: > >>>>>>> SPL always running in EL3. So it just simply fallback to use > >>>>>> readl/writel/clrsetbits_le32. > >>>>>>> > >>>>>>> For U-Boot proper (SSBL), there are 2 scenarios: > >>>>>>> 1) If CONFIG_SPL_ATF is defined, it means ATF is supported. It > >>>>>>> implies that U-Boot proper will be running in EL2 (non-secure), > >>>>>>> then it will use > >>>>>> SMC/PSCI calls to access the secure registers. > >>>>>>> > >>>>>>> 2) CONFIG_SPL_ATF is not defined, no ATF support. U-Boot proper > >>>>>>> will be running in EL3 which will fall back to simply using the > >>>>>>> direct access functions > >>>>>> (readl/writel and etc). > >>>>>> > >>>>>> I would expect the standard IO accessors would or should handle this > stuff ? > >>>>> Standard IO accessors are just general memory read/write functions > >>>>> designed to be compatible with general hardware platforms. Not all > >>>>> platforms have secure/non-secure hardware zones. I don't think > >>>>> they should > >>>> handle this. > >>>>> > >>>>> If it's running in EL3 (secure mode) the standard I/O accessors > >>>>> will work just fine because > >>>>> EL3 can access to all secure/non-secure zones. In the header file, > >>>>> you can see the secure I/O accessors will be replaced by the > >>>>> standard I/O accessors if it's built for SPL and U-Boot proper > >>>>> without ATF. Because both are > >>>> running in EL3 (secure). > >>>>> > >>>>> If ATF is enabled, SPL will be still running in EL3 but U-Boot > >>>>> proper will be running in > >>>>> EL2 (non-secure). If any code accessing those secure zones without > >>>>> going through ATF (making SMC/PSCI calls to EL3), it will trigger > >>>>> 'SError' > >>>> exceptions and crash the U-Boot. > >>>> > >>>> Hmmm, if U-Boot is running in EL2 (non-secure), why would it ever > >>>> access secure zones in the first place ? > >>> SPL and U-Boot reuse the same drivers code. It runs without issue in > >>> SPL (EL3) but it crashes if runni
RE: [PATCH v2 13/21] arm: socfpga: Secure register access for reading PLL frequency
> On 2/22/20 11:05 AM, Ang, Chee Hong wrote:
> >>> From: Chee Hong Ang
> >>>
> >>> 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
> >>> ---
> >>> 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
> >>> #include
> >>> #include
> >>> +#include
> >>>
> >>> 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
> >> This clock info could be directly read from the handoff table (OCRAM)
> >> instead of the System Manager's boot scratch register (secure zone).
> >> Please refer to my full explanation in my previous email reply:
> >> [PATCH v2 11/21] arm: socfpga: Secure register access for clock
> >> manager (SoC
> >> 64bits)
> > Simon raised a good security concern on this approach. I will drop this
> approach.
> > Will go for high-level APIs in ATF for clock queries:
> > INTEL_SIP_SMC_CLK_GET_OSC
> > INTEL_SIP_SMC_CLK_GET_FPGA
>
> Can't you have a clock driver read out the clock tree once and then have all
> the
> drivers in U-Boot just get clock settings from the clock driver?
Yes. This could be part of the clock driver (clock_manager_s10 / agilex.c)
instead of scattering
around in different places.
RE: [PATCH v2 13/21] arm: socfpga: Secure register access for reading PLL frequency
> > From: Chee Hong Ang
> >
> > 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
> > ---
> > 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
> > #include
> > #include
> > +#include
> >
> > 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
> This clock info could be directly read from the handoff table (OCRAM) instead
> of
> the System Manager's boot scratch register (secure zone).
> Please refer to my full explanation in my previous email reply:
> [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC
> 64bits)
Simon raised a good security concern on this approach. I will drop this
approach.
Will go for high-level APIs in ATF for clock queries:
INTEL_SIP_SMC_CLK_GET_OSC
INTEL_SIP_SMC_CLK_GET_FPGA
RE: [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC 64bits)
Ang, Chee Hong mailto:chee.hong@intel.com>>
schrieb am Sa., 22. Feb. 2020, 06:30:
> From: Chee Hong Ang mailto:chee.hong@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
> mailto:chee.hong@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 4ee2b7b..e5a0998 100644
> --- a/arch/arm/mach-socfpga/clock_manager_agilex.c
> +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -65,8 +66,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
> #include
> #include
> +#include
>
> 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
>SPL reads the clock info from handoff table (OCRAM) and write
>the clock info into the System Manager's boot scratch register.
>U-Boot proper will read from the System Manager's boot scratch
>register to get the clock info in case the handoff table (OCRAM)
>is no longer available.
>After some investigations, the handoff table in OCRAM should be preserved
>for warm boot. In other words, this handoff table should be left untouched.
>SPL and U-Boot should directly read the clock info from handoff table in OCRAM.
>Therefore, U-Boot proper no longer need to read the clock info from
>System Manager's boot scratch register (secure zone) from non-secure world
>(EL2).
>I don't think that's a good idea: for security reasons, SPL memory should not
>be accessible from EL2 if it is required/used for the next reboot.
>
>Regards,
>Simon
Right. I think I will have to go for proper high-level API in ATF for EL2 to
query the clock frequency:
INTEL_SIP_SMC_CLK_GET_QSPI
RE: [PATCH v2 16/21] arm: socfpga: Secure register access in Reset Manager driver
> From: Chee Hong Ang
>
> 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
> ---
> 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
> #include
> #include
> +#include
> #include
> #include
>
> @@ -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
ATF already has similar function to enable/disable the socfpga bridge.
This function is needed in U-Boot proper (non-secure, EL2) for enabling
the bridge for soft IP access after FPGA is configured.
Will add a high-level API in ATF for non-secure world.
The API info will be documented in 'include/linux/intel-smc.h'
RE: [PATCH v2 15/21] net: designware: socfpga: Secure register access in MAC driver
> From: Chee Hong Ang
>
> Allow MAC driver to access System Manager's EMAC control registers in non-
> secure mode.
>
> Signed-off-by: Chee Hong Ang
> ---
> 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
> e93561d..293c660 100644
> --- a/drivers/net/dwmac_socfpga.c
> +++ b/drivers/net/dwmac_socfpga.c
> @@ -17,6 +17,7 @@
> #include
> #include
>
> +#include
> #include
>
> struct dwmac_socfpga_platdata {
> @@ -98,8 +99,8 @@ static int dwmac_socfpga_probe(struct udevice *dev)
> reset_assert_bulk(_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(_bulk);
>
> --
> 2.7.4
This MAC driver need to access System Manager's EMAC control register
(secure zone) to configure the PHY interface (GMII/RGMII/RMII).
This should be part of this MAC driver as well.
I will add/define a high-level API in ATF to be used by this MAC driver
from non-secure world (EL2).
This high-level API (SMC/PSCI calls) will be properly documented in
'include/linux/intel-smc.h'
RE: [PATCH v2 14/21] mmc: dwmmc: socfpga: Secure register access in MMC driver
> From: Chee Hong Ang
>
> Allow MMC driver to access System Manager's SDMMC control register in non-
> secure mode (EL2).
>
> Signed-off-by: Chee Hong Ang
> ---
> 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 786cdc7..558f246 100644
> --- a/drivers/mmc/socfpga_dw_mmc.c
> +++ b/drivers/mmc/socfpga_dw_mmc.c
> @@ -5,6 +5,7 @@
>
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -57,10 +58,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
This SDMMC driver need to access System Manager's SDMMC control register
(secure zone) to configure the clock's phase shift settings. I don't think this
could be separated from the driver. I will add/define a high-level API in ATF
to be used by this SDMMC driver from non-secure world (EL2).
This high-level API (SMC/PSCI calls) will be properly documented in
'include/linux/intel-smc.h'
RE: [PATCH v2 13/21] arm: socfpga: Secure register access for reading PLL frequency
> From: Chee Hong Ang
>
> 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
> ---
> 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
> #include
> #include
> +#include
>
> 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
This clock info could be directly read from the handoff table (OCRAM)
instead of the System Manager's boot scratch register (secure zone).
Please refer to my full explanation in my previous email reply:
[PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC
64bits)
RE: [PATCH v2 12/21] arm: socfpga: Secure register access in PHY mode setup
> From: Chee Hong Ang > > Allow access to System Manager's EMAC control register from non-secure mode > during PHY mode setup. > > Signed-off-by: Chee Hong Ang > --- > 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 25c3ff6..6593308 100644 > --- a/arch/arm/mach-socfpga/misc_s10.c > +++ b/arch/arm/mach-socfpga/misc_s10.c > @@ -18,6 +18,7 @@ > #include > #include > #include > +#include > > #include > > @@ -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 Looks like this PHY setup is redundant and no longer needed because it is already being taken care in 'drivers/net/dwmac_socfpga.c' which is written by Marek. Will check with Ley Foon whether this socfpga_phymode_setup() can be safely removed.
RE: [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC 64bits)
> From: Chee Hong Ang
>
> 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
> ---
> 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 4ee2b7b..e5a0998 100644
> --- a/arch/arm/mach-socfpga/clock_manager_agilex.c
> +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
> @@ -12,6 +12,7 @@
> #include
> #include
> #include
> +#include
>
> DECLARE_GLOBAL_DATA_PTR;
>
> @@ -65,8 +66,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
> #include
> #include
> +#include
>
> 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
SPL reads the clock info from handoff table (OCRAM) and write
the clock info into the System Manager's boot scratch register.
U-Boot proper will read from the System Manager's boot scratch
register to get the clock info in case the handoff table (OCRAM)
is no longer available.
After some investigations, the handoff table in OCRAM should be preserved
for warm boot. In other words, this handoff table should be left untouched.
SPL and U-Boot should directly read the clock info from handoff table in OCRAM.
Therefore, U-Boot proper no longer need to read the clock info from
System Manager's boot scratch register (secure zone) from non-secure world
(EL2).
RE: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
> On 2/21/20 7:01 PM, Ang, Chee Hong wrote: > >> On 2/20/20 6:54 PM, Ang, Chee Hong wrote: > >>>> On 2/20/20 3:02 AM, Ang, Chee Hong wrote: > >>>> [...] > >>>>>>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) > >>>>>>> +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_read32readl > >>>>>>> +#define socfpga_secure_reg_write32 writel > >>>>>>> +#define socfpga_secure_reg_update32 clrsetbits_le32 > >>>>>>> +#endif > >>>>>> > >>>>>> I think I don't understand how this is supposed to work. Would > >>>>>> every place in U- Boot have to be patched to call these functions now ? > >>>>> > >>>>> Not every register access need this. Only those accessing > >>>>> registers in secure zone such as 'System Manager' registers need to call > this. > >>>>> It's basically determine whether the driver should issue SMC/PSCI > >>>>> call if it's running in EL2 (non-secure) or access the registers > >>>>> directly by simply using > >>>> readl/writel and etc if it's running in EL3 (secure). > >>>>> Accessing those registers in secure zone in non-secure mode (EL2) > >>>>> will cause > >>>> SError exception. > >>>>> So we can determine this behaviour in compile time: > >>>>> SPL always running in EL3. So it just simply fallback to use > >>>> readl/writel/clrsetbits_le32. > >>>>> > >>>>> For U-Boot proper (SSBL), there are 2 scenarios: > >>>>> 1) If CONFIG_SPL_ATF is defined, it means ATF is supported. It > >>>>> implies that U-Boot proper will be running in EL2 (non-secure), > >>>>> then it will use > >>>> SMC/PSCI calls to access the secure registers. > >>>>> > >>>>> 2) CONFIG_SPL_ATF is not defined, no ATF support. U-Boot proper > >>>>> will be running in EL3 which will fall back to simply using the > >>>>> direct access functions > >>>> (readl/writel and etc). > >>>> > >>>> I would expect the standard IO accessors would or should handle this > >>>> stuff ? > >>> Standard IO accessors are just general memory read/write functions > >>> designed to be compatible with general hardware platforms. Not all > >>> platforms have secure/non-secure hardware zones. I don't think they > >>> should > >> handle this. > >>> > >>> If it's running in EL3 (secure mode) the standard I/O accessors will > >>> work just fine because > >>> EL3 can access to all secure/non-secure zones. In the header file, > >>> you can see the secure I/O accessors will be replaced by the > >>> standard I/O accessors if it's built for SPL and U-Boot proper > >>> without ATF. Because both are > >> running in EL3 (secure). > >>> > >>> If ATF is enabled, SPL will be still running in EL3 but U-Boot > >>> proper will be running in > >>> EL2 (non-secure). If any code accessing those secure zones without > >>> going through ATF (making SMC/PSCI calls to EL3), it will trigger 'SError' > >> exceptions and crash the U-Boot. > >> > >> Hmmm, if U-Boot is running in EL2 (non-secure), why would it ever > >> access secure zones in the first place ? > > SPL and U-Boot reuse the same drivers code. It runs without issue in > > SPL (EL3) but it crashes if running the same driver code in EL2 which access > some secure zone registers. > > The System Manager (secure zone) contains some register which control > > the behaviours of EMAC/SDMMC and etc. Clock manager driver rely on > > those registers in System Manager as well for retrieving clock > > information. These clock/EMAC/SDMMC drivers access the System Manager > (secure zone). > > Maybe those registers should only be configured by the secure OS, so maybe > those drivers should be fixed ? > > >> And if that's really necessary, should the ATF really provide > >> secure-mode register access primitives or sho
RE: [PATCH v2 05/21] arm: socfpga: Override 'lowlevel_init' to support ATF
> > On 2/20/20 8:05 PM, Ang, Chee Hong wrote: > > >> On 2/20/20 3:27 AM, Ang, Chee Hong wrote: > > >>>> On 2/19/20 1:25 PM, chee.hong@intel.com wrote: > > >>>> [...] > > >>>>> diff --git a/arch/arm/mach-socfpga/lowlevel_init.S > > >>>>> b/arch/arm/mach-socfpga/lowlevel_init.S > > >>>>> new file mode 100644 > > >>>>> index 000..68053a0 > > >>>>> --- /dev/null > > >>>>> +++ b/arch/arm/mach-socfpga/lowlevel_init.S > > >>>> > > >>>> This should be some lowlevel_init_64.S to make it clear it's only > > >>>> for > > >>>> arm64 platforms. > > >>> OK. It makes sense. Thanks. > > >>>> > > >>>>> @@ -0,0 +1,85 @@ > > >>>>> +/* SPDX-License-Identifier: GPL-2.0 */ > > >>>>> +/* > > >>>>> + * Copyright (C) 2019, Intel Corporation */ > > >>>>> + > > >>>>> +#include > > >>>>> +#include > > >>>>> +#include > > >>>>> +#include > > >>>>> + > > >>>>> +ENTRY(lowlevel_init) > > >>>>> + mov x29, lr /* Save LR */ > > >>>>> + > > >>>>> +#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) #ifdef > > >>>>> +CONFIG_SPL_ATF > > >>>>> + branch_if_slave x0, 2f > > >>>>> +#else > > >>>>> + branch_if_slave x0, 1f > > >>>>> +#endif > > >>>>> + > > >>>>> + ldr x0, =GICD_BASE > > >>>>> + bl gic_init_secure > > >>>>> +#ifdef CONFIG_SPL_BUILD > > >>>>> + b 2f > > >>>>> +#else > > >>>>> + b 3f > > >>>>> +#endif > > >>>> > > >>>> Can't this be done in C code ? Can we reduce the ifdeffery ? > > >>> This lowlevel_init function is shared by SPL and U-Boot and they > > >>> run in slightly different flow. > > >> > > >> What does this 'different flow' mean ? > > > This has something to with multi-cores CPU such as A53. > > > For SPL, we need to make sure the slave CPUs (CPU1/2/3) trapped in a > > > 'place' > > > Where they could be 'activated' by kernel for multi-processor environment. > > > It means the kernel get to 'activate' the slave CPUs from master CPU > > > (CPU0) U-Boot proper only run on master CPU (CPU0). The rest of > > > slave CPUs are trapped in the beginning of SPL waiting to be 'activated' > > > by kernel. > > > > OK, so the secondary CPUs are spinning until the kernel releases them. > > > > > In U-Boot proper, only master CPU gets to run this code and it will > > > just do the basic GIC setup and skip the 'trap'. The 'trap' is to > > > prevent the slave CPUs from running the same SPL, ATF and U-Boot > > > code as the master CPU in parallel. Only single core (maser CPU) is > > > needed for > > bootloaders and firmware. > > > > I would expect all the other SMP platforms solved this issue with > > secondary CPUs already, so why is agilex special ? > Nothing special. Just like other SMP platforms, I am just telling you the > master > CPU always skips the 'spinning trap' in SPL and U-Boot proper. ATF is now used to activate the secondary CPUs by Linux. This lowlevel_init is to make sure secondary CPUs trap in ATF instead of SPL after ATF is initialized.
RE: [PATCH v2 05/21] arm: socfpga: Override 'lowlevel_init' to support ATF
> On 2/20/20 8:05 PM, Ang, Chee Hong wrote: > >> On 2/20/20 3:27 AM, Ang, Chee Hong wrote: > >>>> On 2/19/20 1:25 PM, chee.hong@intel.com wrote: > >>>> [...] > >>>>> diff --git a/arch/arm/mach-socfpga/lowlevel_init.S > >>>>> b/arch/arm/mach-socfpga/lowlevel_init.S > >>>>> new file mode 100644 > >>>>> index 000..68053a0 > >>>>> --- /dev/null > >>>>> +++ b/arch/arm/mach-socfpga/lowlevel_init.S > >>>> > >>>> This should be some lowlevel_init_64.S to make it clear it's only > >>>> for > >>>> arm64 platforms. > >>> OK. It makes sense. Thanks. > >>>> > >>>>> @@ -0,0 +1,85 @@ > >>>>> +/* SPDX-License-Identifier: GPL-2.0 */ > >>>>> +/* > >>>>> + * Copyright (C) 2019, Intel Corporation */ > >>>>> + > >>>>> +#include > >>>>> +#include > >>>>> +#include > >>>>> +#include > >>>>> + > >>>>> +ENTRY(lowlevel_init) > >>>>> + mov x29, lr /* Save LR */ > >>>>> + > >>>>> +#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) #ifdef > >>>>> +CONFIG_SPL_ATF > >>>>> + branch_if_slave x0, 2f > >>>>> +#else > >>>>> + branch_if_slave x0, 1f > >>>>> +#endif > >>>>> + > >>>>> + ldr x0, =GICD_BASE > >>>>> + bl gic_init_secure > >>>>> +#ifdef CONFIG_SPL_BUILD > >>>>> + b 2f > >>>>> +#else > >>>>> + b 3f > >>>>> +#endif > >>>> > >>>> Can't this be done in C code ? Can we reduce the ifdeffery ? > >>> This lowlevel_init function is shared by SPL and U-Boot and they run > >>> in slightly different flow. > >> > >> What does this 'different flow' mean ? > > This has something to with multi-cores CPU such as A53. > > For SPL, we need to make sure the slave CPUs (CPU1/2/3) trapped in a 'place' > > Where they could be 'activated' by kernel for multi-processor environment. > > It means the kernel get to 'activate' the slave CPUs from master CPU > > (CPU0) U-Boot proper only run on master CPU (CPU0). The rest of slave > > CPUs are trapped in the beginning of SPL waiting to be 'activated' > > by kernel. > > OK, so the secondary CPUs are spinning until the kernel releases them. > > > In U-Boot proper, only master CPU gets to run this code and it will > > just do the basic GIC setup and skip the 'trap'. The 'trap' is to > > prevent the slave CPUs from running the same SPL, ATF and U-Boot code > > as the master CPU in parallel. Only single core (maser CPU) is needed for > bootloaders and firmware. > > I would expect all the other SMP platforms solved this issue with secondary > CPUs already, so why is agilex special ? Nothing special. Just like other SMP platforms, I am just telling you the master CPU always skips the 'spinning trap' in SPL and U-Boot proper.
RE: [PATCH v2 01/21] configs: agilex: Remove CONFIG_OF_EMBED
> On 2/20/20 6:04 PM, Westergreen, Dalon wrote: > > Please fix your mailer, it makes your reply completely unreadable. > > > On Thu, 2020-02-20 at 17:44 +0100, Marek Vasut wrote: > > > > On 2/20/20 3:12 AM, Ang, Chee Hong wrote: > > > > On 2/19/20 1:25 PM, > > > > <mailto:chee.hong@intel.com> > > > > chee.hong@intel.com > > > > wrote: > > > > From: Chee Hong Ang < > > > > <mailto:chee.hong@intel.com> > > > > chee.hong@intel.com > > > >> > > > > > > CONFIG_OF_EMBED was primarily enabled to support the agilex 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. > > OK, so this patch removes functionality. > Can that functionality be retained ? Or what can be done here? The functionality is no longer required. > > [...]
RE: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
> On 2/20/20 6:54 PM, Ang, Chee Hong wrote: > >> On 2/20/20 3:02 AM, Ang, Chee Hong wrote: > >> [...] > >>>>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) > >>>>> +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_update32clrsetbits_le32 > >>>>> +#endif > >>>> > >>>> I think I don't understand how this is supposed to work. Would > >>>> every place in U- Boot have to be patched to call these functions now ? > >>> > >>> Not every register access need this. Only those accessing registers > >>> in secure zone such as 'System Manager' registers need to call this. > >>> It's basically determine whether the driver should issue SMC/PSCI > >>> call if it's running in EL2 (non-secure) or access the registers > >>> directly by simply using > >> readl/writel and etc if it's running in EL3 (secure). > >>> Accessing those registers in secure zone in non-secure mode (EL2) > >>> will cause > >> SError exception. > >>> So we can determine this behaviour in compile time: > >>> SPL always running in EL3. So it just simply fallback to use > >> readl/writel/clrsetbits_le32. > >>> > >>> For U-Boot proper (SSBL), there are 2 scenarios: > >>> 1) If CONFIG_SPL_ATF is defined, it means ATF is supported. It > >>> implies that U-Boot proper will be running in EL2 (non-secure), then > >>> it will use > >> SMC/PSCI calls to access the secure registers. > >>> > >>> 2) CONFIG_SPL_ATF is not defined, no ATF support. U-Boot proper will > >>> be running in EL3 which will fall back to simply using the direct > >>> access functions > >> (readl/writel and etc). > >> > >> I would expect the standard IO accessors would or should handle this stuff > >> ? > > Standard IO accessors are just general memory read/write functions > > designed to be compatible with general hardware platforms. Not all > > platforms have secure/non-secure hardware zones. I don't think they should > handle this. > > > > If it's running in EL3 (secure mode) the standard I/O accessors will > > work just fine because > > EL3 can access to all secure/non-secure zones. In the header file, you > > can see the secure I/O accessors will be replaced by the standard I/O > > accessors if it's built for SPL and U-Boot proper without ATF. Because both > > are > running in EL3 (secure). > > > > If ATF is enabled, SPL will be still running in EL3 but U-Boot proper > > will be running in > > EL2 (non-secure). If any code accessing those secure zones without > > going through ATF (making SMC/PSCI calls to EL3), it will trigger 'SError' > exceptions and crash the U-Boot. > > Hmmm, if U-Boot is running in EL2 (non-secure), why would it ever access > secure zones in the first place ? SPL and U-Boot reuse the same drivers code. It runs without issue in SPL (EL3) but it crashes if running the same driver code in EL2 which access some secure zone registers. The System Manager (secure zone) contains some register which control the behaviours of EMAC/SDMMC and etc. Clock manager driver rely on those registers in System Manager as well for retrieving clock information. These clock/EMAC/SDMMC drivers access the System Manager (secure zone). > > And if that's really necessary, should the ATF really provide secure-mode > register > access primitives or should it provide some more high-level interface instead > ? I see your point. I should have mentioned to you that these secure-mode register access provided by ATF actually do more stuffs than just primitive accessors. ATF only allow certain secure registers required by the non-secure driver to be accessed. It will check the secure register address and block access if the register address is not allowed to be accessed by non-secure world (EL2). So these secure register access provided by ATF is not just simple accessor/delegate which simply allow access to any secure zone from non-secure world without any restrictions. I would say the secure register access provided by ATF is a 'middle-level' interface not just some primitive accessors. Currently, we have like 20+ secure registers allowed access by drivers running in non-secure mode (U-Boot proper / Linux). I don't think we want to define and maintain those high level interfaces for each of those secure register accesses in ATF and U-Boot.
RE: [PATCH v2 05/21] arm: socfpga: Override 'lowlevel_init' to support ATF
> On 2/20/20 3:27 AM, Ang, Chee Hong wrote: > >> On 2/19/20 1:25 PM, chee.hong@intel.com wrote: > >> [...] > >>> diff --git a/arch/arm/mach-socfpga/lowlevel_init.S > >>> b/arch/arm/mach-socfpga/lowlevel_init.S > >>> new file mode 100644 > >>> index 000..68053a0 > >>> --- /dev/null > >>> +++ b/arch/arm/mach-socfpga/lowlevel_init.S > >> > >> This should be some lowlevel_init_64.S to make it clear it's only for > >> arm64 platforms. > > OK. It makes sense. Thanks. > >> > >>> @@ -0,0 +1,85 @@ > >>> +/* SPDX-License-Identifier: GPL-2.0 */ > >>> +/* > >>> + * Copyright (C) 2019, Intel Corporation */ > >>> + > >>> +#include > >>> +#include > >>> +#include > >>> +#include > >>> + > >>> +ENTRY(lowlevel_init) > >>> + mov x29, lr /* Save LR */ > >>> + > >>> +#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) #ifdef > >>> +CONFIG_SPL_ATF > >>> + branch_if_slave x0, 2f > >>> +#else > >>> + branch_if_slave x0, 1f > >>> +#endif > >>> + > >>> + ldr x0, =GICD_BASE > >>> + bl gic_init_secure > >>> +#ifdef CONFIG_SPL_BUILD > >>> + b 2f > >>> +#else > >>> + b 3f > >>> +#endif > >> > >> Can't this be done in C code ? Can we reduce the ifdeffery ? > > This lowlevel_init function is shared by SPL and U-Boot and they run > > in slightly different flow. > > What does this 'different flow' mean ? This has something to with multi-cores CPU such as A53. For SPL, we need to make sure the slave CPUs (CPU1/2/3) trapped in a 'place' Where they could be 'activated' by kernel for multi-processor environment. It means the kernel get to 'activate' the slave CPUs from master CPU (CPU0) U-Boot proper only run on master CPU (CPU0). The rest of slave CPUs are trapped in the beginning of SPL waiting to be 'activated' by kernel. In U-Boot proper, only master CPU gets to run this code and it will just do the basic GIC setup and skip the 'trap'. The 'trap' is to prevent the slave CPUs from running the same SPL, ATF and U-Boot code as the master CPU in parallel. Only single core (maser CPU) is needed for bootloaders and firmware. > > > I don't think this can be done in C code but let me see what I can do > > to further optimize the flow to reduce the ifdeffery. > > That would be nice, thanks.
RE: [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC 64bits)
> -Original Message-
> From: Marek Vasut
> Sent: Friday, February 21, 2020 12:48 AM
> To: Ang, Chee Hong ; u-boot@lists.denx.de
> Cc: Simon Goldschmidt ; See, Chin Liang
> ; Tan, Ley Foon ;
> Westergreen, Dalon ; Gong, Richard
> ; Tom Rini ; Michal Simek
>
> Subject: Re: [PATCH v2 11/21] arm: socfpga: Secure register access for clock
> manager (SoC 64bits)
>
> On 2/20/20 3:32 AM, Ang, Chee Hong wrote:
> >> On 2/19/20 1:25 PM, chee.hong@intel.com wrote:
> >>> From: Chee Hong Ang
> >>>
> >>> 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
> >>> ---
> >>> 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 4ee2b7b..e5a0998 100644
> >>> --- a/arch/arm/mach-socfpga/clock_manager_agilex.c
> >>> +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
> >>> @@ -12,6 +12,7 @@
> >>> #include #include #include
> >>>
> >>> +#include
> >>>
> >>> DECLARE_GLOBAL_DATA_PTR;
> >>>
> >>> @@ -65,8 +66,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 #include
> >>> #include
> >>> +#include
> >>>
> >>> 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)
> >>
> >> Shouldn't the IO accessors already provide the necessary abstraction ?
> > This function accesses the system manager registers, therefore it is
> > required to call the secure register read function to make sure it
> > still can access the system manager register if it's running EL2
> > (non-secure).
>
> But shouldn't the standard IO accessors handle that transparently ?
Regarding this standard IO accessors, please refer to my reply in another email
thread.
> What does Linux do ?
Currently, Linux run in EL1 (non-secure), it will crash if it's accessing
the secure zones directly with standard memory I/O functions provided
by kernel.
It goes through the ATF by making SMC/PSCI calls to ATF to access the
secure zones. Just Like what we did in this patchset.
The only difference is kernel code always access those secure zones by making
SMC/PSCI
calls but U-Boot code get to choose the SMC/PSCI calls or standard I/O
accessors in compile
time because same code base in U-Boot may run in EL2 or EL3 depending on
whether the
code is built for SPL (EL3) or U-Boot proper without ATF (EL2).
RE: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
> On 2/20/20 3:02 AM, Ang, Chee Hong wrote: > [...] > >>> +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) > >>> +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_read32readl > >>> +#define socfpga_secure_reg_write32 writel > >>> +#define socfpga_secure_reg_update32 clrsetbits_le32 > >>> +#endif > >> > >> I think I don't understand how this is supposed to work. Would every > >> place in U- Boot have to be patched to call these functions now ? > > > > Not every register access need this. Only those accessing registers in > > secure zone such as 'System Manager' registers need to call this. It's > > basically determine whether the driver should issue SMC/PSCI call if > > it's running in EL2 (non-secure) or access the registers directly by simply > > using > readl/writel and etc if it's running in EL3 (secure). > > Accessing those registers in secure zone in non-secure mode (EL2) will cause > SError exception. > > So we can determine this behaviour in compile time: > > SPL always running in EL3. So it just simply fallback to use > readl/writel/clrsetbits_le32. > > > > For U-Boot proper (SSBL), there are 2 scenarios: > > 1) If CONFIG_SPL_ATF is defined, it means ATF is supported. It implies > > that U-Boot proper will be running in EL2 (non-secure), then it will use > SMC/PSCI calls to access the secure registers. > > > > 2) CONFIG_SPL_ATF is not defined, no ATF support. U-Boot proper will > > be running in EL3 which will fall back to simply using the direct access > > functions > (readl/writel and etc). > > I would expect the standard IO accessors would or should handle this stuff ? Standard IO accessors are just general memory read/write functions designed to be compatible with general hardware platforms. Not all platforms have secure/non-secure hardware zones. I don't think they should handle this. If it's running in EL3 (secure mode) the standard I/O accessors will work just fine because EL3 can access to all secure/non-secure zones. In the header file, you can see the secure I/O accessors will be replaced by the standard I/O accessors if it's built for SPL and U-Boot proper without ATF. Because both are running in EL3 (secure). If ATF is enabled, SPL will be still running in EL3 but U-Boot proper will be running in EL2 (non-secure). If any code accessing those secure zones without going through ATF (making SMC/PSCI calls to EL3), it will trigger 'SError' exceptions and crash the U-Boot.
RE: [PATCH v2 11/21] arm: socfpga: Secure register access for clock manager (SoC 64bits)
> On 2/19/20 1:25 PM, chee.hong@intel.com wrote:
> > From: Chee Hong Ang
> >
> > 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
> > ---
> > 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 4ee2b7b..e5a0998 100644
> > --- a/arch/arm/mach-socfpga/clock_manager_agilex.c
> > +++ b/arch/arm/mach-socfpga/clock_manager_agilex.c
> > @@ -12,6 +12,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > DECLARE_GLOBAL_DATA_PTR;
> >
> > @@ -65,8 +66,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
> > #include
> > #include
> > +#include
> >
> > 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)
>
> Shouldn't the IO accessors already provide the necessary abstraction ?
This function accesses the system manager registers, therefore it is required
to call the secure register read function to make sure it still can access
the system manager register if it's running EL2 (non-secure).
RE: [PATCH v2 05/21] arm: socfpga: Override 'lowlevel_init' to support ATF
> On 2/19/20 1:25 PM, chee.hong@intel.com wrote: > [...] > > diff --git a/arch/arm/mach-socfpga/lowlevel_init.S > > b/arch/arm/mach-socfpga/lowlevel_init.S > > new file mode 100644 > > index 000..68053a0 > > --- /dev/null > > +++ b/arch/arm/mach-socfpga/lowlevel_init.S > > This should be some lowlevel_init_64.S to make it clear it's only for > arm64 platforms. OK. It makes sense. Thanks. > > > @@ -0,0 +1,85 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2019, Intel Corporation */ > > + > > +#include > > +#include > > +#include > > +#include > > + > > +ENTRY(lowlevel_init) > > + mov x29, lr /* Save LR */ > > + > > +#if defined(CONFIG_GICV2) || defined(CONFIG_GICV3) #ifdef > > +CONFIG_SPL_ATF > > + branch_if_slave x0, 2f > > +#else > > + branch_if_slave x0, 1f > > +#endif > > + > > + ldr x0, =GICD_BASE > > + bl gic_init_secure > > +#ifdef CONFIG_SPL_BUILD > > + b 2f > > +#else > > + b 3f > > +#endif > > Can't this be done in C code ? Can we reduce the ifdeffery ? This lowlevel_init function is shared by SPL and U-Boot and they run in slightly different flow. I don't think this can be done in C code but let me see what I can do to further optimize the flow to reduce the ifdeffery.
RE: [PATCH v2 06/21] configs: socfpga: Enable FIT image loading with ATF support
> On 2/19/20 1:25 PM, chee.hong@intel.com wrote: > > From: Chee Hong Ang > > > > 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 > > --- > > 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 693a774..0065ff0 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=0x20 > > Why did the text base change ? This defconfig support ATF. ATF will occupy from this address range (0x1000) U-Boot now starts at 0x20. > > > CONFIG_SYS_MALLOC_F_LEN=0x2000 > > CONFIG_ENV_SIZE=0x1000 > > CONFIG_ENV_OFFSET=0x200 > > @@ -10,10 +10,16 @@ CONFIG_TARGET_SOCFPGA_AGILEX_SOCDK=y > > CONFIG_IDENT_STRING="socfpga_agilex" > > CONFIG_SPL_FS_FAT=y > > CONFIG_SPL_TEXT_BASE=0xFFE0 > > +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 > > Is legacy image support really needed ? Let me check. Will get rid of this if it's not needed. Thanks.
RE: [PATCH v2 01/21] configs: agilex: Remove CONFIG_OF_EMBED
> On 2/19/20 1:25 PM, chee.hong@intel.com wrote: > > From: Chee Hong Ang > > > > CONFIG_OF_EMBED was primarily enabled to support the agilex 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: Chee Hong Ang > > If I apply just this patch, is the platform still bootable ? Yes. I tested on the platform. There is a similar patch from Dalon for Stratix10 and it still yet to be applied to mainline: https://lists.denx.de/pipermail/u-boot/2019-September/384906.html I hope the patch from Dalon get applied to mainline before these patchsets. In fact, this "CONFIG_OF_EMBED" produce warning during build. Better get rid of this.
RE: [PATCH v2 10/21] arm: socfpga: Add secure register access helper functions for SoC 64bits
> On 2/19/20 1:25 PM, chee.hong@intel.com wrote: > > From: Chee Hong Ang > > > > 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 > > --- > > arch/arm/mach-socfpga/Makefile | 6 +++ > > .../mach-socfpga/include/mach/secure_reg_helper.h | 20 > > arch/arm/mach-socfpga/secure_reg_helper.c | 57 > ++ > > 3 files changed, 83 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..e59587b 100644 > > --- a/arch/arm/mach-socfpga/Makefile > > +++ b/arch/arm/mach-socfpga/Makefile > > @@ -53,6 +53,12 @@ obj-y+= wrap_pinmux_config_s10.o > > obj-y += wrap_pll_config_s10.o > > endif > > > > +ifndef CONFIG_SPL_BUILD > > +ifdef CONFIG_SPL_ATF > > +obj-y += secure_reg_helper.o > > obj-$(FOO) += bar.o , you don't need the inner ifdef OK. It's cleaner. Thanks. > > > +endif > > +endif > > [...] > > > +++ 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 > > + * > > + */ > > + > > +#ifndef_SECURE_REG_HELPER_H_ > > +#define_SECURE_REG_HELPER_H_ > > + > > +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) > > +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_update32clrsetbits_le32 > > +#endif > > I think I don't understand how this is supposed to work. Would every place in > U- > Boot have to be patched to call these functions now ? Not every register access need this. Only those accessing registers in secure zone such as 'System Manager' registers need to call this. It's basically determine whether the driver should issue SMC/PSCI call if it's running in EL2 (non-secure) or access the registers directly by simply using readl/writel and etc if it's running in EL3 (secure). Accessing those registers in secure zone in non-secure mode (EL2) will cause SError exception. So we can determine this behaviour in compile time: SPL always running in EL3. So it just simply fallback to use readl/writel/clrsetbits_le32. For U-Boot proper (SSBL), there are 2 scenarios: 1) If CONFIG_SPL_ATF is defined, it means ATF is supported. It implies that U-Boot proper will be running in EL2 (non-secure), then it will use SMC/PSCI calls to access the secure registers. 2) CONFIG_SPL_ATF is not defined, no ATF support. U-Boot proper will be running in EL3 which will fall back to simply using the direct access functions (readl/writel and etc). > > [...]
RE: [PATCH v2 09/21] arm: socfpga: Define SMC function identifiers for PSCI SiP services
> On 2/19/20 1:25 PM, chee.hong@intel.com wrote: > [...] > > +++ b/include/linux/intel-smc.h > > @@ -0,0 +1,374 @@ > > +/* SPDX-License-Identifier: GPL-2.0 */ > > +/* > > + * Copyright (C) 2017-2018, Intel Corporation > > 2020 ? This file is new in U-Boot but it already exists in Linux kernel and adapted from there. Should I change it to 2020 ? > > [...] > > > + */ > > +#define INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION > 0x > > +#define INTEL_SIP_SMC_STATUS_OK0x0 > > +#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_ERROR0x5 > > +#define INTEL_SIP_SMC_RSU_ERROR0x7 > > Indent with tabs OK. > > [...] > > > +/* > > + * 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_SEN > D_CMD) > > Is this macro a function call or a value ? It adds some value on top of ' INTEL_SIP_SMC_FUNCID_MBOX_SEND_CMD ' through some bitwise operation to produce a final value. So it's a value.
RE: [PATCH v2 08/21] arm: socfpga: Add SMC helper function for Intel SOCFPGA (64bits)
> On 2/19/20 1:25 PM, chee.hong@intel.com wrote:
> [...]
>
> > +#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF) int
> > +invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int
> > +ret_len) {
> > + int i;
> > + struct pt_regs regs;
> > +
> > + memset(, 0, sizeof(regs));
> > +
> > + regs.regs[0] = func_id;
> > +
> > + if (args) {
> > + for (i = 0; i < arg_len; i++)
> > + regs.regs[i + 1] = args[i];
>
> Is this memcpy() ?
Will change this.
>
> > + }
> > +
> > + smc_call();
> > +
> > + if (ret_arg) {
> > + for (i = 0; i < ret_len; i++)
> > + ret_arg[i] = regs.regs[i + 1];
>
> memcpy() ?
Will change this too. Thanks.
RE: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> Am 03.12.2019 um 19:31 schrieb Ang, Chee Hong: > >> On Tue, Dec 3, 2019 at 3:45 PM Ang, Chee Hong > >> > >> wrote: > >>> > >>>> On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong > >>>> > >>>> wrote: > >>>>> > >>>>>> Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > >>>>>>>> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > >>>>>>>> > >>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > >>>>>>>>>> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > >>>>>>>>>>>> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM > >>>>>>>> wrote: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> From: "Ang, Chee Hong" > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> 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 r
RE: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> Am 02.12.2019 um 11:25 schrieb chee.hong@intel.com: > > From: "Ang, Chee Hong" > > > > 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 > >
RE: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Tue, Dec 3, 2019 at 3:45 PM Ang, Chee Hong > wrote: > > > > > On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong > > > > > > wrote: > > > > > > > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > > > > > >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > > > > > >> > > > > > >> wrote: > > > > > >>> > > > > > >>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > > > > > >>>> > > > > > >>>> wrote: > > > > > >>>>> > > > > > >>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > > > >>>>>> > > > > > >>>>>> wrote: > > > > > >>>>>>> > > > > > >>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM > > > > > >>>>>>>> > > > > > >> wrote: > > > > > >>>>>>>>> > > > > > >>>>>>>>> From: "Ang, Chee Hong" > > > > > >>>>>>>>> > > > > > >>>>>>>>> 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 > > > > >
RE: [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Tue, Dec 3, 2019 at 2:37 AM Ang, Chee Hong > wrote: > > > > > Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > > > >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > > > >> > > > >> wrote: > > > >>> > > > >>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > > > >>>> > > > >>>> wrote: > > > >>>>> > > > >>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > >>>>>> > > > >>>>>> wrote: > > > >>>>>>> > > > >>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM > > > >> wrote: > > > >>>>>>>>> > > > >>>>>>>>> From: "Ang, Chee Hong" > > > >>>>>>>>> > > > >>>>>>>>> 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
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> Am 02.12.2019 um 17:10 schrieb Ang, Chee Hong: > >> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > >> > >> wrote: > >>> > >>>> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > >>>> > >>>> wrote: > >>>>> > >>>>>> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > >>>>>> > >>>>>> wrote: > >>>>>>> > >>>>>>>> On Mon, Dec 2, 2019 at 11:25 AM > >> wrote: > >>>>>>>>> > >>>>>>>>> From: "Ang, Chee Hong" > >>>>>>>>> > >>>>>>>>> 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@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
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Mon, Dec 2, 2019 at 4:18 PM Ang, Chee Hong > wrote: > > > > > On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong > > > > > > wrote: > > > > > > > > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > > > > > > > > wrote: > > > > > > > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM > wrote: > > > > > > > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > > > > > > > > > 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@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 > > #include > > #include > > -#include > > > > static int socfpga_sysreset_request(struct udevice *dev, > >
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Mon, Dec 2, 2019 at 3:08 PM Ang, Chee Hong
> wrote:
> >
> > > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong
> > >
> > > wrote:
> > > >
> > > > > On Mon, Dec 2, 2019 at 11:25 AM wrote:
> > > > > >
> > > > > > From: "Ang, Chee Hong"
> > > > > >
> > > > > > 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
#include
#include
-#include
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)
> > > > > >
> > > &
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> > On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > > > > wrote: > > > > > > > On Mon, Dec 2, 2019 at 11:25 AM wrote: > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > > > 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 > > > > > > >
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Mon, Dec 2, 2019 at 2:38 PM Ang, Chee Hong > wrote: > > > > > On Mon, Dec 2, 2019 at 11:25 AM wrote: > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > 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
Re: [U-Boot] [PATCH v1 00/20] Enable ARM Trusted Firmware for U-Boot
> On Mon, Dec 2, 2019 at 11:25 AM wrote: > > > > From: "Ang, Chee Hong" > > > > 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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/3] Enable PSCI services for booting Linux
On Thu, 2019-05-09 at 08:59 +0200, Marek Vasut wrote: > On 5/9/19 7:52 AM, Ang, Chee Hong wrote: > > > > On Mon, 2019-05-06 at 22:20 -0700, chee.hong@intel.com wrote: > > > > > > From: "Ang, Chee Hong" > > > > > > Add "SYTEM_RESET" (cold reset) and "CPU_ON" (SMP) PSCI support > > > for booting Linux on Stratix 10 platform. > > > > > > Ang, Chee Hong (3): > > > ARM: socfpga: stratix10: Enable PSCI system reset > > > ARM: socfpga: stratix10: Enable PSCI CPU_ON > > > ARM: socfpga: stratix10: Enable PSCI support for Stratix 10 > > > > > > arch/arm/mach-socfpga/Kconfig | 9 ++- > > > arch/arm/mach-socfpga/Makefile | 3 +++ > > > arch/arm/mach-socfpga/psci.c | 56 > > > ++ > > > 3 files changed, 67 insertions(+), 1 deletion(-) > > > create mode 100644 arch/arm/mach-socfpga/psci.c > > > > > Hi Marek, > > > > Any comment on this ? These PSCI patches are needed for booting > > Linux > > on our S10 platform. > Same questions as in Re: [PATCH v1 0/3] Enable HPS execution stage > notification , can we stop adding more and more stuff to arch/ and > instead add it to drivers/ ? As you might have noticed, we are trying > to > remove stuff from arch/ and move as much as possible to drivers/ , > but > S10 is doing the exact opposite :( > Not all PSCI code fit in DM (drivers/). There should be a good place to keep the PSCI code for our platform. Can you advise us where should we place those PSCI implementation other than arch/ ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/3] Enable PSCI services for booting Linux
On Mon, 2019-05-06 at 22:20 -0700, chee.hong@intel.com wrote: > From: "Ang, Chee Hong" > > Add "SYTEM_RESET" (cold reset) and "CPU_ON" (SMP) PSCI support > for booting Linux on Stratix 10 platform. > > Ang, Chee Hong (3): > ARM: socfpga: stratix10: Enable PSCI system reset > ARM: socfpga: stratix10: Enable PSCI CPU_ON > ARM: socfpga: stratix10: Enable PSCI support for Stratix 10 > > arch/arm/mach-socfpga/Kconfig | 9 ++- > arch/arm/mach-socfpga/Makefile | 3 +++ > arch/arm/mach-socfpga/psci.c | 56 > ++ > 3 files changed, 67 insertions(+), 1 deletion(-) > create mode 100644 arch/arm/mach-socfpga/psci.c > Hi Marek, Any comment on this ? These PSCI patches are needed for booting Linux on our S10 platform. BR, Ang ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/3] Enable HPS execution stage notification
On Tue, 2019-05-07 at 16:39 +0200, Marek Vasut wrote: > On 5/7/19 4:08 PM, Ang, Chee Hong wrote: > > > > On Tue, 2019-05-07 at 15:03 +0200, Marek Vasut wrote: > > > > > > On 5/7/19 7:07 AM, chee.hong@intel.com wrote: > > > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > Notify Secure Device Manager (SDM) on the stage of HPS code > > > > execution. > > > > In general, there are three main code execution stages: > > > > (1) First Stage Boot Loader (FSBL) which is U-Boot SPL. > > > > (2) Second Stage Boot Loader (SSBL) which is U-Boot. > > > > (3) Operating System which is Linux. > > > > > > > > Ang, Chee Hong (3): > > > > ARM: socfpga: stratix10: Add HPS execution stage notification > > > > function > > > > ARM: socfpga: stratix10: To notify SDM when SPL pass control > > > > to > > > > U-Boot > > > > ARM: socfpga: stratix10: To notify SDM when U-Boot pass > > > > control > > > > to > > > > Linux > > > > > > > > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 7 +++ > > > > arch/arm/mach-socfpga/mailbox_s10.c | 6 ++ > > > > arch/arm/mach-socfpga/misc_s10.c | 5 + > > > > arch/arm/mach-socfpga/spl_s10.c | 6 ++ > > > > 4 files changed, 24 insertions(+) > > > Can we expect any of this mbox stuff to be ever migrated over to > > > DM > > > and > > > moved into drivers/ instead of constantly adding stuff to mach- > > > socfpga ? > > > > > These mailbox stuffs are basically a set of functions shared by > > SPL, u- > > boot and Linux (PSCI) which is specific to our platform. Even if we > > convert this mailbox stuffs to DM and move to drivers/, we still > > need > > to duplicate those functions for PSCI which can be called by Linux. > > We > > are starting to spend time converting our existing clock manager > > and > > etc for S10 platform to DM and will move them to drivers/. > > But we still need to keep those PSCI stuffs which are specific to > > our > > platform in mach-sofcpga. > > > There was some discussion about the PSCI here: > https://www.mail-archive.com/u-boot@lists.denx.de/msg319458.html > Yes. I am aware of it. Current implementation of PSCI in u-boot is "just work" but not elegant. Currently, the PSCI sections only exist right before u-boot booting Linux, because those PSCI functions will be used by Linux only. Our current boot flow involve only u-boot (no ATF): 1) SPL (EL3, secure) 2) U-boot (El3. secure) 3) Install PSCI sections (EL3, secure) 4) Linux (EL1, non-secure) U-boot don't need PSCI call to access secure resources because it's already running in EL3 (secure). Linux will be calling those PSCI functions(EL3) from EL1 to access secure resources. For those users who typically don't use u-boot's PSCI, their boot flow is as follow: 1) ATF (EL3, secure) 2) Install PSCI sections (also known as secure monitor) (EL3, secure) 3) U-boot (EL2, non-secure) 4) Linux (EL1, non-secure) With this boot flow, all PSCI stuffs are in ATF. So u-boot and Linux don't have access to secure resources so both of them have to access it via PSCI/SMC calls. The downside is this boot flow involves 2 pieces of software component which are ATF and u-boot. Back to our u-boot use case, so far our PSCI services don't have dependency on common full driver such as (SPI, I2C and etc). That's the reason we just have sets of functions which can be directly called by u-boot(EL3) and also called by Linux(EL1) through PSCI/SMC. Those PSCI discussions are some good discussions. You have made your points and I know where you stand in those discussions. Currently, PSCI is just part of u-boot (2nd stage boot loader) and it is detached from u-boot right before booting Linux because u-boot is not expected to stay resident in memory after booting Linux. Whether PSCI should be part of SPL or TPL to support full drivers in DM and how/when it should be installed need some serious thought and effort to do it right. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/3] Enable HPS execution stage notification
On Tue, 2019-05-07 at 15:03 +0200, Marek Vasut wrote: > On 5/7/19 7:07 AM, chee.hong@intel.com wrote: > > > > From: "Ang, Chee Hong" > > > > Notify Secure Device Manager (SDM) on the stage of HPS code > > execution. > > In general, there are three main code execution stages: > > (1) First Stage Boot Loader (FSBL) which is U-Boot SPL. > > (2) Second Stage Boot Loader (SSBL) which is U-Boot. > > (3) Operating System which is Linux. > > > > Ang, Chee Hong (3): > > ARM: socfpga: stratix10: Add HPS execution stage notification > > function > > ARM: socfpga: stratix10: To notify SDM when SPL pass control to > > U-Boot > > ARM: socfpga: stratix10: To notify SDM when U-Boot pass control > > to > > Linux > > > > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 7 +++ > > arch/arm/mach-socfpga/mailbox_s10.c | 6 ++ > > arch/arm/mach-socfpga/misc_s10.c | 5 + > > arch/arm/mach-socfpga/spl_s10.c | 6 ++ > > 4 files changed, 24 insertions(+) > Can we expect any of this mbox stuff to be ever migrated over to DM > and > moved into drivers/ instead of constantly adding stuff to mach- > socfpga ? > These mailbox stuffs are basically a set of functions shared by SPL, u- boot and Linux (PSCI) which is specific to our platform. Even if we convert this mailbox stuffs to DM and move to drivers/, we still need to duplicate those functions for PSCI which can be called by Linux. We are starting to spend time converting our existing clock manager and etc for S10 platform to DM and will move them to drivers/. But we still need to keep those PSCI stuffs which are specific to our platform in mach-sofcpga. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Enable DMA330 DMA controller
On Fri, 2019-05-03 at 21:31 +0200, Marek Vasut wrote:
> On 5/3/19 7:56 PM, Ang, Chee Hong wrote:
> >
> > On Fri, 2019-05-03 at 19:04 +0200, Marek Vasut wrote:
> > >
> > > On 5/3/19 5:53 PM, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Fri, 2019-05-03 at 11:55 +0200, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 5/3/19 10:18 AM, chee.hong@intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: "Ang, Chee Hong"
> > > > > Commit message is missing -- why do you need to enable the
> > > > > DMA330
> > > > > ?
> > > > >
> > > > > Don't you have a reset driver, like A10 and Gen5 ?
> > > > DMA driver for S10 is still missing in u-boot. I need to enable
> > > > this
> > > > for booting Linux which is required by Linux's DMA driver.
> > > > I will add the reason to enable DMA330 in the commit message.
> > > Can you also answer my question regarding the reset driver ?
> > Yes. S10 has a reset driver in drivers/reset/reset-socfpga.c.
> So why don't you use it ? :-)
Since our u-boot don't have DMA330 driver, I am going to drop this
patch and let Linux DMA driver take care of the reset. Thanks.
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > Signed-off-by: Ang, Chee Hong
> > > > > > ---
> > > > > > arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 1
> > > > > > +
> > > > > > arch/arm/mach-socfpga/spl_s10.c| 4
> > > > > >
> > > > > > 2 files changed, 5 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/arm/mach-
> > > > > > socfpga/include/mach/reset_manager_s10.h
> > > > > > b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > > > > > index e186296..3ac46c3 100644
> > > > > > --- a/arch/arm/mach-
> > > > > > socfpga/include/mach/reset_manager_s10.h
> > > > > > +++ b/arch/arm/mach-
> > > > > > socfpga/include/mach/reset_manager_s10.h
> > > > > > @@ -95,6 +95,7 @@ struct socfpga_reset_manager {
> > > > > > #define RSTMGR_DMA RSTMGR_DEFINE(1, 16)
> > > > > > #define RSTMGR_SPIM0 RSTMGR_DEFINE(1, 17)
> > > > > > #define RSTMGR_SPIM1 RSTMGR_DEFINE(1, 18)
> > > > > > +#define RSTMGR_DMA_OCP RSTMGR_DEFINE(1, 21)
> > > > > > #define RSTMGR_L4WD0 RSTMGR_DEFINE(2, 0)
> > > > > > #define RSTMGR_L4WD1 RSTMGR_DEFINE(2, 1)
> > > > > > #define RSTMGR_L4WD2 RSTMGR_DEFINE(2, 2)
> > > > > > diff --git a/arch/arm/mach-socfpga/spl_s10.c
> > > > > > b/arch/arm/mach-
> > > > > > socfpga/spl_s10.c
> > > > > > index a141ffe..e063229 100644
> > > > > > --- a/arch/arm/mach-socfpga/spl_s10.c
> > > > > > +++ b/arch/arm/mach-socfpga/spl_s10.c
> > > > > > @@ -158,6 +158,10 @@ void board_init_f(ulong dummy)
> > > > > > writel(SYSMGR_DMA_IRQ_NS | SYSMGR_DMA_MGR_NS,
> > > > > > _regs->dma);
> > > > > > writel(SYSMGR_DMAPERIPH_ALL_NS, _regs-
> > > > > > >
> > > > > > > dma_periph);
> > > > > >
> > > > > > + /* enable DMA330 DMA */
> > > > > > + socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
> > > > > > + socfpga_per_reset(SOCFPGA_RESET(DMA_OCP), 0);
> > > > > > +
> > > > > > spl_disable_firewall_l4_per();
> > > > > >
> > > > > > spl_disable_firewall_l4_sys();
> > > > > >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Enable DMA330 DMA controller
On Fri, 2019-05-03 at 19:04 +0200, Marek Vasut wrote:
> On 5/3/19 5:53 PM, Ang, Chee Hong wrote:
> >
> > On Fri, 2019-05-03 at 11:55 +0200, Marek Vasut wrote:
> > >
> > > On 5/3/19 10:18 AM, chee.hong@intel.com wrote:
> > > >
> > > >
> > > > From: "Ang, Chee Hong"
> > > Commit message is missing -- why do you need to enable the DMA330
> > > ?
> > >
> > > Don't you have a reset driver, like A10 and Gen5 ?
> > DMA driver for S10 is still missing in u-boot. I need to enable
> > this
> > for booting Linux which is required by Linux's DMA driver.
> > I will add the reason to enable DMA330 in the commit message.
> Can you also answer my question regarding the reset driver ?
Yes. S10 has a reset driver in drivers/reset/reset-socfpga.c.
>
> >
> > >
> > > >
> > > > Signed-off-by: Ang, Chee Hong
> > > > ---
> > > > arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 1 +
> > > > arch/arm/mach-socfpga/spl_s10.c| 4
> > > >
> > > > 2 files changed, 5 insertions(+)
> > > >
> > > > diff --git a/arch/arm/mach-
> > > > socfpga/include/mach/reset_manager_s10.h
> > > > b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > > > index e186296..3ac46c3 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > > > @@ -95,6 +95,7 @@ struct socfpga_reset_manager {
> > > > #define RSTMGR_DMA RSTMGR_DEFINE(1, 16)
> > > > #define RSTMGR_SPIM0 RSTMGR_DEFINE(1, 17)
> > > > #define RSTMGR_SPIM1 RSTMGR_DEFINE(1, 18)
> > > > +#define RSTMGR_DMA_OCP RSTMGR_DEFINE(1, 21)
> > > > #define RSTMGR_L4WD0 RSTMGR_DEFINE(2, 0)
> > > > #define RSTMGR_L4WD1 RSTMGR_DEFINE(2, 1)
> > > > #define RSTMGR_L4WD2 RSTMGR_DEFINE(2, 2)
> > > > diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-
> > > > socfpga/spl_s10.c
> > > > index a141ffe..e063229 100644
> > > > --- a/arch/arm/mach-socfpga/spl_s10.c
> > > > +++ b/arch/arm/mach-socfpga/spl_s10.c
> > > > @@ -158,6 +158,10 @@ void board_init_f(ulong dummy)
> > > > writel(SYSMGR_DMA_IRQ_NS | SYSMGR_DMA_MGR_NS,
> > > > _regs->dma);
> > > > writel(SYSMGR_DMAPERIPH_ALL_NS, _regs-
> > > > >dma_periph);
> > > >
> > > > + /* enable DMA330 DMA */
> > > > + socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
> > > > + socfpga_per_reset(SOCFPGA_RESET(DMA_OCP), 0);
> > > > +
> > > > spl_disable_firewall_l4_per();
> > > >
> > > > spl_disable_firewall_l4_sys();
> > > >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] ARM: socfpga: stratix10: Enable DMA330 DMA controller
On Fri, 2019-05-03 at 11:55 +0200, Marek Vasut wrote:
> On 5/3/19 10:18 AM, chee.hong@intel.com wrote:
> >
> > From: "Ang, Chee Hong"
> Commit message is missing -- why do you need to enable the DMA330 ?
>
> Don't you have a reset driver, like A10 and Gen5 ?
DMA driver for S10 is still missing in u-boot. I need to enable this
for booting Linux which is required by Linux's DMA driver.
I will add the reason to enable DMA330 in the commit message.
>
> >
> > Signed-off-by: Ang, Chee Hong
> > ---
> > arch/arm/mach-socfpga/include/mach/reset_manager_s10.h | 1 +
> > arch/arm/mach-socfpga/spl_s10.c| 4
> > 2 files changed, 5 insertions(+)
> >
> > diff --git a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > index e186296..3ac46c3 100644
> > --- a/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > +++ b/arch/arm/mach-socfpga/include/mach/reset_manager_s10.h
> > @@ -95,6 +95,7 @@ struct socfpga_reset_manager {
> > #define RSTMGR_DMA RSTMGR_DEFINE(1, 16)
> > #define RSTMGR_SPIM0 RSTMGR_DEFINE(1, 17)
> > #define RSTMGR_SPIM1 RSTMGR_DEFINE(1, 18)
> > +#define RSTMGR_DMA_OCP RSTMGR_DEFINE(1, 21)
> > #define RSTMGR_L4WD0 RSTMGR_DEFINE(2, 0)
> > #define RSTMGR_L4WD1 RSTMGR_DEFINE(2, 1)
> > #define RSTMGR_L4WD2 RSTMGR_DEFINE(2, 2)
> > diff --git a/arch/arm/mach-socfpga/spl_s10.c b/arch/arm/mach-
> > socfpga/spl_s10.c
> > index a141ffe..e063229 100644
> > --- a/arch/arm/mach-socfpga/spl_s10.c
> > +++ b/arch/arm/mach-socfpga/spl_s10.c
> > @@ -158,6 +158,10 @@ void board_init_f(ulong dummy)
> > writel(SYSMGR_DMA_IRQ_NS | SYSMGR_DMA_MGR_NS,
> > _regs->dma);
> > writel(SYSMGR_DMAPERIPH_ALL_NS, _regs->dma_periph);
> >
> > + /* enable DMA330 DMA */
> > + socfpga_per_reset(SOCFPGA_RESET(DMA), 0);
> > + socfpga_per_reset(SOCFPGA_RESET(DMA_OCP), 0);
> > +
> > spl_disable_firewall_l4_per();
> >
> > spl_disable_firewall_l4_sys();
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI
On Wed, 2019-03-13 at 12:01 -0400, Tom Rini wrote:
> On Wed, Mar 13, 2019 at 08:10:31AM +0000, Ang, Chee Hong wrote:
> >
> > On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> > >
> > > On Mon, Mar 11, 2019 at 03:27:52PM +, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > > > >
> > > > >
> > > > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong.ang@intel
> > > > > .com
> > > > > wrote:
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: "Ang, Chee Hong"
> > > > > >
> > > > > > Currently u-boot only support standard PSCI functions for
> > > > > > power
> > > > > > management
> > > > > > and lack of convenient method to allow the users to extend
> > > > > > the
> > > > > > PSCI
> > > > > > functions
> > > > > > to support platform specific services. Most of the u-boot
> > > > > > users
> > > > > > still rely
> > > > > > on ATF (ARM Trusted Firmware) to handle the standard power
> > > > > > management and
> > > > > > platform specific PSCI services.
> > > > > > The purpose of this patchsets is to allow u-boot users to
> > > > > > support
> > > > > > their
> > > > > > own platform specific secure SMC/PSCI services without
> > > > > > making
> > > > > > any
> > > > > > SMC calls to ATF. This will benefit the users who need to
> > > > > > use
> > > > > > u-
> > > > > > boot as the
> > > > > > only bootloader and secure service provider without relying
> > > > > > on
> > > > > > ATF.
> > > > > >
> > > > > > Below is a simple code example for adding your own PSCI
> > > > > > functions:
> > > > > >
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > > #include
> > > > > >
> > > > > > #define PSCI_SMC64_FUNC_ID1 0xC201
> > > > > > #define PSCI_SMC64_FUNC_ID2 0xC202
> > > > > >
> > > > > > static void __secure psci_plat_specific_func1(unsigned long
> > > > > > function_id)
> > > > > > {
> > > > > > /* Your code for handling the SMC/PSCI platform
> > > > > > specific
> > > > > > service 1 */
> > > > > > }
> > > > > >
> > > > > > static void __secure psci_plat_specific_func2(unsigned long
> > > > > > function_id)
> > > > > > {
> > > > > > /* Your code for handling the SMC/PSCI platform
> > > > > > specific
> > > > > > service 2 */
> > > > > > }
> > > > > >
> > > > > > DECLARE_SECURE_SVC(plat_specific_func1,
> > > > > > PSCI_SMC64_FUNC_ID1,
> > > > > > psci_plat_specific_func1);
> > > > > > DECLARE_SECURE_SVC(plat_specific_func2,
> > > > > > PSCI_SMC64_FUNC_ID2,
> > > > > > psci_plat_specific_func2);
> > > > > >
> > > > > > Ang, Chee Hong (1):
> > > > > > ARMv8: Disable fwcall when PSCI is enabled
> > > > > >
> > > > > > Chee Hong Ang (1):
> > > > > > ARMv8: Allow SiP service extensions on top of PSCI code
> > > > > Conceptually, I suppose this is a logical step. In
> > > > > specifics,
> > > > > would
> > > > > we
> > > > > want to make this functionality opt-in, or no, that doesn't
> > > > > make
> > > > > sense?
> > > > >
> > > > Allowing user to add platform specific service is part of
> > > > SMC/PSCI
> > > > specification as specifed in ARM document (Table 2-1):
> > > > http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_D
> > > > EN00
> > > > 28B_
> > > > SMC_Calling_Convention.pdf
> > > >
> > > > So I think this functionality should be part of the standard
> > > > PSCI/SMC
> > > > implementation. Currently u-boot only support standard PSCI
> > > > call
> > > > which
> > > > is:
> > > > --
> > > > >
> > > > >
> > > > > 0x8400-0x841F | PSCI 32-bit calls |
> > > > > 0xC400-0xC41F | PSCI 64-bit calls |
> > > > --
> > > >
> > > > My implementation do not affect or alter the behavior of any
> > > > existing
> > > > standard PSCI calls.
> > > >
> > > > Users can simply add their own platform specific services by
> > > > using
> > > > the
> > > > service call range as below:
> > > >
> > > > >
> > > > >
> > > > > 0xC200-0xC200 | SMC64: SiP Service Calls |
> > > > > 0xC300-0xC300 | SMC64: OEM Service Calls |
> > > >
> > > >
> > > > For complete service call ranges please refer to Table 6-2 in
> > > > the
> > > > ARM
> > > > document.
> > > OK, thanks!
> > >
> > Any chance this enhancement get accepted ? Thanks.
> After the current release, if there's no further comments.
>
Hi Tom,
Is this patch being merged into mainline ? Or you have any further
concern or comments ? Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH] ARMv8: PSCI: Fix PSCI_TABLE relocation issue
On Mon, 2019-04-08 at 07:27 +, lars.povl...@microchip.com wrote: > > > > From: Ang, Chee Hong > > Sent: Monday, April 8, 2019 05:10 > > To: Lars Povlsen - M31675 ; > > tr...@konsulko.com; u-boot@lists.denx.de; macro.wav...@gmail.com; > > albert.u.b...@aribaud.net; york@nxp.com > > Subject: Re: [RESEND PATCH] ARMv8: PSCI: Fix PSCI_TABLE relocation > > issue > > > > On Thu, 2019-04-04 at 14:38 +0200, Lars Povlsen wrote: > > > > > > This fixes relaction isses with the PSCI_TABLE entries in > > > the psci_32_table and psci_64_table. > > > > > > When using 32-bit adress pointers relocation was not being > > > applied to > > > the tables, causing PSCI handlers to point to the un-relocated > > > code > > > area. By using 64-bit data relocation is properly applied. The > > > handlers are thus in the "secure data" area, which is protected > > > by > > > /memreserve/ in the FDT. > > > > > > Signed-off-by: Lars Povlsen > > > --- > > > arch/arm/cpu/armv8/psci.S | 13 ++--- > > > 1 file changed, 6 insertions(+), 7 deletions(-) > > > > > > diff --git a/arch/arm/cpu/armv8/psci.S > > > b/arch/arm/cpu/armv8/psci.S > > > index 358df8fee9..b4568cf053 100644 > > > --- a/arch/arm/cpu/armv8/psci.S > > > +++ b/arch/arm/cpu/armv8/psci.S > > > @@ -19,8 +19,8 @@ > > > > > > /* PSCI function and ID table definition*/ > > > #define PSCI_TABLE(__id, __fn) \ > > > - .word __id; \ > > > - .word __fn > > > + .quad __id; \ > > > + .quad __fn > > > > > > .pushsection ._secure.text, "ax" > > > > > > @@ -132,16 +132,15 @@ PSCI_TABLE(0, 0) > > > /* Caller must put PSCI function-ID table base in x9 */ > > > handle_psci: > > > psci_enter > > > -1: ldr x10, [x9] /* Load PSCI > > > function > > > table */ > > > - ubfx x11, x10, #32, #32 > > > - ubfx x10, x10, #0, #32 > > > +1: ldr x10, [x9] /* Load PSCI > > > function > > > table */ > > > cbz x10, 3f /* If reach > > > the > > > end, bail out */ > > > cmp x10, x0 > > > b.eq2f /* PSCI function > > > found > > > */ > > > - add x9, x9, #8 /* If not match, > > > try > > > next entry */ > > > + add x9, x9, #16 /* If not match, > > > try > > > next entry */ > > > b 1b > > > > > > -2: blr x11 /* Call PSCI > > > function */ > > > +2: ldr x11, [x9, #8] /* Load PSCI > > > function */ > > > + blr x11 /* Call PSCI > > > function > > > */ > > > psci_return > > > > > > 3: mov x0, #ARM_PSCI_RET_NI > > Hmmm...I presumed you made these changes because your relocation > > address for "secure" section is beyond 32bits (4GB). How your page > > table for MMU is being setup ? Why do you need such large address > > space > > (beyond 4GB) ? > No, as I tried to describe in the log message, the relocation was > simply > not being applied. Changing the offsets to 64-bit fixed this. The > .text base > was 0x8000 and the relocation was done in a 2Gb window (so > somewhere ~ 0xfff.) > > Never the less, I assume a 64-bit target should not be constrained to > 32-bit addresses? > > When debugging the code, I noticed my debugger was able to match the > original symbols > even though relocation was done. That’s how I became aware. I could > see that the vector table > and the first level code *was* relocated, but the individual handlers > not. > ---Lars CONFIG_ARMV8_SECURE_BASE defines the target relocation address for the PSCI code and the table. I just checked the PSCI handler addresses in the PSCI table entry (_psci_32_table & _psci_64_table) of my uboot, they point to the relocated address without using the 64bits size. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [RESEND PATCH] ARMv8: PSCI: Fix PSCI_TABLE relocation issue
On Thu, 2019-04-04 at 14:38 +0200, Lars Povlsen wrote: > This fixes relaction isses with the PSCI_TABLE entries in > the psci_32_table and psci_64_table. > > When using 32-bit adress pointers relocation was not being applied to > the tables, causing PSCI handlers to point to the un-relocated code > area. By using 64-bit data relocation is properly applied. The > handlers are thus in the "secure data" area, which is protected by > /memreserve/ in the FDT. > > Signed-off-by: Lars Povlsen > --- > arch/arm/cpu/armv8/psci.S | 13 ++--- > 1 file changed, 6 insertions(+), 7 deletions(-) > > diff --git a/arch/arm/cpu/armv8/psci.S b/arch/arm/cpu/armv8/psci.S > index 358df8fee9..b4568cf053 100644 > --- a/arch/arm/cpu/armv8/psci.S > +++ b/arch/arm/cpu/armv8/psci.S > @@ -19,8 +19,8 @@ > > /* PSCI function and ID table definition*/ > #define PSCI_TABLE(__id, __fn) \ > - .word __id; \ > - .word __fn > + .quad __id; \ > + .quad __fn > > .pushsection ._secure.text, "ax" > > @@ -132,16 +132,15 @@ PSCI_TABLE(0, 0) > /* Caller must put PSCI function-ID table base in x9 */ > handle_psci: > psci_enter > -1: ldr x10, [x9] /* Load PSCI function > table */ > - ubfx x11, x10, #32, #32 > - ubfx x10, x10, #0, #32 > +1: ldr x10, [x9] /* Load PSCI function > table */ > cbz x10, 3f /* If reach the > end, bail out */ > cmp x10, x0 > b.eq2f /* PSCI function found > */ > - add x9, x9, #8 /* If not match, try > next entry */ > + add x9, x9, #16 /* If not match, try > next entry */ > b 1b > > -2: blr x11 /* Call PSCI > function */ > +2: ldr x11, [x9, #8] /* Load PSCI > function */ > + blr x11 /* Call PSCI function > */ > psci_return > > 3: mov x0, #ARM_PSCI_RET_NI Hmmm...I presumed you made these changes because your relocation address for "secure" section is beyond 32bits (4GB). How your page table for MMU is being setup ? Why do you need such large address space (beyond 4GB) ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI
On Mon, 2019-03-11 at 15:48 -0400, Tom Rini wrote:
> On Mon, Mar 11, 2019 at 03:27:52PM +0000, Ang, Chee Hong wrote:
> >
> > On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> > >
> > > On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com
> > > wrote:
> > >
> > > >
> > > >
> > > > From: "Ang, Chee Hong"
> > > >
> > > > Currently u-boot only support standard PSCI functions for power
> > > > management
> > > > and lack of convenient method to allow the users to extend the
> > > > PSCI
> > > > functions
> > > > to support platform specific services. Most of the u-boot users
> > > > still rely
> > > > on ATF (ARM Trusted Firmware) to handle the standard power
> > > > management and
> > > > platform specific PSCI services.
> > > > The purpose of this patchsets is to allow u-boot users to
> > > > support
> > > > their
> > > > own platform specific secure SMC/PSCI services without making
> > > > any
> > > > SMC calls to ATF. This will benefit the users who need to use
> > > > u-
> > > > boot as the
> > > > only bootloader and secure service provider without relying on
> > > > ATF.
> > > >
> > > > Below is a simple code example for adding your own PSCI
> > > > functions:
> > > >
> > > > #include
> > > > #include
> > > > #include
> > > > #include
> > > > #include
> > > >
> > > > #define PSCI_SMC64_FUNC_ID1 0xC201
> > > > #define PSCI_SMC64_FUNC_ID2 0xC202
> > > >
> > > > static void __secure psci_plat_specific_func1(unsigned long
> > > > function_id)
> > > > {
> > > > /* Your code for handling the SMC/PSCI platform
> > > > specific
> > > > service 1 */
> > > > }
> > > >
> > > > static void __secure psci_plat_specific_func2(unsigned long
> > > > function_id)
> > > > {
> > > > /* Your code for handling the SMC/PSCI platform
> > > > specific
> > > > service 2 */
> > > > }
> > > >
> > > > DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> > > > psci_plat_specific_func1);
> > > > DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> > > > psci_plat_specific_func2);
> > > >
> > > > Ang, Chee Hong (1):
> > > > ARMv8: Disable fwcall when PSCI is enabled
> > > >
> > > > Chee Hong Ang (1):
> > > > ARMv8: Allow SiP service extensions on top of PSCI code
> > > Conceptually, I suppose this is a logical step. In specifics,
> > > would
> > > we
> > > want to make this functionality opt-in, or no, that doesn't make
> > > sense?
> > >
> > Allowing user to add platform specific service is part of SMC/PSCI
> > specification as specifed in ARM document (Table 2-1):
> > http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN00
> > 28B_
> > SMC_Calling_Convention.pdf
> >
> > So I think this functionality should be part of the standard
> > PSCI/SMC
> > implementation. Currently u-boot only support standard PSCI call
> > which
> > is:
> > --
> > >
> > > 0x8400-0x841F | PSCI 32-bit calls |
> > > 0xC400-0xC41F | PSCI 64-bit calls |
> > --
> >
> > My implementation do not affect or alter the behavior of any
> > existing
> > standard PSCI calls.
> >
> > Users can simply add their own platform specific services by using
> > the
> > service call range as below:
> >
> > >
> > > 0xC200-0xC200 | SMC64: SiP Service Calls |
> > > 0xC300-0xC300 | SMC64: OEM Service Calls |
> >
> >
> > For complete service call ranges please refer to Table 6-2 in the
> > ARM
> > document.
> OK, thanks!
>
Any chance this enhancement get accepted ? Thanks.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI
On Fri, 2019-03-08 at 13:09 -0500, Tom Rini wrote:
> On Tue, Feb 12, 2019 at 12:27:01AM -0800, chee.hong@intel.com
> wrote:
>
> >
> > From: "Ang, Chee Hong"
> >
> > Currently u-boot only support standard PSCI functions for power
> > management
> > and lack of convenient method to allow the users to extend the PSCI
> > functions
> > to support platform specific services. Most of the u-boot users
> > still rely
> > on ATF (ARM Trusted Firmware) to handle the standard power
> > management and
> > platform specific PSCI services.
> > The purpose of this patchsets is to allow u-boot users to support
> > their
> > own platform specific secure SMC/PSCI services without making any
> > SMC calls to ATF. This will benefit the users who need to use u-
> > boot as the
> > only bootloader and secure service provider without relying on ATF.
> >
> > Below is a simple code example for adding your own PSCI functions:
> >
> > #include
> > #include
> > #include
> > #include
> > #include
> >
> > #define PSCI_SMC64_FUNC_ID1 0xC201
> > #define PSCI_SMC64_FUNC_ID2 0xC202
> >
> > static void __secure psci_plat_specific_func1(unsigned long
> > function_id)
> > {
> > /* Your code for handling the SMC/PSCI platform specific
> > service 1 */
> > }
> >
> > static void __secure psci_plat_specific_func2(unsigned long
> > function_id)
> > {
> > /* Your code for handling the SMC/PSCI platform specific
> > service 2 */
> > }
> >
> > DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> > psci_plat_specific_func1);
> > DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> > psci_plat_specific_func2);
> >
> > Ang, Chee Hong (1):
> > ARMv8: Disable fwcall when PSCI is enabled
> >
> > Chee Hong Ang (1):
> > ARMv8: Allow SiP service extensions on top of PSCI code
> Conceptually, I suppose this is a logical step. In specifics, would
> we
> want to make this functionality opt-in, or no, that doesn't make
> sense?
>
Allowing user to add platform specific service is part of SMC/PSCI
specification as specifed in ARM document (Table 2-1):
http://infocenter.arm.com/help/topic/com.arm.doc.den0028b/ARM_DEN0028B_
SMC_Calling_Convention.pdf
So I think this functionality should be part of the standard PSCI/SMC
implementation. Currently u-boot only support standard PSCI call which
is:
--
| 0x8400-0x841F | PSCI 32-bit calls |
| 0xC400-0xC41F | PSCI 64-bit calls |
--
My implementation do not affect or alter the behavior of any existing
standard PSCI calls.
Users can simply add their own platform specific services by using the
service call range as below:
| 0xC200-0xC200 | SMC64: SiP Service Calls |
| 0xC300-0xC300 | SMC64: OEM Service Calls |
For complete service call ranges please refer to Table 6-2 in the ARM
document.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI
On Tue, 2019-02-12 at 00:27 -0800, chee.hong@intel.com wrote:
> From: "Ang, Chee Hong"
Hi Tom/Albert,
Any comment on this patch ?
Best Regards,
Ang
>
> Currently u-boot only support standard PSCI functions for power
> management
> and lack of convenient method to allow the users to extend the PSCI
> functions
> to support platform specific services. Most of the u-boot users still
> rely
> on ATF (ARM Trusted Firmware) to handle the standard power management
> and
> platform specific PSCI services.
> The purpose of this patchsets is to allow u-boot users to support
> their
> own platform specific secure SMC/PSCI services without making any
> SMC calls to ATF. This will benefit the users who need to use u-boot
> as the
> only bootloader and secure service provider without relying on ATF.
>
> Below is a simple code example for adding your own PSCI functions:
>
> #include
> #include
> #include
> #include
> #include
>
> #define PSCI_SMC64_FUNC_ID1 0xC201
> #define PSCI_SMC64_FUNC_ID2 0xC202
>
> static void __secure psci_plat_specific_func1(unsigned long
> function_id)
> {
> /* Your code for handling the SMC/PSCI platform specific
> service 1 */
> }
>
> static void __secure psci_plat_specific_func2(unsigned long
> function_id)
> {
> /* Your code for handling the SMC/PSCI platform specific
> service 2 */
> }
>
> DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> psci_plat_specific_func1);
> DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> psci_plat_specific_func2);
>
> Ang, Chee Hong (1):
> ARMv8: Disable fwcall when PSCI is enabled
>
> Chee Hong Ang (1):
> ARMv8: Allow SiP service extensions on top of PSCI code
>
> arch/arm/cpu/armv8/Makefile | 2 ++
> arch/arm/cpu/armv8/psci.S | 33 +++--
> arch/arm/cpu/armv8/u-boot.lds | 4
> arch/arm/include/asm/secure.h | 31 +++
> 4 files changed, 64 insertions(+), 6 deletions(-)
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1] mmc: dwmmc: Enable small delay before returning error
On Fri, 2019-02-22 at 17:02 +0100, Marek Vasut wrote: > On 2/22/19 4:19 PM, Ang, Chee Hong wrote: > > > > On Thu, 2019-02-21 at 11:06 +0100, Marek Vasut wrote: > > > > > > On 2/20/19 2:57 PM, Ang, Chee Hong wrote: > > > > > > > > > > > > On Mon, 2019-02-18 at 21:38 +0100, Marek Vasut wrote: > > > > > > > > > > > > > > > On 2/18/19 3:51 PM, Ang, Chee Hong wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2019-02-18 at 12:57 +0100, Marek Vasut wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/18/19 5:16 AM, chee.hong@intel.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > > > > > > > > > 'SET_BLOCKLEN' may occasionally fail on first attempt. > > > > > > > Why ? > > > > > > This is part of the workaround of mmc driver which is > > > > > > enabled > > > > > > with > > > > > > 'CONFIG_MMC_QUIRKS' config. > > > > > > https://github.com/u-boot/u-boot/blob/dbe70c7d4e3d5c705a98d > > > > > > 8295 > > > > > > 2e05 > > > > > > a591 > > > > > > efd0683/drivers/mmc/mmc.c#L272 > > > > > OK, let's take a step back. What problem do you observe, that > > > > > you're > > > > > trying to fix ? > > > > See my detail explanation below. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > This patch enable a small delay in dwmci_send_cmd() on > > > > > > > > busy, I/O or CRC error to allow the MMC controller > > > > > > > > recovers > > > > > > > > from the failure/error on subsequent retries. > > > > > > > Why 100 uS ? > > > > > > This is a good question. Perhaps the driver's authors can > > > > > > explain > > > > > > this. > > > > > > The driver delay 100us after dwmci_send_cmd() success with > > > > > > the > > > > > > command > > > > > > sent. But it never delay 100us whenever mmc controller > > > > > > response > > > > > > to > > > > > > the > > > > > > command sent with I/O or CRC errors. MMC drivers expect the > > > > > > first > > > > > > 'SET_BLOCKEN' command issued by dwmci_send_cmd() may fail > > > > > > intermittently so it will retry up to 4 times before it > > > > > > gave up > > > > > > and > > > > > > return error. Without this 100us delay after error > > > > > > response, > > > > > > 'SET_BLOCKEN' may sometime fail in 4 attempts in a row. > > > > > > Therefore, > > > > > > we > > > > > > encountered intermittent failure in loading u-boot (SSBL) > > > > > > from > > > > > > MMC. > > > > > Can you be more specific about the failure you saw ? > > > > Here are the steps for booting u-boot (SSBL) from MMC: > > > > > > > > 1) SPL (FSBL) get loaded to OCRAM > > > > 2) SPL try to load uboot as SSBL from MMC > > > > 3) SPL issue 'SET_BLOCKEN' to MMC controller > > > s/SPL/MMC framework via DWMMC driver/ > > Yes. It is done in drivers/mmc/mmc.c (Line 276) > > > > > > > > > > > > > > > > > > 4) If MMC controller response with error continue to step 5 > > > > else go > > > > to > > > > step 7 > > > > 5) If is less than 4 attempts go to step 3 else continue to > > > > step 6 > > > > 6) Indicate to user there was an error loading uboot as SSBL > > > > from > > > > MMC >
Re: [U-Boot] [PATCH v1] mmc: dwmmc: Enable small delay before returning error
On Thu, 2019-02-21 at 11:06 +0100, Marek Vasut wrote:
> On 2/20/19 2:57 PM, Ang, Chee Hong wrote:
> >
> > On Mon, 2019-02-18 at 21:38 +0100, Marek Vasut wrote:
> > >
> > > On 2/18/19 3:51 PM, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Mon, 2019-02-18 at 12:57 +0100, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 2/18/19 5:16 AM, chee.hong@intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: "Ang, Chee Hong"
> > > > > >
> > > > > > 'SET_BLOCKLEN' may occasionally fail on first attempt.
> > > > > Why ?
> > > > This is part of the workaround of mmc driver which is enabled
> > > > with
> > > > 'CONFIG_MMC_QUIRKS' config.
> > > > https://github.com/u-boot/u-boot/blob/dbe70c7d4e3d5c705a98d8295
> > > > 2e05
> > > > a591
> > > > efd0683/drivers/mmc/mmc.c#L272
> > > OK, let's take a step back. What problem do you observe, that
> > > you're
> > > trying to fix ?
> > See my detail explanation below.
> > >
> > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > This patch enable a small delay in dwmci_send_cmd() on
> > > > > > busy, I/O or CRC error to allow the MMC controller recovers
> > > > > > from the failure/error on subsequent retries.
> > > > > Why 100 uS ?
> > > > This is a good question. Perhaps the driver's authors can
> > > > explain
> > > > this.
> > > > The driver delay 100us after dwmci_send_cmd() success with the
> > > > command
> > > > sent. But it never delay 100us whenever mmc controller response
> > > > to
> > > > the
> > > > command sent with I/O or CRC errors. MMC drivers expect the
> > > > first
> > > > 'SET_BLOCKEN' command issued by dwmci_send_cmd() may fail
> > > > intermittently so it will retry up to 4 times before it gave up
> > > > and
> > > > return error. Without this 100us delay after error response,
> > > > 'SET_BLOCKEN' may sometime fail in 4 attempts in a row.
> > > > Therefore,
> > > > we
> > > > encountered intermittent failure in loading u-boot (SSBL) from
> > > > MMC.
> > > Can you be more specific about the failure you saw ?
> > Here are the steps for booting u-boot (SSBL) from MMC:
> >
> > 1) SPL (FSBL) get loaded to OCRAM
> > 2) SPL try to load uboot as SSBL from MMC
> > 3) SPL issue 'SET_BLOCKEN' to MMC controller
> s/SPL/MMC framework via DWMMC driver/
Yes. It is done in drivers/mmc/mmc.c (Line 276)
>
> >
> > 4) If MMC controller response with error continue to step 5 else go
> > to
> > step 7
> > 5) If is less than 4 attempts go to step 3 else continue to step 6
> > 6) Indicate to user there was an error loading uboot as SSBL from
> > MMC
> > and stop here
> > 7) Send command to read blocks of data from MMC
> > 8) uboot successfully loaded to DDR memory
> > 9) SPL jumps to uboot and continue the boot flow.
> >
> > So this patch actually introduce a small delay at step 4. Without
> > this
> > small delay, step 4 might sometime fail in all 4 attempts to issue
> > the
> > 'SET_BLOCKEN' command to MMC controller.
> Isn't what you observe here some sort of timeout which you need to
> respect when the card rejects a command ? If so, such timeout should
> be
> described in either of the SD or MMC specification and it should be
> in
> the MMC framework core instead of a driver.
I don't have chance to test other MMC drivers and I am not sure other
MMC drivers need such small delay for next retry if the card reject
this command. This DW MMC driver already enforce a small delay even the
command is success, so this makes me think that this 'time out' issue
is only specific to this DW MMC driver.
Is it necessary to 'enforce' this small delay in common MMC framework
(affecting all other MMC drivers as well) as shown below:
drivers/mmc/mmc.c
#ifdef CONFIG_MMC_QUIRKS
if (err && (mmc->quirks & MMC_QUIRK_RETRY_SET_BLOCKLEN)) {
int retries = 4;
/*
* It has been seen that SET_BLOCKLEN may fail on the
first
* attempt, let's try a few more time
*/
do {
Re: [U-Boot] [PATCH v1] mmc: dwmmc: Enable small delay before returning error
On Mon, 2019-02-18 at 21:38 +0100, Marek Vasut wrote:
> On 2/18/19 3:51 PM, Ang, Chee Hong wrote:
> >
> > On Mon, 2019-02-18 at 12:57 +0100, Marek Vasut wrote:
> > >
> > > On 2/18/19 5:16 AM, chee.hong@intel.com wrote:
> > > >
> > > >
> > > > From: "Ang, Chee Hong"
> > > >
> > > > 'SET_BLOCKLEN' may occasionally fail on first attempt.
> > > Why ?
> > This is part of the workaround of mmc driver which is enabled with
> > 'CONFIG_MMC_QUIRKS' config.
> > https://github.com/u-boot/u-boot/blob/dbe70c7d4e3d5c705a98d82952e05
> > a591
> > efd0683/drivers/mmc/mmc.c#L272
> OK, let's take a step back. What problem do you observe, that you're
> trying to fix ?
See my detail explanation below.
>
> >
> > >
> > > >
> > > > This patch enable a small delay in dwmci_send_cmd() on
> > > > busy, I/O or CRC error to allow the MMC controller recovers
> > > > from the failure/error on subsequent retries.
> > > Why 100 uS ?
> > This is a good question. Perhaps the driver's authors can explain
> > this.
> > The driver delay 100us after dwmci_send_cmd() success with the
> > command
> > sent. But it never delay 100us whenever mmc controller response to
> > the
> > command sent with I/O or CRC errors. MMC drivers expect the first
> > 'SET_BLOCKEN' command issued by dwmci_send_cmd() may fail
> > intermittently so it will retry up to 4 times before it gave up and
> > return error. Without this 100us delay after error response,
> > 'SET_BLOCKEN' may sometime fail in 4 attempts in a row. Therefore,
> > we
> > encountered intermittent failure in loading u-boot (SSBL) from MMC.
> Can you be more specific about the failure you saw ?
Here are the steps for booting u-boot (SSBL) from MMC:
1) SPL (FSBL) get loaded to OCRAM
2) SPL try to load uboot as SSBL from MMC
3) SPL issue 'SET_BLOCKEN' to MMC controller
4) If MMC controller response with error continue to step 5 else go to
step 7
5) If is less than 4 attempts go to step 3 else continue to step 6
6) Indicate to user there was an error loading uboot as SSBL from MMC
and stop here
7) Send command to read blocks of data from MMC
8) uboot successfully loaded to DDR memory
9) SPL jumps to uboot and continue the boot flow.
So this patch actually introduce a small delay at step 4. Without this
small delay, step 4 might sometime fail in all 4 attempts to issue the
'SET_BLOCKEN' command to MMC controller. Note that this failure is
intermittent. If it fails at step 3 and there is no small delay in step
4, it will most likely fail in subsequent attempts.
>
> >
> > >
> > > Can we rather detect whether the controller recovered by polling
> > > some
> > > bit?
> > Hmmm...I can take a look at the databook of this controller and dig
> > further. Probably this is the limitation of the controller itself.
> > The
> > mmc driver code which introduce 100us delay after every command
> > sent in
> > dwmci_send_cmd() looks iffy.
> If you have access to it, please do.
Unfortunately, I can't find any registers I can poll for the status of
the readiness of the controller from DesignWare storage controller
databook.
>
> btw do you have the same problem if you disable caches ?
The error happen while SPL trying to load uboot as SSBL from MMC into
DDR memory.At this point, the caches are disabled.
>
> >
> > >
> > > >
> > > > Signed-off-by: Ang, Chee Hong
> > > > ---
> > > > drivers/mmc/dw_mmc.c | 14 ++
> > > > 1 file changed, 10 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> > > > index 7544b84..8dcc518 100644
> > > > --- a/drivers/mmc/dw_mmc.c
> > > > +++ b/drivers/mmc/dw_mmc.c
> > > > @@ -266,8 +266,11 @@ static int dwmci_send_cmd(struct mmc *mmc,
> > > > struct mmc_cmd *cmd,
> > > > if (data)
> > > > flags = dwmci_set_transfer_mode(host, data);
> > > >
> > > > - if ((cmd->resp_type & MMC_RSP_136) && (cmd->resp_type
> > > > &
> > > > MMC_RSP_BUSY))
> > > > - return -1;
> > > > + if ((cmd->resp_type & MMC_RSP_136) &&
> > > > + (cmd->resp_type & MMC_RSP_BUSY)) {
> > > > + ret = -1;
> > > > + goto delay_ret;
> > > > + }
> > > >
> > > > if (cmd->cmdid
Re: [U-Boot] [PATCH v1] mmc: dwmmc: Enable small delay before returning error
On Mon, 2019-02-18 at 12:57 +0100, Marek Vasut wrote:
> On 2/18/19 5:16 AM, chee.hong@intel.com wrote:
> >
> > From: "Ang, Chee Hong"
> >
> > 'SET_BLOCKLEN' may occasionally fail on first attempt.
> Why ?
This is part of the workaround of mmc driver which is enabled with
'CONFIG_MMC_QUIRKS' config.
https://github.com/u-boot/u-boot/blob/dbe70c7d4e3d5c705a98d82952e05a591
efd0683/drivers/mmc/mmc.c#L272
>
> >
> > This patch enable a small delay in dwmci_send_cmd() on
> > busy, I/O or CRC error to allow the MMC controller recovers
> > from the failure/error on subsequent retries.
> Why 100 uS ?
This is a good question. Perhaps the driver's authors can explain this.
The driver delay 100us after dwmci_send_cmd() success with the command
sent. But it never delay 100us whenever mmc controller response to the
command sent with I/O or CRC errors. MMC drivers expect the first
'SET_BLOCKEN' command issued by dwmci_send_cmd() may fail
intermittently so it will retry up to 4 times before it gave up and
return error. Without this 100us delay after error response,
'SET_BLOCKEN' may sometime fail in 4 attempts in a row. Therefore, we
encountered intermittent failure in loading u-boot (SSBL) from MMC.
>
> Can we rather detect whether the controller recovered by polling some
> bit?
Hmmm...I can take a look at the databook of this controller and dig
further. Probably this is the limitation of the controller itself. The
mmc driver code which introduce 100us delay after every command sent in
dwmci_send_cmd() looks iffy.
>
> >
> > Signed-off-by: Ang, Chee Hong
> > ---
> > drivers/mmc/dw_mmc.c | 14 ++
> > 1 file changed, 10 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/mmc/dw_mmc.c b/drivers/mmc/dw_mmc.c
> > index 7544b84..8dcc518 100644
> > --- a/drivers/mmc/dw_mmc.c
> > +++ b/drivers/mmc/dw_mmc.c
> > @@ -266,8 +266,11 @@ static int dwmci_send_cmd(struct mmc *mmc,
> > struct mmc_cmd *cmd,
> > if (data)
> > flags = dwmci_set_transfer_mode(host, data);
> >
> > - if ((cmd->resp_type & MMC_RSP_136) && (cmd->resp_type &
> > MMC_RSP_BUSY))
> > - return -1;
> > + if ((cmd->resp_type & MMC_RSP_136) &&
> > + (cmd->resp_type & MMC_RSP_BUSY)) {
> > + ret = -1;
> > + goto delay_ret;
> > + }
> >
> > if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
> > flags |= DWMCI_CMD_ABORT_STOP;
> > @@ -316,11 +319,13 @@ static int dwmci_send_cmd(struct mmc *mmc,
> > struct mmc_cmd *cmd,
> > return -ETIMEDOUT;
> > } else if (mask & DWMCI_INTMSK_RE) {
> > debug("%s: Response Error.\n", __func__);
> > - return -EIO;
> > + ret = -EIO;
> > + goto delay_ret;
> > } else if ((cmd->resp_type & MMC_RSP_CRC) &&
> > (mask & DWMCI_INTMSK_RCRC)) {
> > debug("%s: Response CRC Error.\n", __func__);
> > - return -EIO;
> > + ret = -EIO;
> > + goto delay_ret;
> > }
> >
> >
> > @@ -347,6 +352,7 @@ static int dwmci_send_cmd(struct mmc *mmc,
> > struct mmc_cmd *cmd,
> > }
> > }
> >
> > +delay_ret:
> > udelay(100);
> >
> > return ret;
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 0/2] Allow platform specific service handling on PSCI
Hi Tom,
Any comments on this patch ?
Best Regards,
Ang
On Tue, 2019-02-12 at 00:27 -0800, chee.hong@intel.com wrote:
> From: "Ang, Chee Hong"
>
> Currently u-boot only support standard PSCI functions for power
> management
> and lack of convenient method to allow the users to extend the PSCI
> functions
> to support platform specific services. Most of the u-boot users still
> rely
> on ATF (ARM Trusted Firmware) to handle the standard power management
> and
> platform specific PSCI services.
> The purpose of this patchsets is to allow u-boot users to support
> their
> own platform specific secure SMC/PSCI services without making any
> SMC calls to ATF. This will benefit the users who need to use u-boot
> as the
> only bootloader and secure service provider without relying on ATF.
>
> Below is a simple code example for adding your own PSCI functions:
>
> #include
> #include
> #include
> #include
> #include
>
> #define PSCI_SMC64_FUNC_ID1 0xC201
> #define PSCI_SMC64_FUNC_ID2 0xC202
>
> static void __secure psci_plat_specific_func1(unsigned long
> function_id)
> {
> /* Your code for handling the SMC/PSCI platform specific
> service 1 */
> }
>
> static void __secure psci_plat_specific_func2(unsigned long
> function_id)
> {
> /* Your code for handling the SMC/PSCI platform specific
> service 2 */
> }
>
> DECLARE_SECURE_SVC(plat_specific_func1, PSCI_SMC64_FUNC_ID1,
> psci_plat_specific_func1);
> DECLARE_SECURE_SVC(plat_specific_func2, PSCI_SMC64_FUNC_ID2,
> psci_plat_specific_func2);
>
> Ang, Chee Hong (1):
> ARMv8: Disable fwcall when PSCI is enabled
>
> Chee Hong Ang (1):
> ARMv8: Allow SiP service extensions on top of PSCI code
>
> arch/arm/cpu/armv8/Makefile | 2 ++
> arch/arm/cpu/armv8/psci.S | 33 +++--
> arch/arm/cpu/armv8/u-boot.lds | 4
> arch/arm/include/asm/secure.h | 31 +++
> 4 files changed, 64 insertions(+), 6 deletions(-)
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 4/4] arm: socfpga: stratix10: Enable Stratix10 FPGA Reconfiguration
On Wed, 2018-12-19 at 09:41 +0100, Marek Vasut wrote: > On 12/19/2018 05:55 AM, Ang, Chee Hong wrote: > > > > On Tue, 2018-12-18 at 18:47 +0100, Marek Vasut wrote: > > > > > > On 12/18/2018 09:54 AM, chee.hong@intel.com wrote: > > > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > Enable Stratix10 FPGA reconfiguration support in defconfig. > > > > > > > > Signed-off-by: Ang, Chee Hong > > > > --- > > > > configs/socfpga_stratix10_defconfig | 1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > diff --git a/configs/socfpga_stratix10_defconfig > > > > b/configs/socfpga_stratix10_defconfig > > > > index 5f3d733..155c406 100644 > > > > --- a/configs/socfpga_stratix10_defconfig > > > > +++ b/configs/socfpga_stratix10_defconfig > > > > @@ -10,6 +10,7 @@ CONFIG_NR_DRAM_BANKS=1 > > > > CONFIG_BOOTDELAY=5 > > > > CONFIG_SPL_SPI_LOAD=y > > > > CONFIG_HUSH_PARSER=y > > > > +CONFIG_FPGA_STRATIX10=y > > > > CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # " > > > > CONFIG_CMD_MEMTEST=y > > > > # CONFIG_CMD_FLASH is not set > > > > > > > Can you send a subsequent patch which uses Kconfig imply to > > > select > > > FPGA_STRATIX10 on S10 instead of adding it in defconfig ? > > Noted. Will address this in next patchsets. > I asked you for an incremental patch, not for reposting the whole > patchset (also, please track changelog with new versions of patches). > > But travis would seem to indicate, again, that the patches break some > other target [1]. Can you please at least build test the next version > of > patches on all systems before posting them ? > > You can very well just set up the travis CI with your github > repo/fork > of u-boot repo, push a branch there and wait for travis to build that > branch on all supported systems and tell you what the situation is. > It > saves me time, which I otherwise spend on applying, rejecting and > dropping of your patches after they fail to build. > > [1] https://travis-ci.org/marex/u-boot-socfpga/jobs/469629378#L1142 Ok. I only test the build for current (S10) target. Some of the code are not tested with other build target. I will setup the travis CI and test it on my side before submitting new patchsets. But 1 of the build error is due to your code base missing the following patch: http://u-boot.10912.n7.nabble.com/PATCH-v2-Add-generic-FPGA-reconfig-ma ilbox-API-for-S10-td343559.html#a343560 All current patch has dependency on the patch mentioned above. You will get build errors without this patch applied before current patchsets. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 4/4] arm: socfpga: stratix10: Enable Stratix10 FPGA Reconfiguration
On Tue, 2018-12-18 at 18:47 +0100, Marek Vasut wrote: > On 12/18/2018 09:54 AM, chee.hong@intel.com wrote: > > > > From: "Ang, Chee Hong" > > > > Enable Stratix10 FPGA reconfiguration support in defconfig. > > > > Signed-off-by: Ang, Chee Hong > > --- > > configs/socfpga_stratix10_defconfig | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/configs/socfpga_stratix10_defconfig > > b/configs/socfpga_stratix10_defconfig > > index 5f3d733..155c406 100644 > > --- a/configs/socfpga_stratix10_defconfig > > +++ b/configs/socfpga_stratix10_defconfig > > @@ -10,6 +10,7 @@ CONFIG_NR_DRAM_BANKS=1 > > CONFIG_BOOTDELAY=5 > > CONFIG_SPL_SPI_LOAD=y > > CONFIG_HUSH_PARSER=y > > +CONFIG_FPGA_STRATIX10=y > > CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # " > > CONFIG_CMD_MEMTEST=y > > # CONFIG_CMD_FLASH is not set > > > Can you send a subsequent patch which uses Kconfig imply to select > FPGA_STRATIX10 on S10 instead of adding it in defconfig ? Noted. Will address this in next patchsets. ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v6 0/4] Stratix10 FPGA reconfiguration support
On Tue, 2018-12-18 at 18:47 +0100, Marek Vasut wrote: > On 12/18/2018 09:54 AM, chee.hong@intel.com wrote: > > > > From: "Ang, Chee Hong" > > > > Summary of v6 changes: > > - Patch 1/4 and 4/4 are unchanged > > - Patch 2/4: > > - fixed compilation warnings in drivers/fpga/stratix10.c > > - Patch 3/4: > > - socfpga_fpga_add() in misc.c > > - define fpga descriptor structure in misc_arria10.c, misc_gen5.c > > & > > misc_s10.c respectively > > - removed for-loop in socfpga_fpga_add() (only 1 FPGA device > > added) > > > > v5 patchsets: > > https://lists.denx.de/pipermail/u-boot/2018-November/349670.html > > > > Ang, Chee Hong (4): > > arm: socfpga: stratix10: Add macros for mailbox's arguments > > arm: socfpga: stratix10: Add Stratix 10 FPGA Reconfiguration > > Driver > > arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device > > table > > arm: socfpga: stratix10: Enable Stratix10 FPGA Reconfiguration > > > > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 6 + > > arch/arm/mach-socfpga/include/mach/misc.h| 4 +- > > arch/arm/mach-socfpga/misc.c | 26 +- > > arch/arm/mach-socfpga/misc_arria10.c | 22 +- > > arch/arm/mach-socfpga/misc_gen5.c| 22 +- > > arch/arm/mach-socfpga/misc_s10.c | 22 ++ > > configs/socfpga_stratix10_defconfig | 1 + > > drivers/fpga/Kconfig | 11 + > > drivers/fpga/Makefile| 1 + > > drivers/fpga/altera.c| 6 + > > drivers/fpga/stratix10.c | 288 > > +++ > > include/altera.h | 8 + > > 12 files changed, 389 insertions(+), 28 deletions(-) > > create mode 100644 drivers/fpga/stratix10.c > I take it this fixes the previous stratix 10 build breakage, right ? > let's see what travis says. Yes. Actually they are just compilation warnings to me. Your travis's build settings treat all warning as error. Please let me know about the travis report. Thanks. > ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Thu, 2018-11-29 at 12:28 +0100, Marek Vasut wrote:
> On 11/29/2018 10:40 AM, chee.hong@intel.com wrote:
> >
> > From: "Ang, Chee Hong"
> >
> > Enable 'fpga' command in u-boot. User will be able to use the FPGA
> > command to program the FPGA on Stratix10 SoC.
> >
> > Signed-off-by: Ang, Chee Hong
> > ---
> > arch/arm/mach-socfpga/Makefile | 4 ++
> > arch/arm/mach-socfpga/fpga_device.c | 59
> >
> > arch/arm/mach-socfpga/include/mach/fpga_device.h | 15 ++
> > arch/arm/mach-socfpga/include/mach/misc.h| 6 ---
> > arch/arm/mach-socfpga/misc.c | 31
> > -
> > arch/arm/mach-socfpga/misc_arria10.c | 1 +
> > arch/arm/mach-socfpga/misc_gen5.c| 1 +
> > arch/arm/mach-socfpga/misc_s10.c | 3 ++
> > drivers/fpga/altera.c| 6 +++
> > include/altera.h | 4 ++
> > 10 files changed, 93 insertions(+), 37 deletions(-)
> > create mode 100644 arch/arm/mach-socfpga/fpga_device.c
> > create mode 100644 arch/arm/mach-
> > socfpga/include/mach/fpga_device.h
> >
> > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> > socfpga/Makefile
> > index e667204..2ff1b3f 100644
> > --- a/arch/arm/mach-socfpga/Makefile
> > +++ b/arch/arm/mach-socfpga/Makefile
> > @@ -10,6 +10,10 @@ obj-y+= clock_manager.o
> > obj-y += misc.o
> > obj-y += reset_manager.o
> >
> > +ifdef CONFIG_FPGA
> > +obj-y += fpga_device.o
> > +endif
> > +
> > ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > obj-y += clock_manager_gen5.o
> > obj-y += misc_gen5.o
> > diff --git a/arch/arm/mach-socfpga/fpga_device.c b/arch/arm/mach-
> > socfpga/fpga_device.c
> > new file mode 100644
> > index 000..97b27eb
> > --- /dev/null
> > +++ b/arch/arm/mach-socfpga/fpga_device.c
> > @@ -0,0 +1,59 @@
> > +// SPDX-License-Identifier: GPL-2.0+
> > +/*
> > + * Copyright (C) 2018 Intel Corporation
> > + */
> > +
> > +#include
> > +#include
> > +
> > +#ifdef CONFIG_FPGA_STRATIX10
> > +/*
> > + * FPGA programming support for SoC FPGA Stratix 10
> > + */
> > +static Altera_desc altera_fpga[] = {
> > + {
> > + /* Family */
> > + Intel_FPGA_Stratix10,
> > + /* Interface type */
> > + secure_device_manager_mailbox,
> > + /* No limitation as additional data will be
> > ignored */
> > + -1,
> > + /* No device function table */
> > + NULL,
> > + /* Base interface address specified in driver */
> > + NULL,
> > + /* No cookie implementation */
> > + 0
> > + },
> > +};
> > +#else
> > +/*
> > + * FPGA programming support for SoC FPGA Cyclone V
> > + */
> > +static Altera_desc altera_fpga[] = {
> > + {
> > + /* Family */
> > + Altera_SoCFPGA,
> > + /* Interface type */
> > + fast_passive_parallel,
> > + /* No limitation as additional data will be
> > ignored */
> > + -1,
> > + /* No device function table */
> > + NULL,
> > + /* Base interface address specified in driver */
> > + NULL,
> > + /* No cookie implementation */
> > + 0
> > + },
> > +};
> > +#endif
> > +
> > +/* add device descriptor to FPGA device table */
> > +void socfpga_fpga_add(void)
> > +{
> > + int i;
> > +
> > + fpga_init();
> > + for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
> > + fpga_add(fpga_altera, _fpga[i]);
> Why do we need this loop if there's only one entry in the array ?
This ensure we have support for future platforms which might have more
than 1 FPGA devices on the platform.
> btw this function could stay in misc.c , the altera_fpga tables could
> be
> in misc_s10.c resp. something for Gen5 IMO, so you won't need another
> new file.
Yes. This will be addressed in v6 patchsets.
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v5 0/4] Stratix10 FPGA reconfiguration support
On Thu, 2018-11-29 at 12:25 +0100, Marek Vasut wrote: > On 11/29/2018 10:40 AM, chee.hong@intel.com wrote: > > > > From: "Ang, Chee Hong" > > > > Summary of v5 changes: > > - Patch 1/4, 2/4 and 4/4 are unchanged > > - Patch 3/4: > > - add arch/arm/mach-socfpga/fpga_device.c for Cyclone/Stratix > > platforms > > - remove weak socfpga_fpga_add() > > > > v4 patchsets: > > https://lists.denx.de/pipermail/u-boot/2018-November/347962.html > > > > Ang, Chee Hong (4): > > arm: socfpga: stratix10: Add macros for mailbox's arguments > > arm: socfpga: stratix10: Add Stratix 10 FPGA Reconfiguration > > Driver > > arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device > > table > > arm: socfpga: stratix10: Enable Stratix10 FPGA Reconfiguration > > > > arch/arm/mach-socfpga/Makefile | 4 + > > arch/arm/mach-socfpga/fpga_device.c | 59 + > > arch/arm/mach-socfpga/include/mach/fpga_device.h | 15 ++ > > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 6 + > > arch/arm/mach-socfpga/include/mach/misc.h| 6 - > > arch/arm/mach-socfpga/misc.c | 31 --- > > arch/arm/mach-socfpga/misc_arria10.c | 1 + > > arch/arm/mach-socfpga/misc_gen5.c| 1 + > > arch/arm/mach-socfpga/misc_s10.c | 3 + > > configs/socfpga_stratix10_defconfig | 1 + > > drivers/fpga/Kconfig | 11 + > > drivers/fpga/Makefile| 1 + > > drivers/fpga/altera.c| 6 + > > drivers/fpga/stratix10.c | 288 > > +++ > > include/altera.h | 8 + > > 15 files changed, 404 insertions(+), 37 deletions(-) > > create mode 100644 arch/arm/mach-socfpga/fpga_device.c > > create mode 100644 arch/arm/mach- > > socfpga/include/mach/fpga_device.h > > create mode 100644 drivers/fpga/stratix10.c > > > Is this fixing the build errors I reported recently ? This patchsets only address the coding styles/structures of FPGA configurations for all Intel/Altera FPGA platforms. What sort of build errors you encountered recently ? ___ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v4 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Mon, 2018-11-19 at 14:12 +0100, Marek Vasut wrote:
> On 11/19/2018 10:57 AM, Simon Goldschmidt wrote:
> >
> > On Mon, Nov 19, 2018 at 10:46 AM wrote:
> > >
> > >
> > > From: "Ang, Chee Hong"
> > >
> > > Enable 'fpga' command in u-boot. User will be able to use the
> > > FPGA
> > > command to program the FPGA on Stratix10 SoC.
> > >
> > > Signed-off-by: Ang, Chee Hong
> > > ---
> > > arch/arm/mach-socfpga/Makefile| 4 +++
> > > arch/arm/mach-socfpga/fpga_device.c | 59
> > > +++
> > > arch/arm/mach-socfpga/include/mach/misc.h | 4 ---
> > > arch/arm/mach-socfpga/misc.c | 31 +---
> > > arch/arm/mach-socfpga/misc_s10.c | 2 ++
> > > drivers/fpga/altera.c | 6
> > > include/altera.h | 4 +++
> > > 7 files changed, 76 insertions(+), 34 deletions(-)
> > > create mode 100644 arch/arm/mach-socfpga/fpga_device.c
> > >
> > > diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-
> > > socfpga/Makefile
> > > index e667204..2ff1b3f 100644
> > > --- a/arch/arm/mach-socfpga/Makefile
> > > +++ b/arch/arm/mach-socfpga/Makefile
> > > @@ -10,6 +10,10 @@ obj-y+= clock_manager.o
> > > obj-y += misc.o
> > > obj-y += reset_manager.o
> > >
> > > +ifdef CONFIG_FPGA
> > > +obj-y += fpga_device.o
> > > +endif
> > > +
> > > ifdef CONFIG_TARGET_SOCFPGA_GEN5
> > > obj-y += clock_manager_gen5.o
> > > obj-y += misc_gen5.o
> > > diff --git a/arch/arm/mach-socfpga/fpga_device.c b/arch/arm/mach-
> > > socfpga/fpga_device.c
> > > new file mode 100644
> > > index 000..97b27eb
> > > --- /dev/null
> > > +++ b/arch/arm/mach-socfpga/fpga_device.c
> > > @@ -0,0 +1,59 @@
> > > +// SPDX-License-Identifier: GPL-2.0+
> > > +/*
> > > + * Copyright (C) 2018 Intel Corporation
> > > + */
> > > +
> > > +#include
> > > +#include
> > > +
> > > +#ifdef CONFIG_FPGA_STRATIX10
> > > +/*
> > > + * FPGA programming support for SoC FPGA Stratix 10
> > > + */
> > > +static Altera_desc altera_fpga[] = {
> > > + {
> > > + /* Family */
> > > + Intel_FPGA_Stratix10,
> > > + /* Interface type */
> > > + secure_device_manager_mailbox,
> > > + /* No limitation as additional data will be
> > > ignored */
> > > + -1,
> > > + /* No device function table */
> > > + NULL,
> > > + /* Base interface address specified in driver */
> > > + NULL,
> > > + /* No cookie implementation */
> > > + 0
> > > + },
> > > +};
> > > +#else
> > > +/*
> > > + * FPGA programming support for SoC FPGA Cyclone V
> > > + */
> > > +static Altera_desc altera_fpga[] = {
> > > + {
> > > + /* Family */
> > > + Altera_SoCFPGA,
> > > + /* Interface type */
> > > + fast_passive_parallel,
> > > + /* No limitation as additional data will be
> > > ignored */
> > > + -1,
> > > + /* No device function table */
> > > + NULL,
> > > + /* Base interface address specified in driver */
> > > + NULL,
> > > + /* No cookie implementation */
> > > + 0
> > > + },
> > > +};
> > > +#endif
> > > +
> > > +/* add device descriptor to FPGA device table */
> > > +void socfpga_fpga_add(void)
> > > +{
> > > + int i;
> > > +
> > > + fpga_init();
> > > + for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
> > > + fpga_add(fpga_altera, _fpga[i]);
> > > +}
> > > diff --git a/arch/arm/mach-socfpga/include/mach/misc.h
> > > b/arch/arm/mach-socfpga/include/mach/misc.h
> > > index 4fc9570..6fa9495 100644
> > > --- a/arch/arm/mach-socfpga/include/mach/misc.h
> > > +++ b/arch/arm/mach-socfpga/include/mach/misc.h
> > > @@ -15,11 +15,7 @@ struct bsel {
> > >
> &g
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Wed, 2018-11-14 at 12:52 +0100, Marek Vasut wrote: > On 11/14/2018 08:09 AM, Ang, Chee Hong wrote: > > > > On Thu, 2018-10-11 at 10:03 +, Marek Vasut wrote: > > > > > > On 10/11/2018 08:21 AM, Ang, Chee Hong wrote: > > > > > > > > > > > > On Wed, 2018-10-10 at 12:27 +0200, Marek Vasut wrote: > > > > > > > > > > > > > > > On 10/10/2018 07:30 AM, Ang, Chee Hong wrote: > > > > > > > > > > > > > > > > > > > > > > > > On Tue, 2018-10-09 at 14:48 +0200, Marek Vasut wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/09/2018 05:03 AM, Ang, Chee Hong wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/08/2018 05:10 PM, Ang, Chee Hong wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 10/08/2018 11:48 AM, chee.hong@intel.com > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Enable 'fpga' command in u-boot. User will be > > > > > > > > > > > > able > > > > > > > > > > > > to > > > > > > > > > > > > use > > > > > > > > > > > > the > > > > > > > > > > > > fpga > > > > > > > > > > > > command to program the FPGA on Stratix10 SoC. > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Ang, Chee Hong > > > > > > > > > > > tel. > > > > > > > > > > > > com> > > > > > > > > > > > > --- > > > > > > > > > > > > arch/arm/mach-socfpga/misc.c | 29 > > > > > > > > > > > > + > > > > > > > > > > > > arch/arm/mach-socfpga/misc_s10.c | 2 ++ > > > > > > > > > > > > drivers/fpga/altera.c| 6 ++ > > > > > > > > > > > > include/altera.h | 4 > > > > > > > > > > > > 4 files changed, 41 insertions(+) > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/arch/arm/mach-socfpga/misc.c > > > > > > > > > > > > b/arch/arm/mach- > > > > > > > > > > > > socfpga/misc.c > > > > > > > > > > > > index a4f6d5c..7986b58 100644 > > > > > > > > > > > > --- a/arch/arm/mach-socfpga/misc.c > > > > > > > > > > > > +++ b/arch/arm/mach-socfpga/misc.c > > > > > > > > > > > > @@ -88,6 +88,27 @@ int overwrite_cons
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Thu, 2018-10-11 at 10:03 +, Marek Vasut wrote:
> On 10/11/2018 08:21 AM, Ang, Chee Hong wrote:
> >
> > On Wed, 2018-10-10 at 12:27 +0200, Marek Vasut wrote:
> > >
> > > On 10/10/2018 07:30 AM, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Tue, 2018-10-09 at 14:48 +0200, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 10/09/2018 05:03 AM, Ang, Chee Hong wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 10/08/2018 05:10 PM, Ang, Chee Hong wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On 10/08/2018 11:48 AM, chee.hong@intel.com
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > From: "Ang, Chee Hong"
> > > > > > > > > >
> > > > > > > > > > Enable 'fpga' command in u-boot. User will be able
> > > > > > > > > > to
> > > > > > > > > > use
> > > > > > > > > > the
> > > > > > > > > > fpga
> > > > > > > > > > command to program the FPGA on Stratix10 SoC.
> > > > > > > > > >
> > > > > > > > > > Signed-off-by: Ang, Chee Hong > > > > > > > > > com>
> > > > > > > > > > ---
> > > > > > > > > > arch/arm/mach-socfpga/misc.c | 29
> > > > > > > > > > +
> > > > > > > > > > arch/arm/mach-socfpga/misc_s10.c | 2 ++
> > > > > > > > > > drivers/fpga/altera.c| 6 ++
> > > > > > > > > > include/altera.h | 4
> > > > > > > > > > 4 files changed, 41 insertions(+)
> > > > > > > > > >
> > > > > > > > > > diff --git a/arch/arm/mach-socfpga/misc.c
> > > > > > > > > > b/arch/arm/mach-
> > > > > > > > > > socfpga/misc.c
> > > > > > > > > > index a4f6d5c..7986b58 100644
> > > > > > > > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > > > > > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > > > > > > > @@ -88,6 +88,27 @@ int overwrite_console(void)
> > > > > > > > > > #endif
> > > > > > > > > >
> > > > > > > > > > #ifdef CONFIG_FPGA
> > > > > > > > > > +#ifdef CONFIG_FPGA_STRATIX10
> > > > > > > > > > +/*
> > > > > > > > > > + * FPGA programming support for SoC FPGA Stratix
> > > > > > > > > > 10
> > > > > > > > > > + */
> > > > > > > > > > +static Altera_desc altera_fpga[] = {
> > > > > > > > > > + {
> > > > > > > > > > + /* Family */
> > > > > > > > > > + Intel_FPGA_Stratix10,
> > > > > > > > > > + /* Interface type */
> > > > > > > > > > + secure_device_manager_mailbox,
> > > > > > > > > > + /* No limitation as additional
> > > > > > > > > > data
> > > > > > > > > > will
> > > > > > > > > > be
> > > > > > > > > > ignored */
> > > >
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Wed, 2018-10-10 at 12:27 +0200, Marek Vasut wrote:
> On 10/10/2018 07:30 AM, Ang, Chee Hong wrote:
> >
> > On Tue, 2018-10-09 at 14:48 +0200, Marek Vasut wrote:
> > >
> > > On 10/09/2018 05:03 AM, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 10/08/2018 05:10 PM, Ang, Chee Hong wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On 10/08/2018 11:48 AM, chee.hong@intel.com wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > From: "Ang, Chee Hong"
> > > > > > > >
> > > > > > > > Enable 'fpga' command in u-boot. User will be able to
> > > > > > > > use
> > > > > > > > the
> > > > > > > > fpga
> > > > > > > > command to program the FPGA on Stratix10 SoC.
> > > > > > > >
> > > > > > > > Signed-off-by: Ang, Chee Hong
> > > > > > > > ---
> > > > > > > > arch/arm/mach-socfpga/misc.c | 29
> > > > > > > > +
> > > > > > > > arch/arm/mach-socfpga/misc_s10.c | 2 ++
> > > > > > > > drivers/fpga/altera.c| 6 ++
> > > > > > > > include/altera.h | 4
> > > > > > > > 4 files changed, 41 insertions(+)
> > > > > > > >
> > > > > > > > diff --git a/arch/arm/mach-socfpga/misc.c
> > > > > > > > b/arch/arm/mach-
> > > > > > > > socfpga/misc.c
> > > > > > > > index a4f6d5c..7986b58 100644
> > > > > > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > > > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > > > > > @@ -88,6 +88,27 @@ int overwrite_console(void)
> > > > > > > > #endif
> > > > > > > >
> > > > > > > > #ifdef CONFIG_FPGA
> > > > > > > > +#ifdef CONFIG_FPGA_STRATIX10
> > > > > > > > +/*
> > > > > > > > + * FPGA programming support for SoC FPGA Stratix 10
> > > > > > > > + */
> > > > > > > > +static Altera_desc altera_fpga[] = {
> > > > > > > > + {
> > > > > > > > + /* Family */
> > > > > > > > + Intel_FPGA_Stratix10,
> > > > > > > > + /* Interface type */
> > > > > > > > + secure_device_manager_mailbox,
> > > > > > > > + /* No limitation as additional data
> > > > > > > > will
> > > > > > > > be
> > > > > > > > ignored */
> > > > > > > > + -1,
> > > > > > > > + /* No device function table */
> > > > > > > > + NULL,
> > > > > > > > + /* Base interface address specified in
> > > > > > > > driver
> > > > > > > > */
> > > > > > > > + NULL,
> > > > > > > > + /* No cookie implementation */
> > > > > > > > + 0
> > > > > > > > + },
> > > > > > > > +};
> > > > > > > > +#else
> > > > > > > > /*
> > > > > > > > * FPGA programming support for SoC FPGA Cyclone V
> > > > > > > > */
> > > > > > > > @@ -107,6 +128,7 @@ static Altera_desc altera_fpga[] =
> > > > > > > > {
> > > > > > > > 0
> > > > > > > > },
> > > > > > > > };
> > > > > > > > +#endif
> > > > >
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Tue, 2018-10-09 at 14:48 +0200, Marek Vasut wrote:
> On 10/09/2018 05:03 AM, Ang, Chee Hong wrote:
> >
> > On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote:
> > >
> > > On 10/08/2018 05:10 PM, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 10/08/2018 11:48 AM, chee.hong@intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: "Ang, Chee Hong"
> > > > > >
> > > > > > Enable 'fpga' command in u-boot. User will be able to use
> > > > > > the
> > > > > > fpga
> > > > > > command to program the FPGA on Stratix10 SoC.
> > > > > >
> > > > > > Signed-off-by: Ang, Chee Hong
> > > > > > ---
> > > > > > arch/arm/mach-socfpga/misc.c | 29
> > > > > > +
> > > > > > arch/arm/mach-socfpga/misc_s10.c | 2 ++
> > > > > > drivers/fpga/altera.c| 6 ++
> > > > > > include/altera.h | 4
> > > > > > 4 files changed, 41 insertions(+)
> > > > > >
> > > > > > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-
> > > > > > socfpga/misc.c
> > > > > > index a4f6d5c..7986b58 100644
> > > > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > > > @@ -88,6 +88,27 @@ int overwrite_console(void)
> > > > > > #endif
> > > > > >
> > > > > > #ifdef CONFIG_FPGA
> > > > > > +#ifdef CONFIG_FPGA_STRATIX10
> > > > > > +/*
> > > > > > + * FPGA programming support for SoC FPGA Stratix 10
> > > > > > + */
> > > > > > +static Altera_desc altera_fpga[] = {
> > > > > > + {
> > > > > > + /* Family */
> > > > > > + Intel_FPGA_Stratix10,
> > > > > > + /* Interface type */
> > > > > > + secure_device_manager_mailbox,
> > > > > > + /* No limitation as additional data will
> > > > > > be
> > > > > > ignored */
> > > > > > + -1,
> > > > > > + /* No device function table */
> > > > > > + NULL,
> > > > > > + /* Base interface address specified in
> > > > > > driver
> > > > > > */
> > > > > > + NULL,
> > > > > > + /* No cookie implementation */
> > > > > > + 0
> > > > > > + },
> > > > > > +};
> > > > > > +#else
> > > > > > /*
> > > > > > * FPGA programming support for SoC FPGA Cyclone V
> > > > > > */
> > > > > > @@ -107,6 +128,7 @@ static Altera_desc altera_fpga[] = {
> > > > > > 0
> > > > > > },
> > > > > > };
> > > > > > +#endif
> > > > > >
> > > > > > /* add device descriptor to FPGA device table */
> > > > > > void socfpga_fpga_add(void)
> > > > > > @@ -116,6 +138,13 @@ void socfpga_fpga_add(void)
> > > > > > for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
> > > > > > fpga_add(fpga_altera, _fpga[i]);
> > > > > > }
> > > > > > +
> > > > > > +#else
> > > > > > +
> > > > > > +__weak void socfpga_fpga_add(void)
> > > > > > +{
> > > > > > +}
> > > > > Why is a __weak function defined only in else-statement ?
> > > > >
> > > > > It should be defined always, with a sane default
> > > > > implementation.
> > > > I will remove the empty function in #else-statement and define
> > > > the
> > > > default function like this :
> > > >
> > > > /* add device descriptor to FPGA device table */
> > > > void socfpga_fpga_add(void)
> > > > {
> > > > #ifdef CONFIG_FPGA
> > &g
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Mon, 2018-10-08 at 22:32 +0200, Marek Vasut wrote:
> On 10/08/2018 05:10 PM, Ang, Chee Hong wrote:
> >
> > On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut wrote:
> > >
> > > On 10/08/2018 11:48 AM, chee.hong@intel.com wrote:
> > > >
> > > >
> > > > From: "Ang, Chee Hong"
> > > >
> > > > Enable 'fpga' command in u-boot. User will be able to use the
> > > > fpga
> > > > command to program the FPGA on Stratix10 SoC.
> > > >
> > > > Signed-off-by: Ang, Chee Hong
> > > > ---
> > > > arch/arm/mach-socfpga/misc.c | 29
> > > > +
> > > > arch/arm/mach-socfpga/misc_s10.c | 2 ++
> > > > drivers/fpga/altera.c| 6 ++
> > > > include/altera.h | 4
> > > > 4 files changed, 41 insertions(+)
> > > >
> > > > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-
> > > > socfpga/misc.c
> > > > index a4f6d5c..7986b58 100644
> > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > @@ -88,6 +88,27 @@ int overwrite_console(void)
> > > > #endif
> > > >
> > > > #ifdef CONFIG_FPGA
> > > > +#ifdef CONFIG_FPGA_STRATIX10
> > > > +/*
> > > > + * FPGA programming support for SoC FPGA Stratix 10
> > > > + */
> > > > +static Altera_desc altera_fpga[] = {
> > > > + {
> > > > + /* Family */
> > > > + Intel_FPGA_Stratix10,
> > > > + /* Interface type */
> > > > + secure_device_manager_mailbox,
> > > > + /* No limitation as additional data will be
> > > > ignored */
> > > > + -1,
> > > > + /* No device function table */
> > > > + NULL,
> > > > + /* Base interface address specified in driver
> > > > */
> > > > + NULL,
> > > > + /* No cookie implementation */
> > > > + 0
> > > > + },
> > > > +};
> > > > +#else
> > > > /*
> > > > * FPGA programming support for SoC FPGA Cyclone V
> > > > */
> > > > @@ -107,6 +128,7 @@ static Altera_desc altera_fpga[] = {
> > > > 0
> > > > },
> > > > };
> > > > +#endif
> > > >
> > > > /* add device descriptor to FPGA device table */
> > > > void socfpga_fpga_add(void)
> > > > @@ -116,6 +138,13 @@ void socfpga_fpga_add(void)
> > > > for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
> > > > fpga_add(fpga_altera, _fpga[i]);
> > > > }
> > > > +
> > > > +#else
> > > > +
> > > > +__weak void socfpga_fpga_add(void)
> > > > +{
> > > > +}
> > > Why is a __weak function defined only in else-statement ?
> > >
> > > It should be defined always, with a sane default implementation.
> > I will remove the empty function in #else-statement and define the
> > default function like this :
> >
> > /* add device descriptor to FPGA device table */
> > void socfpga_fpga_add(void)
> > {
> > #ifdef CONFIG_FPGA
> > int i;
> > fpga_init();
> > for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
> > fpga_add(fpga_altera, _fpga[i]);
> > #endif
> > }
> >
> > Is that OK?
> Can't you have __weak empty implementation of socfpga_fpga_add() and
> implement a version per platform ? Would that work and make sense ?
socfpga_fpga_add() as shown above is a generic function for adding FPGA
devices to FPGA driver which applies to all our platforms. This is the
reason why it is defined in misc.c instead of misc_.c.
It turned out we already have this defined in misc.h:
#ifdef CONFIG_FPGA
void socfpga_fpga_add(void);
#else
static inline void socfpga_fpga_add(void) {}
#endif
So I don't think I need to make any changes to socfpga_fpga_add() in
misc.c. I just have to remove ifdef CONFIG_FPGA in misc_s10.c because
it was unnecessary. I will submit v3 for this patch and you can comment
further. The v3 patch will be simpler. Thanks.
>
> btw. the best solution would be to fix this proper and implement a
> DM/DT
> based probing of the FPGA, including a proper driver(s) in
> drivers/fpga/
> instead of putting all the crud into arch/arm/mach-socfpga ...
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v2 3/4] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Mon, 2018-10-08 at 11:57 +0200, Marek Vasut wrote:
> On 10/08/2018 11:48 AM, chee.hong@intel.com wrote:
> >
> > From: "Ang, Chee Hong"
> >
> > Enable 'fpga' command in u-boot. User will be able to use the fpga
> > command to program the FPGA on Stratix10 SoC.
> >
> > Signed-off-by: Ang, Chee Hong
> > ---
> > arch/arm/mach-socfpga/misc.c | 29
> > +
> > arch/arm/mach-socfpga/misc_s10.c | 2 ++
> > drivers/fpga/altera.c| 6 ++
> > include/altera.h | 4
> > 4 files changed, 41 insertions(+)
> >
> > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-
> > socfpga/misc.c
> > index a4f6d5c..7986b58 100644
> > --- a/arch/arm/mach-socfpga/misc.c
> > +++ b/arch/arm/mach-socfpga/misc.c
> > @@ -88,6 +88,27 @@ int overwrite_console(void)
> > #endif
> >
> > #ifdef CONFIG_FPGA
> > +#ifdef CONFIG_FPGA_STRATIX10
> > +/*
> > + * FPGA programming support for SoC FPGA Stratix 10
> > + */
> > +static Altera_desc altera_fpga[] = {
> > + {
> > + /* Family */
> > + Intel_FPGA_Stratix10,
> > + /* Interface type */
> > + secure_device_manager_mailbox,
> > + /* No limitation as additional data will be
> > ignored */
> > + -1,
> > + /* No device function table */
> > + NULL,
> > + /* Base interface address specified in driver */
> > + NULL,
> > + /* No cookie implementation */
> > + 0
> > + },
> > +};
> > +#else
> > /*
> > * FPGA programming support for SoC FPGA Cyclone V
> > */
> > @@ -107,6 +128,7 @@ static Altera_desc altera_fpga[] = {
> > 0
> > },
> > };
> > +#endif
> >
> > /* add device descriptor to FPGA device table */
> > void socfpga_fpga_add(void)
> > @@ -116,6 +138,13 @@ void socfpga_fpga_add(void)
> > for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
> > fpga_add(fpga_altera, _fpga[i]);
> > }
> > +
> > +#else
> > +
> > +__weak void socfpga_fpga_add(void)
> > +{
> > +}
> Why is a __weak function defined only in else-statement ?
>
> It should be defined always, with a sane default implementation.
I will remove the empty function in #else-statement and define the
default function like this :
/* add device descriptor to FPGA device table */
void socfpga_fpga_add(void)
{
#ifdef CONFIG_FPGA
int i;
fpga_init();
for (i = 0; i < ARRAY_SIZE(altera_fpga); i++)
fpga_add(fpga_altera, _fpga[i]);
#endif
}
Is that OK?
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH] arm: socfpga: stratix10: Add generic FPGA reconfig mailbox API for S10
On Thu, 2018-09-27 at 22:39 +0200, Marek Vasut wrote: > On 09/27/2018 08:37 AM, Ang, Chee Hong wrote: > > > > On Thu, 2018-09-27 at 08:21 +0200, Marek Vasut wrote: > > > > > > On 09/27/2018 07:08 AM, Ang, Chee Hong wrote: > > > > > > > > > > > > On Wed, 2018-09-26 at 16:53 +0200, Marek Vasut wrote: > > > > > > > > > > > > > > > On 09/26/2018 11:03 AM, chee.hong@intel.com wrote: > > > > > > > > > > > > > > > > > > > > > > > > From: "Ang, Chee Hong" > > > > > > > > > > > > Add a generic mailbox API for FPGA reconfig status which > > > > > > can be > > > > > > called by others. This new function accepts 2 different > > > > > > mailbox > > > > > > commands: CONFIG_STATUS or RECONFIG_STATUS. > > > > > What "others" can call this ? > > > > This is a common function used to check the readiness of the > > > > FPGA. > > > > FPGA configuration drivers will need to call this to make sure > > > > the FPGA configuration is successfully completed and running. > > > > These FPGA configuration drivers will be submitted soon after > > > > this > > > > patch. > > > So this should be in drivers/fpga/ ? > > Yes. There is a FPGA configuration driver under this folder. Will > > submit soon. > > > > > > > > > Also, don't add dead code, just submit this alongside the user of > > > this code. > > The reason I try to get this common function upstream is because my > > colleague is trying to upstream socfpga dwmac driver which also > > need to > > call this function to check whether the soft Ip running on FPGA for > > the > > dwmac driver is up and running. > SoCFPGA dwmac support is already upstream. Can you explain why it > needs > to query the FPGA at all ? Is the whole dwmac in the FPGA ? Or is the > dwmac just routed through FPGA ? dwmac driver need to call this function to access PCS (MAC PHY) which is routed through FPGA. > > > > > If I bundle this code alongside with my > > FPGA configuration driver, it might take longer time to get into > > the > > mainline. So this common function is blocking other to upstream > > his/her > > code. > I'm not really fond of accepting dead code, on which code I didn't > even > see and design that's unclear depends. I understand. Can I submit another FPGA driver patchsets and refer this patch as the dependency ? The FPGA driver patchsets is the user of the common function. > > > > > > > > > > > > > > > > > > > > > > > > > > > Signed-off-by: Ang, Chee Hong > > > > > > --- > > > > > > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 3 +- > > > > > > arch/arm/mach-socfpga/mailbox_s10.c | 48 > > > > > > > > > > > > 2 files changed, 50 insertions(+), 1 deletion(-) > > > > > > > > > > > > diff --git a/arch/arm/mach- > > > > > > socfpga/include/mach/mailbox_s10.h > > > > > > b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h > > > > > > index 81a609d..660df35 100644 > > > > > > --- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h > > > > > > +++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h > > > > > > @@ -140,5 +140,6 @@ int mbox_qspi_open(void); > > > > > > #endif > > > > > > > > > > > > int mbox_reset_cold(void); > > > > > > - > > > > > > +int mbox_get_fpga_config_status(u32 cmd); > > > > > > +int mbox_get_fpga_config_status_psci(u32 cmd); > > > > > > #endif /* _MAILBOX_S10_H_ */ > > > > > > diff --git a/arch/arm/mach-socfpga/mailbox_s10.c > > > > > > b/arch/arm/mach- > > > > > > socfpga/mailbox_s10.c > > > > > > index 0d906c3..345485c 100644 > > > > > > --- a/arch/arm/mach-socfpga/mailbox_s10.c > > > > > > +++ b/arch/arm/mach-socfpga/mailbox_s10.c > > > > > > @@ -342,6 +342,54 @@ int mbox_reset_cold(void) > > > > > > return 0; > > > > > > } > > > > > > > > > > > > +/* Accepted commands: CONFI
Re: [U-Boot] [PATCH] arm: socfpga: stratix10: Add generic FPGA reconfig mailbox API for S10
On Thu, 2018-09-27 at 08:21 +0200, Marek Vasut wrote:
> On 09/27/2018 07:08 AM, Ang, Chee Hong wrote:
> >
> > On Wed, 2018-09-26 at 16:53 +0200, Marek Vasut wrote:
> > >
> > > On 09/26/2018 11:03 AM, chee.hong@intel.com wrote:
> > > >
> > > >
> > > > From: "Ang, Chee Hong"
> > > >
> > > > Add a generic mailbox API for FPGA reconfig status which can be
> > > > called by others. This new function accepts 2 different mailbox
> > > > commands: CONFIG_STATUS or RECONFIG_STATUS.
> > > What "others" can call this ?
> > This is a common function used to check the readiness of the FPGA.
> > FPGA configuration drivers will need to call this to make sure
> > the FPGA configuration is successfully completed and running.
> > These FPGA configuration drivers will be submitted soon after this
> > patch.
> So this should be in drivers/fpga/ ?
Yes. There is a FPGA configuration driver under this folder. Will
submit soon.
>
> Also, don't add dead code, just submit this alongside the user of
> this code.
The reason I try to get this common function upstream is because my
colleague is trying to upstream socfpga dwmac driver which also need to
call this function to check whether the soft Ip running on FPGA for the
dwmac driver is up and running. If I bundle this code alongside with my
FPGA configuration driver, it might take longer time to get into the
mainline. So this common function is blocking other to upstream his/her
code.
>
> >
> > >
> > > >
> > > > Signed-off-by: Ang, Chee Hong
> > > > ---
> > > > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 3 +-
> > > > arch/arm/mach-socfpga/mailbox_s10.c | 48
> > > >
> > > > 2 files changed, 50 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > > > b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > > > index 81a609d..660df35 100644
> > > > --- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > > > +++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > > > @@ -140,5 +140,6 @@ int mbox_qspi_open(void);
> > > > #endif
> > > >
> > > > int mbox_reset_cold(void);
> > > > -
> > > > +int mbox_get_fpga_config_status(u32 cmd);
> > > > +int mbox_get_fpga_config_status_psci(u32 cmd);
> > > > #endif /* _MAILBOX_S10_H_ */
> > > > diff --git a/arch/arm/mach-socfpga/mailbox_s10.c
> > > > b/arch/arm/mach-
> > > > socfpga/mailbox_s10.c
> > > > index 0d906c3..345485c 100644
> > > > --- a/arch/arm/mach-socfpga/mailbox_s10.c
> > > > +++ b/arch/arm/mach-socfpga/mailbox_s10.c
> > > > @@ -342,6 +342,54 @@ int mbox_reset_cold(void)
> > > > return 0;
> > > > }
> > > >
> > > > +/* Accepted commands: CONFIG_STATUS or RECONFIG_STATUS */
> > > > +static __always_inline int
> > > > mbox_get_fpga_config_status_common(u32
> > > > cmd)
> > > Why __always_inline ?
> > This function is needed in 2 sections. Our u-boot run in normal
> > code
> > section and '__secure' section which mainly used for PSCI services.
> > Refer to the 'mbox_get_fpga_config_status()' and
> > 'mbox_get_fpga_config_status_psci()' below. These 2 functions run
> > in 2
> > different sections and they need to call this function.
> But why does this need to be __always_inline ? The compiler can
> decide
> what's best.
This is dangerous. Let me explain in more details why we need this,
'__secure' section and normal '.code' section exist in different time.
'.code' section no longer valid once u-boot boot to OS, but '__secure'
section still exist after booting to OS because OS need to call PSCI
services to achieve certain things. We need to make sure both sections
contain the full code, therefore we need to enforce the compiler to
duplicate this piece of code to both sections as well.
>
> >
> > >
> > > >
> > > >
> > > > +{
> > > > + u32 reconfig_status_resp_len;
> > > > + u32
> > > > reconfig_status_resp[RECONFIG_STATUS_RESPONSE_LEN];
> > > > + int ret;
> > > > +
> > > > + reconfig_status_resp_len =
> > > > RECONFIG_STATUS_RESPONSE_LEN;
> > > > + ret = mbox_send_cmd_common(MBOX_ID_UBOOT, cmd,
> > > &g
Re: [U-Boot] [PATCH] arm: socfpga: stratix10: Add generic FPGA reconfig mailbox API for S10
On Wed, 2018-09-26 at 16:53 +0200, Marek Vasut wrote:
> On 09/26/2018 11:03 AM, chee.hong@intel.com wrote:
> >
> > From: "Ang, Chee Hong"
> >
> > Add a generic mailbox API for FPGA reconfig status which can be
> > called by others. This new function accepts 2 different mailbox
> > commands: CONFIG_STATUS or RECONFIG_STATUS.
> What "others" can call this ?
This is a common function used to check the readiness of the FPGA.
FPGA configuration drivers will need to call this to make sure
the FPGA configuration is successfully completed and running.
These FPGA configuration drivers will be submitted soon after this
patch.
>
> >
> > Signed-off-by: Ang, Chee Hong
> > ---
> > arch/arm/mach-socfpga/include/mach/mailbox_s10.h | 3 +-
> > arch/arm/mach-socfpga/mailbox_s10.c | 48
> >
> > 2 files changed, 50 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > index 81a609d..660df35 100644
> > --- a/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > +++ b/arch/arm/mach-socfpga/include/mach/mailbox_s10.h
> > @@ -140,5 +140,6 @@ int mbox_qspi_open(void);
> > #endif
> >
> > int mbox_reset_cold(void);
> > -
> > +int mbox_get_fpga_config_status(u32 cmd);
> > +int mbox_get_fpga_config_status_psci(u32 cmd);
> > #endif /* _MAILBOX_S10_H_ */
> > diff --git a/arch/arm/mach-socfpga/mailbox_s10.c b/arch/arm/mach-
> > socfpga/mailbox_s10.c
> > index 0d906c3..345485c 100644
> > --- a/arch/arm/mach-socfpga/mailbox_s10.c
> > +++ b/arch/arm/mach-socfpga/mailbox_s10.c
> > @@ -342,6 +342,54 @@ int mbox_reset_cold(void)
> > return 0;
> > }
> >
> > +/* Accepted commands: CONFIG_STATUS or RECONFIG_STATUS */
> > +static __always_inline int mbox_get_fpga_config_status_common(u32
> > cmd)
> Why __always_inline ?
This function is needed in 2 sections. Our u-boot run in normal code
section and '__secure' section which mainly used for PSCI services.
Refer to the 'mbox_get_fpga_config_status()' and
'mbox_get_fpga_config_status_psci()' below. These 2 functions run in 2
different sections and they need to call this function.
>
> >
> > +{
> > + u32 reconfig_status_resp_len;
> > + u32 reconfig_status_resp[RECONFIG_STATUS_RESPONSE_LEN];
> > + int ret;
> > +
> > + reconfig_status_resp_len = RECONFIG_STATUS_RESPONSE_LEN;
> > + ret = mbox_send_cmd_common(MBOX_ID_UBOOT, cmd,
> > + MBOX_CMD_DIRECT, 0, NULL, 0,
> > + _status_resp_len,
> > + reconfig_status_resp);
> > + if (!ret) {
> if (ret)
> return ret;
Will be addressed in v2 patch.
>
> ...
>
> >
> > + /* Check for any error */
> > + ret = reconfig_status_resp[RECONFIG_STATUS_STATE];
> > + if (ret && ret != MBOX_CFGSTAT_STATE_CONFIG)
> > + return ret;
> > +
> > + /* Make sure nStatus is not 0 */
> > + ret =
> > reconfig_status_resp[RECONFIG_STATUS_PIN_STATUS];
> > + if (!(ret & RCF_PIN_STATUS_NSTATUS))
> > + return MBOX_CFGSTAT_STATE_ERROR_HARDWARE;
> > +
> > + ret =
> > reconfig_status_resp[RECONFIG_STATUS_SOFTFUNC_STATUS];
> > + if (ret & RCF_SOFTFUNC_STATUS_SEU_ERROR)
> > + return MBOX_CFGSTAT_STATE_ERROR_HARDWARE;
> > +
> > + if ((ret & RCF_SOFTFUNC_STATUS_CONF_DONE) &&
> > + (ret & RCF_SOFTFUNC_STATUS_INIT_DONE) &&
> > + !reconfig_status_resp[RECONFIG_STATUS_STATE])
> > + return 0; /* configuration success
> > */
> > + else
> > + return MBOX_CFGSTAT_STATE_CONFIG;
> > + }
> > +
> > + return ret;
> > +}
> > +
> > +int mbox_get_fpga_config_status(u32 cmd)
> > +{
> > + return mbox_get_fpga_config_status_common(cmd);
> > +}
> > +
> > +int __secure mbox_get_fpga_config_status_psci(u32 cmd)
> > +{
> > + return mbox_get_fpga_config_status_common(cmd);
> > +}
> > +
> > int mbox_send_cmd(u8 id, u32 cmd, u8 is_indirect, u32 len, u32
> > *arg,
> > u8 urgent, u32 *resp_buf_len, u32 *resp_buf)
> > {
> >
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 1/3] arm: socfpga: stratix10: Add Stratix10 FPGA Reconfiguration Driver
On Fri, 2018-04-27 at 09:08 +0200, Marek Vasut wrote:
> On 04/27/2018 07:51 AM, Ang, Chee Hong wrote:
> [...]
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > + /* Check for any error */
> > > > > > + ret =
> > > > > > reconfig_status_resp[RECONFIG_STATUS_STATE];
> > > > > > + if (ret && ret !=
> > > > > > MBOX_CFGSTAT_STATE_CONFIG)
> > > > > > + return ret;
> > > > > > +
> > > > > > + /* Make sure nStatus is not 0 */
> > > > > > + ret =
> > > > > > reconfig_status_resp[RECONFIG_STATUS_PIN_STATUS];
> > > > > > + if (!(ret & RCF_PIN_STATUS_NSTATUS))
> > > > > > + return
> > > > > > MBOX_CFGSTAT_STATE_ERROR_HARDWARE;
> > > > > wait_for_bit_le32() or somesuch ?
> > > > No, we don't read the bit status directly from register. We
> > > > only
> > > > need
> > > > to test the bit of the pin status stored in memory.
> > > Who's populating the memory ?
> > ret = mbox_send_cmd(MBOX_ID_UBOOT, MBOX_RECONFIG_STATUS,
> > MBOX_CMD_DIRECT, 0, NULL, 0, _status_resp_len,
> > reconfig_status_resp);
> >
> > We send mailbox command to the device and the device will respond
> > by
> > filling the 'reconfig_status_resp' with the device status.
> Ah, I see. Would it make sense to implement a generic "poll for bit"
> for
> this mailbox communication ? Also, we have drivers/mailbox/ , would
> it
> make sense to move the mailbox stuff there ?
There is a separate patch for mailbox communication stuffs in the
process of upstreaming by my colleague Tan, Ley Foon. But currently, I
don't think the mailbox code is placed under drivers/mailbox. I can
refactor this code into a generic function like 'get fpga device
status' via mailbox and place it under drivers/mailbox. Will work with
her to address this.
>
> [...]
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > + 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];
> > > > > Is this like a memcpy() ?
> > > > No. This is a circular buffer, index to the memory location may
> > > > wrap
> > > > around.
> > > Two memcpys then ?
> > Will refactor this part in v2.
> Does it even have to be a circular buffer in the first place ?
Yes, these mailbox responses are stored in buffer and will be retrieved
in sequence at later stage.
>
> [...]
>
> >
> > >
> > > >
> > > > >
> > > > > >
> > > > > > + /* Make sure we don't send MBOX_RECONFIG_STATUS
> > > > > > too
> > > > > > fast
> > > > > > */
> > > > > > + udelay(RECONFIG_STATUS_INTERVAL_DELAY_US);
> > > > > Hum, this is iffy, is that a hardware bug ?
> > > > Yes. The firmware running in that device is not able to
> > > > response
> > > > quickly.
> > > And you cannot poll it in some way ?
> > I know this is ugly and looks buggy. But there are no mechanism to
> > poll
> > whether the device is ready to accept any mailbox command or not.
> > So
> > for now, slowing down the mailbox exchange is the only way to go.
> If it works reliably, so be it.
Yes. It works reliably.
>
___
U-Boot mailing list
U-Boot@lists.denx.de
https://lists.denx.de/listinfo/u-boot
Re: [U-Boot] [PATCH v1 2/3] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Fri, 2018-04-27 at 09:08 +0200, Marek Vasut wrote:
> On 04/27/2018 07:31 AM, Ang, Chee Hong wrote:
> >
> > On Thu, 2018-04-26 at 14:38 +0200, Marek Vasut wrote:
> > >
> > > On 04/26/2018 08:15 AM, Ang, Chee Hong wrote:
> > > >
> > > >
> > > > On Fri, 2018-04-20 at 05:42 +0200, Marek Vasut wrote:
> > > > >
> > > > >
> > > > > On 04/20/2018 05:26 AM, chee.hong@intel.com wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Chee Hong Ang <chee.hong@intel.com>
> > > > > >
> > > > > > Enable 'fpga' command in u-boot. User will be able to use
> > > > > > the
> > > > > > fpga command to program the FPGA on Stratix10 SoC.
> > > > > >
> > > > > > Signed-off-by: Chee Hong Ang <chee.hong@intel.com>
> > > > > > ---
> > > > > > arch/arm/mach-socfpga/misc.c | 20 +---
> > > > > > arch/arm/mach-socfpga/misc_s10.c | 4
> > > > > > drivers/fpga/altera.c| 6 ++
> > > > > > include/altera.h | 8
> > > > > > 4 files changed, 35 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-
> > > > > > socfpga/misc.c
> > > > > > index d15cbc7..e36c686 100644
> > > > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > > > @@ -87,11 +87,24 @@ int overwrite_console(void)
> > > > > > #endif
> > > > > >
> > > > > > #ifdef CONFIG_FPGA
> > > > > > -/*
> > > > > > - * FPGA programming support for SoC FPGA Cyclone V
> > > > > > - */
> > > > > > static Altera_desc altera_fpga[] = {
> > > > > > {
> > > > > > +#ifdef CONFIG_FPGA_STRATIX10
> > > > > Create a separate structure for each FPGA family.
> > > > Will be addressed in v2 patch.
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > + /* FPGA programming support for SoC FPGA
> > > > > > Stratix
> > > > > > 10 */
> > > > > > + /* Family */
> > > > > > + Intel_FPGA_Stratix10,
> > > > > > + /* Interface type */
> > > > > > + secure_device_manager_mailbox,
> > > > > > + /* No limitation as additional data will
> > > > > > be
> > > > > > ignored */
> > > > > > + -1,
> > > > > > + /* No device function table */
> > > > > > + NULL,
> > > > > > + /* Base interface address specified in
> > > > > > driver
> > > > > > */
> > > > > > + NULL,
> > > > > > + /* No cookie implementation */
> > > > > > + 0
> > > > > > +#else
> > > > > > + /* FPGA programming support for SoC FPGA
> > > > > > Cyclone V
> > > > > > */
> > > > > > /* Family */
> > > > > > Altera_SoCFPGA,
> > > > > > /* Interface type */
> > > > > > @@ -104,6 +117,7 @@ static Altera_desc altera_fpga[] = {
> > > > > > NULL,
> > > > > > /* No cookie implementation */
> > > > > > 0
> > > > > > +#endif
> > > > > > },
> > > > > > };
> > > > > >
> > > > > > diff --git a/arch/arm/mach-socfpga/misc_s10.c
> > > > > > b/arch/arm/mach-
> > > > > > socfpga/misc_s10.c
> > > > > > index b1cc6ca..012d8f6 100644
> > > > > > --- a/arch/arm/mach-socfpga/misc_s10.c
> > > > > > +++ b/arch/arm/mach-socfpga/misc_s10.c
> > > > > > @@ -71,6 +71,10 @@ int arch_misc_init(void)
> > > > > >
> > > > > > int arch_early_init_r(voi
Re: [U-Boot] [PATCH v1 1/3] arm: socfpga: stratix10: Add Stratix10 FPGA Reconfiguration Driver
On Thu, 2018-04-26 at 14:37 +0200, Marek Vasut wrote:
> On 04/26/2018 08:12 AM, Ang, Chee Hong wrote:
> >
> > On Fri, 2018-04-20 at 05:41 +0200, Marek Vasut wrote:
> > >
> > > On 04/20/2018 05:26 AM, chee.hong@intel.com wrote:
> > > >
> > > >
> > > > From: Chee Hong Ang <chee.hong@intel.com>
> > > >
> > > > Enable FPGA reconfiguration support on Stratix10 SoC.
> > > >
> > > > Signed-off-by: Chee Hong Ang <chee.hong@intel.com>
> > > > ---
> > > > drivers/fpga/Kconfig | 10 ++
> > > > drivers/fpga/Makefile| 1 +
> > > > drivers/fpga/stratix10.c | 298
> > > > +++
> > > > 3 files changed, 309 insertions(+)
> > > > create mode 100644 drivers/fpga/stratix10.c
> > > >
> > > > diff --git a/drivers/fpga/Kconfig b/drivers/fpga/Kconfig
> > > > index d36c4c5..255683d 100644
> > > > --- a/drivers/fpga/Kconfig
> > > > +++ b/drivers/fpga/Kconfig
> > > > @@ -31,6 +31,16 @@ config FPGA_CYCLON2
> > > > Enable FPGA driver for loading bitstream in BIT and
> > > > BIN
> > > > format
> > > > on Altera Cyclone II device.
> > > >
> > > > +config FPGA_STRATIX10
> > > > + bool "Enable Altera FPGA driver for Stratix 10"
> > > > + depends on FPGA_ALTERA && TARGET_SOCFPGA_STRATIX10
> > > > + help
> > > > + Say Y here to enable the Altera Stratix 10 FPGA
> > > > specific
> > > > driver
> > > > +
> > > > + This provides common functionality for Altera
> > > > Stratix 10
> > > > devices.
> > > > + Enable FPGA driver for writing bitstream into Altera
> > > > Stratix10
> > > > + device.
> > > > +
> > > > config FPGA_XILINX
> > > > bool "Enable Xilinx FPGA drivers"
> > > > select FPGA
> > > > diff --git a/drivers/fpga/Makefile b/drivers/fpga/Makefile
> > > > index 08c9ff8..3c906ec 100644
> > > > --- a/drivers/fpga/Makefile
> > > > +++ b/drivers/fpga/Makefile
> > > > @@ -19,6 +19,7 @@ obj-$(CONFIG_FPGA_ACEX1K) += ACEX1K.o
> > > > obj-$(CONFIG_FPGA_CYCLON2) += cyclon2.o
> > > > obj-$(CONFIG_FPGA_STRATIX_II) += stratixII.o
> > > > obj-$(CONFIG_FPGA_STRATIX_V) += stratixv.o
> > > > +obj-$(CONFIG_FPGA_STRATIX10) += stratix10.o
> > > > obj-$(CONFIG_FPGA_SOCFPGA) += socfpga.o
> > > > obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += socfpga_gen5.o
> > > > obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += socfpga_arria10.o
> > > > diff --git a/drivers/fpga/stratix10.c
> > > > b/drivers/fpga/stratix10.c
> > > > new file mode 100644
> > > > index 000..f0c5ace
> > > > --- /dev/null
> > > > +++ b/drivers/fpga/stratix10.c
> > > > @@ -0,0 +1,298 @@
> > > > +// SPDX-License-Identifier: GPL-2.0
> > > > +/*
> > > > + * Copyright (C) 2016-2018 Intel Corporation
> > > > + *
> > > > + */
> > > > +
> > > > +#include
> > > > +#include
> > > > +#include
> > > > +
> > > > +#define RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS 60
> > > > 000
> > > > +#define RECONFIG_STATUS_INTERVAL_DELAY_US 1
> > > > 00
> > > > +
> > > > +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, "Acknowledgement
> > > > 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
Re: [U-Boot] [PATCH v1 2/3] arm: socfpga: stratix10: Add Stratix10 FPGA into FPGA device table
On Thu, 2018-04-26 at 14:38 +0200, Marek Vasut wrote:
> On 04/26/2018 08:15 AM, Ang, Chee Hong wrote:
> >
> > On Fri, 2018-04-20 at 05:42 +0200, Marek Vasut wrote:
> > >
> > > On 04/20/2018 05:26 AM, chee.hong@intel.com wrote:
> > > >
> > > >
> > > > From: Chee Hong Ang <chee.hong@intel.com>
> > > >
> > > > Enable 'fpga' command in u-boot. User will be able to use the
> > > > fpga command to program the FPGA on Stratix10 SoC.
> > > >
> > > > Signed-off-by: Chee Hong Ang <chee.hong@intel.com>
> > > > ---
> > > > arch/arm/mach-socfpga/misc.c | 20 +---
> > > > arch/arm/mach-socfpga/misc_s10.c | 4
> > > > drivers/fpga/altera.c| 6 ++
> > > > include/altera.h | 8
> > > > 4 files changed, 35 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-
> > > > socfpga/misc.c
> > > > index d15cbc7..e36c686 100644
> > > > --- a/arch/arm/mach-socfpga/misc.c
> > > > +++ b/arch/arm/mach-socfpga/misc.c
> > > > @@ -87,11 +87,24 @@ int overwrite_console(void)
> > > > #endif
> > > >
> > > > #ifdef CONFIG_FPGA
> > > > -/*
> > > > - * FPGA programming support for SoC FPGA Cyclone V
> > > > - */
> > > > static Altera_desc altera_fpga[] = {
> > > > {
> > > > +#ifdef CONFIG_FPGA_STRATIX10
> > > Create a separate structure for each FPGA family.
> > Will be addressed in v2 patch.
> > >
> > >
> > > >
> > > >
> > > > + /* FPGA programming support for SoC FPGA
> > > > Stratix
> > > > 10 */
> > > > + /* Family */
> > > > + Intel_FPGA_Stratix10,
> > > > + /* Interface type */
> > > > + secure_device_manager_mailbox,
> > > > + /* No limitation as additional data will be
> > > > ignored */
> > > > + -1,
> > > > + /* No device function table */
> > > > + NULL,
> > > > + /* Base interface address specified in driver
> > > > */
> > > > + NULL,
> > > > + /* No cookie implementation */
> > > > + 0
> > > > +#else
> > > > + /* FPGA programming support for SoC FPGA
> > > > Cyclone V
> > > > */
> > > > /* Family */
> > > > Altera_SoCFPGA,
> > > > /* Interface type */
> > > > @@ -104,6 +117,7 @@ static Altera_desc altera_fpga[] = {
> > > > NULL,
> > > > /* No cookie implementation */
> > > > 0
> > > > +#endif
> > > > },
> > > > };
> > > >
> > > > diff --git a/arch/arm/mach-socfpga/misc_s10.c b/arch/arm/mach-
> > > > socfpga/misc_s10.c
> > > > index b1cc6ca..012d8f6 100644
> > > > --- a/arch/arm/mach-socfpga/misc_s10.c
> > > > +++ b/arch/arm/mach-socfpga/misc_s10.c
> > > > @@ -71,6 +71,10 @@ int arch_misc_init(void)
> > > >
> > > > int arch_early_init_r(void)
> > > > {
> > > > +#ifdef CONFIG_FPGA
> > > > + socfpga_fpga_add();
> > > > +#endif
> > > > +
> > > > return 0;
> > > > }
> > > >
> > > > diff --git a/drivers/fpga/altera.c b/drivers/fpga/altera.c
> > > > index 135a357..b662ff5 100644
> > > > --- a/drivers/fpga/altera.c
> > > > +++ b/drivers/fpga/altera.c
> > > > @@ -40,6 +40,9 @@ static const struct altera_fpga {
> > > > #if defined(CONFIG_FPGA_STRATIX_V)
> > > > { Altera_StratixV, "StratixV", stratixv_load, NULL,
> > > > NULL
> > > > },
> > > > #endif
> > > > +#if defined(CONFIG_FPGA_STRATIX10)
> > > > + { Intel_FPGA_Stratix10, "Stratix10", stratix10_load,
> > > > NULL,
> > > > NULL },
> > > > +#endif
> > > > #if defined(CONFIG_FPGA_SOCFPGA)
> > > > { Altera_SoCFPGA, "SoC FPGA", socfpga_
