RE: [v1 2/2] arm: socfpga: Changed to store QSPI reference clock in kHz

[Lim, Elly Siew Chin]

Hi Ley Foon,

> -Original Message-
> From: Tan, Ley Foon 
> Sent: Tuesday, March 23, 2021 6:49 PM
> To: Lim, Elly Siew Chin ; u-boot@lists.denx.de
> Cc: Marek Vasut ; See, Chin Liang
> ; Simon Goldschmidt
> ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai 
> Subject: RE: [v1 2/2] arm: socfpga: Changed to store QSPI reference clock in
> kHz
> 
> 
> 
> > -Original Message-
> > From: Lim, Elly Siew Chin 
> > Sent: Monday, March 15, 2021 10:37 PM
> > To: u-boot@lists.denx.de
> > Cc: Marek Vasut ; Tan, Ley Foon
> > ; See, Chin Liang ;
> > Simon Goldschmidt ; Chee, Tien Fong
> > ; Westergreen, Dalon
> > ; Simon Glass ; Gan,
> > Yau Wai ; Lim, Elly Siew Chin
> > 
> > Subject: [v1 2/2] arm: socfpga: Changed to store QSPI reference clock
> > in kHz
> >
> > Changed to store QSPI reference clock in kHz instead of Hz in boot
> > scratch
> > cold0 register for Stratix10 and Agilex.
> >
> > This patch is in preparation for Intel N5X SDRAM driver support.
> > Reserved 4 bits for Intel N5X SDRAM driver, and there will be 28 bits
> > to store QSPI reference clock.
> > Due to limited bits, QSPI reference clock frequency is converted to
> > kHz from Hz.
> >
> > Signed-off-by: Siew Chin Lim 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  arch/arm/mach-socfpga/clock_manager.c  |  5 +--
> >  .../include/mach/system_manager_soc64.h| 16 -
> >  arch/arm/mach-socfpga/mailbox_s10.c| 40
> > +++---
> >  include/configs/socfpga_soc64_common.h |  1 +
> >  4 files changed, 55 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/arm/mach-socfpga/clock_manager.c b/arch/arm/mach-
> > socfpga/clock_manager.c index be426a5cfb..2783b9d18d 100644
> > --- a/arch/arm/mach-socfpga/clock_manager.c
> > +++ b/arch/arm/mach-socfpga/clock_manager.c
> > @@ -67,8 +67,9 @@ int set_cpu_clk_info(void)  #if
> > IS_ENABLED(CONFIG_TARGET_SOCFPGA_SOC64)
> >  unsigned int cm_get_qspi_controller_clk_hz(void)
> >  {
> > -   return readl(socfpga_get_sysmgr_addr() +
> > -SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> > +   return (readl(socfpga_get_sysmgr_addr() +
> > +SYSMGR_SOC64_BOOT_SCRATCH_COLD0) &
> > +SYSMGR_SCRATCH_REG_0_QSPI_REFCLK_MASK) *
> > CLOCK_1K;
> >  }
> >  #endif
> >
> > 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 1eb8e7a904..fc4e17821b 100644
> > --- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
> > +++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
> > @@ -42,7 +42,10 @@ void populate_sysmgr_pinmux(void);
> >  #define SYSMGR_SOC64_GPO   0xe4
> >  #define SYSMGR_SOC64_GPI   0xe8
> >  #define SYSMGR_SOC64_MPU   0xf0
> > -/* store qspi ref clock */
> > +/*
> > + * Bits[31:28] reserved for N5X DDR retention, bits[27:0] reserved
> > +for SOC 64-bit
> > + * storing qspi ref clock (kHz)
> > + */
> >  #define SYSMGR_SOC64_BOOT_SCRATCH_COLD00x200
> >  /* store osc1 clock freq */
> >  #define SYSMGR_SOC64_BOOT_SCRATCH_COLD10x204
> > @@ -85,6 +88,17 @@ void populate_sysmgr_pinmux(void);
> >  #define SYSMGR_SOC64_HPS_OSC_CLK   0x1358
> >  #define SYSMGR_SOC64_IODELAY0  0x1400
> >
> > +/*
> > + * Bits for SYSMGR_SOC64_BOOT_SCRATCH_COLD0
> > + * Bits[31:28] reserved for DM DDR retention, bits[27:0] reserved for
> > +SOC 64-bit
> > + * storing qspi ref clock (kHz)
> > + */
> > +#define SYSMGR_SCRATCH_REG_0_QSPI_REFCLK_MASK
> > GENMASK(27, 0)
> > +#define ALT_SYSMGR_SCRATCH_REG_0_DDR_RETENTION_MASKBIT(31)
> > +#define ALT_SYSMGR_SCRATCH_REG_0_DDR_SHA_MASK  BIT(30)
> > +#define ALT_SYSMGR_SCRATCH_REG_0_DDR_RESET_TYPE_MASK
> > (BIT(29) | BIT(28))
> > +#define ALT_SYSMGR_SCRATCH_REG_0_DDR_RESET_TYPE_SHIFT  28
> > +
> >  #define SYSMGR_SDMMC
> > SYSMGR_SOC64_SDMMC
> >
> >  #define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGPINMUXBIT(0)
> > diff --git a/arch/arm/mach-socfpga/mailbox_s10.c b/arch/arm/mach-
> > socfpga/mailbox_s10.c index 7dcdae8136..2a13fbb506 100644
> > --- a/arch/arm/mach-socfpga/mailbox_s10.c
> > +++ b/arch/arm/mach-socfpga/mailbox_s10.c
> > @@ -356,6 +356,38 @@ int mbox_qspi_close(void)
> >  0, NULL, 0, 0, NULL);
> >  }
> >
> > +int mbox_qspi_set_controller_clk_hz(int clk_hz) {
> This function nothing related to mailbox. Change to other name and move
> the function to the place read qspi clock.
> Then can remove define CLOCK_1K from socfpga_soc64_common.h.
> 

Noted, I will rename this function to ' cm_set_qspi_controller_clk_hz ' and move
to clock_manager.c.
 
> 
> > +   u32 reg;
> > +   u32 clk_khz;
> > +
> > +   /* We are getting QSPI ref clock and set into sysmgr boot register */
> > +   /*
> > +* Only clock freq in kHz degree is accepted due to limited bits[27:0]
> > +* is reserved for storing the 

RE: [v1 1/2] arm: socfpga: Move Stratix10 and Agilex clock manager common code

[Lim, Elly Siew Chin]

Hi Ley Foon,

> -Original Message-
> From: Tan, Ley Foon 
> Sent: Tuesday, March 23, 2021 6:34 PM
> To: Lim, Elly Siew Chin ; u-boot@lists.denx.de
> Cc: Marek Vasut ; See, Chin Liang
> ; Simon Goldschmidt
> ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai 
> Subject: RE: [v1 1/2] arm: socfpga: Move Stratix10 and Agilex clock manager
> common code
> 
> 
> 
> > -Original Message-
> > From: Lim, Elly Siew Chin 
> > Sent: Monday, March 15, 2021 10:37 PM
> > To: u-boot@lists.denx.de
> > Cc: Marek Vasut ; Tan, Ley Foon
> > ; See, Chin Liang ;
> > Simon Goldschmidt ; Chee, Tien Fong
> > ; Westergreen, Dalon
> > ; Simon Glass ; Gan,
> > Yau Wai ; Lim, Elly Siew Chin
> > 
> > Subject: [v1 1/2] arm: socfpga: Move Stratix10 and Agilex clock
> > manager common code
> >
> > Move duplicated function cm_get_qspi_controller_clk_hz to
> > clock_manager.c.
> >
> > Signed-off-by: Siew Chin Lim 
> > Signed-off-by: Tien Fong Chee 
> > ---
> >  arch/arm/mach-socfpga/clock_manager.c  | 15 ---
> >  arch/arm/mach-socfpga/clock_manager_agilex.c   |  6 --
> >  arch/arm/mach-socfpga/clock_manager_s10.c  |  6 --
> >  arch/arm/mach-socfpga/include/mach/clock_manager.h |  4 
> >  arch/arm/mach-socfpga/include/mach/clock_manager_s10.h |  1 -
> >  5 files changed, 16 insertions(+), 16 deletions(-)
> >
> [...]
> 
> 
> >  unsigned int cm_get_spi_controller_clk_hz(void)
> >  {
> > u32 clock = cm_get_l3_main_clk_hz(); diff --git
> > a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > index 1f734bcd65..0f0cb230fa 100644
> > --- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > +++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> > @@ -12,6 +12,10 @@ 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);
> > +
> > +#if defined(CONFIG_TARGET_SOCFPGA_SOC64)
> > +unsigned int cm_get_qspi_controller_clk_hz(void);
> > +#endif
> >  #endif
> If this is for soc64, move to _SOC64.h file?
> 
We do have clock_manager_soc64.h which shared by both stratix 10 and agilex. 

clock_manager_s10.h if specific for CONFIG_TARGET_SOCFPGA_STRATIX10.  
clock_manager_s10.h includes clock_manager_soc64.h  and it contains additional 
struct and macro for s10.
> 
> 
> Regards
> Ley Foon

[v2 5/5] arm: socfpga: Restructure Stratix10 and Agilex handoff code

[Siew Chin Lim]

Restructure Stratix10 and Agilex handoff code to used by
all SOC64 devices, in preparation to support handoff for
Diamond Mesa.

Remove wrap_pinmux_config_s10.c. Add wrap_handoff_soc64.c
which contains the generic function to parse the handoff
data.

Update system_manager_soc64.c to use generic handoff
function in wrap_handoff_soc64.c.

Signed-off-by: Siew Chin Lim 

---
v2
- Change "#ifdef" to "#if IS_ENABLED()"
- Change to use captial letter for enum macros (LITTLE_ENDIAN, BIG_ENDIAN)
- Soft include files by alphabetical order in system_manager_soc64.c
  and wrap_handoff_soc64.c
- Simplify and clean up socfpga_get_handoff_size function
---
 arch/arm/mach-socfpga/Makefile |  4 +-
 arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 23 +++-
 .../include/mach/system_manager_soc64.h|  4 --
 arch/arm/mach-socfpga/system_manager_soc64.c   | 55 +++---
 arch/arm/mach-socfpga/wrap_handoff_soc64.c | 66 ++
 arch/arm/mach-socfpga/wrap_pinmux_config_s10.c | 56 --
 6 files changed, 126 insertions(+), 82 deletions(-)
 create mode 100644 arch/arm/mach-socfpga/wrap_handoff_soc64.c
 delete mode 100644 arch/arm/mach-socfpga/wrap_pinmux_config_s10.c

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index f9dd166ab3..5779c55621 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -37,7 +37,7 @@ obj-y += mmu-arm64_s10.o
 obj-y  += reset_manager_s10.o
 obj-y  += system_manager_soc64.o
 obj-y  += timer_s10.o
-obj-y  += wrap_pinmux_config_s10.o
+obj-y  += wrap_handoff_soc64.o
 obj-y  += wrap_pll_config_soc64.o
 endif
 
@@ -52,7 +52,7 @@ 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_pinmux_config_s10.o
+obj-y  += wrap_handoff_soc64.o
 obj-y  += wrap_pll_config_soc64.o
 endif
 
diff --git a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h 
b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
index 2561255712..3750216a9a 100644
--- a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
@@ -11,6 +11,7 @@
  * Offset for HW handoff from Quartus tools
  */
 /* HPS handoff */
+#define SOC64_HANDOFF_MAGIC_BOOT   0x424F4F54
 #define SOC64_HANDOFF_MAGIC_MUX0x504D5558
 #define SOC64_HANDOFF_MAGIC_IOCTL  0x494F4354
 #define SOC64_HANDOFF_MAGIC_FPGA   0x46504741
@@ -30,7 +31,7 @@
 #define SOC64_HANDOFF_DELAY(SOC64_HANDOFF_BASE + 0x3F0)
 #define SOC64_HANDOFF_CLOCK(SOC64_HANDOFF_BASE + 0x580)
 
-#ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
+#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_STRATIX10)
 #define SOC64_HANDOFF_CLOCK_OSC(SOC64_HANDOFF_BASE + 0x608)
 #define SOC64_HANDOFF_CLOCK_FPGA   (SOC64_HANDOFF_BASE + 0x60C)
 #else
@@ -38,4 +39,24 @@
 #define SOC64_HANDOFF_CLOCK_FPGA   (SOC64_HANDOFF_BASE + 0x600)
 #endif
 
+#define SOC64_HANDOFF_MUX_LEN  96
+#define SOC64_HANDOFF_IOCTL_LEN96
+#if IS_ENABLED(CONFIG_TARGET_SOCFPGA_STRATIX10)
+#define SOC64_HANDOFF_FPGA_LEN 42
+#else
+#define SOC64_HANDOFF_FPGA_LEN 40
+#endif
+#define SOC64_HANDOFF_DELAY_LEN96
+
+#ifndef __ASSEMBLY__
+#include 
+enum endianness {
+   LITTLE_ENDIAN = 0,
+   BIG_ENDIAN
+};
+
+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);
+#endif
 #endif /* _HANDOFF_SOC64_H_ */
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 4949cae97a..1eb8e7a904 100644
--- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
+++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
@@ -10,10 +10,6 @@
 void sysmgr_pinmux_init(void);
 void populate_sysmgr_fpgaintf_module(void);
 void populate_sysmgr_pinmux(void);
-void sysmgr_pinmux_table_sel(const u32 **table, unsigned int *table_len);
-void sysmgr_pinmux_table_ctrl(const u32 **table, unsigned int *table_len);
-void sysmgr_pinmux_table_fpga(const u32 **table, unsigned int *table_len);
-void sysmgr_pinmux_table_delay(const u32 **table, unsigned int *table_len);
 
 #define SYSMGR_SOC64_WDDBG 0x08
 #define SYSMGR_SOC64_DMA   0x20
diff --git a/arch/arm/mach-socfpga/system_manager_soc64.c 
b/arch/arm/mach-socfpga/system_manager_soc64.c
index c123cc9644..3b5e774e2d 100644
--- a/arch/arm/mach-socfpga/system_manager_soc64.c
+++ b/arch/arm/mach-socfpga/system_manager_soc64.c
@@ -4,10 +4,11 @@
  *
  */
 
-#include 
+#include 
+#include 
 #include 
 #include 
-#include 
+#include 
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -64,39 +65,55 @@ void populate_sysmgr_fpgaintf_module(void)
  */

[v2 4/5] arm: socfpga: Rearrange sequence of macros in handoff_soc64.h

[Siew Chin Lim]

Rearrange sequence of macros in handoff_soc64.h without any functionality
change. In preparation for Stratix10 and Agilex handoff function
restructuring.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 22 --
 1 file changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h 
b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
index 804715b13d..2561255712 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-2018 Intel Corporation 
+ * Copyright (C) 2016-2020 Intel Corporation 
  *
  */
 
@@ -10,21 +10,25 @@
 /*
  * Offset for HW handoff from Quartus tools
  */
-#define SOC64_HANDOFF_BASE 0xFFE3F000
-#define SOC64_HANDOFF_MUX  (SOC64_HANDOFF_BASE + 0x10)
-#define SOC64_HANDOFF_IOCTL(SOC64_HANDOFF_BASE + 0x1A0)
-#define SOC64_HANDOFF_FPGA (SOC64_HANDOFF_BASE + 0x330)
-#define SOC64_HANDOFF_DELAY(SOC64_HANDOFF_BASE + 0x3F0)
-#define SOC64_HANDOFF_CLOCK(SOC64_HANDOFF_BASE + 0x580)
-#define SOC64_HANDOFF_MISC (SOC64_HANDOFF_BASE + 0x610)
+/* HPS handoff */
 #define SOC64_HANDOFF_MAGIC_MUX0x504D5558
 #define SOC64_HANDOFF_MAGIC_IOCTL  0x494F4354
 #define SOC64_HANDOFF_MAGIC_FPGA   0x46504741
 #define SOC64_HANDOFF_MAGIC_DELAY  0x444C4159
 #define SOC64_HANDOFF_MAGIC_CLOCK  0x434C4B53
 #define SOC64_HANDOFF_MAGIC_MISC   0x4D495343
+
 #define SOC64_HANDOFF_OFFSET_LENGTH0x4
 #define SOC64_HANDOFF_OFFSET_DATA  0x10
+#define SOC64_HANDOFF_SIZE 4096
+
+#define SOC64_HANDOFF_BASE 0xFFE3F000
+#define SOC64_HANDOFF_MISC (SOC64_HANDOFF_BASE + 0x610)
+#define SOC64_HANDOFF_MUX  (SOC64_HANDOFF_BASE + 0x10)
+#define SOC64_HANDOFF_IOCTL(SOC64_HANDOFF_BASE + 0x1A0)
+#define SOC64_HANDOFF_FPGA (SOC64_HANDOFF_BASE + 0x330)
+#define SOC64_HANDOFF_DELAY(SOC64_HANDOFF_BASE + 0x3F0)
+#define SOC64_HANDOFF_CLOCK(SOC64_HANDOFF_BASE + 0x580)
 
 #ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
 #define SOC64_HANDOFF_CLOCK_OSC(SOC64_HANDOFF_BASE + 0x608)
@@ -34,6 +38,4 @@
 #define SOC64_HANDOFF_CLOCK_FPGA   (SOC64_HANDOFF_BASE + 0x600)
 #endif
 
-#define SOC64_HANDOFF_SIZE 4096
-
 #endif /* _HANDOFF_SOC64_H_ */
-- 
2.13.0

[v2 3/5] arm: socfpga: Changed system_manager_s10.c to system_manager_soc64.c

