u-boot patch for ACK

2021-04-30 Thread Aleksandar Gerasimovski
Hi Tom,

Hope you are well, I have a question regarding one of my patches pending for 
ACK:
https://patchwork.ozlabs.org/project/uboot/list/?series=&submitter=80669&state=&q=&archive=&delegate=

Is it possible to get some attention on my questions, the changes are deep in 
arm generic code and maybe there is a reason not obvious to me why PRAM region 
is not considered?

Thanks!

Regards,
Aleksandar 


Re: Kirkwood: Fix tv sec/usec normalization in kwboot

2021-04-30 Thread Stefan Roese

On 29.04.21 14:03, Dagan Martinez wrote:

 From c200095d4136a071dd9526a48be642ce58fae8c9 Mon Sep 17 00:00:00 2001
From: Dagan Martinez 
Date: Tue, 27 Apr 2021 15:48:31 -0400
Subject: [PATCH v2] Kirkwood: Fix tv sec/usec normalization in kwboot

`kwboot.c` had an issue where it failed to normalize the `tv` struct in
the case where the `tv_usec` field was 100, ie one second.

This caused issues on Fedora Linux 34, where `select` would return
`EINVAL`, preventing kwboot from communicating with the board.

Signed-off-by: Dagan Martinez 
---
Changes for v2:
- Use real author name in patch


Thanks. Still this patch does not apply. How did you generate and send
it? It's somehow mangled. I suggest to use git send-email.

And another issue: The subject of this original mail still has "Re: " in
it. Please don't reply in some mail client but either use git send-email
or write a completely new message. Some mail clients tend to clutter
the whitespace etc.

Thanks,
Stefan



  tools/kwboot.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/kwboot.c b/tools/kwboot.c
index 4be094c9c8..5d5d501d36 100644
--- a/tools/kwboot.c
+++ b/tools/kwboot.c
@@ -167,7 +167,7 @@ kwboot_tty_recv(int fd, void *buf, size_t len, int timeo)

  tv.tv_sec = 0;
  tv.tv_usec = timeo * 1000;
-if (tv.tv_usec > 100) {
+if (tv.tv_usec >= 100) {
  tv.tv_sec += tv.tv_usec / 100;
  tv.tv_usec %= 100;
  }




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


[v2 00/17] Add Intel N5X SoC support

2021-04-30 Thread Siew Chin Lim
This is the 2nd version of patchset to add Intel N5X SoC[1] support.

Intel N5X SoC is with a 64-bit quad core ARM Cortex-A53 MPCore
hard processor system (HPS). New IPs in N5X are clock manager
and DDR subsystem, other IPs have minor changes compared to Agilex.

Intel N5X SoC supports legacy boot without ATF for debugging purpose,
ATF boot, and ATF boot with VAB enabled.

[1]: 
https://www.intel.com/content/www/us/en/products/programmable/asic/easic-devices/diamond-mesa-soc-devices.html


Patch status:
Have changes: Patch 1, 4, 5, 7, 11, 12, 13, 15, 17
Other patches unchanged.

Detail changelog can find in commit message.

v1->v2:

Patch 1:
- New patch in n5x series, the change is needed to execute
  'linux_qspi_enable' correctly in ATF boot flow

Patch 4:
- Enabled auto detect the endianness from the magic word
- Merged and simplifying the big and little endian flow

Patch 5:
- common.h need to be included before clock_manager.h
- Remove unnecessary comment : write 1 to clear
- Remove unnecessary () in the code

Patch 7:
- common.h need to be included before clock_manager.h
- For consistency, use small letter fo 0x0c and 0x1c in macros

Patch 11:
- Renamed local variable “total_size” to “remaining_size”

Patch 12:
- Move is_ddr_init_skipped and its helper functions to DDR driver and
  converted function to positive checking
- Using GENMASK() macro
- Fixed typo
- Return status of subfunction
- Changed dm to n5x

Patch 13:
- No change on the file. Need review again for this patch.
  common.h need to be included before clock_manager.h.

Patch 15:
- Remove socfpga_n5x.dtsi
- Reuse socfpga_agilex.dtsi in socfpga_n5x_socdk.dts and update
  n5x data accordingly.

Patch 17:
- Move linux_qspi_enable from bootcommand


Siew Chin Lim (16):
  arm: socfpga: Move linux_qspi_enable from bootcommand to
board_prep_linux function
  arm: socfpga: Changed base_addr_s10.h to base_addr_soc64.h
  arm: socfpga: Add base address for Intel N5X device
  arm: socfpga: Add handoff data support for Intel N5X device
  drivers: clk: Add clock driver for Intel N5X device
  arm: socfpga: Get clock manager base address for Intel N5X device
  drivers: clk: Add memory clock driver for Intel N5X device
  arm: socfpga: Move cm_get_mpu_clk_hz function declaration to
clock_manager.h
  arm: socfpga: Add clock manager for Intel N5X device
  arm: socfpga: Changed misc_s10.c to misc_soc64.c
  ddr: altera: Add SDRAM driver for Intel N5X device
  arm: socfpga: Add SPL for Intel N5X device
  board: intel: Add socdk board support for Intel N5X device
  arm: dts: Add base dtsi and devkit dts for Intel N5X device
  include: configs: Add Intel N5X device CONFIGs
  arm: socfpga: Enable Intel N5X device build

Tien Fong Chee (1):
  ddr: socfpga: Enable memory test on memory size less than 1GB

 arch/arm/dts/Makefile |1 +
 arch/arm/dts/socfpga_n5x-u-boot.dtsi  |  101 +
 arch/arm/dts/socfpga_n5x_socdk-u-boot.dtsi|   67 +
 arch/arm/dts/socfpga_n5x_socdk.dts|  243 ++
 arch/arm/mach-socfpga/Kconfig |   21 +-
 arch/arm/mach-socfpga/Makefile|   32 +-
 arch/arm/mach-socfpga/board.c |   17 +-
 arch/arm/mach-socfpga/clock_manager_n5x.c |   80 +
 .../{base_addr_s10.h => base_addr_soc64.h}|   11 +-
 .../mach-socfpga/include/mach/clock_manager.h |3 +
 .../include/mach/clock_manager_agilex.h   |2 -
 .../include/mach/clock_manager_arria10.h  |1 -
 .../include/mach/clock_manager_gen5.h |1 -
 .../include/mach/clock_manager_n5x.h  |   12 +
 .../include/mach/clock_manager_s10.h  |1 -
 arch/arm/mach-socfpga/include/mach/firewall.h |6 +
 .../mach-socfpga/include/mach/handoff_soc64.h |   38 +-
 .../include/mach/system_manager_soc64.h   |   10 +-
 arch/arm/mach-socfpga/misc.c  |3 +
 .../mach-socfpga/{misc_s10.c => misc_soc64.c} |   12 +-
 arch/arm/mach-socfpga/spl_n5x.c   |   94 +
 arch/arm/mach-socfpga/system_manager_soc64.c  |   18 +-
 arch/arm/mach-socfpga/wrap_handoff_soc64.c|  126 +-
 board/intel/n5x-socdk/MAINTAINERS |7 +
 board/intel/n5x-socdk/Makefile|7 +
 board/intel/n5x-socdk/socfpga.c   |7 +
 configs/socfpga_agilex_atf_defconfig  |2 +-
 ...tf_defconfig => socfpga_n5x_atf_defconfig} |   13 +-
 ...ex_atf_defconfig => socfpga_n5x_defconfig} |   29 +-
 ...tf_defconfig => socfpga_n5x_vab_defconfig} |   14 +-
 configs/socfpga_stratix10_atf_defconfig   |2 +-
 drivers/clk/altera/Makefile   |4 +-
 drivers/clk/altera/clk-mem-n5x.c  |  136 +
 drivers/clk/altera/clk-mem-n5x.h  |   84 +
 drivers/clk/altera/clk-n5x.c  |  489 
 drivers/clk/altera/clk-n5x.h  |  217 ++
 drivers/ddr/altera/Makefile   |3 +-
 drivers/ddr/altera/sdram_n5x.c| 2299 +
 drivers/ddr/altera/sdram

[v2 02/17] arm: socfpga: Changed base_addr_s10.h to base_addr_soc64.h

2021-04-30 Thread Siew Chin Lim
Rename to common file name to used by all SOC64 devices and change
"_S10_" to "_SOC64_" in base_addr_soc64.h.

Signed-off-by: Siew Chin Lim 
---
 .../include/mach/{base_addr_s10.h => base_addr_soc64.h}   | 8 
 include/configs/socfpga_soc64_common.h| 2 +-
 2 files changed, 5 insertions(+), 5 deletions(-)
 rename arch/arm/mach-socfpga/include/mach/{base_addr_s10.h => 
base_addr_soc64.h} (89%)

diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h 
b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
similarity index 89%
rename from arch/arm/mach-socfpga/include/mach/base_addr_s10.h
rename to arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
index d3eca65e97..f89066d771 100644
--- a/arch/arm/mach-socfpga/include/mach/base_addr_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
@@ -1,10 +1,10 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * Copyright (C) 2016-2017 Intel Corporation 
+ * Copyright (C) 2016-2021 Intel Corporation 
  */
 
-#ifndef _SOCFPGA_S10_BASE_HARDWARE_H_
-#define _SOCFPGA_S10_BASE_HARDWARE_H_
+#ifndef _SOCFPGA_SOC64_BASE_HARDWARE_H_
+#define _SOCFPGA_SOC64_BASE_HARDWARE_H_
 
 #define SOCFPGA_CCU_ADDRESS0xf700
 #define SOCFPGA_SDR_SCHEDULER_ADDRESS  0xf8000400
@@ -44,4 +44,4 @@
 #define GICD_BASE  0xfffc1000
 #define GICC_BASE  0xfffc2000
 
-#endif /* _SOCFPGA_S10_BASE_HARDWARE_H_ */
+#endif /* _SOCFPGA_SOC64_BASE_HARDWARE_H_ */
diff --git a/include/configs/socfpga_soc64_common.h 
b/include/configs/socfpga_soc64_common.h
index 5afdb10454..f0b7884ebc 100644
--- a/include/configs/socfpga_soc64_common.h
+++ b/include/configs/socfpga_soc64_common.h
@@ -7,7 +7,7 @@
 #ifndef __CONFIG_SOCFPGA_SOC64_COMMON_H__
 #define __CONFIG_SOCFPGA_SOC64_COMMON_H__
 
-#include 
+#include 
 #include 
 #include 
 
-- 
2.19.0



[v2 01/17] arm: socfpga: Move linux_qspi_enable from bootcommand to board_prep_linux function

2021-04-30 Thread Siew Chin Lim
Move 'linux_qspi_enable' from bootcommand to board_prep_linux function when
OS booted from FIT image for Stratix 10 and Agilex. This flow is common for
all Intel SOC64 devices.

U-Boot will update 'fdt_addr' environment value based on FIT image in
board_prep_linux function, and 'linux_qspi_enable' will refer to 'fdt_addr'
environment value to retrieve the device tree node.

Signed-off-by: Siew Chin Lim 

---
v2:
- New patch in n5x series, the change is needed to execute
  'linux_qspi_enable' correctly in ATF boot flow
---
 arch/arm/mach-socfpga/board.c   | 17 +
 configs/socfpga_agilex_atf_defconfig|  2 +-
 configs/socfpga_stratix10_atf_defconfig |  2 +-
 3 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-socfpga/board.c b/arch/arm/mach-socfpga/board.c
