Re: [PATCH] ram: rockchip: px30: add a config-based ddr selection
Hi Simon,
Am Freitag, 2. Oktober 2020, 04:09:56 CEST schrieb Simon Glass:
> Hi Heiko,
>
> On Thu, 1 Oct 2020 at 12:40, Heiko Stuebner wrote:
> >
> > From: Heiko Stuebner
> >
> > The SRAM on the PX30 is not big enough to hold multiple DDR configs
> > so it needs to be selected during build.
> >
> > So far simply the DDR3 config was always selected and getting DDR4
> > or LPDDR2/3 initialized would require a code modification.
> >
> > So add Kconfig options similar to RK3399 to allow selecting the DDR4
> > and LPDDR2/3 options instead, while DDR3 stays the default as before.
> >
> > Signed-off-by: Heiko Stuebner
> > ---
> > drivers/ram/rockchip/Kconfig | 21 +
> > drivers/ram/rockchip/sdram_px30.c | 8
> > 2 files changed, 29 insertions(+)
> >
> > diff --git a/drivers/ram/rockchip/Kconfig b/drivers/ram/rockchip/Kconfig
> > index 8e97c2f49e..c459bbf5e2 100644
> > --- a/drivers/ram/rockchip/Kconfig
> > +++ b/drivers/ram/rockchip/Kconfig
> > @@ -22,6 +22,27 @@ config RAM_ROCKCHIP_DEBUG
> > This is an option for developers to understand the ram drivers
> > initialization, configurations and etc.
> >
> > +config RAM_PX30_DDR4
> > + bool "DDR3 support for Rockchip PX30"
> > + depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> > + help
> > + This enables DDR4 sdram support instead of the default DDR3
> > support
> > + on Rockchip PC30 SoCs.
> > +
> > +config RAM_PX30_LPDDR2
> > + bool "LPDDR2 support for Rockchip PX30"
> > + depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> > + help
> > + This enables LPDDR2 sdram support instead of the default DDR3
> > support
> > + on Rockchip PC30 SoCs.
> > +
> > +config RAM_PX30_LPDDR3
> > + bool "LPDDR3 support for Rockchip PX30"
> > + depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> > + help
> > + This enables LPDDR3 sdram support instead of the default DDR3
> > support
> > + on Rockchip PC30 SoCs.
> > +
> > config RAM_RK3399_LPDDR4
> > bool "LPDDR4 support for Rockchip RK3399"
> > depends on RAM_ROCKCHIP && ROCKCHIP_RK3399
> > diff --git a/drivers/ram/rockchip/sdram_px30.c
> > b/drivers/ram/rockchip/sdram_px30.c
> > index fd5763d0a0..2f1f6e9c0c 100644
> > --- a/drivers/ram/rockchip/sdram_px30.c
> > +++ b/drivers/ram/rockchip/sdram_px30.c
> > @@ -125,7 +125,15 @@ u32 addrmap[][8] = {
> > struct dram_info dram_info;
> >
> > struct px30_sdram_params sdram_configs[] = {
> > +#if defined(CONFIG_RAM_PX30_DDR4)
> > +#include "sdram-px30-ddr4-detect-333.inc"
> > +#elif defined(CONFIG_RAM_PX30_LPDDR2)
> > +#include "sdram-px30-lpddr2-detect-333.inc"
> > +#elif defined(CONFIG_RAM_PX30_LPDDR3)
> > +#include "sdram-px30-lpddr3-detect-333.inc"
> > +#else
> > #include "sdram-px30-ddr3-detect-333.inc"
> > +#endif
>
> How about putting this in the device tree? I think that would be a better
> place.
On the PX30 the TPL does the ram initialization and the SRAM it runs in
is very limited, so the PX30-TPL doesn't even have devicetree support
available - hence the ram selection needs to selected at compiletime.
Even right now we're "dancing" very narrowly on the limit ;-)
Heiko
[PATCH v3] arm64: dts: armada-3720-espressobin: use Linux model/compatible strings
Fix the actual board vendor and ease synching dts files from Linux.
Signed-off-by: Andre Heider
---
v3: rebase on master
arch/arm/dts/armada-3720-espressobin.dts | 4 ++--
board/Marvell/mvebu_armada-37xx/board.c | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/armada-3720-espressobin.dts
b/arch/arm/dts/armada-3720-espressobin.dts
index 4534f5ff29..be67a45870 100644
--- a/arch/arm/dts/armada-3720-espressobin.dts
+++ b/arch/arm/dts/armada-3720-espressobin.dts
@@ -50,8 +50,8 @@
#include "armada-372x.dtsi"
/ {
- model = "Marvell Armada 3720 Community Board ESPRESSOBin";
- compatible = "marvell,armada-3720-espressobin", "marvell,armada3720",
"marvell,armada3710";
+ model = "Globalscale Marvell ESPRESSOBin Board";
+ compatible = "globalscale,espressobin", "marvell,armada3720",
"marvell,armada3710";
chosen {
stdout-path = "serial0:115200n8";
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index 2bfc7171c4..73d69e0388 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -88,14 +88,14 @@ int board_late_init(void)
if (env_get("fdtfile"))
return 0;
- if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
+ if (!of_machine_is_compatible("globalscale,espressobin"))
return 0;
/* If the memory controller has been configured for DDR4, we're running
on v7 */
ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >>
A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
& A3700_MC_CTRL2_SDRAM_TYPE_MASK) ==
A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
- emmc = of_machine_is_compatible("marvell,armada-3720-espressobin-emmc");
+ emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
if (ddr4 && emmc)
env_set("fdtfile",
"marvell/armada-3720-espressobin-v7-emmc.dtb");
@@ -248,7 +248,7 @@ static int mii_multi_chip_mode_write(struct mii_dev *bus,
int dev_smi_addr,
/* Bring-up board-specific network stuff */
int board_network_enable(struct mii_dev *bus)
{
- if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
+ if (!of_machine_is_compatible("globalscale,espressobin"))
return 0;
/*
@@ -300,7 +300,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
int part_off;
/* Fill SPI MTD partitions for Linux kernel on Espressobin */
- if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
+ if (!of_machine_is_compatible("globalscale,espressobin"))
return 0;
spi_off = fdt_node_offset_by_compatible(blob, -1, "jedec,spi-nor");
--
2.28.0
[PATCH v3] arm64: dts: armada-3720-espressobin: use Linux model/compatible strings
Fix the actual board vendor and ease synching dts files from Linux.
Signed-off-by: Andre Heider
---
v3: rebase on master
arch/arm/dts/armada-3720-espressobin.dts | 4 ++--
board/Marvell/mvebu_armada-37xx/board.c | 8
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/arch/arm/dts/armada-3720-espressobin.dts
b/arch/arm/dts/armada-3720-espressobin.dts
index 4534f5ff29..be67a45870 100644
--- a/arch/arm/dts/armada-3720-espressobin.dts
+++ b/arch/arm/dts/armada-3720-espressobin.dts
@@ -50,8 +50,8 @@
#include "armada-372x.dtsi"
/ {
- model = "Marvell Armada 3720 Community Board ESPRESSOBin";
- compatible = "marvell,armada-3720-espressobin", "marvell,armada3720",
"marvell,armada3710";
+ model = "Globalscale Marvell ESPRESSOBin Board";
+ compatible = "globalscale,espressobin", "marvell,armada3720",
"marvell,armada3710";
chosen {
stdout-path = "serial0:115200n8";
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index 2bfc7171c4..73d69e0388 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -88,14 +88,14 @@ int board_late_init(void)
if (env_get("fdtfile"))
return 0;
- if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
+ if (!of_machine_is_compatible("globalscale,espressobin"))
return 0;
/* If the memory controller has been configured for DDR4, we're running
on v7 */
ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >>
A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
& A3700_MC_CTRL2_SDRAM_TYPE_MASK) ==
A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
- emmc = of_machine_is_compatible("marvell,armada-3720-espressobin-emmc");
+ emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
if (ddr4 && emmc)
env_set("fdtfile",
"marvell/armada-3720-espressobin-v7-emmc.dtb");
@@ -248,7 +248,7 @@ static int mii_multi_chip_mode_write(struct mii_dev *bus,
int dev_smi_addr,
/* Bring-up board-specific network stuff */
int board_network_enable(struct mii_dev *bus)
{
- if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
+ if (!of_machine_is_compatible("globalscale,espressobin"))
return 0;
/*
@@ -300,7 +300,7 @@ int ft_board_setup(void *blob, struct bd_info *bd)
int part_off;
/* Fill SPI MTD partitions for Linux kernel on Espressobin */
- if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
+ if (!of_machine_is_compatible("globalscale,espressobin"))
return 0;
spi_off = fdt_node_offset_by_compatible(blob, -1, "jedec,spi-nor");
--
2.28.0
RE: [PATCH v1 02/16] arm: socfpga: soc64: Add FIT generator script for pack itb with ATF
Hi Simon, > -Original Message- > From: Simon Glass > Sent: Friday, October 2, 2020 10:10 AM > To: Tan, Ley Foon > Cc: Ang, Chee Hong ; u-boot@lists.denx.de; > Marek Vasut ; Simon Goldschmidt > ; Tom Rini ; See, > Chin Liang ; Chee, Tien Fong > ; Lim, Elly Siew Chin > > Subject: Re: [PATCH v1 02/16] arm: socfpga: soc64: Add FIT generator script > for pack itb with ATF > > On Thu, 10 Sep 2020 at 03:45, Tan, Ley Foon > wrote: > > > > > > > > > -Original Message- > > > From: Ang, Chee Hong > > > Sent: Monday, August 17, 2020 12:34 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 02/16] arm: socfpga: soc64: Add FIT generator > > > script for pack itb with ATF > > > > > > Generate a FIT image for Intel SOCFPGA (64bits) which include U-boot > > > proper, ATF and DTB for U-boot proper. > > > > > > Signed-off-by: Chee Hong Ang > > > --- > > > > Reviewed-by: Ley Foon Tan > > NAK > > Please use binman. There are a few examples now and I can help if needed. > > Regards, > Simon In our flow, we will call "make u-boot.itb" separately after we successfully built u-boot with command "make mrproper, make socfpga_agilex_atf_defconfig; make -j12". Can you please advise the steps or share us the example how to do this using binman? FYI, I am referring to https://github.com/u-boot/u-boot/commit/a32dd071485b17137b6d6088d26cee8011c5b9fc on how to add binman to dts. Thanks, Siew Chin
Re: [PATCH] ram: rockchip: px30: add a config-based ddr selection
Hi Heiko,
On Thu, 1 Oct 2020 at 12:40, Heiko Stuebner wrote:
>
> From: Heiko Stuebner
>
> The SRAM on the PX30 is not big enough to hold multiple DDR configs
> so it needs to be selected during build.
>
> So far simply the DDR3 config was always selected and getting DDR4
> or LPDDR2/3 initialized would require a code modification.
>
> So add Kconfig options similar to RK3399 to allow selecting the DDR4
> and LPDDR2/3 options instead, while DDR3 stays the default as before.
>
> Signed-off-by: Heiko Stuebner
> ---
> drivers/ram/rockchip/Kconfig | 21 +
> drivers/ram/rockchip/sdram_px30.c | 8
> 2 files changed, 29 insertions(+)
>
> diff --git a/drivers/ram/rockchip/Kconfig b/drivers/ram/rockchip/Kconfig
> index 8e97c2f49e..c459bbf5e2 100644
> --- a/drivers/ram/rockchip/Kconfig
> +++ b/drivers/ram/rockchip/Kconfig
> @@ -22,6 +22,27 @@ config RAM_ROCKCHIP_DEBUG
> This is an option for developers to understand the ram drivers
> initialization, configurations and etc.
>
> +config RAM_PX30_DDR4
> + bool "DDR3 support for Rockchip PX30"
> + depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> + help
> + This enables DDR4 sdram support instead of the default DDR3 support
> + on Rockchip PC30 SoCs.
> +
> +config RAM_PX30_LPDDR2
> + bool "LPDDR2 support for Rockchip PX30"
> + depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> + help
> + This enables LPDDR2 sdram support instead of the default DDR3
> support
> + on Rockchip PC30 SoCs.
> +
> +config RAM_PX30_LPDDR3
> + bool "LPDDR3 support for Rockchip PX30"
> + depends on RAM_ROCKCHIP && ROCKCHIP_PX30
> + help
> + This enables LPDDR3 sdram support instead of the default DDR3
> support
> + on Rockchip PC30 SoCs.
> +
> config RAM_RK3399_LPDDR4
> bool "LPDDR4 support for Rockchip RK3399"
> depends on RAM_ROCKCHIP && ROCKCHIP_RK3399
> diff --git a/drivers/ram/rockchip/sdram_px30.c
> b/drivers/ram/rockchip/sdram_px30.c
> index fd5763d0a0..2f1f6e9c0c 100644
> --- a/drivers/ram/rockchip/sdram_px30.c
> +++ b/drivers/ram/rockchip/sdram_px30.c
> @@ -125,7 +125,15 @@ u32 addrmap[][8] = {
> struct dram_info dram_info;
>
> struct px30_sdram_params sdram_configs[] = {
> +#if defined(CONFIG_RAM_PX30_DDR4)
> +#include "sdram-px30-ddr4-detect-333.inc"
> +#elif defined(CONFIG_RAM_PX30_LPDDR2)
> +#include "sdram-px30-lpddr2-detect-333.inc"
> +#elif defined(CONFIG_RAM_PX30_LPDDR3)
> +#include "sdram-px30-lpddr3-detect-333.inc"
> +#else
> #include "sdram-px30-ddr3-detect-333.inc"
> +#endif
How about putting this in the device tree? I think that would be a better place.
Regards,
Simon
> };
>
> struct ddr_phy_skew skew = {
> --
> 2.28.0
>
Re: [PATCH v1 02/16] arm: socfpga: soc64: Add FIT generator script for pack itb with ATF
On Thu, 10 Sep 2020 at 03:45, Tan, Ley Foon wrote: > > > > > -Original Message- > > From: Ang, Chee Hong > > Sent: Monday, August 17, 2020 12:34 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 02/16] arm: socfpga: soc64: Add FIT generator script for > > pack itb with ATF > > > > Generate a FIT image for Intel SOCFPGA (64bits) which include U-boot proper, > > ATF and DTB for U-boot proper. > > > > Signed-off-by: Chee Hong Ang > > --- > > Reviewed-by: Ley Foon Tan NAK Please use binman. There are a few examples now and I can help if needed. Regards, Simon
Re: [PULL] u-boot-sh/next
On Thu, Oct 01, 2020 at 10:28:35AM +0200, Marek Vasut wrote: > The following changes since commit 0ac83d080a0044cd0d8f782ba12f02cf969d3004: > > Merge branch 'next' of > https://gitlab.denx.de/u-boot/custodians/u-boot-x86 into next > (2020-09-25 09:04:01 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git next > > for you to fetch changes up to 9275a963d448562a80213639c73e2dc34c6d1835: > > net: ravb: Remove writeext function call (2020-09-26 17:25:44 +0200) > Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: Please pull u-boot-marvell/master
On Thu, Oct 01, 2020 at 02:41:27PM +0200, Stefan Roese wrote: > Hi Tom, > > please pull the last batch of Marvell MVEBU related fixes. Here the > summary log: > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-sh/master
On Thu, Oct 01, 2020 at 10:27:21AM +0200, Marek Vasut wrote: > The following changes since commit 1da91d9bcd6e5ef046c1df0d373d0df87b1e8a72: > > Merge https://gitlab.denx.de/u-boot/custodians/u-boot-marvell > (2020-09-24 08:34:54 -0400) > > are available in the Git repository at: > > git://git.denx.de/u-boot-sh.git master > > for you to fetch changes up to d03ad060feab99fbcd768b1169129663f8565640: > > board: renesas: ebisu: Drop CA57 check in reset_cpu() (2020-09-26 > 17:26:01 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [U-Boot] Please pull from u-boot-i2c for 2020.10
On Thu, Oct 01, 2020 at 12:22:01PM +0200, Heiko Schocher wrote: > Hello Tom, > > late bugfix for 2020.10 ... > > The following changes since commit 5f9070a4a48d2db1968b86a54e82724dbe2a6de6: > > optee: copy FDT OP-TEE related nodes before generic FDT changes (2020-09-30 > 11:31:13 -0400) > > are available in the Git repository at: > > https://gitlab.denx.de/u-boot/custodians/u-boot-i2c.git > tags/late-bugfix-for-2020.10 > > for you to fetch changes up to 86a73b0905430c0a637280d33afa498b366f4d23: > > i2c: rcar_i2c: Fix i2c read/write errors (2020-10-01 05:41:44 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: PGP signature
Re: [v2, 00/16] Enable ARM Trusted Firmware for U-Boot
Hi Marek, On Thu, 1 Oct 2020 at 12:48, Marek Vasut wrote: > > On 10/1/20 8:37 PM, Simon Glass wrote: > > Hi Siew, > > > > On Thu, 1 Oct 2020 at 10:52, Michal Simek wrote: > >> > >> > >> > >> On 01. 10. 20 11:15, Siew Chin Lim wrote: > >>> This is the 2nd version of patchset to Enable ARM Trusted Firmware > >>> for U-Boot. > >>> > >>> 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) > >>> > >>> Patch status: > >>> Have changes: Patch 2, 8, 9, 10, 11, 16 > >>> Other patches unchanged. > >>> > >>> Detail changelog can find in commit message. > >>> > >>> v1->v2: > >>> > >>> Patch 2: > >>> - Move soc64 folder from board/altera to board/intel folder > >>> > >>> Patch 8: > >>> - Updated comments > >>> > >>> Patch 9: > >>> - Code clean up without functionality change > >>> > >>> Patch 10: > >>> - Code clean up without functionality change > >>> > >>> Patch 11: > >>> - Print error message and return instead of hang in > >>> socfpga_bridges_reset() > >>> when SMC call is failing. > >>> > >>> Patch 16: > >>> - Add CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200 > >>> - Move board/altera/soc64/fit_spl_atf.sh to > >>> board/intel/soc64/fit_spl_atf.sh > >>> > >>> History: > >>> > >>> [v1]: https://patchwork.ozlabs.org/project/uboot/list/?series=195854 > >>> > >>> > >>> 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 | 13 + > >>> arch/arm/mach-socfpga/smc_api.c| 56 ++ > >>> arch/arm/mach-socfpga/wrap_pll_config_s10.c| 3 +- > >>> board/intel/soc64/fit_spl_atf.sh | 92 > >> > >> The patch > >> > >> commit f4a43d292527ac671dee616ac973899d90a43401 > >> Author: Simon Glass > >> AuthorDate: Sun Jul 19 13:56:11 2020 -0600 > >> Commit: Simon Glass > >> CommitDate: Tue Jul 28 19:30:39 2020 -0600 > >> > >> Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR > >> > >> Add warning to migrate to binman. It means do it directly. > >> > > > > Yes, no more scripts please. > > Does that mean we now have more, additional dependencies, instead of > plain bourne shell ? Yes, binman is written in Python
Re: [v2, 00/16] Enable ARM Trusted Firmware for U-Boot
On Thu, Oct 01, 2020 at 08:48:44PM +0200, Marek Vasut wrote: > On 10/1/20 8:37 PM, Simon Glass wrote: > > Hi Siew, > > > > On Thu, 1 Oct 2020 at 10:52, Michal Simek wrote: > >> > >> > >> > >> On 01. 10. 20 11:15, Siew Chin Lim wrote: > >>> This is the 2nd version of patchset to Enable ARM Trusted Firmware > >>> for U-Boot. > >>> > >>> 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) > >>> > >>> Patch status: > >>> Have changes: Patch 2, 8, 9, 10, 11, 16 > >>> Other patches unchanged. > >>> > >>> Detail changelog can find in commit message. > >>> > >>> v1->v2: > >>> > >>> Patch 2: > >>> - Move soc64 folder from board/altera to board/intel folder > >>> > >>> Patch 8: > >>> - Updated comments > >>> > >>> Patch 9: > >>> - Code clean up without functionality change > >>> > >>> Patch 10: > >>> - Code clean up without functionality change > >>> > >>> Patch 11: > >>> - Print error message and return instead of hang in > >>> socfpga_bridges_reset() > >>> when SMC call is failing. > >>> > >>> Patch 16: > >>> - Add CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200 > >>> - Move board/altera/soc64/fit_spl_atf.sh to > >>> board/intel/soc64/fit_spl_atf.sh > >>> > >>> History: > >>> > >>> [v1]: https://patchwork.ozlabs.org/project/uboot/list/?series=195854 > >>> > >>> > >>> 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 | 13 + > >>> arch/arm/mach-socfpga/smc_api.c| 56 ++ > >>> arch/arm/mach-socfpga/wrap_pll_config_s10.c| 3 +- > >>> board/intel/soc64/fit_spl_atf.sh | 92 > >> > >> The patch > >> > >> commit f4a43d292527ac671dee616ac973899d90a43401 > >> Author: Simon Glass > >> AuthorDate: Sun Jul 19 13:56:11 2020 -0600 > >> Commit: Simon Glass > >> CommitDate: Tue Jul 28 19:30:39 2020 -0600 > >> > >> Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR > >> > >> Add warning to migrate to binman. It means do it directly. > >> > > > > Yes, no more scripts please. > > Does that mean we now have more, additional dependencies, instead of > plain bourne shell ? Yes, it means the tools we pro
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On 10/1/20 8:51 PM, Tom Rini wrote: > On Thu, Oct 01, 2020 at 08:46:56PM +0200, Marek Vasut wrote: >> On 10/1/20 8:42 PM, Adam Ford wrote: >>> On Thu, Oct 1, 2020 at 1:28 PM Tom Rini wrote: >>> On Thu, Oct 01, 2020 at 01:22:37PM -0500, Adam Ford wrote: > On Thu, Oct 1, 2020 at 1:17 PM Tom Rini wrote: > >> On Thu, Oct 01, 2020 at 07:48:32PM +0200, Marek Vasut wrote: >>> On 10/1/20 4:09 PM, Tom Rini wrote: On Tue, Aug 18, 2020 at 08:19:02AM -0500, Adam Ford wrote: > The ethernet controller can read the MAC from EEPROM and display it, > but if ethaddr is not set, the ethernet is still unavailable. > > This patch checks will automatically set the MAC address if it has > not already been set. > > Signed-off-by: Adam Ford > Acked-by: Joe Hershberger Applied to u-boot/next, thanks! >>> >>> Note that this breaks every single setup where smc911x is not primary >>> ethernet. On systems where smc911x is secondary ethernet, you need to >>> set eth1addr and so on, so please do fix that. >>> >>> Also, this kind of ethXaddr update should happen in the ethernet core >>> instead, drivers shouldn't really modify environment, no ? >> >> Interesting points. So, if smc911x is not the primary ether device, >> something else will have already set "ethaddr", most likely. We do have >> both the common case where "ethaddr" (and "eth1addr" and so forth) are >> set. >> >> Adam, when exactly did you run in to the case where ethaddr wasn't set >> correctly? Was it on a non-DM_ETH case? To Marek's last point, we do >> have drivers that set ethaddr/ethXaddr, but that's in the non-DM_ETH >> case. >> > > The only situation I tested was with DM_ETH since I thought it was going to > be a requirement by 2020.07. If ethaddr is already set, it shouldn't > override it, but I can see an issue where using the SMC911x as a secondary > controller may cause an issue because the driver at this level doesn't know. > > It seems like there should be a way to determine if the MAC address is > readable so the user doesn't need to enter it manually, but it's probably > not at the driver level based on the feedback. > > If you want to revert this patch, I won't object. I don't really have time > to develop a better one right now. Well, wait. Did you encounter a case where "ethaddr" was not automatically correctly set? A quick skim of the driver and it looks like it's doing everything needed for the common code to set "ethaddr" correctly from enetaddr the driver probed. Thanks! >>> >>> I haven't tried lately, but when booting the Logic PD OMAP3 boards, I was >>> seeing a message displaying the MAC address while simultaneously showing >>> the message that it didn't have an address, so DHCP calls would fail. I >>> could confirm that ethaddr was not set. However, if I manually set the >>> ethaddr to the value dumped by the SMC911x driver, save the environmental >>> variables then reset the board, the ethernet would work. It seemed like >>> the area where the SMC911x displayed the MAC address made sense to update >>> it since it just finished fetching it. so that's why I set up the patch the >>> way it was. I hadn't considered a use case where it wasn't the primary >>> ethernet controller. >> >> Unless there is something else broken, the driver does provide a >> callback to pull ethernet address from the EEPROM already, and that >> should permit the driver core to set ethXaddr. So can you please debug >> that, why it is not happening on your board, instead of adding the >> current workaround ? > > It does sound like something more fundamental is broken in that > particular setup if the generic code path in net/net-uclass.c to set > "ethaddr"/etc as appropriate is not called. I will revert this for now, > as you said. Thanks! That's fine, but it would be good to figure out what was broken in that other setup too.
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On Thu, Oct 01, 2020 at 08:46:56PM +0200, Marek Vasut wrote: > On 10/1/20 8:42 PM, Adam Ford wrote: > > On Thu, Oct 1, 2020 at 1:28 PM Tom Rini wrote: > > > >> On Thu, Oct 01, 2020 at 01:22:37PM -0500, Adam Ford wrote: > >>> On Thu, Oct 1, 2020 at 1:17 PM Tom Rini wrote: > >>> > On Thu, Oct 01, 2020 at 07:48:32PM +0200, Marek Vasut wrote: > > On 10/1/20 4:09 PM, Tom Rini wrote: > >> On Tue, Aug 18, 2020 at 08:19:02AM -0500, Adam Ford wrote: > >> > >>> The ethernet controller can read the MAC from EEPROM and display > >> it, > >>> but if ethaddr is not set, the ethernet is still unavailable. > >>> > >>> This patch checks will automatically set the MAC address if it has > >>> not already been set. > >>> > >>> Signed-off-by: Adam Ford > >>> Acked-by: Joe Hershberger > >> > >> Applied to u-boot/next, thanks! > > > > Note that this breaks every single setup where smc911x is not primary > > ethernet. On systems where smc911x is secondary ethernet, you need to > > set eth1addr and so on, so please do fix that. > > > > Also, this kind of ethXaddr update should happen in the ethernet core > > instead, drivers shouldn't really modify environment, no ? > > Interesting points. So, if smc911x is not the primary ether device, > something else will have already set "ethaddr", most likely. We do > >> have > both the common case where "ethaddr" (and "eth1addr" and so forth) are > set. > > Adam, when exactly did you run in to the case where ethaddr wasn't set > correctly? Was it on a non-DM_ETH case? To Marek's last point, we do > have drivers that set ethaddr/ethXaddr, but that's in the non-DM_ETH > case. > > >>> > >>> The only situation I tested was with DM_ETH since I thought it was going > >> to > >>> be a requirement by 2020.07. If ethaddr is already set, it shouldn't > >>> override it, but I can see an issue where using the SMC911x as a > >> secondary > >>> controller may cause an issue because the driver at this level doesn't > >> know. > >>> > >>> It seems like there should be a way to determine if the MAC address is > >>> readable so the user doesn't need to enter it manually, but it's probably > >>> not at the driver level based on the feedback. > >>> > >>> If you want to revert this patch, I won't object. I don't really have > >> time > >>> to develop a better one right now. > >> > >> Well, wait. Did you encounter a case where "ethaddr" was not > >> automatically correctly set? A quick skim of the driver and it looks > >> like it's doing everything needed for the common code to set "ethaddr" > >> correctly from enetaddr the driver probed. Thanks! > >> > > > > I haven't tried lately, but when booting the Logic PD OMAP3 boards, I was > > seeing a message displaying the MAC address while simultaneously showing > > the message that it didn't have an address, so DHCP calls would fail. I > > could confirm that ethaddr was not set. However, if I manually set the > > ethaddr to the value dumped by the SMC911x driver, save the environmental > > variables then reset the board, the ethernet would work. It seemed like > > the area where the SMC911x displayed the MAC address made sense to update > > it since it just finished fetching it. so that's why I set up the patch the > > way it was. I hadn't considered a use case where it wasn't the primary > > ethernet controller. > > Unless there is something else broken, the driver does provide a > callback to pull ethernet address from the EEPROM already, and that > should permit the driver core to set ethXaddr. So can you please debug > that, why it is not happening on your board, instead of adding the > current workaround ? It does sound like something more fundamental is broken in that particular setup if the generic code path in net/net-uclass.c to set "ethaddr"/etc as appropriate is not called. I will revert this for now, as you said. Thanks! -- Tom signature.asc Description: PGP signature
Re: [v2, 00/16] Enable ARM Trusted Firmware for U-Boot
On 10/1/20 8:37 PM, Simon Glass wrote: > Hi Siew, > > On Thu, 1 Oct 2020 at 10:52, Michal Simek wrote: >> >> >> >> On 01. 10. 20 11:15, Siew Chin Lim wrote: >>> This is the 2nd version of patchset to Enable ARM Trusted Firmware >>> for U-Boot. >>> >>> 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) >>> >>> Patch status: >>> Have changes: Patch 2, 8, 9, 10, 11, 16 >>> Other patches unchanged. >>> >>> Detail changelog can find in commit message. >>> >>> v1->v2: >>> >>> Patch 2: >>> - Move soc64 folder from board/altera to board/intel folder >>> >>> Patch 8: >>> - Updated comments >>> >>> Patch 9: >>> - Code clean up without functionality change >>> >>> Patch 10: >>> - Code clean up without functionality change >>> >>> Patch 11: >>> - Print error message and return instead of hang in socfpga_bridges_reset() >>> when SMC call is failing. >>> >>> Patch 16: >>> - Add CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200 >>> - Move board/altera/soc64/fit_spl_atf.sh to board/intel/soc64/fit_spl_atf.sh >>> >>> History: >>> >>> [v1]: https://patchwork.ozlabs.org/project/uboot/list/?series=195854 >>> >>> >>> 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 | 13 + >>> arch/arm/mach-socfpga/smc_api.c| 56 ++ >>> arch/arm/mach-socfpga/wrap_pll_config_s10.c| 3 +- >>> board/intel/soc64/fit_spl_atf.sh | 92 >> >> The patch >> >> commit f4a43d292527ac671dee616ac973899d90a43401 >> Author: Simon Glass >> AuthorDate: Sun Jul 19 13:56:11 2020 -0600 >> Commit: Simon Glass >> CommitDate: Tue Jul 28 19:30:39 2020 -0600 >> >> Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR >> >> Add warning to migrate to binman. It means do it directly. >> > > Yes, no more scripts please. Does that mean we now have more, additional dependencies, instead of plain bourne shell ?
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On 10/1/20 8:42 PM, Adam Ford wrote: > On Thu, Oct 1, 2020 at 1:28 PM Tom Rini wrote: > >> On Thu, Oct 01, 2020 at 01:22:37PM -0500, Adam Ford wrote: >>> On Thu, Oct 1, 2020 at 1:17 PM Tom Rini wrote: >>> On Thu, Oct 01, 2020 at 07:48:32PM +0200, Marek Vasut wrote: > On 10/1/20 4:09 PM, Tom Rini wrote: >> On Tue, Aug 18, 2020 at 08:19:02AM -0500, Adam Ford wrote: >> >>> The ethernet controller can read the MAC from EEPROM and display >> it, >>> but if ethaddr is not set, the ethernet is still unavailable. >>> >>> This patch checks will automatically set the MAC address if it has >>> not already been set. >>> >>> Signed-off-by: Adam Ford >>> Acked-by: Joe Hershberger >> >> Applied to u-boot/next, thanks! > > Note that this breaks every single setup where smc911x is not primary > ethernet. On systems where smc911x is secondary ethernet, you need to > set eth1addr and so on, so please do fix that. > > Also, this kind of ethXaddr update should happen in the ethernet core > instead, drivers shouldn't really modify environment, no ? Interesting points. So, if smc911x is not the primary ether device, something else will have already set "ethaddr", most likely. We do >> have both the common case where "ethaddr" (and "eth1addr" and so forth) are set. Adam, when exactly did you run in to the case where ethaddr wasn't set correctly? Was it on a non-DM_ETH case? To Marek's last point, we do have drivers that set ethaddr/ethXaddr, but that's in the non-DM_ETH case. >>> >>> The only situation I tested was with DM_ETH since I thought it was going >> to >>> be a requirement by 2020.07. If ethaddr is already set, it shouldn't >>> override it, but I can see an issue where using the SMC911x as a >> secondary >>> controller may cause an issue because the driver at this level doesn't >> know. >>> >>> It seems like there should be a way to determine if the MAC address is >>> readable so the user doesn't need to enter it manually, but it's probably >>> not at the driver level based on the feedback. >>> >>> If you want to revert this patch, I won't object. I don't really have >> time >>> to develop a better one right now. >> >> Well, wait. Did you encounter a case where "ethaddr" was not >> automatically correctly set? A quick skim of the driver and it looks >> like it's doing everything needed for the common code to set "ethaddr" >> correctly from enetaddr the driver probed. Thanks! >> > > I haven't tried lately, but when booting the Logic PD OMAP3 boards, I was > seeing a message displaying the MAC address while simultaneously showing > the message that it didn't have an address, so DHCP calls would fail. I > could confirm that ethaddr was not set. However, if I manually set the > ethaddr to the value dumped by the SMC911x driver, save the environmental > variables then reset the board, the ethernet would work. It seemed like > the area where the SMC911x displayed the MAC address made sense to update > it since it just finished fetching it. so that's why I set up the patch the > way it was. I hadn't considered a use case where it wasn't the primary > ethernet controller. Unless there is something else broken, the driver does provide a callback to pull ethernet address from the EEPROM already, and that should permit the driver core to set ethXaddr. So can you please debug that, why it is not happening on your board, instead of adding the current workaround ?
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On Thu, Oct 1, 2020 at 1:28 PM Tom Rini wrote: > On Thu, Oct 01, 2020 at 01:22:37PM -0500, Adam Ford wrote: > > On Thu, Oct 1, 2020 at 1:17 PM Tom Rini wrote: > > > > > On Thu, Oct 01, 2020 at 07:48:32PM +0200, Marek Vasut wrote: > > > > On 10/1/20 4:09 PM, Tom Rini wrote: > > > > > On Tue, Aug 18, 2020 at 08:19:02AM -0500, Adam Ford wrote: > > > > > > > > > >> The ethernet controller can read the MAC from EEPROM and display > it, > > > > >> but if ethaddr is not set, the ethernet is still unavailable. > > > > >> > > > > >> This patch checks will automatically set the MAC address if it has > > > > >> not already been set. > > > > >> > > > > >> Signed-off-by: Adam Ford > > > > >> Acked-by: Joe Hershberger > > > > > > > > > > Applied to u-boot/next, thanks! > > > > > > > > Note that this breaks every single setup where smc911x is not primary > > > > ethernet. On systems where smc911x is secondary ethernet, you need to > > > > set eth1addr and so on, so please do fix that. > > > > > > > > Also, this kind of ethXaddr update should happen in the ethernet core > > > > instead, drivers shouldn't really modify environment, no ? > > > > > > Interesting points. So, if smc911x is not the primary ether device, > > > something else will have already set "ethaddr", most likely. We do > have > > > both the common case where "ethaddr" (and "eth1addr" and so forth) are > > > set. > > > > > > Adam, when exactly did you run in to the case where ethaddr wasn't set > > > correctly? Was it on a non-DM_ETH case? To Marek's last point, we do > > > have drivers that set ethaddr/ethXaddr, but that's in the non-DM_ETH > > > case. > > > > > > > The only situation I tested was with DM_ETH since I thought it was going > to > > be a requirement by 2020.07. If ethaddr is already set, it shouldn't > > override it, but I can see an issue where using the SMC911x as a > secondary > > controller may cause an issue because the driver at this level doesn't > know. > > > > It seems like there should be a way to determine if the MAC address is > > readable so the user doesn't need to enter it manually, but it's probably > > not at the driver level based on the feedback. > > > > If you want to revert this patch, I won't object. I don't really have > time > > to develop a better one right now. > > Well, wait. Did you encounter a case where "ethaddr" was not > automatically correctly set? A quick skim of the driver and it looks > like it's doing everything needed for the common code to set "ethaddr" > correctly from enetaddr the driver probed. Thanks! > I haven't tried lately, but when booting the Logic PD OMAP3 boards, I was seeing a message displaying the MAC address while simultaneously showing the message that it didn't have an address, so DHCP calls would fail. I could confirm that ethaddr was not set. However, if I manually set the ethaddr to the value dumped by the SMC911x driver, save the environmental variables then reset the board, the ethernet would work. It seemed like the area where the SMC911x displayed the MAC address made sense to update it since it just finished fetching it. so that's why I set up the patch the way it was. I hadn't considered a use case where it wasn't the primary ethernet controller. adam > > -- > Tom >
[PATCH] ram: rockchip: px30: add a config-based ddr selection
From: Heiko Stuebner
The SRAM on the PX30 is not big enough to hold multiple DDR configs
so it needs to be selected during build.
So far simply the DDR3 config was always selected and getting DDR4
or LPDDR2/3 initialized would require a code modification.
So add Kconfig options similar to RK3399 to allow selecting the DDR4
and LPDDR2/3 options instead, while DDR3 stays the default as before.
Signed-off-by: Heiko Stuebner
---
drivers/ram/rockchip/Kconfig | 21 +
drivers/ram/rockchip/sdram_px30.c | 8
2 files changed, 29 insertions(+)
diff --git a/drivers/ram/rockchip/Kconfig b/drivers/ram/rockchip/Kconfig
index 8e97c2f49e..c459bbf5e2 100644
--- a/drivers/ram/rockchip/Kconfig
+++ b/drivers/ram/rockchip/Kconfig
@@ -22,6 +22,27 @@ config RAM_ROCKCHIP_DEBUG
This is an option for developers to understand the ram drivers
initialization, configurations and etc.
+config RAM_PX30_DDR4
+ bool "DDR3 support for Rockchip PX30"
+ depends on RAM_ROCKCHIP && ROCKCHIP_PX30
+ help
+ This enables DDR4 sdram support instead of the default DDR3 support
+ on Rockchip PC30 SoCs.
+
+config RAM_PX30_LPDDR2
+ bool "LPDDR2 support for Rockchip PX30"
+ depends on RAM_ROCKCHIP && ROCKCHIP_PX30
+ help
+ This enables LPDDR2 sdram support instead of the default DDR3 support
+ on Rockchip PC30 SoCs.
+
+config RAM_PX30_LPDDR3
+ bool "LPDDR3 support for Rockchip PX30"
+ depends on RAM_ROCKCHIP && ROCKCHIP_PX30
+ help
+ This enables LPDDR3 sdram support instead of the default DDR3 support
+ on Rockchip PC30 SoCs.
+
config RAM_RK3399_LPDDR4
bool "LPDDR4 support for Rockchip RK3399"
depends on RAM_ROCKCHIP && ROCKCHIP_RK3399
diff --git a/drivers/ram/rockchip/sdram_px30.c
b/drivers/ram/rockchip/sdram_px30.c
index fd5763d0a0..2f1f6e9c0c 100644
--- a/drivers/ram/rockchip/sdram_px30.c
+++ b/drivers/ram/rockchip/sdram_px30.c
@@ -125,7 +125,15 @@ u32 addrmap[][8] = {
struct dram_info dram_info;
struct px30_sdram_params sdram_configs[] = {
+#if defined(CONFIG_RAM_PX30_DDR4)
+#include "sdram-px30-ddr4-detect-333.inc"
+#elif defined(CONFIG_RAM_PX30_LPDDR2)
+#include "sdram-px30-lpddr2-detect-333.inc"
+#elif defined(CONFIG_RAM_PX30_LPDDR3)
+#include "sdram-px30-lpddr3-detect-333.inc"
+#else
#include "sdram-px30-ddr3-detect-333.inc"
+#endif
};
struct ddr_phy_skew skew = {
--
2.28.0
Re: [PULL] u-boot-usb/next
This is without the DWC2 patch. The following changes since commit 26acc6395fee680cea72e51348bd59e206eb0464: Merge branch '2020-09-30-assorted-network-improvements' into next (2020-10-01 09:46:10 -0400) are available in the Git repository at: git://git.denx.de/u-boot-usb.git next for you to fetch changes up to e15e817f3eb13dd4b58f465b009164ecd8b997cf: usb: xhci-rcar: Add support for R8A774A1 SoC (2020-10-01 19:43:05 +0200) Chunfeng Yun (9): usb: xhci: add a member hci_version in xhci_ctrl struct usb: xhci: create one unified function to calculate TRB TD remainder usb: xhci: add quirks flag to support MediaTek xHCI 0.96 usb: xhci: convert to HCS_MAX_PORTS() usb: xhci: convert to TRB_TYPE() usb: xhci: convert to TRB_LEN() and TRB_INTR_TARGET() usb: xhci: convert to TRB_TX_TYPE() usb: xhci: use macros with parameter to fill ep_info2 usb: xhci: convert to readx_poll_sleep_timeout() Lad Prabhakar (1): usb: xhci-rcar: Add support for R8A774A1 SoC drivers/usb/host/xhci-mem.c | 18 +- drivers/usb/host/xhci-mtk.c | 1 + drivers/usb/host/xhci-rcar.c | 1 + drivers/usb/host/xhci-ring.c | 141 +++- drivers/usb/host/xhci.c | 37 include/usb/xhci.h | 18 -- 6 files changed, 98 insertions(+), 118 deletions(-)
Re: [v2, 00/16] Enable ARM Trusted Firmware for U-Boot
Hi Siew, On Thu, 1 Oct 2020 at 10:52, Michal Simek wrote: > > > > On 01. 10. 20 11:15, Siew Chin Lim wrote: > > This is the 2nd version of patchset to Enable ARM Trusted Firmware > > for U-Boot. > > > > 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) > > > > Patch status: > > Have changes: Patch 2, 8, 9, 10, 11, 16 > > Other patches unchanged. > > > > Detail changelog can find in commit message. > > > > v1->v2: > > > > Patch 2: > > - Move soc64 folder from board/altera to board/intel folder > > > > Patch 8: > > - Updated comments > > > > Patch 9: > > - Code clean up without functionality change > > > > Patch 10: > > - Code clean up without functionality change > > > > Patch 11: > > - Print error message and return instead of hang in socfpga_bridges_reset() > > when SMC call is failing. > > > > Patch 16: > > - Add CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200 > > - Move board/altera/soc64/fit_spl_atf.sh to board/intel/soc64/fit_spl_atf.sh > > > > History: > > > > [v1]: https://patchwork.ozlabs.org/project/uboot/list/?series=195854 > > > > > > 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 | 13 + > > arch/arm/mach-socfpga/smc_api.c| 56 ++ > > arch/arm/mach-socfpga/wrap_pll_config_s10.c| 3 +- > > board/intel/soc64/fit_spl_atf.sh | 92 > > The patch > > commit f4a43d292527ac671dee616ac973899d90a43401 > Author: Simon Glass > AuthorDate: Sun Jul 19 13:56:11 2020 -0600 > Commit: Simon Glass > CommitDate: Tue Jul 28 19:30:39 2020 -0600 > > Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR > > Add warning to migrate to binman. It means do it directly. > Yes, no more scripts please. Let me know if you need help. Regards, Simon
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On Thu, Oct 01, 2020 at 01:22:37PM -0500, Adam Ford wrote: > On Thu, Oct 1, 2020 at 1:17 PM Tom Rini wrote: > > > On Thu, Oct 01, 2020 at 07:48:32PM +0200, Marek Vasut wrote: > > > On 10/1/20 4:09 PM, Tom Rini wrote: > > > > On Tue, Aug 18, 2020 at 08:19:02AM -0500, Adam Ford wrote: > > > > > > > >> The ethernet controller can read the MAC from EEPROM and display it, > > > >> but if ethaddr is not set, the ethernet is still unavailable. > > > >> > > > >> This patch checks will automatically set the MAC address if it has > > > >> not already been set. > > > >> > > > >> Signed-off-by: Adam Ford > > > >> Acked-by: Joe Hershberger > > > > > > > > Applied to u-boot/next, thanks! > > > > > > Note that this breaks every single setup where smc911x is not primary > > > ethernet. On systems where smc911x is secondary ethernet, you need to > > > set eth1addr and so on, so please do fix that. > > > > > > Also, this kind of ethXaddr update should happen in the ethernet core > > > instead, drivers shouldn't really modify environment, no ? > > > > Interesting points. So, if smc911x is not the primary ether device, > > something else will have already set "ethaddr", most likely. We do have > > both the common case where "ethaddr" (and "eth1addr" and so forth) are > > set. > > > > Adam, when exactly did you run in to the case where ethaddr wasn't set > > correctly? Was it on a non-DM_ETH case? To Marek's last point, we do > > have drivers that set ethaddr/ethXaddr, but that's in the non-DM_ETH > > case. > > > > The only situation I tested was with DM_ETH since I thought it was going to > be a requirement by 2020.07. If ethaddr is already set, it shouldn't > override it, but I can see an issue where using the SMC911x as a secondary > controller may cause an issue because the driver at this level doesn't know. > > It seems like there should be a way to determine if the MAC address is > readable so the user doesn't need to enter it manually, but it's probably > not at the driver level based on the feedback. > > If you want to revert this patch, I won't object. I don't really have time > to develop a better one right now. Well, wait. Did you encounter a case where "ethaddr" was not automatically correctly set? A quick skim of the driver and it looks like it's doing everything needed for the common code to set "ethaddr" correctly from enetaddr the driver probed. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On Thu, Oct 1, 2020 at 1:17 PM Tom Rini wrote: > On Thu, Oct 01, 2020 at 07:48:32PM +0200, Marek Vasut wrote: > > On 10/1/20 4:09 PM, Tom Rini wrote: > > > On Tue, Aug 18, 2020 at 08:19:02AM -0500, Adam Ford wrote: > > > > > >> The ethernet controller can read the MAC from EEPROM and display it, > > >> but if ethaddr is not set, the ethernet is still unavailable. > > >> > > >> This patch checks will automatically set the MAC address if it has > > >> not already been set. > > >> > > >> Signed-off-by: Adam Ford > > >> Acked-by: Joe Hershberger > > > > > > Applied to u-boot/next, thanks! > > > > Note that this breaks every single setup where smc911x is not primary > > ethernet. On systems where smc911x is secondary ethernet, you need to > > set eth1addr and so on, so please do fix that. > > > > Also, this kind of ethXaddr update should happen in the ethernet core > > instead, drivers shouldn't really modify environment, no ? > > Interesting points. So, if smc911x is not the primary ether device, > something else will have already set "ethaddr", most likely. We do have > both the common case where "ethaddr" (and "eth1addr" and so forth) are > set. > > Adam, when exactly did you run in to the case where ethaddr wasn't set > correctly? Was it on a non-DM_ETH case? To Marek's last point, we do > have drivers that set ethaddr/ethXaddr, but that's in the non-DM_ETH > case. > The only situation I tested was with DM_ETH since I thought it was going to be a requirement by 2020.07. If ethaddr is already set, it shouldn't override it, but I can see an issue where using the SMC911x as a secondary controller may cause an issue because the driver at this level doesn't know. It seems like there should be a way to determine if the MAC address is readable so the user doesn't need to enter it manually, but it's probably not at the driver level based on the feedback. If you want to revert this patch, I won't object. I don't really have time to develop a better one right now. adam > > Thanks! > > -- > Tom >
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On Thu, Oct 01, 2020 at 07:48:32PM +0200, Marek Vasut wrote: > On 10/1/20 4:09 PM, Tom Rini wrote: > > On Tue, Aug 18, 2020 at 08:19:02AM -0500, Adam Ford wrote: > > > >> The ethernet controller can read the MAC from EEPROM and display it, > >> but if ethaddr is not set, the ethernet is still unavailable. > >> > >> This patch checks will automatically set the MAC address if it has > >> not already been set. > >> > >> Signed-off-by: Adam Ford > >> Acked-by: Joe Hershberger > > > > Applied to u-boot/next, thanks! > > Note that this breaks every single setup where smc911x is not primary > ethernet. On systems where smc911x is secondary ethernet, you need to > set eth1addr and so on, so please do fix that. > > Also, this kind of ethXaddr update should happen in the ethernet core > instead, drivers shouldn't really modify environment, no ? Interesting points. So, if smc911x is not the primary ether device, something else will have already set "ethaddr", most likely. We do have both the common case where "ethaddr" (and "eth1addr" and so forth) are set. Adam, when exactly did you run in to the case where ethaddr wasn't set correctly? Was it on a non-DM_ETH case? To Marek's last point, we do have drivers that set ethaddr/ethXaddr, but that's in the non-DM_ETH case. Thanks! -- Tom signature.asc Description: PGP signature
Re: [PULL] u-boot-usb/next
On Thu, Oct 01, 2020 at 07:42:51PM +0200, Marek Vasut wrote:
> On 10/1/20 7:09 PM, Tom Rini wrote:
> > On Thu, Oct 01, 2020 at 10:29:11AM +0200, Marek Vasut wrote:
> >
> >> The following changes since commit
> >> ae52e75d23ce11f36b3eae758045da95a871f263:
> >>
> >> Merge tag 'for-v2021.01-next' of
> >> https://gitlab.denx.de/u-boot/custodians/u-boot-i2c into next
> >> (2020-09-17 09:55:01 -0400)
> >>
> >> are available in the Git repository at:
> >>
> >> git://git.denx.de/u-boot-usb.git next
> >>
> >> for you to fetch changes up to 4fb50766433626f4d57e7491e638bc55d80badef:
> >>
> >> usb: xhci-rcar: Add support for R8A774A1 SoC (2020-09-22 13:40:27 +0200)
> >>
> >
> > NAK. Introduces a failure to build on:
>
> Interesting, this must be new.
Hmm? 4fb507664336 has this fail to build.
> > rpi_4 poplar odroid-c4 odroid-n2 khadas-vim libretech-ac libretech-cc
> > khadas-vim2 libretech-s905d-pc libretech-s912-pc sei510 sei610 u200
> > khadas-vim3 khadas-vim3l odroid-go2 evb-px30 firefly-px30 roc-cc-rk3308
> > evb-rk3308 evb-rk3328 roc-cc-rk3328 rock-pi-e-rk3328 rock64-rk3328
> > such as:
> > +(rpi_4) drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c: In function
> > 'process_ep_out_intr':
> > +(rpi_4) drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c:425:18: error: cast
> > from pointer to integer of different size [-Werror=pointer-to-int-cast]
> > +(rpi_4) 425 | u32 epsiz_reg = (u32)®->out_endp[ep_num].doeptsiz;
> > +(rpi_4) | ^
> > +(rpi_4) In file included from drivers/usb/gadget/dwc2_udc_otg.c:42:
> > +(rpi_4) arch/arm/include/asm/io.h:45:28: error: cast to pointer from
> > integer of different size [-Werror=int-to-pointer-cast]
> > +(rpi_4)45 | #define __arch_getl(a) (*(volatile unsigned int *)(a))
> > +(rpi_4) |^
> > +(rpi_4) arch/arm/include/asm/io.h:127:31: note: in expansion of macro
> > '__arch_getl'
> > +(rpi_4) 127 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb();
> > __v; })
> > +(rpi_4) | ^~~
> > +(rpi_4) drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c:447:15: note: in
> > expansion of macro 'readl'
> > +(rpi_4) 447 | ep_tsr = readl(epsiz_reg);
> > +(rpi_4) | ^
> > +(rpi_4) cc1: all warnings being treated as errors
> > +(rpi_4) make[2]: *** [drivers/usb/gadget/dwc2_udc_otg.o] Error 1
> > +(rpi_4) make[1]: *** [drivers/usb/gadget] Error 2
> > +(rpi_4) make: *** [sub-make] Error 2
> >
> > Since you'll have to dig in here anyhow, there's also a typo in the
> > commit message of:
> > commit d033774655ee4dd7b3fc45bc5273b8c7a892a5b2
> > Author: Chance.Yang
> > Date: Tue Sep 22 16:48:42 2020 +0800
> >
> > usb: dwc2: Fix contorl OUT transfer issue
>
> It would be useful to CC the author of that patch.
> I will drop the patch for now and wait for a fixed one.
... it is likely that the patch I flagged only because of the typo is
also the patch that introduced breakage, in hindsight.
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On 10/1/20 4:09 PM, Tom Rini wrote: > On Tue, Aug 18, 2020 at 08:19:02AM -0500, Adam Ford wrote: > >> The ethernet controller can read the MAC from EEPROM and display it, >> but if ethaddr is not set, the ethernet is still unavailable. >> >> This patch checks will automatically set the MAC address if it has >> not already been set. >> >> Signed-off-by: Adam Ford >> Acked-by: Joe Hershberger > > Applied to u-boot/next, thanks! Note that this breaks every single setup where smc911x is not primary ethernet. On systems where smc911x is secondary ethernet, you need to set eth1addr and so on, so please do fix that. Also, this kind of ethXaddr update should happen in the ethernet core instead, drivers shouldn't really modify environment, no ?
Re: [PULL] u-boot-usb/next
On 10/1/20 7:09 PM, Tom Rini wrote:
> On Thu, Oct 01, 2020 at 10:29:11AM +0200, Marek Vasut wrote:
>
>> The following changes since commit ae52e75d23ce11f36b3eae758045da95a871f263:
>>
>> Merge tag 'for-v2021.01-next' of
>> https://gitlab.denx.de/u-boot/custodians/u-boot-i2c into next
>> (2020-09-17 09:55:01 -0400)
>>
>> are available in the Git repository at:
>>
>> git://git.denx.de/u-boot-usb.git next
>>
>> for you to fetch changes up to 4fb50766433626f4d57e7491e638bc55d80badef:
>>
>> usb: xhci-rcar: Add support for R8A774A1 SoC (2020-09-22 13:40:27 +0200)
>>
>
> NAK. Introduces a failure to build on:
Interesting, this must be new.
> rpi_4 poplar odroid-c4 odroid-n2 khadas-vim libretech-ac libretech-cc
> khadas-vim2 libretech-s905d-pc libretech-s912-pc sei510 sei610 u200
> khadas-vim3 khadas-vim3l odroid-go2 evb-px30 firefly-px30 roc-cc-rk3308
> evb-rk3308 evb-rk3328 roc-cc-rk3328 rock-pi-e-rk3328 rock64-rk3328
> such as:
> +(rpi_4) drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c: In function
> 'process_ep_out_intr':
> +(rpi_4) drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c:425:18: error: cast from
> pointer to integer of different size [-Werror=pointer-to-int-cast]
> +(rpi_4) 425 | u32 epsiz_reg = (u32)®->out_endp[ep_num].doeptsiz;
> +(rpi_4) | ^
> +(rpi_4) In file included from drivers/usb/gadget/dwc2_udc_otg.c:42:
> +(rpi_4) arch/arm/include/asm/io.h:45:28: error: cast to pointer from integer
> of different size [-Werror=int-to-pointer-cast]
> +(rpi_4)45 | #define __arch_getl(a) (*(volatile unsigned int *)(a))
> +(rpi_4) |^
> +(rpi_4) arch/arm/include/asm/io.h:127:31: note: in expansion of macro
> '__arch_getl'
> +(rpi_4) 127 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb();
> __v; })
> +(rpi_4) | ^~~
> +(rpi_4) drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c:447:15: note: in
> expansion of macro 'readl'
> +(rpi_4) 447 | ep_tsr = readl(epsiz_reg);
> +(rpi_4) | ^
> +(rpi_4) cc1: all warnings being treated as errors
> +(rpi_4) make[2]: *** [drivers/usb/gadget/dwc2_udc_otg.o] Error 1
> +(rpi_4) make[1]: *** [drivers/usb/gadget] Error 2
> +(rpi_4) make: *** [sub-make] Error 2
>
> Since you'll have to dig in here anyhow, there's also a typo in the
> commit message of:
> commit d033774655ee4dd7b3fc45bc5273b8c7a892a5b2
> Author: Chance.Yang
> Date: Tue Sep 22 16:48:42 2020 +0800
>
> usb: dwc2: Fix contorl OUT transfer issue
It would be useful to CC the author of that patch.
I will drop the patch for now and wait for a fixed one.
Re: [PULL] u-boot-usb/next
On Thu, Oct 01, 2020 at 10:29:11AM +0200, Marek Vasut wrote:
> The following changes since commit ae52e75d23ce11f36b3eae758045da95a871f263:
>
> Merge tag 'for-v2021.01-next' of
> https://gitlab.denx.de/u-boot/custodians/u-boot-i2c into next
> (2020-09-17 09:55:01 -0400)
>
> are available in the Git repository at:
>
> git://git.denx.de/u-boot-usb.git next
>
> for you to fetch changes up to 4fb50766433626f4d57e7491e638bc55d80badef:
>
> usb: xhci-rcar: Add support for R8A774A1 SoC (2020-09-22 13:40:27 +0200)
>
NAK. Introduces a failure to build on:
rpi_4 poplar odroid-c4 odroid-n2 khadas-vim libretech-ac libretech-cc
khadas-vim2 libretech-s905d-pc libretech-s912-pc sei510 sei610 u200
khadas-vim3 khadas-vim3l odroid-go2 evb-px30 firefly-px30 roc-cc-rk3308
evb-rk3308 evb-rk3328 roc-cc-rk3328 rock-pi-e-rk3328 rock64-rk3328
such as:
+(rpi_4) drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c: In function
'process_ep_out_intr':
+(rpi_4) drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c:425:18: error: cast from
pointer to integer of different size [-Werror=pointer-to-int-cast]
+(rpi_4) 425 | u32 epsiz_reg = (u32)®->out_endp[ep_num].doeptsiz;
+(rpi_4) | ^
+(rpi_4) In file included from drivers/usb/gadget/dwc2_udc_otg.c:42:
+(rpi_4) arch/arm/include/asm/io.h:45:28: error: cast to pointer from integer
of different size [-Werror=int-to-pointer-cast]
+(rpi_4)45 | #define __arch_getl(a) (*(volatile unsigned int *)(a))
+(rpi_4) |^
+(rpi_4) arch/arm/include/asm/io.h:127:31: note: in expansion of macro
'__arch_getl'
+(rpi_4) 127 | #define readl(c) ({ u32 __v = __arch_getl(c); __iormb(); __v;
})
+(rpi_4) | ^~~
+(rpi_4) drivers/usb/gadget/dwc2_udc_otg_xfer_dma.c:447:15: note: in expansion
of macro 'readl'
+(rpi_4) 447 | ep_tsr = readl(epsiz_reg);
+(rpi_4) | ^
+(rpi_4) cc1: all warnings being treated as errors
+(rpi_4) make[2]: *** [drivers/usb/gadget/dwc2_udc_otg.o] Error 1
+(rpi_4) make[1]: *** [drivers/usb/gadget] Error 2
+(rpi_4) make: *** [sub-make] Error 2
Since you'll have to dig in here anyhow, there's also a typo in the
commit message of:
commit d033774655ee4dd7b3fc45bc5273b8c7a892a5b2
Author: Chance.Yang
Date: Tue Sep 22 16:48:42 2020 +0800
usb: dwc2: Fix contorl OUT transfer issue
Thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [v2, 00/16] Enable ARM Trusted Firmware for U-Boot
On 01. 10. 20 11:15, Siew Chin Lim wrote: > This is the 2nd version of patchset to Enable ARM Trusted Firmware > for U-Boot. > > 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) > > Patch status: > Have changes: Patch 2, 8, 9, 10, 11, 16 > Other patches unchanged. > > Detail changelog can find in commit message. > > v1->v2: > > Patch 2: > - Move soc64 folder from board/altera to board/intel folder > > Patch 8: > - Updated comments > > Patch 9: > - Code clean up without functionality change > > Patch 10: > - Code clean up without functionality change > > Patch 11: > - Print error message and return instead of hang in socfpga_bridges_reset() > when SMC call is failing. > > Patch 16: > - Add CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200 > - Move board/altera/soc64/fit_spl_atf.sh to board/intel/soc64/fit_spl_atf.sh > > History: > > [v1]: https://patchwork.ozlabs.org/project/uboot/list/?series=195854 > > > 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 | 13 + > arch/arm/mach-socfpga/smc_api.c| 56 ++ > arch/arm/mach-socfpga/wrap_pll_config_s10.c| 3 +- > board/intel/soc64/fit_spl_atf.sh | 92 The patch commit f4a43d292527ac671dee616ac973899d90a43401 Author: Simon Glass AuthorDate: Sun Jul 19 13:56:11 2020 -0600 Commit: Simon Glass CommitDate: Tue Jul 28 19:30:39 2020 -0600 Makefile: Warn against using CONFIG_SPL_FIT_GENERATOR Add warning to migrate to binman. It means do it directly. Thanks, Michal -- Michal Simek, Ing. (M.Eng), OpenPGP -> KeyID: FE3D1F91 w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel - Xilinx Microblaze Maintainer of Linux kernel - Xilinx Zynq ARM and ZynqMP ARM64 SoCs U-Boot custodian - Xilinx Microblaze/Zynq/ZynqMP/Versal SoCs
Re: IMX8MM 4GiB boundary issue
On 10/1/20 6:33 PM, Tim Harvey wrote: > On Sun, Sep 27, 2020 at 7:47 AM Marek Vasut wrote: >> >> On 9/27/20 4:35 AM, Peng Fan wrote: Subject: Re: IMX8MM 4GiB boundary issue On 9/27/20 2:56 AM, Peng Fan wrote: [...] >>> I can imagine that either the FEC/SDHCI is limited to 32bit >>> addressing in hardware (the DMA can only operate on 32bit range due >>> to it coming from 32bit systems), OR, the drivers need to be patched >>> to support the 64bit addresses properly on 64bit SoCs and 64bit >>> variants of the IPs >> >> I hadn't thought about the DMA boundary issue. I'll wait for NXP to >> weigh in before I start digging through drivers. I wonder if there is >> a simple workaround to make sure U-Boot is running in lower DRAM? I'm >> not all that clear where U-Boot gets allocated. > > The IP only support 32bits DMA, you could let U-Boot only relocated to > the end of 4GB memory address space using get_effective_memsize Surely the ARM64 core can address more than 4 GiB of DRAM, and can execute code from above the 4 GiB boundary, right ? >>> >>> Yes >>> >>> In that case, get_effective_memsize cannot be used. What you describe here is a limitation of the old IP blocks which were taken from previously 32bit SoCs and they are incapable of accessing DRAM above the 4 GiB boundary with their limited DMAs. The solution for that is to fix those drivers, e.g. by placing their buffers below the 4 GiB boundary, or by using bounce buffers if needed. Placing U-Boot below the 4 GiB boundary is NOT a solution in any way, but a broken workaround. There is still nothing preventing user from placing a buffer above the 4 GiB boundary and passing that to the driver, at which point the driver will fail (e.g. a simple "$ load mmc 0:1 0x1 file" will just fail, unless e.g. a bounce buffer is used). >>> >>> That will be several drivers need to use bounce buffer, >>> sdhc/fec/usb/nand/video. >>> Let's see how to address the drivers. >> >> R-Car had the same problem, so you can look there. > > Marek, > > Are you referring to d2661d8: mmc: tmio: sdhi: Use bounce buffer to > avoid DMA limitations Yes, but on R-Car3 this could also be solved better by using IOMMU (Linux does it). IOMMU isn't available on MX8M though, to my knowledge. > Do you know the state of the Linux kernel drivers with regards to this > issue and if there is a performance hit due to the bounce buffers? In Linux, R-Car3 uses IOMMU, so there is no performance hit on that specific hardware. On iMX8M, you would likely need to set some bit which indicates the hardware supports only 32bit DMA, so the DMA buffers would be allocated below the 32bit barrier, also no big problem. I think it is one of the DMA flags, DMA_BIT_MASK(32) or so.
Re: IMX8MM 4GiB boundary issue
On Sun, Sep 27, 2020 at 7:47 AM Marek Vasut wrote: > > On 9/27/20 4:35 AM, Peng Fan wrote: > >> Subject: Re: IMX8MM 4GiB boundary issue > >> > >> On 9/27/20 2:56 AM, Peng Fan wrote: > >> > >> [...] > >> > > I can imagine that either the FEC/SDHCI is limited to 32bit > > addressing in hardware (the DMA can only operate on 32bit range due > > to it coming from 32bit systems), OR, the drivers need to be patched > > to support the 64bit addresses properly on 64bit SoCs and 64bit > > variants of the IPs > > I hadn't thought about the DMA boundary issue. I'll wait for NXP to > weigh in before I start digging through drivers. I wonder if there is > a simple workaround to make sure U-Boot is running in lower DRAM? I'm > not all that clear where U-Boot gets allocated. > >>> > >>> The IP only support 32bits DMA, you could let U-Boot only relocated to > >>> the end of 4GB memory address space using get_effective_memsize > >> > >> Surely the ARM64 core can address more than 4 GiB of DRAM, and can > >> execute code from above the 4 GiB boundary, right ? > > > > Yes > > > > In that case, > >> get_effective_memsize cannot be used. > >> > >> What you describe here is a limitation of the old IP blocks which were > >> taken > >> from previously 32bit SoCs and they are incapable of accessing DRAM above > >> the 4 GiB boundary with their limited DMAs. The solution for that is to fix > >> those drivers, e.g. by placing their buffers below the 4 GiB boundary, or > >> by > >> using bounce buffers if needed. > >> > >> Placing U-Boot below the 4 GiB boundary is NOT a solution in any way, but a > >> broken workaround. There is still nothing preventing user from placing a > >> buffer above the 4 GiB boundary and passing that to the driver, at which > >> point > >> the driver will fail (e.g. a simple "$ load mmc > >> 0:1 0x1 file" will just fail, unless e.g. a bounce buffer is used). > > > > That will be several drivers need to use bounce buffer, > > sdhc/fec/usb/nand/video. > > Let's see how to address the drivers. > > R-Car had the same problem, so you can look there. Marek, Are you referring to d2661d8: mmc: tmio: sdhi: Use bounce buffer to avoid DMA limitations Do you know the state of the Linux kernel drivers with regards to this issue and if there is a performance hit due to the bounce buffers? Best Regards, Tim
Re: [PATCH v2] board: phytec: imx8mm: Add PHYTEC phyCORE-i.MX8MM support
Hi Teresa,
On 01.10.20 14:51, Teresa Remmet wrote:
> Hello,
>
> Am Freitag, den 21.08.2020, 09:55 +0200 schrieb Teresa Remmet:
>> Add support PHYTEC phyCORE-i.MX8MM SOM.
>>
>> Supported features:
>> - 2GB LPDDR4 RAM
>> - 1x 1Gbit Ethernet
>> - eMMC
>> - external SD
>> - debug UART3
>> - watchdog
>> - i2c eeprom
>>
>> Signed-off-by: Teresa Remmet
>> ---
>> Changes in v2:
>> - Removed fdt_high to allow relocation
>> - Moved fdt_addr to 0x4800
>
> is there anything else that needs to be done?
>
Not yet - I will pick this up after 2020.10 is released.
Regards,
Stefano
> Thanks,
> Teresa
>
>>
>> arch/arm/dts/Makefile|1 +
>> arch/arm/dts/phycore-imx8mm-u-boot.dtsi | 100 ++
>> arch/arm/dts/phycore-imx8mm.dts | 259
>> arch/arm/mach-imx/imx8m/Kconfig |6 +
>> board/phytec/phycore_imx8mm/Kconfig | 12 +
>> board/phytec/phycore_imx8mm/MAINTAINERS |9 +
>> board/phytec/phycore_imx8mm/Makefile | 11 +
>> board/phytec/phycore_imx8mm/lpddr4_timing.c | 1846
>> ++
>> board/phytec/phycore_imx8mm/phycore-imx8mm.c | 53 +
>> board/phytec/phycore_imx8mm/spl.c| 128 ++
>> configs/phycore-imx8mm_defconfig | 103 ++
>> include/configs/phycore_imx8mm.h | 130 ++
>> 12 files changed, 2658 insertions(+)
>> create mode 100644 arch/arm/dts/phycore-imx8mm-u-boot.dtsi
>> create mode 100644 arch/arm/dts/phycore-imx8mm.dts
>> create mode 100644 board/phytec/phycore_imx8mm/Kconfig
>> create mode 100644 board/phytec/phycore_imx8mm/MAINTAINERS
>> create mode 100644 board/phytec/phycore_imx8mm/Makefile
>> create mode 100644 board/phytec/phycore_imx8mm/lpddr4_timing.c
>> create mode 100644 board/phytec/phycore_imx8mm/phycore-imx8mm.c
>> create mode 100644 board/phytec/phycore_imx8mm/spl.c
>> create mode 100644 configs/phycore-imx8mm_defconfig
>> create mode 100644 include/configs/phycore_imx8mm.h
>>
>> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
>> index b2b5360f6d86..0e3826a9b892 100644
>> --- a/arch/arm/dts/Makefile
>> +++ b/arch/arm/dts/Makefile
>> @@ -762,6 +762,7 @@ dtb-$(CONFIG_ARCH_IMX8) += \
>> dtb-$(CONFIG_ARCH_IMX8M) += \
>> imx8mm-evk.dtb \
>> imx8mm-verdin.dtb \
>> +phycore-imx8mm.dtb \
>> imx8mn-ddr4-evk.dtb \
>> imx8mq-evk.dtb \
>> imx8mm-beacon-kit.dtb \
>> diff --git a/arch/arm/dts/phycore-imx8mm-u-boot.dtsi
>> b/arch/arm/dts/phycore-imx8mm-u-boot.dtsi
>> new file mode 100644
>> index ..fc0fa22d1bb4
>> --- /dev/null
>> +++ b/arch/arm/dts/phycore-imx8mm-u-boot.dtsi
>> @@ -0,0 +1,100 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Copyright (C) 2020 PHYTEC Messtechnik GmbH
>> + * Author: Teresa Remmet
>> + */
>> +
>> +/ {
>> +wdt-reboot {
>> +compatible = "wdt-reboot";
>> +wdt = <&wdog1>;
>> +u-boot,dm-spl;
>> +};
>> +};
>> +
>> +&{/soc@0} {
>> +u-boot,dm-pre-reloc;
>> +u-boot,dm-spl;
>> +};
>> +
>> +&clk {
>> +u-boot,dm-spl;
>> +u-boot,dm-pre-reloc;
>> +/delete-property/ assigned-clocks;
>> +/delete-property/ assigned-clock-parents;
>> +/delete-property/ assigned-clock-rates;
>> +};
>> +
>> +&osc_24m {
>> +u-boot,dm-spl;
>> +u-boot,dm-pre-reloc;
>> +};
>> +
>> +&aips1 {
>> +u-boot,dm-spl;
>> +u-boot,dm-pre-reloc;
>> +};
>> +
>> +&aips2 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&aips3 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&iomuxc {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&pinctrl_uart3 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&pinctrl_usdhc2_gpio {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&pinctrl_usdhc2 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&pinctrl_usdhc3 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&gpio1 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&gpio2 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&gpio3 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&gpio4 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&gpio5 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&uart3 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&usdhc2 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&usdhc3 {
>> +u-boot,dm-spl;
>> +};
>> +
>> +&wdog1 {
>> +u-boot,dm-spl;
>> +};
>> diff --git a/arch/arm/dts/phycore-imx8mm.dts b/arch/arm/dts/phycore-
>> imx8mm.dts
>> new file mode 100644
>> index ..c46d3c72ced9
>> --- /dev/null
>> +++ b/arch/arm/dts/phycore-imx8mm.dts
>> @@ -0,0 +1,259 @@
>> +// SPDX-License-Identifier: GPL-2.0-or-later
>> +/*
>> + * Copyright (C) 2019-2020 PHYTEC Messtechnik GmbH
>> + * Author: Teresa Remmet
>> + */
>> +
>> +/dts-v1/;
>> +
>> +#include
>> +#include "imx8mm.dtsi"
>> +
>> +/ {
>> +model = "PHYTEC phyCORE-i.MX8MM";
>> +compatible = "phytec,imx8mm-phycore-som", "fsl,imx8mm";
>> +
>> +chosen {
>> +stdout-patch = &uart3;
>> +};
>> +
>> +reg_usdhc2_vmmc: regulator-usdhc2 {
>> +compatible = "regulator-fixed";
>> +regulator-name = "VSD_3V3";
Re: Pinebook Pro keyboard (RK3399 OHCI)?
Simon South writes: > Has anyone managed to get the built-in keyboard of the Pinebook Pro > working with U-Boot? > > Even using the latest code, having USB started makes the U-boot > console feel sluggish while pressing keys on the keyboard produces no > result. To follow up on this, for anyone looking into it in the future: The issue is that the Pinebook Pro's keyboard firmware does not actually implement the keyboard boot protocol (described in the USB HID specification[1]). It also doesn't support retrieving input reports via its control interface, meaning neither of the two mechanisms U-Boot normally uses for polling keyboard data are functional. The firmware does recognize the Set_Protocol request, and will even store the supplied value in the controller's memory and return it in response to Get_Protocol. But it doesn't actually change how the keyboard operates. As such, the keyboard continues to NAK every interrupt-transfer request it sees (whenever the user isn't pressing a key), despite U-Boot expecting it to return a report at least once each 40-millisecond period. Consequently the submit_common_msg() routine in drivers/usb/host/ohci-hcd.c is continually timing out waiting for a response, and this slows down the U-Boot console considerably. Arnaud Patard has pointed out setting the CONFIG_SYS_USB_EVENT_POLL_VIA_INT_QUEUE configuration option seems to improve the keyboard's responsiveness somewhat, and while this is true, I suspect all this does is increase the likelihood U-Boot will happen to be polling the keyboard at the same moment the user is pressing a key. It doesn't address the underlying problem. In fact, nothing seems likely to address this unless and until new keyboard firmware is created for the Pinebook Pro. There has actually been some progress in this area[2], but the complexity involved in using an external programmer with the controller[3] (and the possibility of bricking it without one) makes it risky for an end-user to experiment with anything beyond very minor changes to the existing code. [1] https://www.usb.org/document-library/device-class-definition-hid-111 [2] https://github.com/jackhumbert/pinebook-pro-keyboard-updater/tree/master/firmware [3] https://electronics.stackexchange.com/a/277395 -- Simon South si...@simonsouth.net
Re: [PATCH v4 0/7] wdt: Add support for watchdogs on Kendryte K210
On 9/9/20 5:04 PM, Sean Anderson wrote: > This series depends on > https://patchwork.ozlabs.org/project/uboot/list/?series=200642 > > Changes in v4: > - Fix build error without CONFIG_CLK > > Changes in v3: > - Note dependency on "time: Fix get_ticks being non-monotonic" > - Add a few signed-off-bys which were sent for version 1 > > Changes in v2: > - Fix fls being off-by-one when compared to log_2_n_round_up > - Move watchdog enable to k210.dtsi as it does not depend on anything > board-specific. > > Sean Anderson (7): > wdt: dw: Switch to using fls for log2 > wdt: dw: Switch to if(CONFIG()) instead of using #if > wdt: dw: Fix clock rate being off by 1000 > wdt: dw: Enable the clock before using it > wdt: dw: Free the clock on error > riscv: Add watchdog bindings for the k210 > riscv: Enable watchdog for the k210 > > arch/riscv/dts/k210.dtsi | 1 - > board/sipeed/maix/Kconfig | 2 ++ > drivers/watchdog/designware_wdt.c | 39 --- > 3 files changed, 27 insertions(+), 15 deletions(-) > *ping* Marek can these go into -next? --Sean
[PATCH v2] cpu: at91: add driver for CPU
Add basic CPU driver use to retrieve information about CPU itself.
Signed-off-by: Claudiu Beznea
---
Changes in v2:
- get rid of compilation warnings
- rebase on top of "MAINTAINERS: add Microchip PIT64B timer" patch
MAINTAINERS| 1 +
drivers/cpu/Makefile | 1 +
drivers/cpu/at91_cpu.c | 123 +
3 files changed, 125 insertions(+)
create mode 100644 drivers/cpu/at91_cpu.c
diff --git a/MAINTAINERS b/MAINTAINERS
index 85e51855c488..91b06b49bd78 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -291,6 +291,7 @@ S: Maintained
T: git https://gitlab.denx.de/u-boot/custodians/u-boot-atmel.git
F: arch/arm/mach-at91/
F: board/atmel/
+F: drivers/cpu/at91_cpu.c
F: drivers/misc/microchip_flexcom.c
F: drivers/timer/mchp-pit64b-timer.c
diff --git a/drivers/cpu/Makefile b/drivers/cpu/Makefile
index 0b5dbc7c88e6..c8532637ca7c 100644
--- a/drivers/cpu/Makefile
+++ b/drivers/cpu/Makefile
@@ -8,6 +8,7 @@ obj-$(CONFIG_CPU) += cpu-uclass.o
obj-$(CONFIG_ARCH_BMIPS) += bmips_cpu.o
obj-$(CONFIG_ARCH_IMX8) += imx8_cpu.o
+obj-$(CONFIG_ARCH_AT91) += at91_cpu.o
obj-$(CONFIG_CPU_MPC83XX) += mpc83xx_cpu.o
obj-$(CONFIG_CPU_RISCV) += riscv_cpu.o
obj-$(CONFIG_SANDBOX) += cpu_sandbox.o
diff --git a/drivers/cpu/at91_cpu.c b/drivers/cpu/at91_cpu.c
new file mode 100644
index ..058ae3a81199
--- /dev/null
+++ b/drivers/cpu/at91_cpu.c
@@ -0,0 +1,123 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Microchip Technology Inc. and its subsidiaries
+ *
+ * Author: Claudiu Beznea
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+struct at91_cpu_platdata {
+ const char *name;
+ ulong cpufreq_mhz;
+ ulong mckfreq_mhz;
+ ulong xtalfreq_mhz;
+};
+
+extern char *get_cpu_name(void);
+
+const char *at91_cpu_get_name(void)
+{
+ return get_cpu_name();
+}
+
+int at91_cpu_get_desc(const struct udevice *dev, char *buf, int size)
+{
+ struct at91_cpu_platdata *plat = dev_get_platdata(dev);
+
+ snprintf(buf, size, "%s\n"
+"Crystal frequency: %8lu MHz\n"
+"CPU clock: %8lu MHz\n"
+"Master clock : %8lu MHz\n",
+plat->name, plat->xtalfreq_mhz, plat->cpufreq_mhz,
+plat->mckfreq_mhz);
+
+ return 0;
+}
+
+static int at91_cpu_get_info(const struct udevice *dev, struct cpu_info *info)
+{
+ struct at91_cpu_platdata *plat = dev_get_platdata(dev);
+
+ info->cpu_freq = plat->cpufreq_mhz * 100;
+ info->features = BIT(CPU_FEAT_L1_CACHE);
+
+ return 0;
+}
+
+static int at91_cpu_get_count(const struct udevice *dev)
+{
+ return 1;
+}
+
+static int at91_cpu_get_vendor(const struct udevice *dev, char *buf, int size)
+{
+ snprintf(buf, size, "Microchip Technology Inc.");
+
+ return 0;
+}
+
+static const struct cpu_ops at91_cpu_ops = {
+ .get_desc = at91_cpu_get_desc,
+ .get_info = at91_cpu_get_info,
+ .get_count = at91_cpu_get_count,
+ .get_vendor = at91_cpu_get_vendor,
+};
+
+static const struct udevice_id at91_cpu_ids[] = {
+ { .compatible = "arm,cortex-a7" },
+ { /* Sentinel. */ }
+};
+
+static int at91_cpu_probe(struct udevice *dev)
+{
+ struct at91_cpu_platdata *plat = dev_get_platdata(dev);
+ struct clk clk;
+ ulong rate;
+ int ret;
+
+ ret = clk_get_by_index(dev, 0, &clk);
+ if (ret)
+ return ret;
+
+ rate = clk_get_rate(&clk);
+ if (!rate)
+ return -ENOTSUPP;
+ plat->cpufreq_mhz = DIV_ROUND_CLOSEST_ULL(rate, 100);
+
+ ret = clk_get_by_index(dev, 1, &clk);
+ if (ret)
+ return ret;
+
+ rate = clk_get_rate(&clk);
+ if (!rate)
+ return -ENOTSUPP;
+ plat->mckfreq_mhz = DIV_ROUND_CLOSEST_ULL(rate, 100);
+
+ ret = clk_get_by_index(dev, 2, &clk);
+ if (ret)
+ return ret;
+
+ rate = clk_get_rate(&clk);
+ if (!rate)
+ return -ENOTSUPP;
+ plat->xtalfreq_mhz = DIV_ROUND_CLOSEST_ULL(rate, 100);
+
+ plat->name = get_cpu_name();
+
+ return 0;
+}
+
+U_BOOT_DRIVER(cpu_at91_drv) = {
+ .name = "at91-cpu",
+ .id = UCLASS_CPU,
+ .of_match = at91_cpu_ids,
+ .ops= &at91_cpu_ops,
+ .probe = at91_cpu_probe,
+ .platdata_auto_alloc_size = sizeof(struct at91_cpu_platdata),
+ .flags = DM_FLAG_PRE_RELOC,
+};
--
2.7.4
Re: [PATCHv4 2/3] sandbox: enable support of generic udp protocol
On Fri, Sep 18, 2020 at 02:13:01PM +0200, Philippe Reynes wrote: > This commit enable the support of the generic udp protocol. > > Signed-off-by: Philippe Reynes > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/3] net: add a generic udp protocol
On Fri, Sep 18, 2020 at 02:13:00PM +0200, Philippe Reynes wrote: > This commit adds a generic udp protocol framework in the > network loop. So protocol based on udp may be implemented > without modifying the network loop (for example custom > wait magic packet). > > Signed-off-by: Philippe Reynes > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 3/3] sntp: use udp framework
On Fri, Sep 18, 2020 at 02:13:02PM +0200, Philippe Reynes wrote: > This commits update the support of sntp to use > the framework udp. This change allows to remove > all the reference to sntp in the main network > file net/net.c. > > Signed-off-by: Philippe Reynes > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/1] net: use log_err() for 'No ethernet found' message
On Mon, Sep 14, 2020 at 11:00:18AM +0200, Heinrich Schuchardt wrote: > Write the 'No ethernet found' message via the log drivers. This allows > suppressing it during output via the syslog driver. > > This fixes the problem reported in: > > [PATCH 0/4] log: Fix the syslog spam when running tests > https://lists.denx.de/pipermail/u-boot/2020-September/426343.html > > Reported-by: Simon Glass > Signed-off-by: Heinrich Schuchardt > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 3/3] net: tftp: Fix load_block offset calculation
On Tue, Aug 25, 2020 at 10:26:37AM +0800, Ley Foon Tan wrote: > When load the last block, the "len" might not be a block size. This cause > loading the incorrect last block data. > > The fix change "len" to tftp_block_size and minus one tftp_block_size > for offset calculation. > > Use same offset calculation formula as in store_block(). > > Signed-off-by: Ley Foon Tan > Reviewed-By: Ramon Fried Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/3] net: tftp: Fix store_block offset calculation
On Tue, Aug 25, 2020 at 10:26:36AM +0800, Ley Foon Tan wrote: > tftp_cur_block start with 1 for first block, but tftp_cur_block counter is > start with zero when block number is rollover. The existing code > "tftp_cur_block - 1" will cause the block number become -1 in store_block() > when tftp_cur_block is 0 when tftp_cur_block is rollover. > > The fix pass in tftp_cur_block to store_block() and minus the > tftp_block_size when do the offset calculation. > > Signed-off-by: Ley Foon Tan > Reviewed-By: Ramon Fried Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: dwc_eth_qos: Convert to use APIs which support live DT
On Wed, Sep 09, 2020 at 06:30:06PM +0200, Patrick Delaunay wrote: > Use ofnode_ or dev_ APIs instead of fdt_ and fdtdec_ APIs so that the > driver can support live DT. > > Signed-off-by: Patrick Delaunay Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH V2] net: smc911x: Automatically Update ethaddr with MAC
On Tue, Aug 18, 2020 at 08:19:02AM -0500, Adam Ford wrote: > The ethernet controller can read the MAC from EEPROM and display it, > but if ethaddr is not set, the ethernet is still unavailable. > > This patch checks will automatically set the MAC address if it has > not already been set. > > Signed-off-by: Adam Ford > Acked-by: Joe Hershberger Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/3] net: tftp: Fix tftp_prev_block counter update
On Tue, Aug 25, 2020 at 10:26:35AM +0800, Ley Foon Tan wrote: > Fixes missing update to tftp_prev_block counter before increase > tftp_cur_block counter when do the tftpput operation. > > tftp_prev_block counter is used in update_block_number() function to > check whether block number (sequence number) is rollover. This bug > cause the tftpput command fail to upload a large file when block > number is greater than 16-bit (0x). > > Signed-off-by: Ley Foon Tan > Reviewed-By: Ramon Fried Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 1/2] net: phy: mscc: make clock-output configurable on vsc85xx
On Tue, Jun 09, 2020 at 03:37:39PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > The vsc8530/8531/8540/8541 phys have a configurable clock output that > can emit 25, 50 and 125 MHz rates, which in turn may be needed for > stable network connections. > > This follows a similar change introduced into the Linux kernel at > https://lore.kernel.org/netdev/20200609133140.1421109-2-he...@sntech.de > > Signed-off-by: Heiko Stuebner > Reviewed-by: Philipp Tomsich Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/1] phy: add support for stingray PAXB PHY controller
On Thu, Apr 02, 2020 at 04:08:12PM +0530, Rayagonda Kokatanur wrote: > From: Srinath Mannam > > Add support for stingray PAXB PHY controller driver. > This driver supports maximum 8 PAXB phys using pipemux data. > > Signed-off-by: Srinath Mannam > Signed-off-by: Rayagonda Kokatanur > Reviewed-by: Stefan Roese Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH 2/2] net: phy: mscc: sync rx/tx delay settings with Linux on vsc85xx
On Tue, Jun 09, 2020 at 03:37:40PM +0200, Heiko Stuebner wrote: > From: Heiko Stuebner > > The Linux kernel does set the clock delays to > - 0.2 ns (their default, and lowest, hardware value) if delays should > not be enabled > - 2.0 ns (which causes the data to be sampled at exactly half way between > clock transitions at 1000 Mbps) if delays should be enabled > depending on the interface mode > > See > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/net/phy/mscc/mscc_main.c#n523 > > So instead of using arbitrary delay values like now, mimic this behaviour. > > The behaviour is the same for all of vsc8530/8531/8540/8541 so move that > to a shared function while at it. > > Signed-off-by: Heiko Stuebner > Reviewed-by: Philipp Tomsich Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] net: ftgmac100: Add support for board specific PHY interface address
On Mon, Aug 17, 2020 at 05:08:26PM -0700, Thirupathaiah Annapureddy wrote: > ftgmac100 driver is using hard-coded PHY interface address of zero. > Each board can have different PHY interface address (phy_addr). > This commit modifies the driver to make use of board specific address > by leveraging CONFIG_PHY_ADDR. > > Signed-off-by: Thirupathaiah Annapureddy > Reviewed-by: Cédric Le Goater Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 9/9] test: dm: Add tests for regmap managed API and regmap fields
On Thu, Sep 24, 2020 at 10:04:18AM +0530, Pratyush Yadav wrote: > From: Jean-Jacques Hiblot > > The tests rely on a dummy driver to allocate and initialize the regmaps > and the regmap fields using the managed API. The first test checks if > the regmap config fields like width, reg_offset_shift, range specifiers, > etc work. The second test checks if regmap fields behave properly (mask > and shift are ok) by peeking into the regmap. > > Signed-off-by: Jean-Jacques Hiblot > Signed-off-by: Pratyush Yadav > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 5/9] regmap: Add regmap_init_mem_range()
On Thu, Sep 24, 2020 at 10:04:14AM +0530, Pratyush Yadav wrote: > Right now, the base of a regmap can only be obtained from the device > tree. This makes it impossible for devices which calculate the base at > runtime to use a regmap. An example of such a device is the Cadence > Sierra PHY. > > Allow creating a regmap with one range whose start and size can be > specified by the driver based on calculations at runtime. > > Signed-off-by: Pratyush Yadav > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 8/9] test/py: allow multi-digit index in in_tree()
On Thu, Sep 24, 2020 at 10:04:17AM +0530, Pratyush Yadav wrote: > When more nodes are added for a uclass the index might go into two or > more digits. This means that there are less spaces printed because they > are used up by the extra digits. Update the regular expression to allow > variable-length spacing between the class name and and index. > > This was discovered when adding a simple_bus node in test.dts made > test_bind_unbind_with_uclass() fail because the index went up to 10. > > Signed-off-by: Pratyush Yadav Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 6/9] regmap: Allow devices to specify regmap range start and size in config
On Thu, Sep 24, 2020 at 10:04:15AM +0530, Pratyush Yadav wrote: > Some devices need to calculate the regmap base address at runtime. This > makes it impossible to use device tree to get the regmap base. Instead, > allow devices to specify it in the regmap config. This will create a > regmap with a single range that corresponds to the start and size given > by the driver. > > Signed-off-by: Pratyush Yadav > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 7/9] regmap: Add support for regmap fields
On Thu, Sep 24, 2020 at 10:04:16AM +0530, Pratyush Yadav wrote: > From: Jean-Jacques Hiblot > > A regmap field is an abstraction available in Linux. It provides to access > bitfields in a regmap without having to worry about shifts and masks. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Simon Glass > Signed-off-by: Pratyush Yadav Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 4/9] regmap: Allow left shifting register offset before access
On Thu, Sep 24, 2020 at 10:04:13AM +0530, Pratyush Yadav wrote: > Drivers can configure it to adjust the final read/write location. > > Signed-off-by: Pratyush Yadav > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/9] regmap: Add devm_regmap_init()
On Thu, Sep 24, 2020 at 10:04:10AM +0530, Pratyush Yadav wrote: > From: Jean-Jacques Hiblot > > Most of new linux drivers are using managed-API to allocate resources. To > ease porting drivers from linux to U-Boot, introduce devm_regmap_init() as > a managed API to get a regmap from the device tree. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Simon Glass > Signed-off-by: Pratyush Yadav Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/9] regmap: zero out the regmap on allocation
On Thu, Sep 24, 2020 at 10:04:11AM +0530, Pratyush Yadav wrote: > Some fields will be introduced in the regmap structure that should be > set to 0 by default. So, once we allocate a regmap, make sure it is > zeroed out to avoid unexpected defaults for those values. > > Signed-off-by: Pratyush Yadav > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 3/9] regmap: Allow specifying read/write width
On Thu, Sep 24, 2020 at 10:04:12AM +0530, Pratyush Yadav wrote:
> Right now, regmap_read() and regmap_write() read/write a 32-bit value
> only. To write other lengths, regmap_raw_read() and regmap_raw_write()
> need to be used.
>
> This means that any driver ported from Linux that relies on
> regmap_{read,write}() to know the size already has to be updated at each
> callsite. This makes the port harder to maintain.
>
> So, allow specifying the read/write width to make it easier to port the
> drivers, since now the only change needed is when initializing the
> regmap.
>
> Signed-off-by: Pratyush Yadav
> Reviewed-by: Simon Glass
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v5 2/2] test: gpio: Add tests for the managed API
On Fri, Sep 11, 2020 at 01:43:35PM +0530, Pratyush Yadav wrote: > From: Jean-Jacques Hiblot > > Add a test to verify that GPIOs can be acquired/released using the managed > API. Also check that the GPIOs are released when the consumer device is > removed. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Simon Glass > Signed-off-by: Pratyush Yadav Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 8/8] firmware: smci: sandbox test for SCMI reset controllers
On Wed, Sep 09, 2020 at 06:44:07PM +0200, Etienne Carriere wrote: > Add tests for SCMI reset controllers. A test device driver > sandbox-scmi_devices.c is used to get reset resources, allowing further > resets manipulation. > > Change sandbox-smci_agent to emulate 1 reset controller exposed through > an agent. Add DM test scmi_resets to test this reset controller. > > Signed-off-by: Etienne Carriere > Cc: Simon Glass > Cc: Peng Fan > Cc: Sudeep Holla > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 7/8] reset: add reset controller driver for SCMI agents
On Wed, Sep 09, 2020 at 06:44:06PM +0200, Etienne Carriere wrote: > This change introduces a reset controller driver for SCMI agent devices. > When SCMI agent and SCMI reset domain drivers are enabled, SCMI agent > binds a reset controller device for each SCMI reset domain protocol > devices enabled in the FDT. > > SCMI reset driver is embedded upon CONFIG_RESET_SCMI=y. If enabled, > CONFIG_SCMI_AGENT is also enabled. > > SCMI Reset Domain protocol is defined in the SCMI specification [1]. > > Links: [1] > https://developer.arm.com/architectures/system-architectures/software-standards/scmi > Signed-off-by: Etienne Carriere > Cc: Simon Glass > Cc: Peng Fan > Cc: Sudeep Holla > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 6/8] firmware: scmi: sandbox test for SCMI clocks
On Wed, Sep 09, 2020 at 06:44:05PM +0200, Etienne Carriere wrote:
> Add tests for SCMI clocks. A test device driver sandbox-scmi_devices.c
> is used to get clock resources, allowing further clock manipulation.
>
> Change sandbox-smci_agent to emulate 3 clocks exposed through 2 agents.
> Add DM test scmi_clocks to test these 3 clocks.
> Update DM test sandbox_scmi_agent with load/remove test sequences
> factorized by {load|remove}_sandbox_scmi_test_devices() helper functions.
>
> Signed-off-by: Etienne Carriere
> Cc: Simon Glass
> Cc: Peng Fan
> Cc: Sudeep Holla
> Reviewed-by: Simon Glass
Applied to u-boot/next, thanks!
--
Tom
signature.asc
Description: PGP signature
Re: [PATCH v5 1/2] drivers: gpio: Add a managed API to get a GPIO from the device-tree
On Fri, Sep 11, 2020 at 01:43:34PM +0530, Pratyush Yadav wrote: > From: Jean-Jacques Hiblot > > Add managed functions to get a gpio from the devce-tree, based on a > property name (minus the '-gpios' suffix) and optionally an index. > > When the device is unbound, the GPIO is automatically released and the > data structure is freed. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Simon Glass > Signed-off-by: Pratyush Yadav Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 5/8] clk: add clock driver for SCMI agents
On Wed, Sep 09, 2020 at 06:44:04PM +0200, Etienne Carriere wrote: > This change introduces a clock driver for SCMI agent devices. When > SCMI agent and SCMI clock drivers are enabled, SCMI agent binds a > clock device for each SCMI clock protocol devices enabled in the FDT. > > SCMI clock driver is embedded upon CONFIG_CLK_SCMI=y. If enabled, > CONFIG_SCMI_AGENT is also enabled. > > SCMI Clock protocol is defined in the SCMI specification [1]. > > Links: [1] > https://developer.arm.com/architectures/system-architectures/software-standards/scmi > Signed-off-by: Etienne Carriere > Cc: Lukasz Majewski > Cc: Simon Glass > Cc: Peng Fan > Cc: Sudeep Holla > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 4/8] dt-bindings: arm: SCMI bindings documentation
On Wed, Sep 09, 2020 at 06:44:03PM +0200, Etienne Carriere wrote: > Dump SCMI DT bindings documentation from Linux kernel source > tree v5.8-rc1. > > Signed-off-by: Etienne Carriere > Reviewed-by: Simon Glass > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 2/8] firmware: scmi: mailbox/smt agent device
On Wed, Sep 09, 2020 at 06:44:01PM +0200, Etienne Carriere wrote: > This change implements a mailbox transport using SMT format for SCMI > exchanges. This implementation follows the Linux kernel and > SCP-firmware [1] as references implementation for SCMI message > processing using SMT format for communication channel meta-data. > > Use of mailboxes in SCMI FDT bindings are defined in the Linux kernel > DT bindings since v4.17. > > Links: [1] https://github.com/ARM-software/SCP-firmware > Signed-off-by: Etienne Carriere > Cc: Simon Glass > Cc: Peng Fan > Cc: Sudeep Holla > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 3/8] firmware: scmi: support Arm SMCCC transport
On Wed, Sep 09, 2020 at 06:44:02PM +0200, Etienne Carriere wrote: > This change implements a SMCCC transport for SCMI exchanges. This > implementation follows the Linux kernel as references implementation > for SCMI message processing, using the SMT format for communication > channel meta-data. > > Use of SMCCC transport in SCMI FDT bindings are defined in the Linux > kernel DT bindings since v5.8. SMCCC with SMT is implemented in OP-TEE > from tag 3.9.0 [2]. > > Links: [2] https://github.com/OP-TEE/optee_os/commit/a58c4d706d23 > Signed-off-by: Etienne Carriere > Cc: Simon Glass > Cc: Peng Fan > Cc: Sudeep Holla > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v4 1/8] firmware: add SCMI agent uclass
On Wed, Sep 09, 2020 at 06:44:00PM +0200, Etienne Carriere wrote: > This change introduces SCMI agent uclass to interact with a firmware > using the SCMI protocols [1]. > > SCMI agent uclass currently supports a single method to request > processing of the SCMI message by an identified server. A SCMI message > is made of a byte payload associated to a protocol ID and a message ID, > all defined by the SCMI specification [1]. On return from process_msg() > method, the caller gets the service response. > > SCMI agent uclass defines a post bind generic sequence for all devices. > The sequence binds all the SCMI protocols listed in the FDT for that > SCMI agent device. Currently none, but later change will introduce > protocols. > > This change implements a simple sandbox device for the SCMI agent uclass. > The sandbox nicely answers SCMI_NOT_SUPPORTED to SCMI messages. > To prepare for further test support, the sandbox exposes a architecture > function for test application to read the sandbox emulated devices state. > Currently supports 2 SCMI agents, identified by an ID in the FDT device > name. The simplistic DM test does nothing yet. > > SCMI agent uclass is designed for platforms that embed a SCMI server in > a firmware hosted somewhere, for example in a companion co-processor or > in the secure world of the executing processor. SCMI protocols allow an > SCMI agent to discover and access external resources as clock, reset > controllers and more. SCMI agent and server communicate following the > SCMI specification [1]. This SCMI agent implementation complies with > the DT bindings defined in the Linux kernel source tree regarding > SCMI agent description since v5.8. > > Links: [1] > https://developer.arm.com/architectures/system-architectures/software-standards/scmi > Signed-off-by: Etienne Carriere > Cc: Simon Glass > Cc: Peng Fan > Cc: Sudeep Holla > Reviewed-by: Simon Glass Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 1/2] drivers: reset: Add a managed API to get reset controllers from the DT
On Wed, Sep 09, 2020 at 03:37:03PM +0530, Pratyush Yadav wrote: > From: Jean-Jacques Hiblot > > Add managed functions to get a reset_ctl from the device-tree, based on a > name or an index. > Also add a managed functions to get a reset_ctl_bulk (array of reset_ctl) > from the device-tree. > > When the device is unbound, the reset controllers are automatically > released and the data structure is freed. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Simon Glass > Signed-off-by: Pratyush Yadav Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH v3 2/2] test: reset: Add tests for the managed API
On Wed, Sep 09, 2020 at 03:37:04PM +0530, Pratyush Yadav wrote: > From: Jean-Jacques Hiblot > > The tests are basically the same as for the regular API. Except that > the reset are initialized using the managed API, and no freed manually. > > Signed-off-by: Jean-Jacques Hiblot > Reviewed-by: Simon Glass > Signed-off-by: Pratyush Yadav Applied to u-boot/next, thanks! -- Tom signature.asc Description: PGP signature
Re: [PATCH] ARM: dts: stm32: Add missing dm-spl props for SPI NOR on AV96
Hi Marek
On 10/1/20 12:25 PM, Marek Vasut wrote:
> The u-boot,dm-spl DT props are missing on AV96, hence the pinmux and
> flash0 nodes are not included in the reduced SPL DT. This prevents
> SPI NOR boot from working at all. Fix this by filling them in.
>
> Signed-off-by: Marek Vasut
> Cc: Patrick Delaunay
> Cc: Patrice Chotard
> ---
> arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> index c73318488d..9d3db20876 100644
> --- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> +++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
> @@ -21,6 +21,10 @@
> };
> };
>
> +&flash0 {
> + u-boot,dm-spl;
> +};
> +
> &gpiof {
> snor-nwp {
> gpio-hog;
> @@ -49,6 +53,23 @@
> u-boot,dm-spl;
> };
>
> +&qspi_clk_pins_a {
> + u-boot,dm-spl;
> + pins {
> + u-boot,dm-spl;
> + };
> +};
> +
> +&qspi_bk1_pins_a {
> + u-boot,dm-spl;
> + pins1 {
> + u-boot,dm-spl;
> + };
> + pins2 {
> + u-boot,dm-spl;
> + };
> +};
> +
> &rcc {
> st,clksrc = <
> CLK_MPU_PLL1P
Reviewed-by: Patrice Chotard
Thanks
Re: [PATCH v2] board: phytec: imx8mm: Add PHYTEC phyCORE-i.MX8MM support
Hello,
Am Freitag, den 21.08.2020, 09:55 +0200 schrieb Teresa Remmet:
> Add support PHYTEC phyCORE-i.MX8MM SOM.
>
> Supported features:
> - 2GB LPDDR4 RAM
> - 1x 1Gbit Ethernet
> - eMMC
> - external SD
> - debug UART3
> - watchdog
> - i2c eeprom
>
> Signed-off-by: Teresa Remmet
> ---
> Changes in v2:
> - Removed fdt_high to allow relocation
> - Moved fdt_addr to 0x4800
is there anything else that needs to be done?
Thanks,
Teresa
>
> arch/arm/dts/Makefile|1 +
> arch/arm/dts/phycore-imx8mm-u-boot.dtsi | 100 ++
> arch/arm/dts/phycore-imx8mm.dts | 259
> arch/arm/mach-imx/imx8m/Kconfig |6 +
> board/phytec/phycore_imx8mm/Kconfig | 12 +
> board/phytec/phycore_imx8mm/MAINTAINERS |9 +
> board/phytec/phycore_imx8mm/Makefile | 11 +
> board/phytec/phycore_imx8mm/lpddr4_timing.c | 1846
> ++
> board/phytec/phycore_imx8mm/phycore-imx8mm.c | 53 +
> board/phytec/phycore_imx8mm/spl.c| 128 ++
> configs/phycore-imx8mm_defconfig | 103 ++
> include/configs/phycore_imx8mm.h | 130 ++
> 12 files changed, 2658 insertions(+)
> create mode 100644 arch/arm/dts/phycore-imx8mm-u-boot.dtsi
> create mode 100644 arch/arm/dts/phycore-imx8mm.dts
> create mode 100644 board/phytec/phycore_imx8mm/Kconfig
> create mode 100644 board/phytec/phycore_imx8mm/MAINTAINERS
> create mode 100644 board/phytec/phycore_imx8mm/Makefile
> create mode 100644 board/phytec/phycore_imx8mm/lpddr4_timing.c
> create mode 100644 board/phytec/phycore_imx8mm/phycore-imx8mm.c
> create mode 100644 board/phytec/phycore_imx8mm/spl.c
> create mode 100644 configs/phycore-imx8mm_defconfig
> create mode 100644 include/configs/phycore_imx8mm.h
>
> diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
> index b2b5360f6d86..0e3826a9b892 100644
> --- a/arch/arm/dts/Makefile
> +++ b/arch/arm/dts/Makefile
> @@ -762,6 +762,7 @@ dtb-$(CONFIG_ARCH_IMX8) += \
> dtb-$(CONFIG_ARCH_IMX8M) += \
> imx8mm-evk.dtb \
> imx8mm-verdin.dtb \
> + phycore-imx8mm.dtb \
> imx8mn-ddr4-evk.dtb \
> imx8mq-evk.dtb \
> imx8mm-beacon-kit.dtb \
> diff --git a/arch/arm/dts/phycore-imx8mm-u-boot.dtsi
> b/arch/arm/dts/phycore-imx8mm-u-boot.dtsi
> new file mode 100644
> index ..fc0fa22d1bb4
> --- /dev/null
> +++ b/arch/arm/dts/phycore-imx8mm-u-boot.dtsi
> @@ -0,0 +1,100 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2020 PHYTEC Messtechnik GmbH
> + * Author: Teresa Remmet
> + */
> +
> +/ {
> + wdt-reboot {
> + compatible = "wdt-reboot";
> + wdt = <&wdog1>;
> + u-boot,dm-spl;
> + };
> +};
> +
> +&{/soc@0} {
> + u-boot,dm-pre-reloc;
> + u-boot,dm-spl;
> +};
> +
> +&clk {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> + /delete-property/ assigned-clocks;
> + /delete-property/ assigned-clock-parents;
> + /delete-property/ assigned-clock-rates;
> +};
> +
> +&osc_24m {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +&aips1 {
> + u-boot,dm-spl;
> + u-boot,dm-pre-reloc;
> +};
> +
> +&aips2 {
> + u-boot,dm-spl;
> +};
> +
> +&aips3 {
> + u-boot,dm-spl;
> +};
> +
> +&iomuxc {
> + u-boot,dm-spl;
> +};
> +
> +&pinctrl_uart3 {
> + u-boot,dm-spl;
> +};
> +
> +&pinctrl_usdhc2_gpio {
> + u-boot,dm-spl;
> +};
> +
> +&pinctrl_usdhc2 {
> + u-boot,dm-spl;
> +};
> +
> +&pinctrl_usdhc3 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio1 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio2 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio3 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio4 {
> + u-boot,dm-spl;
> +};
> +
> +&gpio5 {
> + u-boot,dm-spl;
> +};
> +
> +&uart3 {
> + u-boot,dm-spl;
> +};
> +
> +&usdhc2 {
> + u-boot,dm-spl;
> +};
> +
> +&usdhc3 {
> + u-boot,dm-spl;
> +};
> +
> +&wdog1 {
> + u-boot,dm-spl;
> +};
> diff --git a/arch/arm/dts/phycore-imx8mm.dts b/arch/arm/dts/phycore-
> imx8mm.dts
> new file mode 100644
> index ..c46d3c72ced9
> --- /dev/null
> +++ b/arch/arm/dts/phycore-imx8mm.dts
> @@ -0,0 +1,259 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2019-2020 PHYTEC Messtechnik GmbH
> + * Author: Teresa Remmet
> + */
> +
> +/dts-v1/;
> +
> +#include
> +#include "imx8mm.dtsi"
> +
> +/ {
> + model = "PHYTEC phyCORE-i.MX8MM";
> + compatible = "phytec,imx8mm-phycore-som", "fsl,imx8mm";
> +
> + chosen {
> + stdout-patch = &uart3;
> + };
> +
> + reg_usdhc2_vmmc: regulator-usdhc2 {
> + compatible = "regulator-fixed";
> + regulator-name = "VSD_3V3";
> + regulator-min-microvolt = <330>;
> + regulator-max-microvolt = <330>;
> + startup-delay-us = <100>;
> + off-on-delay-us = <12000>;
> + };
> +};
> +
> +/* ethernet */
> +&fec1 {
> + pinctrl-names = "default";
> + pi
Re: [PATCH 1/2] spl: Avoid printing boot device if silent console is enabled
On 30.09.20 13:47, Otavio Salvador wrote: Em qua., 30 de set. de 2020 às 02:23, Stefan Roese escreveu: On 30.09.20 04:14, Otavio Salvador wrote: Wouldn't it be better, to add this CONFIG_SILENT_CONSOLE check to the console / printf function itself instead of adding it to all callers? I believe in critical errors and like, it is important to print so I'd say that using a more controlled "hide" mechanism is good. Agreed. I forgot about that. Thanks, Stefan
Please pull u-boot-marvell/master
Hi Tom, please pull the last batch of Marvell MVEBU related fixes. Here the summary log: - Espressobin: Fix compatible string check - Espressobin: Extend README for more MAC addresses Here the Azure build, without any issues: https://dev.azure.com/sr0718/u-boot/_build/results?buildId=53&view=results Thanks, Stefan The following changes since commit 5f9070a4a48d2db1968b86a54e82724dbe2a6de6: optee: copy FDT OP-TEE related nodes before generic FDT changes (2020-09-30 11:31:13 -0400) are available in the Git repository at: g...@gitlab.denx.de:u-boot/custodians/u-boot-marvell.git for you to fetch changes up to 05e7511fae612aabfc13c58da9bafa12b6438ec8: arm: mvebu: Espressobin: Fix checks against machine compatible strings (2020-10-01 10:43:43 +0200) Andre Heider (1): arm: mvebu: Espressobin: Fix checks against machine compatible strings Pali Rohár (1): arm: mvebu: Espressobin: Instructions for more MAC addresses in README.marvell board/Marvell/mvebu_armada-37xx/board.c | 4 ++-- doc/README.marvell | 23 +-- 2 files changed, 19 insertions(+), 8 deletions(-)
Re: [PATCH] arm: mvebu: Espressobin: Instructions for more MAC addresses in README.marvell
On 25.09.20 09:54, Pali Rohár wrote: Some Espressobin boards got assigned more than one MAC address. Update instructions how to correctly store and preserve all MAC addresses. Signed-off-by: Pali Rohár Applied to u-boot-marvell/master Thanks, Stefan --- doc/README.marvell | 23 +-- 1 file changed, 17 insertions(+), 6 deletions(-) diff --git a/doc/README.marvell b/doc/README.marvell index 5416bc3035..6fc5ac8a40 100644 --- a/doc/README.marvell +++ b/doc/README.marvell @@ -27,7 +27,7 @@ Build Procedure - For the Armada-70x0/80x0 DB board use "mvebu_db_armada8k_defconfig" - For the Armada-80x0 MacchiatoBin use "make mvebu_mcbin-88f8040_defconfig" - For the Armada-3700 DB board use "make mvebu_db-88f3720_defconfig" - - For the Armada-3700 EsspressoBin use "make mvebu_espressobin-88f3720_defconfig" + - For the Armada-3700 EspressoBin use "make mvebu_espressobin-88f3720_defconfig" 5. Configure the device-tree and build the U-Boot image: @@ -62,11 +62,15 @@ Configuration update Permanent ethernet MAC address --- Prior flashing new U-Boot version (as part of ATF image) it is suggested to backup - permanent ethernet MAC address as it is stored only in U-Boot env storage (SPI or eMMC). - Some boards like EspressoBin have MAC address printed on sticker. To print current MAC - address run: + permanent ethernet MAC addresses as they are stored only in U-Boot env storage (SPI or eMMC). + Some boards like EspressoBin have MAC addresses printed on sticker. Some boards got assigned + only one address other may also more than one. To print current MAC addresses run: # echo $ethaddr + # echo $eth1addr + # echo $eth2addr + # echo $eth3addr + # ... MAC addresses 00:51:82:11:22:00, 00:51:82:11:22:01, 00:51:82:11:22:02, 00:51:82:11:22:03 and F0:AD:4E:03:64:7F are default hardcoded values found in Marvell's and Armbian U-Boot @@ -75,13 +79,20 @@ Permanent ethernet MAC address suggested to generate new random one. After flashing new U-Boot version it is suggested to reset U-Boot env variables to default - and then set correct permanent ethernet MAC address. + and then set correct permanent ethernet MAC addresses. # env default -a # setenv ethaddr XX:XX:XX:XX:XX:XX + # setenv eth1addr XX:XX:XX:XX:XX:XX + # setenv eth2addr YY:YY:YY:YY:YY:YY + # setenv eth3addr ZZ:ZZ:ZZ:ZZ:ZZ:ZZ + # ... # saveenv - Where XX:XX:XX:XX:XX:XX is permanent ethernet MAC address. + Where value for ethaddr is required permanent ethernet MAC address and values for ethNaddr + are optional per-port MAC addresses. When optional ethNaddr variables are not defined then + they are inherited from required ethaddr variable. eth1addr contains MAC address for the + wan port, other for particular lan ports. Recent Linux kernel versions use correct permanent ethernet MAC address from U-Boot env as U-Boot will inject it into kernel's device-tree. Viele Grüße, Stefan -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] arm: mvebu: Espressobin: Fix checks against machine compatible strings
On 29.09.20 14:34, Andre Heider wrote:
The patches changing the compatible strings to the ones used by Linux have
not been merged yet, so fix the checks to use the current in-tree ones.
Reported-by: Pali Rohár
Signed-off-by: Andre Heider
Applied to u-boot-marvell/master
Thanks,
Stefan
---
board/Marvell/mvebu_armada-37xx/board.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index eacee15cb3..2bfc7171c4 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -88,14 +88,14 @@ int board_late_init(void)
if (env_get("fdtfile"))
return 0;
- if (!of_machine_is_compatible("globalscale,espressobin"))
+ if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
return 0;
/* If the memory controller has been configured for DDR4, we're running on v7 */
ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >>
A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
& A3700_MC_CTRL2_SDRAM_TYPE_MASK) ==
A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
- emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
+ emmc = of_machine_is_compatible("marvell,armada-3720-espressobin-emmc");
if (ddr4 && emmc)
env_set("fdtfile",
"marvell/armada-3720-espressobin-v7-emmc.dtb");
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
[PATCH] i2c: mvtwsi: disable i2c slave also on Armada 8k
The hidden I2C slave is also present on the Armada 8k AP806. Testing shows that this I2C slave causes the same issues as Armada 38x. Disabling that I2C slave fixes all these issues. I2C blocks on the Armada 8k CP110 are not affected. Extend the I2C slave disable to Armada 8k as well. Cc: Stefan Roese Signed-off-by: Baruch Siach --- drivers/i2c/mvtwsi.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/i2c/mvtwsi.c b/drivers/i2c/mvtwsi.c index fdb8fd42e5c0..14c594d648ba 100644 --- a/drivers/i2c/mvtwsi.c +++ b/drivers/i2c/mvtwsi.c @@ -823,7 +823,8 @@ static int mvtwsi_i2c_bind(struct udevice *bus) struct mvtwsi_registers *twsi = dev_read_addr_ptr(bus); /* Disable the hidden slave in i2c0 of these platforms */ - if ((IS_ENABLED(CONFIG_ARMADA_38X) || IS_ENABLED(CONFIG_ARCH_KIRKWOOD)) + if ((IS_ENABLED(CONFIG_ARMADA_38X) || IS_ENABLED(CONFIG_ARCH_KIRKWOOD) + || IS_ENABLED(CONFIG_ARMADA_8K)) && bus->req_seq == 0) twsi_disable_i2c_slave(twsi); -- 2.28.0
[PATCH v2] mtd: spi-nor: Add support for Cypress s25hl-t/s25hs-t
From: Takahiro Kuwano
The S25HL-T/S25HS-T family is the Cypress Semper Flash with Quad SPI.
The datasheet can be found in https://community.cypress.com/docs/DOC-15165
This device family can be configured to non-uniform sector layout, while
U-Boot does not support it. To handle this, an erase hook emulates uniform
sector layout. To enable quad mode, using volatile register is recommended
for safety. And some other fixups for spi_nor_flash_parameter and mtd_info
are added.
Tested on Xilinx Zynq-7000 FPGA board.
Signed-off-by: Takahiro Kuwano
---
Changes since v2:
- Fixed typo in comment for spansion_overlaid_erase()
- Fixed expressions for addr and len check in spansion_overlaid_erase()
- Added device ID check to make the changes effective for S25 only
- Added nor->setup() and fixup hooks based on the following patches
https://patchwork.ozlabs.org/project/uboot/patch/20200904153500.3569-7-p.ya...@ti.com/
https://patchwork.ozlabs.org/project/uboot/patch/20200904153500.3569-8-p.ya...@ti.com/
https://patchwork.ozlabs.org/project/uboot/patch/20200904153500.3569-9-p.ya...@ti.com/
drivers/mtd/spi/spi-nor-core.c | 178 +
drivers/mtd/spi/spi-nor-ids.c | 24 +
drivers/mtd/spi/spi-nor-tiny.c | 73 ++
include/linux/mtd/spi-nor.h| 3 +
4 files changed, 278 insertions(+)
diff --git a/drivers/mtd/spi/spi-nor-core.c b/drivers/mtd/spi/spi-nor-core.c
index 5264d24fd0..98811ce8cc 100644
--- a/drivers/mtd/spi/spi-nor-core.c
+++ b/drivers/mtd/spi/spi-nor-core.c
@@ -466,6 +466,7 @@ static int set_4byte(struct spi_nor *nor, const struct
flash_info *info,
case SNOR_MFR_ISSI:
case SNOR_MFR_MACRONIX:
case SNOR_MFR_WINBOND:
+ case SNOR_MFR_CYPRESS:
if (need_wren)
write_enable(nor);
@@ -730,6 +731,54 @@ erase_err:
return ret;
}
+#ifdef CONFIG_SPI_FLASH_SPANSION
+/*
+ * Erase for Spansion/Cypress Flash devices that has overlaid 4KB sectors at
+ * the top and/or bottom.
+ */
+static int spansion_overlaid_erase(struct mtd_info *mtd,
+ struct erase_info *instr)
+{
+ struct spi_nor *nor = mtd_to_spi_nor(mtd);
+ struct erase_info instr_4k;
+ u8 opcode;
+ u32 erasesize;
+ int ret;
+
+ /* Perform default erase operation (non-overlaid portion is erased) */
+ ret = spi_nor_erase(mtd, instr);
+ if (ret)
+ return ret;
+
+ /* Backup default erase opcode and size */
+ opcode = nor->erase_opcode;
+ erasesize = mtd->erasesize;
+
+ /*
+* Erase 4KB sectors. Use the possible max length of 4KB sector region.
+* The Flash just ignores the command if the address is not configured
+* as 4KB sector and reports ready status immediately.
+*/
+ instr_4k.len = SZ_128K;
+ nor->erase_opcode = SPINOR_OP_BE_4K_4B;
+ mtd->erasesize = SZ_4K;
+ if (instr->addr == 0) {
+ instr_4k.addr = 0;
+ ret = spi_nor_erase(mtd, &instr_4k);
+ }
+ if (!ret && instr->addr + instr->len == mtd->size) {
+ instr_4k.addr = mtd->size - instr_4k.len;
+ ret = spi_nor_erase(mtd, &instr_4k);
+ }
+
+ /* Restore erase opcode and size */
+ nor->erase_opcode = opcode;
+ mtd->erasesize = erasesize;
+
+ return ret;
+}
+#endif
+
#if defined(CONFIG_SPI_FLASH_STMICRO) || defined(CONFIG_SPI_FLASH_SST)
/* Write status register and ensure bits in mask match written values */
static int write_sr_and_check(struct spi_nor *nor, u8 status_new, u8 mask)
@@ -1550,6 +1599,60 @@ static int spansion_read_cr_quad_enable(struct spi_nor
*nor)
return 0;
}
+/**
+ * spansion_quad_enable_volatile() - enable Quad I/O mode in volatile register.
+ * @nor: pointer to a 'struct spi_nor'
+ *
+ * It is recommended to update volatile registers in the field application due
+ * to a risk of the non-volatile registers corruption by power interrupt. This
+ * function sets Quad Enable bit in CFR1 volatile.
+ *
+ * Return: 0 on success, -errno otherwise.
+ */
+static int spansion_quad_enable_volatile(struct spi_nor *nor)
+{
+ struct spi_mem_op op =
+ SPI_MEM_OP(SPI_MEM_OP_CMD(SPINOR_OP_WRAR, 1),
+ SPI_MEM_OP_ADDR(nor->addr_width,
+ SPINOR_REG_ADDR_CFR1V, 1),
+ SPI_MEM_OP_NO_DUMMY,
+ SPI_MEM_OP_DATA_OUT(1, NULL, 1));
+ u8 cr;
+ int ret;
+
+ /* Check current Quad Enable bit value. */
+ ret = read_cr(nor);
+ if (ret < 0) {
+ dev_dbg(nor->dev,
+ "error while reading configuration register\n");
+ return -EINVAL;
+ }
+
+ if (ret & CR_QUAD_EN_SPAN)
+ return 0;
+
+ cr = ret | CR_QUAD_EN_SPAN;
+
+
Re: [PATCH] arm: mvebu: Espressobin: Fix checks against machine compatible strings
On 01.10.20 12:48, Pali Rohár wrote:
On Thursday 01 October 2020 12:42:21 Heinrich Schuchardt wrote:
On 01.10.20 10:23, Pali Rohár wrote:
On Tuesday 29 September 2020 14:43:25 Andre Heider wrote:
On 29/09/2020 14:38, Pali Rohár wrote:
On Tuesday 29 September 2020 14:34:26 Andre Heider wrote:
The patches changing the compatible strings to the ones used by Linux have
not been merged yet, so fix the checks to use the current in-tree ones.
Reported-by: Pali Rohár
Signed-off-by: Andre Heider
---
board/Marvell/mvebu_armada-37xx/board.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index eacee15cb3..2bfc7171c4 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -88,14 +88,14 @@ int board_late_init(void)
if (env_get("fdtfile"))
return 0;
- if (!of_machine_is_compatible("globalscale,espressobin"))
+ if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
Linux v5.9-rc6
arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts:19:
compatible = "globalscale,espressobin", "marvell,armada3720",
"marvell,armada3710";
This value has been in Linux since 2016.
We should be able to boot with the U-Boot internal device tree into Linux.
Hello Heinrich!
This is not possible yet as Linux kernel uses different comphy driver as
U-Boot and device tree structure for these drivers are different.
So you cannot use U-Boot internal device tree file for booting Linux
kernel.
So fix the device tree in U-Boot and not the C code, please.
Yes, this is ongoing work, Marek is working on replacing U-Boot comphy
driver one from Linux kernel and Andre is working on synchronizing DTS
files from Linux kernel to U-Boot. But these works are not complete yet
and we need non-broken U-Boot 2020.10 release.
Thanks for the explanation Pali. Yes, this fix is only temporarily for
the upcoming release. The DT sync will continue after the 2020.10
release.
Thanks,
Stefan
Best regards
Heinrich
return 0;
/* If the memory controller has been configured for DDR4, we're running
on v7 */
ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >>
A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
& A3700_MC_CTRL2_SDRAM_TYPE_MASK) ==
A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
- emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
+ emmc = of_machine_is_compatible("marvell,armada-3720-espressobin-emmc");
I run 'git grep marvell,armada-3720-espressobin-emmc origin/master' just
for verification... but it returned me empty result.
So marvell,armada-3720-espressobin-emmc is not correct too and therefore
this patch does not still fix this problem.
Right, without my set there is no support for the eMMC board in u-boot at
all. We could remove the code, but I figured that'll be just unnecessary
churn. The check evaluates correctly to non-emmc, so it works for the
in-tree board just fine. This is the smaller fixup for the release.
Ok, Lets include it!
Reviewed-by: Pali Rohár
Stefan, can you send this patch for U-Boot 2020.10 release?
Maybe following patch for documentation (doc/README.marvell) may be useful to:
https://patchwork.ozlabs.org/project/uboot/patch/20200925075416.16124-1-p...@kernel.org/
if (ddr4 && emmc)
env_set("fdtfile",
"marvell/armada-3720-espressobin-v7-emmc.dtb");
--
2.28.0
Viele Grüße,
Stefan
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-51 Fax: (+49)-8142-66989-80 Email: s...@denx.de
Re: [PATCH] arm: mvebu: Espressobin: Fix checks against machine compatible strings
On Thursday 01 October 2020 12:42:21 Heinrich Schuchardt wrote:
> On 01.10.20 10:23, Pali Rohár wrote:
> > On Tuesday 29 September 2020 14:43:25 Andre Heider wrote:
> >> On 29/09/2020 14:38, Pali Rohár wrote:
> >>> On Tuesday 29 September 2020 14:34:26 Andre Heider wrote:
> The patches changing the compatible strings to the ones used by Linux
> have
> not been merged yet, so fix the checks to use the current in-tree ones.
>
> Reported-by: Pali Rohár
> Signed-off-by: Andre Heider
> ---
> board/Marvell/mvebu_armada-37xx/board.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/board/Marvell/mvebu_armada-37xx/board.c
> b/board/Marvell/mvebu_armada-37xx/board.c
> index eacee15cb3..2bfc7171c4 100644
> --- a/board/Marvell/mvebu_armada-37xx/board.c
> +++ b/board/Marvell/mvebu_armada-37xx/board.c
> @@ -88,14 +88,14 @@ int board_late_init(void)
> if (env_get("fdtfile"))
> return 0;
> -if (!of_machine_is_compatible("globalscale,espressobin"))
> +if
> (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
>
> Linux v5.9-rc6
> arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts:19:
> compatible = "globalscale,espressobin", "marvell,armada3720",
> "marvell,armada3710";
>
> This value has been in Linux since 2016.
>
> We should be able to boot with the U-Boot internal device tree into Linux.
Hello Heinrich!
This is not possible yet as Linux kernel uses different comphy driver as
U-Boot and device tree structure for these drivers are different.
So you cannot use U-Boot internal device tree file for booting Linux
kernel.
> So fix the device tree in U-Boot and not the C code, please.
Yes, this is ongoing work, Marek is working on replacing U-Boot comphy
driver one from Linux kernel and Andre is working on synchronizing DTS
files from Linux kernel to U-Boot. But these works are not complete yet
and we need non-broken U-Boot 2020.10 release.
> Best regards
>
> Heinrich
>
> return 0;
> /* If the memory controller has been configured for DDR4, we're
> running on v7 */
> ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >>
> A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
> & A3700_MC_CTRL2_SDRAM_TYPE_MASK) ==
> A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
> -emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
> +emmc =
> of_machine_is_compatible("marvell,armada-3720-espressobin-emmc");
> >>>
> >>> I run 'git grep marvell,armada-3720-espressobin-emmc origin/master' just
> >>> for verification... but it returned me empty result.
> >>>
> >>> So marvell,armada-3720-espressobin-emmc is not correct too and therefore
> >>> this patch does not still fix this problem.
> >>
> >> Right, without my set there is no support for the eMMC board in u-boot at
> >> all. We could remove the code, but I figured that'll be just unnecessary
> >> churn. The check evaluates correctly to non-emmc, so it works for the
> >> in-tree board just fine. This is the smaller fixup for the release.
> >
> > Ok, Lets include it!
> >
> > Reviewed-by: Pali Rohár
> >
> > Stefan, can you send this patch for U-Boot 2020.10 release?
> >
> > Maybe following patch for documentation (doc/README.marvell) may be useful
> > to:
> > https://patchwork.ozlabs.org/project/uboot/patch/20200925075416.16124-1-p...@kernel.org/
> >
> >>>
> if (ddr4 && emmc)
> env_set("fdtfile",
> "marvell/armada-3720-espressobin-v7-emmc.dtb");
> --
> 2.28.0
>
> >>
>
Re: [PATCH] arm: mvebu: Espressobin: Fix checks against machine compatible strings
On 01.10.20 10:23, Pali Rohár wrote:
> On Tuesday 29 September 2020 14:43:25 Andre Heider wrote:
>> On 29/09/2020 14:38, Pali Rohár wrote:
>>> On Tuesday 29 September 2020 14:34:26 Andre Heider wrote:
The patches changing the compatible strings to the ones used by Linux have
not been merged yet, so fix the checks to use the current in-tree ones.
Reported-by: Pali Rohár
Signed-off-by: Andre Heider
---
board/Marvell/mvebu_armada-37xx/board.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/board/Marvell/mvebu_armada-37xx/board.c
b/board/Marvell/mvebu_armada-37xx/board.c
index eacee15cb3..2bfc7171c4 100644
--- a/board/Marvell/mvebu_armada-37xx/board.c
+++ b/board/Marvell/mvebu_armada-37xx/board.c
@@ -88,14 +88,14 @@ int board_late_init(void)
if (env_get("fdtfile"))
return 0;
- if (!of_machine_is_compatible("globalscale,espressobin"))
+ if (!of_machine_is_compatible("marvell,armada-3720-espressobin"))
Linux v5.9-rc6
arch/arm64/boot/dts/marvell/armada-3720-espressobin.dts:19:
compatible = "globalscale,espressobin", "marvell,armada3720",
"marvell,armada3710";
This value has been in Linux since 2016.
We should be able to boot with the U-Boot internal device tree into Linux.
So fix the device tree in U-Boot and not the C code, please.
Best regards
Heinrich
return 0;
/* If the memory controller has been configured for DDR4, we're running
on v7 */
ddr4 = ((readl(A3700_CH0_MC_CTRL2_REG) >>
A3700_MC_CTRL2_SDRAM_TYPE_OFFS)
& A3700_MC_CTRL2_SDRAM_TYPE_MASK) ==
A3700_MC_CTRL2_SDRAM_TYPE_DDR4;
- emmc = of_machine_is_compatible("globalscale,espressobin-emmc");
+ emmc = of_machine_is_compatible("marvell,armada-3720-espressobin-emmc");
>>>
>>> I run 'git grep marvell,armada-3720-espressobin-emmc origin/master' just
>>> for verification... but it returned me empty result.
>>>
>>> So marvell,armada-3720-espressobin-emmc is not correct too and therefore
>>> this patch does not still fix this problem.
>>
>> Right, without my set there is no support for the eMMC board in u-boot at
>> all. We could remove the code, but I figured that'll be just unnecessary
>> churn. The check evaluates correctly to non-emmc, so it works for the
>> in-tree board just fine. This is the smaller fixup for the release.
>
> Ok, Lets include it!
>
> Reviewed-by: Pali Rohár
>
> Stefan, can you send this patch for U-Boot 2020.10 release?
>
> Maybe following patch for documentation (doc/README.marvell) may be useful to:
> https://patchwork.ozlabs.org/project/uboot/patch/20200925075416.16124-1-p...@kernel.org/
>
>>>
if (ddr4 && emmc)
env_set("fdtfile",
"marvell/armada-3720-espressobin-v7-emmc.dtb");
--
2.28.0
>>
[PATCH v4 2/2] arm: rmobile: Add HopeRun HiHope RZ/G2M board support
The HiHope RZ/G2M board from HopeRun consists of main board
(HopeRun HiHope RZ/G2M main board) and sub board(HopeRun
HiHope RZ/G2M sub board). The HiHope RZ/G2M sub board sits
below the HiHope RZ/G2M main board.
DTS files apart from r8a774a1-hihope-rzg2m-u-boot.dts and
r8a774a1-u-boot.dtsi have been imported from Linux kernel 5.9-rc4 commit
f4d51dffc6c0 ("Linux 5.9-rc4")
This patch adds the required board support to boot HopeRun HiHope
RZ/G2M board.
Signed-off-by: Biju Das
Reviewed-by: Lad Prabhakar
---
V3->V4
* Added USB0 channel0 Host support
V2->V3
* Reworked as per Marek's suggestion
* Added rzg2_get_cpu_type function to get cpu_type by matching TFA
compatible string
* Removed SoC family type Enum
Ref:
https://patchwork.ozlabs.org/project/uboot/patch/20200922160317.16296-3-biju.das...@bp.renesas.com/
V1->V2
* Fixed indentation for R8A774A1 config
* Used GPIO hog for setting WLAN/BT REG ON
* Removed USB related initialization
Ref:
https://patchwork.ozlabs.org/project/uboot/patch/20200918160307.14323-2-biju.das...@bp.renesas.com/
V1:-
* New Patch
Ref:
https://patchwork.ozlabs.org/project/uboot/patch/20200915143630.7678-5-biju.das...@bp.renesas.com/
---
arch/arm/dts/Makefile | 1 +
arch/arm/dts/hihope-common.dtsi | 377 ++
arch/arm/dts/hihope-rev4.dtsi | 124 ++
arch/arm/dts/hihope-rzg2-ex.dtsi | 92 +
arch/arm/dts/r8a774a1-hihope-rzg2m-ex.dts | 21 +
arch/arm/dts/r8a774a1-hihope-rzg2m-u-boot.dts | 27 ++
arch/arm/dts/r8a774a1-hihope-rzg2m.dts| 37 ++
arch/arm/dts/r8a774a1-u-boot.dtsi | 55 +++
arch/arm/mach-rmobile/Kconfig.64 | 16 +-
board/hoperun/hihope-rzg2/Kconfig | 15 +
board/hoperun/hihope-rzg2/MAINTAINERS | 6 +
board/hoperun/hihope-rzg2/Makefile| 9 +
board/hoperun/hihope-rzg2/hihope-rzg2.c | 75
configs/hihope_rzg2_defconfig | 75
include/configs/hihope-rzg2.h | 20 +
15 files changed, 949 insertions(+), 1 deletion(-)
create mode 100644 arch/arm/dts/hihope-common.dtsi
create mode 100644 arch/arm/dts/hihope-rev4.dtsi
create mode 100644 arch/arm/dts/hihope-rzg2-ex.dtsi
create mode 100644 arch/arm/dts/r8a774a1-hihope-rzg2m-ex.dts
create mode 100644 arch/arm/dts/r8a774a1-hihope-rzg2m-u-boot.dts
create mode 100644 arch/arm/dts/r8a774a1-hihope-rzg2m.dts
create mode 100644 arch/arm/dts/r8a774a1-u-boot.dtsi
create mode 100644 board/hoperun/hihope-rzg2/Kconfig
create mode 100644 board/hoperun/hihope-rzg2/MAINTAINERS
create mode 100644 board/hoperun/hihope-rzg2/Makefile
create mode 100644 board/hoperun/hihope-rzg2/hihope-rzg2.c
create mode 100644 configs/hihope_rzg2_defconfig
create mode 100644 include/configs/hihope-rzg2.h
diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index 72b6fe1a3e..0de6bce873 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -784,6 +784,7 @@ dtb-$(CONFIG_RCAR_GEN2) += \
dtb-$(CONFIG_RCAR_GEN3) += \
r8a774a1-beacon-rzg2m-kit.dtb \
+ r8a774a1-hihope-rzg2m-u-boot.dtb \
r8a77950-ulcb-u-boot.dtb \
r8a77950-salvator-x-u-boot.dtb \
r8a77960-ulcb-u-boot.dtb \
diff --git a/arch/arm/dts/hihope-common.dtsi b/arch/arm/dts/hihope-common.dtsi
new file mode 100644
index 00..51eb74fbe9
--- /dev/null
+++ b/arch/arm/dts/hihope-common.dtsi
@@ -0,0 +1,377 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Device Tree Source for the HiHope RZ/G2H Rev.4.0 and
+ * HiHope RZ/G2[MN] Rev.[2.0/3.0/4.0] main board common parts
+ *
+ * Copyright (C) 2020 Renesas Electronics Corp.
+ */
+
+#include
+
+/ {
+ aliases {
+ serial0 = &scif2;
+ serial1 = &hscif0;
+ };
+
+ chosen {
+ bootargs = "ignore_loglevel";
+ stdout-path = "serial0:115200n8";
+ };
+
+ hdmi0-out {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi0_con: endpoint {
+ remote-endpoint = <&rcar_dw_hdmi0_out>;
+ };
+ };
+ };
+
+ leds {
+ compatible = "gpio-leds";
+
+ led1 {
+ gpios = <&gpio6 12 GPIO_ACTIVE_HIGH>;
+ };
+
+ led2 {
+ gpios = <&gpio6 13 GPIO_ACTIVE_HIGH>;
+ };
+
+ led3 {
+ gpios = <&gpio0 0 GPIO_ACTIVE_HIGH>;
+ };
+
+ led4 {
+ gpios = <&gpio6 11 GPIO_ACTIVE_HIGH>;
+ };
+ };
+
+ reg_1p8v: regulator0 {
+ compatible = "regulator-fixed";
+ regulator-name = "fixed-1.8V";
+ regulator-min-microvolt = <180>;
+ regulator-max-microvolt = <180>;
+ regulator-boot-on;
+
[PATCH v4 1/2] arm: rmobile: Add PRR CPU ID macros for RZ/G2[HMNE]
RZ/G2 SoC's are identical to R-Car Gen3 SoC's apart from some automotive peripherals and they also share the same PRR CPU ID's. RZ/G2H (a.k.a R8A774E1) is identical to R-Car H3 SoC. RZ/G2M (a.k.a R8A774A1) is identical to R-Car M3W SoC. RZ/G2N (a.k.a R8A774B1) is identical to R-Car M3N SoC. RZ/G2E (a.k.a R8A774C0) is identical to R-Car E3 SoC. Signed-off-by: Biju Das Reviewed-by: Lad Prabhakar --- v3->v4 * Dropped CPU info reporting logic for RZ/G2. Will address this later. * Added PRRID's for RZG2[HMNE] v2->v3 * Reworked as per Marek's suggestion * Added rzg2_get_cpu_type function to get cpu_type by matching TFA compatible string * Removed SoC family type Enum (Ref: https://patchwork.ozlabs.org/project/uboot/patch/20200922160317.16296-2-biju.das...@bp.renesas.com/) v1->v2: * Add comment's related to loop logic (ref: https://patchwork.ozlabs.org/project/uboot/patch/20200918160307.14323-1-biju.das...@bp.renesas.com/) v1: * New patch (ref:https://patchwork.ozlabs.org/project/uboot/patch/20200915143630.7678-4-biju.das...@bp.renesas.com/) --- arch/arm/mach-rmobile/include/mach/rmobile.h | 4 1 file changed, 4 insertions(+) diff --git a/arch/arm/mach-rmobile/include/mach/rmobile.h b/arch/arm/mach-rmobile/include/mach/rmobile.h index a50249dc96..bd4bd01b75 100644 --- a/arch/arm/mach-rmobile/include/mach/rmobile.h +++ b/arch/arm/mach-rmobile/include/mach/rmobile.h @@ -27,6 +27,10 @@ /* PRR CPU IDs */ #define RMOBILE_CPU_TYPE_SH73A00x37 #define RMOBILE_CPU_TYPE_R8A7740 0x40 +#define RMOBILE_CPU_TYPE_R8A774A1 0x52 +#define RMOBILE_CPU_TYPE_R8A774B1 0x55 +#define RMOBILE_CPU_TYPE_R8A774C0 0x57 +#define RMOBILE_CPU_TYPE_R8A774E1 0x4F #define RMOBILE_CPU_TYPE_R8A7790 0x45 #define RMOBILE_CPU_TYPE_R8A7791 0x47 #define RMOBILE_CPU_TYPE_R8A7792 0x4A -- 2.17.1
[PATCH] ARM: dts: stm32: Add missing dm-spl props for SPI NOR on AV96
The u-boot,dm-spl DT props are missing on AV96, hence the pinmux and
flash0 nodes are not included in the reduced SPL DT. This prevents
SPI NOR boot from working at all. Fix this by filling them in.
Signed-off-by: Marek Vasut
Cc: Patrick Delaunay
Cc: Patrice Chotard
---
arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi | 21 +
1 file changed, 21 insertions(+)
diff --git a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
index c73318488d..9d3db20876 100644
--- a/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
+++ b/arch/arm/dts/stm32mp15xx-dhcor-u-boot.dtsi
@@ -21,6 +21,10 @@
};
};
+&flash0 {
+ u-boot,dm-spl;
+};
+
&gpiof {
snor-nwp {
gpio-hog;
@@ -49,6 +53,23 @@
u-boot,dm-spl;
};
+&qspi_clk_pins_a {
+ u-boot,dm-spl;
+ pins {
+ u-boot,dm-spl;
+ };
+};
+
+&qspi_bk1_pins_a {
+ u-boot,dm-spl;
+ pins1 {
+ u-boot,dm-spl;
+ };
+ pins2 {
+ u-boot,dm-spl;
+ };
+};
+
&rcc {
st,clksrc = <
CLK_MPU_PLL1P
--
2.28.0
[U-Boot] Please pull from u-boot-i2c for 2020.10
Hello Tom,
late bugfix for 2020.10 ...
The following changes since commit 5f9070a4a48d2db1968b86a54e82724dbe2a6de6:
optee: copy FDT OP-TEE related nodes before generic FDT changes (2020-09-30
11:31:13 -0400)
are available in the Git repository at:
https://gitlab.denx.de/u-boot/custodians/u-boot-i2c.git
tags/late-bugfix-for-2020.10
for you to fetch changes up to 86a73b0905430c0a637280d33afa498b366f4d23:
i2c: rcar_i2c: Fix i2c read/write errors (2020-10-01 05:41:44 +0200)
i2c late bugfix for v2020.10
- rcar_i2c: Fix i2c read/write errors
fixes commit 7c8f821e ("i2c: rcar_i2c: Set the slave address from
rcar_i2c_xfer")
Lad Prabhakar (1):
i2c: rcar_i2c: Fix i2c read/write errors
drivers/i2c/rcar_i2c.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
travis builds fine:
https://travis-ci.org/github/hsdenx/u-boot-i2c/builds/731810194
Thanks!
bye,
Heiko
--
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-52 Fax: +49-8142-66989-80 Email: h...@denx.de
Re: [RFC PATCH v2 1/1] Fix missing __udivdi3 in SquashFS implementation.
Ok, Thanks. Patch is ready, I'll send it after some extended testing on my system (vocore2). Regards Mauro On 10/1/20 10:56 AM, Miquel Raynal wrote: > Hi Mauro, > > Mauro Condarelli wrote on Thu, 1 Oct 2020 10:53:30 > +0200: > >> Correcting myself. >> See below. >> >> On 10/1/20 10:41 AM, Mauro Condarelli wrote: >>> Thanks for Your review. >>> >>> On 10/1/20 9:59 AM, Miquel Raynal wrote: Hello, Thomas Petazzoni wrote on Thu, 1 Oct 2020 09:28:41 +0200: > Hello, > > On Wed, 30 Sep 2020 17:45:11 +0200 > Mauro Condarelli wrote: > >> Use right shift to avoid 64-bit divisions. >> >> These divisions are needed to convert from file length (potentially >> over 32-bit range) to block number, so result and remainder are >> guaranteed to fit in 32-bit integers. >> >> Signed-off-by: Mauro Condarelli > Perhaps the commit log should contain an example U-Boot > configuration/platform where it fails to build. Indeed, we did test the > SquashFS code on ARM 32-bit, and it built and worked fine. >>> This fails on mips32, specifically for the vocore2 board. >>> Problem here is __udivdi3 is not defined for this architecture >>> while it is for ARM32. >>> My (limited) understanding suggests it should be removed for ARM >>> since its usage has been (is being?) weeded out from both kernel >>> and u-boot. This is not my call, though. >>> >>> I will add a note to v3. >>> >> --- >> >> Changes in v2: >> - replace division with right shift (Daniel Schwierzeck). >> - remove vocore2-specific change (Daniel Schwierzeck). >> - add warning to Kconfig about CONFIG_SYS_MALLOC_LEN (Tom Rini). >> >> fs/squashfs/Kconfig | 2 ++ >> fs/squashfs/sqfs.c | 30 +++--- >> fs/squashfs/sqfs_inode.c | 6 +++--- >> 3 files changed, 20 insertions(+), 18 deletions(-) >> >> diff --git a/fs/squashfs/Kconfig b/fs/squashfs/Kconfig >> index 54ab1618f1..7c3f83d007 100644 >> --- a/fs/squashfs/Kconfig >> +++ b/fs/squashfs/Kconfig >> @@ -9,3 +9,5 @@ config FS_SQUASHFS >>filesystem use, for archival use (i.e. in cases where a >> .tar.gz file >>may be used), and in constrained block device/memory systems >> (e.g. >>embedded systems) where low overhead is needed. >> + WARNING: if compression is enabled SquashFS needs a large >> amount >> + of dynamic memory; make sure CONFIG_SYS_MALLOC_LEN >= 0x4000. >> > This change is completely unrelated, and should be in a separate patch. I was about to tell you the same thing, this warning is useful but should definitely lay into its own commit. >>> Will do in v3. >>> >>> >> -n_blks = DIV_ROUND_UP(table_size + table_offset, >> - ctxt.cur_dev->blksz); >> +n_blks = (table_size + table_offset + >> ctxt.cur_dev->blksz - 1) >> >> +ctxt.cur_dev->log2blksz; > I understand why you have to add blksz - 1 before doing the shift, but > I find that it's overall a lot less readable/clear. Is there a way to > do better ? > > We could use DIV_ROUND_UP_ULL() I guess. >>> I did not do this because DIV_ROUND_UP() is in a global >>> (non-architecture-specific) >>> header and it unconditionally uses division; I did not know how to handle >>> this. >>> Would a comment suffice to clarify intent? Something like: >>> >>> n_blks = (table_size + table_offset + ctxt.cur_dev->blksz - 1) >> >>> ctxt.cur_dev->log2blksz; /* ROUND_UP division */ >>> >>> Note: this problem stays even if we roll-back to use do_div(); see below. >> actually include/linux/kernel.h defines both DIV_ROUND_DOWN_ULL() >> and DIV_ROUND_UP_ULL() I suppose we should use those in all cases. >> >> >> else >> -blk_list_size = file_size / blk_size; >> +blk_list_size = file_size > LOG2(blk_size); > Very bad mistake here: > should be >>. >>> Sorry, my bad. >>> Corrected for v3. >>> I personally highly dislike replacing divisions into shifts. I think it's too much effort when trying to understand code you did not write yourself. Is it possible to use something like do_div? plus, you can check the remainder to be 0 in this case. >>> Please make up your mind about this. >>> I personally tend to agree with Miquèl and my v1 patch used >>> do_div() exclusively (i did not use even the lldiv() wrapper), but >>> I will not insist either way... just let me know what's considered >>> better. >> As said above: it seems using the macros is both "standard" and >> safer than using shifts. >> If I get a go-ahead I'll use those macros in v3. > I think we all agree using these macros is much nicer, readable and > probably almost as fa
Re: STM32MP1: Adding TF-A causes kernel errors
On 30.09.20 11:51, Jan Kiszka wrote: > [BCC'ed TF-A only, migrating to u-boot, including folks involved there] > > On 30.09.20 11:20, Yann GAUTIER wrote: >> Hi Jan, >> >> After discussing with my colleagues, it seems there are 2 issues there. >> One patch is missing in U-Boot: >> http://patchwork.ozlabs.org/project/uboot/patch/20200605092244.1.I773bf523d9f4d1a6212483d030e34113b832a779@changeid/ >> > > I can confirm that this resolves the errors I've seen. > Picking up again, this time for OP-TEE: Do I need more patches, wherever, to get that one running as well? NOTICE: CPU: STM32MP157AAA Rev.B NOTICE: Model: STMicroelectronics STM32MP157C eval daughter on eval mother NOTICE: Board: MB1263 Var1 Rev.C-01 NOTICE: BL2: v2.3(): NOTICE: BL2: Built : 10:11:55, Sep 30 2020 NOTICE: BL2: Booting BL32 I/TC: Early console on UART#4 I/TC: I/TC: Pager is enabled. Hashes: 2144 bytes I/TC: Pager pool size: 100kB I/TC: No non-secure external DT I/TC: Embedded DTB found I/TC: OP-TEE version: Unknown (gcc version 8.3.0 (Debian 8.3.0-2)) #2 Thu Oct 1 06:53:58 UTC 2020 arm I/TC: Primary CPU initializing I/TC: Platform stm32mp1: flavor PLATFORM_FLAVOR - DT stm32mp157c-ev1.dts I/TC: RCC is non-secure I/TC: DTB enables console (non-secure) I/TC: Primary CPU switching to normal world boot U-Boot 2020.07 (Oct 01 2020 - 06:54:18 +) CPU: STM32MP157AAA Rev.B Model: STMicroelectronics STM32MP157C eval daughter on eval mother Board: stm32mp1 in trusted mode (st,stm32mp157c-ev1) Board: MB1263 Var1.0 Rev.C-01 DRAM: 1 GiB Clocks: - MPU : 650 MHz - MCU : 208.878 MHz - AXI : 266.500 MHz - PER : 24 MHz - DDR : 533 MHz NAND: 1024 MiB MMC: STM32 SD/MMC: 0, STM32 SD/MMC: 1 Loading Environment from EXT4... ** File not found /uboot.env ** ** Unable to read "/uboot.env" from mmc0:7 ** In:serial Out: serial Err: serial Net: eth0: ethernet@5800a000 Hit any key to stop autoboot: 0 Boot over mmc0! Saving Environment to EXT4... Unsupported feature metadata_csum found, not writing. ** Unable to write "/uboot.env" from mmc0:7 ** Failed (1) switch to partitions #0, OK mmc0 is current device Scanning mmc 0:7... Found U-Boot script /boot/boot.scr 562 bytes read in 26 ms (20.5 KiB/s) ## Executing script at c410 57629 bytes read in 38 ms (1.4 MiB/s) 9474560 bytes read in 429 ms (21.1 MiB/s) 4410487 bytes read in 212 ms (19.8 MiB/s) Kernel image @ 0xc200 [ 0x00 - 0x909200 ] ## Flattened Device Tree blob at c400 Booting using the fdt blob at 0xc400 Loading Ramdisk to cfbcb000, end cc77 ... OK Loading Device Tree to cfbb9000, end cfbca11c ... OK OP-TEE: revision 3.10 Starting kernel ... I/TC: Secondary CI/TC: Secondary CPU 1 switching to normal world boot E/TC:1 tzc_it_handler:19 TZC permission failure E/TC:1 dump_fail_filter:417 Overrun violation on filter 0 E/TC:1 dump_fail_filter:420 Permission violation on filter 0 E/TC:1 dump_fail_filter:430 Violation @0xff00, non-secure privileged read, AXI ID 4a0 E/TC:1 Panic Besides the U-Boot patch I also have the kernel fixup for gpu_reserved applied. Thanks, Jan
[v2, 13/16] arm: socfpga: mailbox: Add 'SYSTEM_RESET' PSCI support to mbox_reset_cold()
From: Chee Hong Ang
mbox_reset_cold() will invoke ATF's PSCI service when running in
non-secure mode (EL2).
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/mailbox_s10.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/arch/arm/mach-socfpga/mailbox_s10.c
b/arch/arm/mach-socfpga/mailbox_s10.c
index 18d44924e6..429444f069 100644
--- a/arch/arm/mach-socfpga/mailbox_s10.c
+++ b/arch/arm/mach-socfpga/mailbox_s10.c
@@ -11,6 +11,7 @@
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -398,6 +399,9 @@ error:
int mbox_reset_cold(void)
{
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+ psci_system_reset();
+#else
int ret;
ret = mbox_send_cmd(MBOX_ID_UBOOT, MBOX_REBOOT_HPS, MBOX_CMD_DIRECT,
@@ -406,6 +410,7 @@ int mbox_reset_cold(void)
/* mailbox sent failure, wait for watchdog to kick in */
hang();
}
+#endif
return 0;
}
--
2.13.0
[v2, 12/16] arm: socfpga: soc64: Add ATF support for FPGA reconfig driver
From: Chee Hong Ang
In non-secure mode (EL2), FPGA reconfiguration driver calls the
SMC/PSCI services provided by ATF to configure the FPGA.
Signed-off-by: Chee Hong Ang
---
drivers/fpga/intel_sdm_mb.c | 139
1 file changed, 139 insertions(+)
diff --git a/drivers/fpga/intel_sdm_mb.c b/drivers/fpga/intel_sdm_mb.c
index 9a1dc2c0c8..f5fd9a14c2 100644
--- a/drivers/fpga/intel_sdm_mb.c
+++ b/drivers/fpga/intel_sdm_mb.c
@@ -8,11 +8,149 @@
#include
#include
#include
+#include
#include
+#include
#define RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS 6
#define RECONFIG_STATUS_INTERVAL_DELAY_US 100
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+
+#define BITSTREAM_CHUNK_SIZE 0x0
+#define RECONFIG_STATUS_POLL_RETRY_MAX 100
+
+/*
+ * Polling the FPGA configuration status.
+ * Return 0 for success, non-zero for error.
+ */
+static int reconfig_status_polling_resp(void)
+{
+ int ret;
+ unsigned long start = get_timer(0);
+
+ while (1) {
+ ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_ISDONE, NULL, 0,
+NULL, 0);
+
+ if (!ret)
+ return 0; /* configuration success */
+
+ if (ret != INTEL_SIP_SMC_STATUS_BUSY)
+ return ret;
+
+ if (get_timer(start) > RECONFIG_STATUS_POLL_RESP_TIMEOUT_MS)
+ return -ETIMEDOUT; /* time out */
+
+ puts(".");
+ udelay(RECONFIG_STATUS_INTERVAL_DELAY_US);
+ WATCHDOG_RESET();
+ }
+
+ return -ETIMEDOUT;
+}
+
+static int send_bitstream(const void *rbf_data, size_t rbf_size)
+{
+ int i;
+ u64 res_buf[3];
+ u64 args[2];
+ u32 xfer_count = 0;
+ int ret, wr_ret = 0, retry = 0;
+ size_t buf_size = (rbf_size > BITSTREAM_CHUNK_SIZE) ?
+ BITSTREAM_CHUNK_SIZE : rbf_size;
+
+ while (rbf_size || xfer_count) {
+ if (!wr_ret && rbf_size) {
+ args[0] = (u64)rbf_data;
+ args[1] = buf_size;
+ wr_ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_WRITE,
+ args, 2, NULL, 0);
+
+ debug("wr_ret = %d, rbf_data = %p, buf_size = %08lx\n",
+ wr_ret, rbf_data, buf_size);
+
+ if (wr_ret)
+ continue;
+
+ rbf_size -= buf_size;
+ rbf_data += buf_size;
+
+ if (buf_size >= rbf_size)
+ buf_size = rbf_size;
+
+ xfer_count++;
+ puts(".");
+ } else {
+ ret = invoke_smc(
+ INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE,
+ NULL, 0, res_buf, ARRAY_SIZE(res_buf));
+ if (!ret) {
+ for (i = 0; i < ARRAY_SIZE(res_buf); i++) {
+ if (!res_buf[i])
+ break;
+ xfer_count--;
+ wr_ret = 0;
+ retry = 0;
+ }
+ } else if (ret !=
+ INTEL_SIP_SMC_STATUS_BUSY)
+ return ret;
+ else if (!xfer_count)
+ return INTEL_SIP_SMC_STATUS_ERROR;
+
+ if (++retry >= RECONFIG_STATUS_POLL_RETRY_MAX)
+ return -ETIMEDOUT;
+
+ udelay(2);
+ }
+ WATCHDOG_RESET();
+ }
+
+ return 0;
+}
+
+/*
+ * This is the interface used by FPGA driver.
+ * Return 0 for success, non-zero for error.
+ */
+int intel_sdm_mb_load(Altera_desc *desc, const void *rbf_data, size_t rbf_size)
+{
+ int ret;
+ u64 arg = 1;
+
+ debug("Invoking FPGA_CONFIG_START...\n");
+
+ ret = invoke_smc(INTEL_SIP_SMC_FPGA_CONFIG_START, &arg, 1, NULL, 0);
+
+ if (ret) {
+ puts("Failure in RECONFIG mailbox command!\n");
+ return ret;
+ }
+
+ ret = send_bitstream(rbf_data, rbf_size);
+ if (ret) {
+ puts("Error sending bitstream!\n");
+ return ret;
+ }
+
+ /* Make sure we don't send MBOX_RECONFIG_STATUS too fast */
+ udelay(RECONFIG_STATUS_INTERVAL_DELAY_US);
+
+ debug("Polling with MBOX_RECONFIG_STATUS...\n");
+ ret = reconfig_status_polling_resp();
+ if (ret) {
+ puts("FPGA reconfiguration failed!");
+ return ret;
+ }
+
+ puts("FPGA recon
[v2, 15/16] arm: socfpga: soc64: Skip handoff data access in SSBL
From: Chee Hong Ang
SPL already setup the Clock Manager with the handoff data
from OCRAM. When the Clock Manager's driver get probed again
in SSBL, it shall skip the handoff data access in OCRAM.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/wrap_pll_config_s10.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-socfpga/wrap_pll_config_s10.c
b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
index 3da85791a1..049c5711a8 100644
--- a/arch/arm/mach-socfpga/wrap_pll_config_s10.c
+++ b/arch/arm/mach-socfpga/wrap_pll_config_s10.c
@@ -12,6 +12,7 @@
const struct cm_config * const cm_get_default_config(void)
{
+#ifdef CONFIG_SPL_BUILD
struct cm_config *cm_handoff_cfg = (struct cm_config *)
(S10_HANDOFF_CLOCK + S10_HANDOFF_OFFSET_DATA);
u32 *conversion = (u32 *)cm_handoff_cfg;
@@ -26,7 +27,7 @@ const struct cm_config * const cm_get_default_config(void)
} else if (handoff_clk == S10_HANDOFF_MAGIC_CLOCK) {
return cm_handoff_cfg;
}
-
+#endif
return NULL;
}
--
2.13.0
[v2, 16/16] configs: socfpga: Add defconfig for Agilex and Stratix 10 with ATF support
From: Chee Hong Ang Booting Agilex and Stratix 10 with ATF support. 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) U-Boot proper now starts at 0x20 (CONFIG_SYS_TEXT_BASE). ATF will occupy the address range starting from 0x1000. Signed-off-by: Chee Hong Ang Signed-off-by: Siew Chin Lim --- v2: - Add CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200 - Move board/altera/soc64/fit_spl_atf.sh to board/intel/soc64/fit_spl_atf.sh --- configs/socfpga_agilex_atf_defconfig| 72 configs/socfpga_stratix10_atf_defconfig | 74 + 2 files changed, 146 insertions(+) create mode 100644 configs/socfpga_agilex_atf_defconfig create mode 100644 configs/socfpga_stratix10_atf_defconfig diff --git a/configs/socfpga_agilex_atf_defconfig b/configs/socfpga_agilex_atf_defconfig new file mode 100644 index 00..73ca8d1cca --- /dev/null +++ b/configs/socfpga_agilex_atf_defconfig @@ -0,0 +1,72 @@ +CONFIG_ARM=y +CONFIG_ARM_SMCCC=y +CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds" +CONFIG_ARCH_SOCFPGA=y +CONFIG_SYS_TEXT_BASE=0x20 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_ENV_SIZE=0x1000 +CONFIG_ENV_OFFSET=0x200 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=2 +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_LOAD_FIT_ADDRESS=0x0200 +CONFIG_SPL_FIT_GENERATOR="board/intel/soc64/fit_spl_atf.sh" +CONFIG_BOOTDELAY=5 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="earlycon" +CONFIG_SPL_CACHE=y +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200 +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_HUSH_PARSER=y +CONFIG_SYS_PROMPT="SOCFPGA_AGILEX # " +CONFIG_CMD_MEMTEST=y +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_DEFAULT_DEVICE_TREE="socfpga_agilex_socdk" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_ALTERA_SDRAM=y +CONFIG_DWAPB_GPIO=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_DW=y +CONFIG_DM_MMC=y +CONFIG_MMC_DW=y +CONFIG_MTD=y +CONFIG_SF_DEFAULT_MODE=0x2003 +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_MII=y +CONFIG_DM_RESET=y +CONFIG_SPI=y +CONFIG_CADENCE_QSPI=y +CONFIG_DESIGNWARE_SPI=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_STORAGE=y +CONFIG_DESIGNWARE_WATCHDOG=y +CONFIG_WDT=y +# CONFIG_SPL_USE_TINY_PRINTF is not set +CONFIG_PANIC_HANG=y diff --git a/configs/socfpga_stratix10_atf_defconfig b/configs/socfpga_stratix10_atf_defconfig new file mode 100644 index 00..e0b9c6964c --- /dev/null +++ b/configs/socfpga_stratix10_atf_defconfig @@ -0,0 +1,74 @@ +CONFIG_ARM=y +CONFIG_ARM_SMCCC=y +CONFIG_SPL_LDSCRIPT="arch/arm/mach-socfpga/u-boot-spl-soc64.lds" +CONFIG_ARCH_SOCFPGA=y +CONFIG_SYS_TEXT_BASE=0x20 +CONFIG_SYS_MALLOC_F_LEN=0x2000 +CONFIG_ENV_SIZE=0x1000 +CONFIG_ENV_OFFSET=0x200 +CONFIG_DM_GPIO=y +CONFIG_NR_DRAM_BANKS=2 +CONFIG_TARGET_SOCFPGA_STRATIX10_SOCDK=y +CONFIG_IDENT_STRING="socfpga_stratix10" +CONFIG_SPL_FS_FAT=y +CONFIG_SPL_TEXT_BASE=0xFFE0 +CONFIG_FIT=y +CONFIG_SPL_LOAD_FIT=y +CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200 +CONFIG_SPL_FIT_GENERATOR="board/intel/soc64/fit_spl_atf.sh" +CONFIG_BOOTDELAY=5 +CONFIG_USE_BOOTARGS=y +CONFIG_BOOTARGS="earlycon" +CONFIG_SPL_SPI_LOAD=y +CONFIG_SYS_SPI_U_BOOT_OFFS=0x0200 +CONFIG_SPL_ATF=y +CONFIG_SPL_ATF_NO_PLATFORM_PARAM=y +CONFIG_HUSH_PARSER=y +CONFIG_SYS_PROMPT="SOCFPGA_STRATIX10 # " +CONFIG_CMD_MEMTEST=y +# CONFIG_CMD_FLASH is not set +CONFIG_CMD_GPIO=y +CONFIG_CMD_I2C=y +CONFIG_CMD_MMC=y +CONFIG_CMD_SPI=y +CONFIG_CMD_USB=y +CONFIG_CMD_DHCP=y +CONFIG_CMD_MII=y +CONFIG_CMD_PING=y +CONFIG_CMD_CACHE=y +CONFIG_CMD_EXT4=y +CONFIG_CMD_FAT=y +CONFIG_CMD_FS_GENERIC=y +CONFIG_DEFAULT_DEVICE_TREE="socfpga_stratix10_socdk" +CONFIG_ENV_IS_IN_MMC=y +CONFIG_SYS_RELOC_GD_ENV_ADDR=y +CONFIG_NET_RANDOM_ETHADDR=y +CONFIG_SPL_DM_SEQ_ALIAS=y +CONFIG_SPL_ALTERA_SDRAM=y +CONFIG_FPGA_INTEL_PR=y +CONFIG_DWAPB_GPIO=y +CONFIG_DM_I2C=y +CONFIG_SYS_I2C_DW=y +CONFIG_DM_MMC=y +CONFIG_MMC_DW=y +CONFIG_MTD=y +CONFIG_SF_DEFAULT_MODE=0x2003 +CONFIG_SPI_FLASH_SPANSION=y +CONFIG_SPI_FLASH_STMICRO=y +CONFIG_PHY_MICREL=y +CONFIG_PHY_MICREL_KSZ90X1=y +CONFIG_DM_ETH=y +CONFIG_ETH_DESIGNWARE=y +CONFIG_MII=y +CONFIG_DM_RESET=y +CONFIG_SPI=y +CONFIG_CADENCE_QSPI=y +CONFIG_DESIGNWARE_SPI=y +CONFIG_USB=y +CONFIG_DM_USB=y +CONFIG_USB_DWC2=y +CONFIG_USB_STORAGE=y +CONFIG_DESIGNWARE_WATCHDOG=y +CONFIG_WDT=y +# CONFIG_SPL_USE_TINY_PRINTF is not set +CONFIG_PANIC_HANG=y -- 2.13.0
[v2, 11/16] arm: socfpga: soc64: Add ATF support for Reset Manager driver
From: Chee Hong Ang
In non-secure mode (EL2), Reset Manager driver calls the
SMC/PSCI service provided by ATF to enable/disable the
SOCFPGA bridges.
Signed-off-by: Chee Hong Ang
Signed-off-by: Siew Chin Lim
---
v2:
- Print error message and return instead of hang in
socfpga_bridges_reset() when SMC call is failing.
---
arch/arm/mach-socfpga/reset_manager_s10.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/arch/arm/mach-socfpga/reset_manager_s10.c
b/arch/arm/mach-socfpga/reset_manager_s10.c
index 3746e6a60c..af8f2c0873 100644
--- a/arch/arm/mach-socfpga/reset_manager_s10.c
+++ b/arch/arm/mach-socfpga/reset_manager_s10.c
@@ -5,11 +5,14 @@
*/
#include
+#include
#include
#include
+#include
#include
#include
#include
+#include
DECLARE_GLOBAL_DATA_PTR;
@@ -55,6 +58,15 @@ void socfpga_per_reset_all(void)
void socfpga_bridges_reset(int enable)
{
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+ u64 arg = enable;
+
+ int ret = invoke_smc(INTEL_SIP_SMC_HPS_SET_BRIDGES, &arg, 1, NULL, 0);
+ if (ret) {
+ printf("SMC call failed with error %d in %s.\n", ret, __func__);
+ return;
+ }
+#else
u32 reg;
if (enable) {
@@ -101,6 +113,7 @@ void socfpga_bridges_reset(int enable)
/* Disable NOC timeout */
writel(0, socfpga_get_sysmgr_addr() + SYSMGR_SOC64_NOC_TIMEOUT);
}
+#endif
}
/*
--
2.13.0
[v2, 14/16] arm: socfpga: soc64: SSBL shall not setup stack on OCRAM
From: Chee Hong Ang Since SSBL is running in DRAM, it shall setup the stack in DRAM instead of OCRAM which is occupied by SPL and handoff data. Signed-off-by: Chee Hong Ang --- include/configs/socfpga_soc64_common.h | 5 + 1 file changed, 5 insertions(+) diff --git a/include/configs/socfpga_soc64_common.h b/include/configs/socfpga_soc64_common.h index cb9bb21597..dadd21b0ba 100644 --- a/include/configs/socfpga_soc64_common.h +++ b/include/configs/socfpga_soc64_common.h @@ -40,9 +40,14 @@ */ #define CONFIG_SYS_INIT_RAM_ADDR 0xFFE0 #define CONFIG_SYS_INIT_RAM_SIZE 0x4 +#ifdef CONFIG_SPL_BUILD #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_INIT_RAM_ADDR \ + CONFIG_SYS_INIT_RAM_SIZE \ - S10_HANDOFF_SIZE) +#else +#define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_TEXT_BASE \ + + 0x10) +#endif #define CONFIG_SYS_INIT_SP_OFFSET (CONFIG_SYS_INIT_SP_ADDR) #define CONFIG_SYS_MALLOC_LEN (5 * 1024 * 1024) -- 2.13.0
[v2, 08/16] arm: socfpga: soc64: Define SMC function identifiers for PSCI SiP services
From: Chee Hong Ang This header file defines the Secure Monitor Call (SMC) message protocol for ATF (BL31) PSCI runtime services. It includes all the PSCI SiP function identifiers for the secure runtime services provided by ATF. The secure runtime services include System Manager's registers access, 2nd phase bitstream FPGA reconfiguration, Remote System Update (RSU) and etc. Signed-off-by: Chee Hong Ang Signed-off-by: Siew Chin Lim --- v2: - Updated comments: - Changed string 'kernel tree' to 'u-boot tree' - INTEL_SIP_SMC_STATUS_OK and INTEL_SIP_SMC_STATUS ERROR are not for FPGA configuration only, they are common return values in INTEL_SIP_SMC_* call. --- include/linux/intel-smc.h | 573 ++ 1 file changed, 573 insertions(+) create mode 100644 include/linux/intel-smc.h diff --git a/include/linux/intel-smc.h b/include/linux/intel-smc.h new file mode 100644 index 00..cacb410691 --- /dev/null +++ b/include/linux/intel-smc.h @@ -0,0 +1,573 @@ +/* SPDX-License-Identifier: GPL-2.0 */ +/* + * Copyright (C) 2017-2018, Intel Corporation + */ + +#ifndef __INTEL_SMC_H +#define __INTEL_SMC_H + +#include +#include + +/* + * This file defines the Secure Monitor Call (SMC) message protocol used for + * service layer driver in normal world (EL1) to communicate with secure + * monitor software in Secure Monitor Exception Level 3 (EL3). + * + * This file is shared with secure firmware (FW) which is out of u-boot tree. + * + * An ARM SMC instruction takes a function identifier and up to 6 64-bit + * register values as arguments, and can return up to 4 64-bit register + * values. The operation of the secure monitor is determined by the parameter + * values passed in through registers. + + * EL1 and EL3 communicates pointer as physical address rather than the + * virtual address. + */ + +/* + * Functions specified by ARM SMC Calling convention: + * + * FAST call executes atomic operations, returns when the requested operation + * has completed. + * STD call starts a operation which can be preempted by a non-secure + * interrupt. The call can return before the requested operation has + * completed. + * + * a0..a7 is used as register names in the descriptions below, on arm32 + * that translates to r0..r7 and on arm64 to w0..w7. + */ + +#define INTEL_SIP_SMC_STD_CALL_VAL(func_num) \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_STD_CALL, ARM_SMCCC_SMC_64, \ + ARM_SMCCC_OWNER_SIP, (func_num)) + +#define INTEL_SIP_SMC_FAST_CALL_VAL(func_num) \ + ARM_SMCCC_CALL_VAL(ARM_SMCCC_FAST_CALL, ARM_SMCCC_SMC_64, \ + ARM_SMCCC_OWNER_SIP, (func_num)) + +/* + * Return values in INTEL_SIP_SMC_* call + * + * INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION: + * Secure monitor software doesn't recognize the request. + * + * INTEL_SIP_SMC_STATUS_OK: + * SMC call completed successfully, + * In case of FPGA configuration write operation, it means secure monitor + * software can accept the next chunk of FPGA configuration data. + * + * INTEL_SIP_SMC_STATUS_BUSY: + * In case of FPGA configuration write operation, it means secure monitor + * software is still processing previous data & can't accept the next chunk + * of data. Service driver needs to issue + * INTEL_SIP_SMC_FPGA_CONFIG_COMPLETED_WRITE call to query the + * completed block(s). + * + * INTEL_SIP_SMC_STATUS_ERROR: + * There is error during the SMC call process. + * + * INTEL_SIP_SMC_REG_ERROR: + * There is error during a read or write operation of the protected + * registers. + */ +#define INTEL_SIP_SMC_RETURN_UNKNOWN_FUNCTION 0x +#define INTEL_SIP_SMC_STATUS_OK0x0 +#define INTEL_SIP_SMC_STATUS_BUSY 0x1 +#define INTEL_SIP_SMC_STATUS_REJECTED 0x2 +#define INTEL_SIP_SMC_STATUS_ERROR 0x4 +#define INTEL_SIP_SMC_REG_ERROR0x5 +#define INTEL_SIP_SMC_RSU_ERROR0x7 + +/* + * Request INTEL_SIP_SMC_FPGA_CONFIG_START + * + * Sync call used by service driver at EL1 to request the FPGA in EL3 to + * be prepare to receive a new configuration. + * + * Call register usage: + * a0: INTEL_SIP_SMC_FPGA_CONFIG_START. + * a1: flag for full or partial configuration + *0 full reconfiguration. + *1 partial reconfiguration. + * a2-7: not used. + * + * Return status: + * a0: INTEL_SIP_SMC_STATUS_OK, or INTEL_SIP_SMC_STATUS_ERROR. + * a1-3: not used. + */ +#define INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START 1 +#define INTEL_SIP_SMC_FPGA_CONFIG_START \ + INTEL_SIP_SMC_FAST_CALL_VAL(INTEL_SIP_SMC_FUNCID_FPGA_CONFIG_START) + +/* + * Request INTEL_SIP_SMC_FPGA_CONFIG_WRITE + * + * Async call used by service driver at EL1 to provide FPGA configuration data + * to secure world. + * + * Call register usage: + * a0: INTEL_SIP_SMC_FPGA_CONFIG_WRITE. + * a1: 64bit physical address of the configuration data memory block + * a2: Size of configuration data block. + * a3-7: not used.
[v2, 10/16] net: designware: socfpga: Add ATF support for MAC driver
From: Chee Hong Ang
In non-secure mode (EL2), MAC driver calls the SMC/PSCI services
provided by ATF to setup the PHY interface.
Signed-off-by: Chee Hong Ang
Signed-off-by: Siew Chin Lim
---
v2:
- Code clean up without functionality change:
- Changed dwmac_socfpga_fw_setphy() to dwmac_socfpga_do_setphy().
This function will be called in both legacy and ATF boot flow.
- Use phy_intf value from phandle in dwmac_socfpga_do_setphy().
- Move #ifdef .. #endif switch into dwmac_socfpga_do_setphy(),
and directly call it in dwmac_socfpga_probe().
---
drivers/net/dwmac_socfpga.c | 31 +++
1 file changed, 27 insertions(+), 4 deletions(-)
diff --git a/drivers/net/dwmac_socfpga.c b/drivers/net/dwmac_socfpga.c
index e93561dffa..2528577b34 100644
--- a/drivers/net/dwmac_socfpga.c
+++ b/drivers/net/dwmac_socfpga.c
@@ -17,7 +17,9 @@
#include
#include
+#include
#include
+#include
struct dwmac_socfpga_platdata {
struct dw_eth_pdata dw_eth_pdata;
@@ -64,6 +66,28 @@ static int dwmac_socfpga_ofdata_to_platdata(struct udevice
*dev)
return designware_eth_ofdata_to_platdata(dev);
}
+static int dwmac_socfpga_do_setphy(struct udevice *dev, u32 modereg)
+{
+ struct dwmac_socfpga_platdata *pdata = dev_get_platdata(dev);
+
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+ u64 args[2];
+ int ret;
+
+ args[0] = ((u64)pdata->phy_intf - socfpga_get_sysmgr_addr() -
+ SYSMGR_SOC64_EMAC0) >> 2;
+ args[1] = modereg;
+
+ if (invoke_smc(INTEL_SIP_SMC_HPS_SET_PHYINTF, args, 2, NULL, 0))
+ return -EIO;
+#else
+ clrsetbits_le32(pdata->phy_intf, SYSMGR_EMACGRP_CTRL_PHYSEL_MASK <<
+ pdata->reg_shift, modereg << pdata->reg_shift);
+#endif
+
+ return 0;
+}
+
static int dwmac_socfpga_probe(struct udevice *dev)
{
struct dwmac_socfpga_platdata *pdata = dev_get_platdata(dev);
@@ -71,7 +95,6 @@ static int dwmac_socfpga_probe(struct udevice *dev)
struct reset_ctl_bulk reset_bulk;
int ret;
u32 modereg;
- u32 modemask;
switch (edata->phy_interface) {
case PHY_INTERFACE_MODE_MII:
@@ -97,9 +120,9 @@ static int dwmac_socfpga_probe(struct udevice *dev)
reset_assert_bulk(&reset_bulk);
- modemask = SYSMGR_EMACGRP_CTRL_PHYSEL_MASK << pdata->reg_shift;
- clrsetbits_le32(pdata->phy_intf, modemask,
- modereg << pdata->reg_shift);
+ ret = dwmac_socfpga_do_setphy(dev, modereg);
+ if (ret)
+ return ret;
reset_release_bulk(&reset_bulk);
--
2.13.0
[v2, 07/16] arm: socfpga: soc64: Add SMC helper function for Intel SOCFPGA (64bits)
From: Chee Hong Ang
invoke_smc() allow U-Boot proper running in non-secure mode (EL2)
to invoke SMC call to ATF's PSCI runtime services such as
System Manager's registers access, 2nd phase bitstream FPGA
reconfiguration, Remote System Update (RSU) and etc.
smc_send_mailbox() is a send mailbox command helper function which invokes
the ATF's PSCI runtime service (function ID: INTEL_SIP_SMC_MBOX_SEND_CMD)
to send mailbox messages to Secure Device Manager (SDM).
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/Makefile | 2 +
arch/arm/mach-socfpga/include/mach/smc_api.h | 13 +++
arch/arm/mach-socfpga/smc_api.c | 56
3 files changed, 71 insertions(+)
create mode 100644 arch/arm/mach-socfpga/include/mach/smc_api.h
create mode 100644 arch/arm/mach-socfpga/smc_api.c
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index c63162a5c6..0b05283a7a 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -72,6 +72,8 @@ ifdef CONFIG_TARGET_SOCFPGA_AGILEX
obj-y += firewall.o
obj-y += spl_agilex.o
endif
+else
+obj-$(CONFIG_SPL_ATF) += smc_api.o
endif
ifdef CONFIG_TARGET_SOCFPGA_GEN5
diff --git a/arch/arm/mach-socfpga/include/mach/smc_api.h
b/arch/arm/mach-socfpga/include/mach/smc_api.h
new file mode 100644
index 00..bbefdd8dd9
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/smc_api.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0+ */
+/*
+ * Copyright (C) 2020 Intel Corporation
+ */
+
+#ifndef _SMC_API_H_
+#define _SMC_API_H_
+
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len);
+int smc_send_mailbox(u32 cmd, u32 len, u32 *arg, u8 urgent, u32 *resp_buf_len,
+u32 *resp_buf);
+
+#endif /* _SMC_API_H_ */
diff --git a/arch/arm/mach-socfpga/smc_api.c b/arch/arm/mach-socfpga/smc_api.c
new file mode 100644
index 00..085daba162
--- /dev/null
+++ b/arch/arm/mach-socfpga/smc_api.c
@@ -0,0 +1,56 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (C) 2020 Intel Corporation
+ *
+ */
+
+#include
+#include
+#include
+#include
+
+int invoke_smc(u32 func_id, u64 *args, int arg_len, u64 *ret_arg, int ret_len)
+{
+ struct pt_regs regs;
+
+ memset(®s, 0, sizeof(regs));
+ regs.regs[0] = func_id;
+
+ if (args)
+ memcpy(®s.regs[1], args, arg_len * sizeof(*args));
+
+ smc_call(®s);
+
+ if (ret_arg)
+ memcpy(ret_arg, ®s.regs[1], ret_len * sizeof(*ret_arg));
+
+ return regs.regs[0];
+}
+
+int smc_send_mailbox(u32 cmd, u32 len, u32 *arg, u8 urgent, u32 *resp_buf_len,
+u32 *resp_buf)
+{
+ int ret;
+ u64 args[6];
+ u64 resp[3];
+
+ args[0] = cmd;
+ args[1] = (u64)arg;
+ args[2] = len;
+ args[3] = urgent;
+ args[4] = (u64)resp_buf;
+ if (resp_buf_len)
+ args[5] = *resp_buf_len;
+ else
+ args[5] = 0;
+
+ ret = invoke_smc(INTEL_SIP_SMC_MBOX_SEND_CMD, args, ARRAY_SIZE(args),
+resp, ARRAY_SIZE(resp));
+
+ if (ret == INTEL_SIP_SMC_STATUS_OK && resp_buf && resp_buf_len) {
+ if (!resp[0])
+ *resp_buf_len = resp[1];
+ }
+
+ return (int)resp[0];
+}
--
2.13.0
[v2, 02/16] arm: socfpga: soc64: Add FIT generator script for pack itb with ATF
From: Chee Hong Ang
Generate a FIT image for Intel SOCFPGA (64bits) which
include U-boot proper, ATF and DTB for U-boot proper.
Signed-off-by: Chee Hong Ang
Signed-off-by: Siew Chin Lim
---
v2:
- Move soc64 folder from board/altera to board/intel folder
---
board/intel/soc64/fit_spl_atf.sh | 92
1 file changed, 92 insertions(+)
create mode 100755 board/intel/soc64/fit_spl_atf.sh
diff --git a/board/intel/soc64/fit_spl_atf.sh b/board/intel/soc64/fit_spl_atf.sh
new file mode 100755
index 00..40f0e20c05
--- /dev/null
+++ b/board/intel/soc64/fit_spl_atf.sh
@@ -0,0 +1,92 @@
+#!/bin/sh
+#
+# SPDX-License-Identifier: GPL-2.0+
+#
+# script to generate FIT image source for Stratix 10 and
+# Agilex boards with U-Boot proper, ATF and device tree
+# for U-Boot proper.
+#
+# usage: $0
+
+BL31="bl31.bin"
+if [ ! -f $BL31 ]; then
+ echo "BL31 file \"$BL31\" NOT found!" >&2
+ exit 1
+fi
+
+BL33="u-boot-nodtb.bin"
+if [ ! -f $BL33 ]; then
+ echo "BL33 file \"$BL33\" NOT found!" >&2
+ exit 1
+fi
+
+if [ -f "$1" ] ; then
+ DT_NAME="$1"
+else
+ echo "File not found: \"$1\"" >&2
+ exit 1
+fi
+
+cat << __PREAMBLE_EOF
+/*
+ * Copyright (C) 2020 Intel Corporation. All rights reserved
+ *
+ * SPDX-License-Identifier: GPL-2.0+
+ */
+
+/dts-v1/;
+
+/ {
+ description = "FIT image with U-Boot proper, ATF bl31, U-Boot DTB";
+ #address-cells = <1>;
+
+__PREAMBLE_EOF
+
+cat << __IMAGES_EOF
+ images {
+ uboot {
+ description = "U-Boot SoC64";
+ data = /incbin/("$BL33");
+ type = "standalone";
+ os = "U-Boot";
+ arch = "arm64";
+ compression = "none";
+ load = <0x0020>;
+ };
+
+ atf {
+ description = "ARM Trusted Firmware";
+ data = /incbin/("$BL31");
+ type = "firmware";
+ os = "arm-trusted-firmware";
+ arch = "arm64";
+ compression = "none";
+ load = <0x1000>;
+ entry = <0x1000>;
+ };
+
+ fdt {
+ description = "U-Boot SoC64 flat device-tree";
+ data = /incbin/("$DT_NAME");
+ type = "flat_dt";
+ compression = "none";
+ };
+ };
+
+__IMAGES_EOF
+
+cat << __CONFIGS_EOF
+ configurations {
+ default = "conf";
+ conf {
+ description = "Intel SoC64 FPGA";
+ firmware = "atf";
+ loadables = "uboot";
+ fdt = "fdt";
+ };
+ };
+__CONFIGS_EOF
+
+cat << __END_EOF
+};
+__END_EOF
--
2.13.0
[v2, 09/16] mmc: dwmmc: socfpga: Add ATF support for MMC driver
From: Chee Hong Ang
In non-secure mode (EL2), MMC driver calls the SMC/PSCI services
provided by ATF to set SDMMC's DRVSEL and SMPLSEL.
Signed-off-by: Chee Hong Ang
Signed-off-by: Siew Chin Lim
---
v2:
- Code clean up without functionality change:
- Changed socfpga_dwmci_fw_clksel() to socfpga_dwmci_do_clksel().
This function will be called in both legacy and ATF boot flow.
- Move #ifdef .. #endif switch into socfpga_dwmci_do_clksel().
- Remove #ifdef .. #endif switch from socfpga_dwmci_clksel(),
Directly call socfpga_dwmci_do_clksel() in socfpga_dwmci_clksel().
---
drivers/mmc/socfpga_dw_mmc.c | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/drivers/mmc/socfpga_dw_mmc.c b/drivers/mmc/socfpga_dw_mmc.c
index 0022f943bd..404dd2c91a 100644
--- a/drivers/mmc/socfpga_dw_mmc.c
+++ b/drivers/mmc/socfpga_dw_mmc.c
@@ -6,6 +6,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -13,6 +14,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -46,6 +48,26 @@ static void socfpga_dwmci_reset(struct udevice *dev)
reset_deassert_bulk(&reset_bulk);
}
+static void socfpga_dwmci_do_clksel(u32 sdmmc_mask)
+{
+#if !defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_ATF)
+ u64 args[2];
+
+ /* drvsel */
+ args[0] = (sdmmc_mask >> SYSMGR_SDMMC_DRVSEL_SHIFT) & 0x7;
+ /* smplsel */
+ args[1] = (sdmmc_mask >> SYSMGR_SDMMC_SMPLSEL_SHIFT) & 0x7;
+ if (invoke_smc(INTEL_SIP_SMC_HPS_SET_SDMMC_CCLK, args, 2, NULL, 0))
+ dev_err(host->dev, "SMC call failed in %s\n", __func__);
+
+#else
+ writel(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));
+#endif
+}
+
static void socfpga_dwmci_clksel(struct dwmci_host *host)
{
struct dwmci_socfpga_priv_data *priv = host->priv;
@@ -58,10 +80,8 @@ 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);
- debug("%s: SYSMGR_SDMMCGRP_CTRL_REG = 0x%x\n", __func__,
- readl(socfpga_get_sysmgr_addr() + SYSMGR_SDMMC));
+ socfpga_dwmci_do_clksel(sdmmc_mask);
/* Enable SDMMC clock */
setbits_le32(socfpga_get_clkmgr_addr() + CLKMGR_PERPLL_EN,
--
2.13.0
[v2, 04/16] arm: socfpga: soc64: Load FIT image with ATF support
From: Chee Hong Ang Instead of loading u-boot proper image (u-boot.img), SPL now loads FIT image (u-boot.itb) which includes u-boot proper, ATF and u-boot proper's DTB. Signed-off-by: Chee Hong Ang --- include/configs/socfpga_soc64_common.h | 4 1 file changed, 4 insertions(+) diff --git a/include/configs/socfpga_soc64_common.h b/include/configs/socfpga_soc64_common.h index fb5e2e8aaf..cb9bb21597 100644 --- a/include/configs/socfpga_soc64_common.h +++ b/include/configs/socfpga_soc64_common.h @@ -193,6 +193,10 @@ unsigned int cm_get_l4_sys_free_clk_hz(void); - CONFIG_SYS_SPL_MALLOC_SIZE) /* SPL SDMMC boot support */ +#ifdef CONFIG_SPL_LOAD_FIT +#define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.itb" +#else #define CONFIG_SPL_FS_LOAD_PAYLOAD_NAME"u-boot.img" +#endif #endif /* __CONFIG_SOCFPGA_SOC64_COMMON_H__ */ -- 2.13.0
[v2, 06/16] arm: socfpga: Disable "spin-table" method for booting Linux
From: Chee Hong Ang Standard PSCI function "CPU_ON" provided by ATF is now used by Linux kernel to bring up the secondary CPUs to enable SMP booting in Linux on SoC 64bits platform. Signed-off-by: Chee Hong Ang --- arch/arm/mach-socfpga/Kconfig | 2 -- 1 file changed, 2 deletions(-) diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig index 37083ec0d8..38795265e5 100644 --- a/arch/arm/mach-socfpga/Kconfig +++ b/arch/arm/mach-socfpga/Kconfig @@ -33,7 +33,6 @@ config TARGET_SOCFPGA_AGILEX bool select ARMV8_MULTIENTRY select ARMV8_SET_SMPEN - select ARMV8_SPIN_TABLE select CLK select FPGA_INTEL_SDM_MAILBOX select NCORE_CACHE @@ -79,7 +78,6 @@ config TARGET_SOCFPGA_STRATIX10 bool select ARMV8_MULTIENTRY select ARMV8_SET_SMPEN - select ARMV8_SPIN_TABLE select FPGA_INTEL_SDM_MAILBOX choice -- 2.13.0
[v2, 00/16] Enable ARM Trusted Firmware for U-Boot
This is the 2nd version of patchset to Enable ARM Trusted Firmware
for U-Boot.
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)
Patch status:
Have changes: Patch 2, 8, 9, 10, 11, 16
Other patches unchanged.
Detail changelog can find in commit message.
v1->v2:
Patch 2:
- Move soc64 folder from board/altera to board/intel folder
Patch 8:
- Updated comments
Patch 9:
- Code clean up without functionality change
Patch 10:
- Code clean up without functionality change
Patch 11:
- Print error message and return instead of hang in socfpga_bridges_reset()
when SMC call is failing.
Patch 16:
- Add CONFIG_SPL_LOAD_FIT_ADDRESS=0x0200
- Move board/altera/soc64/fit_spl_atf.sh to board/intel/soc64/fit_spl_atf.sh
History:
[v1]: https://patchwork.ozlabs.org/project/uboot/list/?series=195854
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 | 13 +
arch/arm/mach-socfpga/smc_api.c| 56 ++
arch/arm/mach-socfpga/wrap_pll_config_s10.c| 3 +-
board/intel/soc64/fit_spl_atf.sh | 92
...ilex_defconfig => socfpga_agilex_atf_defconfig} | 23 +-
configs/socfpga_agilex_defconfig | 1 -
...0_defconfig => socfpga_stratix10_atf_defconfig} | 25 +-
configs/socfpga_stratix10_defconfig| 1 -
drivers/fpga/intel_sdm_mb.c| 139 +
drivers/mmc/socfpga_dw_mmc.c | 26 +-
drivers/net/dwmac_socfpga.c| 31 +-
include/configs/socfpga_soc64_common.h | 9 +
include/linux/intel-smc.h | 573 +
19 files changed, 1071 insertions(+), 33 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/intel/soc64/fit_spl_atf.sh
copy configs/{socfpga_agilex_defconfig => socfpga_agilex_atf_defconfig} (79%)
copy configs/{socfpga_stratix10_defconfig => socfpga_stratix10_atf_defconfig}
(79%)
create mode 100644 include/linux/intel-smc.h
--
2.13.0
[v2, 03/16] arm: socfpga: Add function for checking description from FIT image
From: Chee Hong Ang
Add board_fit_config_name_match() for matching board name with
device tree files in FIT image. This will ensure correct DTB
file is loaded for different board type. Currently, we are not
supporting multiple device tree files in FIT image therefore this
function basically do nothing for now.
Users are allowed to override this 'weak' function in their
specific board implementation.
Signed-off-by: Chee Hong Ang
---
arch/arm/mach-socfpga/board.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index 340abf9305..7993c27646 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -13,7 +13,7 @@
#include
#include
#include
-
+#include
#include
#include
@@ -87,3 +87,13 @@ int g_dnl_board_usb_cable_connected(void)
return 1;
}
#endif
+
+#ifdef CONFIG_SPL_BUILD
+__weak int board_fit_config_name_match(const char *name)
+{
+ /* Just empty function now - can't decide what to choose */
+ debug("%s: %s\n", __func__, name);
+
+ return 0;
+}
+#endif
--
2.13.0