[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 ++--
 .../arm/mach-socfpga/{system_manager_s10.c => system_manager_soc64.c} | 0
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename arch/arm/mach-socfpga/{system_manager_s10.c => system_manager_soc64.c} 
(100%)

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index eca6fd173f..f9dd166ab3 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -35,7 +35,7 @@ obj-y += mailbox_s10.o
 obj-y  += misc_s10.o
 obj-y  += mmu-arm64_s10.o
 obj-y  += reset_manager_s10.o
-obj-y  += system_manager_s10.o
+obj-y  += system_manager_soc64.o
 obj-y  += timer_s10.o
 obj-y  += wrap_pinmux_config_s10.o
 obj-y  += wrap_pll_config_soc64.o
@@ -49,7 +49,7 @@ obj-y += misc_s10.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_s10.o
+obj-y  += system_manager_soc64.o
 obj-y  += timer_s10.o
 obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += vab.o
 obj-y  += wrap_pinmux_config_s10.o
diff --git a/arch/arm/mach-socfpga/system_manager_s10.c 
b/arch/arm/mach-socfpga/system_manager_soc64.c
similarity index 100%
rename from arch/arm/mach-socfpga/system_manager_s10.c
rename to arch/arm/mach-socfpga/system_manager_soc64.c
-- 
2.13.0

[v2 2/5] arm: socfpga: Changed wrap_pll_config_s10.c to wrap_pll_config_soc64.c

[Siew Chin Lim]

Rename to common file name to used by all SOC64 devices.

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

diff --git a/arch/arm/mach-socfpga/Makefile b/arch/arm/mach-socfpga/Makefile
index e4c2da93d5..eca6fd173f 100644
--- a/arch/arm/mach-socfpga/Makefile
+++ b/arch/arm/mach-socfpga/Makefile
@@ -38,7 +38,7 @@ obj-y += reset_manager_s10.o
 obj-y  += system_manager_s10.o
 obj-y  += timer_s10.o
 obj-y  += wrap_pinmux_config_s10.o
-obj-y  += wrap_pll_config_s10.o
+obj-y  += wrap_pll_config_soc64.o
 endif
 
 ifdef CONFIG_TARGET_SOCFPGA_AGILEX
@@ -53,7 +53,7 @@ obj-y += system_manager_s10.o
 obj-y  += timer_s10.o
 obj-$(CONFIG_SOCFPGA_SECURE_VAB_AUTH)  += vab.o
 obj-y  += wrap_pinmux_config_s10.o
-obj-y  += wrap_pll_config_s10.o
+obj-y  += wrap_pll_config_soc64.o
 endif
 
 ifdef CONFIG_SPL_BUILD
diff --git a/arch/arm/mach-socfpga/wrap_pll_config_s10.c 
b/arch/arm/mach-socfpga/wrap_pll_config_soc64.c
similarity index 100%
rename from arch/arm/mach-socfpga/wrap_pll_config_s10.c
rename to arch/arm/mach-socfpga/wrap_pll_config_soc64.c
-- 
2.13.0

[v2 1/5] arm: socfpga: Rename Stratix10 and Agilex handoff common macros

[Siew Chin Lim]

Rename handoff_s10.h to handoff_soc64.h. Changed macros prefix from
S10_HANDOFF to SOC64_HANDOFF.

Signed-off-by: Siew Chin Lim 
---
 arch/arm/mach-socfpga/clock_manager_s10.c  |  2 +-
 arch/arm/mach-socfpga/include/mach/handoff_s10.h   | 39 --
 arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 39 ++
 arch/arm/mach-socfpga/wrap_pinmux_config_s10.c | 18 +-
 arch/arm/mach-socfpga/wrap_pll_config_s10.c| 16 -
 include/configs/socfpga_soc64_common.h |  4 +--
 6 files changed, 59 insertions(+), 59 deletions(-)
 delete mode 100644 arch/arm/mach-socfpga/include/mach/handoff_s10.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/handoff_soc64.h

diff --git a/arch/arm/mach-socfpga/clock_manager_s10.c 
b/arch/arm/mach-socfpga/clock_manager_s10.c
index 642dcbb0ac..e060e5754e 100644
--- a/arch/arm/mach-socfpga/clock_manager_s10.c
+++ b/arch/arm/mach-socfpga/clock_manager_s10.c
@@ -8,7 +8,7 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 #include 
 
 DECLARE_GLOBAL_DATA_PTR;
diff --git a/arch/arm/mach-socfpga/include/mach/handoff_s10.h 
b/arch/arm/mach-socfpga/include/mach/handoff_s10.h
deleted file mode 100644
index 3e9b606ce2..00
--- a/arch/arm/mach-socfpga/include/mach/handoff_s10.h
+++ /dev/null
@@ -1,39 +0,0 @@
-/* SPDX-License-Identifier: GPL-2.0
- *
- * Copyright (C) 2016-2018 Intel Corporation 
- *
- */
-
-#ifndef _HANDOFF_S10_H_
-#define _HANDOFF_S10_H_
-
-/*
- * Offset for HW handoff from Quartus tools
- */
-#define S10_HANDOFF_BASE   0xFFE3F000
-#define S10_HANDOFF_MUX(S10_HANDOFF_BASE + 0x10)
-#define S10_HANDOFF_IOCTL  (S10_HANDOFF_BASE + 0x1A0)
-#define S10_HANDOFF_FPGA   (S10_HANDOFF_BASE + 0x330)
-#define S10_HANODFF_DELAY  (S10_HANDOFF_BASE + 0x3F0)
-#define S10_HANDOFF_CLOCK  (S10_HANDOFF_BASE + 0x580)
-#define S10_HANDOFF_MISC   (S10_HANDOFF_BASE + 0x610)
-#define S10_HANDOFF_MAGIC_MUX  0x504D5558
-#define S10_HANDOFF_MAGIC_IOCTL0x494F4354
-#define S10_HANDOFF_MAGIC_FPGA 0x46504741
-#define S10_HANDOFF_MAGIC_DELAY0x444C4159
-#define S10_HANDOFF_MAGIC_CLOCK0x434C4B53
-#define S10_HANDOFF_MAGIC_MISC 0x4D495343
-#define S10_HANDOFF_OFFSET_LENGTH  0x4
-#define S10_HANDOFF_OFFSET_DATA0x10
-
-#ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
-#define HANDOFF_CLOCK_OSC  (S10_HANDOFF_BASE + 0x608)
-#define HANDOFF_CLOCK_FPGA (S10_HANDOFF_BASE + 0x60C)
-#else
-#define HANDOFF_CLOCK_OSC  (S10_HANDOFF_BASE + 0x5fc)
-#define HANDOFF_CLOCK_FPGA (S10_HANDOFF_BASE + 0x600)
-#endif
-
-#define S10_HANDOFF_SIZE   4096
-
-#endif /* _HANDOFF_S10_H_ */
diff --git a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h 
b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
new file mode 100644
index 00..804715b13d
--- /dev/null
+++ b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
@@ -0,0 +1,39 @@
+/* SPDX-License-Identifier: GPL-2.0
+ *
+ * Copyright (C) 2016-2018 Intel Corporation 
+ *
+ */
+
+#ifndef _HANDOFF_SOC64_H_
+#define _HANDOFF_SOC64_H_
+
+/*
+ * Offset for HW handoff from Quartus tools
+ */
+#define SOC64_HANDOFF_BASE 0xFFE3F000
+#define SOC64_HANDOFF_MUX  (SOC64_HANDOFF_BASE + 0x10)
+#define SOC64_HANDOFF_IOCTL(SOC64_HANDOFF_BASE + 0x1A0)
+#define SOC64_HANDOFF_FPGA (SOC64_HANDOFF_BASE + 0x330)
+#define SOC64_HANDOFF_DELAY(SOC64_HANDOFF_BASE + 0x3F0)
+#define SOC64_HANDOFF_CLOCK(SOC64_HANDOFF_BASE + 0x580)
+#define SOC64_HANDOFF_MISC (SOC64_HANDOFF_BASE + 0x610)
+#define SOC64_HANDOFF_MAGIC_MUX0x504D5558
+#define SOC64_HANDOFF_MAGIC_IOCTL  0x494F4354
+#define SOC64_HANDOFF_MAGIC_FPGA   0x46504741
+#define SOC64_HANDOFF_MAGIC_DELAY  0x444C4159
+#define SOC64_HANDOFF_MAGIC_CLOCK  0x434C4B53
+#define SOC64_HANDOFF_MAGIC_MISC   0x4D495343
+#define SOC64_HANDOFF_OFFSET_LENGTH0x4
+#define SOC64_HANDOFF_OFFSET_DATA  0x10
+
+#ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
+#define SOC64_HANDOFF_CLOCK_OSC(SOC64_HANDOFF_BASE + 0x608)
+#define SOC64_HANDOFF_CLOCK_FPGA   (SOC64_HANDOFF_BASE + 0x60C)
+#else
+#define SOC64_HANDOFF_CLOCK_OSC(SOC64_HANDOFF_BASE + 0x5fc)
+#define SOC64_HANDOFF_CLOCK_FPGA   (SOC64_HANDOFF_BASE + 0x600)
+#endif
+
+#define SOC64_HANDOFF_SIZE 4096
+
+#endif /* _HANDOFF_SOC64_H_ */
diff --git a/arch/arm/mach-socfpga/wrap_pinmux_config_s10.c 
b/arch/arm/mach-socfpga/wrap_pinmux_config_s10.c
index 0b497ec30c..d10fb5e454 100644
--- a/arch/arm/mach-socfpga/wrap_pinmux_config_s10.c
+++ b/arch/arm/mach-socfpga/wrap_pinmux_config_s10.c
@@ -7,23 +7,23 @@
 #include 
 #include 
 #include 
-#include 
+#include 
 
 static void sysmgr_pinmux_handoff_read(void *handoff_address,
   const u32 **table,
   unsigned int *table_len)
 {
unsigned int 

[v2 0/5] Restructure Stratix10 and Agilex handoff code

[Siew Chin Lim]

This is the 2cd version of patchset to restructure Stratix10 and Agilex
handoff code to be generic and to be used by all SOC64 devices.

This patchset is extracted from "Add Intel Diamond Mesa SoC support" series.
We are in preparation to support new Intel N5X (Diamond Mesa) SOC64 device
and we would like to clean up some code before enable N5X device.

Patch status:
Have changes: Patch 5
Other patches unchanged.

Detail changelog can find in commit message.

v1->v2:

Patch 5:
- Change "#ifdef" to "#if IS_ENABLED()"
- Change to use captial letter for enum macros (LITTLE_ENDIAN, BIG_ENDIAN)
- Soft include files by alphabetical order in system_manager_soc64.c
  and wrap_handoff_soc64.c
- Simplify and clean up socfpga_get_handoff_size function

History:


  [v1]: 
https://patchwork.ozlabs.org/project/uboot/cover/20210315094329.30282-1-elly.siew.chin@intel.com/

  The first version of this patchset is extracted from "Add Intel Diamond Mesa 
SoC support" series.
  
https://patchwork.ozlabs.org/project/uboot/cover/20201110064439.9683-1-elly.siew.chin@intel.com/

This patchset has dependency on:

  1. arm: socfpga: Move Stratix10 and Agilex SPL common code
 
https://patchwork.ozlabs.org/project/uboot/patch/20210315075916.26336-1-elly.siew.chin@intel.com/


Siew Chin Lim (5):
  arm: socfpga: Rename Stratix10 and Agilex handoff common macros
  arm: socfpga: Changed wrap_pll_config_s10.c to wrap_pll_config_soc64.c
  arm: socfpga: Changed system_manager_s10.c to system_manager_soc64.c
  arm: socfpga: Rearrange sequence of macros in handoff_soc64.h
  arm: socfpga: Restructure Stratix10 and Agilex handoff code

 arch/arm/mach-socfpga/Makefile | 12 ++--
 arch/arm/mach-socfpga/clock_manager_s10.c  |  2 +-
 arch/arm/mach-socfpga/include/mach/handoff_s10.h   | 39 -
 arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 62 
 .../include/mach/system_manager_soc64.h|  4 --
 ...system_manager_s10.c => system_manager_soc64.c} | 55 +++---
 arch/arm/mach-socfpga/wrap_handoff_soc64.c | 66 ++
 arch/arm/mach-socfpga/wrap_pinmux_config_s10.c | 56 --
 ...ap_pll_config_s10.c => wrap_pll_config_soc64.c} | 16 +++---
 include/configs/socfpga_soc64_common.h |  4 +-
 10 files changed, 181 insertions(+), 135 deletions(-)
 delete mode 100644 arch/arm/mach-socfpga/include/mach/handoff_s10.h
 create mode 100644 arch/arm/mach-socfpga/include/mach/handoff_soc64.h
 rename arch/arm/mach-socfpga/{system_manager_s10.c => system_manager_soc64.c} 
(57%)
 create mode 100644 arch/arm/mach-socfpga/wrap_handoff_soc64.c
 delete mode 100644 arch/arm/mach-socfpga/wrap_pinmux_config_s10.c
 rename arch/arm/mach-socfpga/{wrap_pll_config_s10.c => 
wrap_pll_config_soc64.c} (74%)

-- 
2.13.0

RE: Patches pending for review

[Priyanka Jain]

>-Original Message-
>From: U-Boot  On Behalf Of Daniel
>Schwierzeck
>Sent: Wednesday, March 17, 2021 3:54 AM
>To: Aleksandar Gerasimovski powergrids.com>; Tom Rini ; u-boot@lists.denx.de;
>Priyanka Jain (OSS) 
>Subject: Re: Patches pending for review
>
>Am Montag, den 15.03.2021, 21:24 + schrieb Aleksandar Gerasimovski:
>> Hi Folks,
>>
>> Hope you are all well!
>>
>> I guess you have verry busy times, but I have to ask about the state
>> of my last two patches on patchwork:
>>
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>
>hwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2FVI1PR06MB402989C0EFEE
>6A51
>>
>21437C68D2819%40VI1PR06MB4029.eurprd06.prod.outlook.com%2Fda
>ta=04
>> %7C01%7Cpriyanka.jain%40nxp.com%7Caf582697fb7a4f5fda5c08d8e8ca419
>b%7C6
>>
>86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637515302698520810%7CU
>nknown
>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>WwiLCJ
>>
>XVCI6Mn0%3D%7C1000sdata=biSvPkALluX0yCljQYrthvm%2FEQxR%2B
>%2F5AQD9
>> YBw5wWvY%3Dreserved=0
>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpatc
>>
>hwork.ozlabs.org%2Fproject%2Fuboot%2Fpatch%2FVI1PR06MB40297747EE7
>A342B
>>
>4D3F0E2FD2819%40VI1PR06MB4029.eurprd06.prod.outlook.com%2Fda
>ta=04
>> %7C01%7Cpriyanka.jain%40nxp.com%7Caf582697fb7a4f5fda5c08d8e8ca419
>b%7C6
>>
>86ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637515302698520810%7CU
>nknown
>> %7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1ha
>WwiLCJ
>>
>XVCI6Mn0%3D%7C1000sdata=50EHHkr1ehPS2vA4hh05mmtqJbD8s44l7
>uc0QJcrp
>> PA%3Dreserved=0
>>
>> They are in same state since almost a month, and for me it looks like
>> they are forgotten.
>> Is it possible to get attention from some of you? Thanks in advance!
>
>I don't know why the patches were assigned to me and who did that. Also the
>patches were in state "Changes requested" so they were not visible in my
>patchwork inbox. Maybe someone's patchwork script went crazy ;)
>
>I've reassigned the patches to Priyanka who is NXP maintainer and changed
>the state to "New". Hope this helps ;)
>
>--
>- Daniel

I have applied 1/2 for v2020.04 as it fixes the bug. 
I will pick 2/2 for next branch in my next pull-request.

Regards
Priyanka

pull request of u-boot-fsl-qoriq for v2021.04

[Priyanka Jain]

Dear Tom,

Please find my pull-request for u-boot-fsl-qoriq/master 
https://github.com/u-boot/u-boot/pull/58

Summary
Bug fixes related to FSL-IFC, watchdog
layerscape-pcie, flexspi, T2080rdb.

priyankajain
-
The following changes since commit 1f9c3f13f6ad8595a0fb5ab2cb830583cdc0b60a:

  Merge tag 'efi-2021-04-rc5-2' of 
https://source.denx.de/u-boot/custodians/u-boot-efi (2021-03-20 08:55:18 -0400)

are available in the Git repository at:

  https://gitlab.denx.de/u-boot/custodians/u-boot-fsl-qoriq.git HEAD

for you to fetch changes up to cad6ffa34d255692833576bc2c911d1ee39f2af0:

  mtd: rawnand: fsl_ifc: fix FSL NAND driver to read all ONFI parameter pages 
(2021-03-23 18:06:07 +0530)


Aleksandar Gerasimovski (1):
  fsl_ifc: fix typo in the NOR CSOR register definition

Chris Packham (3):
  rtc: ds1307: Add ds1339 compatible
  powerpc: t2080rdb: Enable RTC support
  board: freescale: t208xrdb: Add link to User Guide

Hou Zhiqiang (1):
  pci: layerscape: Change to allocate zeroed memery for struct ls_pcie

Kuldeep Singh (5):
  configs: lx2160a: Unset CONFIG_SPI_FLASH_SPANSION
  configs: lx2160a: Remove unused Flexspi config options
  configs: ls1028a: Unset CONFIG_SPI_FLASH_SPANSION
  configs: ls1028aqds: Move CONFIG_SPI_FLASH_* definitions to defconfig
  configs: ls1028a: Correct CONFIG_ENV_SECT_SIZE

Maxim Kochetkov (1):
  mtd: rawnand: fsl_ifc: fix FSL NAND driver to read all ONFI parameter 
pages

arch/powerpc/dts/t2080rdb.dts|  8 
board/freescale/t208xrdb/README  |  5 +
configs/T2080RDB_NAND_defconfig  |  2 ++
configs/T2080RDB_SDCARD_defconfig|  2 ++
configs/T2080RDB_SPIFLASH_defconfig  |  2 ++
configs/T2080RDB_defconfig   |  2 ++
configs/ls1028aqds_tfa_SECURE_BOOT_defconfig |  3 ++-
configs/ls1028aqds_tfa_defconfig |  5 +++--
configs/ls1028aqds_tfa_lpuart_defconfig  |  5 +++--
configs/ls1028ardb_tfa_SECURE_BOOT_defconfig |  1 -
configs/ls1028ardb_tfa_defconfig |  3 +--
configs/lx2160aqds_tfa_SECURE_BOOT_defconfig |  1 -
configs/lx2160aqds_tfa_defconfig |  1 -
configs/lx2160ardb_tfa_SECURE_BOOT_defconfig |  1 -
configs/lx2160ardb_tfa_defconfig |  1 -
configs/lx2160ardb_tfa_stmm_defconfig|  1 -
drivers/mtd/nand/raw/fsl_ifc_nand.c  | 17 ++---
drivers/pci/pcie_layerscape_ep.c |  2 +-
drivers/pci/pcie_layerscape_rc.c |  2 +-
drivers/rtc/ds1307.c |  2 ++
include/configs/ls1028aqds.h |  6 --
include/configs/lx2160a_common.h |  6 --
include/fsl_ifc.h|  2 +-
23 files changed, 45 insertions(+), 35 deletions(-)

RE: [v1 5/5] arm: socfpga: Restructure Stratix10 and Agilex handoff code