index 650122fcd4..f5a3f2ad62 100644
--- a/arch/arm/mach-socfpga/board.c
+++ b/arch/arm/mach-socfpga/board.c
@@ -115,17 +115,18 @@ void board_fit_image_post_process(void **p_image, size_t 
*p_size)
 #if !IS_ENABLED(CONFIG_SPL_BUILD) && IS_ENABLED(CONFIG_FIT)
 void board_prep_linux(bootm_headers_t *images)
 {
-   if (IS_ENABLED(CONFIG_SOCFPGA_SECURE_VAB_AUTH) &&
-   !IS_ENABLED(CONFIG_SOCFPGA_SECURE_VAB_AUTH_ALLOW_NON_FIT_IMAGE)) {
-   /*
-* Ensure the OS is always booted from FIT and with
-* VAB signed certificate
-*/
-   if (!images->fit_uname_cfg) {
+   if (!images->fit_uname_cfg) {
+   if (IS_ENABLED(CONFIG_SOCFPGA_SECURE_VAB_AUTH) &&
+   
!IS_ENABLED(CONFIG_SOCFPGA_SECURE_VAB_AUTH_ALLOW_NON_FIT_IMAGE)) {
+   /*
+* Ensure the OS is always booted from FIT and with
+* VAB signed certificate
+*/
printf("Please use FIT with VAB signed images!\n");
hang();
}
-
+   } else {
+   /* Update fdt_addr in enviroment variable */
env_set_hex("fdt_addr", (ulong)images->ft_addr);
debug("images->ft_addr = 0x%08lx\n", (ulong)images->ft_addr);
}
diff --git a/configs/socfpga_agilex_atf_defconfig 
b/configs/socfpga_agilex_atf_defconfig
index 0de65a22a0..e0a8714e3d 100644
--- a/configs/socfpga_agilex_atf_defconfig
+++ b/configs/socfpga_agilex_atf_defconfig
@@ -22,7 +22,7 @@ CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
 CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run 
mmcfitboot"
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run mmcfitboot"
 CONFIG_SPL_CRC32_SUPPORT=y
 CONFIG_SPL_CACHE=y
 CONFIG_SPL_SPI_LOAD=y
diff --git a/configs/socfpga_stratix10_atf_defconfig 
b/configs/socfpga_stratix10_atf_defconfig
index c187987dd8..d0bc5e7909 100644
--- a/configs/socfpga_stratix10_atf_defconfig
+++ b/configs/socfpga_stratix10_atf_defconfig
@@ -22,7 +22,7 @@ CONFIG_BOOTDELAY=5
 CONFIG_USE_BOOTARGS=y
 CONFIG_BOOTARGS="earlycon"
 CONFIG_USE_BOOTCOMMAND=y
-CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run linux_qspi_enable; run 
mmcfitboot"
+CONFIG_BOOTCOMMAND="run fatscript; run mmcfitload; run mmcfitboot"
 CONFIG_SPL_CRC32_SUPPORT=y
 CONFIG_SPL_SPI_LOAD=y
 CONFIG_SPL_ATF=y
-- 
2.19.0



[v2 03/17] arm: socfpga: Add base address for Intel N5X device

2021-04-30 Thread Siew Chin Lim
Reuse base_addr_soc64.h for Intel N5X device, the address is the
same as Agilex.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/mach-socfpga/include/mach/base_addr_soc64.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h 
b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
index f89066d771..3f899fcfa3 100644
--- a/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/base_addr_soc64.h
@@ -10,7 +10,8 @@
 #define SOCFPGA_SDR_SCHEDULER_ADDRESS  0xf8000400
 #define SOCFPGA_HMC_MMR_IO48_ADDRESS   0xf801
 #define SOCFPGA_SDR_ADDRESS0xf8011000
-#ifdef CONFIG_TARGET_SOCFPGA_AGILEX
+#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX) || \
+   IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
 #define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020200
 #else
 #define SOCFPGA_FW_MPU_DDR_SCR_ADDRESS 0xf8020100
-- 
2.19.0



[v2 04/17] arm: socfpga: Add handoff data support for Intel N5X device

2021-04-30 Thread Siew Chin Lim
N5X support both HPS handoff data and DDR handoff data.
Existing HPS handoff functions are restructured to support both existing
devices and N5X device.

Signed-off-by: Siew Chin Lim 
Signed-off-by: Tien Fong Chee 

---
v2:
- Enabled auto detect the endianness from the magic word
- Merged and simplifying the big and little endian flow
---
 .../mach-socfpga/include/mach/handoff_soc64.h |  38 +-
 arch/arm/mach-socfpga/system_manager_soc64.c  |  18 +--
 arch/arm/mach-socfpga/wrap_handoff_soc64.c| 126 +-
 3 files changed, 136 insertions(+), 46 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h 
b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
index 3750216a9a..902fc6bfb5 100644
--- a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0
  *
- * Copyright (C) 2016-2020 Intel Corporation 
+ * Copyright (C) 2016-2021 Intel Corporation 
  *
  */
 
@@ -23,8 +23,36 @@
 #define SOC64_HANDOFF_OFFSET_DATA  0x10
 #define SOC64_HANDOFF_SIZE 4096
 
+#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_STRATIX10) || \
+   IS_ENABLED(CONFIG_TARGET_SOCFPGA_AGILEX)
 #define SOC64_HANDOFF_BASE 0xFFE3F000
 #define SOC64_HANDOFF_MISC (SOC64_HANDOFF_BASE + 0x610)
+#elif IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
+#define SOC64_HANDOFF_BASE 0xFFE5F000
+#define SOC64_HANDOFF_MISC (SOC64_HANDOFF_BASE + 0x630)
+
+/* DDR handoff */
+#define SOC64_HANDOFF_DDR_BASE 0xFFE5C000
+#define SOC64_HANDOFF_DDR_MAGIC0x4852
+#define SOC64_HANDOFF_DDR_UMCTL2_MAGIC 0x4C54434D
+#define SOC64_HANDOFF_DDR_UMCTL2_DDR4_TYPE 0x3452
+#define SOC64_HANDOFF_DDR_UMCTL2_LPDDR4_0_TYPE 0x3044504C
+#define SOC64_HANDOFF_DDR_UMCTL2_LPDDR4_1_TYPE 0x3144504C
+#define SOC64_HANDOFF_DDR_MEMRESET_BASE(SOC64_HANDOFF_DDR_BASE 
+ 0xC)
+#define SOC64_HANDOFF_DDR_UMCTL2_SECTION   (SOC64_HANDOFF_DDR_BASE + 0x10)
+#define SOC64_HANDOFF_DDR_PHY_MAGIC0x43594850
+#define SOC64_HANDOFF_DDR_PHY_INIT_ENGINE_MAGIC0x45594850
+#define SOC64_HANDOFF_DDR_PHY_BASE_OFFSET  0x8
+#define SOC64_HANDOFF_DDR_UMCTL2_TYPE_OFFSET   0x8
+#define SOC64_HANDOFF_DDR_UMCTL2_BASE_ADDR_OFFSET  0xC
+#define SOC64_HANDOFF_DDR_TRAIN_IMEM_1D_SECTION0xFFE5
+#define SOC64_HANDOFF_DDR_TRAIN_DMEM_1D_SECTION0xFFE58000
+#define SOC64_HANDOFF_DDR_TRAIN_IMEM_2D_SECTION0xFFE44000
+#define SOC64_HANDOFF_DDR_TRAIN_DMEM_2D_SECTION0xFFE4C000
+#define SOC64_HANDOFF_DDR_TRAIN_IMEM_LENGTHSZ_32K
+#define SOC64_HANDOFF_DDR_TRAIN_DMEM_LENGTHSZ_16K
+#endif
+
 #define SOC64_HANDOFF_MUX  (SOC64_HANDOFF_BASE + 0x10)
 #define SOC64_HANDOFF_IOCTL(SOC64_HANDOFF_BASE + 0x1A0)
 #define SOC64_HANDOFF_FPGA (SOC64_HANDOFF_BASE + 0x330)
@@ -52,11 +80,11 @@
 #include 
 enum endianness {
LITTLE_ENDIAN = 0,
-   BIG_ENDIAN
+   BIG_ENDIAN,
+   UNKNOWN_ENDIANNESS
 };
 
-int socfpga_get_handoff_size(void *handoff_address, enum endianness endian);
-int socfpga_handoff_read(void *handoff_address, void *table, u32 table_len,
-enum endianness big_endian);
+int socfpga_get_handoff_size(void *handoff_address);
+int socfpga_handoff_read(void *handoff_address, void *table, u32 table_len);
 #endif
 #endif /* _HANDOFF_SOC64_H_ */
diff --git a/arch/arm/mach-socfpga/system_manager_soc64.c 
b/arch/arm/mach-socfpga/system_manager_soc64.c
index 3b5e774e2d..958bb5107b 100644
--- a/arch/arm/mach-socfpga/system_manager_soc64.c
+++ b/arch/arm/mach-socfpga/system_manager_soc64.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2016-2018 Intel Corporation 
+ * Copyright (C) 2016-2021 Intel Corporation 
  *
  */
 
@@ -66,10 +66,10 @@ void populate_sysmgr_fpgaintf_module(void)
 void populate_sysmgr_pinmux(void)
 {
u32 len, i;
-   u32 len_mux = socfpga_get_handoff_size((void *)SOC64_HANDOFF_MUX, 
BIG_ENDIAN);
-   u32 len_ioctl = socfpga_get_handoff_size((void *)SOC64_HANDOFF_IOCTL, 
BIG_ENDIAN);
-   u32 len_fpga = socfpga_get_handoff_size((void *)SOC64_HANDOFF_FPGA, 
BIG_ENDIAN);
-   u32 len_delay = socfpga_get_handoff_size((void *)SOC64_HANDOFF_DELAY, 
BIG_ENDIAN);
+   u32 len_mux = socfpga_get_handoff_size((void *)SOC64_HANDOFF_MUX);
+   u32 len_ioctl = socfpga_get_handoff_size((void *)SOC64_HANDOFF_IOCTL);
+   u32 len_fpga = socfpga_get_handoff_size((void *)SOC64_HANDOFF_FPGA);
+   u32 len_delay = socfpga_get_handoff_size((void *)SOC64_HANDOFF_DELAY);
 
len = (len_mux > len_ioctl) ? len_mux : len_ioctl;
len = (len > len_fpga) ? len : len_fpga;
@@ -79,7 +79,7 @@ void populate_sysmgr_pinmux(void)
 
/* setup the pin sel */
len = (len_mux < SOC64_HANDOFF_MUX_LEN) ? len_mux : 
SOC64_HANDOFF_MUX_LEN;
-   socfpga_handoff_read((void *)SOC64

[v2 06/17] arm: socfpga: Get clock manager base address for Intel N5X device

2021-04-30 Thread Siew Chin Lim
Add N5X clock manager to socfpga_get_managers_addr function.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/mach-socfpga/misc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-socfpga/misc.c b/arch/arm/mach-socfpga/misc.c
index 64a7c9d652..9305bec38a 100644
--- a/arch/arm/mach-socfpga/misc.c
+++ b/arch/arm/mach-socfpga/misc.c
@@ -254,6 +254,9 @@ void socfpga_get_managers_addr(void)
 #ifdef CONFIG_TARGET_SOCFPGA_AGILEX
ret = socfpga_get_base_addr("intel,agilex-clkmgr",
&socfpga_clkmgr_base);
+#elif IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
+   ret = socfpga_get_base_addr("intel,n5x-clkmgr",
+   &socfpga_clkmgr_base);
 #else
ret = socfpga_get_base_addr("altr,clk-mgr", &socfpga_clkmgr_base);
 #endif
-- 
2.19.0



[v2 05/17] drivers: clk: Add clock driver for Intel N5X device

2021-04-30 Thread Siew Chin Lim
Add clock manager driver for N5X. Provides clock initialization
and get_rate functions.

Signed-off-by: Siew Chin Lim 

---
v2:
- common.h need to be included before clock_manager.h
- Remove unnecessary comment : write 1 to clear
- Remove unnecessary () in the code
---
 drivers/clk/altera/Makefile   |   3 +-
 drivers/clk/altera/clk-n5x.c  | 489 ++
 drivers/clk/altera/clk-n5x.h  | 217 
 include/dt-bindings/clock/n5x-clock.h |  71 
 4 files changed, 779 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/altera/clk-n5x.c
 create mode 100644 drivers/clk/altera/clk-n5x.h
 create mode 100644 include/dt-bindings/clock/n5x-clock.h

diff --git a/drivers/clk/altera/Makefile b/drivers/clk/altera/Makefile
index 96215ad5c4..38cd730685 100644
--- a/drivers/clk/altera/Makefile
+++ b/drivers/clk/altera/Makefile
@@ -1,7 +1,8 @@
 # SPDX-License-Identifier: GPL-2.0+
 #
-# Copyright (C) 2018 Marek Vasut 
+# Copyright (C) 2018-2021 Marek Vasut 
 #
 
 obj-$(CONFIG_TARGET_SOCFPGA_AGILEX) += clk-agilex.o
 obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += clk-arria10.o
+obj-$(CONFIG_TARGET_SOCFPGA_N5X) += clk-n5x.o
diff --git a/drivers/clk/altera/clk-n5x.c b/drivers/clk/altera/clk-n5x.c
new file mode 100644
index 00..bdcbbaae91
--- /dev/null
+++ b/drivers/clk/altera/clk-n5x.c
@@ -0,0 +1,489 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020-2021 Intel Corporation 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct socfpga_clk_plat {
+   void __iomem *regs;
+};
+
+/*
+ * function to write the bypass register which requires a poll of the
+ * busy bit
+ */
+static void clk_write_bypass_mainpll(struct socfpga_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, CLKMGR_MAINPLL_BYPASS);
+   cm_wait_for_fsm();
+}
+
+static void clk_write_bypass_perpll(struct socfpga_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, CLKMGR_PERPLL_BYPASS);
+   cm_wait_for_fsm();
+}
+
+/* function to write the ctrl register which requires a poll of the busy bit */
+static void clk_write_ctrl(struct socfpga_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, CLKMGR_CTRL);
+   cm_wait_for_fsm();
+}
+
+/*
+ * Setup clocks while making no assumptions about previous state of the clocks.
+ */
+static void clk_basic_init(struct udevice *dev,
+  const struct cm_config * const cfg)
+{
+   struct socfpga_clk_plat *plat = dev_get_plat(dev);
+
+   if (!cfg)
+   return;
+
+#if IS_ENABLED(CONFIG_SPL_BUILD)
+   /* Always force clock manager into boot mode before any configuration */
+   clk_write_ctrl(plat,
+  CM_REG_READL(plat, CLKMGR_CTRL) | CLKMGR_CTRL_BOOTMODE);
+#else
+   /* Skip clock configuration in SSBL if it's not in boot mode */
+   if (!(CM_REG_READL(plat, CLKMGR_CTRL) & CLKMGR_CTRL_BOOTMODE))
+   return;
+#endif
+
+   /* Put both PLLs in bypass */
+   clk_write_bypass_mainpll(plat, CLKMGR_BYPASS_MAINPLL_ALL);
+   clk_write_bypass_perpll(plat, CLKMGR_BYPASS_PERPLL_ALL);
+
+   /* Put both PLLs in Reset */
+   CM_REG_SETBITS(plat, CLKMGR_MAINPLL_PLLCTRL,
+  CLKMGR_PLLCTRL_BYPASS_MASK);
+   CM_REG_SETBITS(plat, CLKMGR_PERPLL_PLLCTRL,
+  CLKMGR_PLLCTRL_BYPASS_MASK);
+
+   /* setup main PLL */
+   CM_REG_WRITEL(plat, cfg->main_pll_pllglob, CLKMGR_MAINPLL_PLLGLOB);
+   CM_REG_WRITEL(plat, cfg->main_pll_plldiv, CLKMGR_MAINPLL_PLLDIV);
+   CM_REG_WRITEL(plat, cfg->main_pll_plloutdiv, CLKMGR_MAINPLL_PLLOUTDIV);
+   CM_REG_WRITEL(plat, cfg->main_pll_mpuclk, CLKMGR_MAINPLL_MPUCLK);
+   CM_REG_WRITEL(plat, cfg->main_pll_nocclk, CLKMGR_MAINPLL_NOCCLK);
+   CM_REG_WRITEL(plat, cfg->main_pll_nocdiv, CLKMGR_MAINPLL_NOCDIV);
+
+   /* setup peripheral */
+   CM_REG_WRITEL(plat, cfg->per_pll_pllglob, CLKMGR_PERPLL_PLLGLOB);
+   CM_REG_WRITEL(plat, cfg->per_pll_plldiv, CLKMGR_PERPLL_PLLDIV);
+   CM_REG_WRITEL(plat, cfg->per_pll_plloutdiv, CLKMGR_PERPLL_PLLOUTDIV);
+   CM_REG_WRITEL(plat, cfg->per_pll_emacctl, CLKMGR_PERPLL_EMACCTL);
+   CM_REG_WRITEL(plat, cfg->per_pll_gpiodiv, CLKMGR_PERPLL_GPIODIV);
+
+   /* Take both PLL out of reset and power up */
+   CM_REG_CLRBITS(plat, CLKMGR_MAINPLL_PLLCTRL,
+  CLKMGR_PLLCTRL_BYPASS_MASK);
+   CM_REG_CLRBITS(plat, CLKMGR_PERPLL_PLLCTRL,
+  CLKMGR_PLLCTRL_BYPASS_MASK);
+
+   cm_wait_for_lock(CLKMGR_STAT_ALLPLL_LOCKED_MASK);
+
+   CM_REG_WRITEL(plat, cfg->alt_emacactr, CLKMGR_ALTR_EMACACTR);
+   CM_REG_WRITEL(plat, cfg->alt_emacbctr, CLKMGR_ALTR_EMACBCTR);
+   CM_REG_WRITEL(plat, cfg->alt_emacptpctr, CLKMGR_ALTR_EMACPTPCTR);
+   CM_REG_WRITEL(plat, cfg->alt_gpiodbctr, CLKMGR_ALTR_GPIODBCTR);
+   CM_REG_WRITEL(plat, cfg->alt_sdmmcctr, CLKMGR

[v2 07/17] drivers: clk: Add memory clock driver for Intel N5X device

2021-04-30 Thread Siew Chin Lim
Add memory clock manager driver for N5X. Provides memory clock
initialization and enable functions.

Signed-off-by: Siew Chin Lim 

---
v2:
- common.h need to be included before clock_manager.h
- For consistency, use small letter fo 0x0c and 0x1c in macros
---
 drivers/clk/altera/Makefile  |   1 +
 drivers/clk/altera/clk-mem-n5x.c | 136 +++
 drivers/clk/altera/clk-mem-n5x.h |  84 +++
 3 files changed, 221 insertions(+)
 create mode 100644 drivers/clk/altera/clk-mem-n5x.c
 create mode 100644 drivers/clk/altera/clk-mem-n5x.h

diff --git a/drivers/clk/altera/Makefile b/drivers/clk/altera/Makefile
index 38cd730685..33db092918 100644
--- a/drivers/clk/altera/Makefile
+++ b/drivers/clk/altera/Makefile
@@ -6,3 +6,4 @@
 obj-$(CONFIG_TARGET_SOCFPGA_AGILEX) += clk-agilex.o
 obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += clk-arria10.o
 obj-$(CONFIG_TARGET_SOCFPGA_N5X) += clk-n5x.o
+obj-$(CONFIG_TARGET_SOCFPGA_N5X) += clk-mem-n5x.o
diff --git a/drivers/clk/altera/clk-mem-n5x.c b/drivers/clk/altera/clk-mem-n5x.c
new file mode 100644
index 00..ca44998641
--- /dev/null
+++ b/drivers/clk/altera/clk-mem-n5x.c
@@ -0,0 +1,136 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020-2021 Intel Corporation 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include "clk-mem-n5x.h"
+#include 
+#include 
+#include 
+#include 
+#include 
+
+DECLARE_GLOBAL_DATA_PTR;
+
+struct socfpga_mem_clk_plat {
+   void __iomem *regs;
+};
+
+void clk_mem_wait_for_lock(struct socfpga_mem_clk_plat *plat, u32 mask)
+{
+   u32 inter_val;
+   u32 retry = 0;
+
+   do {
+   inter_val = CM_REG_READL(plat, MEMCLKMGR_STAT) & mask;
+
+   /* Wait for stable lock */
+   if (inter_val == mask)
+   retry++;
+   else
+   retry = 0;
+
+   if (retry >= 10)
+   return;
+   } while (1);
+}
+
+/*
+ * function to write the bypass register which requires a poll of the
+ * busy bit
+ */
+void clk_mem_write_bypass_mempll(struct socfpga_mem_clk_plat *plat, u32 val)
+{
+   CM_REG_WRITEL(plat, val, MEMCLKMGR_MEMPLL_BYPASS);
+}
+
+/*
+ * Setup clocks while making no assumptions about previous state of the clocks.
+ */
+static void clk_mem_basic_init(struct udevice *dev,
+  const struct cm_config * const cfg)
+{
+   struct socfpga_mem_clk_plat *plat = dev_get_plat(dev);
+
+   if (!cfg)
+   return;
+
+   /* Put PLLs in bypass */
+   clk_mem_write_bypass_mempll(plat, MEMCLKMGR_BYPASS_MEMPLL_ALL);
+
+   /* Put PLLs in Reset */
+   CM_REG_SETBITS(plat, MEMCLKMGR_MEMPLL_PLLCTRL,
+  MEMCLKMGR_PLLCTRL_BYPASS_MASK);
+
+   /* setup mem PLL */
+   CM_REG_WRITEL(plat, cfg->mem_memdiv, MEMCLKMGR_MEMPLL_MEMDIV);
+   CM_REG_WRITEL(plat, cfg->mem_pllglob, MEMCLKMGR_MEMPLL_PLLGLOB);
+   CM_REG_WRITEL(plat, cfg->mem_plldiv, MEMCLKMGR_MEMPLL_PLLDIV);
+   CM_REG_WRITEL(plat, cfg->mem_plloutdiv, MEMCLKMGR_MEMPLL_PLLOUTDIV);
+
+   /* Take PLL out of reset and power up */
+   CM_REG_CLRBITS(plat, MEMCLKMGR_MEMPLL_PLLCTRL,
+  MEMCLKMGR_PLLCTRL_BYPASS_MASK);
+}
+
+static int socfpga_mem_clk_enable(struct clk *clk)
+{
+   const struct cm_config *cm_default_cfg = cm_get_default_config();
+   struct socfpga_mem_clk_plat *plat = dev_get_plat(clk->dev);
+
+   clk_mem_basic_init(clk->dev, cm_default_cfg);
+
+   clk_mem_wait_for_lock(plat, MEMCLKMGR_STAT_ALLPLL_LOCKED_MASK);
+
+   CM_REG_WRITEL(plat, CM_REG_READL(plat, MEMCLKMGR_MEMPLL_PLLGLOB) |
+ MEMCLKMGR_PLLGLOB_CLR_LOSTLOCK_BYPASS_MASK,
+ MEMCLKMGR_MEMPLL_PLLGLOB);
+
+   /* Take all PLLs out of bypass */
+   clk_mem_write_bypass_mempll(plat, 0);
+
+   /* Clear the loss of lock bits (write 1 to clear) */
+   CM_REG_CLRBITS(plat, MEMCLKMGR_INTRCLR,
+  MEMCLKMGR_INTER_MEMPLLLOST_MASK);
+
+   /* Take all ping pong counters out of reset */
+   CM_REG_CLRBITS(plat, MEMCLKMGR_MEMPLL_EXTCNTRST,
+  MEMCLKMGR_EXTCNTRST_ALLCNTRST);
+
+   return 0;
+}
+
+static int socfpga_mem_clk_of_to_plat(struct udevice *dev)
+{
+   struct socfpga_mem_clk_plat *plat = dev_get_plat(dev);
+   fdt_addr_t addr;
+
+   addr = devfdt_get_addr(dev);
+   if (addr == FDT_ADDR_T_NONE)
+   return -EINVAL;
+   plat->regs = (void __iomem *)addr;
+
+   return 0;
+}
+
+static struct clk_ops socfpga_mem_clk_ops = {
+   .enable = socfpga_mem_clk_enable
+};
+
+static const struct udevice_id socfpga_mem_clk_match[] = {
+   { .compatible = "intel,n5x-mem-clkmgr" },
+   {}
+};
+
+U_BOOT_DRIVER(socfpga_n5x_mem_clk) = {
+   .name   = "mem-clk-n5x",
+   .id = UCLASS_CLK,
+   .of_match   = socfpga_mem_clk_match,
+   .ops= &socfpga_mem_cl

[v2 09/17] arm: socfpga: Add clock manager for Intel N5X device

2021-04-30 Thread Siew Chin Lim
Add clock manager for N5X.

Signed-off-by: Siew Chin Lim 
---
 ...k_manager_agilex.c => clock_manager_n5x.c} | 32 +--
 .../mach-socfpga/include/mach/clock_manager.h |  2 ++
 .../include/mach/clock_manager_n5x.h  | 12 +++
 3 files changed, 29 insertions(+), 17 deletions(-)
 copy arch/arm/mach-socfpga/{clock_manager_agilex.c => clock_manager_n5x.c} 
(64%)
 create mode 100644 arch/arm/mach-socfpga/include/mach/clock_manager_n5x.h

diff --git a/arch/arm/mach-socfpga/clock_manager_agilex.c 
b/arch/arm/mach-socfpga/clock_manager_n5x.c
similarity index 64%
copy from arch/arm/mach-socfpga/clock_manager_agilex.c
copy to arch/arm/mach-socfpga/clock_manager_n5x.c
index e035c09aae..4f098533e7 100644
--- a/arch/arm/mach-socfpga/clock_manager_agilex.c
+++ b/arch/arm/mach-socfpga/clock_manager_n5x.c
@@ -1,19 +1,18 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2019 Intel Corporation 
+ * Copyright (C) 2020-2021 Intel Corporation 
  *
  */
 
-#include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -25,7 +24,7 @@ static ulong cm_get_rate_dm(u32 id)
int ret;
 
ret = uclass_get_device_by_driver(UCLASS_CLK,
- DM_DRIVER_GET(socfpga_agilex_clk),
+ DM_DRIVER_GET(socfpga_n5x_clk),
  &dev);
if (ret)
return 0;
@@ -39,8 +38,7 @@ static ulong cm_get_rate_dm(u32 id)
 
clk_free(&clk);
 
-   if ((rate == (unsigned long)-ENOSYS) ||
-   (rate == (unsigned long)-ENXIO) ||
+   if ((rate == (unsigned long)-ENXIO) ||
(rate == (unsigned long)-EIO)) {
debug("%s id %u: clk_get_rate err: %ld\n",
  __func__, id, rate);
@@ -57,26 +55,26 @@ static u32 cm_get_rate_dm_khz(u32 id)
 
 unsigned long cm_get_mpu_clk_hz(void)
 {
-   return cm_get_rate_dm(AGILEX_MPU_CLK);
+   return cm_get_rate_dm(N5X_MPU_CLK);
 }
 
 unsigned int cm_get_l4_sys_free_clk_hz(void)
 {
-   return cm_get_rate_dm(AGILEX_L4_SYS_FREE_CLK);
+   return cm_get_rate_dm(N5X_L4_SYS_FREE_CLK);
 }
 
 void cm_print_clock_quick_summary(void)
 {
printf("MPU   %10d kHz\n",
-  cm_get_rate_dm_khz(AGILEX_MPU_CLK));
+  cm_get_rate_dm_khz(N5X_MPU_CLK));
printf("L4 Main %8d kHz\n",
-  cm_get_rate_dm_khz(AGILEX_L4_MAIN_CLK));
+  cm_get_rate_dm_khz(N5X_L4_MAIN_CLK));
printf("L4 sys free %8d kHz\n",
-  cm_get_rate_dm_khz(AGILEX_L4_SYS_FREE_CLK));
+  cm_get_rate_dm_khz(N5X_L4_SYS_FREE_CLK));
printf("L4 MP   %8d kHz\n",
-  cm_get_rate_dm_khz(AGILEX_L4_MP_CLK));
+  cm_get_rate_dm_khz(N5X_L4_MP_CLK));
printf("L4 SP   %8d kHz\n",
-  cm_get_rate_dm_khz(AGILEX_L4_SP_CLK));
+  cm_get_rate_dm_khz(N5X_L4_SP_CLK));
printf("SDMMC   %8d kHz\n",
-  cm_get_rate_dm_khz(AGILEX_SDMMC_CLK));
+  cm_get_rate_dm_khz(N5X_SDMMC_CLK));
 }
diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager.h 
b/arch/arm/mach-socfpga/include/mach/clock_manager.h
index d0b172a30e..a8cb07a1c4 100644
--- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
@@ -28,6 +28,8 @@ int cm_set_qspi_controller_clk_hz(u32 clk_hz);
 #include 
 #elif defined(CONFIG_TARGET_SOCFPGA_AGILEX)
 #include 
+#elif IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
+#include 
 #endif
 
 #endif /* _CLOCK_MANAGER_H_ */
diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager_n5x.h 
b/arch/arm/mach-socfpga/include/mach/clock_manager_n5x.h
new file mode 100644
index 00..54615ae8f7
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/clock_manager_n5x.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2020-2021 Intel Corporation 
+ */
+
+#ifndef _CLOCK_MANAGER_N5X_
+#define _CLOCK_MANAGER_N5X_
+
+#include 
+#include "../../../../../drivers/clk/altera/clk-n5x.h"
+
+#endif /* _CLOCK_MANAGER_N5X_ */
-- 
2.19.0



[v2 08/17] arm: socfpga: Move cm_get_mpu_clk_hz function declaration to clock_manager.h

2021-04-30 Thread Siew Chin Lim
Move cm_get_mpu_clk_hz function declaration from individual device's
clock manager header file to common clock_manager.h.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/mach-socfpga/include/mach/clock_manager.h | 1 +
 arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h  | 2 --
 arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h | 1 -
 arch/arm/mach-socfpga/include/mach/clock_manager_gen5.h| 1 -
 arch/arm/mach-socfpga/include/mach/clock_manager_s10.h | 1 -
 5 files changed, 1 insertion(+), 5 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager.h 
b/arch/arm/mach-socfpga/include/mach/clock_manager.h
index 2f9b471af3..d0b172a30e 100644
--- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
+++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
@@ -12,6 +12,7 @@ phys_addr_t socfpga_get_clkmgr_addr(void);
 void cm_wait_for_lock(u32 mask);
 int cm_wait_for_fsm(void);
 void cm_print_clock_quick_summary(void);
+unsigned long cm_get_mpu_clk_hz(void);
 unsigned int cm_get_qspi_controller_clk_hz(void);
 
 #if defined(CONFIG_TARGET_SOCFPGA_SOC64)
diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h 
b/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
index 386e82a4e3..4feae3dda9 100644
--- a/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
+++ b/arch/arm/mach-socfpga/include/mach/clock_manager_agilex.h
@@ -6,8 +6,6 @@
 #ifndef _CLOCK_MANAGER_AGILEX_
 #define _CLOCK_MANAGER_AGILEX_
 
-unsigned long cm_get_mpu_clk_hz(void);
-
 #include 
 #include "../../../../../drivers/clk/altera/clk-agilex.h"
 
diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h 
b/arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h
index 798d3741bd..553ebe660d 100644
--- a/arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h
+++ b/arch/arm/mach-socfpga/include/mach/clock_manager_arria10.h
@@ -68,7 +68,6 @@ int cm_basic_init(const void *blob);
 
 #include 
 unsigned int cm_get_l4_sp_clk_hz(void);
-unsigned long cm_get_mpu_clk_hz(void);
 
 #endif /* __ASSEMBLY__ */
 
diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager_gen5.h 
b/arch/arm/mach-socfpga/include/mach/clock_manager_gen5.h
index 4cc1268b4c..d53095a7da 100644
--- a/arch/arm/mach-socfpga/include/mach/clock_manager_gen5.h
+++ b/arch/arm/mach-socfpga/include/mach/clock_manager_gen5.h
@@ -96,7 +96,6 @@ struct cm_config {
 #define CLKMGR_PERPLL_EN   CLKMGR_GEN5_PERPLL_EN
 
 /* Clock speed accessors */
-unsigned long cm_get_mpu_clk_hz(void);
 unsigned long cm_get_sdram_clk_hz(void);
 unsigned int cm_get_l4_sp_clk_hz(void);
 unsigned int cm_get_mmc_controller_clk_hz(void);
diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager_s10.h 
b/arch/arm/mach-socfpga/include/mach/clock_manager_s10.h
index 98c3bf1b03..7f10296dc7 100644
--- a/arch/arm/mach-socfpga/include/mach/clock_manager_s10.h
+++ b/arch/arm/mach-socfpga/include/mach/clock_manager_s10.h
@@ -11,7 +11,6 @@
 #include 
 
 /* Clock speed accessors */
-unsigned long cm_get_mpu_clk_hz(void);
 unsigned long cm_get_sdram_clk_hz(void);
 unsigned int cm_get_l4_sp_clk_hz(void);
 unsigned int cm_get_mmc_controller_clk_hz(void);
-- 
2.19.0



[v2 10/17] arm: socfpga: Changed misc_s10.c to misc_soc64.c

2021-04-30 Thread Siew Chin Lim
Rename to common file name to used by all SOC64 devices.
No functionality change.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/mach-socfpga/Makefile |  4 ++--
 arch/arm/mach-socfpga/{misc_s10.c => misc_soc64.c} | 12 ++--
 2 files changed, 8 insertions(+), 8 deletions(-)
 rename arch/arm/mach-socfpga/{misc_s10.c => misc_soc64.c} (100%)

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 5779c55621..58afde950f 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -32,7 +32,7 @@ ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
 obj-y  += clock_manager_s10.o
 obj-y  += lowlevel_init_soc64.o
 obj-y  += mailbox_s10.o
-obj-y  += misc_s10.o
+obj-y  += misc_soc64.o
 obj-y  += mmu-arm64_s10.o
 obj-y  += reset_manager_s10.o
 obj-y  += system_manager_soc64.o
@@ -45,7 +45,7 @@ ifdef CONFIG_TARGET_SOCFPGA_AGILEX
 obj-y  += clock_manager_agilex.o
 obj-y  += lowlevel_init_soc64.o
 obj-y  += mailbox_s10.o
-obj-y  += misc_s10.o
+obj-y  += misc_soc64.o
 obj-y  += mmu-arm64_s10.o
 obj-y  += reset_manager_s10.o
 obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += secure_vab.o
diff --git a/arch/arm/mach-socfpga/misc_s10.c 
b/arch/arm/mach-socfpga/misc_soc64.c
similarity index 100%
rename from arch/arm/mach-socfpga/misc_s10.c
rename to arch/arm/mach-socfpga/misc_soc64.c
index 50c7f19ae1..7b973a79e8 100644
--- a/arch/arm/mach-socfpga/misc_s10.c
+++ b/arch/arm/mach-socfpga/misc_soc64.c
@@ -6,16 +6,16 @@
 
 #include 
 #include 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
-- 
2.19.0



[v2 11/17] ddr: socfpga: Enable memory test on memory size less than 1GB

2021-04-30 Thread Siew Chin Lim
From: Tien Fong Chee 

Minimum 1GB memory size is required in current memory test, so this patch
improves the memory test for processing memory size less than 1GB, and
the size in power of two.

Signed-off-by: Tien Fong Chee 

---
v2:
- Renamed local variable “total_size” to “remaining_size”
---
 drivers/ddr/altera/sdram_soc64.c | 24 +---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/drivers/ddr/altera/sdram_soc64.c b/drivers/ddr/altera/sdram_soc64.c
index a08f0953e5..cc656db97c 100644
--- a/drivers/ddr/altera/sdram_soc64.c
+++ b/drivers/ddr/altera/sdram_soc64.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2016-2019 Intel Corporation 
+ * Copyright (C) 2016-2021 Intel Corporation 
  *
  */
 
@@ -182,6 +182,7 @@ void sdram_size_check(struct bd_info *bd)
phys_size_t total_ram_check = 0;
phys_size_t ram_check = 0;
phys_addr_t start = 0;
+   phys_size_t size, remaining_size;
int bank;
 
/* Sanity check ensure correct SDRAM size specified */
@@ -189,10 +190,27 @@ void sdram_size_check(struct bd_info *bd)
 
for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
start = bd->bi_dram[bank].start;
+   remaining_size = bd->bi_dram[bank].size;
while (ram_check < bd->bi_dram[bank].size) {
-   ram_check += get_ram_size((void *)(start + ram_check),
-(phys_size_t)SZ_1G);
+   size = min((phys_addr_t)SZ_1G,
+  (phys_addr_t)remaining_size);
+
+   /*
+* Ensure the size is power of two, this is requirement
+* to run get_ram_size() / memory test
+*/
+   if (size != 0 && ((size & (size - 1)) == 0)) {
+   ram_check += get_ram_size((void *)
+   (start + ram_check), size);
+   remaining_size = bd->bi_dram[bank].size -
+   ram_check;
+   } else {
+   puts("DDR: Memory test requires SDRAM size ");
+   puts("in power of two!\n");
+   hang();
+   }
}
+
total_ram_check += ram_check;
ram_check = 0;
}
-- 
2.19.0



[v2 13/17] arm: socfpga: Add SPL for Intel N5X device

2021-04-30 Thread Siew Chin Lim
Add SPL for N5X.

Signed-off-by: Siew Chin Lim 
---
 .../mach-socfpga/{spl_agilex.c => spl_n5x.c}  | 37 +++
 1 file changed, 22 insertions(+), 15 deletions(-)
 copy arch/arm/mach-socfpga/{spl_agilex.c => spl_n5x.c} (83%)

diff --git a/arch/arm/mach-socfpga/spl_agilex.c 
b/arch/arm/mach-socfpga/spl_n5x.c
similarity index 83%
copy from arch/arm/mach-socfpga/spl_agilex.c
copy to arch/arm/mach-socfpga/spl_n5x.c
index ee5a9dc1e2..d056871d29 100644
--- a/arch/arm/mach-socfpga/spl_agilex.c
+++ b/arch/arm/mach-socfpga/spl_n5x.c
@@ -1,27 +1,26 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2019 Intel Corporation 
+ * Copyright (C) 2020-2021 Intel Corporation 
  *
  */
 
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
 #include 
-#include 
-#include 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
 #include 
-#include 
+#include 
+#include 
+#include 
+#include 
 #include 
+#include 
+#include 
+#include 
+#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -54,27 +53,35 @@ void board_init_f(ulong dummy)
 
sysmgr_pinmux_init();
 
+   preloader_console_init();
+
ret = uclass_get_device(UCLASS_CLK, 0, &dev);
if (ret) {
-   debug("Clock init failed: %d\n", ret);
+   printf("Clock init failed: %d\n", ret);
+   hang();
+   }
+
+   ret = uclass_get_device(UCLASS_CLK, 1, &dev);
+   if (ret) {
+   printf("Memory clock init failed: %d\n", ret);
hang();
}
 
-   preloader_console_init();
print_reset_info();
cm_print_clock_quick_summary();
 
firewall_setup();
+
ret = uclass_get_device(UCLASS_CACHE, 0, &dev);
if (ret) {
-   debug("CCU init failed: %d\n", ret);
+   printf("CCU init failed: %d\n", ret);
hang();
}
 
 #if CONFIG_IS_ENABLED(ALTERA_SDRAM)
ret = uclass_get_device(UCLASS_RAM, 0, &dev);
if (ret) {
-   debug("DRAM init failed: %d\n", ret);
+   printf("DRAM init failed: %d\n", ret);
hang();
}
 #endif
-- 
2.19.0



[v2 15/17] arm: dts: Add base dtsi and devkit dts for Intel N5X device

2021-04-30 Thread Siew Chin Lim
Add device tree for N5X.

Signed-off-by: Siew Chin Lim 
Signed-off-by: Tien Fong Chee 

---
v2:
- Remove socfpga_n5x.dtsi
- Reuse socfpga_agilex.dtsi in socfpga_n5x_socdk.dts and update
  n5x data accordingly.
---
 arch/arm/dts/Makefile |   1 +
 ...ex-u-boot.dtsi => socfpga_n5x-u-boot.dtsi} |  13 ++-
 arch/arm/dts/socfpga_n5x_socdk-u-boot.dtsi|  67 +++
 ...agilex_socdk.dts => socfpga_n5x_socdk.dts} | 110 +-
 4 files changed, 182 insertions(+), 9 deletions(-)
 copy arch/arm/dts/{socfpga_agilex-u-boot.dtsi => socfpga_n5x-u-boot.dtsi} (85%)
 create mode 100644 arch/arm/dts/socfpga_n5x_socdk-u-boot.dtsi
 copy arch/arm/dts/{socfpga_agilex_socdk.dts => socfpga_n5x_socdk.dts} (57%)

diff --git a/arch/arm/dts/Makefile b/arch/arm/dts/Makefile
index aec5020a0f..2e13277816 100644
--- a/arch/arm/dts/Makefile
+++ b/arch/arm/dts/Makefile
@@ -381,6 +381,7 @@ dtb-$(CONFIG_ARCH_SOCFPGA) +=   
\
socfpga_cyclone5_socrates.dtb   \
socfpga_cyclone5_sr1500.dtb \
socfpga_cyclone5_vining_fpga.dtb\
+   socfpga_n5x_socdk.dtb   \
socfpga_stratix10_socdk.dtb
 
 dtb-$(CONFIG_TARGET_DRA7XX_EVM) += dra72-evm.dtb dra7-evm.dtb  \
diff --git a/arch/arm/dts/socfpga_agilex-u-boot.dtsi 
b/arch/arm/dts/socfpga_n5x-u-boot.dtsi
similarity index 85%
copy from arch/arm/dts/socfpga_agilex-u-boot.dtsi
copy to arch/arm/dts/socfpga_n5x-u-boot.dtsi
index 08f7cf7f7a..2f63f4a4e6 100644
--- a/arch/arm/dts/socfpga_agilex-u-boot.dtsi
+++ b/arch/arm/dts/socfpga_n5x-u-boot.dtsi
@@ -2,7 +2,7 @@
 /*
  * U-Boot additions
  *
- * Copyright (C) 2019-2020 Intel Corporation 
+ * Copyright (C) 2020-2021 Intel Corporation 
  */
 
 #include "socfpga_soc64_fit-u-boot.dtsi"
@@ -53,6 +53,10 @@
reset-names = "i2c";
 };
 
+&memclkmgr {
+   u-boot,dm-pre-reloc;
+};
+
 &mmc {
resets = <&rst SDMMC_RESET>, <&rst SDMMC_OCP_RESET>;
 };
@@ -76,11 +80,10 @@
 };
 
 &sdr {
-   compatible = "intel,sdr-ctl-agilex";
-   reg = <0xf8000400 0x80>,
- <0xf801 0x190>,
- <0xf8011000 0x500>;
+   compatible = "intel,sdr-ctl-n5x";
resets = <&rst DDRSCH_RESET>;
+   clocks = <&memclkmgr>;
+   clock-names = "mem_clk";
u-boot,dm-pre-reloc;
 };
 
diff --git a/arch/arm/dts/socfpga_n5x_socdk-u-boot.dtsi 
b/arch/arm/dts/socfpga_n5x_socdk-u-boot.dtsi
new file mode 100644
index 00..57509f083e
--- /dev/null
+++ b/arch/arm/dts/socfpga_n5x_socdk-u-boot.dtsi
@@ -0,0 +1,67 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * U-Boot additions
+ *
+ * Copyright (C) 2020-2021 Intel Corporation 
+ */
+
+#include "socfpga_n5x-u-boot.dtsi"
+
+/{
+   aliases {
+   spi0 = &qspi;
+   i2c0 = &i2c1;
+   };
+
+   memory {
+   /*
+* Memory type: DDR4
+* 16GB
+* <0 0x 0 0x8000>,
+* <4 0x8000 3 0x8000>;
+*
+* 8GB
+* <0 0x 0 0x8000>,
+* <2 0x8000 1 0x8000>;
+*
+* 4GB
+* <0 0x 0 0x8000>,
+* <1 0x8000 0 0x8000>;
+*
+* Memory type: LPDDR4 (non-interleaving mode)
+* Total memory size 3GB, usable = 2.5GB, 0.5GB trade off for 
secure
+* region.
+*/
+   reg = <0 0x 0 0x6000>,
+ <0x10 0x0010 0 0x4000>;
+   };
+};
+
+&flash0 {
+   compatible = "jedec,spi-nor";
+   spi-tx-bus-width = <4>;
+   spi-rx-bus-width = <4>;
+   u-boot,dm-pre-reloc;
+};
+
+&i2c1 {
+   status = "okay";
+};
+
+&nand {
+   u-boot,dm-pre-reloc;
+};
+
+&mmc {
+   drvsel = <3>;
+   smplsel = <0>;
+   u-boot,dm-pre-reloc;
+};
+
+&qspi {
+   status = "okay";
+};
+
+&watchdog0 {
+   u-boot,dm-pre-reloc;
+};
diff --git a/arch/arm/dts/socfpga_agilex_socdk.dts 
b/arch/arm/dts/socfpga_n5x_socdk.dts
similarity index 57%
copy from arch/arm/dts/socfpga_agilex_socdk.dts
copy to arch/arm/dts/socfpga_n5x_socdk.dts
index bcdeecc0e0..30130bb910 100644
--- a/arch/arm/dts/socfpga_agilex_socdk.dts
+++ b/arch/arm/dts/socfpga_n5x_socdk.dts
@@ -1,11 +1,12 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2019, Intel Corporation
+ * Copyright (C) 2020-2021, Intel Corporation
  */
 #include "socfpga_agilex.dtsi"