[Tan, Ley Foon]

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Wednesday, March 24, 2021 11:02 AM
> To: Tan, Ley Foon ; u-boot@lists.denx.de
> Cc: Marek Vasut ; See, Chin Liang
> ; Simon Goldschmidt
> ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai 
> Subject: RE: [v1 5/5] arm: socfpga: Restructure Stratix10 and Agilex handoff
> code
> 
> Hi Ley Foon,
> 
> > > +
> > > +int socfpga_handoff_read(void *handoff_address, void *table, u32
> > > table_len,
> > > +  enum endianness big_endian)
> > > +{
> > > + u32 temp, i;
> > > + u32 *table_x32 = table;
> > > +
> > > + debug("%s: handoff addr = 0x%p ", __func__, (u32
> > > *)handoff_address);
> > > +
> > > + if (big_endian) {
> > > + if (swab32(readl(SOC64_HANDOFF_BASE)) ==
> > > SOC64_HANDOFF_MAGIC_BOOT) {
> > > + debug("Handoff table address = 0x%p ", table_x32);
> > > + debug("table length = 0x%x\n", table_len);
> > > + debug("%s: handoff data =\n{\n", __func__);
> > > +
> > > + for (i = 0; i < table_len; i++) {
> > > + temp = readl(handoff_address +
> > > +  SOC64_HANDOFF_OFFSET_DATA +
> > > +  (i * sizeof(u32)));
> > > + *table_x32 = swab32(temp);
> > > +
> > > + if (!(i % 2))
> > > + debug(" No.%d Addr 0x%08x: ", i,
> > > +   *table_x32);
> > > + else
> > > + debug(" 0x%08x\n", *table_x32);
> > > +
> > > + table_x32++;
> > > + }
> > > + debug("\n}\n");
> > > + } else {
> > > + debug("%s: Cannot find
> > > SOC64_HANDOFF_MAGIC_BOOT ", __func__);
> > > + debug("at addr  0x%p\n", (u32 *)handoff_address);
> > > + return -EPERM;
> > > + }
> > > + }
> > How about if it is little endian, why don't need to fill up table_x32?
> >
> The little endian only needed in new Intel SOC N5X (Diamond Mesa) , we will
> upstream this part together with N5X patches later.

Then can return error if doesn't support little endian as now.

test/overlay builds every time

[Simon Glass]

Hi Maxime & Pantelis,

I notice that this directory always builds its files even if seemingly
nothing has changed:

  LD  test/built-in.o
  DTC test/overlay/test-fdt-base.dtb
  DTB test/overlay/test-fdt-base.dtb.S
  AS  test/overlay/test-fdt-base.dtb.o
  DTC test/overlay/test-fdt-overlay.dtb
  DTB test/overlay/test-fdt-overlay.dtb.S
  AS  test/overlay/test-fdt-overlay.dtb.o
  DTC test/overlay/test-fdt-overlay-stacked.dtb
  DTB test/overlay/test-fdt-overlay-stacked.dtb.S
  AS  test/overlay/test-fdt-overlay-stacked.dtb.o
  LD  test/overlay/built-in.o
  LD  u-boot

Do either of you know what might be causing this? Can we fix it?

Thanks,
Simon

RE: [v1 5/5] arm: socfpga: Restructure Stratix10 and Agilex handoff code

[Lim, Elly Siew Chin]

Hi Ley Foon,

> -Original Message-
> From: Tan, Ley Foon 
> Sent: Tuesday, March 23, 2021 6:04 PM
> To: Lim, Elly Siew Chin ; u-boot@lists.denx.de
> Cc: Marek Vasut ; See, Chin Liang
> ; Simon Goldschmidt
> ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai 
> Subject: RE: [v1 5/5] arm: socfpga: Restructure Stratix10 and Agilex handoff
> code
> 
> 
> 
> > -Original Message-
> > From: Lim, Elly Siew Chin 
> > Sent: Monday, March 15, 2021 5:43 PM
> > To: u-boot@lists.denx.de
> > Cc: Marek Vasut ; Tan, Ley Foon
> > ; See, Chin Liang ;
> > Simon Goldschmidt ; Chee, Tien Fong
> > ; Westergreen, Dalon
> > ; Simon Glass ; Gan,
> > Yau Wai ; Lim, Elly Siew Chin
> > 
> > Subject: [v1 5/5] arm: socfpga: Restructure Stratix10 and Agilex
> > handoff code
> >
> > Restructure Stratix10 and Agilex handoff code to used by all SOC64
> > devices, in preparation to support handoff for Diamond Mesa.
> >
> > Remove wrap_pinmux_config_s10.c. Add wrap_handoff_soc64.c which
> > contains the generic function to parse the handoff data.
> >
> > Update system_manager_soc64.c to use generic handoff function in
> > wrap_handoff_soc64.c.
> >
> > Signed-off-by: Siew Chin Lim 
> > ---
> >  arch/arm/mach-socfpga/Makefile |  4 +-
> >  arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 21 +++
> >  .../include/mach/system_manager_soc64.h|  4 --
> >  arch/arm/mach-socfpga/system_manager_soc64.c   | 53 ++---
> --
> > -
> >  arch/arm/mach-socfpga/wrap_handoff_soc64.c | 73
> > ++
> >
> > diff --git a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> > b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> > index 2561255712..f4c03688d6 100644
> > --- a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> > +++ b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> > @@ -11,6 +11,7 @@
> >   * Offset for HW handoff from Quartus tools
> >   */
> >  /* HPS handoff */
> > +#define SOC64_HANDOFF_MAGIC_BOOT   0x424F4F54
> >  #define SOC64_HANDOFF_MAGIC_MUX0x504D5558
> >  #define SOC64_HANDOFF_MAGIC_IOCTL  0x494F4354
> >  #define SOC64_HANDOFF_MAGIC_FPGA   0x46504741
> > @@ -38,4 +39,24 @@
> >  #define SOC64_HANDOFF_CLOCK_FPGA   (SOC64_HANDOFF_BASE +
> > 0x600)
> >  #endif
> >
> > +#define SOC64_HANDOFF_MUX_LEN  96
> > +#define SOC64_HANDOFF_IOCTL_LEN96
> > +#ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
> Can change to #if CONFIG_IS_ENABLED()
> 
> 
> > +#define SOC64_HANDOFF_FPGA_LEN 42
> > +#else
> > +#define SOC64_HANDOFF_FPGA_LEN 40
> > +#endif
> > +#define SOC64_HANDOFF_DELAY_LEN96
> > +
> > +#ifndef __ASSEMBLY__
> > +#include 
> > +enum endianness {
> > +   little_endian,
> > +   big_endian
> > +};
> Uses capital letter for enum macros.
> 
> > +
> > +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);
> > +#endif
> >  #endif /* _HANDOFF_SOC64_H_ */
> > 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 4949cae97a..1eb8e7a904 100644
> > --- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
> > +++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
> > @@ -10,10 +10,6 @@
> >  void sysmgr_pinmux_init(void);
> >  void populate_sysmgr_fpgaintf_module(void);
> >  void populate_sysmgr_pinmux(void);
> > -void sysmgr_pinmux_table_sel(const u32 **table, unsigned int
> > *table_len); -void sysmgr_pinmux_table_ctrl(const u32 **table,
> > unsigned int *table_len); -void sysmgr_pinmux_table_fpga(const u32
> > **table, unsigned int *table_len); -void
> > sysmgr_pinmux_table_delay(const u32 **table, unsigned int *table_len);
> >
> >  #define SYSMGR_SOC64_WDDBG 0x08
> >  #define SYSMGR_SOC64_DMA   0x20
> 
> [...]
> 
> > diff --git a/arch/arm/mach-socfpga/wrap_handoff_soc64.c
> > b/arch/arm/mach-socfpga/wrap_handoff_soc64.c
> > new file mode 100644
> > index 00..ba168676e9
> > --- /dev/null
> > +++ b/arch/arm/mach-socfpga/wrap_handoff_soc64.c
> > @@ -0,0 +1,73 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Copyright (C) 2020 Intel Corporation 
> > + *
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include "log.h"
> Sort this.
> 
> 
> > +
> > +int socfpga_get_handoff_size(void *handoff_address, enum endianness
> > +endian) {
> > +   u32 handoff_size;
> > +
> > +   if (endian == little_endian) {
> > +   handoff_size = (readl(handoff_address +
> > SOC64_HANDOFF_OFFSET_LENGTH) -
> > +   SOC64_HANDOFF_OFFSET_DATA) /
> > +   sizeof(u32);
> > +   } else if (endian == big_endian) {
> > +   handoff_size = 

Re: [PATCH v2 1/2] power: regulator: add driver for ANATOP regulator

[Ying-Chun Liu (PaulLiu)]

Hi Sean,

Thanks for the review. I fix almost of the issues. Will upload the v3 soon.

Still have some questions.


Sean Anderson 於 2021/3/23 下午11:06 寫道:
>
>
>
> if (anatop_reg->supply) {
>     ret = regulator_set_value(anatop_reg->supply, uV + 15);
>     if (ret)
>     return ret;
> }
>

What is 15? Is it the min_dropout_uV?

Should I set it to 125000 instead?



>
>
> 
> ret = regulator_set_enable(sreg->supply, true);
> if (ret)
>     return ret;
>

Since vin-supply is optional, I change it to

    ret = device_get_supply_regulator(dev, "vin-supply",
  _reg->supply);
    if (!ret) {
    ret = regulator_set_enable(anatop_reg->supply, true);
    if (ret)
    return ret;
    }

Is this ok?

> > +
> > +    ret = ofnode_read_u32(dev_ofnode(dev),
>
> > +U_BOOT_DRIVER(anatop_regulator) = {
> > +    .name = "anatop_regulator",
> > +    .id = UCLASS_REGULATOR,
> > +    .ops = _regulator_ops,
> > +    .of_match = of_anatop_regulator_match_tbl,
> > +    .plat_auto = sizeof(struct anatop_regulator),
> > +    .probe = anatop_regulator_probe,
> > +};
> >


Yours,
Paul

Re: [PATCH 1/2] of: addr: Abort address translation for parent nodes missing 'ranges'

[Bin Meng]

Hi Dario,

On Wed, Mar 24, 2021 at 1:27 AM Dario Binacchi  wrote:
>
> Hi Bin,
>
> > Il 22/03/2021 02:25 Bin Meng  ha scritto:
> >
> >
> > Hi Dario,
> >
> > On Sun, Mar 21, 2021 at 11:19 PM Dario Binacchi  wrote:
> > >
> > > Hi Tom,
> > >
> > > > Il 18/03/2021 20:51 Tom Rini  ha scritto:
> > > >
> > > >
> > > > On Thu, Mar 18, 2021 at 08:27:49AM +0100, Dario Binacchi wrote:
> > > > > Hi Bin,
> > > > >
> > > > > > Il 17/03/2021 02:26 Bin Meng  ha scritto:
> > > > > >
> > > > > >
> > > > > > Hi Dario,
> > > > > >
> > > > > > On Wed, Mar 17, 2021 at 4:57 AM Dario Binacchi  
> > > > > > wrote:
> > > > > > >
> > > > > > > Hi Bin,
> > > > > > >
> > > > > > > > Il 16/03/2021 02:28 Bin Meng  ha scritto:
> > > > > > > >
> > > > > > > >
> > > > > > > > Hi Dario,
> > > > > > > >
> > > > > > > > On Tue, Mar 16, 2021 at 6:49 AM Dario Binacchi 
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Il 15/03/2021 19:23 Simon Glass  ha 
> > > > > > > > > > scritto:
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > +Tom Rini too
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > On Tue, 16 Mar 2021 at 03:48, Bin Meng  
> > > > > > > > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > +Dario Binacchi
> > > > > > > > > > >
> > > > > > > > > > > On Mon, Mar 15, 2021 at 3:11 PM Simon Glass 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > Hi Bin,
> > > > > > > > > > > >
> > > > > > > > > > > > On Wed, 3 Mar 2021 at 14:54, Simon Glass 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > On Fri, 26 Feb 2021 at 00:36, Bin Meng 
> > > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > The implementation of of_translate_one() was taken 
> > > > > > > > > > > > > > from the one in
> > > > > > > > > > > > > > Linux kernel drivers/of/address.c, and the Linux 
> > > > > > > > > > > > > > one added a quirk
> > > > > > > > > > > > > > for Apple Macs that don't have the  
> > > > > > > > > > > > > > property in the parent
> > > > > > > > > > > > > > node. Since U-Boot does not support Apple Macs, 
> > > > > > > > > > > > > > remove the comment
> > > > > > > > > > > > > > block and adhere to the spec to abort the 
> > > > > > > > > > > > > > translation.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Signed-off-by: Bin Meng 
> > > > > > > > > > > > > > ---
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >  drivers/core/of_addr.c | 24 
> > > > > > > > > > > > > > ++--
> > > > > > > > > > > > > >  1 file changed, 6 insertions(+), 18 deletions(-)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Reviewed-by: Simon Glass 
> > > > > > > > > > > >
> > > > > > > > > > > > Unfortunately this seems to cause a test failure for
> > > > > > > > > > > > ut_dm_fdt_translation. Can you please take a look?
> > > > > > > > > > >
> > > > > > > > > > > It seems the no "ranges" property was intentionally 
> > > > > > > > > > > removed by the
> > > > > > > > > > > following commit:
> > > > > > > > > > >
> > > > > > > > > > > commit d64b9cdcd475eb7f07b49741ded87e24dae4a5fc
> > > > > > > > > > > Author: Dario Binacchi 
> > > > > > > > > > > Date:   Wed Dec 30 00:16:21 2020 +0100
> > > > > > > > > > >
> > > > > > > > > > > fdt: translate address if #size-cells = <0>
> > > > > > > > > > >
> > > > > > > > > > > The __of_translate_address routine translates an 
> > > > > > > > > > > address from the
> > > > > > > > > > > device tree into a CPU physical address. A note in 
> > > > > > > > > > > the description of
> > > > > > > > > > > the routine explains that the crossing of any level 
> > > > > > > > > > > with
> > > > > > > > > > > since inherited from IBM. This does not happen for 
> > > > > > > > > > > Texas Instruments, or
> > > > > > > > > > > at least for the beaglebone device tree. Without this 
> > > > > > > > > > > patch, in fact,
> > > > > > > > > > > the translation into physical addresses of the 
> > > > > > > > > > > registers contained in the
> > > > > > > > > > > am33xx-clocks.dtsi nodes would not be possible. They 
> > > > > > > > > > > all have a parent
> > > > > > > > > > > with #size-cells = <0>.
> > > > > > > > > > >
> > > > > > > > > > > It looks the commit was needed for beaglebone board.
> > > > > > > > > > >
> > > > > > > > > > > Dario, could you please comment on why U-Boot needs to 
> > > > > > > > > > > done like this,
> > > > > > > > > > > while Linux kernel has this check? Is the beaglebone 
> > > > > > > > > > > board not working
> > > > > > > > > > > in Linux?
> > > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Beaglebone is working in Linux, but I think Linux walks the 
> > > > > > > > > device tree less
> > > > > > > > > fully than u-boot.
> > > > > > > > > I was surprised by the address translation error when 
> > > > > > > > > traversing nodes with
> > > > > > > > > size cells 0. And for this reason I added the 

Re: SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Sean Anderson]

On 3/23/21 12:54 PM, Manuel Luís Reis wrote:

Hi again,


There are timers on the board. How come it used to work, before the
commit that breaks it ?

I understand that nobody registers a driver in the UCLASS_TIMER , but
why was this enforced? and if this enforcement breaks our board, we can
either:
1/ stop the enforcement
2/ comply

Either way, I think we have to see how we can get one timer to register
itself as an UCLASS_TIMER


You can also track down the early call to get_ticks. Whatever is doing
it probably doesn't need to, considering that before this patch it was
getting back garbage.

--Sean



I understand.


This timer is a new hardware timer which is not present in the sama5d3 SoC.

Sama5d3 should have old PIT timers, (programmable interrupt timer)
and most likely that code has not been converted to DM (UCLASSes)

One possible approach is to convert specific old PIT code to comply with
DM requirements (or if that code is already available, we have to
use/enable it ).

I add Claudiu in the mail thread, as he is more familiar with PIT and
timers than I am, and maybe he has some opinion related to this issue.


Thanks for clarifying this for me.

Look forward to hearing from Claudiu.

Cheers,




On Tue, 23 Mar 2021 at 16:26,  wrote:


On 3/23/21 6:08 PM, Manuel Luís Reis wrote:

Hi again,

FYI: As a small test I commented out the change you mentioned but got
the same mistake. Begs to wonder if it is
   related to the issue at hand.

Going back to
http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html

Sean Anderson asks:

"So nothing here is probed, but additionally nothing has UCLASS_TIMER.
What do you expect the timer device to be?"


There are timers on the board. How come it used to work, before the
commit that breaks it ?

I understand that nobody registers a driver in the UCLASS_TIMER , but
why was this enforced? and if this enforcement breaks our board, we can
either:
1/ stop the enforcement
2/ comply

Either way, I think we have to see how we can get one timer to register
itself as an UCLASS_TIMER




Is the timer missing for SAMA5D3 board? I cannot find it in
/drivers/timer, other than mchp-pit64b-timer.c, which doesn't
seem to be used ins this particular board as far as I could tell.


This timer is a new hardware timer which is not present in the sama5d3 SoC.

Sama5d3 should have old PIT timers, (programmable interrupt timer)
and most likely that code has not been converted to DM (UCLASSes)

One possible approach is to convert specific old PIT code to comply with
DM requirements (or if that code is already available, we have to
use/enable it ).

I add Claudiu in the mail thread, as he is more familiar with PIT and
timers than I am, and maybe he has some opinion related to this issue.

Eugen



Any thoughts on how to fix this? Anything I can do to help?

Cheers


On Tue, 23 Mar 2021 at 13:20, Manuel Luís Reis mailto:mluis.r...@gmail.com>> wrote:


  > The change may be dedicated to sama5d2 devices. Could you have a look
  > please if your device (sama5d3) needs this change as well ? I
 mean, does
  > doing something similar for sama5d3 fixes your problem ?

 I  am not quite sure how to check what you suggest to be honest.

 The commit you've sent seems to be board independent ->
 mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards,
 sama5d3 inclusive?
 I don't see where else I could make a change like that.

 Thanks for your patience.



 On Tue, 23 Mar 2021 at 11:38, mailto:eugen.hris...@microchip.com>> wrote:

 On 3/23/21 1:28 PM, Manuel Luís Reis wrote:

  > Hi,
  >
  > Thanks for your reply.
  >
  >  > Can you please check if this commit is in your tree, or,
 if the same has
  >  > to be applied in your case (sama5d3), to make it work ?
  >
  > I've got that change in my tree, but I'm still getting the
 error message.

 The change may be dedicated to sama5d2 devices. Could you have a
 look
 please if your device (sama5d3) needs this change as well ? I
 mean, does
 doing something similar for sama5d3 fixes your problem ?

 Thanks,
 Eugen

  >
  > I am using up-to-date mainline U-Boot.
  >
  > Thanks
  >
  >
  >
  > On Tue, 23 Mar 2021 at 11:14, mailto:eugen.hris...@microchip.com>
  > >> wrote:
  >
  > Hi,
  >
  > Can you please check if this commit is in your tree, or,
 if the same
  > has
  > to be applied in your case (sama5d3), to make it work ?
  >
  > Here is the commit :
  >
  >
  >
 

Re: [RFC PATCH v2 2/2] board: sifive: unmatched: clear feature disable CSR

[Sean Anderson]

On 3/23/21 4:35 AM, Green Wan wrote:

Clear feature disable CSR to turn on all features of hart. The detail
is specified at section, 'SiFive Feature Disable CSR', in user manual

https://sifive.cdn.prismic.io/sifive/aee0dd4c-d156-496e-a6c4-db0cf54bbe68_sifive_U74MC_rtl_full_20G1.03.00_manual.pdf

Signed-off-by: Green Wan 
---
  board/sifive/unmatched/spl.c | 13 +
  1 file changed, 13 insertions(+)

diff --git a/board/sifive/unmatched/spl.c b/board/sifive/unmatched/spl.c
index 5e1333b09a..d09d129dc9 100644
--- a/board/sifive/unmatched/spl.c
+++ b/board/sifive/unmatched/spl.c
@@ -22,6 +22,19 @@
  #define MODE_SELECT_SD0xb
  #define MODE_SELECT_MASK  GENMASK(3, 0)
  
+void riscv_hart_early_init(void)

+{
+#if CONFIG_IS_ENABLED(RISCV_MMODE)


use

if (CONFIG_IS_ENABLED(RISCV_MMODE)

please


+   /*
+* Feature Disable CSR
+*
+* Clear feature disable CSR to '0' to turn on all features for
+* each core. This operatioin must be in m-mode.


nit: operation


+*/
+   asm volatile ("csrwi 0x7c1, 0");


Perhaps

#define CSR_U74_FEATURE_DISABLE 0x7c1
csr_write(CSR_U74_FEATURE_DISABLE, 0);


+#endif
+}
+
  int spl_board_init_f(void)
  {
int ret;

Re: [RFC PATCH v2 1/2] arch: riscv: cpu: Add callback to init each core

[Sean Anderson]

On 3/23/21 4:35 AM, Green Wan wrote:

Add a callback riscv_hart_early_init() to ./arch/riscv/cpu/start.S to
allow different riscv hart perform setup code for each hart as early
as possible. Since all the harts enter the calback, they must be able


nit: callback


to run the same setup.

Signed-off-by: Green Wan 
---
  arch/riscv/cpu/start.S | 5 +
  arch/riscv/lib/spl.c   | 4 
  2 files changed, 9 insertions(+)

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 8589509e01..5c7d4da9e2 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -117,6 +117,11 @@ call_board_init_f_0:
mv  sp, a0
  #endif
  
+#if CONFIG_IS_ENABLED(RISCV_MMODE)

+call_riscv_hart_early_init:
+   jal riscv_hart_early_init
+#endif
+
  #ifndef CONFIG_XIP
/*
 * Pick hart to initialize global data and run U-Boot. The other harts
diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c
index 8baee07bea..e5b1affbfc 100644
--- a/arch/riscv/lib/spl.c
+++ b/arch/riscv/lib/spl.c
@@ -14,6 +14,10 @@
  
  DECLARE_GLOBAL_DATA_PTR;
  
+__weak void riscv_hart_early_init(void)

+{
+}
+


Can you add some documentation for what the purpose of this function is
and what the limitations are? In particular, this function cannot access
gd.

--Sean


  __weak int spl_board_init_f(void)
  {
return 0;

[PATCH v2] sunxi: add fdtoverlay_addr_r environment variable

[Jernej Skrabec]

Commit 69076dff2284 ("cmd: pxe: add support for FDT overlays") added
support for loading DT overlay files to PXE boot. However, it needs
additional environment variable which points to memory location which
can be used to temporary store overlay data.

Add it and in the process unify alignment using spaces and fix comment.

Reviewed-by: Andre Przywara 
Signed-off-by: Jernej Skrabec 
---

Changes from v1:
- added r-b tag
- fixed comment

 include/configs/sunxi-common.h | 49 ++
 1 file changed, 26 insertions(+), 23 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index ded5aea551d3..3e1dc47c9c55 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -62,7 +62,7 @@
 #define SDRAM_OFFSET(x) 0x2##x
 #define CONFIG_SYS_SDRAM_BASE  0x2000
 #define CONFIG_SYS_LOAD_ADDR   0x2200 /* default load address */
-/* Note SPL_STACK_R_ADDR is set through Kconfig, we include it here 
+/* Note SPL_STACK_R_ADDR is set through Kconfig, we include it here
  * since it needs to fit in with the other values. By also #defining it
  * we get warnings if the Kconfig value mismatches. */
 #define CONFIG_SPL_STACK_R_ADDR0x2fe0
@@ -72,7 +72,7 @@
 #define CONFIG_SYS_SDRAM_BASE  0x4000
 #define CONFIG_SYS_LOAD_ADDR   0x4200 /* default load address */
 /* V3s do not have enough memory to place code at 0x4a00 */
-/* Note SPL_STACK_R_ADDR is set through Kconfig, we include it here 
+/* Note SPL_STACK_R_ADDR is set through Kconfig, we include it here
  * since it needs to fit in with the other values. By also #defining it
  * we get warnings if the Kconfig value mismatches. */
 #define CONFIG_SPL_STACK_R_ADDR0x4fe0
@@ -257,40 +257,42 @@ extern int soft_i2c_gpio_scl;
  * There is no compression for arm64 kernels (yet), so leave some space
  * for really big kernels, say 256MB for now.
  * Scripts, PXE and DTBs should go afterwards, leaving the rest for the initrd.
- * Align the initrd to a 2MB page.
  */
-#define BOOTM_SIZE __stringify(0xa00)
-#define KERNEL_ADDR_R  __stringify(SDRAM_OFFSET(008))
-#define FDT_ADDR_R __stringify(SDRAM_OFFSET(FA0))
-#define SCRIPT_ADDR_R  __stringify(SDRAM_OFFSET(FC0))
-#define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(FD0))
-#define RAMDISK_ADDR_R __stringify(SDRAM_OFFSET(FE0))
+#define BOOTM_SIZE__stringify(0xa00)
+#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(008))
+#define FDT_ADDR_R__stringify(SDRAM_OFFSET(FA0))
+#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(FC0))
+#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(FD0))
+#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(FE0))
+#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(FF0))
 
 #else
 /*
  * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc.
  * 32M uncompressed kernel, 16M compressed kernel, 1M fdt,
- * 1M script, 1M pxe and the ramdisk at the end.
+ * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end.
  */
 #ifndef CONFIG_MACH_SUN8I_V3S
-#define BOOTM_SIZE __stringify(0xa00)
-#define KERNEL_ADDR_R  __stringify(SDRAM_OFFSET(200))
-#define FDT_ADDR_R __stringify(SDRAM_OFFSET(300))
-#define SCRIPT_ADDR_R  __stringify(SDRAM_OFFSET(310))
-#define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(320))
-#define RAMDISK_ADDR_R __stringify(SDRAM_OFFSET(330))
+#define BOOTM_SIZE__stringify(0xa00)
+#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(200))
+#define FDT_ADDR_R__stringify(SDRAM_OFFSET(300))
+#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(310))
+#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(320))
+#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(330))
+#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(340))
 #else
 /*
  * 64M RAM minus 2MB heap + 16MB for u-boot, stack, fb, etc.
  * 16M uncompressed kernel, 8M compressed kernel, 1M fdt,
- * 1M script, 1M pxe and the ramdisk at the end.
+ * 1M script, 1M pxe, 1M dt overlay and the ramdisk at the end.
  */
-#define BOOTM_SIZE __stringify(0x2e0)
-#define KERNEL_ADDR_R  __stringify(SDRAM_OFFSET(100))
-#define FDT_ADDR_R __stringify(SDRAM_OFFSET(180))
-#define SCRIPT_ADDR_R  __stringify(SDRAM_OFFSET(190))
-#define PXEFILE_ADDR_R __stringify(SDRAM_OFFSET(1A0))
-#define RAMDISK_ADDR_R __stringify(SDRAM_OFFSET(1B0))
+#define BOOTM_SIZE__stringify(0x2e0)
+#define KERNEL_ADDR_R __stringify(SDRAM_OFFSET(100))
+#define FDT_ADDR_R__stringify(SDRAM_OFFSET(180))
+#define SCRIPT_ADDR_R __stringify(SDRAM_OFFSET(190))
+#define PXEFILE_ADDR_R__stringify(SDRAM_OFFSET(1A0))
+#define FDTOVERLAY_ADDR_R __stringify(SDRAM_OFFSET(1B0))
+#define RAMDISK_ADDR_R__stringify(SDRAM_OFFSET(1C0))
 #endif
 #endif
 
@@ -300,6 +302,7 @@ extern int 

Re: SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Eugen.Hristev]

On 3/23/21 6:08 PM, Manuel Luís Reis wrote:
> Hi again,
> 
> FYI: As a small test I commented out the change you mentioned but got 
> the same mistake. Begs to wonder if it is
>   related to the issue at hand.
> 
> Going back to 
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
>  
> 
> Sean Anderson asks:
> 
> "So nothing here is probed, but additionally nothing has UCLASS_TIMER.
> What do you expect the timer device to be?"

There are timers on the board. How come it used to work, before the 
commit that breaks it ?

I understand that nobody registers a driver in the UCLASS_TIMER , but 
why was this enforced? and if this enforcement breaks our board, we can 
either:
1/ stop the enforcement
2/ comply

Either way, I think we have to see how we can get one timer to register 
itself as an UCLASS_TIMER


> 
> Is the timer missing for SAMA5D3 board? I cannot find it in 
> /drivers/timer, other than mchp-pit64b-timer.c, which doesn't
> seem to be used ins this particular board as far as I could tell.

This timer is a new hardware timer which is not present in the sama5d3 SoC.

Sama5d3 should have old PIT timers, (programmable interrupt timer)
and most likely that code has not been converted to DM (UCLASSes)

One possible approach is to convert specific old PIT code to comply with 
DM requirements (or if that code is already available, we have to 
use/enable it ).

I add Claudiu in the mail thread, as he is more familiar with PIT and 
timers than I am, and maybe he has some opinion related to this issue.

Eugen

> 
> Any thoughts on how to fix this? Anything I can do to help?
> 
> Cheers
> 
> 
> On Tue, 23 Mar 2021 at 13:20, Manuel Luís Reis  > wrote:
> 
> 
>  > The change may be dedicated to sama5d2 devices. Could you have a look
>  > please if your device (sama5d3) needs this change as well ? I
> mean, does
>  > doing something similar for sama5d3 fixes your problem ?
> 
> I  am not quite sure how to check what you suggest to be honest.
> 
> The commit you've sent seems to be board independent ->
> mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards,
> sama5d3 inclusive?
> I don't see where else I could make a change like that.
> 
> Thanks for your patience.
> 
> 
> 
> On Tue, 23 Mar 2021 at 11:38,  > wrote:
> 
> On 3/23/21 1:28 PM, Manuel Luís Reis wrote:
> 
>  > Hi,
>  >
>  > Thanks for your reply.
>  >
>  >  > Can you please check if this commit is in your tree, or,
> if the same has
>  >  > to be applied in your case (sama5d3), to make it work ?
>  >
>  > I've got that change in my tree, but I'm still getting the
> error message.
> 
> The change may be dedicated to sama5d2 devices. Could you have a
> look
> please if your device (sama5d3) needs this change as well ? I
> mean, does
> doing something similar for sama5d3 fixes your problem ?
> 
> Thanks,
> Eugen
> 
>  >
>  > I am using up-to-date mainline U-Boot.
>  >
>  > Thanks
>  >
>  >
>  >
>  > On Tue, 23 Mar 2021 at 11:14,  
>  >  >> wrote:
>  >
>  >     Hi,
>  >
>  >     Can you please check if this commit is in your tree, or,
> if the same
>  >     has
>  >     to be applied in your case (sama5d3), to make it work ?
>  >
>  >     Here is the commit :
>  >
>  >
>  >
> 
> https://source.denx.de/u-boot/custodians/u-boot-atmel/-/commit/786f35b619ddbfb88e4532d11a56413f5dab473f
>  >
>  >
>  >
>  >     On 3/23/21 1:06 PM, Manuel Luís Reis wrote:
>  >      > Hello,
>  >      >
>  >      > I've been having issues with SPL booting in the
> SAMA5D3 Xplained
>  >     board
>  >      > getting the following error, with up-to-date mainline
> U-boot and
>  >      > sama5d3_xplained _mmc_defconfig:
>  >      >
>  >      > ---
>  >      > RomBOOT
>  >      >
>  >      > 
>  >      > Could not initialize timer (err -19)
>  >      > .
>  >      > ---
>  >      >
>  >      > I could trace back the error to commit 4b2be78.
>  >      >
>  >      > This topic has been raised before on
>  >      >
>  >
> 
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
>  >      > Tried the suggestions there with the same 

[PATCH] efi_loader: Add a locality event on the eventlog

[Ilias Apalodimas]

We are currently not adding any events on the eventlog apart from the
SpecID event.  The locality event is mandatory and must be logged before
extending PCR[0].

The spec description is
"The Startup Locality event should be placed in the log before any event
which extends PCR[0]. This allows software which needs to parse the TCG 
Event Log to initialize its internal PCR[0] state correctly".

So let's add a locality even during the EventLog creation, right after
our SpecID event.

Signed-off-by: Ilias Apalodimas 
---
 lib/efi_loader/efi_tcg2.c | 50 +--
 1 file changed, 37 insertions(+), 13 deletions(-)

diff --git a/lib/efi_loader/efi_tcg2.c b/lib/efi_loader/efi_tcg2.c
index 797d6eb134f6..a89dadcb22e9 100644
--- a/lib/efi_loader/efi_tcg2.c
+++ b/lib/efi_loader/efi_tcg2.c
@@ -513,7 +513,7 @@ static efi_status_t tcg2_create_digest(const u8 *input, u32 
length,
sha1_context ctx;
sha256_context ctx_256;
sha512_context ctx_512;
-   u8 final[TPM2_ALG_SHA512];
+   u8 final[TPM2_ALG_SHA512] = { 0 };
efi_status_t ret;
u32 active;
int i;
@@ -530,27 +530,35 @@ static efi_status_t tcg2_create_digest(const u8 *input, 
u32 length,
continue;
switch (hash_alg) {
case TPM2_ALG_SHA1:
-   sha1_starts();
-   sha1_update(, input, length);
-   sha1_finish(, final);
+   if (input) {
+   sha1_starts();
+   sha1_update(, input, length);
+   sha1_finish(, final);
+   }
digest_list->count++;
break;
case TPM2_ALG_SHA256:
-   sha256_starts(_256);
-   sha256_update(_256, input, length);
-   sha256_finish(_256, final);
+   if (input) {
+   sha256_starts(_256);
+   sha256_update(_256, input, length);
+   sha256_finish(_256, final);
+   }
digest_list->count++;
break;
case TPM2_ALG_SHA384:
-   sha384_starts(_512);
-   sha384_update(_512, input, length);
-   sha384_finish(_512, final);
+   if (input) {
+   sha384_starts(_512);
+   sha384_update(_512, input, length);
+   sha384_finish(_512, final);
+   }
digest_list->count++;
break;
case TPM2_ALG_SHA512:
-   sha512_starts(_512);
-   sha512_update(_512, input, length);
-   sha512_finish(_512, final);
+   if (input) {
+   sha512_starts(_512);
+   sha512_update(_512, input, length);
+   sha512_finish(_512, final);
+   }
digest_list->count++;
break;
default:
@@ -1004,6 +1012,8 @@ static efi_status_t efi_init_event_log(void)
struct udevice *dev;
size_t spec_event_size;
efi_status_t ret;
+   struct tcg_efi_startup_locality_event locality_event;
+   struct tpml_digest_values digest_list;
 
ret = platform_get_tpm2_device();
if (ret != EFI_SUCCESS)
@@ -1040,6 +1050,20 @@ static efi_status_t efi_init_event_log(void)
event_log.pos = spec_event_size + sizeof(*event_header);
event_log.last_event_size = event_log.pos;
 
+   /* Add a locality event before PCR[0] changes */
+   memcpy(locality_event.signature, TCG_EFI_STARTUP_LOCALITY_SIGNATURE,
+  sizeof(locality_event.signature));
+   /*
+* Locality 0 is designated as the default Locality. This is usually
+* the platform’s boot firmware, OS and applications.
+*/
+   locality_event.startup_locality = 0;
+   ret = tcg2_create_digest(NULL, 0, _list);
+   ret = tcg2_agile_log_append(0, EV_NO_ACTION, _list,
+   sizeof(locality_event), (u8 
*)_event);
+   if (ret != EFI_SUCCESS)
+   goto out;
+
ret = create_final_event();
 
 out:
-- 
2.31.0

[PATCH v3 2/2] test: unit test for longjmp

[Heinrich Schuchardt]

Provide a unit test for the longjmp() library function

Signed-off-by: Heinrich Schuchardt 
Acked-by: Sean Anderson 
---
v3:
check variable on stack
v2:
no change
---
 test/lib/Makefile  |  1 +
 test/lib/longjmp.c | 73 ++
 2 files changed, 74 insertions(+)
 create mode 100644 test/lib/longjmp.c

diff --git a/test/lib/Makefile b/test/lib/Makefile
index 97c11e35a8..a30f615aa9 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_EFI_LOADER) += efi_device_path.o
 obj-$(CONFIG_EFI_SECURE_BOOT) += efi_image_region.o
 obj-y += hexdump.o
 obj-y += lmb.o
+obj-y += longjmp.o
 obj-$(CONFIG_CONSOLE_RECORD) += test_print.o
 obj-$(CONFIG_SSCANF) += sscanf.o
 obj-y += string.o
diff --git a/test/lib/longjmp.c b/test/lib/longjmp.c
new file mode 100644
index 00..201367a5a3
--- /dev/null
+++ b/test/lib/longjmp.c
@@ -0,0 +1,73 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Test setjmp(), longjmp()
+ *
+ * Copyright (c) 2021, Heinrich Schuchardt 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+struct test_jmp_buf {
+   jmp_buf env;
+   int val;
+};
+
+/**
+ * test_longjmp() - test longjmp function
+ *
+ * @i is passed to longjmp.
+ * @i << 8 is set in the environment structure.
+ *
+ * @env:   environment
+ * @i: value passed to longjmp()
+ */
+static noinline void test_longjmp(struct test_jmp_buf *env, int i)
+{
+   env->val = i << 8;
+   longjmp(env->env, i);
+}
+
+/**
+ * test_setjmp() - test setjmp function
+ *
+ * setjmp() will return the value @i passed to longjmp() if @i is non-zero.
+ * For @i == 0 we expect return value 1.
+ *
+ * @i << 8 will be set by test_longjmp in the environment structure.
+ * This value can be used to check that the stack frame is restored.
+ *
+ * We return the XORed values to allow simply check both at once.
+ *
+ * @i: value passed to longjmp()
+ * Return: values return by longjmp()
+ */
+static int test_setjmp(int i)
+{
+   struct test_jmp_buf env;
+   int ret;
+
+   env.val = -1;
+   ret = setjmp(env.env);
+   if (ret)
+   return ret ^ env.val;
+   test_longjmp(, i);
+   /* We should not arrive here */
+   return 0x1000;
+}
+
+static int lib_test_longjmp(struct unit_test_state *uts)
+{
+   int i;
+
+   for (i = -3; i < 0; ++i)
+   ut_asserteq(i ^ (i << 8), test_setjmp(i));
+   ut_asserteq(1, test_setjmp(0));
+   for (i = 1; i < 4; ++i)
+   ut_asserteq(i ^ (i << 8), test_setjmp(i));
+   return 0;
+}
+LIB_TEST(lib_test_longjmp, 0);
--
2.30.2

[PATCH v3 0/2] riscv: simplify longjmp

[Heinrich Schuchardt]

The implementation of longjmp() is simplified.
A unit test for longjmp() is provided.

For testing use

CONFIG_UNIT_TEST=y
CONFIG_CMD_SETEXPR=n

and execute

ut lib

v3:
improve unit test
v2:
correct title of patch 1

Heinrich Schuchardt (2):
  riscv: simplify longjmp
  test: unit test for longjmp

 arch/riscv/lib/setjmp.S |  8 ++---
 test/lib/Makefile   |  1 +
 test/lib/longjmp.c  | 73 +
 3 files changed, 76 insertions(+), 6 deletions(-)
 create mode 100644 test/lib/longjmp.c

--
2.30.2

[PATCH v3 1/2] riscv: simplify longjmp

[Heinrich Schuchardt]

The value returned by setjmp must be nonzero. If zero is passed as
parameter it must be replaced by 1.

This patch reduces the code size a bit.

Signed-off-by: Heinrich Schuchardt 
Reviewed-by: Sean Anderson 
Reviewed-by: Leo Yu-Chi Liang 
---
v3:
no change
v2:
correct typo in title
---
 arch/riscv/lib/setjmp.S | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/arch/riscv/lib/setjmp.S b/arch/riscv/lib/setjmp.S
index 72bc9241f6..99d6195827 100644
--- a/arch/riscv/lib/setjmp.S
+++ b/arch/riscv/lib/setjmp.S
@@ -54,12 +54,8 @@ ENTRY(longjmp)
LOAD_IDX(sp, 13)

/* Move the return value in place, but return 1 if passed 0. */
-   beq a1, zero, longjmp_1
-   mv a0, a1
-   ret
-
-   longjmp_1:
-   li a0, 1
+   seqz a0, a1
+   add a0, a0, a1
ret
 ENDPROC(longjmp)
 .popsection
--
2.30.2

Re: [PATCH 1/2] of: addr: Abort address translation for parent nodes missing 'ranges'

[Dario Binacchi]

Hi Bin,

> Il 22/03/2021 02:25 Bin Meng  ha scritto:
> 
>  
> Hi Dario,
> 
> On Sun, Mar 21, 2021 at 11:19 PM Dario Binacchi  wrote:
> >
> > Hi Tom,
> >
> > > Il 18/03/2021 20:51 Tom Rini  ha scritto:
> > >
> > >
> > > On Thu, Mar 18, 2021 at 08:27:49AM +0100, Dario Binacchi wrote:
> > > > Hi Bin,
> > > >
> > > > > Il 17/03/2021 02:26 Bin Meng  ha scritto:
> > > > >
> > > > >
> > > > > Hi Dario,
> > > > >
> > > > > On Wed, Mar 17, 2021 at 4:57 AM Dario Binacchi  
> > > > > wrote:
> > > > > >
> > > > > > Hi Bin,
> > > > > >
> > > > > > > Il 16/03/2021 02:28 Bin Meng  ha scritto:
> > > > > > >
> > > > > > >
> > > > > > > Hi Dario,
> > > > > > >
> > > > > > > On Tue, Mar 16, 2021 at 6:49 AM Dario Binacchi 
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > >
> > > > > > > > > Il 15/03/2021 19:23 Simon Glass  ha 
> > > > > > > > > scritto:
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > +Tom Rini too
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > On Tue, 16 Mar 2021 at 03:48, Bin Meng  
> > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > +Dario Binacchi
> > > > > > > > > >
> > > > > > > > > > On Mon, Mar 15, 2021 at 3:11 PM Simon Glass 
> > > > > > > > > >  wrote:
> > > > > > > > > > >
> > > > > > > > > > > Hi Bin,
> > > > > > > > > > >
> > > > > > > > > > > On Wed, 3 Mar 2021 at 14:54, Simon Glass 
> > > > > > > > > > >  wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > On Fri, 26 Feb 2021 at 00:36, Bin Meng 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > The implementation of of_translate_one() was taken 
> > > > > > > > > > > > > from the one in
> > > > > > > > > > > > > Linux kernel drivers/of/address.c, and the Linux one 
> > > > > > > > > > > > > added a quirk
> > > > > > > > > > > > > for Apple Macs that don't have the  property 
> > > > > > > > > > > > > in the parent
> > > > > > > > > > > > > node. Since U-Boot does not support Apple Macs, 
> > > > > > > > > > > > > remove the comment
> > > > > > > > > > > > > block and adhere to the spec to abort the translation.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Signed-off-by: Bin Meng 
> > > > > > > > > > > > > ---
> > > > > > > > > > > > >
> > > > > > > > > > > > >  drivers/core/of_addr.c | 24 ++--
> > > > > > > > > > > > >  1 file changed, 6 insertions(+), 18 deletions(-)
> > > > > > > > > > > >
> > > > > > > > > > > > Reviewed-by: Simon Glass 
> > > > > > > > > > >
> > > > > > > > > > > Unfortunately this seems to cause a test failure for
> > > > > > > > > > > ut_dm_fdt_translation. Can you please take a look?
> > > > > > > > > >
> > > > > > > > > > It seems the no "ranges" property was intentionally removed 
> > > > > > > > > > by the
> > > > > > > > > > following commit:
> > > > > > > > > >
> > > > > > > > > > commit d64b9cdcd475eb7f07b49741ded87e24dae4a5fc
> > > > > > > > > > Author: Dario Binacchi 
> > > > > > > > > > Date:   Wed Dec 30 00:16:21 2020 +0100
> > > > > > > > > >
> > > > > > > > > > fdt: translate address if #size-cells = <0>
> > > > > > > > > >
> > > > > > > > > > The __of_translate_address routine translates an 
> > > > > > > > > > address from the
> > > > > > > > > > device tree into a CPU physical address. A note in the 
> > > > > > > > > > description of
> > > > > > > > > > the routine explains that the crossing of any level with
> > > > > > > > > > since inherited from IBM. This does not happen for 
> > > > > > > > > > Texas Instruments, or
> > > > > > > > > > at least for the beaglebone device tree. Without this 
> > > > > > > > > > patch, in fact,
> > > > > > > > > > the translation into physical addresses of the 
> > > > > > > > > > registers contained in the
> > > > > > > > > > am33xx-clocks.dtsi nodes would not be possible. They 
> > > > > > > > > > all have a parent
> > > > > > > > > > with #size-cells = <0>.
> > > > > > > > > >
> > > > > > > > > > It looks the commit was needed for beaglebone board.
> > > > > > > > > >
> > > > > > > > > > Dario, could you please comment on why U-Boot needs to done 
> > > > > > > > > > like this,
> > > > > > > > > > while Linux kernel has this check? Is the beaglebone board 
> > > > > > > > > > not working
> > > > > > > > > > in Linux?
> > > > > > > > > >
> > > > > > > >
> > > > > > > > Beaglebone is working in Linux, but I think Linux walks the 
> > > > > > > > device tree less
> > > > > > > > fully than u-boot.
> > > > > > > > I was surprised by the address translation error when 
> > > > > > > > traversing nodes with
> > > > > > > > size cells 0. And for this reason I added the 
> > > > > > > > CONFIG_OF_TRANSLATE_ZERO_SIZE_CELLS
> > > > > > > > symbol to fix the issue, not enabled by default, thus making 
> > > > > > > > the change backwards
> > > > > > > > compatible.
> > > > > > >
> > > > > > > Could you please prepare a patch against upstream Linux kernel, so
> > > > > > > that U-Boot can be in sync with it?
> > > > > >
> > > > > > With pleasure. But 

Re: [PATCH v2] spl: Add callback for preprocessing loaded FIT header before parsing

[Philippe REYNES]

Hi Simon and Alex,

Le 23/03/2021 à 01:56, Simon Glass a écrit :

Hi Alex,

On Tue, 23 Mar 2021 at 04:12, Alex G.  wrote:

On 3/22/21 9:27 AM, Philippe REYNES wrote:

Hi all,


Le 11/03/2021 à 00:10, Alex G a écrit :

[snip]

I reach the same issue, my customers are also worried with the actual
signature check scheme on u-boot.
The fit data/node are parsed before being checked : data should be used
only after being checked, not before.
The code become quite complex for a signature, and the more complex the
code is more risk to have/introduce a bug or security issue.

[snip]


The reason I used a weak function was to mirror the already
upstreamed board_spl_fit_post_load(),

I see why you'd think it was a good idea. board_spl_fit_pre_load()
sneaks in a dependency on arch-specific code (CONFIG_IMX_HAB). I don't
really like the way it's implemented, and I don't know if it would
work with SPL_LOAD_FIT_FULL or bootm.


As I reach the same issue, I was also thinking strongly about adding a
"hook" before the fit image is launched/analyzed. In my mind this "pre
load" function should be able to do some check/update to the fit image,
but also modify the beginning of the fit image (to remove a header for
example). Such function/feature may allow to:
- check a signature for the full fit (without parsing the node)
- cipher the full fit (even the node)
- compress the full fit
- probably that users will find a lot of others ideas .

I think that this feature pre load should be implemented in spl and
bootm command.

I have understood the feedback about a useful implementation/usage of
pre_load.
I propose to sent an example soon (probably based on signature check).

So "what" you want to do is verify untrusted metadata before using it.
That's a very logical and reasonable thing to do.

"How" you are trying to do this is by
   (1) adding a weak function
   (2) allowing each board to have a completely different implementation

Those are two terrible ideas.

I agree that there is a deficiency in the way FIT images are signed. Can
we stick the signature between the fdt_header and before dt_struct?

That seems like a reasonable idea to me. Even better might be to have
it completely separate, e.g. before the FIT starts, so no parsing at
all is needed?



That's my idea, a header with only the minimum information (like fit 
size and signature).
The information about the signature (hash, algo, padding, public key, 
...) may be stored
in the u-boot device tree. So u-boot won't parse the fit image, only 
compute the hash

to check the signature.



Also, which signature? FIT supports multiple signatures which can be
added at different times. Perhaps this could be for a base signature,
enough to get through to verifying the 'real' signature.



I was thinking that the signature information could be stored in the 
u-boot device tree
(or hardcoded in the u-boot configuration). The idea is to have a very 
simple header.
I also think that this signature may be used with the signature in the 
fit.  It is two

options, so users may eanble both options.

As we agree on the principle, I will sent a RFC asap.


Regards,
Simon



Regards,
Philippe

Re: SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Manuel Luís Reis]

Hi again,

> There are timers on the board. How come it used to work, before the
> commit that breaks it ?
>
> I understand that nobody registers a driver in the UCLASS_TIMER , but
> why was this enforced? and if this enforcement breaks our board, we can
> either:
> 1/ stop the enforcement
> 2/ comply
>
> Either way, I think we have to see how we can get one timer to register
> itself as an UCLASS_TIMER

I understand.

> This timer is a new hardware timer which is not present in the sama5d3 SoC.
>
> Sama5d3 should have old PIT timers, (programmable interrupt timer)
> and most likely that code has not been converted to DM (UCLASSes)
>
> One possible approach is to convert specific old PIT code to comply with
> DM requirements (or if that code is already available, we have to
> use/enable it ).
>
> I add Claudiu in the mail thread, as he is more familiar with PIT and
> timers than I am, and maybe he has some opinion related to this issue.

Thanks for clarifying this for me.

Look forward to hearing from Claudiu.

Cheers,




On Tue, 23 Mar 2021 at 16:26,  wrote:
>
> On 3/23/21 6:08 PM, Manuel Luís Reis wrote:
> > Hi again,
> >
> > FYI: As a small test I commented out the change you mentioned but got
> > the same mistake. Begs to wonder if it is
> >   related to the issue at hand.
> >
> > Going back to
> > http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> >
> > Sean Anderson asks:
> >
> > "So nothing here is probed, but additionally nothing has UCLASS_TIMER.
> > What do you expect the timer device to be?"
>
> There are timers on the board. How come it used to work, before the
> commit that breaks it ?
>
> I understand that nobody registers a driver in the UCLASS_TIMER , but
> why was this enforced? and if this enforcement breaks our board, we can
> either:
> 1/ stop the enforcement
> 2/ comply
>
> Either way, I think we have to see how we can get one timer to register
> itself as an UCLASS_TIMER
>
>
> >
> > Is the timer missing for SAMA5D3 board? I cannot find it in
> > /drivers/timer, other than mchp-pit64b-timer.c, which doesn't
> > seem to be used ins this particular board as far as I could tell.
>
> This timer is a new hardware timer which is not present in the sama5d3 SoC.
>
> Sama5d3 should have old PIT timers, (programmable interrupt timer)
> and most likely that code has not been converted to DM (UCLASSes)
>
> One possible approach is to convert specific old PIT code to comply with
> DM requirements (or if that code is already available, we have to
> use/enable it ).
>
> I add Claudiu in the mail thread, as he is more familiar with PIT and
> timers than I am, and maybe he has some opinion related to this issue.
>
> Eugen
>
> >
> > Any thoughts on how to fix this? Anything I can do to help?
> >
> > Cheers
> >
> >
> > On Tue, 23 Mar 2021 at 13:20, Manuel Luís Reis  > > wrote:
> >
> >
> >  > The change may be dedicated to sama5d2 devices. Could you have a look
> >  > please if your device (sama5d3) needs this change as well ? I
> > mean, does
> >  > doing something similar for sama5d3 fixes your problem ?
> >
> > I  am not quite sure how to check what you suggest to be honest.
> >
> > The commit you've sent seems to be board independent ->
> > mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards,
> > sama5d3 inclusive?
> > I don't see where else I could make a change like that.
> >
> > Thanks for your patience.
> >
> >
> >
> > On Tue, 23 Mar 2021 at 11:38,  > > wrote:
> >
> > On 3/23/21 1:28 PM, Manuel Luís Reis wrote:
> >
> >  > Hi,
> >  >
> >  > Thanks for your reply.
> >  >
> >  >  > Can you please check if this commit is in your tree, or,
> > if the same has
> >  >  > to be applied in your case (sama5d3), to make it work ?
> >  >
> >  > I've got that change in my tree, but I'm still getting the
> > error message.
> >
> > The change may be dedicated to sama5d2 devices. Could you have a
> > look
> > please if your device (sama5d3) needs this change as well ? I
> > mean, does
> > doing something similar for sama5d3 fixes your problem ?
> >
> > Thanks,
> > Eugen
> >
> >  >
> >  > I am using up-to-date mainline U-Boot.
> >  >
> >  > Thanks
> >  >
> >  >
> >  >
> >  > On Tue, 23 Mar 2021 at 11:14,  > 
> >  >  > >> wrote:
> >  >
> >  > Hi,
> >  >
> >  > Can you please check if this commit is in your tree, or,
> > if the same
> >  > has
> >  > to be applied in your case (sama5d3), to make it work ?
> >  >
> >  > 

Re: SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Manuel Luís Reis]

Hi again,

FYI: As a small test I commented out the change you mentioned but got the
same mistake. Begs to wonder if it is
 related to the issue at hand.

Going back to
http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html

Sean Anderson asks:

"So nothing here is probed, but additionally nothing has UCLASS_TIMER.
What do you expect the timer device to be?"

Is the timer missing for SAMA5D3 board? I cannot find it in /drivers/timer,
other than mchp-pit64b-timer.c, which doesn't
seem to be used ins this particular board as far as I could tell.

Any thoughts on how to fix this? Anything I can do to help?

Cheers


On Tue, 23 Mar 2021 at 13:20, Manuel Luís Reis  wrote:

>
> > The change may be dedicated to sama5d2 devices. Could you have a look
> > please if your device (sama5d3) needs this change as well ? I mean, does
> > doing something similar for sama5d3 fixes your problem ?
>
> I  am not quite sure how to check what you suggest to be honest.
>
> The commit you've sent seems to be board independent ->
> mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards, sama5d3
> inclusive?
> I don't see where else I could make a change like that.
>
> Thanks for your patience.
>
>
>
> On Tue, 23 Mar 2021 at 11:38,  wrote:
>
>> On 3/23/21 1:28 PM, Manuel Luís Reis wrote:
>>
>> > Hi,
>> >
>> > Thanks for your reply.
>> >
>> >  > Can you please check if this commit is in your tree, or, if the same
>> has
>> >  > to be applied in your case (sama5d3), to make it work ?
>> >
>> > I've got that change in my tree, but I'm still getting the error
>> message.
>>
>> The change may be dedicated to sama5d2 devices. Could you have a look
>> please if your device (sama5d3) needs this change as well ? I mean, does
>> doing something similar for sama5d3 fixes your problem ?
>>
>> Thanks,
>> Eugen
>>
>> >
>> > I am using up-to-date mainline U-Boot.
>> >
>> > Thanks
>> >
>> >
>> >
>> > On Tue, 23 Mar 2021 at 11:14, > > > wrote:
>> >
>> > Hi,
>> >
>> > Can you please check if this commit is in your tree, or, if the same
>> > has
>> > to be applied in your case (sama5d3), to make it work ?
>> >
>> > Here is the commit :
>> >
>> >
>> >
>> https://source.denx.de/u-boot/custodians/u-boot-atmel/-/commit/786f35b619ddbfb88e4532d11a56413f5dab473f
>> >
>> >
>> >
>> > On 3/23/21 1:06 PM, Manuel Luís Reis wrote:
>> >  > Hello,
>> >  >
>> >  > I've been having issues with SPL booting in the SAMA5D3 Xplained
>> > board
>> >  > getting the following error, with up-to-date mainline U-boot and
>> >  > sama5d3_xplained _mmc_defconfig:
>> >  >
>> >  > ---
>> >  > RomBOOT
>> >  >
>> >  > 
>> >  > Could not initialize timer (err -19)
>> >  > .
>> >  > ---
>> >  >
>> >  > I could trace back the error to commit 4b2be78.
>> >  >
>> >  > This topic has been raised before on
>> >  >
>> >
>> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
>> >  > Tried the suggestions there with the same result.
>> >  >
>> >  > I'm am not too knowledgeable with U-Boot nor this board. Could
>> > you shed
>> >  > some light on this? Any pointers would be appreciated.
>> >  >
>> >  > Let me know if you require additional information.
>> >  >
>> >  > Cheers,
>> >  > Manuel
>> >  >
>> >  > Output from dm_dump_all():
>> >  >
>> >  >   Class Index  Probed  DriverName
>> >  > ---
>> >  >   root  0  [ + ]   root_driver  root_driver
>> >  >   simple_bus  0  [   ]   simple_bus  `-- ahb
>> >  >   simple_bus  1  [   ]   simple_bus  `-- apb
>> >  >   mmc  0  [   ]   atmel-mci  |-- mmc@f000
>> >  >   blk  0  [   ]   mmc_blk  |   `-- m...@f000.blk
>> >  >   mmc  1  [   ]   atmel-mci  |-- mmc@f800
>> >  >   blk  1  [   ]   mmc_blk  |   `-- m...@f800.blk
>> >  >   serial  0  [   ]   serial_atmel  |-- serial@ee00
>> >  >   pinctrl  0  [   ]   atmel_sama5d3_pinctrl  |--
>> > pinctrl@f200
>> >  >   pinconfig  0  [   ]   pinconfig  |   |-- dbgu
>> >  >   pinconfig  1  [   ]   pinconfig  |   |   `-- dbgu-0
>> >  >   pinconfig  2  [   ]   pinconfig  |   |-- mmc0
>> >  >   pinconfig  3  [   ]   pinconfig  |   |   |--
>> > mmc0_clk_cmd_dat0
>> >  >   pinconfig  4  [   ]   pinconfig  |   |   |--
>> mmc0_dat1_3
>> >  >   pinconfig  5  [   ]   pinconfig  |   |   `--
>> mmc0_dat4_7
>> >  >   pinconfig  6  [   ]   pinconfig  |   |-- mmc1
>> >  >   pinconfig  7  [   ]   pinconfig  |   |   |--
>> > mmc1_clk_cmd_dat0
>> >  >   

Re: SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Eugen.Hristev]

On 3/23/21 1:28 PM, Manuel Luís Reis wrote:

> Hi,
> 
> Thanks for your reply.
> 
>  > Can you please check if this commit is in your tree, or, if the same has
>  > to be applied in your case (sama5d3), to make it work ?
> 
> I've got that change in my tree, but I'm still getting the error message.

The change may be dedicated to sama5d2 devices. Could you have a look 
please if your device (sama5d3) needs this change as well ? I mean, does 
doing something similar for sama5d3 fixes your problem ?

Thanks,
Eugen

> 
> I am using up-to-date mainline U-Boot.
> 
> Thanks
> 
> 
> 
> On Tue, 23 Mar 2021 at 11:14,  > wrote:
> 
> Hi,
> 
> Can you please check if this commit is in your tree, or, if the same
> has
> to be applied in your case (sama5d3), to make it work ?
> 
> Here is the commit :
> 
> 
> 
> https://source.denx.de/u-boot/custodians/u-boot-atmel/-/commit/786f35b619ddbfb88e4532d11a56413f5dab473f
> 
> 
> 
> On 3/23/21 1:06 PM, Manuel Luís Reis wrote:
>  > Hello,
>  >
>  > I've been having issues with SPL booting in the SAMA5D3 Xplained
> board
>  > getting the following error, with up-to-date mainline U-boot and
>  > sama5d3_xplained _mmc_defconfig:
>  >
>  > ---
>  > RomBOOT
>  >
>  > 
>  > Could not initialize timer (err -19)
>  > .
>  > ---
>  >
>  > I could trace back the error to commit 4b2be78.
>  >
>  > This topic has been raised before on
>  >
> 
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
>  > Tried the suggestions there with the same result.
>  >
>  > I'm am not too knowledgeable with U-Boot nor this board. Could
> you shed
>  > some light on this? Any pointers would be appreciated.
>  >
>  > Let me know if you require additional information.
>  >
>  > Cheers,
>  > Manuel
>  >
>  > Output from dm_dump_all():
>  >
>  >   Class     Index  Probed  Driver                Name
>  > ---
>  >   root  0  [ + ]   root_driver  root_driver
>  >   simple_bus  0  [   ]   simple_bus  `-- ahb
>  >   simple_bus  1  [   ]   simple_bus      `-- apb
>  >   mmc  0  [   ]   atmel-mci          |-- mmc@f000
>  >   blk  0  [   ]   mmc_blk          |   `-- m...@f000.blk
>  >   mmc  1  [   ]   atmel-mci          |-- mmc@f800
>  >   blk  1  [   ]   mmc_blk          |   `-- m...@f800.blk
>  >   serial  0  [   ]   serial_atmel          |-- serial@ee00
>  >   pinctrl  0  [   ]   atmel_sama5d3_pinctrl          |--
> pinctrl@f200
>  >   pinconfig  0  [   ]   pinconfig          |   |-- dbgu
>  >   pinconfig  1  [   ]   pinconfig          |   |   `-- dbgu-0
>  >   pinconfig  2  [   ]   pinconfig          |   |-- mmc0
>  >   pinconfig  3  [   ]   pinconfig          |   |   |--
> mmc0_clk_cmd_dat0
>  >   pinconfig  4  [   ]   pinconfig          |   |   |-- mmc0_dat1_3
>  >   pinconfig  5  [   ]   pinconfig          |   |   `-- mmc0_dat4_7
>  >   pinconfig  6  [   ]   pinconfig          |   |-- mmc1
>  >   pinconfig  7  [   ]   pinconfig          |   |   |--
> mmc1_clk_cmd_dat0
>  >   pinconfig  8  [   ]   pinconfig          |   |   `-- mmc1_dat1_3
>  >   pinconfig  9  [   ]   pinconfig          |   |-- spi0
>  >   pinconfig  10  [   ]   pinconfig          |   |   `-- spi0-0
>  >   pinconfig  11  [   ]   pinconfig          |   |-- spi1
>  >   pinconfig  12  [   ]   pinconfig          |   |   `-- spi1-0
>  >   pinconfig  13  [   ]   pinconfig          |   `-- board
>  >   pinconfig  14  [   ]   pinconfig          |       |-- mmc0_cd
>  >   pinconfig  15  [   ]   pinconfig          |       `-- mmc1_cd
>  >   gpio  0  [   ]   atmel_at91rm9200_gpio          |-- gpio@f200
>  >   gpio  1  [   ]   atmel_at91rm9200_gpio          |-- gpio@f400
>  >   gpio  2  [   ]   atmel_at91rm9200_gpio          |-- gpio@f600
>  >   gpio  3  [   ]   atmel_at91rm9200_gpio          |-- gpio@f800
>  >   gpio  4  [   ]   atmel_at91rm9200_gpio          |-- gpio@fa00
>  >   simple_bus  2  [   ]   at91-pmc          `-- pmc@fc00
>  >   clk  0  [   ]   at91sam9x5-utmi-clk              |-- utmick
>  >   clk  1  [   ]   at91-master-clk              |-- masterck
>  >   misc  0  [   ]   sam9x5-periph-clk              `-- periphck
>  >   clk  2  [   ]   periph-clk                  |-- dbgu_clk@2
>  >   clk  3  [   ]   periph-clk                  |-- pioA_clk@6
>  >   clk  4  [   ]   periph-clk                  |-- pioB_clk@7
>  >   clk  5  [   ]   periph-clk                  |-- pioC_clk@8
>  >   clk  6  [   ]   periph-clk                  |-- pioD_clk@9
> 

Re: SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Eugen.Hristev]

Hi,

Can you please check if this commit is in your tree, or, if the same has 
to be applied in your case (sama5d3), to make it work ?

Here is the commit :


https://source.denx.de/u-boot/custodians/u-boot-atmel/-/commit/786f35b619ddbfb88e4532d11a56413f5dab473f



On 3/23/21 1:06 PM, Manuel Luís Reis wrote:
> Hello,
> 
> I've been having issues with SPL booting in the SAMA5D3 Xplained board 
> getting the following error, with up-to-date mainline U-boot and 
> sama5d3_xplained _mmc_defconfig:
> 
> ---
> RomBOOT
> 
> 
> Could not initialize timer (err -19)
> .
> ---
> 
> I could trace back the error to commit 4b2be78.
> 
> This topic has been raised before on 
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> Tried the suggestions there with the same result.
> 
> I'm am not too knowledgeable with U-Boot nor this board. Could you shed 
> some light on this? Any pointers would be appreciated.
> 
> Let me know if you require additional information.
> 
> Cheers,
> Manuel
> 
> Output from dm_dump_all():
> 
>   Class     Index  Probed  Driver                Name
> ---
>   root  0  [ + ]   root_driver  root_driver
>   simple_bus  0  [   ]   simple_bus  `-- ahb
>   simple_bus  1  [   ]   simple_bus      `-- apb
>   mmc  0  [   ]   atmel-mci          |-- mmc@f000
>   blk  0  [   ]   mmc_blk          |   `-- m...@f000.blk
>   mmc  1  [   ]   atmel-mci          |-- mmc@f800
>   blk  1  [   ]   mmc_blk          |   `-- m...@f800.blk
>   serial  0  [   ]   serial_atmel          |-- serial@ee00
>   pinctrl  0  [   ]   atmel_sama5d3_pinctrl          |-- pinctrl@f200
>   pinconfig  0  [   ]   pinconfig          |   |-- dbgu
>   pinconfig  1  [   ]   pinconfig          |   |   `-- dbgu-0
>   pinconfig  2  [   ]   pinconfig          |   |-- mmc0
>   pinconfig  3  [   ]   pinconfig          |   |   |-- mmc0_clk_cmd_dat0
>   pinconfig  4  [   ]   pinconfig          |   |   |-- mmc0_dat1_3
>   pinconfig  5  [   ]   pinconfig          |   |   `-- mmc0_dat4_7
>   pinconfig  6  [   ]   pinconfig          |   |-- mmc1
>   pinconfig  7  [   ]   pinconfig          |   |   |-- mmc1_clk_cmd_dat0
>   pinconfig  8  [   ]   pinconfig          |   |   `-- mmc1_dat1_3
>   pinconfig  9  [   ]   pinconfig          |   |-- spi0
>   pinconfig  10  [   ]   pinconfig          |   |   `-- spi0-0
>   pinconfig  11  [   ]   pinconfig          |   |-- spi1
>   pinconfig  12  [   ]   pinconfig          |   |   `-- spi1-0
>   pinconfig  13  [   ]   pinconfig          |   `-- board
>   pinconfig  14  [   ]   pinconfig          |       |-- mmc0_cd
>   pinconfig  15  [   ]   pinconfig          |       `-- mmc1_cd
>   gpio  0  [   ]   atmel_at91rm9200_gpio          |-- gpio@f200
>   gpio  1  [   ]   atmel_at91rm9200_gpio          |-- gpio@f400
>   gpio  2  [   ]   atmel_at91rm9200_gpio          |-- gpio@f600
>   gpio  3  [   ]   atmel_at91rm9200_gpio          |-- gpio@f800
>   gpio  4  [   ]   atmel_at91rm9200_gpio          |-- gpio@fa00
>   simple_bus  2  [   ]   at91-pmc          `-- pmc@fc00
>   clk  0  [   ]   at91sam9x5-utmi-clk              |-- utmick
>   clk  1  [   ]   at91-master-clk              |-- masterck
>   misc  0  [   ]   sam9x5-periph-clk              `-- periphck
>   clk  2  [   ]   periph-clk                  |-- dbgu_clk@2
>   clk  3  [   ]   periph-clk                  |-- pioA_clk@6
>   clk  4  [   ]   periph-clk                  |-- pioB_clk@7
>   clk  5  [   ]   periph-clk                  |-- pioC_clk@8
>   clk  6  [   ]   periph-clk                  |-- pioD_clk@9
>   clk  7  [   ]   periph-clk                  |-- pioE_clk@10
>   clk  8  [   ]   periph-clk                  |-- mci0_clk@21
>   clk  9  [   ]   periph-clk                  |-- mci1_clk@22
>   clk  10  [   ]   periph-clk                  |-- spi0_clk@24
>   clk  11  [   ]   periph-clk                  `-- spi1_clk@25
> Could not initialize timer (err -19)
> 

Re: [PATCH v2 1/2] power: regulator: add driver for ANATOP regulator

[Sean Anderson]

On 3/23/21 9:48 AM, Ying-Chun Liu wrote:
> From: "Ying-Chun Liu (PaulLiu)" 
>
> Anatop is an integrated regulator inside i.MX6 SoC.
> There are 3 digital regulators which controls PU, CORE (ARM), and SOC.
> And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB).
> This patch adds the Anatop regulator driver.

+CC Peng Fan, Fabio Estevam

I don't see support for vin-supply. I have made comments below showing
the (relatively-minimal IMO) changes necessary to support it, along
with some additional comments.

>
> Signed-off-by: Ying-Chun Liu (PaulLiu) 
> ---
> v2: add functions for set selector and delay. Define ANATOP_REGULATOR_STEP
> ---
>   drivers/power/regulator/Kconfig|  10 +
>   drivers/power/regulator/Makefile   |   1 +
>   drivers/power/regulator/anatop_regulator.c | 299 +
>   3 files changed, 310 insertions(+)
>   create mode 100644 drivers/power/regulator/anatop_regulator.c
>
> diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
> index fbbea18c7d..1cd1f3f5ed 100644
> --- a/drivers/power/regulator/Kconfig
> +++ b/drivers/power/regulator/Kconfig
> @@ -312,6 +312,16 @@ config DM_REGULATOR_STPMIC1
>by the PMIC device. This driver is controlled by a device tree node
>which includes voltage limits.
>
> +config DM_REGULATOR_ANATOP
> +  bool "Enable driver for ANATOP regulators"
> +  depends on DM_REGULATOR
> +  select REGMAP
> +  select SYSCON
> +  help
> +  Enable support for the Freescale i.MX on-chip ANATOP LDOs
> +  regulators. It is recommended that this option be enabled on
> +  i.MX6 platform.
> +
>   config SPL_DM_REGULATOR_STPMIC1
>bool "Enable driver for STPMIC1 regulators in SPL"
>depends on SPL_DM_REGULATOR && PMIC_STPMIC1
> diff --git a/drivers/power/regulator/Makefile 
b/drivers/power/regulator/Makefile
> index 9d58112dcb..e7198da911 100644
> --- a/drivers/power/regulator/Makefile
> +++ b/drivers/power/regulator/Makefile
> @@ -30,3 +30,4 @@ obj-$(CONFIG_DM_REGULATOR_TPS65910) += tps65910_regulator.o
>   obj-$(CONFIG_DM_REGULATOR_TPS62360) += tps62360_regulator.o
>   obj-$(CONFIG_$(SPL_)DM_REGULATOR_STPMIC1) += stpmic1.o
>   obj-$(CONFIG_DM_REGULATOR_TPS65941) += tps65941_regulator.o
> +obj-$(CONFIG_$(SPL_)DM_REGULATOR_ANATOP) += anatop_regulator.o
> diff --git a/drivers/power/regulator/anatop_regulator.c 
b/drivers/power/regulator/anatop_regulator.c
> new file mode 100644
> index 00..d824f4acc4
> --- /dev/null
> +++ b/drivers/power/regulator/anatop_regulator.c
> @@ -0,0 +1,299 @@
> +// SPDX-License-Identifier: GPL-2.0+
> +//
> +// Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
> +// Copyright (C) 2021 Linaro

Use C-style comments (/* */) for everything other than the initial SPDX
line.

> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

These should be below with the other linux headers.

> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 

These should be above the linux headers.

> +
> +#define LDO_RAMP_UP_UNIT_IN_CYCLES  64 /* 64 cycles per step */
> +#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */
> +
> +#define LDO_POWER_GATE0x00
> +#define LDO_FET_FULL_ON   0x1f
> +
> +#define BIT_WIDTH_MAX 32
> +
> +#define ANATOP_REGULATOR_STEP 25000
> +
> +struct anatop_regulator {
> +  const char *name;

struct udevice *supply;

> +  u32 control_reg;
> +  u32 vol_bit_shift;
> +  u32 vol_bit_width;
> +  u32 min_bit_val;
> +  u32 min_voltage;
> +  u32 max_voltage;
> +  u32 delay_reg;
> +  u32 delay_bit_shift;
> +  u32 delay_bit_width;
> +};
> +
> +static u32 anatop_get_bits(struct udevice *dev, u32 addr, int bit_shift,
> + int bit_width)
> +{
> +  struct udevice *syscon;
> +  struct regmap *regmap;
> +  int err;
> +  u32 val, mask;
> +
> +  syscon = dev_get_parent(dev);
> +  if (!syscon) {
> +  dev_err(dev, "%s: unable to find syscon device\n", __func__);

Use dev_dbg, per [1]. This applies to most other logs in this file as
well.

> +  return -ENODEV;

Use ENOENT, per [1].

[1] https://lists.denx.de/pipermail/u-boot/2021-March/445207.html

> +  }
> +
> +  regmap = syscon_get_regmap(syscon);
> +  if (IS_ERR(regmap)) {
> +  dev_err(dev, "%s: unable to find regmap (%ld)\n", __func__,
> +  PTR_ERR(regmap));
> +  return PTR_ERR(regmap);
> +  }

This should be done in probe().

> +
> +  if (bit_width == BIT_WIDTH_MAX)
> +  mask = ~0;
> +  else
> +  mask = (1 << bit_width) - 1;
> +
> +  err = regmap_read(regmap, addr, );
> +  if (err)
> +  return err;
> +
> +  val = (val >> bit_shift) & mask;
> +
> +  return val;
> +}
> +
> +static int anatop_set_bits(struct udevice *dev, u32 addr, int bit_shift,
> + int bit_width, u32 data)
> +{
> +  struct udevice *syscon;
> +  struct regmap *regmap;
> +  

[PATCH v2 2/2] doc: device-tree-bindings: regulator: anatop regulator

[Ying-Chun Liu]

From: "Ying-Chun Liu (PaulLiu)" 

Document the bindings for fsl,anatop-regulator

Signed-off-by: Ying-Chun Liu (PaulLiu) 
---
 .../regulator/fsl,anatop-regulator.txt| 45 +++
 1 file changed, 45 insertions(+)
 create mode 100644 doc/device-tree-bindings/regulator/fsl,anatop-regulator.txt

diff --git a/doc/device-tree-bindings/regulator/fsl,anatop-regulator.txt 
b/doc/device-tree-bindings/regulator/fsl,anatop-regulator.txt
new file mode 100644
index 00..2a60e4941b
--- /dev/null
+++ b/doc/device-tree-bindings/regulator/fsl,anatop-regulator.txt
@@ -0,0 +1,45 @@
+ANATOP REGULATOR
+
+Anatop is an integrated regulator inside i.MX6 SoC.
+
+Required properties:
+- compatible:  Must be "fsl,anatop-regulator".
+- regulator-name:  Name of the regulator
+- anatop-reg-offset:   u32 value representing the anatop MFD register offset.
+- anatop-vol-bit-shift:u32 value representing the bit shift for the 
register.
+- anatop-vol-bit-width:u32 value representing the number of bits used 
in the
+   register.
+- anatop-min-bit-val:  u32 value representing the minimum value of this
+   register.
+- anatop-min-voltage:  u32 value representing the minimum voltage of this
+   regulator.
+- anatop-max-voltage:  u32 value representing the maximum voltage of this
+   regulator.
+
+Optional properties:
+- anatop-delay-reg-offset: u32 value representing the anatop MFD step time
+  register offset.
+- anatop-delay-bit-shift: u32 value representing the bit shift for the step
+ time register.
+- anatop-delay-bit-width: u32 value representing the number of bits used in
+ the step time register.
+- anatop-enable-bit: u32 value representing regulator enable bit offset.
+- vin-supply:input supply phandle.
+
+Example:
+   regulator-vddpu {
+   compatible = "fsl,anatop-regulator";
+   regulator-name = "vddpu";
+   regulator-min-microvolt = <725000>;
+   regulator-max-microvolt = <130>;
+   regulator-always-on;
+   anatop-reg-offset = <0x140>;
+   anatop-vol-bit-shift = <9>;
+   anatop-vol-bit-width = <5>;
+   anatop-delay-reg-offset = <0x170>;
+   anatop-delay-bit-shift = <24>;
+   anatop-delay-bit-width = <2>;
+   anatop-min-bit-val = <1>;
+   anatop-min-voltage = <725000>;
+   anatop-max-voltage = <130>;
+   };
-- 
2.30.2

[PATCH v2 1/2] power: regulator: add driver for ANATOP regulator

[Ying-Chun Liu]

From: "Ying-Chun Liu (PaulLiu)" 

Anatop is an integrated regulator inside i.MX6 SoC.
There are 3 digital regulators which controls PU, CORE (ARM), and SOC.
And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB).
This patch adds the Anatop regulator driver.

Signed-off-by: Ying-Chun Liu (PaulLiu) 
---
v2: add functions for set selector and delay. Define ANATOP_REGULATOR_STEP
---
 drivers/power/regulator/Kconfig|  10 +
 drivers/power/regulator/Makefile   |   1 +
 drivers/power/regulator/anatop_regulator.c | 299 +
 3 files changed, 310 insertions(+)
 create mode 100644 drivers/power/regulator/anatop_regulator.c

diff --git a/drivers/power/regulator/Kconfig b/drivers/power/regulator/Kconfig
index fbbea18c7d..1cd1f3f5ed 100644
--- a/drivers/power/regulator/Kconfig
+++ b/drivers/power/regulator/Kconfig
@@ -312,6 +312,16 @@ config DM_REGULATOR_STPMIC1
by the PMIC device. This driver is controlled by a device tree node
which includes voltage limits.
 
+config DM_REGULATOR_ANATOP
+   bool "Enable driver for ANATOP regulators"
+   depends on DM_REGULATOR
+   select REGMAP
+   select SYSCON
+   help
+   Enable support for the Freescale i.MX on-chip ANATOP LDOs
+   regulators. It is recommended that this option be enabled on
+   i.MX6 platform.
+
 config SPL_DM_REGULATOR_STPMIC1
bool "Enable driver for STPMIC1 regulators in SPL"
depends on SPL_DM_REGULATOR && PMIC_STPMIC1
diff --git a/drivers/power/regulator/Makefile b/drivers/power/regulator/Makefile
index 9d58112dcb..e7198da911 100644
--- a/drivers/power/regulator/Makefile
+++ b/drivers/power/regulator/Makefile
@@ -30,3 +30,4 @@ obj-$(CONFIG_DM_REGULATOR_TPS65910) += tps65910_regulator.o
 obj-$(CONFIG_DM_REGULATOR_TPS62360) += tps62360_regulator.o
 obj-$(CONFIG_$(SPL_)DM_REGULATOR_STPMIC1) += stpmic1.o
 obj-$(CONFIG_DM_REGULATOR_TPS65941) += tps65941_regulator.o
+obj-$(CONFIG_$(SPL_)DM_REGULATOR_ANATOP) += anatop_regulator.o
diff --git a/drivers/power/regulator/anatop_regulator.c 
b/drivers/power/regulator/anatop_regulator.c
new file mode 100644
index 00..d824f4acc4
--- /dev/null
+++ b/drivers/power/regulator/anatop_regulator.c
@@ -0,0 +1,299 @@
+// SPDX-License-Identifier: GPL-2.0+
+//
+// Copyright (C) 2011 Freescale Semiconductor, Inc. All Rights Reserved.
+// Copyright (C) 2021 Linaro
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LDO_RAMP_UP_UNIT_IN_CYCLES  64 /* 64 cycles per step */
+#define LDO_RAMP_UP_FREQ_IN_MHZ 24 /* cycle based on 24M OSC */
+
+#define LDO_POWER_GATE 0x00
+#define LDO_FET_FULL_ON0x1f
+
+#define BIT_WIDTH_MAX  32
+
+#define ANATOP_REGULATOR_STEP  25000
+
+struct anatop_regulator {
+   const char *name;
+   u32 control_reg;
+   u32 vol_bit_shift;
+   u32 vol_bit_width;
+   u32 min_bit_val;
+   u32 min_voltage;
+   u32 max_voltage;
+   u32 delay_reg;
+   u32 delay_bit_shift;
+   u32 delay_bit_width;
+};
+
+static u32 anatop_get_bits(struct udevice *dev, u32 addr, int bit_shift,
+  int bit_width)
+{
+   struct udevice *syscon;
+   struct regmap *regmap;
+   int err;
+   u32 val, mask;
+
+   syscon = dev_get_parent(dev);
+   if (!syscon) {
+   dev_err(dev, "%s: unable to find syscon device\n", __func__);
+   return -ENODEV;
+   }
+
+   regmap = syscon_get_regmap(syscon);
+   if (IS_ERR(regmap)) {
+   dev_err(dev, "%s: unable to find regmap (%ld)\n", __func__,
+   PTR_ERR(regmap));
+   return PTR_ERR(regmap);
+   }
+
+   if (bit_width == BIT_WIDTH_MAX)
+   mask = ~0;
+   else
+   mask = (1 << bit_width) - 1;
+
+   err = regmap_read(regmap, addr, );
+   if (err)
+   return err;
+
+   val = (val >> bit_shift) & mask;
+
+   return val;
+}
+
+static int anatop_set_bits(struct udevice *dev, u32 addr, int bit_shift,
+  int bit_width, u32 data)
+{
+   struct udevice *syscon;
+   struct regmap *regmap;
+   int err;
+   u32 val, mask;
+
+   syscon = dev_get_parent(dev);
+   if (!syscon) {
+   dev_err(dev, "%s: unable to find syscon device\n", __func__);
+   return -ENODEV;
+   }
+
+   regmap = syscon_get_regmap(syscon);
+   if (IS_ERR(regmap)) {
+   dev_err(dev,
+   "%s: unable to find regmap (%ld)\n", __func__,
+   PTR_ERR(regmap));
+   return PTR_ERR(regmap);
+   }
+
+   if (bit_width == 32)
+   mask = ~0;
+   else
+   mask = (1 << bit_width) - 1;
+
+   err = regmap_read(regmap, addr, );
+   if (err) {
+   

[PATCH v2 0/2] power: regulator: add driver for ANATOP regulator

[Ying-Chun Liu]

From: "Ying-Chun Liu (PaulLiu)" 

Anatop is an integrated regulator inside i.MX6 SoC.
There are 3 digital regulators which controls PU, CORE (ARM), and SOC.
And 3 analog regulators which controls 1P1, 2P5, 3P0 (USB).
This patch adds the Anatop regulator driver.

Ying-Chun Liu (PaulLiu) (2):
  power: regulator: add driver for ANATOP regulator
  doc: device-tree-bindings: regulator: anatop regulator

v2: add functions for set selector and delay. Define ANATOP_REGULATOR_STEP

 .../regulator/fsl,anatop-regulator.txt|  45 +++
 drivers/power/regulator/Kconfig   |  10 +
 drivers/power/regulator/Makefile  |   1 +
 drivers/power/regulator/anatop_regulator.c| 299 ++
 4 files changed, 355 insertions(+)
 create mode 100644 doc/device-tree-bindings/regulator/fsl,anatop-regulator.txt
 create mode 100644 drivers/power/regulator/anatop_regulator.c

-- 
2.30.2

Re: [PATCH v2 2/2] test: unit test for longjmp

[Sean Anderson]

On 3/22/21 12:42 PM, Heinrich Schuchardt wrote:

On 22.03.21 14:30, Sean Anderson wrote:


On 3/22/21 9:23 AM, Sean Anderson wrote:


On 3/22/21 7:02 AM, Heinrich Schuchardt wrote:

Provide a unit test for the longjmp() library function

Signed-off-by: Heinrich Schuchardt 
---
v2:
     no change
---
   test/lib/Makefile  |  1 +
   test/lib/longjmp.c | 44 
   2 files changed, 45 insertions(+)
   create mode 100644 test/lib/longjmp.c

diff --git a/test/lib/Makefile b/test/lib/Makefile
index 97c11e35a8..a30f615aa9 100644
--- a/test/lib/Makefile
+++ b/test/lib/Makefile
@@ -7,6 +7,7 @@ obj-$(CONFIG_EFI_LOADER) += efi_device_path.o
   obj-$(CONFIG_EFI_SECURE_BOOT) += efi_image_region.o
   obj-y += hexdump.o
   obj-y += lmb.o
+obj-y += longjmp.o
   obj-$(CONFIG_CONSOLE_RECORD) += test_print.o
   obj-$(CONFIG_SSCANF) += sscanf.o
   obj-y += string.o
diff --git a/test/lib/longjmp.c b/test/lib/longjmp.c
new file mode 100644
index 00..7571540ffc
--- /dev/null
+++ b/test/lib/longjmp.c
@@ -0,0 +1,44 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Test setjmp(), longjmp()
+ *
+ * Copyright (c) 2021, Heinrich Schuchardt 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+/**
+ * test_longjmp_ret() - get longjmp() return value
+ *
+ * @i:    value passed to longjmp()
+ * Return:    value returned by longjmp()
+ */
+int test_longjmp_ret(int i)
+{
+    jmp_buf env;
+    int ret;
+
+    ret = setjmp(env);
+    if (ret)
+    return ret;
+    longjmp(env, i);
+    /* We should not arrive here */
+    return 0x1000;
+}
+
+static int lib_test_longjmp(struct unit_test_state *uts)
+{
+    int i;
+
+    for (i = -3; i < 0; ++i)
+    ut_asserteq(i, test_longjmp_ret(i));
+    ut_asserteq(1, test_longjmp_ret(0));
+    for (i = 1; i < 4; ++i)
+    ut_asserteq(i, test_longjmp_ret(i));
+    return 0;
+}
+LIB_TEST(lib_test_longjmp, 0);
--
2.30.2



Reviewed-by: Sean Anderson 
Tested-by: Sean Anderson 

Though I would like to test that variables are set correctly e.g. by
doing

int test_longjmp_ret(int i)
{
  jmp_buf env;
  int ret;

  ret = setjmp(env);
  if (ret)
  return ret;
  ret = 0x1000;
  longjmp(env, i);
  /* We should not arrive here */
  return ret;
}

--Sean


err, rather by doing

int test_longjmp_ret(int i)
{
  jmp_buf env;
  int ret;
  int foo = i;

  ret = setjmp(env);
  if (ret)
  return foo;
  foo = 0x1000;
  longjmp(env, i);
  /* We should not arrive here */
  return foo;
}

or something else which demonstrates that variables get reset to their
earlier values.

--Sean


Hello Sean,

thank you for reviewing.

Would the following make sense to you to check that the stack pointer is
correctly restored?


struct test_jmp_buf {
 jmp_buf env;
 int val;
};

/**
  * test_longjmp() - test longjmp function
  *
  * @i is passed to longjmp.
  * @i << 8 is set in the environment structure.
  *
  * @env:environment
  * @i:  value passed to longjmp()
  */
static void noinline test_longjmp(struct test_jmp_buf *env, int i)
{
 env->val = i << 8;
 longjmp(env->env, i);
}

/**
  * test_setjmp() - test setjmp function
  *
  * setjmp() will return the value @i passed to longjmp() if @i is non-zero.
  * For @i == 0 we expect return value 1.
  *
  * @i << 8 will be set by test_longjmp in the environment structure.
  * This value can be used to check that the stack frame is restored.
  *
  * We return the XORed values to allow simply check both at once.
  *
  * @i:  value passed to longjmp()
  * Return:  values return byby longjmp()


nit: by


  */
static int test_setjmp(int i)
{
 struct test_jmp_buf env;
 int ret;

 env.val = -1;
 ret = setjmp(env.env);
 if (ret)
 return ret ^ env.val;
 test_longjmp(, i);
 /* We should not arrive here */
 return 0x1000;
}

Best regards

Heinrich



Yes, this looks good.

--Sean

Re: SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Manuel Luís Reis]

> The change may be dedicated to sama5d2 devices. Could you have a look
> please if your device (sama5d3) needs this change as well ? I mean, does
> doing something similar for sama5d3 fixes your problem ?

I  am not quite sure how to check what you suggest to be honest.

The commit you've sent seems to be board independent ->
mach-at91/spl_atmel.c. Doesn't it apply to all of the at91 boards, sama5d3
inclusive?
I don't see where else I could make a change like that.

Thanks for your patience.



On Tue, 23 Mar 2021 at 11:38,  wrote:

> On 3/23/21 1:28 PM, Manuel Luís Reis wrote:
>
> > Hi,
> >
> > Thanks for your reply.
> >
> >  > Can you please check if this commit is in your tree, or, if the same
> has
> >  > to be applied in your case (sama5d3), to make it work ?
> >
> > I've got that change in my tree, but I'm still getting the error message.
>
> The change may be dedicated to sama5d2 devices. Could you have a look
> please if your device (sama5d3) needs this change as well ? I mean, does
> doing something similar for sama5d3 fixes your problem ?
>
> Thanks,
> Eugen
>
> >
> > I am using up-to-date mainline U-Boot.
> >
> > Thanks
> >
> >
> >
> > On Tue, 23 Mar 2021 at 11:14,  > > wrote:
> >
> > Hi,
> >
> > Can you please check if this commit is in your tree, or, if the same
> > has
> > to be applied in your case (sama5d3), to make it work ?
> >
> > Here is the commit :
> >
> >
> >
> https://source.denx.de/u-boot/custodians/u-boot-atmel/-/commit/786f35b619ddbfb88e4532d11a56413f5dab473f
> >
> >
> >
> > On 3/23/21 1:06 PM, Manuel Luís Reis wrote:
> >  > Hello,
> >  >
> >  > I've been having issues with SPL booting in the SAMA5D3 Xplained
> > board
> >  > getting the following error, with up-to-date mainline U-boot and
> >  > sama5d3_xplained _mmc_defconfig:
> >  >
> >  > ---
> >  > RomBOOT
> >  >
> >  > 
> >  > Could not initialize timer (err -19)
> >  > .
> >  > ---
> >  >
> >  > I could trace back the error to commit 4b2be78.
> >  >
> >  > This topic has been raised before on
> >  >
> >
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> >  > Tried the suggestions there with the same result.
> >  >
> >  > I'm am not too knowledgeable with U-Boot nor this board. Could
> > you shed
> >  > some light on this? Any pointers would be appreciated.
> >  >
> >  > Let me know if you require additional information.
> >  >
> >  > Cheers,
> >  > Manuel
> >  >
> >  > Output from dm_dump_all():
> >  >
> >  >   Class Index  Probed  DriverName
> >  > ---
> >  >   root  0  [ + ]   root_driver  root_driver
> >  >   simple_bus  0  [   ]   simple_bus  `-- ahb
> >  >   simple_bus  1  [   ]   simple_bus  `-- apb
> >  >   mmc  0  [   ]   atmel-mci  |-- mmc@f000
> >  >   blk  0  [   ]   mmc_blk  |   `-- m...@f000.blk
> >  >   mmc  1  [   ]   atmel-mci  |-- mmc@f800
> >  >   blk  1  [   ]   mmc_blk  |   `-- m...@f800.blk
> >  >   serial  0  [   ]   serial_atmel  |-- serial@ee00
> >  >   pinctrl  0  [   ]   atmel_sama5d3_pinctrl  |--
> > pinctrl@f200
> >  >   pinconfig  0  [   ]   pinconfig  |   |-- dbgu
> >  >   pinconfig  1  [   ]   pinconfig  |   |   `-- dbgu-0
> >  >   pinconfig  2  [   ]   pinconfig  |   |-- mmc0
> >  >   pinconfig  3  [   ]   pinconfig  |   |   |--
> > mmc0_clk_cmd_dat0
> >  >   pinconfig  4  [   ]   pinconfig  |   |   |-- mmc0_dat1_3
> >  >   pinconfig  5  [   ]   pinconfig  |   |   `-- mmc0_dat4_7
> >  >   pinconfig  6  [   ]   pinconfig  |   |-- mmc1
> >  >   pinconfig  7  [   ]   pinconfig  |   |   |--
> > mmc1_clk_cmd_dat0
> >  >   pinconfig  8  [   ]   pinconfig  |   |   `-- mmc1_dat1_3
> >  >   pinconfig  9  [   ]   pinconfig  |   |-- spi0
> >  >   pinconfig  10  [   ]   pinconfig  |   |   `-- spi0-0
> >  >   pinconfig  11  [   ]   pinconfig  |   |-- spi1
> >  >   pinconfig  12  [   ]   pinconfig  |   |   `-- spi1-0
> >  >   pinconfig  13  [   ]   pinconfig  |   `-- board
> >  >   pinconfig  14  [   ]   pinconfig  |   |-- mmc0_cd
> >  >   pinconfig  15  [   ]   pinconfig  |   `-- mmc1_cd
> >  >   gpio  0  [   ]   atmel_at91rm9200_gpio  |--
> gpio@f200
> >  >   gpio  1  [   ]   atmel_at91rm9200_gpio  |--
> gpio@f400
> >  >   gpio  2  [   ]   atmel_at91rm9200_gpio  |--
> gpio@f600
> >  >   gpio  3  [   ]   atmel_at91rm9200_gpio

RE: [PATCH] common: board_f: Restore 85xx watchdog support

[Priyanka Jain]

>-Original Message-
>From: U-Boot  On Behalf Of Chris Packham
>Sent: Wednesday, March 3, 2021 2:30 AM
>To: u-boot@lists.denx.de
>Cc: York Sun ; Rainer Boschung
>; Chris Packham ;
>Masahiro Yamada ; Ovidiu Panait
>; Patrick Delaunay
>; Simon Glass ; Stefan
>Roese ; Stephen Warren 
>Subject: [PATCH] common: board_f: Restore 85xx watchdog support
>
>In commit 75918afa649b ("powerpc: Drop old non-generic-board code") we lost
>the call to init_85xx_watchdog() which had the effect of disabling support for 
>the
>watchdog on 85xx and similar SoCs (i.e. the QorIQ P Series and T Series).
>
>Signed-off-by: Chris Packham 
>---
>Admittedly this is a bit ugly but it's the most literal reinstatement of the 
>code that
>was lost. At the very least I should probably rename
>init_85xx_watchdog() to hw_watchdog_init() so it fits with the rest of the 
>code.
>
>The other question is how has this gone unnoticed for ~5 years. I think the 
>answer
>is because only the keymile boards were using it.
>
>Finally I am wondering if this should be converted to a DM driver. But given 
>the
>fact that the watchdog is part of the core and not a peripheral on the SoC I 
>don't
>know how that would look (e.g. what would I put in the DTS?).
>
>So I thought I'd run this up the flag pole as-is and see what feedback I get.
>
> common/board_f.c | 5 +
> 1 file changed, 5 insertions(+)
>
>diff --git a/common/board_f.c b/common/board_f.c index
>0cddf0359dca..3778571a7196 100644
>--- a/common/board_f.c
>+++ b/common/board_f.c
>@@ -111,6 +111,11 @@ static int init_func_watchdog_init(void)
>   hw_watchdog_init();
>   puts("   Watchdog enabled\n");
> # endif
>+# ifdef CONFIG_MPC85xx
>+  init_85xx_watchdog();
>+  puts("   Watchdog enabled\n");
>+# endif
>+
>   WATCHDOG_RESET();
>
>   return 0;
>--
>2.30.1

Kindly fix below build error for non-fsl ppc boards
powerpc:  w+   mpc8308_p1m sbc8349 sbc8349_PCI_33 sbc8349_PCI_66 ve8313 caddy2 
vme8349 hrcon hrcon_dh strider_con strider_con_dp strider_cpu strider_cpu_dp 
ids8313 TQM834x sbc8548 sbc8548_PCI_33 sbc8548_PCI_33_PCIE sbc8548_PCI_66 
sbc8548_PCI_66_PCIE socrates UCP1020 kmcent2 kmcoge4 Cyrus_P5020 Cyrus_P5040 
xpedite520x xpedite537x xpedite550x sbc8641d xpedite517x MCR3000 +   
controlcenterd_36BIT_SDCARD controlcenterd_36BIT_SDCARD_DEVELOP 
controlcenterd_TRAILBLAZER controlcenterd_TRAILBLAZER_DEVELOP


+powerpc-linux-ld.bfd: common/built-in.o: in function `init_func_watchdog_init':
2021-03-23T11:09:10.9787128Z +common/board_f.c:115: undefined reference to 
`init_85xx_watchdog'
2021-03-23T11:09:10.9787600Z +make[1]: *** [u-boot] Error 1
2021-03-23T11:09:10.9787981Z +make: *** [sub-make] Error 2


Regards
Priyanka

Re: [PATCH v2 1/2] riscv: simplify longjmp

[Leo Liang]

Hi Heinrich,

On Mon, Mar 22, 2021 at 12:02:48PM +0100, Heinrich Schuchardt wrote:
> The value returned by setjmp must be nonzero. If zero is passed as
> parameter it must be replaced by 1.
> 
> This patch reduces the code size a bit.
> 
> Signed-off-by: Heinrich Schuchardt 
> Sean Anderson 

I think Sean is refering to the "Reviewed-by" tag is missing.
Otherwise than that, LGTM.

> ---
> v2:
>   fix typo in title
> ---
>  arch/riscv/lib/setjmp.S | 8 ++--
>  1 file changed, 2 insertions(+), 6 deletions(-)
> 
> diff --git a/arch/riscv/lib/setjmp.S b/arch/riscv/lib/setjmp.S
> index 72bc9241f6..99d6195827 100644
> --- a/arch/riscv/lib/setjmp.S
> +++ b/arch/riscv/lib/setjmp.S
> @@ -54,12 +54,8 @@ ENTRY(longjmp)
>   LOAD_IDX(sp, 13)
> 
>   /* Move the return value in place, but return 1 if passed 0. */
> - beq a1, zero, longjmp_1
> - mv a0, a1
> - ret
> -
> - longjmp_1:
> - li a0, 1
> + seqz a0, a1
> + add a0, a0, a1
>   ret
>  ENDPROC(longjmp)
>  .popsection
> --
> 2.30.2
>
Reviewed-by: Leo Yu-Chi Liang 

Best regards,
Leo

[PATCH 1/1] sandbox: define __dyn_sym_start, dyn_sym_end

[Heinrich Schuchardt]

On RISC-V the symbols __dyn_sym_start, dyn_sym_end are referenced in
efi_runtime_relocate().

Signed-off-by: Heinrich Schuchardt 
---
 arch/sandbox/cpu/u-boot.lds | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/sandbox/cpu/u-boot.lds b/arch/sandbox/cpu/u-boot.lds
index 936da5e140..a1f509c9ab 100644
--- a/arch/sandbox/cpu/u-boot.lds
+++ b/arch/sandbox/cpu/u-boot.lds
@@ -44,6 +44,13 @@ SECTIONS
{
*(.__efi_runtime_rel_stop)
}
+
+   .dynsym :
+   {
+   __dyn_sym_start = .;
+   *(.dynsym)
+   __dyn_sym_end = .;
+   }
 }

 INSERT BEFORE .data;
--
2.30.2

Re: Help needed with uboot for CHIP

[Maxime Ripard]

On Tue, Mar 23, 2021 at 12:01:36AM +0530, Gunjan Gupta wrote:
> Ok...
> 
> What about supporting SLC. I dont have a Chip pro, but are you sure that
> the current logic works for that too?

The CHIP Pro has support for the NAND enabled, and if there's an issue
then it should be fixed indeed.

Maxime

Re: SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Manuel Luís Reis]

Hi,

Thanks for your reply.

> Can you please check if this commit is in your tree, or, if the same has
> to be applied in your case (sama5d3), to make it work ?

I've got that change in my tree, but I'm still getting the error message.

I am using up-to-date mainline U-Boot.

Thanks



On Tue, 23 Mar 2021 at 11:14,  wrote:

> Hi,
>
> Can you please check if this commit is in your tree, or, if the same has
> to be applied in your case (sama5d3), to make it work ?
>
> Here is the commit :
>
>
>
> https://source.denx.de/u-boot/custodians/u-boot-atmel/-/commit/786f35b619ddbfb88e4532d11a56413f5dab473f
>
>
>
> On 3/23/21 1:06 PM, Manuel Luís Reis wrote:
> > Hello,
> >
> > I've been having issues with SPL booting in the SAMA5D3 Xplained board
> > getting the following error, with up-to-date mainline U-boot and
> > sama5d3_xplained _mmc_defconfig:
> >
> > ---
> > RomBOOT
> >
> > 
> > Could not initialize timer (err -19)
> > .
> > ---
> >
> > I could trace back the error to commit 4b2be78.
> >
> > This topic has been raised before on
> >
> http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
> > Tried the suggestions there with the same result.
> >
> > I'm am not too knowledgeable with U-Boot nor this board. Could you shed
> > some light on this? Any pointers would be appreciated.
> >
> > Let me know if you require additional information.
> >
> > Cheers,
> > Manuel
> >
> > Output from dm_dump_all():
> >
> >   Class Index  Probed  DriverName
> > ---
> >   root  0  [ + ]   root_driver  root_driver
> >   simple_bus  0  [   ]   simple_bus  `-- ahb
> >   simple_bus  1  [   ]   simple_bus  `-- apb
> >   mmc  0  [   ]   atmel-mci  |-- mmc@f000
> >   blk  0  [   ]   mmc_blk  |   `-- m...@f000.blk
> >   mmc  1  [   ]   atmel-mci  |-- mmc@f800
> >   blk  1  [   ]   mmc_blk  |   `-- m...@f800.blk
> >   serial  0  [   ]   serial_atmel  |-- serial@ee00
> >   pinctrl  0  [   ]   atmel_sama5d3_pinctrl  |-- pinctrl@f200
> >   pinconfig  0  [   ]   pinconfig  |   |-- dbgu
> >   pinconfig  1  [   ]   pinconfig  |   |   `-- dbgu-0
> >   pinconfig  2  [   ]   pinconfig  |   |-- mmc0
> >   pinconfig  3  [   ]   pinconfig  |   |   |-- mmc0_clk_cmd_dat0
> >   pinconfig  4  [   ]   pinconfig  |   |   |-- mmc0_dat1_3
> >   pinconfig  5  [   ]   pinconfig  |   |   `-- mmc0_dat4_7
> >   pinconfig  6  [   ]   pinconfig  |   |-- mmc1
> >   pinconfig  7  [   ]   pinconfig  |   |   |-- mmc1_clk_cmd_dat0
> >   pinconfig  8  [   ]   pinconfig  |   |   `-- mmc1_dat1_3
> >   pinconfig  9  [   ]   pinconfig  |   |-- spi0
> >   pinconfig  10  [   ]   pinconfig  |   |   `-- spi0-0
> >   pinconfig  11  [   ]   pinconfig  |   |-- spi1
> >   pinconfig  12  [   ]   pinconfig  |   |   `-- spi1-0
> >   pinconfig  13  [   ]   pinconfig  |   `-- board
> >   pinconfig  14  [   ]   pinconfig  |   |-- mmc0_cd
> >   pinconfig  15  [   ]   pinconfig  |   `-- mmc1_cd
> >   gpio  0  [   ]   atmel_at91rm9200_gpio  |-- gpio@f200
> >   gpio  1  [   ]   atmel_at91rm9200_gpio  |-- gpio@f400
> >   gpio  2  [   ]   atmel_at91rm9200_gpio  |-- gpio@f600
> >   gpio  3  [   ]   atmel_at91rm9200_gpio  |-- gpio@f800
> >   gpio  4  [   ]   atmel_at91rm9200_gpio  |-- gpio@fa00
> >   simple_bus  2  [   ]   at91-pmc  `-- pmc@fc00
> >   clk  0  [   ]   at91sam9x5-utmi-clk  |-- utmick
> >   clk  1  [   ]   at91-master-clk  |-- masterck
> >   misc  0  [   ]   sam9x5-periph-clk  `-- periphck
> >   clk  2  [   ]   periph-clk  |-- dbgu_clk@2
> >   clk  3  [   ]   periph-clk  |-- pioA_clk@6
> >   clk  4  [   ]   periph-clk  |-- pioB_clk@7
> >   clk  5  [   ]   periph-clk  |-- pioC_clk@8
> >   clk  6  [   ]   periph-clk  |-- pioD_clk@9
> >   clk  7  [   ]   periph-clk  |-- pioE_clk@10
> >   clk  8  [   ]   periph-clk  |-- mci0_clk@21
> >   clk  9  [   ]   periph-clk  |-- mci1_clk@22
> >   clk  10  [   ]   periph-clk  |-- spi0_clk@24
> >   clk  11  [   ]   periph-clk  `-- spi1_clk@25
> > Could not initialize timer (err -19)
> >
>
>