+#include 
 
 / {
-   model = "SoCFPGA Agilex SoCDK";
+   model = "eASIC N5X SoCDK";
 
aliases {
serial0 = &uart0;
@@ -16,6 +17,7 @@
 
chosen {
stdout-path = "serial0:115200n8";
+   u-boot,boot0 = <&mmc>;
};
 
leds {
@@ -47,10 +49,26 @@
osc1 {
clock-frequen

[v2 14/17] board: intel: Add socdk board support for Intel N5X device

2021-04-30 Thread Siew Chin Lim
Add N5X SoC devkit board.

Signed-off-by: Siew Chin Lim 
---
 board/intel/n5x-socdk/MAINTAINERS  | 7 +++
 board/{altera/stratix10-socdk => intel/n5x-socdk}/Makefile | 2 +-
 .../{altera/stratix10-socdk => intel/n5x-socdk}/socfpga.c  | 2 +-
 3 files changed, 9 insertions(+), 2 deletions(-)
 create mode 100644 board/intel/n5x-socdk/MAINTAINERS
 copy board/{altera/stratix10-socdk => intel/n5x-socdk}/Makefile (50%)
 copy board/{altera/stratix10-socdk => intel/n5x-socdk}/socfpga.c (52%)

diff --git a/board/intel/n5x-socdk/MAINTAINERS 
b/board/intel/n5x-socdk/MAINTAINERS
new file mode 100644
index 00..c1059f092c
--- /dev/null
+++ b/board/intel/n5x-socdk/MAINTAINERS
@@ -0,0 +1,7 @@
+SOCFPGA BOARD
+M: Chee Tien Fong 
+M: Lim Siew Chin 
+S: Maintained
+F: board/intel/n5x-socdk/
+F: include/configs/socfpga_n5x_socdk.h
+F: configs/socfpga_n5x_atf_defconfig
diff --git a/board/altera/stratix10-socdk/Makefile 
b/board/intel/n5x-socdk/Makefile
similarity index 50%
copy from board/altera/stratix10-socdk/Makefile
copy to board/intel/n5x-socdk/Makefile
index 02a9cadf76..accfdcddcb 100644
--- a/board/altera/stratix10-socdk/Makefile
+++ b/board/intel/n5x-socdk/Makefile
@@ -1,5 +1,5 @@
 #
-# Copyright (C) 2016-2017 Intel Corporation 
+# Copyright (C) 2020-2021 Intel Corporation 
 #
 # SPDX-License-Identifier: GPL-2.0
 #
diff --git a/board/altera/stratix10-socdk/socfpga.c 
b/board/intel/n5x-socdk/socfpga.c
similarity index 52%
copy from board/altera/stratix10-socdk/socfpga.c
copy to board/intel/n5x-socdk/socfpga.c
index 043fc543f1..985ba190d0 100644
--- a/board/altera/stratix10-socdk/socfpga.c
+++ b/board/intel/n5x-socdk/socfpga.c
@@ -1,6 +1,6 @@
 // SPDX-License-Identifier: GPL-2.0
 /*
- * Copyright (C) 2016-2018 Intel Corporation 
+ * Copyright (C) 2020-2021 Intel Corporation 
  *
  */
 
-- 
2.19.0



[v2 12/17] ddr: altera: Add SDRAM driver for Intel N5X device

2021-04-30 Thread Siew Chin Lim
The DDR subsystem in Diamond Mesa is consisted of controller, PHY,
memory reset manager and memory clock manager.

Configuration settings of controller, PHY and  memory reset manager
is come from DDR handoff data in bitstream, which contain the register
base addresses and user settings from tool.

Configuration settings of memory clock manager is come from the HPS
handoff data in bitstream, however the register base address is defined
in device tree.

The calibration is fully done in HPS, which requires IMEM and DMEM
binaries loading to PHY SRAM for running this calibration, both
IMEM and DMEM binaries are also part of bitstream, this bitstream
would be loaded to OCRAM by SDM, and configured by DDR driver.

Signed-off-by: Siew Chin Lim 
Signed-off-by: Tien Fong Chee 

---
v2:
- Move is_ddr_init_skipped and its helper functions to DDR driver and
  converted function to positive checking
- Using GENMASK() macro
- Fixed typo
- Return status of subfunction
- Changed dm to n5x
---
 arch/arm/mach-socfpga/include/mach/firewall.h |6 +
 .../include/mach/system_manager_soc64.h   |   10 +-
 drivers/ddr/altera/Makefile   |3 +-
 drivers/ddr/altera/sdram_n5x.c| 2299 +
 drivers/ddr/altera/sdram_soc64.c  |   70 +
 drivers/ddr/altera/sdram_soc64.h  |1 +
 6 files changed, 2387 insertions(+), 2 deletions(-)
 create mode 100644 drivers/ddr/altera/sdram_n5x.c

diff --git a/arch/arm/mach-socfpga/include/mach/firewall.h 
b/arch/arm/mach-socfpga/include/mach/firewall.h
index adab65bc96..5cb7f23f8f 100644
--- a/arch/arm/mach-socfpga/include/mach/firewall.h
+++ b/arch/arm/mach-socfpga/include/mach/firewall.h
@@ -115,10 +115,16 @@ struct socfpga_firwall_l4_sys {
 /* Firewall MPU DDR SCR registers */
 #define FW_MPU_DDR_SCR_EN  0x00
 #define FW_MPU_DDR_SCR_EN_SET  0x04
+#define FW_MPU_DDR_SCR_MPUREGION0ADDR_BASE 0x10
+#define FW_MPU_DDR_SCR_MPUREGION0ADDR_BASEEXT  0x14
 #define FW_MPU_DDR_SCR_MPUREGION0ADDR_LIMIT0x18
 #define FW_MPU_DDR_SCR_MPUREGION0ADDR_LIMITEXT 0x1c
+
+#define FW_MPU_DDR_SCR_NONMPUREGION0ADDR_BASE  0x90
+#define FW_MPU_DDR_SCR_NONMPUREGION0ADDR_BASEEXT   0x94
 #define FW_MPU_DDR_SCR_NONMPUREGION0ADDR_LIMIT 0x98
 #define FW_MPU_DDR_SCR_NONMPUREGION0ADDR_LIMITEXT  0x9c
+#define FW_MPU_DDR_SCR_NONMPUREGION0ADDR_LIMITEXT_FIELD0xff
 
 #define MPUREGION0_ENABLE  BIT(0)
 #define NONMPUREGION0_ENABLE   BIT(8)
diff --git a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h 
b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
index fc4e17821b..a8009664fe 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
@@ -1,6 +1,6 @@
 /* SPDX-License-Identifier: GPL-2.0 */
 /*
- * Copyright (C) 2019 Intel Corporation 
+ * Copyright (C) 2019-2021 Intel Corporation 
  */
 
 #ifndef _SYSTEM_MANAGER_SOC64_H_
@@ -28,8 +28,12 @@ void populate_sysmgr_pinmux(void);
 #define SYSMGR_SOC64_FPGAINTF_EN2  0x6c
 #define SYSMGR_SOC64_FPGAINTF_EN3  0x70
 #define SYSMGR_SOC64_DMA_L3MASTER  0x74
+#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
+#define SYSMGR_SOC64_DDR_MODE  0xb8
+#else
 #define SYSMGR_SOC64_HMC_CLK   0xb4
 #define SYSMGR_SOC64_IO_PA_CTRL0xb8
+#endif
 #define SYSMGR_SOC64_NOC_TIMEOUT   0xc0
 #define SYSMGR_SOC64_NOC_IDLEREQ_SET   0xc4
 #define SYSMGR_SOC64_NOC_IDLEREQ_CLR   0xc8
@@ -143,4 +147,8 @@ void populate_sysmgr_pinmux(void);
 
 #define SYSMGR_WDDBG_PAUSE_ALL_CPU 0x0F0F0F0F
 
+#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_N5X)
+#defineSYSMGR_SOC64_DDR_MODE_MSK   BIT(0)
+#endif
+
 #endif /* _SYSTEM_MANAGER_SOC64_H_ */
diff --git a/drivers/ddr/altera/Makefile b/drivers/ddr/altera/Makefile
index 39dfee5d5a..9fa5d85a27 100644
--- a/drivers/ddr/altera/Makefile
+++ b/drivers/ddr/altera/Makefile
@@ -4,11 +4,12 @@
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 #
 # (C) Copyright 2010, Thomas Chou 
-# Copyright (C) 2014 Altera Corporation 
+# Copyright (C) 2014-2021 Altera Corporation 
 
 ifdef CONFIG_$(SPL_)ALTERA_SDRAM
 obj-$(CONFIG_TARGET_SOCFPGA_GEN5) += sdram_gen5.o sequencer.o
 obj-$(CONFIG_TARGET_SOCFPGA_ARRIA10) += sdram_arria10.o
 obj-$(CONFIG_TARGET_SOCFPGA_STRATIX10) += sdram_soc64.o sdram_s10.o
 obj-$(CONFIG_TARGET_SOCFPGA_AGILEX) += sdram_soc64.o sdram_agilex.o
+obj-$(CONFIG_TARGET_SOCFPGA_N5X) += sdram_soc64.o sdram_n5x.o
 endif
diff --git a/drivers/ddr/altera/sdram_n5x.c b/drivers/ddr/altera/sdram_n5x.c
new file mode 100644
index 00..f86342e4ef
--- /dev/null
+++ b/drivers/ddr/altera/sdram_n5x.c
@@ -0,0 +1,2299 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (C) 2020-2021 Intel Corporation 
+ *
+ */
+
+#include 
+#include

[v2 16/17] include: configs: Add Intel N5X device CONFIGs

2021-04-30 Thread Siew Chin Lim
Add CONFIGs for N5X.

Signed-off-by: Siew Chin Lim 
---
 include/configs/socfpga_n5x_socdk.h | 45 +
 1 file changed, 45 insertions(+)
 create mode 100644 include/configs/socfpga_n5x_socdk.h

diff --git a/include/configs/socfpga_n5x_socdk.h 
b/include/configs/socfpga_n5x_socdk.h
new file mode 100644
index 00..c295e91e3d
--- /dev/null
+++ b/include/configs/socfpga_n5x_socdk.h
@@ -0,0 +1,45 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2020-2021 Intel Corporation 
+ *
+ */
+
+#ifndef __CONFIG_SOCFGPA_N5X_H__
+#define __CONFIG_SOCFGPA_N5X_H__
+
+#include 
+
+#undef CONFIG_EXTRA_ENV_SETTINGS
+#define CONFIG_EXTRA_ENV_SETTINGS \
+   "loadaddr=" __stringify(CONFIG_SYS_LOAD_ADDR) "\0" \
+   "bootfile=" CONFIG_BOOTFILE "\0" \
+   "fdt_addr=110\0" \
+   "fdtimage=" CONFIG_DEFAULT_DEVICE_TREE ".dtb\0" \
+   "mmcroot=/dev/mmcblk0p2\0" \
+   "mmcboot=setenv bootargs " CONFIG_BOOTARGS \
+   " root=${mmcroot} rw rootwait;" \
+   "booti ${loadaddr} - ${fdt_addr}\0" \
+   "mmcload=mmc rescan;" \
+   "load mmc 0:1 ${loadaddr} ${bootfile};" \
+   "load mmc 0:1 ${fdt_addr} ${fdtimage}\0" \
+   "mmcfitboot=setenv bootargs " CONFIG_BOOTARGS \
+   " root=${mmcroot} rw rootwait;" \
+   "bootm ${loadaddr}\0" \
+   "mmcfitload=mmc rescan;" \
+   "load mmc 0:1 ${loadaddr} ${bootfile}\0" \
+   "ramboot=setenv bootargs " CONFIG_BOOTARGS";" \
+   "booti ${loadaddr} - ${fdt_addr}\0" \
+   "linux_qspi_enable=if sf probe; then " \
+   "echo Enabling QSPI at Linux DTB...;" \
+   "fdt addr ${fdt_addr}; fdt resize;" \
+   "fdt set /soc/spi@ff8d2000 status okay;" \
+   "if fdt set /soc/clocks/qspi-clk clock-frequency" \
+   " ${qspi_clock}; then" \
+   " else fdt set /soc/clkmgr/clocks/qspi_clk clock-frequency" \
+   " ${qspi_clock}; fi; fi\0" \
+   "scriptaddr=0x0210\0" \
+   "scriptfile=u-boot.scr\0" \
+   "fatscript=if fatload mmc 0:1 ${scriptaddr} ${scriptfile};" \
+  "then source ${scriptaddr}; fi\0"
+
+#endif /* __CONFIG_SOCFGPA_N5X_H__ */
-- 
2.19.0



[v2 17/17] arm: socfpga: Enable Intel N5X device build

2021-04-30 Thread Siew Chin Lim
Add defconfig for N5X to support legacy, ATF and VAB boot flow.

Signed-off-by: Siew Chin Lim 

---
v2:
- Move linux_qspi_enable from bootcommand
---
 arch/arm/mach-socfpga/Kconfig | 21 +-
 arch/arm/mach-socfpga/Makefile| 28 +++
 ...ab_defconfig => socfpga_n5x_atf_defconfig} | 12 
 ...agilex_defconfig => socfpga_n5x_defconfig} | 14 --
 ...ab_defconfig => socfpga_n5x_vab_defconfig} | 11 
 5 files changed, 61 insertions(+), 25 deletions(-)
 copy configs/{socfpga_agilex_vab_defconfig => socfpga_n5x_atf_defconfig} (87%)
 copy configs/{socfpga_agilex_defconfig => socfpga_n5x_defconfig} (82%)
 copy configs/{socfpga_agilex_vab_defconfig => socfpga_n5x_vab_defconfig} (87%)

diff --git a/arch/arm/mach-socfpga/Kconfig b/arch/arm/mach-socfpga/Kconfig
index 0c35406232..a4d733c756 100644
--- a/arch/arm/mach-socfpga/Kconfig
+++ b/arch/arm/mach-socfpga/Kconfig
@@ -8,7 +8,7 @@ config NR_DRAM_BANKS
 
 config SOCFPGA_SECURE_VAB_AUTH
bool "Enable boot image authentication with Secure Device Manager"
-   depends on TARGET_SOCFPGA_AGILEX
+   depends on TARGET_SOCFPGA_AGILEX || TARGET_SOCFPGA_N5X
select FIT_IMAGE_POST_PROCESS
select SHA384
select SHA512_ALGO
@@ -91,6 +91,22 @@ config TARGET_SOCFPGA_GEN5
imply SPL_SYS_MALLOC_SIMPLE
imply SPL_USE_TINY_PRINTF
 
+config TARGET_SOCFPGA_N5X
+   bool
+   select ARMV8_MULTIENTRY
+   select ARMV8_SET_SMPEN
+   select BINMAN if SPL_ATF
+   select CLK
+   select FPGA_INTEL_SDM_MAILBOX
+   select NCORE_CACHE
+   select SPL_ALTERA_SDRAM
+   select SPL_CLK if SPL
+   select TARGET_SOCFPGA_SOC64
+
+config TARGET_SOCFPGA_N5X_SOCDK
+   bool "Intel eASIC SoCDK (N5X)"
+   select TARGET_SOCFPGA_N5X
+
 config TARGET_SOCFPGA_SOC64
bool
 
@@ -183,6 +199,7 @@ config SYS_BOARD
default "de0-nano-soc" if TARGET_SOCFPGA_TERASIC_DE0_NANO
default "de1-soc" if TARGET_SOCFPGA_TERASIC_DE1_SOC
default "de10-nano" if TARGET_SOCFPGA_TERASIC_DE10_NANO
+   default "n5x-socdk" if TARGET_SOCFPGA_N5X_SOCDK
default "is1" if TARGET_SOCFPGA_IS1
default "mcvevk" if TARGET_SOCFPGA_ARIES_MCVEVK
default "secu1" if TARGET_SOCFPGA_ARRIA5_SECU1
@@ -194,6 +211,7 @@ config SYS_BOARD
 
 config SYS_VENDOR
default "intel" if TARGET_SOCFPGA_AGILEX_SOCDK
+   default "intel" if TARGET_SOCFPGA_N5X_SOCDK
default "altera" if TARGET_SOCFPGA_ARRIA5_SOCDK
default "altera" if TARGET_SOCFPGA_ARRIA10_SOCDK
default "altera" if TARGET_SOCFPGA_CYCLONE5_SOCDK
@@ -221,6 +239,7 @@ config SYS_CONFIG_NAME
default "socfpga_de0_nano_soc" if TARGET_SOCFPGA_TERASIC_DE0_NANO
default "socfpga_de1_soc" if TARGET_SOCFPGA_TERASIC_DE1_SOC
default "socfpga_de10_nano" if TARGET_SOCFPGA_TERASIC_DE10_NANO
+   default "socfpga_n5x_socdk" if TARGET_SOCFPGA_N5X_SOCDK
default "socfpga_is1" if TARGET_SOCFPGA_IS1
default "socfpga_mcvevk" if TARGET_SOCFPGA_ARIES_MCVEVK
default "socfpga_sockit" if TARGET_SOCFPGA_TERASIC_SOCKIT
diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index 58afde950f..ec38b64dd4 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -4,7 +4,7 @@
 # Wolfgang Denk, DENX Software Engineering, w...@denx.de.
 #
 # Copyright (C) 2012-2017 Altera Corporation 
-# Copyright (C) 2017-2020 Intel Corporation 
+# Copyright (C) 2017-2021 Intel Corporation 
 
 obj-y  += board.o
 obj-y  += clock_manager.o
@@ -56,6 +56,21 @@ obj-y+= wrap_handoff_soc64.o
 obj-y  += wrap_pll_config_soc64.o
 endif
 
+ifdef CONFIG_TARGET_SOCFPGA_N5X
+obj-y  += clock_manager_n5x.o
+obj-y  += lowlevel_init_soc64.o
+obj-y  += mailbox_s10.o
+obj-y  += misc_soc64.o
+obj-y  += mmu-arm64_s10.o
+obj-y  += reset_manager_s10.o
+obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += secure_vab.o
+obj-y  += system_manager_soc64.o
+obj-y  += timer_s10.o
+obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += vab.o
+obj-y  += wrap_handoff_soc64.o
+obj-y  += wrap_pll_config_soc64.o
+endif
+
 ifdef CONFIG_SPL_BUILD
 ifdef CONFIG_TARGET_SOCFPGA_GEN5
 obj-y  += spl_gen5.o
@@ -64,18 +79,21 @@ obj-y   += wrap_iocsr_config.o
 obj-y  += wrap_pinmux_config.o
 obj-y  += wrap_sdram_config.o
 endif
+ifdef CONFIG_TARGET_SOCFPGA_SOC64
+obj-y  += firewall.o
+obj-y  += spl_soc64.o
+endif
 ifdef CONFIG_TARGET_SOCFPGA_ARRIA10
 obj-y  += spl_a10.o
 endif
 ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
-obj-y  += firewall.o
 obj-y  += spl_s10.o
-obj-y  += spl_soc64.o
 endif
 ifdef CONFIG_TARGET_SOCFPGA_AGILEX
-obj-y  += firewall.o
 obj-y  += spl_agilex.o
-obj-y  += spl_soc64.o
+endif
+ifdef CONFIG_TARGET_SOCFPGA_N5X
+obj-y  += spl_n5x.o
 endif
 else
 obj-$(CONFIG_SPL_ATF) += secure_reg_helper.o
diff --git a/configs/socfpga_agilex_vab_defconfig 
b/configs/socfpga_n5x_atf_defconfig
similarity index 87%
copy from configs/socfpga_agilex_vab_defconfig
copy to co

Re: [PATCH 1/1] efi_loader: implement non-blocking file services

2021-04-30 Thread Michal Simek
Hi Heinrich,

pá 1. 1. 2021 v 19:29 odesílatel Heinrich Schuchardt
 napsal:
>
> Implement services OpenEx(), ReadEx(), WriteEx(), FlushEx() of the
> EFI_FILE_PROTOCOL.
>
> Signed-off-by: Heinrich Schuchardt 
> ---
>  include/efi_api.h |  28 ++--
>  lib/efi_loader/efi_file.c | 317 --
>  2 files changed, 280 insertions(+), 65 deletions(-)
>
> diff --git a/include/efi_api.h b/include/efi_api.h
> index ecb43a0607..2b54ee02a2 100644
> --- a/include/efi_api.h
> +++ b/include/efi_api.h
> @@ -1589,35 +1589,35 @@ struct efi_file_io_token {
>
>  struct efi_file_handle {
> u64 rev;
> -   efi_status_t (EFIAPI *open)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *open)(struct efi_file_handle *this,
> struct efi_file_handle **new_handle,
> u16 *file_name, u64 open_mode, u64 attributes);
> -   efi_status_t (EFIAPI *close)(struct efi_file_handle *file);
> -   efi_status_t (EFIAPI *delete)(struct efi_file_handle *file);
> -   efi_status_t (EFIAPI *read)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *close)(struct efi_file_handle *this);
> +   efi_status_t (EFIAPI *delete)(struct efi_file_handle *this);
> +   efi_status_t (EFIAPI *read)(struct efi_file_handle *this,
> efi_uintn_t *buffer_size, void *buffer);
> -   efi_status_t (EFIAPI *write)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *write)(struct efi_file_handle *this,
> efi_uintn_t *buffer_size, void *buffer);
> -   efi_status_t (EFIAPI *getpos)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *getpos)(struct efi_file_handle *this,
>   u64 *pos);
> -   efi_status_t (EFIAPI *setpos)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *setpos)(struct efi_file_handle *this,
>   u64 pos);
> -   efi_status_t (EFIAPI *getinfo)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *getinfo)(struct efi_file_handle *this,
> const efi_guid_t *info_type, efi_uintn_t *buffer_size,
> void *buffer);
> -   efi_status_t (EFIAPI *setinfo)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *setinfo)(struct efi_file_handle *this,
> const efi_guid_t *info_type, efi_uintn_t buffer_size,
> void *buffer);
> -   efi_status_t (EFIAPI *flush)(struct efi_file_handle *file);
> -   efi_status_t (EFIAPI *open_ex)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *flush)(struct efi_file_handle *this);
> +   efi_status_t (EFIAPI *open_ex)(struct efi_file_handle *this,
> struct efi_file_handle **new_handle,
> u16 *file_name, u64 open_mode, u64 attributes,
> struct efi_file_io_token *token);
> -   efi_status_t (EFIAPI *read_ex)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *read_ex)(struct efi_file_handle *this,
> struct efi_file_io_token *token);
> -   efi_status_t (EFIAPI *write_ex)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *write_ex)(struct efi_file_handle *this,
> struct efi_file_io_token *token);
> -   efi_status_t (EFIAPI *flush_ex)(struct efi_file_handle *file,
> +   efi_status_t (EFIAPI *flush_ex)(struct efi_file_handle *this,
> struct efi_file_io_token *token);
>  };
>
> diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
> index 72b7ec1e63..8ece8e71ee 100644
> --- a/lib/efi_loader/efi_file.c
> +++ b/lib/efi_loader/efi_file.c
> @@ -246,18 +246,16 @@ error:
> return NULL;
>  }
>
> -static efi_status_t EFIAPI efi_file_open(struct efi_file_handle *file,
> -   struct efi_file_handle **new_handle,
> -   u16 *file_name, u64 open_mode, u64 attributes)
> +static efi_status_t efi_file_open_int(struct efi_file_handle *this,
> + struct efi_file_handle **new_handle,
> + u16 *file_name, u64 open_mode,
> + u64 attributes)
>  {
> -   struct file_handle *fh = to_fh(file);
> +   struct file_handle *fh = to_fh(this);
> efi_status_t ret;
>
> -   EFI_ENTRY("%p, %p, \"%ls\", %llx, %llu", file, new_handle,
> - file_name, open_mode, attributes);
> -
> /* Check parameters */
> -   if (!file || !new_handle || !file_name) {
> +   if (!this || !new_handle || !file_name) {
> ret = EFI_INVALID_PARAMETER;
> goto out;
> }
> @@ -291,6 +289,75 @@ static efi_status_t EFIAPI efi_file_open(struct 
> efi_file_handle *file,
> } else {
> ret = EFI_NOT_FOUND;
> }
> +out:
> +   return ret;
> +}
> +
> +/**
>

Re: [PATCH 1/1] efi_loader: implement non-blocking file services

2021-04-30 Thread Heinrich Schuchardt
On 30.04.21 12:09, Michal Simek wrote:
> Hi Heinrich,
>
> pá 1. 1. 2021 v 19:29 odesílatel Heinrich Schuchardt
>  napsal:
>>
>> Implement services OpenEx(), ReadEx(), WriteEx(), FlushEx() of the
>> EFI_FILE_PROTOCOL.
>>
>> Signed-off-by: Heinrich Schuchardt 
>> ---
>>  include/efi_api.h |  28 ++--
>>  lib/efi_loader/efi_file.c | 317 --
>>  2 files changed, 280 insertions(+), 65 deletions(-)
>>
>> diff --git a/include/efi_api.h b/include/efi_api.h
>> index ecb43a0607..2b54ee02a2 100644
>> --- a/include/efi_api.h
>> +++ b/include/efi_api.h
>> @@ -1589,35 +1589,35 @@ struct efi_file_io_token {
>>
>>  struct efi_file_handle {
>> u64 rev;
>> -   efi_status_t (EFIAPI *open)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *open)(struct efi_file_handle *this,
>> struct efi_file_handle **new_handle,
>> u16 *file_name, u64 open_mode, u64 attributes);
>> -   efi_status_t (EFIAPI *close)(struct efi_file_handle *file);
>> -   efi_status_t (EFIAPI *delete)(struct efi_file_handle *file);
>> -   efi_status_t (EFIAPI *read)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *close)(struct efi_file_handle *this);
>> +   efi_status_t (EFIAPI *delete)(struct efi_file_handle *this);
>> +   efi_status_t (EFIAPI *read)(struct efi_file_handle *this,
>> efi_uintn_t *buffer_size, void *buffer);
>> -   efi_status_t (EFIAPI *write)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *write)(struct efi_file_handle *this,
>> efi_uintn_t *buffer_size, void *buffer);
>> -   efi_status_t (EFIAPI *getpos)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *getpos)(struct efi_file_handle *this,
>>   u64 *pos);
>> -   efi_status_t (EFIAPI *setpos)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *setpos)(struct efi_file_handle *this,
>>   u64 pos);
>> -   efi_status_t (EFIAPI *getinfo)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *getinfo)(struct efi_file_handle *this,
>> const efi_guid_t *info_type, efi_uintn_t 
>> *buffer_size,
>> void *buffer);
>> -   efi_status_t (EFIAPI *setinfo)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *setinfo)(struct efi_file_handle *this,
>> const efi_guid_t *info_type, efi_uintn_t buffer_size,
>> void *buffer);
>> -   efi_status_t (EFIAPI *flush)(struct efi_file_handle *file);
>> -   efi_status_t (EFIAPI *open_ex)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *flush)(struct efi_file_handle *this);
>> +   efi_status_t (EFIAPI *open_ex)(struct efi_file_handle *this,
>> struct efi_file_handle **new_handle,
>> u16 *file_name, u64 open_mode, u64 attributes,
>> struct efi_file_io_token *token);
>> -   efi_status_t (EFIAPI *read_ex)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *read_ex)(struct efi_file_handle *this,
>> struct efi_file_io_token *token);
>> -   efi_status_t (EFIAPI *write_ex)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *write_ex)(struct efi_file_handle *this,
>> struct efi_file_io_token *token);
>> -   efi_status_t (EFIAPI *flush_ex)(struct efi_file_handle *file,
>> +   efi_status_t (EFIAPI *flush_ex)(struct efi_file_handle *this,
>> struct efi_file_io_token *token);
>>  };
>>
>> diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
>> index 72b7ec1e63..8ece8e71ee 100644
>> --- a/lib/efi_loader/efi_file.c
>> +++ b/lib/efi_loader/efi_file.c
>> @@ -246,18 +246,16 @@ error:
>> return NULL;
>>  }
>>
>> -static efi_status_t EFIAPI efi_file_open(struct efi_file_handle *file,
>> -   struct efi_file_handle **new_handle,
>> -   u16 *file_name, u64 open_mode, u64 attributes)
>> +static efi_status_t efi_file_open_int(struct efi_file_handle *this,
>> + struct efi_file_handle **new_handle,
>> + u16 *file_name, u64 open_mode,
>> + u64 attributes)
>>  {
>> -   struct file_handle *fh = to_fh(file);
>> +   struct file_handle *fh = to_fh(this);
>> efi_status_t ret;
>>
>> -   EFI_ENTRY("%p, %p, \"%ls\", %llx, %llu", file, new_handle,
>> - file_name, open_mode, attributes);
>> -
>> /* Check parameters */
>> -   if (!file || !new_handle || !file_name) {
>> +   if (!this || !new_handle || !file_name) {
>> ret = EFI_INVALID_PARAMETER;
>> goto out;
>> }
>> @@ -291,6 +289,75 @@ static efi_status_t EFIAPI efi_file_open(struct

[PATCH] fs/squashfs: Fix some hardlinks reading the wrong inode

2021-04-30 Thread Campbell Suter

In SquashFS, the contents of a directory is stored by
squashfs_directory_entry structures which contain the file's name, inode
and position within the filesystem.

The inode number is not stored directly; instead each directory has one
or more headers which set a base inode number, and files store the
offset from that to the file's inode number.

In mksquashfs, each inode is allocated a number in the same order as
they are written to the directory table; thus the offset from the
header's base inode number to the file's inode number is usually
positive.

Hardlinks are simply stored with two directory entries referencing the
same file. This means the second entry will thus have an inode number
much lower than the surrounding files. Since the header's base inode
number comes from the first entry that uses the header, this delta will
usually be negative.

Previously, U-Boot's squashfs_directory_entry.inode_offset field was
declared as an unsigned value. Thus when a negative value was found, it
would either resolve to an invalid inode number or to that of an
unrelated file.

A squashfs image to test this can be created like so:

   echo hi > sqfs_test_files/001-root-file
   mkdir sqfs_test_files/002-subdir
   touch sqfs_test_files/002-subdir/003-file
   lnsqfs_test_files/{001-root-file,002-subdir/004-link}
   mksquashfs sqfs_test_files/ test.sqfs -noappend

Note that squashfs sorts the files ASCIIbetacally, so we can use the
names to control the order they appear in. The ordering is important -
the first reference to the file must have a lower inode number than the
directory in which the second reference resides, and the second
reference cannot be the first file in the directory.

Listing this sample image in U-Boot results in:

=> sqfsls virtio 2 002-subdir
0   003-file
Inode not found.
0   004-link

Signed-off-by: Campbell Suter 
---

 fs/squashfs/sqfs_filesystem.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/squashfs/sqfs_filesystem.h b/fs/squashfs/sqfs_filesystem.h
index 856cd15e349..5440b6c0e05 100644
--- a/fs/squashfs/sqfs_filesystem.h
+++ b/fs/squashfs/sqfs_filesystem.h
@@ -231,7 +231,7 @@ union squashfs_inode {

 struct squashfs_directory_entry {
u16 offset;
-   u16 inode_offset;
+   s16 inode_offset;
u16 type;
u16 name_size;
char name[0];
--
2.31.1


[PATCH v3,2/2] driver: watchdog: enable wdt command by default

2021-04-30 Thread Meng . Li
From: MengLi 

In latest u-boot code, watchdog feature is implemented, so enable
wdt command by default.

Signed-off-by: Meng Li 
---
 configs/socfpga_stratix10_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/socfpga_stratix10_defconfig 
b/configs/socfpga_stratix10_defconfig
index 02d4ac0dae..0256afe511 100644
--- a/configs/socfpga_stratix10_defconfig
+++ b/configs/socfpga_stratix10_defconfig
@@ -40,6 +40,7 @@ CONFIG_CMD_CACHE=y
 CONFIG_CMD_EXT4=y
 CONFIG_CMD_FAT=y
 CONFIG_CMD_FS_GENERIC=y
+CONFIG_CMD_WDT=y
 CONFIG_MTDIDS_DEFAULT="nor0=ff705000.spi.0"
 CONFIG_ENV_IS_IN_MMC=y
 CONFIG_SYS_RELOC_GD_ENV_ADDR=y
-- 
2.17.1



[PATCH v3, 1/2] driver: watchdog: reset watchdog in designware_wdt_stop() function

2021-04-30 Thread Meng . Li
From: MengLi 

In uboot command line environment, watchdog is not able to be
stopped with below commands:
SOCFPGA_STRATIX10 # wdt dev watchdog@ffd00200
SOCFPGA_STRATIX10 # wdt stop
Refer to watchdog driver in linux kernel, it is also need to reset
watchdog after disable it so that the disable action takes effect.

Signed-off-by: Meng Li 
Reviewed-by: Stefan Roese 
Reviewed-by: Sean Anderson 

---
v3:
Add the resets to designware_wdt_priv and initialize it in probe().
v2:
Change "#if CONFIG_IS_ENABLED(DM_RESET)" into
"if (CONFIG_IS_ENABLED(DM_RESET)) {", and define the variable
into if condition sentence.
---
 drivers/watchdog/designware_wdt.c | 31 +--
 1 file changed, 21 insertions(+), 10 deletions(-)

diff --git a/drivers/watchdog/designware_wdt.c 
b/drivers/watchdog/designware_wdt.c
index 12f09a7a39..cdf6b5709b 100644
--- a/drivers/watchdog/designware_wdt.c
+++ b/drivers/watchdog/designware_wdt.c
@@ -23,6 +23,7 @@
 struct designware_wdt_priv {
void __iomem*base;
unsigned intclk_khz;
+   struct reset_ctl_bulk *resets;
 };
 
 /*
@@ -96,6 +97,18 @@ static int designware_wdt_stop(struct udevice *dev)
designware_wdt_reset(dev);
writel(0, priv->base + DW_WDT_CR);
 
+if (CONFIG_IS_ENABLED(DM_RESET)) {
+   int ret;
+
+   ret = reset_assert_bulk(priv->resets);
+   if (ret)
+   return ret;
+
+   ret = reset_deassert_bulk(priv->resets);
+   if (ret)
+   return ret;
+   }
+
return 0;
 }
 
@@ -137,17 +150,15 @@ static int designware_wdt_probe(struct udevice *dev)
priv->clk_khz = CONFIG_DW_WDT_CLOCK_KHZ;
 #endif
 
-#if CONFIG_IS_ENABLED(DM_RESET)
-   struct reset_ctl_bulk resets;
+   if (CONFIG_IS_ENABLED(DM_RESET)) {
+   ret = reset_get_bulk(dev, priv->resets);
+   if (ret)
+   return ret;
 
-   ret = reset_get_bulk(dev, &resets);
-   if (ret)
-   return ret;
-
-   ret = reset_deassert_bulk(&resets);
-   if (ret)
-   return ret;
-#endif
+   ret = reset_deassert_bulk(priv->resets);
+   if (ret)
+   return ret;
+   }
 
/* reset to disable the watchdog */
return designware_wdt_stop(dev);
-- 
2.17.1



Re: Please pull u-boot-dm

2021-04-30 Thread Tom Rini
On Thu, Apr 29, 2021 at 04:16:02PM -0700, Simon Glass wrote:

> Hi Tom,
> 
> https://source.denx.de/u-boot/custodians/u-boot-dm/-/pipelines/7344
> 
> 
> The following changes since commit 79b0f08d6af498e6fda8cd257d62e2095764410c:
> 
>   configs: Resync with savedefconfig (2021-04-27 08:28:38 -0400)
> 
> are available in the Git repository at:
> 
>   g...@source.denx.de:u-boot/custodians/u-boot-dm.git tags/dm-pull-29apr21
> 
> for you to fetch changes up to 5b700cdcff61426843405ca1df4b549237e8bbc2:
> 
>   tpm: missing event types (2021-04-29 04:10:55 -0700)
> 

Applied to u-boot/master, thanks!

-- 
Tom


signature.asc
Description: PGP signature


32-bit DMA limit for devices (and drivers)

2021-04-30 Thread Andre Przywara
Hi,

We now see the first Allwinner devices [1] having DRAM located above
4GB in address space (4GB DRAM starting at 1GB). After one fix[2]
this works somewhat fine, but the sun8i-emac network device is still
limited to 32-bit DMA addresses. With U-Boot relocating itself (plus
stack and heap) to the end of DRAM, it now runs completely beyond 4GB
on those machines, so not giving pure 32-bit addresses for buffers
anymore.
In Linux we handle this easily by just keeping the default DMA
mask at 32 bits, and letting the DMA framework deal with the nasty
details.

I was wondering how this should be handled in U-Boot? The straight
forward solution would be:
- Let the driver allocate the RX and TX buffers separately, placing them
  below 4GB in the address space (using lmb_reserve(), I guess?)
- Use those RX buffers and hand the addresses back to the upper layers.
- We already copy TX packets, so this would also be covered, in this
  situation. Other drivers might need to introduce copying.

This sounds like a common problem, so I was wondering if there is a
more generic solution to this? Maybe there are already platforms or
devices affected? Or should the whole heap and stack be moved below 4GB
(if this is easily possible)?
In our case we make the buffers part of our priv struct, so should
there be an option to let the priv_auto allocation come from below 4GB?

Grateful for any input on this!

Thanks!
Andre

[1] https://linux-sunxi.org/X96_Mate
[2] https://lists.denx.de/pipermail/u-boot/2021-April/448327.html


Re: [PATCH 1/1] efi_loader: implement non-blocking file services

2021-04-30 Thread Michal Simek
pá 30. 4. 2021 v 12:42 odesílatel Heinrich Schuchardt
 napsal:
>
> On 30.04.21 12:09, Michal Simek wrote:
> > Hi Heinrich,
> >
> > pá 1. 1. 2021 v 19:29 odesílatel Heinrich Schuchardt
> >  napsal:
> >>
> >> Implement services OpenEx(), ReadEx(), WriteEx(), FlushEx() of the
> >> EFI_FILE_PROTOCOL.
> >>
> >> Signed-off-by: Heinrich Schuchardt 
> >> ---
> >>  include/efi_api.h |  28 ++--
> >>  lib/efi_loader/efi_file.c | 317 --
> >>  2 files changed, 280 insertions(+), 65 deletions(-)
> >>
> >> diff --git a/include/efi_api.h b/include/efi_api.h
> >> index ecb43a0607..2b54ee02a2 100644
> >> --- a/include/efi_api.h
> >> +++ b/include/efi_api.h
> >> @@ -1589,35 +1589,35 @@ struct efi_file_io_token {
> >>
> >>  struct efi_file_handle {
> >> u64 rev;
> >> -   efi_status_t (EFIAPI *open)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *open)(struct efi_file_handle *this,
> >> struct efi_file_handle **new_handle,
> >> u16 *file_name, u64 open_mode, u64 attributes);
> >> -   efi_status_t (EFIAPI *close)(struct efi_file_handle *file);
> >> -   efi_status_t (EFIAPI *delete)(struct efi_file_handle *file);
> >> -   efi_status_t (EFIAPI *read)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *close)(struct efi_file_handle *this);
> >> +   efi_status_t (EFIAPI *delete)(struct efi_file_handle *this);
> >> +   efi_status_t (EFIAPI *read)(struct efi_file_handle *this,
> >> efi_uintn_t *buffer_size, void *buffer);
> >> -   efi_status_t (EFIAPI *write)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *write)(struct efi_file_handle *this,
> >> efi_uintn_t *buffer_size, void *buffer);
> >> -   efi_status_t (EFIAPI *getpos)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *getpos)(struct efi_file_handle *this,
> >>   u64 *pos);
> >> -   efi_status_t (EFIAPI *setpos)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *setpos)(struct efi_file_handle *this,
> >>   u64 pos);
> >> -   efi_status_t (EFIAPI *getinfo)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *getinfo)(struct efi_file_handle *this,
> >> const efi_guid_t *info_type, efi_uintn_t 
> >> *buffer_size,
> >> void *buffer);
> >> -   efi_status_t (EFIAPI *setinfo)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *setinfo)(struct efi_file_handle *this,
> >> const efi_guid_t *info_type, efi_uintn_t 
> >> buffer_size,
> >> void *buffer);
> >> -   efi_status_t (EFIAPI *flush)(struct efi_file_handle *file);
> >> -   efi_status_t (EFIAPI *open_ex)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *flush)(struct efi_file_handle *this);
> >> +   efi_status_t (EFIAPI *open_ex)(struct efi_file_handle *this,
> >> struct efi_file_handle **new_handle,
> >> u16 *file_name, u64 open_mode, u64 attributes,
> >> struct efi_file_io_token *token);
> >> -   efi_status_t (EFIAPI *read_ex)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *read_ex)(struct efi_file_handle *this,
> >> struct efi_file_io_token *token);
> >> -   efi_status_t (EFIAPI *write_ex)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *write_ex)(struct efi_file_handle *this,
> >> struct efi_file_io_token *token);
> >> -   efi_status_t (EFIAPI *flush_ex)(struct efi_file_handle *file,
> >> +   efi_status_t (EFIAPI *flush_ex)(struct efi_file_handle *this,
> >> struct efi_file_io_token *token);
> >>  };
> >>
> >> diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
> >> index 72b7ec1e63..8ece8e71ee 100644
> >> --- a/lib/efi_loader/efi_file.c
> >> +++ b/lib/efi_loader/efi_file.c
> >> @@ -246,18 +246,16 @@ error:
> >> return NULL;
> >>  }
> >>
> >> -static efi_status_t EFIAPI efi_file_open(struct efi_file_handle *file,
> >> -   struct efi_file_handle **new_handle,
> >> -   u16 *file_name, u64 open_mode, u64 attributes)
> >> +static efi_status_t efi_file_open_int(struct efi_file_handle *this,
> >> + struct efi_file_handle **new_handle,
> >> + u16 *file_name, u64 open_mode,
> >> + u64 attributes)
> >>  {
> >> -   struct file_handle *fh = to_fh(file);
> >> +   struct file_handle *fh = to_fh(this);
> >> efi_status_t ret;
> >>
> >> -   EFI_ENTRY("%p, %p, \"%ls\", %llx, %llu", file, new_handle,
> >> - file_name, open_mode, attributes);
> >> -
> >> /* Check parameters */
> >> -  

[PATCH] ARM: stm32: Add additional ID register check for KSZ8851 presence

2021-04-30 Thread Marek Vasut
Currently the code sets eth1addr only if /ethernet1 alias exists in DT,
the node pointed to by the alias has "micrel,ks8851-mll" compatible
string, and the KSZ8851 CCR register read indicates programmed EEPROM
is not connected.

This is not sufficient to detect cases where the DT still contains the
KSZ8851 nodes, but the chip itself is not present. Extend the detection
to handle these cases.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 board/dhelectronics/dh_stm32mp1/board.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/board/dhelectronics/dh_stm32mp1/board.c 
b/board/dhelectronics/dh_stm32mp1/board.c
index 49b12c4c042..ac1af718d4a 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -86,6 +86,8 @@ DECLARE_GLOBAL_DATA_PTR;
 #define KS_CCR_EEPROM  BIT(9)
 #define KS_BE0 BIT(12)
 #define KS_BE1 BIT(13)
+#define KS_CIDER   0xC0
+#define CIDER_ID   0x8870
 
 int setup_mac_address(void)
 {
@@ -123,11 +125,18 @@ int setup_mac_address(void)
 * is present. If EEPROM is present, it must contain valid
 * MAC address.
 */
-   u32 reg, ccr;
+   u32 reg, cider, ccr;
reg = fdt_get_base_address(gd->fdt_blob, off);
if (!reg)
goto out_set_ethaddr;
 
+   writew(KS_BE0 | KS_BE1 | KS_CIDER, reg + 2);
+   cider = readw(reg);
+   if ((cider & 0xfff0) != CIDER_ID) {
+   skip_eth1 = true;
+   goto out_set_ethaddr;
+   }
+
writew(KS_BE0 | KS_BE1 | KS_CCR, reg + 2);
ccr = readw(reg);
if (ccr & KS_CCR_EEPROM) {
-- 
2.30.2



Re: [PATCH V2] efi_loader: loosen buffer parameter check in efi_file_read_int

2021-04-30 Thread Michal Simek
st 28. 4. 2021 v 15:22 odesílatel Peng Fan (OSS)  napsal:
>
> From: Peng Fan 
>
> This is same issue as https://bugzilla.redhat.com/show_bug.cgi?id=1733817,
> but that fix was wrongly partial reverted.
>
> When reading a directory, EFI_BUFFER_TOO_SMALL should be returned when
> the supplied buffer is too small, so a use-case is to call
> EFI_FILE_PROTOCOL.Read() with *buffer_size=0 and buffer=NULL to
> obtain the needed size before doing the actual read.
>
> So remove the check only for directory reading, file reading already
> do the check by itself.
>
> Fixes: db12f518edb0("efi_loader: implement non-blocking file services")
> Cc: Heinrich Schuchardt 
> Cc: Stefan Sørensen 
> Tested-by: Peter Robinson 
> Signed-off-by: Peng Fan 
> ---
>
> V2:
>  Update commit log Per Heinrich's comments.
>  Add T-b tag
>
>  lib/efi_loader/efi_file.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/efi_loader/efi_file.c b/lib/efi_loader/efi_file.c
> index 204105e25a..6b3f5962be 100644
> --- a/lib/efi_loader/efi_file.c
> +++ b/lib/efi_loader/efi_file.c
> @@ -554,7 +554,7 @@ static efi_status_t efi_file_read_int(struct 
> efi_file_handle *this,
> efi_status_t ret = EFI_SUCCESS;
> u64 bs;
>
> -   if (!this || !buffer_size || !buffer)
> +   if (!this || !buffer_size)
> return EFI_INVALID_PARAMETER;
>
> bs = *buffer_size;
> --
> 2.30.0
>

Tested-by: Michal Simek 

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


[PATCH] ARM: stm32: Enable UNZIP on DHSOM by default

2021-04-30 Thread Marek Vasut
The CMD_UNZIP provides the 'gzwrite' command, which is convenient
for writing e.g. gz-compressed images to eMMC from U-Boot.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 configs/stm32mp15_dhcom_basic_defconfig | 1 +
 configs/stm32mp15_dhcor_basic_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
b/configs/stm32mp15_dhcom_basic_defconfig
index e36d34d001e..df702547081 100644
--- a/configs/stm32mp15_dhcom_basic_defconfig
+++ b/configs/stm32mp15_dhcom_basic_defconfig
@@ -36,6 +36,7 @@ CONFIG_SYS_PROMPT="STM32MP> "
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_UNZIP=y
 CONFIG_CMD_ADC=y
 CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
b/configs/stm32mp15_dhcor_basic_defconfig
index 4794b1a14d5..4508d4158af 100644
--- a/configs/stm32mp15_dhcor_basic_defconfig
+++ b/configs/stm32mp15_dhcor_basic_defconfig
@@ -34,6 +34,7 @@ CONFIG_SYS_PROMPT="STM32MP> "
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_UNZIP=y
 CONFIG_CMD_ADC=y
 CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
-- 
2.30.2



Re: [PATCH] arm: bootm: wrong lmb region reservation when PRAM is used

2021-04-30 Thread Tom Rini
On Fri, Feb 19, 2021 at 09:46:49PM +, Aleksandar Gerasimovski wrote:

> This is a draft patch to describe the problem and to initiate
> a discussion for solution.
> 
> PRAM usage is not taken into account when reserving lmb for ARM
> architecture, this means that predefined PRAM region is reserved
> by the u-boot and cannot be used by the u-boot users.
> 
> In our case this bug leads to non functional ramfs boot, as the PRAM and
> ram rootfs address ranges are getting reserved by the u-boot.
> 
> It is obvious that here PRAM region is ignored, but my question is is this
> clear to everyone and expected?
> 
> Taking  board_f.c as reference, when calculating relocation address PRAM
> area is taken into account so I would expect that to be case here.
> Here the intention is to reserve unused space at the end of the effective
> RAM but PRAM is not part of that.
> 
> Possible solution would be to introduce something like
> get_effective_memsize here e.g powerpc/lib/bootm.c but then also
> NR_DRAM_BANKS has to be considered?
> 
> Signed-off-by: Aleksandar Gerasimovski 
> 
> ---
>  arch/arm/lib/bootm.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
> index 11af9e2..4b06d25 100644
> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -54,7 +54,7 @@ static ulong get_sp(void)
>  
>  void arch_lmb_reserve(struct lmb *lmb)
>  {
> - ulong sp, bank_end;
> + ulong sp, bank_end, pram = 0;
>   int bank;
>  
>   /*
> @@ -69,6 +69,11 @@ void arch_lmb_reserve(struct lmb *lmb)
>   sp = get_sp();
>   debug("## Current stack ends at 0x%08lx ", sp);
>  
> +#ifdef CONFIG_PRAM
> + pram = env_get_ulong("pram", 10, CONFIG_PRAM);
> + pram = pram << 10;  /* size is in kB */
> +#endif
> +
>   /* adjust sp by 4K to be safe */
>   sp -= 4096;
>   for (bank = 0; bank < CONFIG_NR_DRAM_BANKS; bank++) {
> @@ -76,8 +81,9 @@ void arch_lmb_reserve(struct lmb *lmb)
>   sp < gd->bd->bi_dram[bank].start)
>   continue;
>   /* Watch out for RAM at end of address space! */
> + /* @todo: pram obviously wrong if NR_DRAM_BANKS > 1 */
>   bank_end = gd->bd->bi_dram[bank].start +
> - gd->bd->bi_dram[bank].size - 1;
> +gd->bd->bi_dram[bank].size - pram - 1;
>   if (sp > bank_end)
>   continue;
>   if (bank_end > gd->ram_top)

Adding a few folks who have touched lmb code relatively recently for
their thoughts.  Thanks!

-- 
Tom


signature.asc
Description: PGP signature


Re: 32-bit DMA limit for devices (and drivers)

2021-04-30 Thread Mark Kettenis
> Date: Fri, 30 Apr 2021 12:21:21 +0100
> From: Andre Przywara 
> 
> Hi,
> 
> We now see the first Allwinner devices [1] having DRAM located above
> 4GB in address space (4GB DRAM starting at 1GB). After one fix[2]
> this works somewhat fine, but the sun8i-emac network device is still
> limited to 32-bit DMA addresses. With U-Boot relocating itself (plus
> stack and heap) to the end of DRAM, it now runs completely beyond 4GB
> on those machines, so not giving pure 32-bit addresses for buffers
> anymore.
> In Linux we handle this easily by just keeping the default DMA
> mask at 32 bits, and letting the DMA framework deal with the nasty
> details.
> 
> I was wondering how this should be handled in U-Boot? The straight
> forward solution would be:
> - Let the driver allocate the RX and TX buffers separately, placing them
>   below 4GB in the address space (using lmb_reserve(), I guess?)
> - Use those RX buffers and hand the addresses back to the upper layers.
> - We already copy TX packets, so this would also be covered, in this
>   situation. Other drivers might need to introduce copying.

What you describe here is called a bounce buffer approach.  I believe
Linux developers also refer to this as swiotlb.

> This sounds like a common problem, so I was wondering if there is a
> more generic solution to this? Maybe there are already platforms or
> devices affected? Or should the whole heap and stack be moved below 4GB
> (if this is easily possible)?
> In our case we make the buffers part of our priv struct, so should
> there be an option to let the priv_auto allocation come from below 4GB?
> 
> Grateful for any input on this!

I looked into this a bit when I was trying to figure out what to do on
Apple M1 systems where I have a somewhat related issue.  These systems
have an IOMMU that can't be bypassed.  Since I don't want to add IOMMU
infrastructure to U-Boot, I set up the IOMMU to map a fixed block of
physical memory and make sure that all allocations of memory come from
that block of memory.  In this case this is fairly easy to achieve.
U-Boot allocates memory from the top of usable memory, so as long as I
let the IOMMU map that high memory, things work.  U-Boot doesn't need
a lot of memory, so a block of 512MB is more than sufficient.

In your case this means that as long as you set the top of usable
memory to an address < 4G, U-Boot itself should be fine and no bounce
buffers are needed.  You have to make sure the addresses in the U-Boot
environment for loading things like the kernel and the FDT are set to
an address < 4G as well.

For EFI things are different though.  You want to expose all physical
memory in the EFI memory map.  This means that an EFI application
(such as an OS loader) may pick memory > 4G and use it to do I/O.  For
this purpose U-Boot already implements bounce buffers.  See the
CONFIG_EFI_LOADER_BOUNCE_BUFFER option.

Hope that helps!


Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for information passing between boot stages

2021-04-30 Thread Manish Pandey2
Hi All,

Please find invite for next TF-A Tech Forum session to continue our discussions 
on HOB implementation, feel free to forward it to others.



The next TF-A Tech Forum is scheduled for Thu 6th May 2021 16:00 – 17:00 (BST).



Agenda:

  *   Discussion Session: Static and Dynamic Information Handling in TF-A
 *   Lead by Manish Pandey and Madhukar Pappireddy

· There is ongoing mailing lists discussion[1] related with adopting a 
mechanism to pass information through boot stages.

The requirement is two-fold:

1.  Passing static information(config files)

2.  Passing dynamic information (Hob list)

In the upcoming TF-A tech forum, we can start with a discussion on dynamic 
information passing and if time permits, we can cover static information 
passing. The purpose of the call is to have an open discussion and continue the 
discussion from the trusted-substrate call[2] done earlier. We would like to 
understand the various requirements and possible ways to implement it in TF-A 
in a generalized way so that it can work with other Firmware projects.



The two specific item which we would like to discuss are:

  1.  HOB format: TF-A/u-boot both has an existing bloblist implementation, 
which uses tag values. Question, can this be enhanced to use hybrid values(Tag 
and UUID) both?
  2.  Standardization on Physical register use to pass base of HoB data 
structure.

References:

[1] https://lists.trustedfirmware.org/pipermail/tf-a/2021-April/001069.html

[2] 
https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQnHTqzgA5Wav0qOO8n7SAM0yj-Hg.mLyFkVJNB1vDKqw_
 Passcode: IPn+5q%



Thanks



Joanna



You have been invited to the following event.
TF-A Tech Forum

When

Every 2 weeks from 16:00 to 17:00 on Thursday United Kingdom Time

Calendar

t...@lists.trustedfirmware.org

Who

•

Bill Fletcher- creator

•

t...@lists.trustedfirmware.org

more details 
»



We run an open technical forum call for anyone to participate and it is not 
restricted to Trusted Firmware project members. It will operate under the 
guidance of the TF TSC.



Feel free to forward this invite to colleagues. Invites are via the TF-A 
mailing list and also published on the Trusted Firmware website. Details are 
here: 
https://www.trustedfirmware.org/meetings/tf-a-technical-forum/



Trusted Firmware is inviting you to a scheduled Zoom meeting.



Join Zoom Meeting

https://zoom.us/j/9159704974



Meeting ID: 915 970 4974



One tap mobile

+16465588656,,9159704974# US (New York)

+16699009128,,9159704974# US (San Jose)



Dial by your location

+1 646 558 8656 US (New York)

+1 669 900 9128 US (San Jose)

877 853 5247 US Toll-free

888 788 0099 US Toll-free

Meeting ID: 915 970 4974

Find your local number: 
https://zoom.us/u/ad27hc6t7h


From: François Ozog 
Sent: 08 April 2021 16:50
To: Manish Pandey2 
Cc: Simon Glass ; Julius Werner ; Harb 
Abdulhamid OS ; Boot Architecture Mailman 
List ; t...@lists.trustedfirmware.org 
; U-Boot Mailing List ; 
Paul Isaac's ; Ron Minnich 
Subject: Re: [TF-A] Proposal: TF-A to adopt hand-off blocks (HOBs) for 
information passing between boot stages

Hi

here is the meeting recording:
https://linaro-org.zoom.us/rec/share/zjfHeMIumkJhirLCVQYTHR6ftaqyWvF_0klgQnHTqzgA5Wav0qOO8n7SAM0yj-Hg.mLyFkVJNB1vDKqw_
 Passcode: IPn+5q%z

I am really sorry about the confusion related to the meeting time. I have now 
understood: the Collaborate portal uses a specific calendar which is tied to 
US/Chicago timezone while the actual Google Calendar is tied to Central Europe 
timezone. I am going to drop the Collaborate portal and use a shared Google 
calendar (it should be visible on the 
trusted-substrate.org page).

I'll try to summarize what I learnt and highlight my view on what can be next 
steps in a future mail.

Cheers

FF

On Thu, 8 Apr 2021 at 13:56, Manish Pandey2 via TF-A 
mailto:t...@lists.trustedfirmware.org>> wrote:
Hi,

From TF-A project point of view, we prefer to use existing mechanism to pass 
parameters across boot stages using linked list of tagged elements (as 
suggested by Julius). It has support for both generic and SiP-specific tags. 
Having s

[PATCH v2 1/2] of: addr: Translate 'dma-ranges' for parent nodes missing 'dma-ranges'

2021-04-30 Thread Bin Meng
'dma-ranges' frequently exists without parent nodes having 'dma-ranges'.
While this is an error for 'ranges', this is fine because DMA capable
devices always have a translatable DMA address. Also, with no
'dma-ranges' at all, the assumption is that DMA addresses are 1:1 with
no restrictions unless perhaps the device itself has implicit
restrictions.

This keeps in sync with Linux kernel commit:

  81db12ee15cb: of/address: Translate 'dma-ranges' for parent nodes missing 
'dma-ranges'

Signed-off-by: Bin Meng 
Reviewed-by: Simon Glass 

---

Changes in v2:
- rebase on top of Dario's revert patch:
  
http://patchwork.ozlabs.org/project/uboot/patch/20210425141746.19115-6-dario...@libero.it/
- drop commit "of: addr: Abort address translation for parent nodes missing 
'ranges'",
  as the revert patch restores the abort behavior

 drivers/core/of_addr.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
index 9b77308182..a3af48fd88 100644
--- a/drivers/core/of_addr.c
+++ b/drivers/core/of_addr.c
@@ -192,9 +192,13 @@ static int of_translate_one(const struct device_node 
*parent,
 *
 * As far as we know, this damage only exists on Apple machines, so
 * This code is only enabled on powerpc. --gcl
+*
+* This quirk also applies for 'dma-ranges' which frequently exist in
+* child nodes without 'dma-ranges' in the parent nodes. --RobH
 */
ranges = of_get_property(parent, rprop, &rlen);
-   if (ranges == NULL && !of_empty_ranges_quirk(parent)) {
+   if (ranges == NULL && !of_empty_ranges_quirk(parent) &&
+   strcmp(rprop, "dma-ranges")) {
debug("no ranges; cannot translate\n");
return 1;
}
-- 
2.25.1



[PATCH v2 2/2] of: addr: Remove call to dev_count_cells() in of_get_address()

2021-04-30 Thread Bin Meng
In of_get_address(), there is:

  dev_count_cells(dev, &na, &ns);

followed by:

  bus->count_cells(dev, &na, &ns);

but no codes in between use na/ns, hence the first call is useless.
By dropping the first call, dev_count_cells() is now useless too.

Signed-off-by: Bin Meng 

---

Changes in v2:
- new patch: of: addr: Remove call to dev_count_cells() in of_get_address()

 drivers/core/of_addr.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/core/of_addr.c b/drivers/core/of_addr.c
index a3af48fd88..3fbc0a7afa 100644
--- a/drivers/core/of_addr.c
+++ b/drivers/core/of_addr.c
@@ -118,11 +118,6 @@ static struct of_bus *of_match_bus(struct device_node *np)
return NULL;
 }
 
-static void dev_count_cells(const struct device_node *np, int *nap, int *nsp)
-{
-   of_bus_default_count_cells(np, nap, nsp);
-}
-
 const __be32 *of_get_address(const struct device_node *dev, int index,
 u64 *size, unsigned int *flags)
 {
@@ -136,7 +131,6 @@ const __be32 *of_get_address(const struct device_node *dev, 
int index,
parent = of_get_parent(dev);
if (parent == NULL)
return NULL;
-   dev_count_cells(dev, &na, &ns);
bus = of_match_bus(parent);
bus->count_cells(dev, &na, &ns);
of_node_put(parent);
-- 
2.25.1



[PATCH v1 0/3] spi: Sync Kirkwood SPI driver with Marvell version

2021-04-30 Thread Stefan Roese


This patchset adds some Kirkwood SPI driver patches from the Marvell
SDK. This is needed to resolve some issues with correct SPI NOR
operation on the CN9132 DB board.

Thanks,
Stefan


Grzegorz Jaszczyk (1):
  spi: kirkwood: prevent limiting speed to 0

Ken Ma (1):
  spi: kirkwood: support extended baud rates

Marcin Wojtas (1):
  spi: kirkwood: prevent configuring speed exceeding max controller freq

 drivers/spi/kirkwood_spi.c | 67 +++---
 1 file changed, 62 insertions(+), 5 deletions(-)

-- 
2.31.1



[PATCH v1 1/3] spi: kirkwood: support extended baud rates

2021-04-30 Thread Stefan Roese
From: Ken Ma 

The Armada SoC family implementation of this SPI hardware module has
extended the configuration register to allow for a wider range of SPI
clock rates. Specifically the Serial Baud Rate Pre-selection bits in the
SPI Interface Configuration Register now also use bits 6 and 7 as well.

Modify the baud rate calculation to handle these differences for the
Armada case. Potentially a baud rate can be setup using a number of
different pre-scalar and scalar combinations. This code tries all
possible pre-scalar divisors (8 in total) to try and find the most
accurate set.

Signed-off-by: Ken Ma 
Signed-off-by: Stefan Roese 
---

 drivers/spi/kirkwood_spi.c | 60 ++
 1 file changed, 55 insertions(+), 5 deletions(-)

diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index 43812da0ebb7..3dc62f351a06 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -111,12 +111,62 @@ static int mvebu_spi_set_speed(struct udevice *bus, uint 
hz)
 {
struct mvebu_spi_plat *plat = dev_get_plat(bus);
struct kwspi_registers *reg = plat->spireg;
-   u32 data;
+   u32 data, divider;
+   unsigned int spr, sppr;
+
+   /*
+* Calculate spi clock prescaller using max_hz.
+* SPPR is SPI Baud Rate Pre-selection, it holds bits 5 and 7:6 in
+* SPI Interface Configuration Register;
+* SPR is SPI Baud Rate Selection, it holds bits 3:0 in SPI Interface
+* Configuration Register.
+* The SPR together with the SPPR define the SPI CLK frequency as
+* follows:
+* SPI actual frequency = core_clk / (SPR * (2 ^ SPPR))
+*/
+   divider = DIV_ROUND_UP(CONFIG_SYS_TCLK, hz);
+   if (divider < 16) {
+   /* This is the easy case, divider is less than 16 */
+   spr = divider;
+   sppr = 0;
+
+   } else {
+   unsigned int two_pow_sppr;
+   /*
+* Find the highest bit set in divider. This and the
+* three next bits define SPR (apart from rounding).
+* SPPR is then the number of zero bits that must be
+* appended:
+*/
+   sppr = fls(divider) - 4;
+
+   /*
+* As SPR only has 4 bits, we have to round divider up
+* to the next multiple of 2 ** sppr.
+*/
+   two_pow_sppr = 1 << sppr;
+   divider = (divider + two_pow_sppr - 1) & -two_pow_sppr;
+
+   /*
+* recalculate sppr as rounding up divider might have
+* increased it enough to change the position of the
+* highest set bit. In this case the bit that now
+* doesn't make it into SPR is 0, so there is no need to
+* round again.
+*/
+   sppr = fls(divider) - 4;
+   spr = divider >> sppr;
+
+   /*
+* Now do range checking. SPR is constructed to have a
+* width of 4 bits, so this is fine for sure. So we
+* still need to check for sppr to fit into 3 bits:
+*/
+   if (sppr > 7)
+   return -EINVAL;
+   }
 
-   /* calculate spi clock prescaller using max_hz */
-   data = ((CONFIG_SYS_TCLK / 2) / hz) + 0x10;
-   data = data < KWSPI_CLKPRESCL_MIN ? KWSPI_CLKPRESCL_MIN : data;
-   data = data > KWSPI_CLKPRESCL_MASK ? KWSPI_CLKPRESCL_MASK : data;
+   data = ((sppr & 0x6) << 5) | ((sppr & 0x1) << 4) | spr;
 
/* program spi clock prescaler using max_hz */
writel(KWSPI_ADRLEN_3BYTE | data, ®->cfg);
-- 
2.31.1



[PATCH v1 3/3] spi: kirkwood: prevent limiting speed to 0

2021-04-30 Thread Stefan Roese
From: Grzegorz Jaszczyk 

After commit 1fe929ed497bcc8975be8d37383ebafd22b99dd2
("spi: kirkwood: prevent configuring speed exceeding max controller freq")
the spi frequency could be set to 0 on platform where spi-max-frequency
is not defined (e.g. on armada-388-gp). Prevent limiting speed in
mentioned cases.

Signed-off-by: Grzegorz Jaszczyk 
Tested-by: Kostya Porotchkin 
Reviewed-by: Marcin Wojtas 
Reviewed-by: Kostya Porotchkin 
Signed-off-by: Stefan Roese 
---

 drivers/spi/kirkwood_spi.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index 063ed5f35a3a..bc5da0a1e6e9 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -115,7 +115,7 @@ static int mvebu_spi_set_speed(struct udevice *bus, uint hz)
u32 data, divider;
unsigned int spr, sppr;
 
-   if (hz > spi->max_hz) {
+   if (spi->max_hz && (hz > spi->max_hz)) {
debug("%s: limit speed to the max_hz of the bus %d\n",
  __func__, spi->max_hz);
hz = spi->max_hz;
-- 
2.31.1



[PATCH v1 2/3] spi: kirkwood: prevent configuring speed exceeding max controller freq

2021-04-30 Thread Stefan Roese
From: Marcin Wojtas 

This patch adds a limitation in the kirkwood_spi driver
set_speed hook, which prevents setting too high transfer
speed.

Signed-off-by: Marcin Wojtas 
Reviewed-by: Kostya Porotchkin 
Tested-by: Kostya Porotchkin 
Signed-off-by: Stefan Roese 
---

 drivers/spi/kirkwood_spi.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/spi/kirkwood_spi.c b/drivers/spi/kirkwood_spi.c
index 3dc62f351a06..063ed5f35a3a 100644
--- a/drivers/spi/kirkwood_spi.c
+++ b/drivers/spi/kirkwood_spi.c
@@ -110,10 +110,17 @@ static int _spi_xfer(struct kwspi_registers *reg, 
unsigned int bitlen,
 static int mvebu_spi_set_speed(struct udevice *bus, uint hz)
 {
struct mvebu_spi_plat *plat = dev_get_plat(bus);
+   struct dm_spi_bus *spi = dev_get_uclass_priv(bus);
struct kwspi_registers *reg = plat->spireg;
u32 data, divider;
unsigned int spr, sppr;
 
+   if (hz > spi->max_hz) {
+   debug("%s: limit speed to the max_hz of the bus %d\n",
+ __func__, spi->max_hz);
+   hz = spi->max_hz;
+   }
+
/*
 * Calculate spi clock prescaller using max_hz.
 * SPPR is SPI Baud Rate Pre-selection, it holds bits 5 and 7:6 in
-- 
2.31.1



[PATCH v1 0/4] arm64: mvebu: Sync Marvell armada8k MMU setup with Marvell version

2021-04-30 Thread Stefan Roese


This patchset adds some Armada8k MMU setup related patches from the
Marvell SDK. This is needed to resolve some PCI related issues that I
exprienced while porting mainline U-Boot to the CN9132 DB board.

Thanks,
Stefan


Grzegorz Jaszczyk (3):
  arm64: mvebu: do not map firmware RT service region
  arm64: mvebu: a8k: move firmware related definitions to fw info
  arm64: mvebu: extend the mmio region

jinghua (1):
  arm64: mvebu: a8k: align memory regions

 arch/arm/mach-mvebu/armada8k/cpu.c | 70 +-
 arch/arm/mach-mvebu/include/mach/fw_info.h | 18 ++
 2 files changed, 34 insertions(+), 54 deletions(-)
 create mode 100644 arch/arm/mach-mvebu/include/mach/fw_info.h

-- 
2.31.1



[PATCH v1 1/4] arm64: mvebu: a8k: align memory regions

2021-04-30 Thread Stefan Roese
From: jinghua 

1. RAM: base address 0x0 size 2Gbytes
2. MMIO: base address 0xf000 size 1Gbytes

Signed-off-by: Ofir Fedida 
Signed-off-by: Stefan Roese 
---

 arch/arm/mach-mvebu/armada8k/cpu.c | 62 --
 1 file changed, 7 insertions(+), 55 deletions(-)

diff --git a/arch/arm/mach-mvebu/armada8k/cpu.c 
b/arch/arm/mach-mvebu/armada8k/cpu.c
index 474327a8e1c9..99531711ee34 100644
--- a/arch/arm/mach-mvebu/armada8k/cpu.c
+++ b/arch/arm/mach-mvebu/armada8k/cpu.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -23,62 +24,22 @@
 #define BOOT_MODE_MASK 0x3f
 #define BOOT_MODE_OFFSET   4
 
-/*
- * The following table includes all memory regions for Armada 7k and
- * 8k SoCs. The Armada 7k is missing the CP110 slave regions here. Lets
- * define these regions at the beginning of the struct so that they
- * can be easier removed later dynamically if an Armada 7k device is detected.
- * For a detailed memory map, please see doc/mvebu/armada-8k-memory.txt
- */
-#define ARMADA_7K8K_COMMON_REGIONS_START   2
 static struct mm_region mvebu_mem_map[] = {
/* Armada 80x0 memory regions include the CP1 (slave) units */
-   {
-   /* SRAM, MMIO regions - CP110 slave region */
-   .phys = 0xf400UL,
-   .virt = 0xf400UL,
-   .size = 0x0200UL,   /* 32MiB internal registers */
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE
-   },
-   {
-   /* PCI CP1 regions */
-   .phys = 0xfa00UL,
-   .virt = 0xfa00UL,
-   .size = 0x0400UL,   /* 64MiB CP110 slave PCI space */
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE
-   },
-   /* Armada 80x0 and 70x0 common memory regions start here */
{
/* RAM */
.phys = 0x0UL,
.virt = 0x0UL,
-   .size = 0x8000UL,
+   .size = SZ_2G,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
},
{
-   /* SRAM, MMIO regions - AP806 region */
-   .phys = 0xf000UL,
-   .virt = 0xf000UL,
-   .size = 0x0100UL,   /* 16MiB internal registers */
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE
-   },
-   {
-   /* SRAM, MMIO regions - CP110 master region */
-   .phys = 0xf200UL,
-   .virt = 0xf200UL,
-   .size = 0x0200UL,   /* 32MiB internal registers */
-   .attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
-PTE_BLOCK_NON_SHARE
-   },
-   {
-   /* PCI CP0 regions */
-   .phys = 0xf600UL,
-   .virt = 0xf600UL,
-   .size = 0x0400UL,   /* 64MiB CP110 master PCI space */
+   /* MMIO regions */
+   .phys = SOC_REGS_PHY_BASE,
+   .virt = SOC_REGS_PHY_BASE,
+   .size = SZ_1G,
+
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
 PTE_BLOCK_NON_SHARE
},
@@ -91,15 +52,6 @@ struct mm_region *mem_map = mvebu_mem_map;
 
 void enable_caches(void)
 {
-   /*
-* Armada 7k is not equipped with the CP110 slave CP. In case this
-* code runs on an Armada 7k device, lets remove the CP110 slave
-* entries from the memory mapping by moving the start to the
-* common regions.
-*/
-   if (of_machine_is_compatible("marvell,armada7040"))
-   mem_map = &mvebu_mem_map[ARMADA_7K8K_COMMON_REGIONS_START];
-
icache_enable();
dcache_enable();
 }
-- 
2.31.1



[PATCH v1 2/4] arm64: mvebu: do not map firmware RT service region

2021-04-30 Thread Stefan Roese
From: Grzegorz Jaszczyk 

There is region left by ATF, which needs to remain in memory to provide RT
services. To prevent overwriting it by u-boot, do not provide any mapping
for this memory region, so any attempt to access it will trigger
synchronous exception.

Update sr 2021-04-12:
Don't update armada3700/cpu.c mmu table, as this has specific changes
included in mainline.

Signed-off-by: Grzegorz Jaszczyk 
Signed-off-by: Stefan Roese 
---

 arch/arm/mach-mvebu/armada8k/cpu.c | 12 +++-
 arch/arm/mach-mvebu/include/mach/fw_info.h | 13 +
 2 files changed, 24 insertions(+), 1 deletion(-)
 create mode 100644 arch/arm/mach-mvebu/include/mach/fw_info.h

diff --git a/arch/arm/mach-mvebu/armada8k/cpu.c 
b/arch/arm/mach-mvebu/armada8k/cpu.c
index 99531711ee34..d76e17632556 100644
--- a/arch/arm/mach-mvebu/armada8k/cpu.c
+++ b/arch/arm/mach-mvebu/armada8k/cpu.c
@@ -14,6 +14,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /* Armada 7k/8k */
 #define MVEBU_RFU_BASE (MVEBU_REGISTER(0x6f))
@@ -27,9 +28,18 @@
 static struct mm_region mvebu_mem_map[] = {
/* Armada 80x0 memory regions include the CP1 (slave) units */
{
-   /* RAM */
+   /* RAM 0-64MB */
.phys = 0x0UL,
.virt = 0x0UL,
+   .size = ATF_REGION_START,
+   .attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
+PTE_BLOCK_INNER_SHARE
+   },
+   /* ATF and TEE region 0x400-0x540 not mapped */
+   {
+   /* RAM 66MB-2GB */
+   .phys = ATF_REGION_END,
+   .virt = ATF_REGION_END,
.size = SZ_2G,
.attrs = PTE_BLOCK_MEMTYPE(MT_NORMAL) |
 PTE_BLOCK_INNER_SHARE
diff --git a/arch/arm/mach-mvebu/include/mach/fw_info.h 
b/arch/arm/mach-mvebu/include/mach/fw_info.h
new file mode 100644
index ..ab2bb91bd5b3
--- /dev/null
+++ b/arch/arm/mach-mvebu/include/mach/fw_info.h
@@ -0,0 +1,13 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * Copyright (C) 2018 Marvell International Ltd.
+ */
+
+#ifndef _FW_INFO_H_
+#define _FW_INFO_H_
+
+/* Protected ATF and TEE region */
+#define ATF_REGION_START   0x400
+#define ATF_REGION_END 0x540
+
+#endif /* _FW_INFO_H_ */
-- 
2.31.1



[PATCH v1 4/4] arm64: mvebu: extend the mmio region

2021-04-30 Thread Stefan Roese
From: Grzegorz Jaszczyk 

Some of the setups including cn9130 opens mmio window starting from
0xc000, reflect it in the u-boot code.

Signed-off-by: Grzegorz Jaszczyk 
Signed-off-by: Kostya Porotchkin 
Signed-off-by: Stefan Roese 
---

 arch/arm/mach-mvebu/armada8k/cpu.c | 4 ++--
 arch/arm/mach-mvebu/include/mach/fw_info.h | 2 ++
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm/mach-mvebu/armada8k/cpu.c 
b/arch/arm/mach-mvebu/armada8k/cpu.c
index d76e17632556..939abce000f6 100644
--- a/arch/arm/mach-mvebu/armada8k/cpu.c
+++ b/arch/arm/mach-mvebu/armada8k/cpu.c
@@ -46,8 +46,8 @@ static struct mm_region mvebu_mem_map[] = {
},
{
/* MMIO regions */
-   .phys = SOC_REGS_PHY_BASE,
-   .virt = SOC_REGS_PHY_BASE,
+   .phys = MMIO_REGS_PHY_BASE,
+   .virt = MMIO_REGS_PHY_BASE,
.size = SZ_1G,
 
.attrs = PTE_BLOCK_MEMTYPE(MT_DEVICE_NGNRNE) |
diff --git a/arch/arm/mach-mvebu/include/mach/fw_info.h 
b/arch/arm/mach-mvebu/include/mach/fw_info.h
index 6ab972e36e93..1382438e390e 100644
--- a/arch/arm/mach-mvebu/include/mach/fw_info.h
+++ b/arch/arm/mach-mvebu/include/mach/fw_info.h
@@ -13,4 +13,6 @@
 /* Firmware related definition used for SMC calls */
 #define MV_SIP_DRAM_SIZE   0x8210
 
+#define MMIO_REGS_PHY_BASE 0xc000
+
 #endif /* _FW_INFO_H_ */
-- 
2.31.1



[PATCH v1 3/4] arm64: mvebu: a8k: move firmware related definitions to fw info

2021-04-30 Thread Stefan Roese
From: Grzegorz Jaszczyk 

Signed-off-by: Grzegorz Jaszczyk 
Signed-off-by: Stefan Roese 
---

 arch/arm/mach-mvebu/include/mach/fw_info.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm/mach-mvebu/include/mach/fw_info.h 
b/arch/arm/mach-mvebu/include/mach/fw_info.h
index ab2bb91bd5b3..6ab972e36e93 100644
--- a/arch/arm/mach-mvebu/include/mach/fw_info.h
+++ b/arch/arm/mach-mvebu/include/mach/fw_info.h
@@ -10,4 +10,7 @@
 #define ATF_REGION_START   0x400
 #define ATF_REGION_END 0x540
 
+/* Firmware related definition used for SMC calls */
+#define MV_SIP_DRAM_SIZE   0x8210
+
 #endif /* _FW_INFO_H_ */
-- 
2.31.1



[PATCH] pcie: designware: mvebu: do not configure ATU for IO when not used

2021-04-30 Thread Stefan Roese
From: Marcin Wojtas 

The pcie_dw_mvebu configure ATU regions for memory, configuration
and IO space types. However the latter is not obligatory
and when not specified in the device tree, causes wrong
ATU configuration. Fix that by adding a dependency on the
detected PCIE regions count.

Signed-off-by: Marcin Wojtas 
Reviewed-on: https://sj1git1.cavium.com/18136
Reviewed-by: Kostya Porotchkin 
Tested-by: Kostya Porotchkin 
---
 drivers/pci/pcie_dw_mvebu.c | 37 +
 1 file changed, 25 insertions(+), 12 deletions(-)

diff --git a/drivers/pci/pcie_dw_mvebu.c b/drivers/pci/pcie_dw_mvebu.c
index 93e57cf0cf14..0490fd337705 100644
--- a/drivers/pci/pcie_dw_mvebu.c
+++ b/drivers/pci/pcie_dw_mvebu.c
@@ -115,6 +115,7 @@ struct pcie_dw_mvebu {
int first_busno;
 
/* IO and MEM PCI regions */
+   int region_count;
struct pci_region io;
struct pci_region mem;
 };
@@ -267,9 +268,10 @@ static int pcie_dw_mvebu_read_config(const struct udevice 
*bus, pci_dev_t bdf,
debug("(addr,val)=(0x%04x, 0x%08lx)\n", offset, value);
*valuep = pci_conv_32_to_size(value, offset, size);
 
-   pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,
- PCIE_ATU_TYPE_IO, pcie->io.phys_start,
- pcie->io.bus_start, pcie->io.size);
+   if (pcie->region_count > 1)
+   pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,
+ PCIE_ATU_TYPE_IO, pcie->io.phys_start,
+ pcie->io.bus_start, pcie->io.size);
 
return 0;
 }
@@ -312,9 +314,10 @@ static int pcie_dw_mvebu_write_config(struct udevice *bus, 
pci_dev_t bdf,
value = pci_conv_size_to_32(old, value, offset, size);
writel(value, va_address);
 
-   pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,
- PCIE_ATU_TYPE_IO, pcie->io.phys_start,
- pcie->io.bus_start, pcie->io.size);
+   if (pcie->region_count > 1)
+   pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX0,
+ PCIE_ATU_TYPE_IO, pcie->io.phys_start,
+ pcie->io.bus_start, pcie->io.size);
 
return 0;
 }
@@ -513,14 +516,24 @@ static int pcie_dw_mvebu_probe(struct udevice *dev)
   hose->first_busno);
}
 
+   pcie->region_count = hose->region_count - CONFIG_NR_DRAM_BANKS;
+
/* Store the IO and MEM windows settings for future use by the ATU */
-   pcie->io.phys_start = hose->regions[0].phys_start; /* IO base */
-   pcie->io.bus_start  = hose->regions[0].bus_start;  /* IO_bus_addr */
-   pcie->io.size   = hose->regions[0].size;   /* IO size */
+   if (pcie->region_count > 1) {
+   /* IO base */
+   pcie->io.phys_start = hose->regions[0].phys_start;
+   /* IO_bus_addr */
+   pcie->io.bus_start  = hose->regions[0].bus_start;
+   /* IO size */
+   pcie->io.size   = hose->regions[0].size;
+   }
 
-   pcie->mem.phys_start = hose->regions[1].phys_start; /* MEM base */
-   pcie->mem.bus_start  = hose->regions[1].bus_start;  /* MEM_bus_addr */
-   pcie->mem.size   = hose->regions[1].size;   /* MEM size */
+   /* MEM base */
+   pcie->mem.phys_start = hose->regions[pcie->region_count - 1].phys_start;
+   /* MEM_bus_addr */
+   pcie->mem.bus_start  = hose->regions[pcie->region_count - 1].bus_start;
+   /* MEM size */
+   pcie->mem.size   = hose->regions[pcie->region_count - 1].size;
 
pcie_dw_prog_outbound_atu(pcie, PCIE_ATU_REGION_INDEX1,
  PCIE_ATU_TYPE_MEM, pcie->mem.phys_start,
-- 
2.31.1



Re: 32-bit DMA limit for devices (and drivers)

2021-04-30 Thread Andre Przywara
On Fri, 30 Apr 2021 14:02:52 +0200 (CEST)
Mark Kettenis  wrote:

Hi Mark,

thanks for the reply!

(CC:ing Alex and Heinrich for the UEFI questions below)

> > Date: Fri, 30 Apr 2021 12:21:21 +0100
> > From: Andre Przywara 
> > 
> > Hi,
> > 
> > We now see the first Allwinner devices [1] having DRAM located above
> > 4GB in address space (4GB DRAM starting at 1GB). After one fix[2]
> > this works somewhat fine, but the sun8i-emac network device is still
> > limited to 32-bit DMA addresses. With U-Boot relocating itself (plus
> > stack and heap) to the end of DRAM, it now runs completely beyond 4GB
> > on those machines, so not giving pure 32-bit addresses for buffers
> > anymore.
> > In Linux we handle this easily by just keeping the default DMA
> > mask at 32 bits, and letting the DMA framework deal with the nasty
> > details.
> > 
> > I was wondering how this should be handled in U-Boot? The straight
> > forward solution would be:
> > - Let the driver allocate the RX and TX buffers separately, placing them
> >   below 4GB in the address space (using lmb_reserve(), I guess?)
> > - Use those RX buffers and hand the addresses back to the upper layers.
> > - We already copy TX packets, so this would also be covered, in this
> >   situation. Other drivers might need to introduce copying.  
> 
> What you describe here is called a bounce buffer approach.  I believe
> Linux developers also refer to this as swiotlb.

Yes, but it's not entirely the same as bounce buffering in Linux,
since we allocate the buffers ourselves, in the driver, so we have full
control over it. The problem I face is that malloc() works on the heap
(which is high), or we use the automatic priv_alloc mechanism, which
uses the heap as well, IIUC.

> > This sounds like a common problem, so I was wondering if there is a
> > more generic solution to this? Maybe there are already platforms or
> > devices affected? Or should the whole heap and stack be moved below 4GB
> > (if this is easily possible)?
> > In our case we make the buffers part of our priv struct, so should
> > there be an option to let the priv_auto allocation come from below 4GB?
> > 
> > Grateful for any input on this!  
> 
> I looked into this a bit when I was trying to figure out what to do on
> Apple M1 systems where I have a somewhat related issue.  These systems
> have an IOMMU that can't be bypassed.  Since I don't want to add IOMMU
> infrastructure to U-Boot, I set up the IOMMU to map a fixed block of
> physical memory and make sure that all allocations of memory come from
> that block of memory.  In this case this is fairly easy to achieve.
> U-Boot allocates memory from the top of usable memory, so as long as I
> let the IOMMU map that high memory, things work.  U-Boot doesn't need
> a lot of memory, so a block of 512MB is more than sufficient.

I'd rather not play around with the visible memory size (see below).
And while technically there is a (scatter/gather) IOMMU in the SoC, it
would be too big guns for that small problem.

> In your case this means that as long as you set the top of usable
> memory to an address < 4G, U-Boot itself should be fine and no bounce
> buffers are needed.  You have to make sure the addresses in the U-Boot
> environment for loading things like the kernel and the FDT are set to
> an address < 4G as well.
> 
> For EFI things are different though.  You want to expose all physical
> memory in the EFI memory map.

Not only for UEFI, since U-Boot populates the DT memory node even for
booti/bootm, in arch/arm/lib/bootm-fdt.c:arch_fixup_fdt().
So limiting the memory is not an option, since this would be passed on
to the OS.

> This means that an EFI application
> (such as an OS loader) may pick memory > 4G and use it to do I/O.

I think we should be safe here, as the driver has full control over the
buffers: For TX we copy already, to use "fire-and-forget", so we
just start the DMA and return. And for RX U-Boot network drivers
return the buffer address, so it's our own buffer again. So wherever
higher layers put the packets, we should be good (given our own buffers
are).


So I guess my question boils down to: How can I best allocate buffers
from "low" memory? And do those buffers carveouts make it into the UEFI
memory map, as reserved regions? Or can UEFI differentiate between
boot services and runtime services allocations? The buffers would be
needed during boot services, for the UEFI network protocol. But later
on they can be abandoned.

> this purpose U-Boot already implements bounce buffers.  See the
> CONFIG_EFI_LOADER_BOUNCE_BUFFER option.

Interesting, thanks, I will have a look at that. Maybe that contains
some useful traces to other code.

Cheers,
Andre


Re: [PATCH v1 08/10] net: mvpp2: fix missing switch case break

2021-04-30 Thread Ramon Fried
On Fri, Apr 30, 2021 at 7:40 AM Stefan Roese  wrote:
>
> On 29.04.21 22:24, Ramon Fried wrote:
> > On Tue, Apr 27, 2021 at 4:28 PM Stefan Roese  wrote:
> >>
> >> From: Ben Peled 
> >>
> >> Signed-off-by: Ben Peled 
> >> Reviewed-by: Stefan Chulski 
> >> Reviewed-by: Kostya Porotchkin 
> >> Tested-by: sa_ip-sw-jenkins 
> > Please remove this, Jenkins is not a person.
>
> I've left these lines in because most of these patches are plain
> cherry-picked from the Marvell SDK.
>
> Should I resubmit this patch only or the complete patchset? Or could you
> perhaps remove this line while collecting the patches for a pull
> request?
Please submit the patchset again.


Re: [PATCH v3,1/2] driver: watchdog: reset watchdog in designware_wdt_stop() function

2021-04-30 Thread Sean Anderson




On 4/30/21 1:26 AM, meng...@windriver.com wrote:
> From: MengLi 
>
> In uboot command line environment, watchdog is not able to be
> stopped with below commands:
> SOCFPGA_STRATIX10 # wdt dev watchdog@ffd00200
> SOCFPGA_STRATIX10 # wdt stop
> Refer to watchdog driver in linux kernel, it is also need to reset
> watchdog after disable it so that the disable action takes effect.
>
> Signed-off-by: Meng Li 
> Reviewed-by: Stefan Roese 
> Reviewed-by: Sean Anderson 

I did not review your previous version. Please do not add a
"Reviewed-by" tag for people who did not send you one.

>
> ---
> v3:
> Add the resets to designware_wdt_priv and initialize it in probe().
> v2:
> Change "#if CONFIG_IS_ENABLED(DM_RESET)" into
> "if (CONFIG_IS_ENABLED(DM_RESET)) {", and define the variable
> into if condition sentence.
> ---
>   drivers/watchdog/designware_wdt.c | 31 +--
>   1 file changed, 21 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/watchdog/designware_wdt.c 
b/drivers/watchdog/designware_wdt.c
> index 12f09a7a39..cdf6b5709b 100644
> --- a/drivers/watchdog/designware_wdt.c
> +++ b/drivers/watchdog/designware_wdt.c
> @@ -23,6 +23,7 @@
>   struct designware_wdt_priv {
>void __iomem*base;
>unsigned intclk_khz;
> +  struct reset_ctl_bulk *resets;
>   };
>
>   /*
> @@ -96,6 +97,18 @@ static int designware_wdt_stop(struct udevice *dev)
>designware_wdt_reset(dev);
>writel(0, priv->base + DW_WDT_CR);
>
> +if (CONFIG_IS_ENABLED(DM_RESET)) {
> +  int ret;
> +
> +  ret = reset_assert_bulk(priv->resets);
> +  if (ret)
> +  return ret;
> +
> +  ret = reset_deassert_bulk(priv->resets);
> +  if (ret)
> +  return ret;
> +  }
> +
>return 0;
>   }
>
> @@ -137,17 +150,15 @@ static int designware_wdt_probe(struct udevice *dev)
>priv->clk_khz = CONFIG_DW_WDT_CLOCK_KHZ;
>   #endif
>
> -#if CONFIG_IS_ENABLED(DM_RESET)
> -  struct reset_ctl_bulk resets;
> +  if (CONFIG_IS_ENABLED(DM_RESET)) {
> +  ret = reset_get_bulk(dev, priv->resets);
> +  if (ret)
> +  return ret;
>
> -  ret = reset_get_bulk(dev, &resets);
> -  if (ret)
> -  return ret;
> -
> -  ret = reset_deassert_bulk(&resets);
> -  if (ret)
> -  return ret;
> -#endif
> +  ret = reset_deassert_bulk(priv->resets);
> +  if (ret)
> +  return ret;
> +  }
>
>/* reset to disable the watchdog */
>return designware_wdt_stop(dev);
>

However, this version LGTM.

Reviewed-by: Sean Anderson 


Re: 32-bit DMA limit for devices (and drivers)

2021-04-30 Thread Jernej Škrabec
Hi!

Dne petek, 30. april 2021 ob 15:34:28 CEST je Andre Przywara napisal(a):
> On Fri, 30 Apr 2021 14:02:52 +0200 (CEST)
> Mark Kettenis  wrote:
> 
> Hi Mark,
> 
> thanks for the reply!
> 
> (CC:ing Alex and Heinrich for the UEFI questions below)
> 
> > > Date: Fri, 30 Apr 2021 12:21:21 +0100
> > > From: Andre Przywara 
> > > 
> > > Hi,
> > > 
> > > We now see the first Allwinner devices [1] having DRAM located above
> > > 4GB in address space (4GB DRAM starting at 1GB). After one fix[2]
> > > this works somewhat fine, but the sun8i-emac network device is still
> > > limited to 32-bit DMA addresses. With U-Boot relocating itself (plus
> > > stack and heap) to the end of DRAM, it now runs completely beyond 4GB
> > > on those machines, so not giving pure 32-bit addresses for buffers
> > > anymore.
> > > In Linux we handle this easily by just keeping the default DMA
> > > mask at 32 bits, and letting the DMA framework deal with the nasty
> > > details.
> > > 
> > > I was wondering how this should be handled in U-Boot? The straight
> > > forward solution would be:
> > > - Let the driver allocate the RX and TX buffers separately, placing them
> > > 
> > >   below 4GB in the address space (using lmb_reserve(), I guess?)
> > > 
> > > - Use those RX buffers and hand the addresses back to the upper layers.
> > > - We already copy TX packets, so this would also be covered, in this
> > > 
> > >   situation. Other drivers might need to introduce copying.
> > 
> > What you describe here is called a bounce buffer approach.  I believe
> > Linux developers also refer to this as swiotlb.
> 
> Yes, but it's not entirely the same as bounce buffering in Linux,
> since we allocate the buffers ourselves, in the driver, so we have full
> control over it. The problem I face is that malloc() works on the heap
> (which is high), or we use the automatic priv_alloc mechanism, which
> uses the heap as well, IIUC.
> 
> > > This sounds like a common problem, so I was wondering if there is a
> > > more generic solution to this? Maybe there are already platforms or
> > > devices affected? Or should the whole heap and stack be moved below 4GB
> > > (if this is easily possible)?
> > > In our case we make the buffers part of our priv struct, so should
> > > there be an option to let the priv_auto allocation come from below 4GB?
> > > 
> > > Grateful for any input on this!
> > 
> > I looked into this a bit when I was trying to figure out what to do on
> > Apple M1 systems where I have a somewhat related issue.  These systems
> > have an IOMMU that can't be bypassed.  Since I don't want to add IOMMU
> > infrastructure to U-Boot, I set up the IOMMU to map a fixed block of
> > physical memory and make sure that all allocations of memory come from
> > that block of memory.  In this case this is fairly easy to achieve.
> > U-Boot allocates memory from the top of usable memory, so as long as I
> > let the IOMMU map that high memory, things work.  U-Boot doesn't need
> > a lot of memory, so a block of 512MB is more than sufficient.
> 
> I'd rather not play around with the visible memory size (see below).
> And while technically there is a (scatter/gather) IOMMU in the SoC, it
> would be too big guns for that small problem.

IOMMU is connected only to video related cores, so it's not an option here.

Best regards,
Jernej

> 
> > In your case this means that as long as you set the top of usable
> > memory to an address < 4G, U-Boot itself should be fine and no bounce
> > buffers are needed.  You have to make sure the addresses in the U-Boot
> > environment for loading things like the kernel and the FDT are set to
> > an address < 4G as well.
> > 
> > For EFI things are different though.  You want to expose all physical
> > memory in the EFI memory map.
> 
> Not only for UEFI, since U-Boot populates the DT memory node even for
> booti/bootm, in arch/arm/lib/bootm-fdt.c:arch_fixup_fdt().
> So limiting the memory is not an option, since this would be passed on
> to the OS.
> 
> > This means that an EFI application
> > (such as an OS loader) may pick memory > 4G and use it to do I/O.
> 
> I think we should be safe here, as the driver has full control over the
> buffers: For TX we copy already, to use "fire-and-forget", so we
> just start the DMA and return. And for RX U-Boot network drivers
> return the buffer address, so it's our own buffer again. So wherever
> higher layers put the packets, we should be good (given our own buffers
> are).
> 
> 
> So I guess my question boils down to: How can I best allocate buffers
> from "low" memory? And do those buffers carveouts make it into the UEFI
> memory map, as reserved regions? Or can UEFI differentiate between
> boot services and runtime services allocations? The buffers would be
> needed during boot services, for the UEFI network protocol. But later
> on they can be abandoned.
> 
> > this purpose U-Boot already implements bounce buffers.  See the
> > CONFIG_EFI_LOADER_BOUNCE_BUFFER option.
> 
> Interesting

Re: [PATCH v2 04/13] gpio: Introduce CONFIG_ONLY_GENERIC_GPIO to cleanup #ifdefs

2021-04-30 Thread Simon Glass
Hi Masami,

On Thu, 29 Apr 2021 at 20:03, Masami Hiramatsu
 wrote:
>
> Hi Simon,
>
> 2021年4月30日(金) 1:10 Simon Glass :
> >
> > Hi Masami,
> >
> > On Fri, 16 Apr 2021 at 16:38, Masami Hiramatsu
> >  wrote:
> > >
> > > Many architecture do not have specific asm/arch/gpio.h, so instead
> > > of adding !defined(CONFIG_ARCH_xxx), introduce CONFIG_ONLY_GENERIC_GPIO
> >
> > This seems OK, but I think GPIO_GENERIC_ONLY is a better name, since
> > it uses the GPIO prefix.
> >
> > I would also prefer to have a 'positive' option, but I suspect that
> > might be a pain to do?
>
> Would you mean making it something like CONFIG_GPIO_EXTRA_HEADER ?
>
> I think it is also possible. My concern is if I missed any arch which
> should say y that :P.

Yes...it's just that negative configs generally cause us pain at some point.

Regards,
Simon


Re: [PATCH 03/17] x86: Allow coreboot serial driver to guess the UART

2021-04-30 Thread Simon Glass
Hi Bin,

On Thu, 29 Apr 2021 at 17:01, Bin Meng  wrote:
>
> Hi Simon,
>
> On Fri, Apr 30, 2021 at 12:10 AM Simon Glass  wrote:
> >
> > Hi Bin,
> >
> > On Sun, 25 Apr 2021 at 18:21, Bin Meng  wrote:
> > >
> > > Hi Simon,
> > >
> > > On Sun, Apr 25, 2021 at 10:10 AM Simon Glass  wrote:
> > > >
> > > > Hi Bin,
> > > >
> > > > On Sun, 25 Apr 2021 at 13:49, Bin Meng  wrote:
> > > > >
> > > > > Hi Simon,
> > > > >
> > > > > On Sat, Apr 24, 2021 at 12:56 PM Simon Glass  
> > > > > wrote:
> > > > > >
> > > > > > Hi Bin,
> > > > > >
> > > > > > On Thu, 8 Apr 2021 at 14:23, Bin Meng  wrote:
> > > > > > >
> > > > > > > Hi Simon,
> > > > > > >
> > > > > > > On Wed, Apr 7, 2021 at 12:32 PM Simon Glass  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > At present this driver relies on coreboot to provide 
> > > > > > > > information about
> > > > > > > > the console UART. However if coreboot is not compiled with the 
> > > > > > > > UART
> > > > > > > > enabled, the information is left out. This configuration is 
> > > > > > > > quite
> > > > > > > > common, e.g. with shipping x86-based Chrome OS Chromebooks.
> > > > > > > >
> > > > > > > > Add a way to determine the UART settings in this case, using a
> > > > > > > > hard-coded list of PCI IDs.
> > > > > > > >
> > > > > > > > Signed-off-by: Simon Glass 
> > > > > > > > ---
> > > > > > > >
> > > > > > > >  drivers/serial/serial_coreboot.c | 68 
> > > > > > > > 
> > > > > > > >  include/pci_ids.h|  1 +
> > > > > > > >  2 files changed, 61 insertions(+), 8 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/drivers/serial/serial_coreboot.c 
> > > > > > > > b/drivers/serial/serial_coreboot.c
> > > > > > > > index de09c8681f5..4b4619432d8 100644
> > > > > > > > --- a/drivers/serial/serial_coreboot.c
> > > > > > > > +++ b/drivers/serial/serial_coreboot.c
> > > > > > > > @@ -11,19 +11,71 @@
> > > > > > > >  #include 
> > > > > > > >  #include 
> > > > > > > >
> > > > > > > > +static const struct pci_device_id ids[] = {
> > > > > > > > +   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, 
> > > > > > > > PCI_DEVICE_ID_INTEL_APL_UART2) },
> > > > > > > > +   {},
> > > > > > > > +};
> > > > > > > > +
> > > > > > > > +/*
> > > > > > > > + * Coreboot only sets up the UART if it uses it and doesn't 
> > > > > > > > bother to put the
> > > > > > > > + * details in sysinfo if it doesn't. Try to guess in that 
> > > > > > > > case, using devices
> > > > > > > > + * we know about
> > > > > > > > + *
> > > > > > > > + * @plat: Platform data to fill in
> > > > > > > > + * @return 0 if found, -ve if no UART was found
> > > > > > > > + */
> > > > > > > > +static int guess_uart(struct ns16550_plat *plat)
> > > > > > >
> > > > > > > This is really not a guess, but use a pre-configured platform 
> > > > > > > data.
> > > > > > > Also this only work for Apollo Lake board, and will break other 
> > > > > > > boards
> > > > > > > if they don't have cbinfo available.
> > > > > >
> > > > > > Which bit of it breaks other boards?
> > > > >
> > > > > I see it does not return the error code to the caller, that's okay ...
> > > > >
> > > > > >
> > > > > > >
> > > > > > > Why not just simply put a serial node in the device tree and we 
> > > > > > > are all done?
> > > > > >
> > > > > > See my other email...I am trying to make this boot on any board that
> > > > > > coreboot supports.
> > > > >
> > > > > But this solution does not scale. One has to put all known UARTs into
> > > > > serial_coreboot.c.
> > > >
> > > > Yes that's right...but this is only for when coreboot does not enable
> > > > serial. Also the number of new platforms is not that great.
> > > >
> > > > >
> > > > > Why not patch coreboot instead? Why coreboot does not provide a cbinfo
> > > > > with serial?
> > > >
> > > > Because it does not even set up the serial device in that case, so
> > > > doesn't know the details. The driver is completely missing.
> > >
> > > Sigh. Is it possible to upstream a patch to coreboot to enable that?
> >
> > Well I'm not even sure upstream coreboot boots on the various
> > Chromebooks I am targetting. If it does, then serial is probablt
> > enabled. But certainly for chromebooks, it is not. My goal is to have
> > U-Boot boot on a chromebook in altfw mode with serial enabled.
> >
> > >
> > > I don't like the current approach because it ends up duplicating all
> > > UART IDs/info in C.
> >
> > Yes. Do you think it would be better to put it in the devicetree? I
> > suppose we could add some more stuff to the compatible string,
> > although U-Boot does not support the PCI compatible strings at
> > present.
>
> Putting it in the device tree also looks odd, because it only matters
> on a dedicated board.

Right, but that is the nature of trying to run the same image on
different hardware.

>
> > What do you suggest?
>
> Or parse the ACPI table coreboot has set up? But that might be another
> huge monster :(

Yes, even worse...

Regards,
Simon


Re: [PATCH] Makefile: Fix generation of flash.bin u-boot.itb with binman

2021-04-30 Thread Simon Glass
Hi,

On Thu, 29 Apr 2021 at 17:11, Bin Meng  wrote:
>
> On Sat, Apr 24, 2021 at 8:57 PM Marek Vasut  wrote:
> >
> > On 2/25/21 9:50 PM, Marek Vasut wrote:
> > > In case binman is enabled, the u-boot.itb is generated using this tool
> > > and there is no direct u-boot.itb target, but instead the binman tool
> > > must be invoked. Add support for this case.
> > >
> > > Signed-off-by: Marek Vasut 
> > > Cc: Peng Fan 
> > > Cc: Stefano Babic 
> >
> > This bugfix is still missing from upstream.

It seems to be missing a Fixes tag?

I can't really comment on this particular patch as it is up to MX8
what is done here.

But a much better solution is to move this generation stuff to binman,
instead of all the arch-specific Makefile rules.

Regards,
Simon


Re: [PATCH v2 2/2] of: addr: Remove call to dev_count_cells() in of_get_address()

2021-04-30 Thread Simon Glass
On Fri, 30 Apr 2021 at 07:17, Bin Meng  wrote:
>
> In of_get_address(), there is:
>
>   dev_count_cells(dev, &na, &ns);
>
> followed by:
>
>   bus->count_cells(dev, &na, &ns);
>
> but no codes in between use na/ns, hence the first call is useless.
> By dropping the first call, dev_count_cells() is now useless too.
>
> Signed-off-by: Bin Meng 
>
> ---
>
> Changes in v2:
> - new patch: of: addr: Remove call to dev_count_cells() in of_get_address()
>
>  drivers/core/of_addr.c | 6 --
>  1 file changed, 6 deletions(-)

Reviewed-by: Simon Glass 

I wonder why this is now different from linux?


Re: [PATCH 03/17] x86: Allow coreboot serial driver to guess the UART

2021-04-30 Thread Andy Shevchenko
On Fri, Apr 30, 2021 at 9:14 PM Simon Glass  wrote:
> On Thu, 29 Apr 2021 at 17:01, Bin Meng  wrote:
> > On Fri, Apr 30, 2021 at 12:10 AM Simon Glass  wrote:
> > > On Sun, 25 Apr 2021 at 18:21, Bin Meng  wrote:
> > > > On Sun, Apr 25, 2021 at 10:10 AM Simon Glass  wrote:
> > > > > On Sun, 25 Apr 2021 at 13:49, Bin Meng  wrote:
> > > > > > On Sat, Apr 24, 2021 at 12:56 PM Simon Glass  
> > > > > > wrote:
> > > > > > > On Thu, 8 Apr 2021 at 14:23, Bin Meng  wrote:
> > > > > > > > On Wed, Apr 7, 2021 at 12:32 PM Simon Glass  
> > > > > > > > wrote:
> > > > > > > > >
> > > > > > > > > At present this driver relies on coreboot to provide 
> > > > > > > > > information about
> > > > > > > > > the console UART. However if coreboot is not compiled with 
> > > > > > > > > the UART
> > > > > > > > > enabled, the information is left out. This configuration is 
> > > > > > > > > quite
> > > > > > > > > common, e.g. with shipping x86-based Chrome OS Chromebooks.
> > > > > > > > >
> > > > > > > > > Add a way to determine the UART settings in this case, using a
> > > > > > > > > hard-coded list of PCI IDs.

I don't like this either, so -1 from me.

What coreboot should do is either provide serial information or SPCR ACPI table.
Otherwise if it does not provide it, I think it's on purpose, and we
have to respect this.

The patch is ugly hack in my opinion. Sorry.

You may make it less ugly by checking PCI class rather than IDs.

> > > > > > > > Why not just simply put a serial node in the device tree and we 
> > > > > > > > are all done?
> > > > > > >
> > > > > > > See my other email...I am trying to make this boot on any board 
> > > > > > > that
> > > > > > > coreboot supports.
> > > > > >
> > > > > > But this solution does not scale. One has to put all known UARTs 
> > > > > > into
> > > > > > serial_coreboot.c.
> > > > >
> > > > > Yes that's right...but this is only for when coreboot does not enable
> > > > > serial. Also the number of new platforms is not that great.
> > > > >
> > > > > >
> > > > > > Why not patch coreboot instead? Why coreboot does not provide a 
> > > > > > cbinfo
> > > > > > with serial?
> > > > >
> > > > > Because it does not even set up the serial device in that case, so
> > > > > doesn't know the details. The driver is completely missing.
> > > >
> > > > Sigh. Is it possible to upstream a patch to coreboot to enable that?
> > >
> > > Well I'm not even sure upstream coreboot boots on the various
> > > Chromebooks I am targetting. If it does, then serial is probablt
> > > enabled. But certainly for chromebooks, it is not. My goal is to have
> > > U-Boot boot on a chromebook in altfw mode with serial enabled.
> > >
> > > >
> > > > I don't like the current approach because it ends up duplicating all
> > > > UART IDs/info in C.
> > >
> > > Yes. Do you think it would be better to put it in the devicetree? I
> > > suppose we could add some more stuff to the compatible string,
> > > although U-Boot does not support the PCI compatible strings at
> > > present.
> >
> > Putting it in the device tree also looks odd, because it only matters
> > on a dedicated board.
>
> Right, but that is the nature of trying to run the same image on
> different hardware.
>
> >
> > > What do you suggest?
> >
> > Or parse the ACPI table coreboot has set up? But that might be another
> > huge monster :(
>
> Yes, even worse...

-- 
With Best Regards,
Andy Shevchenko


Re: [PATCH] Makefile: Fix generation of flash.bin u-boot.itb with binman

2021-04-30 Thread Marek Vasut

On 4/30/21 8:13 PM, Simon Glass wrote:

Hi,


Hello Simon,


On Thu, 29 Apr 2021 at 17:11, Bin Meng  wrote:


On Sat, Apr 24, 2021 at 8:57 PM Marek Vasut  wrote:


On 2/25/21 9:50 PM, Marek Vasut wrote:

In case binman is enabled, the u-boot.itb is generated using this tool
and there is no direct u-boot.itb target, but instead the binman tool
must be invoked. Add support for this case.

Signed-off-by: Marek Vasut 
Cc: Peng Fan 
Cc: Stefano Babic 


This bugfix is still missing from upstream.


It seems to be missing a Fixes tag?


There are way too many commits related to this to identify specific one.


I can't really comment on this particular patch as it is up to MX8
what is done here.


In that case, deciding on this bugfix is up to the maintainer, Stefano.


But a much better solution is to move this generation stuff to binman,
instead of all the arch-specific Makefile rules.


Feel free to submit subsequent patch, but this bug should be fixed 
first, improvements can go in later.


Re: [PATCH] Makefile: Fix generation of flash.bin u-boot.itb with binman

2021-04-30 Thread Simon Glass
Hi Marek,

On Fri, 30 Apr 2021 at 11:47, Marek Vasut  wrote:
>
> On 4/30/21 8:13 PM, Simon Glass wrote:
> > Hi,
>
> Hello Simon,
>
> > On Thu, 29 Apr 2021 at 17:11, Bin Meng  wrote:
> >>
> >> On Sat, Apr 24, 2021 at 8:57 PM Marek Vasut  wrote:
> >>>
> >>> On 2/25/21 9:50 PM, Marek Vasut wrote:
>  In case binman is enabled, the u-boot.itb is generated using this tool
>  and there is no direct u-boot.itb target, but instead the binman tool
>  must be invoked. Add support for this case.
> 
>  Signed-off-by: Marek Vasut 
>  Cc: Peng Fan 
>  Cc: Stefano Babic 
> >>>
> >>> This bugfix is still missing from upstream.
> >
> > It seems to be missing a Fixes tag?
>
> There are way too many commits related to this to identify specific one.

Sure, I was suggesting why it had not been picked up for the release.

>
> > I can't really comment on this particular patch as it is up to MX8
> > what is done here.
>
> In that case, deciding on this bugfix is up to the maintainer, Stefano.
>
> > But a much better solution is to move this generation stuff to binman,
> > instead of all the arch-specific Makefile rules.
>
> Feel free to submit subsequent patch, but this bug should be fixed
> first, improvements can go in later.

Yes indeed. It looks like the maintainers are on this thread so they
should be able to pick it up.

Regards,
Simon


RE: [PATCH] ARM: stm32: Enable UNZIP on DHSOM by default

2021-04-30 Thread Patrice CHOTARD
Hi Marek

Can you resend this patch to our @foss.st.com email address please ?

Thanks
Patrice

De : Marek Vasut 
Envoyé : vendredi 30 avril 2021 13:49
À : u-boot@lists.denx.de 
Cc : Marek Vasut ; Patrice CHOTARD ; 
Patrick DELAUNAY 
Objet : [PATCH] ARM: stm32: Enable UNZIP on DHSOM by default

The CMD_UNZIP provides the 'gzwrite' command, which is convenient
for writing e.g. gz-compressed images to eMMC from U-Boot.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 configs/stm32mp15_dhcom_basic_defconfig | 1 +
 configs/stm32mp15_dhcor_basic_defconfig | 1 +
 2 files changed, 2 insertions(+)

diff --git a/configs/stm32mp15_dhcom_basic_defconfig 
b/configs/stm32mp15_dhcom_basic_defconfig
index e36d34d001e..df702547081 100644
--- a/configs/stm32mp15_dhcom_basic_defconfig
+++ b/configs/stm32mp15_dhcom_basic_defconfig
@@ -36,6 +36,7 @@ CONFIG_SYS_PROMPT="STM32MP> "
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_UNZIP=y
 CONFIG_CMD_ADC=y
 CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
diff --git a/configs/stm32mp15_dhcor_basic_defconfig 
b/configs/stm32mp15_dhcor_basic_defconfig
index 4794b1a14d5..4508d4158af 100644
--- a/configs/stm32mp15_dhcor_basic_defconfig
+++ b/configs/stm32mp15_dhcor_basic_defconfig
@@ -34,6 +34,7 @@ CONFIG_SYS_PROMPT="STM32MP> "
 CONFIG_CMD_EEPROM=y
 CONFIG_CMD_MEMINFO=y
 CONFIG_CMD_MEMTEST=y
+CONFIG_CMD_UNZIP=y
 CONFIG_CMD_ADC=y
 CONFIG_CMD_CLK=y
 CONFIG_CMD_DFU=y
--
2.30.2



ST Restricted


RE: [PATCH] ARM: stm32: Add additional ID register check for KSZ8851 presence

2021-04-30 Thread Patrice CHOTARD
Hi Marek

Can you resend this patch to our @foss.st.com email address please ?

Thanks
Patrice

De : Marek Vasut 
Envoyé : vendredi 30 avril 2021 13:29
À : u-boot@lists.denx.de 
Cc : Marek Vasut ; Patrice CHOTARD ; 
Patrick DELAUNAY 
Objet : [PATCH] ARM: stm32: Add additional ID register check for KSZ8851 
presence

Currently the code sets eth1addr only if /ethernet1 alias exists in DT,
the node pointed to by the alias has "micrel,ks8851-mll" compatible
string, and the KSZ8851 CCR register read indicates programmed EEPROM
is not connected.

This is not sufficient to detect cases where the DT still contains the
KSZ8851 nodes, but the chip itself is not present. Extend the detection
to handle these cases.

Signed-off-by: Marek Vasut 
Cc: Patrice Chotard 
Cc: Patrick Delaunay 
---
 board/dhelectronics/dh_stm32mp1/board.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/board/dhelectronics/dh_stm32mp1/board.c 
b/board/dhelectronics/dh_stm32mp1/board.c
index 49b12c4c042..ac1af718d4a 100644
--- a/board/dhelectronics/dh_stm32mp1/board.c
+++ b/board/dhelectronics/dh_stm32mp1/board.c
@@ -86,6 +86,8 @@ DECLARE_GLOBAL_DATA_PTR;
 #define KS_CCR_EEPROM   BIT(9)
 #define KS_BE0  BIT(12)
 #define KS_BE1  BIT(13)
+#define KS_CIDER   0xC0
+#define CIDER_ID   0x8870

 int setup_mac_address(void)
 {
@@ -123,11 +125,18 @@ int setup_mac_address(void)
  * is present. If EEPROM is present, it must contain valid
  * MAC address.
  */
-   u32 reg, ccr;
+   u32 reg, cider, ccr;
 reg = fdt_get_base_address(gd->fdt_blob, off);
 if (!reg)
 goto out_set_ethaddr;

+   writew(KS_BE0 | KS_BE1 | KS_CIDER, reg + 2);
+   cider = readw(reg);
+   if ((cider & 0xfff0) != CIDER_ID) {
+   skip_eth1 = true;
+   goto out_set_ethaddr;
+   }
+
 writew(KS_BE0 | KS_BE1 | KS_CCR, reg + 2);
 ccr = readw(reg);
 if (ccr & KS_CCR_EEPROM) {
--
2.30.2



ST Restricted


Re: [PATCH v2 2/2] of: addr: Remove call to dev_count_cells() in of_get_address()

2021-04-30 Thread Bin Meng
Hi Simon,

On Sat, May 1, 2021 at 2:14 AM Simon Glass  wrote:
>
> On Fri, 30 Apr 2021 at 07:17, Bin Meng  wrote:
> >
> > In of_get_address(), there is:
> >
> >   dev_count_cells(dev, &na, &ns);
> >
> > followed by:
> >
> >   bus->count_cells(dev, &na, &ns);
> >
> > but no codes in between use na/ns, hence the first call is useless.
> > By dropping the first call, dev_count_cells() is now useless too.
> >
> > Signed-off-by: Bin Meng 
> >
> > ---
> >
> > Changes in v2:
> > - new patch: of: addr: Remove call to dev_count_cells() in of_get_address()
> >
> >  drivers/core/of_addr.c | 6 --
> >  1 file changed, 6 deletions(-)
>
> Reviewed-by: Simon Glass 
>
> I wonder why this is now different from linux?

With this patch, the code flow is the same as Linux.

Regards,
Bin