[PATCH] mtd: spi-nor-ids: Add Macronix MX66UW2G345G

[zhengxun]

The MX66UW2G345G is Macronix Flash with SINGLE and OCTAL I/O. Hence,
add SPI_NOR_OCTAL_READ flag for this flash.

Signed-off-by: zhengxun 
---
 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 2b57797954..8d2b73b676 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -167,6 +167,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("mx66l1g45g",  0xc2201b, 0, 64 * 1024, 2048, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("mx25l1633e", 0xc22415, 0, 64 * 1024,   32, SPI_NOR_QUAD_READ | 
SPI_NOR_4B_OPCODES | SECT_4K) },
{ INFO("mx25r6435f", 0xc22817, 0, 64 * 1024,   128,  SECT_4K) },
+   { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
 #endif
 
 #ifdef CONFIG_SPI_FLASH_STMICRO/* STMICRO */
-- 
2.17.1

SAMA5D3 Xplained: SPL broken after panic added to /lib/time.c:94

[Manuel Luís Reis]

Hello,

I've been having issues with SPL booting in the SAMA5D3 Xplained board
getting the following error, with up-to-date mainline U-boot and
sama5d3_xplained _mmc_defconfig:

---
RomBOOT


Could not initialize timer (err -19)
.
---

I could trace back the error to commit 4b2be78.

This topic has been raised before on
http://u-boot.10912.n7.nabble.com/PATCH-v2-time-Fix-get-ticks-being-non-monotonic-td426172.html
Tried the suggestions there with the same result.

I'm am not too knowledgeable with U-Boot nor this board. Could you shed
some light on this? Any pointers would be appreciated.

Let me know if you require additional information.

Cheers,
Manuel

Output from dm_dump_all():

 Class Index  Probed  DriverName
---
 root  0  [ + ]   root_driver  root_driver
 simple_bus  0  [   ]   simple_bus  `-- ahb
 simple_bus  1  [   ]   simple_bus  `-- apb
 mmc  0  [   ]   atmel-mci  |-- mmc@f000
 blk  0  [   ]   mmc_blk  |   `-- m...@f000.blk
 mmc  1  [   ]   atmel-mci  |-- mmc@f800
 blk  1  [   ]   mmc_blk  |   `-- m...@f800.blk
 serial  0  [   ]   serial_atmel  |-- serial@ee00
 pinctrl  0  [   ]   atmel_sama5d3_pinctrl  |-- pinctrl@f200
 pinconfig  0  [   ]   pinconfig  |   |-- dbgu
 pinconfig  1  [   ]   pinconfig  |   |   `-- dbgu-0
 pinconfig  2  [   ]   pinconfig  |   |-- mmc0
 pinconfig  3  [   ]   pinconfig  |   |   |-- mmc0_clk_cmd_dat0
 pinconfig  4  [   ]   pinconfig  |   |   |-- mmc0_dat1_3
 pinconfig  5  [   ]   pinconfig  |   |   `-- mmc0_dat4_7
 pinconfig  6  [   ]   pinconfig  |   |-- mmc1
 pinconfig  7  [   ]   pinconfig  |   |   |-- mmc1_clk_cmd_dat0
 pinconfig  8  [   ]   pinconfig  |   |   `-- mmc1_dat1_3
 pinconfig  9  [   ]   pinconfig  |   |-- spi0
 pinconfig  10  [   ]   pinconfig  |   |   `-- spi0-0
 pinconfig  11  [   ]   pinconfig  |   |-- spi1
 pinconfig  12  [   ]   pinconfig  |   |   `-- spi1-0
 pinconfig  13  [   ]   pinconfig  |   `-- board
 pinconfig  14  [   ]   pinconfig  |   |-- mmc0_cd
 pinconfig  15  [   ]   pinconfig  |   `-- mmc1_cd
 gpio  0  [   ]   atmel_at91rm9200_gpio  |-- gpio@f200
 gpio  1  [   ]   atmel_at91rm9200_gpio  |-- gpio@f400
 gpio  2  [   ]   atmel_at91rm9200_gpio  |-- gpio@f600
 gpio  3  [   ]   atmel_at91rm9200_gpio  |-- gpio@f800
 gpio  4  [   ]   atmel_at91rm9200_gpio  |-- gpio@fa00
 simple_bus  2  [   ]   at91-pmc  `-- pmc@fc00
 clk  0  [   ]   at91sam9x5-utmi-clk  |-- utmick
 clk  1  [   ]   at91-master-clk  |-- masterck
 misc  0  [   ]   sam9x5-periph-clk  `-- periphck
 clk  2  [   ]   periph-clk  |-- dbgu_clk@2
 clk  3  [   ]   periph-clk  |-- pioA_clk@6
 clk  4  [   ]   periph-clk  |-- pioB_clk@7
 clk  5  [   ]   periph-clk  |-- pioC_clk@8
 clk  6  [   ]   periph-clk  |-- pioD_clk@9
 clk  7  [   ]   periph-clk  |-- pioE_clk@10
 clk  8  [   ]   periph-clk  |-- mci0_clk@21
 clk  9  [   ]   periph-clk  |-- mci1_clk@22
 clk  10  [   ]   periph-clk  |-- spi0_clk@24
 clk  11  [   ]   periph-clk  `-- spi1_clk@25
Could not initialize timer (err -19)

[PATCH] mtd: spi-nor-ids: Add Macronix MX66UW2G345G

[zhengxun]

The MX66UW2G345G is Macronix Flash with SINGLE and OCTAL I/O. Hence,
add SPI_NOR_OCTAL_READ flag for this flash.

Signed-off-by: zhengxun 
---
 drivers/mtd/spi/spi-nor-ids.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mtd/spi/spi-nor-ids.c b/drivers/mtd/spi/spi-nor-ids.c
index 2b57797954..8d2b73b676 100644
--- a/drivers/mtd/spi/spi-nor-ids.c
+++ b/drivers/mtd/spi/spi-nor-ids.c
@@ -167,6 +167,7 @@ const struct flash_info spi_nor_ids[] = {
{ INFO("mx66l1g45g",  0xc2201b, 0, 64 * 1024, 2048, SECT_4K | 
SPI_NOR_DUAL_READ | SPI_NOR_QUAD_READ) },
{ INFO("mx25l1633e", 0xc22415, 0, 64 * 1024,   32, SPI_NOR_QUAD_READ | 
SPI_NOR_4B_OPCODES | SECT_4K) },
{ INFO("mx25r6435f", 0xc22817, 0, 64 * 1024,   128,  SECT_4K) },
+   { INFO("mx66uw2g345g", 0xc2943c, 0, 64 * 1024, 4096, SECT_4K | 
SPI_NOR_OCTAL_READ | SPI_NOR_4B_OPCODES) },
 #endif
 
 #ifdef CONFIG_SPI_FLASH_STMICRO/* STMICRO */
-- 
2.17.1

Re: [PATCH] Revert "mmc: sdhci: set to INT_DATA_END when there are data"

[Jaehoon Chung]

Hi Andy,

On 3/18/21 10:59 AM, andy...@sony.com wrote:

Hi


I don't want to revert this commit. Is there any issue without this?

Without revert commit 17ea3c86, Some board, like Dragonboard 410c will meet
transfer data timeout error (we used v2018.01):

U-Boot 2018.01 (Nov 26 2020 - 03:31:09 +)
Qualcomm-DragonBoard 410C

DRAM:  986 MiB
MMC:   sdhci@07824000: 0, sdhci@07864000: 1
sdhci_transfer_data: Transfer data timeout
mmc_init: -70, time 10645
*** Warning - No block device, using default environment

And it seems the 17ea3c86 not followed the sdhci specification as
transfer complete bit should be wait for the BUSY status de-assert.

Kernel side code also wait the transfer complete bit for response-with-busy
command.


Did you test on latest u-boot?  v2018.01 was too old version.

And if my understanding is right, INT_DATA_END needs to set when there 
is a data.


If there is no data, it doesn't need to set to it. Logically, there is 
no problem, isn't?


I will check with QC 410C board for clarifying this problem.




Without this patch, some SoCs have timeout error with stop command.

Sorry, we didn't meet this stop command timeout issue, but I guess it maybe
another issue, and can be fixed with modification limited to stop command,
not for all response-with-busy command.

Does the SDHCI_QUIRK_BROKEN_R1B can be used for this case?


Well, it can be used.

Best Regards,

Jaehoon Chung



Best Regards
Andy Wu


-Original Message-
From: U-Boot  On Behalf Of Jaehoon Chung
Sent: Thursday, March 18, 2021 6:44 AM
To: Mo, Yuezhang ; u-boot@lists.denx.de
Cc: peng@nxp.com; c...@samsung.com
Subject: Re: [PATCH] Revert "mmc: sdhci: set to INT_DATA_END when there are
data"

Hi

On 3/17/21 3:44 PM, yuezhang...@sony.com wrote:

This reverts commit 17ea3c862865c0d704646f67dbf8412f9ff54f59.

In eMMC specification, for the response-with-busy(R1b, R5b) command,
the DAT0 will driven to LOW as BUSY status, and in sdhci
specification, the transfer complete bit should be wait for BUSY
status de-assert.

All response-with-busy commands don't contain data, the data judgement
is no need.


I don't want to revert this commit. Is there any issue without this?
Without this patch, some SoCs have timeout error with stop command.

To prevent it, it needs to increase timeout value at that time.
(Timeout value can't fix each boards, waste time to find proper value, and be
performance degradation.)

I didn't test without this patch on latest U-boot.
But if there is no critical issue, keep it, plz.

Best Regards,
Jaehoon Chung


Signed-off-by: Yuezhang.Mo 
---
  drivers/mmc/sdhci.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/mmc/sdhci.c b/drivers/mmc/sdhci.c index
d9ab6a0a83..8568f65b18 100644
--- a/drivers/mmc/sdhci.c
+++ b/drivers/mmc/sdhci.c
@@ -258,8 +258,7 @@ static int sdhci_send_command(struct mmc *mmc,

struct mmc_cmd *cmd,

flags = SDHCI_CMD_RESP_LONG;
else if (cmd->resp_type & MMC_RSP_BUSY) {
flags = SDHCI_CMD_RESP_SHORT_BUSY;
-   if (data)
-   mask |= SDHCI_INT_DATA_END;
+   mask |= SDHCI_INT_DATA_END;
} else
flags = SDHCI_CMD_RESP_SHORT;

Re: [PATCH RFT 0/4] pci: add common Designware PCIe functions and support Amlogic Meson PCIe controller

[Shawn Lin]

Hi Neil,

On 2021/3/22 17:18, Neil Armstrong wrote:

With the introduction of pcie_dw_rockchip, and need to support the DW PCIe in 
the
Amlogic AXG & G12 SoCs, most of the DW PCIe helpers would be duplicated.

This introduce a "common" DW PCIe helpers file with common code merged from the
dw_ti and dw_rockchip drivers and adapted to fit with the upcoming dw_meson.


That's a good idea.

BTW, pcie_dw_mvebu.c and  pcie_imx.c also should need a migration.



The following changes will switch the dw_ti and dw_rockchip, and introduce a new
driver to support the Amlogic AXG & G12 SoCs using these new common helpers.

The dw_meson has been validated, but the dw_ti and dw_rockchip would need 
testing
on hardware to validate nothing has been broken.

Neil Armstrong (4):
   pci: add common Designware PCIe functions
   pci: pcie_dw_ti: migrate to common Designware PCIe functions
   pci: pcie_dw_rockchip: migrate to common Designware PCIe functions
   pci: add Amlogic Meson Designware PCIe controller

  drivers/pci/Kconfig|  15 +-
  drivers/pci/Makefile   |   2 +
  drivers/pci/pcie_dw_common.c   | 352 
  drivers/pci/pcie_dw_common.h   | 153 +++
  drivers/pci/pcie_dw_meson.c| 459 
  drivers/pci/pcie_dw_rockchip.c | 472 ++---
  drivers/pci/pcie_dw_ti.c   | 444 +++
  7 files changed, 1046 insertions(+), 851 deletions(-)
  create mode 100644 drivers/pci/pcie_dw_common.c
  create mode 100644 drivers/pci/pcie_dw_common.h
  create mode 100644 drivers/pci/pcie_dw_meson.c

[PATCH] driver: spi: renesas_rpc_spi: Add mem_ops

[zhengxun]

This patch adds an implementation of exec_op, which support octal
mode and quad mode for reading flash and support existing single
mode for reading and writing flash concurrently.

Signed-off-by: zhengxun 
---
 drivers/spi/renesas_rpc_spi.c | 144 ++
 1 file changed, 144 insertions(+)

diff --git a/drivers/spi/renesas_rpc_spi.c b/drivers/spi/renesas_rpc_spi.c
index 26b6aa85c9..b317995dae 100644
--- a/drivers/spi/renesas_rpc_spi.c
+++ b/drivers/spi/renesas_rpc_spi.c
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define RPC_CMNCR  0x  /* R/W */
@@ -368,6 +369,144 @@ err:
return ret;
 }
 
+static int rpc_spi_exec_mem_op(struct spi_slave *slave,
+  const struct spi_mem_op *op)
+{
+   struct rpc_spi_priv *priv;
+   struct udevice *bus;
+   u32 wloop = (op->data.dir == SPI_MEM_DATA_OUT) ?
+DIV_ROUND_UP(op->data.nbytes, 4) : 0;
+   u32 smenr, smcr, cmncr;
+   u32 *datout;
+   int ret = 0;
+
+   bus = slave->dev->parent;
+   priv = dev_get_priv(bus);
+
+   if (op->cmd.buswidth == 2 || op->addr.buswidth == 2 ||
+   op->data.buswidth == 2 || op->addr.nbytes > 4)
+   return -ENOTSUPP;
+
+   smenr = 0;
+
+   if (op->data.dir == SPI_MEM_DATA_OUT ||
+   op->data.dir == SPI_MEM_NO_DATA) {
+   rpc_spi_claim_bus(slave->dev, true);
+
+   writel(0, priv->regs + RPC_SMCR);
+
+   /* Commnad(1) */
+   writel(RPC_SMCMR_CMD(op->cmd.opcode), priv->regs + RPC_SMCMR);
+
+   smenr |= RPC_SMENR_CDE;
+
+   smenr |= RPC_SMENR_CDB(fls(op->cmd.buswidth) - 1);
+
+   /* Address(3 or 4) */
+   if (op->addr.nbytes) {
+   writel(op->addr.val, priv->regs + RPC_SMADR);
+   if (op->addr.nbytes == 3)
+   smenr |= RPC_SMENR_ADE(0x7);
+   else
+   smenr |= RPC_SMENR_ADE(0xf);
+   smenr |= RPC_SMENR_ADB(fls(op->addr.buswidth) - 1);
+   } else {
+   writel(0, priv->regs + RPC_SMADR);
+   }
+
+   /* Dummy(0) */
+   writel(0, priv->regs + RPC_SMDMCR);
+
+   writel(0, priv->regs + RPC_SMOPR);
+
+   writel(0, priv->regs + RPC_SMDRENR);
+
+   /* Data(n) */
+   if (op->data.nbytes) {
+   datout = (u32 *)op->data.buf.out;
+
+   smenr |= RPC_SMENR_SPIDE(0xf);
+
+   smenr |= RPC_SMENR_SPIDB(fls(op->data.buswidth) - 1);
+
+   while (wloop--) {
+   smcr = RPC_SMCR_SPIWE | RPC_SMCR_SPIE;
+   if (wloop >= 1)
+   smcr |= RPC_SMCR_SSLKP;
+   writel(smenr, priv->regs + RPC_SMENR);
+   writel(*datout, priv->regs + RPC_SMWDR0);
+   writel(smcr, priv->regs + RPC_SMCR);
+   ret = rpc_spi_wait_tend(slave->dev);
+   if (ret)
+   goto err;
+   datout++;
+   smenr = RPC_SMENR_SPIDE(0xf);
+   }
+
+   ret = rpc_spi_wait_sslf(slave->dev);
+   } else {
+   writel(smenr, priv->regs + RPC_SMENR);
+   writel(RPC_SMCR_SPIE, priv->regs + RPC_SMCR);
+   ret = rpc_spi_wait_tend(slave->dev);
+   }
+   } else {/* Read data only, using DRx ext access */
+   rpc_spi_claim_bus(slave->dev, false);
+
+   if (op->cmd.buswidth > 4 || op->addr.buswidth > 4 ||
+   op->data.buswidth > 4) {
+   cmncr = readl(priv->regs + RPC_CMNCR);
+   cmncr |= RPC_CMNCR_BSZ(1);
+   writel(cmncr, priv->regs + RPC_CMNCR);
+   }
+
+   /* Command(1) */
+   writel(RPC_DRCMR_CMD(op->cmd.opcode), priv->regs + RPC_DRCMR);
+
+   smenr |= RPC_DRENR_CDE;
+
+   smenr |= RPC_DRENR_CDB(fls(op->cmd.buswidth) - 1);
+
+   /* Address(3 or 4) */
+   if (op->addr.nbytes) {
+   if (op->addr.nbytes == 3)
+   smenr |= RPC_DRENR_ADE(0x7);
+   else
+   smenr |= RPC_DRENR_ADE(0xf);
+   smenr |= RPC_DRENR_ADB(fls(op->addr.buswidth) - 1);
+   }
+
+   /* Dummy(n) */
+   if (op->dummy.nbytes) {
+   writel(op->dummy.nbytes, priv->regs + RPC_DRDMCR);
+   smenr |= RPC_DRENR_DME;
+   } else {

Re: [PATCH 0/4] Add rt-thread art-pi board support

[dillon min]

Hi,

Just a gentle ping.

On Thu, Mar 11, 2021 at 2:44 PM  wrote:
>
> From: dillon min 
>
> These patches aim to adds u-boot support on art-pi board.
>
> the board resources:
> - stm32h750xbh6 128k flash, 1024k sram
> - 32MiB sdram
> - 16MiB spi flash
> - 8MiB qspi flash
> - onboard wifi, bt, fm
>
> the detail board information can be found at:
> https://art-pi.gitee.io/website/
>
> dillon min (4):
>   ARM: dts: stm32: split sdram pin & timing parameter into specific
> board dts
>   ARM: dts: stm32: Add RT-Thread art-pi board support
>   board: Add rt-thread art-pi board support
>   ram: stm32: fix strsep failed on read only memory
>
>  arch/arm/dts/Makefile|   3 +-
>  arch/arm/dts/stm32h7-u-boot.dtsi |  95 
>  arch/arm/dts/stm32h743.dtsi  |   8 +
>  arch/arm/dts/stm32h743i-disco-u-boot.dtsi|  98 
>  arch/arm/dts/stm32h743i-eval-u-boot.dtsi |  98 
>  arch/arm/dts/stm32h750-pinctrl.dtsi  | 319 
> +++
>  arch/arm/dts/stm32h750.dtsi  |   5 +
>  arch/arm/dts/stm32h750i-art-pi-u-boot.dtsi   |  81 +++
>  arch/arm/dts/stm32h750i-art-pi.dts   |  75 +++
>  arch/arm/mach-stm32/stm32h7/Kconfig  |   4 +
>  board/st/stm32h750-art-pi/Kconfig|  19 ++
>  board/st/stm32h750-art-pi/MAINTAINERS|   7 +
>  board/st/stm32h750-art-pi/Makefile   |   6 +
>  board/st/stm32h750-art-pi/stm32h750-art-pi.c |  58 +
>  configs/stm32h750-art-pi_defconfig   |  51 +
>  drivers/ram/stm32_sdram.c|   3 +
>  include/configs/stm32h750-art-pi.h   |  48 
>  include/dt-bindings/memory/stm32-sdram.h |   2 +
>  18 files changed, 884 insertions(+), 96 deletions(-)
>  create mode 100644 arch/arm/dts/stm32h750-pinctrl.dtsi
>  create mode 100644 arch/arm/dts/stm32h750.dtsi
>  create mode 100644 arch/arm/dts/stm32h750i-art-pi-u-boot.dtsi
>  create mode 100644 arch/arm/dts/stm32h750i-art-pi.dts
>  create mode 100644 board/st/stm32h750-art-pi/Kconfig
>  create mode 100644 board/st/stm32h750-art-pi/MAINTAINERS
>  create mode 100644 board/st/stm32h750-art-pi/Makefile
>  create mode 100644 board/st/stm32h750-art-pi/stm32h750-art-pi.c
>  create mode 100644 configs/stm32h750-art-pi_defconfig
>  create mode 100644 include/configs/stm32h750-art-pi.h
>
> --
> 2.7.4
>

RE: [v1 2/2] arm: socfpga: Changed to store QSPI reference clock in kHz

[Tan, Ley Foon]

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Monday, March 15, 2021 10:37 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 2/2] arm: socfpga: Changed to store QSPI reference clock in kHz
> 
> Changed to store QSPI reference clock in kHz instead of Hz in boot scratch
> cold0 register for Stratix10 and Agilex.
> 
> This patch is in preparation for Intel N5X SDRAM driver support. Reserved 4
> bits for Intel N5X SDRAM driver, and there will be 28 bits to store QSPI
> reference clock.
> Due to limited bits, QSPI reference clock frequency is converted to kHz from
> Hz.
> 
> Signed-off-by: Siew Chin Lim 
> Signed-off-by: Tien Fong Chee 
> ---
>  arch/arm/mach-socfpga/clock_manager.c  |  5 +--
>  .../include/mach/system_manager_soc64.h| 16 -
>  arch/arm/mach-socfpga/mailbox_s10.c| 40
> +++---
>  include/configs/socfpga_soc64_common.h |  1 +
>  4 files changed, 55 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/mach-socfpga/clock_manager.c b/arch/arm/mach-
> socfpga/clock_manager.c
> index be426a5cfb..2783b9d18d 100644
> --- a/arch/arm/mach-socfpga/clock_manager.c
> +++ b/arch/arm/mach-socfpga/clock_manager.c
> @@ -67,8 +67,9 @@ int set_cpu_clk_info(void)  #if
> IS_ENABLED(CONFIG_TARGET_SOCFPGA_SOC64)
>  unsigned int cm_get_qspi_controller_clk_hz(void)
>  {
> - return readl(socfpga_get_sysmgr_addr() +
> -  SYSMGR_SOC64_BOOT_SCRATCH_COLD0);
> + return (readl(socfpga_get_sysmgr_addr() +
> +  SYSMGR_SOC64_BOOT_SCRATCH_COLD0) &
> +  SYSMGR_SCRATCH_REG_0_QSPI_REFCLK_MASK) *
> CLOCK_1K;
>  }
>  #endif
> 
> 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 1eb8e7a904..fc4e17821b 100644
> --- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
> +++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
> @@ -42,7 +42,10 @@ void populate_sysmgr_pinmux(void);
>  #define SYSMGR_SOC64_GPO 0xe4
>  #define SYSMGR_SOC64_GPI 0xe8
>  #define SYSMGR_SOC64_MPU 0xf0
> -/* store qspi ref clock */
> +/*
> + * Bits[31:28] reserved for N5X DDR retention, bits[27:0] reserved for
> +SOC 64-bit
> + * storing qspi ref clock (kHz)
> + */
>  #define SYSMGR_SOC64_BOOT_SCRATCH_COLD0  0x200
>  /* store osc1 clock freq */
>  #define SYSMGR_SOC64_BOOT_SCRATCH_COLD1  0x204
> @@ -85,6 +88,17 @@ void populate_sysmgr_pinmux(void);
>  #define SYSMGR_SOC64_HPS_OSC_CLK 0x1358
>  #define SYSMGR_SOC64_IODELAY00x1400
> 
> +/*
> + * Bits for SYSMGR_SOC64_BOOT_SCRATCH_COLD0
> + * Bits[31:28] reserved for DM DDR retention, bits[27:0] reserved for
> +SOC 64-bit
> + * storing qspi ref clock (kHz)
> + */
> +#define SYSMGR_SCRATCH_REG_0_QSPI_REFCLK_MASK
>   GENMASK(27, 0)
> +#define ALT_SYSMGR_SCRATCH_REG_0_DDR_RETENTION_MASK  BIT(31)
> +#define ALT_SYSMGR_SCRATCH_REG_0_DDR_SHA_MASKBIT(30)
> +#define ALT_SYSMGR_SCRATCH_REG_0_DDR_RESET_TYPE_MASK
>   (BIT(29) | BIT(28))
> +#define ALT_SYSMGR_SCRATCH_REG_0_DDR_RESET_TYPE_SHIFT28
> +
>  #define SYSMGR_SDMMC
>   SYSMGR_SOC64_SDMMC
> 
>  #define SYSMGR_ROMCODEGRP_CTRL_WARMRSTCFGPINMUX  BIT(0)
> diff --git a/arch/arm/mach-socfpga/mailbox_s10.c b/arch/arm/mach-
> socfpga/mailbox_s10.c
> index 7dcdae8136..2a13fbb506 100644
> --- a/arch/arm/mach-socfpga/mailbox_s10.c
> +++ b/arch/arm/mach-socfpga/mailbox_s10.c
> @@ -356,6 +356,38 @@ int mbox_qspi_close(void)
>0, NULL, 0, 0, NULL);
>  }
> 
> +int mbox_qspi_set_controller_clk_hz(int clk_hz) {
This function nothing related to mailbox. Change to other name and move the 
function to the place read qspi clock.
Then can remove define CLOCK_1K from socfpga_soc64_common.h.


> + u32 reg;
> + u32 clk_khz;
> +
> + /* We are getting QSPI ref clock and set into sysmgr boot register */
> + /*
> +  * Only clock freq in kHz degree is accepted due to limited bits[27:0]
> +  * is reserved for storing the QSPI clock freq into boot scratch cold0
> +  * register
> +  */
> + if (clk_hz < CLOCK_1K)
> + return -EINVAL;
> +
> + clk_khz = clk_hz / CLOCK_1K;
> + printf("QSPI: Reference clock at %d kHz\n", clk_khz);
> +
> + /*
> +  * DDR retention bit, SHA comparison bit and reset type bits sharing
> the
> +  * same scratch register in N5X, ensure the content inside register is
> +  * not overwritten by QSPI ref clock (kHz)
> +  */
Comment doesn't need to mention about DDR retention. This is for N5X only.
This just to clear the intended bits only.


> + reg = (readl(socfpga_get_sysmgr_addr() +
> +   

RE: [v1 1/2] arm: socfpga: Move Stratix10 and Agilex clock manager common code

[Tan, Ley Foon]

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Monday, March 15, 2021 10:37 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 1/2] arm: socfpga: Move Stratix10 and Agilex clock manager
> common code
> 
> Move duplicated function cm_get_qspi_controller_clk_hz to
> clock_manager.c.
> 
> Signed-off-by: Siew Chin Lim 
> Signed-off-by: Tien Fong Chee 
> ---
>  arch/arm/mach-socfpga/clock_manager.c  | 15 ---
>  arch/arm/mach-socfpga/clock_manager_agilex.c   |  6 --
>  arch/arm/mach-socfpga/clock_manager_s10.c  |  6 --
>  arch/arm/mach-socfpga/include/mach/clock_manager.h |  4 
>  arch/arm/mach-socfpga/include/mach/clock_manager_s10.h |  1 -
>  5 files changed, 16 insertions(+), 16 deletions(-)
> 
[...]


>  unsigned int cm_get_spi_controller_clk_hz(void)
>  {
>   u32 clock = cm_get_l3_main_clk_hz();
> diff --git a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> index 1f734bcd65..0f0cb230fa 100644
> --- a/arch/arm/mach-socfpga/include/mach/clock_manager.h
> +++ b/arch/arm/mach-socfpga/include/mach/clock_manager.h
> @@ -12,6 +12,10 @@ 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);
> +
> +#if defined(CONFIG_TARGET_SOCFPGA_SOC64)
> +unsigned int cm_get_qspi_controller_clk_hz(void);
> +#endif
>  #endif
If this is for soc64, move to _SOC64.h file?



Regards
Ley Foon

RE: [v1 5/5] arm: socfpga: Restructure Stratix10 and Agilex handoff code

[Tan, Ley Foon]

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Monday, March 15, 2021 5:43 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 5/5] arm: socfpga: Restructure Stratix10 and Agilex handoff code
> 
> Restructure Stratix10 and Agilex handoff code to used by all SOC64 devices,
> in preparation to support handoff for Diamond Mesa.
> 
> Remove wrap_pinmux_config_s10.c. Add wrap_handoff_soc64.c which
> contains the generic function to parse the handoff data.
> 
> Update system_manager_soc64.c to use generic handoff function in
> wrap_handoff_soc64.c.
> 
> Signed-off-by: Siew Chin Lim 
> ---
>  arch/arm/mach-socfpga/Makefile |  4 +-
>  arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 21 +++
>  .../include/mach/system_manager_soc64.h|  4 --
>  arch/arm/mach-socfpga/system_manager_soc64.c   | 53 ++-
> -
>  arch/arm/mach-socfpga/wrap_handoff_soc64.c | 73
> ++
> 
> diff --git a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> index 2561255712..f4c03688d6 100644
> --- a/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> +++ b/arch/arm/mach-socfpga/include/mach/handoff_soc64.h
> @@ -11,6 +11,7 @@
>   * Offset for HW handoff from Quartus tools
>   */
>  /* HPS handoff */
> +#define SOC64_HANDOFF_MAGIC_BOOT 0x424F4F54
>  #define SOC64_HANDOFF_MAGIC_MUX  0x504D5558
>  #define SOC64_HANDOFF_MAGIC_IOCTL0x494F4354
>  #define SOC64_HANDOFF_MAGIC_FPGA 0x46504741
> @@ -38,4 +39,24 @@
>  #define SOC64_HANDOFF_CLOCK_FPGA (SOC64_HANDOFF_BASE +
> 0x600)
>  #endif
> 
> +#define SOC64_HANDOFF_MUX_LEN96
> +#define SOC64_HANDOFF_IOCTL_LEN  96
> +#ifdef CONFIG_TARGET_SOCFPGA_STRATIX10
Can change to #if CONFIG_IS_ENABLED()


> +#define SOC64_HANDOFF_FPGA_LEN   42
> +#else
> +#define SOC64_HANDOFF_FPGA_LEN   40
> +#endif
> +#define SOC64_HANDOFF_DELAY_LEN  96
> +
> +#ifndef __ASSEMBLY__
> +#include 
> +enum endianness {
> + little_endian,
> + big_endian
> +};
Uses capital letter for enum macros.

> +
> +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);
> +#endif
>  #endif /* _HANDOFF_SOC64_H_ */
> 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 4949cae97a..1eb8e7a904 100644
> --- a/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
> +++ b/arch/arm/mach-socfpga/include/mach/system_manager_soc64.h
> @@ -10,10 +10,6 @@
>  void sysmgr_pinmux_init(void);
>  void populate_sysmgr_fpgaintf_module(void);
>  void populate_sysmgr_pinmux(void);
> -void sysmgr_pinmux_table_sel(const u32 **table, unsigned int *table_len);
> -void sysmgr_pinmux_table_ctrl(const u32 **table, unsigned int *table_len);
> -void sysmgr_pinmux_table_fpga(const u32 **table, unsigned int
> *table_len); -void sysmgr_pinmux_table_delay(const u32 **table, unsigned
> int *table_len);
> 
>  #define SYSMGR_SOC64_WDDBG   0x08
>  #define SYSMGR_SOC64_DMA 0x20

[...]

> diff --git a/arch/arm/mach-socfpga/wrap_handoff_soc64.c
> b/arch/arm/mach-socfpga/wrap_handoff_soc64.c
> new file mode 100644
> index 00..ba168676e9
> --- /dev/null
> +++ b/arch/arm/mach-socfpga/wrap_handoff_soc64.c
> @@ -0,0 +1,73 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * Copyright (C) 2020 Intel Corporation 
> + *
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "log.h"
Sort this.


> +
> +int socfpga_get_handoff_size(void *handoff_address, enum endianness
> +endian) {
> + u32 handoff_size;
> +
> + if (endian == little_endian) {
> + handoff_size = (readl(handoff_address +
> SOC64_HANDOFF_OFFSET_LENGTH) -
> + SOC64_HANDOFF_OFFSET_DATA) /
> + sizeof(u32);
> + } else if (endian == big_endian) {
> + handoff_size = swab32(readl(handoff_address +
> +
Can merge this, just need do additional swab32 if it is bit endian.


[.]


> +
> +int socfpga_handoff_read(void *handoff_address, void *table, u32
> table_len,
> +  enum endianness big_endian)
> +{
> + u32 temp, i;
> + u32 *table_x32 = table;
> +
> + debug("%s: handoff addr = 0x%p ", __func__, (u32
> *)handoff_address);
> +
> + if (big_endian) {
> + if (swab32(readl(SOC64_HANDOFF_BASE)) ==
> SOC64_HANDOFF_MAGIC_BOOT) {
> + debug("Handoff table address = 0x%p ", table_x32);
> + debug("table 

[PATCH] x86: mtrr: Fix function descriptions

[Wolfgang Wallner]

Fix copy/paste errors in the descriptions of mtrr_close () and mtrr_set().

Signed-off-by: Wolfgang Wallner 

---

 arch/x86/include/asm/mtrr.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/x86/include/asm/mtrr.h b/arch/x86/include/asm/mtrr.h
index 3a98aacdef..384672e93f 100644
--- a/arch/x86/include/asm/mtrr.h
+++ b/arch/x86/include/asm/mtrr.h
@@ -103,7 +103,7 @@ struct mtrr_info {
 void mtrr_open(struct mtrr_state *state, bool do_caches);
 
 /**
- * mtrr_open() - Clean up after adjusting MTRRs, and enable them
+ * mtrr_close() - Clean up after adjusting MTRRs, and enable them
  *
  * This uses the structure containing information returned from mtrr_open().
  *
@@ -170,7 +170,7 @@ void mtrr_read_all(struct mtrr_info *info);
 int mtrr_set_valid(int cpu_select, int reg, bool valid);
 
 /**
- * mtrr_set() - Set the valid flag for a selected MTRR and CPU(s)
+ * mtrr_set() - Set the base address and mask for a selected MTRR and CPU(s)
  *
  * @cpu_select: Selected CPUs (either a CPU number or MP_SELECT_...)
  * @reg: MTRR register to write (0-7)
-- 
2.30.2

RE: [v1 4/5] arm: socfpga: Rearrange sequence of macros in handoff_soc64.h

[Tan, Ley Foon]

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Monday, March 15, 2021 5:43 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 4/5] arm: socfpga: Rearrange sequence of macros in
> handoff_soc64.h
> 
> Rearrange sequence of macros in handoff_soc64.h without any functionality
> change. In preparation for Stratix10 and Agilex handoff function 
> restructuring.
> 
> Signed-off-by: Siew Chin Lim 
> ---
>  arch/arm/mach-socfpga/include/mach/handoff_soc64.h | 22
> --
>  1 file changed, 12 insertions(+), 10 deletions(-)
> 


Reviewed-by: Ley Foon Tan 

RE: [v1 3/5] arm: socfpga: Changed system_manager_s10.c to system_manager_soc64.c

[Tan, Ley Foon]

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Monday, March 15, 2021 5:43 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 3/5] arm: socfpga: Changed system_manager_s10.c to
> system_manager_soc64.c
> 
> Rename to common file name to used by all SOC64 devices.
> No functionality change.
> 
> Signed-off-by: Siew Chin Lim 
> ---

Reviewed-by: Ley Foon Tan 

RE: [v1 2/5] arm: socfpga: Changed wrap_pll_config_s10.c to wrap_pll_config_soc64.c

[Tan, Ley Foon]

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Monday, March 15, 2021 5:43 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 2/5] arm: socfpga: Changed wrap_pll_config_s10.c to
> wrap_pll_config_soc64.c
> 
> Rename to common file name to used by all SOC64 devices.
> 
> Signed-off-by: Siew Chin Lim 
> ---


Reviewed-by: Ley Foon Tan 

[PATCH] dt-bindings: fsp: Fix Apollo Lake FSP-S devicetree bindings

[Wolfgang Wallner]

An entry is missing in the FSP-S devicetree bindings, and as a result
the description for the next few following entries is off by one line.

Signed-off-by: Wolfgang Wallner 

---

 .../fsp/fsp2/apollolake/fsp-s.txt | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt 
b/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt
index b605ed0056..dc8e3251a3 100644
--- a/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt
+++ b/doc/device-tree-bindings/fsp/fsp2/apollolake/fsp-s.txt
@@ -258,19 +258,20 @@ Optional properties:
 - fsps,pcie-rp-clk-req-detect: CLKREQ# Detection
 - fsps,advanced-error-reportingt: Advanced Error Reporting
 - fsps,pme-interrupt: PME Interrupt
-- fsps,fatal-error-report: URR
-- fsps,no-fatal-error-report: FER
-- fsps,correctable-error-report: NFER
-- fsps,system-error-on-fatal-error: CER
-- fsps,system-error-on-non-fatal-error: SEFE
-- fsps,system-error-on-correctable-error: SENFE
-- fsps,pcie-rp-speed: SECE
-- fsps,physical-slot-number: PCIe Speed
+- fsps,unsupported-request-report: URR
+- fsps,fatal-error-report: FER
+- fsps,no-fatal-error-report: NFER
+- fsps,correctable-error-report: CER
+- fsps,system-error-on-fatal-error: SEFE
+- fsps,system-error-on-non-fatal-error: SENFE
+- fsps,system-error-on-correctable-error: SECE
+- fsps,pcie-rp-speed: PCIe Speed
+- fsps,physical-slot-number: Physical Slot Number
   0: Auto (default)
   1: Gen1
   2: Gen2
   3: Gen3
-- fsps,pcie-rp-completion-timeout: Physical Slot Number
+- fsps,pcie-rp-completion-timeout: CTO
   0x00, 0x01, 0x02, 0x03, 0x04, 0x05 (default)
 - fsps,enable-ptm: PTM Support
 - fsps,pcie-rp-aspm: ASPM
-- 
2.30.2

[RFC PATCH v2 2/2] board: sifive: unmatched: clear feature disable CSR

[Green Wan]

Clear feature disable CSR to turn on all features of hart. The detail
is specified at section, 'SiFive Feature Disable CSR', in user manual

https://sifive.cdn.prismic.io/sifive/aee0dd4c-d156-496e-a6c4-db0cf54bbe68_sifive_U74MC_rtl_full_20G1.03.00_manual.pdf

Signed-off-by: Green Wan 
---
 board/sifive/unmatched/spl.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/board/sifive/unmatched/spl.c b/board/sifive/unmatched/spl.c
index 5e1333b09a..d09d129dc9 100644
--- a/board/sifive/unmatched/spl.c
+++ b/board/sifive/unmatched/spl.c
@@ -22,6 +22,19 @@
 #define MODE_SELECT_SD 0xb
 #define MODE_SELECT_MASK   GENMASK(3, 0)
 
+void riscv_hart_early_init(void)
+{
+#if CONFIG_IS_ENABLED(RISCV_MMODE)
+   /*
+* Feature Disable CSR
+*
+* Clear feature disable CSR to '0' to turn on all features for
+* each core. This operatioin must be in m-mode.
+*/
+   asm volatile ("csrwi 0x7c1, 0");
+#endif
+}
+
 int spl_board_init_f(void)
 {
int ret;
-- 
2.31.0

[RFC PATCH v2 1/2] arch: riscv: cpu: Add callback to init each core

[Green Wan]

Add a callback riscv_hart_early_init() to ./arch/riscv/cpu/start.S to
allow different riscv hart perform setup code for each hart as early
as possible. Since all the harts enter the calback, they must be able
to run the same setup.

Signed-off-by: Green Wan 
---
 arch/riscv/cpu/start.S | 5 +
 arch/riscv/lib/spl.c   | 4 
 2 files changed, 9 insertions(+)

diff --git a/arch/riscv/cpu/start.S b/arch/riscv/cpu/start.S
index 8589509e01..5c7d4da9e2 100644
--- a/arch/riscv/cpu/start.S
+++ b/arch/riscv/cpu/start.S
@@ -117,6 +117,11 @@ call_board_init_f_0:
mv  sp, a0
 #endif
 
+#if CONFIG_IS_ENABLED(RISCV_MMODE)
+call_riscv_hart_early_init:
+   jal riscv_hart_early_init
+#endif
+
 #ifndef CONFIG_XIP
/*
 * Pick hart to initialize global data and run U-Boot. The other harts
diff --git a/arch/riscv/lib/spl.c b/arch/riscv/lib/spl.c
index 8baee07bea..e5b1affbfc 100644
--- a/arch/riscv/lib/spl.c
+++ b/arch/riscv/lib/spl.c
@@ -14,6 +14,10 @@
 
 DECLARE_GLOBAL_DATA_PTR;
 
+__weak void riscv_hart_early_init(void)
+{
+}
+
 __weak int spl_board_init_f(void)
 {
return 0;
-- 
2.31.0

RE: [v1 1/5] arm: socfpga: Rename Stratix10 and Agilex handoff common macros

[Tan, Ley Foon]

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Monday, March 15, 2021 5:43 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [v1 1/5] arm: socfpga: Rename Stratix10 and Agilex handoff common
> macros
> 
> Rename handoff_s10.h to handoff_soc64.h. Changed macros prefix from
> S10_HANDOFF to SOC64_HANDOFF.
> 
> Signed-off-by: Siew Chin Lim 
> ---

Reviewed-by: Ley Foon Tan 

RE: [PATCH] arm: socfpga: Move Stratix10 and Agilex SPL common code

[Tan, Ley Foon]

> -Original Message-
> From: Lim, Elly Siew Chin 
> Sent: Monday, March 15, 2021 3:59 PM
> To: u-boot@lists.denx.de
> Cc: Marek Vasut ; Tan, Ley Foon
> ; See, Chin Liang ;
> Simon Goldschmidt ; Chee, Tien Fong
> ; Westergreen, Dalon
> ; Simon Glass ; Gan,
> Yau Wai ; Lim, Elly Siew Chin
> 
> Subject: [PATCH] arm: socfpga: Move Stratix10 and Agilex SPL common code
> 
> Move Stratix10 and Agilex SPL common code to spl_soc64.c.
> We are in preparation for new n5x device support.
> No functional change in this patch.
> 
> Signed-off-by: Siew Chin Lim 


Reviewed-by: Ley Foon Tan 

Re: [PATCH RFT 0/4] pci: add common Designware PCIe functions and support Amlogic Meson PCIe controller

[Neil Armstrong]

Hi Green,


On 23/03/2021 05:36, Green Wan wrote:
> Hi Neil,
> 
> pcie_dw_common.* is a good starting point. I'd like to spend time on this. 
> Please add me into the loop. Thanks.

Sure, I'll CC you on the next revision, in the meantime don't hesitate to 
comment and/or post the changes
needed for sifive.

Neil

> 
> -
> Green

[GIT PULL] SoCFPGA changes for v2021.04-rc5

[Tan, Ley Foon]

Hi Tom

Please pull one fix for v2021.04-rc5.

Thanks.

Regards
Ley Foon

The following changes since commit 1f9c3f13f6ad8595a0fb5ab2cb830583cdc0b60a:

  Merge tag 'efi-2021-04-rc5-2' of 
https://source.denx.de/u-boot/custodians/u-boot-efi (2021-03-20 08:55:18 -0400)

are available in the Git repository at:

  https://github.com/lftan/u-boot.git v2021.04-rc5

for you to fetch changes up to 2dbcc037ccf3a16a2a0225133f8721b87ae7fffb:

  arm: socfpga: Only do 'is OS booted from FIT' checking when VAB is enabled 
(2021-03-23 14:46:35 +0800)


Siew Chin Lim (1):
  arm: socfpga: Only do 'is OS booted from FIT' checking when VAB is enabled

 arch/arm/mach-socfpga/board.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

Re: [RFC PATCH] arch: riscv: cpu: Add callback to init each core

[Green Wan]

On Tue, Mar 23, 2021 at 1:07 PM Bin Meng  wrote:

> Hi Green,
>
> On Tue, Mar 23, 2021 at 12:12 PM Green Wan  wrote:
> >
> > Hi Bin,
> >
> > I can move it to the place right after stacks for harts are set up and
> right before picking up the lottery hart. (like below) How about the
> function name? Do we come up with a better function name?
> mach_cpu_core_init() is similar to mach_cpu_init() in include/init.h. It
> could cause confusion.
>
> How about riscv_core_early_init(), or riscv_hart_early_init()?
>

I'll vote for riscv_hart_early_init() and create the v2 patch based on it.

Thanks,


> Regards,
> Bin
>

Re: [PATCH 02/16] drivers: reset: Handle gracefully NULL pointers

[Kishon Vijay Abraham I]

Hi Simon,

On 23/03/21 6:26 am, Simon Glass wrote:
> Hi Kishon,
> 
> On Mon, 22 Mar 2021 at 18:11, Kishon Vijay Abraham I  wrote:
>>
>> Hi Simon,
>>
>> On 12/03/21 10:15 am, Simon Glass wrote:
>>> Hi Kishon,
>>>
>>> On Tue, 9 Mar 2021 at 05:27, Kishon Vijay Abraham I  wrote:

 From: Jean-Jacques Hiblot 

 Prepare the way for a managed reset API by handling NULL pointers without
 crashing nor failing.

 Signed-off-by: Jean-Jacques Hiblot 
 Signed-off-by: Vignesh Raghavendra 
 Signed-off-by: Kishon Vijay Abraham I 
 ---
  drivers/reset/reset-uclass.c | 30 +-
  1 file changed, 17 insertions(+), 13 deletions(-)
>>>
>>> Why do you want this? This patch is missing the motivation which
>>> should be at the start of the commit message.
>>
>> This is for "optional" reset controllers used by peripheral drivers.
>> This will help avoid adding checks in peripheral drivers.
> 
> Can you please be more specific?

Sorry for not being clear.

Cadence Torrent SERDES has a reset line for APB (APB_RESET). This reset
line is connected in Cadence platform but not connected in TI platform
which also uses the Torrent SERDES.

So in the Cadence Torrent driver we use
devm_reset_control_get_optional() which returns NULL when used in TI
platform. However if we use the return value of
devm_reset_control_get_optional() directly in reset_ops (for TI), it
will result in abort.

This patch helps to avoid adding additional checks before invoking
reset_ops.

Thanks
Kishon