Skip to contentSkip to conversation

armv8/fsl-lsch3: Implement workaround for erratum A008585

PATCH Superseded York Sun 8 participants 69 messages Mar 19, 2015 – Mar 27, 2015 1 message not in the archive

Subsystems (9)

v1 of 6 Superseded Latest is v6 →

lore
Share & tools
lore

York Sun

author
#0 lore raw

PATCH 1/28 armv8/fsl-lsch3: Implement workaround for erratum A008585

Generic Timer may contain an erroneous value. The workaround is to read it twice until getting the same value.

---
 arch/arm/cpu/armv8/generic_timer.c           |   11 +++++++++++
 arch/arm/include/asm/arch-fsl-lsch3/config.h |    1 +
 2 files changed, 12 insertions(+)
arch/arm/cpu/armv8/generic_timer.c +11 -0
index 223b95e..8e60bae 100644
@@ -25,7 +25,18 @@ unsigned long get_tbclk(void)
 unsigned long timer_read_counter(void)
 {
 	unsigned long cntpct;
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008585
+	/* This erratum number needs to be confirmed to match ARM document */
+	unsigned long temp;
+#endif
 	isb();
 	asm volatile("mrs %0, cntpct_el0" : "=r" (cntpct));
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008585
+	asm volatile("mrs %0, cntpct_el0" : "=r" (temp));
+	while (temp != cntpct) {
+		asm volatile("mrs %0, cntpct_el0" : "=r" (cntpct));
+		asm volatile("mrs %0, cntpct_el0" : "=r" (temp));
+	}
+#endif
 	return cntpct;
 }
arch/arm/include/asm/arch-fsl-lsch3/config.h +1 -0
index 1d2a7fa..2d461d9 100644
@@ -120,6 +120,7 @@
 #ifdef CONFIG_LS2085A
 #define CONFIG_SYS_FSL_ERRATUM_A008336
 #define CONFIG_SYS_FSL_ERRATUM_A008514
+#define CONFIG_SYS_FSL_ERRATUM_A008585
 #endif
 
 #endif /* _ASM_ARMV8_FSL_LSCH3_CONFIG_ */
Signature · 1 line
1.7.9.5
author
#1 lore raw

PATCH 2/28 armv8/ls2085a: Update common header file

From: Prabhakar Kushwaha <[email protected]>

ls2085a_common.h contains hard-coded information for NOR/NAND flash, I2C, DDR, etc. These are platform specific. Move them out of common header file and placed into respective board header files.

Move TEXTBASE to 1MB offset to fit NOR flash with up to 1MB sector size.

Enable command auto complete. Update prompt symbol. Set fdt_high to 0xa0000000 because Linux requires that the fdt be 8-byte aligned and below 512 MiB. Besides ensuring compliance with the 512 MiB limit, this avoids problems with the dtb being misaligned within the FIT image.

Change the MC FW, MC DPL and Debug server NOR addresses in compliance with the NOR flash layouts for 128MB flash.

Add PCIe macros. Enable "loadb" command. Disable debug server. Enable workaround for erratum A008511.
Stop reset on panic for postmortem debugging.

---
 arch/arm/include/asm/arch-fsl-lsch3/config.h |   11 ++
 include/configs/ls2085a_common.h             |  142 ++++++--------------------
 include/configs/ls2085a_emu.h                |   62 +++++++++++
 include/configs/ls2085a_simu.h               |  117 +++++++++++++++++++++
 4 files changed, 222 insertions(+), 110 deletions(-)
arch/arm/include/asm/arch-fsl-lsch3/config.h +11 -0
index 2d461d9..518e59c 100644
@@ -108,6 +108,16 @@
 /* IFC */
 #define CONFIG_SYS_FSL_IFC_LE
 
+/* PCIe */
+#define CONFIG_SYS_PCIE1_ADDR			(CONFIG_SYS_IMMR + 0x2400000)
+#define CONFIG_SYS_PCIE2_ADDR			(CONFIG_SYS_IMMR + 0x2500000)
+#define CONFIG_SYS_PCIE3_ADDR			(CONFIG_SYS_IMMR + 0x2600000)
+#define CONFIG_SYS_PCIE4_ADDR			(CONFIG_SYS_IMMR + 0x2700000)
+#define CONFIG_SYS_PCIE1_PHYS_ADDR		0x1000000000ULL
+#define CONFIG_SYS_PCIE2_PHYS_ADDR		0x1200000000ULL
+#define CONFIG_SYS_PCIE3_PHYS_ADDR		0x1400000000ULL
+#define CONFIG_SYS_PCIE4_PHYS_ADDR		0x1600000000ULL
+
 #ifdef CONFIG_LS2085A
 #define CONFIG_MAX_CPUS				16
 #define CONFIG_SYS_FSL_IFC_BANK_COUNT		8
@@ -119,6 +129,7 @@
 
 #ifdef CONFIG_LS2085A
 #define CONFIG_SYS_FSL_ERRATUM_A008336
+#define CONFIG_SYS_FSL_ERRATUM_A008511
 #define CONFIG_SYS_FSL_ERRATUM_A008514
 #define CONFIG_SYS_FSL_ERRATUM_A008585
 #endif
include/configs/ls2085a_common.h +32 -110

239 lines not on this page · raw message

include/configs/ls2085a_emu.h +62 -0

74 lines not on this page · raw message

include/configs/ls2085a_simu.h +117 -0

131 lines not on this page · raw message

Signature · 1 line
1.7.9.5
author
#2 lore raw

PATCH 3/28 armv8/fsl-lsch3: Fix platform clock calculation

In reply to York Sun

Platform clock is half of platform PLL. There is an additional divisor in place. Clean up code copied from powerpc.

---
 arch/arm/cpu/armv8/fsl-lsch3/speed.c |    7 +++----
 1 file changed, 3 insertions(+), 4 deletions(-)
arch/arm/cpu/armv8/fsl-lsch3/speed.c +3 -4
index 72cd999..2b140cd 100644
@@ -86,6 +86,8 @@ void get_sys_info(struct sys_info *sys_info)
 	sys_info->freq_systembus *= (in_le32(&gur->rcwsr[0]) >>
 			FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_SHIFT) &
 			FSL_CHASSIS3_RCWSR0_SYS_PLL_RAT_MASK;
+	/* Platform clock is half of platform PLL */
+	sys_info->freq_systembus /= 2;
 	sys_info->freq_ddrbus *= (in_le32(&gur->rcwsr[0]) >>
 			FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_SHIFT) &
 			FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_MASK;
@@ -102,10 +104,7 @@ void get_sys_info(struct sys_info *sys_info)
 			 offsetof(struct ccsr_clk_cluster_group,
 				  pllngsr[i%3].gsr));
 		ratio[i] = (in_le32(offset) >> 1) & 0x3f;
-		if (ratio[i] > 4)
-			freq_c_pll[i] = sysclk * ratio[i];
-		else
-			freq_c_pll[i] = sys_info->freq_systembus * ratio[i];
+		freq_c_pll[i] = sysclk * ratio[i];
 	}
 
 	for_each_cpu(i, cpu, cpu_numcores(), cpu_mask()) {
Signature · 1 line
1.7.9.5
author
#3 lore raw

PATCH 4/28 armv8/ls2085a: Fix generic timer clock source

In reply to York Sun

The timer clock is system clock divided by 4, not fixed 12MHz. This is common to the SoC, not board specific.

---
 README                             |    8 ++++++++
 arch/arm/cpu/armv8/fsl-lsch3/cpu.c |   24 ++++++++++++++++++++++++
 board/freescale/ls2085a/ls2085a.c  |   18 ------------------
 include/configs/ls2085a_common.h   |    6 +++++-
 4 files changed, 37 insertions(+), 19 deletions(-)
README +8 -0
index f473515..776ebf4 100644
@@ -690,6 +690,14 @@ The following options need to be configured:
 		exists, unlike the similar options in the Linux kernel. Do not
 		set these options unless they apply!
 
+		COUNTER_FREQUENCY
+		Generic timer clock source frequency.
+
+		COUNTER_FREQUENCY_REAL
+		Generic timer clock source frequency if the real clock is
+		different from COUNTER_FREQUENCY, and can only be determined
+		at run time.
+
 		NOTE: The following can be machine specific errata. These
 		do have ability to provide rudimentary version and machine
 		specific checks, but expect no product checks.
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +24 -0
index 94fd147..e985181 100644
@@ -395,3 +395,27 @@ int arch_early_init_r(void)
 
 	return 0;
 }
+
+int timer_init(void)
+{
+	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
+	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
+#ifdef COUNTER_FREQUENCY_REAL
+	unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
+
+	/* Update with accurate clock frequency */
+	asm volatile("msr cntfrq_el0, %0" : : "r" (cntfrq) : "memory");
+#endif
+
+	/* Enable timebase for all clusters.
+	 * It is safe to do so even some clusters are not enabled.
+	 */
+	out_le32(cltbenr, 0xf);
+
+	/* Enable clock for timer
+	 * This is a global setting.
+	 */
+	out_le32(cntcr, 0x1);
+
+	return 0;
+}
board/freescale/ls2085a/ls2085a.c +0 -18
index e78c63a..bd016e9 100644
@@ -55,24 +55,6 @@ int dram_init(void)
 	return 0;
 }
 
-int timer_init(void)
-{
-	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
-	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
-
-	/* Enable timebase for all clusters.
-	 * It is safe to do so even some clusters are not enabled.
-	 */
-	out_le32(cltbenr, 0xf);
-
-	/* Enable clock for timer
-	 * This is a global setting.
-	 */
-	out_le32(cntcr, 0x1);
-
-	return 0;
-}
-
 /*
  * Board specific reset that is system reset.
  */
include/configs/ls2085a_common.h +5 -1
index 339337d..b47cf68 100644
@@ -72,7 +72,11 @@
 #define CONFIG_DP_DDR_NUM_CTRLS		1
 
 /* Generic Timer Definitions */
-#define COUNTER_FREQUENCY		12000000	/* 12MHz */
+/*
+ * This is not an accurate number. It is used in start.S. The frequency
+ * will be udpated later when get_bus_freq(0) is available.
+ */
+#define COUNTER_FREQUENCY		25000000	/* 25MHz */
 
 /* Size of malloc() pool */
 #define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + 2048 * 1024)
Signature · 1 line
1.7.9.5
#4 lore raw

PATCH 4/28 armv8/ls2085a: Fix generic timer clock source

Quoted 39 lines · York Sun

The timer clock is system clock divided by 4, not fixed 12MHz. This is common to the SoC, not board specific.

---
 README                             |    8 ++++++++
 arch/arm/cpu/armv8/fsl-lsch3/cpu.c |   24 ++++++++++++++++++++++++
 board/freescale/ls2085a/ls2085a.c  |   18 ------------------
 include/configs/ls2085a_common.h   |    6 +++++-
 4 files changed, 37 insertions(+), 19 deletions(-)
README +8 -0
index f473515..776ebf4 100644
@@ -690,6 +690,14 @@ The following options need to be configured:
 		exists, unlike the similar options in the Linux kernel. Do not
 		set these options unless they apply!
 
+		COUNTER_FREQUENCY
+		Generic timer clock source frequency.
+
+		COUNTER_FREQUENCY_REAL
+		Generic timer clock source frequency if the real clock is
+		different from COUNTER_FREQUENCY, and can only be determined
+		at run time.
+
 		NOTE: The following can be machine specific errata. These
 		do have ability to provide rudimentary version and machine
 		specific checks, but expect no product checks.
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +1 -0
index 94fd147..e985181 100644
@@ -395,3 +395,27 @@ int arch_early_init_r(void)
 
 	return 0;
 }
+

arch/arm/cpu/armv8/fsl-lsch3/cpu.c int arch_early_init_r(void) · line 408

Quoted 10 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +10 -0
+int timer_init(void)
+{
+	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
+	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
+#ifdef COUNTER_FREQUENCY_REAL
+	unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
+
+	/* Update with accurate clock frequency */
+	asm volatile("msr cntfrq_el0, %0" : : "r" (cntfrq) : "memory");
+#endif

Is this executed on all CPUs, or do secondary CPUs have CNTFRQ programmed with the correct value elsewhere?

Mark.

author
#5 lore raw

PATCH 4/28 armv8/ls2085a: Fix generic timer clock source

Quoted 6 lines · Mark Rutland
Quoted 6 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +6 -0
+
+int timer_init(void)
+{
+	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
+	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
+#ifdef COUNTER_FREQUENCY_REAL
Quoted 9 lines

arch/arm/cpu/armv8/fsl-lsch3/cpu.c int arch_early_init_r(void) · line 408

Quoted 5 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +5 -0
+	unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
+
+	/* Update with accurate clock frequency */
+	asm volatile("msr cntfrq_el0, %0" : : "r" (cntfrq) : "memory");
+#endif

Is this executed on all CPUs, or do secondary CPUs have CNTFRQ programmed with the correct value elsewhere?

Only the primary CPU runs here. The secondary CPU doesn't come here.

York

#6 lore raw

PATCH 4/28 armv8/ls2085a: Fix generic timer clock source

Quoted 17 lines · York Sun
Quoted 6 lines · Mark Rutland
Quoted 6 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +6 -0
+
+int timer_init(void)
+{
+	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
+	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
+#ifdef COUNTER_FREQUENCY_REAL
Quoted 9 lines

arch/arm/cpu/armv8/fsl-lsch3/cpu.c int arch_early_init_r(void) · line 408

Quoted 5 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +5 -0
+	unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
+
+	/* Update with accurate clock frequency */
+	asm volatile("msr cntfrq_el0, %0" : : "r" (cntfrq) : "memory");
+#endif

Is this executed on all CPUs, or do secondary CPUs have CNTFRQ programmed with the correct value elsewhere?

Quoted 1 line

Only the primary CPU runs here. The secondary CPU doesn't come here.

Ok. Where does CNTFRQ get programmed for those CPUs?

If it's necessary to write COUNTER_FREQUENCY_REAL to the primary CPU's CNTFRQ, that's also necessary on the secondaries before they enter the OS.

Mark.

author
#7 lore raw

PATCH 4/28 armv8/ls2085a: Fix generic timer clock source

Quoted 18 lines · Mark Rutland
Quoted 17 lines · York Sun
Quoted 15 lines · Mark Rutland

arch/arm/cpu/armv8/fsl-lsch3/cpu.c int arch_early_init_r(void) · line 408

Quoted 11 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +11 -0
+
+int timer_init(void)
+{
+	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
+	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
+#ifdef COUNTER_FREQUENCY_REAL
+	unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
+
+	/* Update with accurate clock frequency */
+	asm volatile("msr cntfrq_el0, %0" : : "r" (cntfrq) : "memory");
+#endif

Is this executed on all CPUs, or do secondary CPUs have CNTFRQ programmed with the correct value elsewhere?

Quoted 7 lines
Quoted 1 line

Only the primary CPU runs here. The secondary CPU doesn't come here.

Ok. Where does CNTFRQ get programmed for those CPUs?

If it's necessary to write COUNTER_FREQUENCY_REAL to the primary CPU's CNTFRQ, that's also necessary on the secondaries before they enter the OS.

Hmm, this may be a bug. Didn't hear any complain from Linux users. We found the timer wasn't correct during bring-up. Let me check with internal team.

Thanks, Mark.

York

#8 lore raw

PATCH 4/28 armv8/ls2085a: Fix generic timer clock source

Quoted 21 lines · York Sun
Quoted 20 lines · Mark Rutland
Quoted 18 lines · York Sun
Quoted 6 lines · Mark Rutland
Quoted 6 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +6 -0
+
+int timer_init(void)
+{
+	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
+	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
+#ifdef COUNTER_FREQUENCY_REAL
Quoted 9 lines

arch/arm/cpu/armv8/fsl-lsch3/cpu.c int arch_early_init_r(void) · line 408

Quoted 5 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +5 -0
+	unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
+
+	/* Update with accurate clock frequency */
+	asm volatile("msr cntfrq_el0, %0" : : "r" (cntfrq) : "memory");
+#endif

Is this executed on all CPUs, or do secondary CPUs have CNTFRQ programmed with the correct value elsewhere?

Only the primary CPU runs here. The secondary CPU doesn't come here.

Quoted 8 lines
Quoted 5 lines

Ok. Where does CNTFRQ get programmed for those CPUs?

If it's necessary to write COUNTER_FREQUENCY_REAL to the primary CPU's CNTFRQ, that's also necessary on the secondaries before they enter the OS.

Hmm, this may be a bug. Didn't hear any complain from Linux users. We found the timer wasn't correct during bring-up. Let me check with internal team.

Cheers!

If the CPUs don't have matching CNTFRQ, things will work most of the time, but timekeeping will be broken in some cases (e.g. KVM guests, after a kexec). It's not possible for the OS to fix this up, so the boot protocol requires that it's programmed on all CPUs prior to entering the kernel.

Since commit 127161aaf0fcd376 ("arm64: add runtime system sanity checks"), Linux should complain at boot time if CNTFRQ is mismatched across CPUs. We've added other sanity checks since that commit.

Mark.

author
#9 lore raw

PATCH 4/28 armv8/ls2085a: Fix generic timer clock source

Quoted 39 lines · Mark Rutland
Quoted 21 lines · York Sun
Quoted 20 lines · Mark Rutland
Quoted 18 lines · York Sun
Quoted 6 lines · Mark Rutland
Quoted 6 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +6 -0
+
+int timer_init(void)
+{
+	u32 __iomem *cntcr = (u32 *)CONFIG_SYS_FSL_TIMER_ADDR;
+	u32 __iomem *cltbenr = (u32 *)CONFIG_SYS_FSL_PMU_CLTBENR;
+#ifdef COUNTER_FREQUENCY_REAL
Quoted 9 lines

arch/arm/cpu/armv8/fsl-lsch3/cpu.c int arch_early_init_r(void) · line 408

Quoted 5 lines
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +5 -0
+	unsigned long cntfrq = COUNTER_FREQUENCY_REAL;
+
+	/* Update with accurate clock frequency */
+	asm volatile("msr cntfrq_el0, %0" : : "r" (cntfrq) : "memory");
+#endif

Is this executed on all CPUs, or do secondary CPUs have CNTFRQ programmed with the correct value elsewhere?

Only the primary CPU runs here. The secondary CPU doesn't come here.

Quoted 8 lines
Quoted 5 lines

Ok. Where does CNTFRQ get programmed for those CPUs?

If it's necessary to write COUNTER_FREQUENCY_REAL to the primary CPU's CNTFRQ, that's also necessary on the secondaries before they enter the OS.

Hmm, this may be a bug. Didn't hear any complain from Linux users. We found the timer wasn't correct during bring-up. Let me check with internal team.

Cheers!

If the CPUs don't have matching CNTFRQ, things will work most of the time, but timekeeping will be broken in some cases (e.g. KVM guests, after a kexec). It's not possible for the OS to fix this up, so the boot protocol requires that it's programmed on all CPUs prior to entering the kernel.

Quoted 4 lines

Since commit 127161aaf0fcd376 ("arm64: add runtime system sanity checks"), Linux should complain at boot time if CNTFRQ is mismatched across CPUs. We've added other sanity checks since that commit.

I checked again. We don't have this Linux commit for internal development.

For u-boot, the secondary CPUs only have cntfrq set in start.S which is a compiling macro, not a real time value. We happen to have it same as the real value so no one observed any issue. If the board reference clock changes (which is possible), the clock needs to be fixed. I will update the patch after verification.

York

author
#10 lore raw

PATCH 5/28 armv8/ls2085a: Add support for reset request

In reply to York Sun

From: pankaj chauhan <[email protected]>

Add support for reset_cpu() by asserting RESET_REQ_B.

---
 arch/arm/cpu/armv8/fsl-lsch3/cpu.c |   11 +++++++++++
 board/freescale/ls2085a/ls2085a.c  |    7 -------
 2 files changed, 11 insertions(+), 7 deletions(-)
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +11 -0
index e985181..0e5aa5c 100644
@@ -419,3 +419,14 @@ int timer_init(void)
 
 	return 0;
 }
+
+void reset_cpu(ulong addr)
+{
+	u32 __iomem *rstcr = (u32 *)CONFIG_SYS_FSL_RST_ADDR;
+	u32 val;
+
+	/* Raise RESET_REQ_B */
+	val = in_le32(rstcr);
+	val |= 0x02;
+	out_le32(rstcr, val);
+}
board/freescale/ls2085a/ls2085a.c +0 -7
index bd016e9..19f5a7b 100644
@@ -55,13 +55,6 @@ int dram_init(void)
 	return 0;
 }
 
-/*
- * Board specific reset that is system reset.
- */
-void reset_cpu(ulong addr)
-{
-}
-
 #if defined(CONFIG_ARCH_MISC_INIT)
 int arch_misc_init(void)
 {
Signature · 1 line
1.7.9.5
author
#11 lore raw

PATCH 6/28 armv8/fsl-lsch3: Set nodes in DVM domain

In reply to York Sun

From: Scott Wood <[email protected]>

This is required for TLB invalidation broadcasts to work.

---
 arch/arm/cpu/armv8/fsl-lsch3/lowlevel.S      |    9 +++++++++
 arch/arm/include/asm/arch-fsl-lsch3/config.h |    6 ++++++
 2 files changed, 15 insertions(+)
arch/arm/cpu/armv8/fsl-lsch3/lowlevel.S +9 -0
index 886576e..1787168 100644
@@ -15,6 +15,15 @@
 ENTRY(lowlevel_init)
 	mov	x29, lr			/* Save LR */
 
+	/* Add fully-coherent masters to DVM domain */
+	ldr	x1, =CCI_MN_BASE
+	ldr	x2, [x1, #CCI_MN_RNF_NODEID_LIST]
+	str	x2, [x1, #CCI_MN_DVM_DOMAIN_CTL_SET]
+1:	ldr	x3, [x1, #CCI_MN_DVM_DOMAIN_CTL_SET]
+	mvn	x0, x3
+	tst	x0, x3		/* Wait for domain addition to complete */
+	b.ne	1b
+
 	/* Set the SMMU page size in the sACR register */
 	ldr	x1, =SMMU_BASE
 	ldr	w0, [x1, #0x10]
arch/arm/include/asm/arch-fsl-lsch3/config.h +6 -0
index 518e59c..9121452 100644
@@ -118,6 +118,12 @@
 #define CONFIG_SYS_PCIE3_PHYS_ADDR		0x1400000000ULL
 #define CONFIG_SYS_PCIE4_PHYS_ADDR		0x1600000000ULL
 
+/* Cache Coherent Interconnect */
+#define CCI_MN_BASE		0x04000000
+#define CCI_MN_RNF_NODEID_LIST		0x180
+#define CCI_MN_DVM_DOMAIN_CTL		0x200
+#define CCI_MN_DVM_DOMAIN_CTL_SET	0x210
+
 #ifdef CONFIG_LS2085A
 #define CONFIG_MAX_CPUS				16
 #define CONFIG_SYS_FSL_IFC_BANK_COUNT		8
Signature · 1 line
1.7.9.5
author
#12 lore raw

PATCH 7/28 armv8/fsl-lsch3: Update early MMU table

In reply to York Sun

During booting, IFC is mapped to low region. After booting up, IFC is remapped to high region for larger space. The environmental variables are also stored at high region. In order to read the variables during booting, a virtual mapping is required.

Cache was enabled for entire IFC space before. Actually the first two entries are big enough (4MB) to cover the boot code and environmental variables. Remove extra entries. Move OCRAM entry out of ifdef.

---
 arch/arm/cpu/armv8/fsl-lsch3/cpu.c |   56 +++++++++++++++++++++++++-----------
 common/board_r.c                   |    6 ++++
 2 files changed, 45 insertions(+), 17 deletions(-)
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +39 -17
index 0e5aa5c..595dbd1 100644
@@ -25,8 +25,9 @@ DECLARE_GLOBAL_DATA_PTR;
  * levels of translation tables here to cover 40-bit address space.
  * We use 4KB granule size, with 40 bits physical address, T0SZ=24
  * Level 0 IA[39], table address @0
- * Level 1 IA[31:30], table address @01000, 0x2000
- * Level 2 IA[29:21], table address @0x3000
+ * Level 1 IA[31:30], table address @0x1000, 0x2000
+ * Level 2 IA[29:21], table address @0x3000, 0x4000
+ * Address above 0x5000 is free for other purpose.
  */
 
 #define SECTION_SHIFT_L0	39UL
@@ -61,12 +62,12 @@ static inline void early_mmu_setup(void)
 {
 	int el;
 	u64 i;
-	u64 section_l1t0, section_l1t1, section_l2;
+	u64 section_l1t0, section_l1t1, section_l2t0, section_l2t1;
 	u64 *level0_table = (u64 *)CONFIG_SYS_FSL_OCRAM_BASE;
 	u64 *level1_table_0 = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x1000);
 	u64 *level1_table_1 = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x2000);
-	u64 *level2_table = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x3000);
-
+	u64 *level2_table_0 = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x3000);
+	u64 *level2_table_1 = (u64 *)(CONFIG_SYS_FSL_OCRAM_BASE + 0x4000);
 
 	level0_table[0] =
 		(u64)level1_table_0 | PMD_TYPE_TABLE;
@@ -80,21 +81,25 @@ static inline void early_mmu_setup(void)
 	 */
 	section_l1t0 = 0;
 	section_l1t1 = BLOCK_SIZE_L0;
-	section_l2 = 0;
+	section_l2t0 = 0;
+	section_l2t1 = CONFIG_SYS_FLASH_BASE;
 	for (i = 0; i < 512; i++) {
 		set_pgtable_section(level1_table_0, i, section_l1t0,
 				    MT_DEVICE_NGNRNE);
 		set_pgtable_section(level1_table_1, i, section_l1t1,
 				    MT_NORMAL);
-		set_pgtable_section(level2_table, i, section_l2,
+		set_pgtable_section(level2_table_0, i, section_l2t0,
+				    MT_DEVICE_NGNRNE);
+		set_pgtable_section(level2_table_1, i, section_l2t1,
 				    MT_DEVICE_NGNRNE);
 		section_l1t0 += BLOCK_SIZE_L1;
 		section_l1t1 += BLOCK_SIZE_L1;
-		section_l2 += BLOCK_SIZE_L2;
+		section_l2t0 += BLOCK_SIZE_L2;
+		section_l2t1 += BLOCK_SIZE_L2;
 	}
 
 	level1_table_0[0] =
-		(u64)level2_table | PMD_TYPE_TABLE;
+		(u64)level2_table_0 | PMD_TYPE_TABLE;
 	level1_table_0[1] =
 		0x40000000 | PMD_SECT_AF | PMD_TYPE_SECT |
 		PMD_ATTRINDX(MT_DEVICE_NGNRNE);
@@ -105,17 +110,34 @@ static inline void early_mmu_setup(void)
 		0xc0000000 | PMD_SECT_AF | PMD_TYPE_SECT |
 		PMD_ATTRINDX(MT_NORMAL);
 
-	/* Rewrite table to enable cache */
-	set_pgtable_section(level2_table,
+	/* Rewerite table to enable cache for OCRAM */
+	set_pgtable_section(level2_table_0,
 			    CONFIG_SYS_FSL_OCRAM_BASE >> SECTION_SHIFT_L2,
 			    CONFIG_SYS_FSL_OCRAM_BASE,
 			    MT_NORMAL);
-	for (i = CONFIG_SYS_IFC_BASE >> SECTION_SHIFT_L2;
-	     i < (CONFIG_SYS_IFC_BASE + CONFIG_SYS_IFC_SIZE)
-	     >> SECTION_SHIFT_L2; i++) {
-		section_l2 = i << SECTION_SHIFT_L2;
-		set_pgtable_section(level2_table, i,
-				    section_l2, MT_NORMAL);
+
+#if defined(CONFIG_SYS_NOR0_CSPR_EARLY) && defined(CONFIG_SYS_NOR_AMASK_EARLY)
+	/* Rewrite table to enable cache for two entries (4MB) */
+	section_l2t1 = CONFIG_SYS_IFC_BASE;
+	set_pgtable_section(level2_table_0,
+			    section_l2t1 >> SECTION_SHIFT_L2,
+			    section_l2t1,
+			    MT_NORMAL);
+	section_l2t1 += BLOCK_SIZE_L2;
+	set_pgtable_section(level2_table_0,
+			    section_l2t1 >> SECTION_SHIFT_L2,
+			    section_l2t1,
+			    MT_NORMAL);
+#endif
+
+	/* Create a mapping for 256MB IFC region to final flash location */
+	level1_table_0[CONFIG_SYS_FLASH_BASE >> SECTION_SHIFT_L1] =
+		(u64)level2_table_1 | PMD_TYPE_TABLE;
+	section_l2t1 = CONFIG_SYS_IFC_BASE;
+	for (i = 0; i < 0x10000000 >> SECTION_SHIFT_L2; i++) {
+		set_pgtable_section(level2_table_1, i,
+				    section_l2t1, MT_DEVICE_NGNRNE);
+		section_l2t1 += BLOCK_SIZE_L2;
 	}
 
 	el = current_el();
common/board_r.c +6 -0
index 0335f6b..d6dcc97 100644
@@ -699,6 +699,12 @@ init_fnc_t init_sequence_r[] = {
 	/* TODO: could x86/PPC have this also perhaps? */
 #ifdef CONFIG_ARM
 	initr_caches,
+	/* Note: For Freescale LS2 SoCs, new MMU table is created in DDR.
+	 *	 A temporary mapping of IFC high region is since removed,
+	 *	 so environmental variables in NOR flash is not availble
+	 *	 until board_init() is called below to remap IFC to high
+	 *	 region.
+	 */
 #endif
 	initr_reloc_global_data,
 #if defined(CONFIG_SYS_INIT_RAM_LOCK) && defined(CONFIG_E500)
Signature · 1 line
1.7.9.5
author
#13 lore raw

PATCH 8/28 fsl-lsch3: Introduce place for common early SoC init

In reply to York Sun

From: Scott Wood <[email protected]>

---
 arch/arm/cpu/armv8/fsl-lsch3/Makefile     |    1 +
 arch/arm/cpu/armv8/fsl-lsch3/soc.c        |   14 ++++++++++++++
 arch/arm/include/asm/arch-fsl-lsch3/soc.h |    8 ++++++++
 board/freescale/ls2085a/ls2085a.c         |    4 ++--
 4 files changed, 25 insertions(+), 2 deletions(-)
 create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/soc.c
 create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/soc.h
arch/arm/cpu/armv8/fsl-lsch3/Makefile +1 -0
index f920eeb..6542590 100644
@@ -6,6 +6,7 @@
 
 obj-y += cpu.o
 obj-y += lowlevel.o
+obj-y += soc.o
 obj-y += speed.o
 obj-$(CONFIG_MP) += mp.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
arch/arm/cpu/armv8/fsl-lsch3/soc.c new file +14 -0
new file mode 100644
index 0000000..242a865
@@ -0,0 +1,14 @@
+/*
+ * Copyright 2015 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <common.h>
+#include <fsl_ifc.h>
+#include <asm/arch-fsl-lsch3/soc.h>
+
+void fsl_lsch3_early_init_f(void)
+{
+	init_early_memctl_regs();	/* tighten IFC timing */
+}
arch/arm/include/asm/arch-fsl-lsch3/soc.h new file +8 -0
new file mode 100644
index 0000000..16b723d
@@ -0,0 +1,8 @@
+/*
+ * Copyright 2015 Freescale Semiconductor
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+void fsl_lsch3_early_init_f(void);
+
board/freescale/ls2085a/ls2085a.c +2 -2
index 19f5a7b..dd0acf2 100644
@@ -15,6 +15,7 @@
 #include <fsl_debug_server.h>
 #include <fsl-mc/fsl_mc.h>
 #include <environment.h>
+#include <asm/arch-fsl-lsch3/soc.h>
 
 DECLARE_GLOBAL_DATA_PTR;
 
@@ -31,8 +32,7 @@ int board_init(void)
 
 int board_early_init_f(void)
 {
-	init_early_memctl_regs();	/* tighten IFC timing */
-
+	fsl_lsch3_early_init_f();
 	return 0;
 }
 
Signature · 1 line
1.7.9.5
author
#14 lore raw

PATCH 9/28 armv8/ls2085a: Add workaround for USB erratum A-008751

In reply to York Sun

From: Scott Wood <[email protected]>

Without this "USB may not work" according to the erratum text, though I did not notice a problem without it.

---
 arch/arm/cpu/armv8/fsl-lsch3/soc.c           |   11 +++++++++++
 arch/arm/include/asm/arch-fsl-lsch3/config.h |    5 +++++
 2 files changed, 16 insertions(+)
arch/arm/cpu/armv8/fsl-lsch3/soc.c +11 -0
index 242a865..17700ef 100644
@@ -7,8 +7,19 @@
 #include <common.h>
 #include <fsl_ifc.h>
 #include <asm/arch-fsl-lsch3/soc.h>
+#include <asm/io.h>
+
+static void erratum_a008751(void)
+{
+#ifdef CONFIG_SYS_FSL_ERRATUM_A008751
+	u32 __iomem *scfg = (u32 __iomem *)SCFG_BASE;
+
+	writel(0x27672b2a, scfg + SCFG_USB3PRM1CR / 4);
+#endif
+}
 
 void fsl_lsch3_early_init_f(void)
 {
+	erratum_a008751();
 	init_early_memctl_regs();	/* tighten IFC timing */
 }
arch/arm/include/asm/arch-fsl-lsch3/config.h +5 -0
index 9121452..a81e3ed 100644
@@ -124,6 +124,10 @@
 #define CCI_MN_DVM_DOMAIN_CTL		0x200
 #define CCI_MN_DVM_DOMAIN_CTL_SET	0x210
 
+/* Supplemental Configuration */
+#define SCFG_BASE		0x01fc0000
+#define SCFG_USB3PRM1CR			0x000
+
 #ifdef CONFIG_LS2085A
 #define CONFIG_MAX_CPUS				16
 #define CONFIG_SYS_FSL_IFC_BANK_COUNT		8
@@ -138,6 +142,7 @@
 #define CONFIG_SYS_FSL_ERRATUM_A008511
 #define CONFIG_SYS_FSL_ERRATUM_A008514
 #define CONFIG_SYS_FSL_ERRATUM_A008585
+#define CONFIG_SYS_FSL_ERRATUM_A008751
 #endif
 
 #endif /* _ASM_ARMV8_FSL_LSCH3_CONFIG_ */
Signature · 1 line
1.7.9.5
author
#15 lore raw

PATCH 10/28 armv8/fsl-lsch3: Use correct compatible for serial clock fixup

In reply to York Sun

From: Scott Wood <[email protected]>

The serial nodes in the fsl-lsch3 device trees have compatible = "fsl,ns16550", "ns16550a" -- so don't look for "ns16550".

---
 arch/arm/cpu/armv8/fsl-lsch3/fdt.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
arch/arm/cpu/armv8/fsl-lsch3/fdt.c +1 -1
index 7eb9b6a..42c5b58 100644
@@ -62,7 +62,7 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 #endif
 
 #ifdef CONFIG_SYS_NS16550
-	do_fixup_by_compat_u32(blob, "ns16550",
+	do_fixup_by_compat_u32(blob, "fsl,ns16550",
 			       "clock-frequency", CONFIG_SYS_NS16550_CLK, 1);
 #endif
 }
Signature · 1 line
1.7.9.5
author
#16 lore raw

PATCH 11/28 driver/ldpaa_eth: Update ldpaa ethernet driver

In reply to York Sun

From: Prabhakar Kushwaha <[email protected]>

Fix flush_dcache_range() input parameter to use start and end addresses. Change ethernet interface name to DPNI. Update entry criteria for ldpaa_eth_stop. Ethernet stack first stop the device before performing next operation. At the time of Ethernet driver registration, net_dev->state is set as ETH_STATE_INIT So take care net_dev->state as ETH_STATE_INIT in ldpaa_eth_stop.

Undef CONFIG_PHYLIB temorarily because ldpaa_eth driver currently does not support PHYLIB.

Instead of clearing pull descriptor one time, clear it before issuing any volatile dequeue command.

Volatile command does not return frame immidiately, wait till a frame is available in DQRR. This frame can be valid or expired.

Flush buffer before releasing to BMan ensure the core does not have any cachelines that the WRIOP will DMA to.

---
 drivers/net/ldpaa_eth/ldpaa_eth.c |   62 +++++++++++++++++++++++--------------
 1 file changed, 38 insertions(+), 24 deletions(-)
drivers/net/ldpaa_eth/ldpaa_eth.c +38 -24
index b79942f..9015e4f 100644
@@ -15,6 +15,7 @@
 
 #include "ldpaa_eth.h"
 
+#undef CONFIG_PHYLIB
 static int init_phy(struct eth_device *dev)
 {
 	/*TODO for external PHY */
@@ -33,8 +34,6 @@ static void ldpaa_eth_rx(struct ldpaa_eth_priv *priv,
 	struct qbman_release_desc releasedesc;
 	struct qbman_swp *swp = dflt_dpio->sw_portal;
 
-	invalidate_dcache_all();
-
 	fd_addr = ldpaa_fd_get_addr(fd);
 	fd_offset = ldpaa_fd_get_offset(fd);
 	fd_length = ldpaa_fd_get_len(fd);
@@ -62,6 +61,7 @@ static void ldpaa_eth_rx(struct ldpaa_eth_priv *priv,
 	NetReceive((uint8_t *)(fd_addr)  + fd_offset, fd_length);
 
 error:
+	flush_dcache_range(fd_addr, fd_addr + LDPAA_ETH_RX_BUFFER_SIZE);
 	qbman_release_desc_clear(&releasedesc);
 	qbman_release_desc_set_bpid(&releasedesc, dflt_dpbp->dpbp_attr.bpid);
 	do {
@@ -76,22 +76,29 @@ static int ldpaa_eth_pull_dequeue_rx(struct eth_device *dev)
 	struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)dev->priv;
 	const struct ldpaa_dq *dq;
 	const struct dpaa_fd *fd;
-	int i = 5, err = 0, status;
+	int i = 5, err = 0, status, loop = 20;
 	static struct qbman_pull_desc pulldesc;
 	struct qbman_swp *swp = dflt_dpio->sw_portal;
 
-	qbman_pull_desc_clear(&pulldesc);
-	qbman_pull_desc_set_numframes(&pulldesc, 1);
-	qbman_pull_desc_set_fq(&pulldesc, priv->rx_dflt_fqid);
-
 	while (--i) {
+		qbman_pull_desc_clear(&pulldesc);
+		qbman_pull_desc_set_numframes(&pulldesc, 1);
+		qbman_pull_desc_set_fq(&pulldesc, priv->rx_dflt_fqid);
+
 		err = qbman_swp_pull(swp, &pulldesc);
 		if (err < 0) {
 			printf("Dequeue frames error:0x%08x\n", err);
 			continue;
 		}
 
-		dq = qbman_swp_dqrr_next(swp);
+		do {
+			loop--;
+			dq = qbman_swp_dqrr_next(swp);
+
+			if (!loop)
+				break;
+		} while (!dq);
+
 		if (dq) {
 			/* Check for valid frame. If not sent a consume
 			 * confirmation to QBMAN otherwise give it to NADK
@@ -128,7 +135,6 @@ static void ldpaa_eth_tx_conf(struct ldpaa_eth_priv *priv,
 	struct qbman_release_desc releasedesc;
 	struct qbman_swp *swp = dflt_dpio->sw_portal;
 
-	invalidate_dcache_all();
 	fd_addr = ldpaa_fd_get_addr(fd);
 
 
@@ -159,22 +165,29 @@ static int ldpaa_eth_pull_dequeue_tx_conf(struct ldpaa_eth_priv *priv)
 	const struct ldpaa_dq *dq;
 	const struct dpaa_fd *fd;
 	int err = 0;
-	int i = 5, status;
+	int i = 5, status, loop = 20;
 	static struct qbman_pull_desc pulldesc;
 	struct qbman_swp *swp = dflt_dpio->sw_portal;
 
-	qbman_pull_desc_clear(&pulldesc);
-	qbman_pull_desc_set_numframes(&pulldesc, 1);
-	qbman_pull_desc_set_fq(&pulldesc, priv->tx_conf_fqid);
-
 	while (--i) {
+		qbman_pull_desc_clear(&pulldesc);
+		qbman_pull_desc_set_numframes(&pulldesc, 1);
+		qbman_pull_desc_set_fq(&pulldesc, priv->tx_conf_fqid);
+
 		err =  qbman_swp_pull(swp, &pulldesc);
 		if (err < 0) {
 			printf("Dequeue TX conf frames error:0x%08x\n", err);
 			continue;
 		}
 
-		dq = qbman_swp_dqrr_next(swp);
+		do {
+			loop--;
+			dq = qbman_swp_dqrr_next(swp);
+
+			if (!loop)
+				break;
+		} while (!dq);
+
 		if (dq) {
 			/* Check for valid frame. If not sent a consume
 			 * confirmation to QBMAN otherwise give it to NADK
@@ -229,7 +242,8 @@ static int ldpaa_eth_tx(struct eth_device *net_dev, void *buf, int len)
 
 	memcpy(((uint8_t *)(buffer_start) + data_offset), buf, len);
 
-	flush_dcache_range(buffer_start, LDPAA_ETH_RX_BUFFER_SIZE);
+	flush_dcache_range(buffer_start, buffer_start +
+					LDPAA_ETH_RX_BUFFER_SIZE);
 
 	ldpaa_fd_set_addr(&fd, (u64)buffer_start);
 	ldpaa_fd_set_offset(&fd, (uint16_t)(data_offset));
@@ -297,10 +311,10 @@ static int ldpaa_eth_open(struct eth_device *net_dev, bd_t *bd)
 
 #ifdef CONFIG_PHYLIB
 	/* TODO Check this path */
-	ret = phy_startup(priv->phydev);
-	if (ret) {
+	err = phy_startup(priv->phydev);
+	if (err) {
 		printf("%s: Could not initialize\n", priv->phydev->dev->name);
-		return ret;
+		return err;
 	}
 #else
 	priv->phydev->speed = SPEED_1000;
@@ -361,7 +375,8 @@ static void ldpaa_eth_stop(struct eth_device *net_dev)
 	struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)net_dev->priv;
 	int err = 0;
 
-	if (net_dev->state == ETH_STATE_PASSIVE)
+	if ((net_dev->state == ETH_STATE_PASSIVE) ||
+	    (net_dev->state == ETH_STATE_INIT))
 		return;
 	/* Stop Tx and Rx traffic */
 	err = dpni_disable(dflt_mc_io, priv->dpni_handle);
@@ -422,6 +437,8 @@ static int ldpaa_bp_add_7(uint16_t bpid)
 			goto err_alloc;
 		}
 		memset(addr, 0x00, LDPAA_ETH_RX_BUFFER_SIZE);
+		flush_dcache_range((u64)addr,
+				   (u64)(addr + LDPAA_ETH_RX_BUFFER_SIZE));
 
 		buf_array[i] = (uint64_t)addr;
 		debug("Release: buffer addr =0x%p\n", addr);
@@ -623,10 +640,7 @@ static int ldpaa_eth_netdev_init(struct eth_device *net_dev)
 	int err;
 	struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)net_dev->priv;
 
-	if (priv->type == LDPAA_ETH_1G_E)
-		sprintf(net_dev->name, "DTSEC%d", priv->dpni_id);
-	else
-		sprintf(net_dev->name, "TGEC%d", priv->dpni_id);
+	sprintf(net_dev->name, "DPNI%d", priv->dpni_id);
 
 	net_dev->iobase = 0;
 	net_dev->init = ldpaa_eth_open;
Signature · 1 line
1.7.9.5
author
#17 lore raw

PATCH 12/28 armv8: Add SerDes framework for LayerScape Architecture

In reply to York Sun

From: Minghuan Lian <[email protected]>

Add support of SerDes framework for LayerScape Architecture.
- Add support of 2 SerDes block
- Add SerDes protocol parsing and detection
- Create table of SerDes protocol supported by LS2085A

---
 arch/arm/cpu/armv8/fsl-lsch3/Makefile              |    1 +
 arch/arm/cpu/armv8/fsl-lsch3/cpu.c                 |    4 +
 .../fsl-lsch3/fsl_lsch3_serdes.c}                  |   78 ++++++-------
 arch/arm/cpu/armv8/fsl-lsch3/ls2085a_serdes.c      |  117 ++++++++++++++++++++
 arch/arm/include/asm/arch-fsl-lsch3/config.h       |    4 +
 arch/arm/include/asm/arch-fsl-lsch3/fsl_serdes.h   |   67 +++++++++++
 arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h  |    5 +
 include/configs/ls2085a_common.h                   |    5 +
 8 files changed, 237 insertions(+), 44 deletions(-)
 copy arch/arm/cpu/{armv7/ls102xa/fsl_ls1_serdes.c => armv8/fsl-lsch3/fsl_lsch3_serdes.c} (51%)
 create mode 100644 arch/arm/cpu/armv8/fsl-lsch3/ls2085a_serdes.c
 create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/fsl_serdes.h
arch/arm/cpu/armv8/fsl-lsch3/Makefile +1 -0
index 6542590..9f7815b 100644
@@ -8,5 +8,6 @@ obj-y += cpu.o
 obj-y += lowlevel.o
 obj-y += soc.o
 obj-y += speed.o
+obj-$(CONFIG_SYS_HAS_SERDES) += fsl_lsch3_serdes.o ls2085a_serdes.o
 obj-$(CONFIG_MP) += mp.o
 obj-$(CONFIG_OF_LIBFDT) += fdt.o
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +4 -0
index 595dbd1..caa48f2 100644
@@ -12,6 +12,7 @@
 #include <asm/arch-fsl-lsch3/immap_lsch3.h>
 #include <fsl_debug_server.h>
 #include <fsl-mc/fsl_mc.h>
+#include <asm/arch/fsl_serdes.h>
 #include "cpu.h"
 #include "mp.h"
 #include "speed.h"
@@ -415,6 +416,9 @@ int arch_early_init_r(void)
 	if (rv)
 		printf("Did not wake secondary cores\n");
 
+#ifdef CONFIG_SYS_HAS_SERDES
+	fsl_serdes_init();
+#endif
 	return 0;
 }
 
arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c renamed from arch/arm/cpu/armv7/ls102xa/fsl_ls1_serdes.c +34 -44

145 lines not on this page · raw message

arch/arm/cpu/armv8/fsl-lsch3/ls2085a_serdes.c new file +117 -0

117 lines not on this page · raw message

arch/arm/include/asm/arch-fsl-lsch3/config.h +4 -0
index a81e3ed..98db1ef 100644
@@ -38,6 +38,8 @@
 #define CONFIG_SYS_FSL_PMU_CLTBENR		(CONFIG_SYS_FSL_PMU_ADDR + \
 						 0x18A0)
 
+#define CONFIG_SYS_FSL_LSCH3_SERDES_ADDR	(CONFIG_SYS_IMMR + 0xEA0000)
+
 /* SP (Cortex-A5) related */
 #define CONFIG_SYS_FSL_SP_ADDR			(CONFIG_SYS_IMMR + 0x00F00000)
 #define CONFIG_SYS_FSL_SP_VSG_GIC_ADDR		(CONFIG_SYS_FSL_SP_ADDR)
@@ -133,6 +135,8 @@
 #define CONFIG_SYS_FSL_IFC_BANK_COUNT		8
 #define CONFIG_NUM_DDR_CONTROLLERS		3
 #define CONFIG_SYS_FSL_CLUSTER_CLOCKS		{ 1, 1, 4, 4 }
+#define CONFIG_SYS_FSL_SRDS_1
+#define CONFIG_SYS_FSL_SRDS_2
 #else
 #error SoC not defined
 #endif
arch/arm/include/asm/arch-fsl-lsch3/fsl_serdes.h new file +67 -0

67 lines not on this page · raw message

arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h +5 -0
index dd11ef7..91cf68b 100644
@@ -63,6 +63,11 @@ struct ccsr_gur {
 #define FSL_CHASSIS3_RCWSR0_MEM_PLL_RAT_MASK	0x3f
 #define FSL_CHASSIS3_RCWSR0_MEM2_PLL_RAT_SHIFT	18
 #define FSL_CHASSIS3_RCWSR0_MEM2_PLL_RAT_MASK	0x3f
+#define	FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_MASK	0x00FF0000
+#define	FSL_CHASSIS3_RCWSR28_SRDS1_PRTCL_SHIFT	16
+#define	FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_MASK	0xFF000000
+#define	FSL_CHASSIS3_RCWSR28_SRDS2_PRTCL_SHIFT	24
+
 	u8	res_180[0x200-0x180];
 	u32	scratchrw[32];	/* Scratch Read/Write */
 	u8	res_280[0x300-0x280];
include/configs/ls2085a_common.h +5 -0
index b47cf68..9bbcc64 100644
@@ -19,6 +19,11 @@
 #define CONFIG_ARM_ERRATA_828024
 #define CONFIG_ARM_ERRATA_826974
 
+#include <asm/arch-fsl-lsch3/config.h>
+#if (defined(CONFIG_SYS_FSL_SRDS_1) || defined(CONFIG_SYS_FSL_SRDS_2))
+#define	CONFIG_SYS_HAS_SERDES
+#endif
+
 /* We need architecture specific misc initializations */
 #define CONFIG_ARCH_MISC_INIT
 
Signature · 1 line
1.7.9.5
author
#18 lore raw

PATCH 13/28 net/phy/cortina: Fix compilation warning

In reply to York Sun

From: pankaj chauhan <[email protected]>

Fix comilation warning which is emitted when
firmware address is more than 32 bit.

---
 drivers/net/phy/cortina.c |    4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
drivers/net/phy/cortina.c +2 -2
index 254f056..3a2b3bb 100644
@@ -186,8 +186,8 @@ void cs4340_upload_firmware(struct phy_device *phydev)
 		while (*addr != 0x0a) {
 			line_temp[i++] = *addr++;
 			if (0x50 < i) {
-				printf("Not found Cortina PHY ucode at 0x%x\n",
-				       CONFIG_CORTINA_FW_ADDR);
+				printf("Not found Cortina PHY ucode@0x%p\n",
+				       (char *)CONFIG_CORTINA_FW_ADDR);
 				return;
 			}
 		}
Signature · 1 line
1.7.9.5
author
#20 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

In reply to York Sun

From: "J. German Rivera" <[email protected]>

Changed MC firmware loading to comply with the new MC boot architecture. Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib functions.

---
 arch/arm/cpu/armv8/fsl-lsch3/README |    8 +
 drivers/net/fsl-mc/mc.c             |  494 ++++++++++++++++++++++++++---------
 include/configs/ls2085a_common.h    |    6 +-
 include/configs/ls2085a_emu.h       |   13 +-
 include/configs/ls2085a_simu.h      |    5 +
 5 files changed, 395 insertions(+), 131 deletions(-)
arch/arm/cpu/armv8/fsl-lsch3/README +8 -0
index 99fc39a..f781620 100644
@@ -33,3 +33,11 @@ is shown below considering a 32MB NOR flash device:
 	------------------------- ----> 0x0000_0000
 
 	32-MB NOR flash layout
+
+Environment Variables
+=====================
+mcboottimeout:	MC boot timeout in milliseconds. If this variable is not defined
+		the value CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS will be assumed.
+
+mcmemsize:	MC DRAM block size. If this variable is not defined, the value
+		CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE will be assumed.
drivers/net/fsl-mc/mc.c +370 -124

605 lines not on this page · raw message

include/configs/ls2085a_common.h +4 -2
index 9bbcc64..c0e4314 100644
@@ -136,8 +136,10 @@
 #define CONFIG_FSL_MC_ENET
 #define CONFIG_SYS_LS_MC_DRAM_BLOCK_MIN_SIZE	(512UL * 1024 * 1024)
 /* TODO Actual DPL max length needs to be confirmed with the MC FW team */
-#define CONFIG_SYS_LS_MC_DPL_MAX_LENGTH		(256 * 1024)
-#define CONFIG_SYS_LS_MC_DRAM_DPL_OFFSET	0xe00000
+#define CONFIG_SYS_LS_MC_DPC_MAX_LENGTH	    0x20000
+#define CONFIG_SYS_LS_MC_DRAM_DPC_OFFSET    0x00F00000
+#define CONFIG_SYS_LS_MC_DPL_MAX_LENGTH	    0x20000
+#define CONFIG_SYS_LS_MC_DRAM_DPL_OFFSET    0x00F20000
 
 /* Carve out a DDR region which will not be used by u-boot/Linux */
 #if defined(CONFIG_FSL_MC_ENET) || defined(CONFIG_FSL_DEBUG_SERVER)
include/configs/ls2085a_emu.h +8 -5
index 961dc63..2d68e1b 100644
@@ -72,12 +72,15 @@
 #define CONFIG_SYS_DEBUG_SERVER_FW_IN_NOR
 #define CONFIG_SYS_DEBUG_SERVER_FW_ADDR	0x580C00000ULL
 
-/* MC firmware */
-#define CONFIG_SYS_LS_MC_FW_IN_NOR
-#define CONFIG_SYS_LS_MC_FW_ADDR	0x580200000ULL
+/*
+ * This trick allows users to load MC images into DDR directly without
+ * copying from NOR flash. It dramatically improves speed.
+ */
+#define CONFIG_SYS_LS_MC_FW_IN_DDR
+#define CONFIG_SYS_LS_MC_DPL_IN_DDR
+#define CONFIG_SYS_LS_MC_DPC_IN_DDR
 
-#define CONFIG_SYS_LS_MC_DPL_IN_NOR
-#define CONFIG_SYS_LS_MC_DPL_ADDR	0x5806C0000ULL
+#define CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS 200000
 
 /* Store environment at top of flash */
 #define CONFIG_ENV_IS_NOWHERE		1
include/configs/ls2085a_simu.h +5 -0
index e669d8d..d0d2eed 100644
@@ -138,6 +138,11 @@
 #define CONFIG_SYS_LS_MC_DPL_IN_NOR
 #define CONFIG_SYS_LS_MC_DPL_ADDR	0x5806C0000ULL
 
+#define CONFIG_SYS_LS_MC_DPC_IN_NOR
+#define CONFIG_SYS_LS_MC_DPC_ADDR	0x5806F8000ULL
+
+#define CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS 200000
+
 /* Store environment@top of flash */
 #define CONFIG_ENV_IS_NOWHERE		1
 #define CONFIG_ENV_SIZE			0x1000
Signature · 1 line
1.7.9.5
#21 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 7 lines · On Thu, 19 Mar 2015 09:45:45 -0700 York Sun <[email protected]> wrote:

From: "J. German Rivera" <[email protected]>

Changed MC firmware loading to comply with the new MC boot architecture. Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib functions.

Can we just assign actual and/or optimal values for 'mcboottimeout' and 'mcmemsize' instead of making them environment variables?

drivers/net/fsl-mc/mc.c int parse_mc_firmware_fit_image(const void **raw_image_addr, · line 336

Quoted 12 lines
drivers/net/fsl-mc/mc.c +12 -0
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr)
+{
+	u32 reg_gsr;
+	u32 mc_fw_boot_status;
+	unsigned long timeout_ms = get_mc_boot_timeout_ms();
+	struct mc_ccsr_registers __iomem *mc_ccsr_regs = MC_CCSR_BASE_ADDR;
+
+	dmb();
+	debug("Polling mc_ccsr_regs->reg_gsr ...\n");
+	assert(timeout_ms > 0);
+	for (;;) {
+		udelay(1000);	/* throttle polling */

does this really need to be a whole 1ms?

drivers/net/fsl-mc/mc.c int get_mc_boot_status(void) · line 548

Quoted 9 lines
drivers/net/fsl-mc/mc.c +0 -4
@@ -318,14 +545,28 @@ int get_mc_boot_status(void)
 
 /**
  * Return the actual size of the MC private DRAM block.
- *
- * NOTE: For now this function always returns the minimum required size,
- * However, in the future, the actual size may be obtained from an environment
- * variable.
  */

why?

Kim

#22 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 14 lines

-----Original Message-----
From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM
To: Sun York-R58495
Cc: u-boot at lists.denx.de; Rivera Jose-B46482
Subject: Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 3 lines · On Thu, 19 Mar 2015 09:45:45 -0700 York Sun <[email protected]> wrote:

From: "J. German Rivera" <[email protected]>

Changed MC firmware loading to comply with the new MC boot

Quoted 9 lines

architecture.

Quoted 4 lines

Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib functions.

Can we just assign actual and/or optimal values for 'mcboottimeout' and 'mcmemsize' instead of making them environment variables?

Having environment variables gives us the flexibility if these values need to be changed for a given customer configuration. The actual boot time of the MC and the amount of memory needed by the MC is dependent on how big/complex is the DPL used. Also, the memory needed by the MC needs to account for how much memory is needed for AIOP programs, which may depend on how big/complex they are.

Quoted 5 lines
Quoted 5 lines
drivers/net/fsl-mc/mc.c +5 -0
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+	u32 reg_gsr;
+	u32 mc_fw_boot_status;
+	unsigned long timeout_ms = get_mc_boot_timeout_ms();
+	struct mc_ccsr_registers __iomem *mc_ccsr_regs = MC_CCSR_BASE_ADDR;
Quoted 8 lines

drivers/net/fsl-mc/mc.c int parse_mc_firmware_fit_image(const void **raw_image_addr, · line 336

Quoted 6 lines
drivers/net/fsl-mc/mc.c +6 -0
+
+	dmb();
+	debug("Polling mc_ccsr_regs->reg_gsr ...\n");
+	assert(timeout_ms > 0);
+	for (;;) {
+		udelay(1000);	/* throttle polling */

does this really need to be a whole 1ms?

It is unlikely that the MC fw will boot in less than 1 ms. So, checking more frequently than 1 ms is not necessary.

Quoted 15 lines
Quoted 9 lines
drivers/net/fsl-mc/mc.c +0 -3
@@ -318,14 +545,28 @@ int get_mc_boot_status(void)
 
 /**
  * Return the actual size of the MC private DRAM block.
- *
- * NOTE: For now this function always returns the minimum required
 size,
- * However, in the future, the actual size may be obtained from an
Quoted 3 lines

environment
- * variable.
*/

why?

See answer above.

German

#23 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 15 lines · On Mon, 23 Mar 2015 15:06:11 -0500 Rivera Jose-B46482…
Quoted 15 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM

Quoted 3 lines · On Thu, 19 Mar 2015 09:45:45 -0700 York Sun <[email protected]> wrote:

From: "J. German Rivera" <[email protected]>

Changed MC firmware loading to comply with the new MC boot

architecture.

Quoted 4 lines

Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib functions.

Quoted 5 lines
Quoted 3 lines

Can we just assign actual and/or optimal values for 'mcboottimeout' and 'mcmemsize' instead of making them environment variables?

Having environment variables gives us the flexibility if these values need to be changed for a given customer configuration. The actual

what defines a 'customer configuration,' and how does that manifest itself at u-boot boot time? Is it the amount of time it takes to load (and execute?) firmare? Why isn't customer-specific firmware being loaded via linux? All u-boot needs is basic networking, pretty static setup: fixed numbers for both memsize & timeout.

Quoted 4 lines

boot time of the MC and the amount of memory needed by the MC is dependent on how big/complex is the DPL used. Also, the memory needed by the MC needs to account for how much memory is needed for AIOP programs, which may depend on how big/complex they are.

ok, that helps (modulo not knowing what 'DPL' is), but still, the massive customer configurations should be being loaded via linux' firmware loading infrastructure: u-boot should be using a static image for u-boot's needs.

Quoted 14 lines
Quoted 5 lines
Quoted 5 lines
drivers/net/fsl-mc/mc.c +5 -0
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+	u32 reg_gsr;
+	u32 mc_fw_boot_status;
+	unsigned long timeout_ms = get_mc_boot_timeout_ms();
+	struct mc_ccsr_registers __iomem *mc_ccsr_regs = MC_CCSR_BASE_ADDR;
Quoted 8 lines

drivers/net/fsl-mc/mc.c int parse_mc_firmware_fit_image(const void **raw_image_addr, · line 336

Quoted 6 lines
drivers/net/fsl-mc/mc.c +6 -0
+
+	dmb();
+	debug("Polling mc_ccsr_regs->reg_gsr ...\n");
+	assert(timeout_ms > 0);
+	for (;;) {
+		udelay(1000);	/* throttle polling */

does this really need to be a whole 1ms?

Quoted 1 line

It is unlikely that the MC fw will boot in less than 1 ms.

is wait_for_mc() only called for the boot command, or all commands?

Quoted 1 line

So, checking more frequently than 1 ms is not necessary.

yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on this.

Kim

#24 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 26 lines

-----Original Message-----
From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 3:34 PM
To: Rivera Jose-B46482
Cc: Sun York-R58495; u-boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 15 lines · On Mon, 23 Mar 2015 15:06:11 -0500 Rivera Jose-B46482…
Quoted 15 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM

Quoted 3 lines · On Thu, 19 Mar 2015 09:45:45 -0700 York Sun <[email protected]> wrote:

From: "J. German Rivera" <[email protected]>

Changed MC firmware loading to comply with the new MC boot

architecture.

Quoted 4 lines

Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib functions.

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

Can we just assign actual and/or optimal values for 'mcboottimeout' and 'mcmemsize' instead of making them environment variables?

Having environment variables gives us the flexibility if these values need to be changed for a given customer configuration. The actual

what defines a 'customer configuration,' and how does that manifest itself at u-boot boot time?

A DPL (data path layout - a device-tree-like structure describing The DPAA2 objects created at boot time and their connections)

Quoted 2 lines

Is it the amount of time it takes to load
(and execute?) firmare?

Yes, bigger DPLs take longer to process by the MC.

Quoted 3 lines

Why isn't customer-specific firmware being
loaded via linux? All u-boot needs is basic networking, pretty static
setup: fixed numbers for both memsize & timeout.

This is not customer-specific firmware. What is customer-specific is just the DPL. In order to have networking in u-boot, we need to load the MC firmware in u-boot, For cases in which the target system has only DPAA2-based network interfaces.

Quoted 26 lines
Quoted 5 lines

boot time of the MC and the amount of memory needed by the MC is dependent on how big/complex is the DPL used. Also, the memory needed by the MC needs to account for how much memory is needed for AIOP programs, which may depend on how big/complex they are.

ok, that helps (modulo not knowing what 'DPL' is), but still, the massive customer configurations should be being loaded via linux' firmware loading infrastructure: u-boot should be using a static image for u-boot's needs.

Quoted 15 lines
Quoted 14 lines

drivers/net/fsl-mc/mc.c int parse_mc_firmware_fit_image(const void **raw_image_addr, · line 336

Quoted 12 lines
drivers/net/fsl-mc/mc.c +12 -0
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+	u32 reg_gsr;
+	u32 mc_fw_boot_status;
+	unsigned long timeout_ms = get_mc_boot_timeout_ms();
+	struct mc_ccsr_registers __iomem *mc_ccsr_regs =
+MC_CCSR_BASE_ADDR;
+
+	dmb();
+	debug("Polling mc_ccsr_regs->reg_gsr ...\n");
+	assert(timeout_ms > 0);
+	for (;;) {
+		udelay(1000);	/* throttle polling */

does this really need to be a whole 1ms?

Quoted 9 lines
Quoted 1 line

It is unlikely that the MC fw will boot in less than 1 ms.

is wait_for_mc() only called for the boot command, or all commands?

Quoted 1 line

So, checking more frequently than 1 ms is not necessary.

yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on this.

How significant is to save 0.9ms of the whole boot time?

As the comment in the code says, the intent was to throttle down the polling, to reduce traffic on the system bus due to polling. This traffic competes with the MC itself accessing the system bus, as it boots. Having the polling traffic get in the way of the MC traffic may increase the MC boot time. Too small delay between polls may cause the MC boot time to increase more than the .9ms you are concerned of wasting in the delay.

What value would you suggest to use for the delay instead 1000ms?

Quoted 1 line

Kim

#25 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 39 lines · On Mon, 23 Mar 2015 16:15:56 -0500 Rivera Jose-B46482…
Quoted 26 lines

-----Original Message-----
From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 3:34 PM
To: Rivera Jose-B46482
Cc: Sun York-R58495; u-boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 15 lines · On Mon, 23 Mar 2015 15:06:11 -0500 Rivera Jose-B46482…
Quoted 15 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM

Quoted 3 lines · On Thu, 19 Mar 2015 09:45:45 -0700 York Sun <[email protected]> wrote:

From: "J. German Rivera" <[email protected]>

Changed MC firmware loading to comply with the new MC boot

architecture.

Quoted 4 lines

Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib functions.

Quoted 8 lines
Quoted 5 lines
Quoted 3 lines

Can we just assign actual and/or optimal values for 'mcboottimeout' and 'mcmemsize' instead of making them environment variables?

Having environment variables gives us the flexibility if these values need to be changed for a given customer configuration. The actual

what defines a 'customer configuration,' and how does that manifest itself at u-boot boot time?

A DPL (data path layout - a device-tree-like structure describing The DPAA2 objects created at boot time and their connections)

Quoted 2 lines

Is it the amount of time it takes to load
(and execute?) firmare?

Quoted 8 lines

Yes, bigger DPLs take longer to process by the MC.

Quoted 3 lines

Why isn't customer-specific firmware being
loaded via linux? All u-boot needs is basic networking, pretty static
setup: fixed numbers for both memsize & timeout.

This is not customer-specific firmware. What is customer-specific is just the DPL. In order to have networking in u-boot, we need to load the MC firmware in u-boot, For cases in which the target system has only DPAA2-based network interfaces.

ok, for that case, when time comes for u-boot to do some DPAA2 networking arrives (i.e., we shouldn't have to be loading firmware at board boot-time), then we should load a minimal DPL for the number of singular, non-virtual/switch, etc., interfaces for that board just to tftp: this shouldn't be a big DPL at all, and its time complexity is fixed.

Quoted 25 lines
Quoted 25 lines
Quoted 4 lines

boot time of the MC and the amount of memory needed by the MC is dependent on how big/complex is the DPL used. Also, the memory needed by the MC needs to account for how much memory is needed for AIOP programs, which may depend on how big/complex they are.

ok, that helps (modulo not knowing what 'DPL' is), but still, the massive customer configurations should be being loaded via linux' firmware loading infrastructure: u-boot should be using a static image for u-boot's needs.

Quoted 15 lines
Quoted 14 lines

drivers/net/fsl-mc/mc.c int parse_mc_firmware_fit_image(const void **raw_image_addr, · line 336

Quoted 12 lines
drivers/net/fsl-mc/mc.c +12 -0
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+	u32 reg_gsr;
+	u32 mc_fw_boot_status;
+	unsigned long timeout_ms = get_mc_boot_timeout_ms();
+	struct mc_ccsr_registers __iomem *mc_ccsr_regs =
+MC_CCSR_BASE_ADDR;
+
+	dmb();
+	debug("Polling mc_ccsr_regs->reg_gsr ...\n");
+	assert(timeout_ms > 0);
+	for (;;) {
+		udelay(1000);	/* throttle polling */

does this really need to be a whole 1ms?

Quoted 3 lines
Quoted 3 lines
Quoted 1 line

It is unlikely that the MC fw will boot in less than 1 ms.

is wait_for_mc() only called for the boot command, or all commands?

I see: there's a udelay(500) in mc_send_command(), which is too high, too, IMO, but I'm not that familiar with the h/w: How long does the shortest command take?

Quoted 6 lines
Quoted 5 lines
Quoted 1 line

So, checking more frequently than 1 ms is not necessary.

yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on this.

How significant is to save 0.9ms of the whole boot time?

Why waste 0.9ms of boot time when there's no need? It already takes the boards *way* too long to boot, and now I'm understanding mc_send_command's delay should probably be adjusted, too.

Quoted 8 lines

As the comment in the code says, the intent was to throttle down the polling, to reduce traffic on the system bus due to polling. This traffic competes with the MC itself accessing the system bus, as it boots. Having the polling traffic get in the way of the MC traffic may increase the MC boot time. Too small delay between polls may cause the MC boot time to increase more than the .9ms you are concerned of wasting in the delay.

What value would you suggest to use for the delay instead 1000ms?

I don't know MC h/w: what's the shortest boot time given a standard simple "DPL"?: A small fraction of that.

Kim

#26 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 60 lines

-----Original Message-----
From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 5:06 PM
To: Rivera Jose-B46482
Cc: Sun York-R58495; u-boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 19 lines · On Mon, 23 Mar 2015 16:15:56 -0500 Rivera Jose-B46482…
Quoted 19 lines

-----Original Message-----
From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 3:34 PM
To: Rivera Jose-B46482
Cc: Sun York-R58495; u-boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 8 lines · On Mon, 23 Mar 2015 15:06:11 -0500 Rivera Jose-B46482…
Quoted 8 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM

Quoted 2 lines · On Thu, 19 Mar 2015 09:45:45 -0700 York Sun <[email protected]> wrote:

From: "J. German Rivera" <[email protected]>

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 1 line

Changed MC firmware loading to comply with the new MC boot

architecture.

Quoted 4 lines

Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib functions.

Can we just assign actual and/or optimal values for

'mcboottimeout'

Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

and 'mcmemsize' instead of making them environment variables?

Having environment variables gives us the flexibility if these values need to be changed for a given customer configuration. The actual

what defines a 'customer configuration,' and how does that manifest itself at u-boot boot time?

A DPL (data path layout - a device-tree-like structure describing The DPAA2 objects created at boot time and their connections)

Quoted 7 lines
Quoted 1 line

Is it the amount of time it takes to load (and execute?) firmare?

Yes, bigger DPLs take longer to process by the MC.

Quoted 3 lines

Why isn't customer-specific firmware being loaded via linux? All u-boot needs is basic networking, pretty static
setup: fixed numbers for both memsize & timeout.

This is not customer-specific firmware. What is customer-specific is

just the DPL.

Quoted 2 lines

In order to have networking in u-boot, we need to load the MC firmware in u-boot, For cases in which the target system has only DPAA2-based

Quoted 8 lines

network interfaces.

ok, for that case, when time comes for u-boot to do some DPAA2 networking arrives (i.e., we shouldn't have to be loading firmware at board boot- time), then we should load a minimal DPL for the number of singular, non- virtual/switch, etc., interfaces for that board just to tftp: this shouldn't be a big DPL at all, and its time complexity is fixed.

It is up to the customer to decide what kind of DPL they want to have.

Quoted 35 lines
Quoted 25 lines
Quoted 25 lines
Quoted 4 lines

boot time of the MC and the amount of memory needed by the MC is dependent on how big/complex is the DPL used. Also, the memory needed by the MC needs to account for how much memory is needed for AIOP programs, which may depend on how big/complex they are.

ok, that helps (modulo not knowing what 'DPL' is), but still, the massive customer configurations should be being loaded via linux' firmware loading infrastructure: u-boot should be using a static image for u-boot's needs.

Quoted 15 lines
Quoted 14 lines

drivers/net/fsl-mc/mc.c int parse_mc_firmware_fit_image(const void **raw_image_addr, · line 336

Quoted 12 lines
drivers/net/fsl-mc/mc.c +12 -0
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+	u32 reg_gsr;
+	u32 mc_fw_boot_status;
+	unsigned long timeout_ms = get_mc_boot_timeout_ms();
+	struct mc_ccsr_registers __iomem *mc_ccsr_regs =
+MC_CCSR_BASE_ADDR;
+
+	dmb();
+	debug("Polling mc_ccsr_regs->reg_gsr ...\n");
+	assert(timeout_ms > 0);
+	for (;;) {
+		udelay(1000);	/* throttle polling */

does this really need to be a whole 1ms?

Quoted 3 lines
Quoted 3 lines
Quoted 1 line

It is unlikely that the MC fw will boot in less than 1 ms.

is wait_for_mc() only called for the boot command, or all commands?

I see: there's a udelay(500) in mc_send_command(), which is too high, too, IMO, but I'm not that familiar with the h/w: How long does the shortest command take?

Quoted 2 lines
Quoted 2 lines
Quoted 1 line

So, checking more frequently than 1 ms is not necessary.

Quoted 9 lines
Quoted 4 lines
Quoted 3 lines

yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on this.

How significant is to save 0.9ms of the whole boot time?

Why waste 0.9ms of boot time when there's no need? It already takes the boards *way* too long to boot, and now I'm understanding mc_send_command's delay should probably be adjusted, too.

I have not heard any complain about RDB/QDS boards taking too long to boot Due to this "wasteds 0.9ms".

Can you support your statement about LS2 RDB/QDS boards taking too long to boot with actual numbers? Otherwise, I will not make any change.

Quoted 6 lines
Quoted 6 lines

As the comment in the code says, the intent was to throttle down the polling, to reduce traffic on the system bus due to polling. This traffic competes with the MC itself accessing the system bus, as it boots. Having the polling traffic get in the way of the MC traffic may increase the MC boot time. Too small delay between polls may cause the MC boot time to increase more than the .9ms you are concerned of

Quoted 7 lines

wasting in the delay.

Quoted 2 lines

What value would you suggest to use for the delay instead 1000ms?

I don't know MC h/w: what's the shortest boot time given a standard simple "DPL"?: A small fraction of that.

I will not make any change at this time as there is no evidence that this optimization is actually needed.

Quoted 1 line

Kim

#27 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 52 lines · On Tue, 24 Mar 2015 10:14:39 -0500 Rivera Jose-B46482…
Quoted 52 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 5:06 PM

Quoted 14 lines · On Mon, 23 Mar 2015 16:15:56 -0500 Rivera Jose-B46482…
Quoted 14 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 3:34 PM

Quoted 8 lines · On Mon, 23 Mar 2015 15:06:11 -0500 Rivera Jose-B46482…
Quoted 8 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM

Quoted 2 lines · On Thu, 19 Mar 2015 09:45:45 -0700 York Sun <[email protected]> wrote:

From: "J. German Rivera" <[email protected]>

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 1 line

Changed MC firmware loading to comply with the new MC boot

architecture.

Quoted 4 lines

Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib functions.

Can we just assign actual and/or optimal values for

'mcboottimeout'

Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

and 'mcmemsize' instead of making them environment variables?

Having environment variables gives us the flexibility if these values need to be changed for a given customer configuration. The actual

what defines a 'customer configuration,' and how does that manifest itself at u-boot boot time?

A DPL (data path layout - a device-tree-like structure describing The DPAA2 objects created at boot time and their connections)

Quoted 7 lines
Quoted 1 line

Is it the amount of time it takes to load (and execute?) firmare?

Yes, bigger DPLs take longer to process by the MC.

Quoted 3 lines

Why isn't customer-specific firmware being loaded via linux? All u-boot needs is basic networking, pretty static
setup: fixed numbers for both memsize & timeout.

This is not customer-specific firmware. What is customer-specific is

just the DPL.

Quoted 2 lines

In order to have networking in u-boot, we need to load the MC firmware in u-boot, For cases in which the target system has only DPAA2-based

network interfaces.

Quoted 7 lines
Quoted 6 lines

ok, for that case, when time comes for u-boot to do some DPAA2 networking arrives (i.e., we shouldn't have to be loading firmware at board boot- time), then we should load a minimal DPL for the number of singular, non- virtual/switch, etc., interfaces for that board just to tftp: this shouldn't be a big DPL at all, and its time complexity is fixed.

It is up to the customer to decide what kind of DPL they want to have.

true, but in this case the 'customer' is the average upstream u-boot user, presumably whose DPL is the simplest ethernet use-case for tftp'ing kernels.

Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 4 lines

boot time of the MC and the amount of memory needed by the MC is dependent on how big/complex is the DPL used. Also, the memory needed by the MC needs to account for how much memory is needed for AIOP programs, which may depend on how big/complex they are.

ok, that helps (modulo not knowing what 'DPL' is), but still, the massive customer configurations should be being loaded via linux' firmware loading infrastructure: u-boot should be using a static image for u-boot's needs.

Quoted 15 lines
Quoted 14 lines

Review

Quoted 12 lines
(quoted diff) +12 -0
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+	u32 reg_gsr;
+	u32 mc_fw_boot_status;
+	unsigned long timeout_ms = get_mc_boot_timeout_ms();
+	struct mc_ccsr_registers __iomem *mc_ccsr_regs =
+MC_CCSR_BASE_ADDR;
+
+	dmb();
+	debug("Polling mc_ccsr_regs->reg_gsr ...\n");
+	assert(timeout_ms > 0);
+	for (;;) {
+		udelay(1000);	/* throttle polling */

does this really need to be a whole 1ms?

Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line

It is unlikely that the MC fw will boot in less than 1 ms.

is wait_for_mc() only called for the boot command, or all commands?

I see: there's a udelay(500) in mc_send_command(), which is too high, too, IMO, but I'm not that familiar with the h/w: How long does the shortest command take?

Can you answer this?

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line

So, checking more frequently than 1 ms is not necessary.

yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on this.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

How significant is to save 0.9ms of the whole boot time?

Why waste 0.9ms of boot time when there's no need? It already takes the boards *way* too long to boot, and now I'm understanding mc_send_command's delay should probably be adjusted, too.

I have not heard any complain about RDB/QDS boards taking too long to boot Due to this "wasteds 0.9ms".

I'm complaining now :)

And it's not just about this singleton constant; it's about the general approach to not optimizing the code, vis-a-vis the mc_send_command() delay I bring up above.

Quoted 2 lines

Can you support your statement about LS2 RDB/QDS boards taking too long to boot with actual numbers? Otherwise, I will not make any change.

A board takes anywhere from 17 to 35 seconds to boot, and, from the prompts, a lot - if not most - of this time is spent during MC processing. If we take boot time down to say half of that, that would work miracles in how we spend our development time on them.

Quoted 8 lines
Quoted 8 lines
Quoted 6 lines

As the comment in the code says, the intent was to throttle down the polling, to reduce traffic on the system bus due to polling. This traffic competes with the MC itself accessing the system bus, as it boots. Having the polling traffic get in the way of the MC traffic may increase the MC boot time. Too small delay between polls may cause the MC boot time to increase more than the .9ms you are concerned of

wasting in the delay.

Quoted 1 line
Quoted 7 lines
Quoted 5 lines
Quoted 1 line

What value would you suggest to use for the delay instead 1000ms?

I don't know MC h/w: what's the shortest boot time given a standard simple "DPL"?: A small fraction of that.

I will not make any change at this time as there is no evidence that this optimization is actually needed.

this kind of attitude leaves a lot to be desired...:(

Kim

A message that is not in the archive (sent off-list or not yet received): CALRxmdDfZKYh3QOSnz1LzvkpWuS2OzontG_fLECuMgzz2N68uA@mail.gmail.com

#29 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 1 line · On Tue, 24 Mar 2015 21:32:56 -0500 Stuart Yoder <[email protected]> wrote:

Kim,

why is this being taken off-list? Adding it back. Also, please don't top-post.

Quoted 17 lines

I think it is premature to start focusing on saving single digit milliseconds in u-boot. The 35 second boot time you are seeing on some ls2085 boards is due to the fact that the MC was running with it's CPU caches off until a few weeks ago. DDR is still running at the slowest speed, which will affect the MC's performance. It's still early in hardware bringup and things are not even stable yet.

I'm still convinced that the MC itself probably has significant performance work.

The 1ms delay used polling for MC to boot has nothing to do with DPL size. DPL processing is a separate, later initialization step. We're just waiting for the MC to initialize here. The MC boot time shouldn't vary. My visual reading watching things boot is that the MC boot takes a few hundred milliseconds. I don't see what's wrong with a 1 ms polling delay here.

Quoted 6 lines

On a system with the MC running with caches on, u-boot took 20 seconds
to boot. The MC took about 5 seconds of that, most of that in DPL
processing.

We would welcome help analyzing u-boot boot time and where the time is
going. But, seriously, saving 1 ms is not going to help at all.

I did a quick experiment and saved ~50ms when setting both udelays down to 50, which, sure, isn't a big deal given it's out of the order of 10sec, but it's something, and, like I said, development time for our users can be seriously helped if MC initialization were omitted from the main u-boot boot sequence, and occurred only when necessary, i.e., when users want to use one of the DP net interfaces. Most of the time when we boot today, we don't use DP net interfaces, so MC init - with or without DPL processing - is just a waste of our time!

Thanks,

Kim

Quoted 160 lines

Thanks,
Stuart

Quoted 153 lines · Kim Phillips
Quoted 52 lines · On Tue, 24 Mar 2015 10:14:39 -0500 Rivera Jose-B46482…
Quoted 52 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 5:06 PM

Quoted 14 lines · On Mon, 23 Mar 2015 16:15:56 -0500 Rivera Jose-B46482…
Quoted 14 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 3:34 PM

Quoted 8 lines · On Mon, 23 Mar 2015 15:06:11 -0500 Rivera Jose-B46482…
Quoted 8 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM

Quoted 2 lines · On Thu, 19 Mar 2015 09:45:45 -0700 York Sun <[email protected]> wrote:

From: "J. German Rivera" <[email protected]>

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 1 line

Changed MC firmware loading to comply with the new MC boot

architecture.

Quoted 4 lines

Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib functions.

Can we just assign actual and/or optimal values for

'mcboottimeout'

Quoted 11 lines
Quoted 8 lines
Quoted 5 lines
Quoted 2 lines

and 'mcmemsize' instead of making them environment variables?

Having environment variables gives us the flexibility if these values need to be changed for a given customer configuration. The actual

what defines a 'customer configuration,' and how does that manifest itself at u-boot boot time?

A DPL (data path layout - a device-tree-like structure describing The DPAA2 objects created at boot time and their connections)

Quoted 7 lines
Quoted 1 line

Is it the amount of time it takes to load (and execute?) firmare?

Yes, bigger DPLs take longer to process by the MC.

Quoted 3 lines

Why isn't customer-specific firmware being loaded via linux? All u-boot needs is basic networking, pretty static
setup: fixed numbers for both memsize & timeout.

This is not customer-specific firmware. What is customer-specific is

just the DPL.

Quoted 2 lines

In order to have networking in u-boot, we need to load the MC firmware in u-boot, For cases in which the target system has only DPAA2-based

network interfaces.

Quoted 7 lines
Quoted 6 lines

ok, for that case, when time comes for u-boot to do some DPAA2 networking arrives (i.e., we shouldn't have to be loading firmware at board boot- time), then we should load a minimal DPL for the number of singular, non- virtual/switch, etc., interfaces for that board just to tftp: this shouldn't be a big DPL at all, and its time complexity is fixed.

It is up to the customer to decide what kind of DPL they want to have.

true, but in this case the 'customer' is the average upstream u-boot user, presumably whose DPL is the simplest ethernet use-case for tftp'ing kernels.

Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 25 lines
Quoted 4 lines

boot time of the MC and the amount of memory needed by the MC is dependent on how big/complex is the DPL used. Also, the memory needed by the MC needs to account for how much memory is needed for AIOP programs, which may depend on how big/complex they are.

ok, that helps (modulo not knowing what 'DPL' is), but still, the massive customer configurations should be being loaded via linux' firmware loading infrastructure: u-boot should be using a static image for u-boot's needs.

Quoted 15 lines
Quoted 14 lines

Review

Quoted 12 lines
(quoted diff) +12 -0
+static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr) {
+ u32 reg_gsr;
+ u32 mc_fw_boot_status;
+ unsigned long timeout_ms = get_mc_boot_timeout_ms();
+ struct mc_ccsr_registers __iomem *mc_ccsr_regs =
+MC_CCSR_BASE_ADDR;
+
+ dmb();
+ debug("Polling mc_ccsr_regs->reg_gsr ...\n");
+ assert(timeout_ms > 0);
+ for (;;) {
+         udelay(1000);   /* throttle polling */

does this really need to be a whole 1ms?

Quoted 7 lines
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line

It is unlikely that the MC fw will boot in less than 1 ms.

is wait_for_mc() only called for the boot command, or all commands?

I see: there's a udelay(500) in mc_send_command(), which is too high, too, IMO, but I'm not that familiar with the h/w: How long does the shortest command take?

Can you answer this?

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 1 line

So, checking more frequently than 1 ms is not necessary.

yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on this.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

How significant is to save 0.9ms of the whole boot time?

Why waste 0.9ms of boot time when there's no need? It already takes the boards *way* too long to boot, and now I'm understanding mc_send_command's delay should probably be adjusted, too.

I have not heard any complain about RDB/QDS boards taking too long to boot Due to this "wasteds 0.9ms".

I'm complaining now :)

And it's not just about this singleton constant; it's about the general approach to not optimizing the code, vis-a-vis the mc_send_command() delay I bring up above.

Quoted 2 lines

Can you support your statement about LS2 RDB/QDS boards taking too long to boot with actual numbers? Otherwise, I will not make any change.

A board takes anywhere from 17 to 35 seconds to boot, and, from the prompts, a lot - if not most - of this time is spent during MC processing. If we take boot time down to say half of that, that would work miracles in how we spend our development time on them.

Quoted 8 lines
Quoted 8 lines
Quoted 6 lines

As the comment in the code says, the intent was to throttle down the polling, to reduce traffic on the system bus due to polling. This traffic competes with the MC itself accessing the system bus, as it boots. Having the polling traffic get in the way of the MC traffic may increase the MC boot time. Too small delay between polls may cause the MC boot time to increase more than the .9ms you are concerned of

wasting in the delay.

Quoted 1 line
Quoted 7 lines
Quoted 5 lines
Quoted 1 line

What value would you suggest to use for the delay instead 1000ms?

I don't know MC h/w: what's the shortest boot time given a standard simple "DPL"?: A small fraction of that.

I will not make any change at this time as there is no evidence that this optimization is actually needed.

this kind of attitude leaves a lot to be desired...:(

Kim
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#30 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 40 lines

-----Original Message-----
From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Wednesday, March 25, 2015 4:13 PM
To: Stuart Yoder
Cc: Rivera Jose-B46482; Sun York-R58495; u-boot at lists.denx.de
Subject: Re: [U-Boot] [PATCH 14/28] drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 1 line · On Tue, 24 Mar 2015 21:32:56 -0500 Stuart Yoder <[email protected]> wrote:

Kim,

why is this being taken off-list? Adding it back. Also, please don't top-post.

Quoted 17 lines

I think it is premature to start focusing on saving single digit milliseconds in u-boot. The 35 second boot time you are seeing on some ls2085 boards is due to the fact that the MC was running with it's CPU caches off until a few weeks ago. DDR is still running at the slowest speed, which will affect the MC's performance. It's still early in hardware bringup and things are not even stable yet.

I'm still convinced that the MC itself probably has significant performance work.

The 1ms delay used polling for MC to boot has nothing to do with DPL size. DPL processing is a separate, later initialization step. We're just waiting for the MC to initialize here. The MC boot time shouldn't vary. My visual reading watching things boot is that the MC boot takes a few hundred milliseconds. I don't see what's wrong with a 1 ms polling delay here.

Quoted 6 lines

On a system with the MC running with caches on, u-boot took 20 seconds
to boot. The MC took about 5 seconds of that, most of that in DPL
processing.

We would welcome help analyzing u-boot boot time and where the time is
going. But, seriously, saving 1 ms is not going to help at all.

Quoted 9 lines

I did a quick experiment and saved ~50ms when setting both udelays down to 50, which, sure, isn't a big deal given it's out of the order of 10sec, but it's something, and, like I said, development time for our users can be seriously helped if MC initialization were omitted from the main u-boot boot sequence, and occurred only when necessary, i.e., when users want to use one of the DP net interfaces. Most of the time when we boot today, we don't use DP net interfaces, so MC init - with or without DPL processing - is just a waste of our time!

The 50ms improvement you claim will not make any difference to save time For development users, since 50ms is not something humans can perceive. As Stuart said, we (the MC team) should first analyze where is the bulk of The DPL processing by the MC fw is being spent, to see how much we can reduce the 5 seconds spent there. That is, we should be concerned first about where we can save big bucks, before being concerned about where we can save one penny or two.

Thanks,

German

Quoted 179 lines

Thanks,

Kim

Quoted 5 lines

Thanks,
Stuart

Quoted 32 lines
Quoted 30 lines · Kim Phillips
Quoted 27 lines · On Tue, 24 Mar 2015 10:14:39 -0500 Rivera Jose-B46482…
Quoted 27 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 5:06 PM

Quoted 21 lines · On Mon, 23 Mar 2015 16:15:56 -0500 Rivera Jose-B46482…
Quoted 21 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Monday, March 23, 2015 3:34 PM

Quoted 15 lines · On Mon, 23 Mar 2015 15:06:11 -0500 Rivera Jose-B46482…
Quoted 15 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Thursday, March 19, 2015 12:53 PM

Quoted 4 lines · On Thu, 19 Mar 2015 09:45:45 -0700 York Sun <[email protected]> wrote:

From: "J. German Rivera" <[email protected]>

Changed MC firmware loading to comply with the new MC boot

architecture.

Quoted 4 lines

Flush D-cache hierarchy after loading MC images. Add environment variables "mcboottimeout" for MC boot timeout in milliseconds, "mcmemsize" for MC DRAM block size. Check MC boot status before calling flib

functions.

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines

Can we just assign actual and/or optimal values for

'mcboottimeout'

Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line

and 'mcmemsize' instead of making them environment

variables?

Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 4 lines
Quoted 1 line

Having environment variables gives us the flexibility if these values need to be changed for a given customer configuration. The actual

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 2 lines

what defines a 'customer configuration,' and how does that manifest itself at u-boot boot time?

A DPL (data path layout - a device-tree-like structure describing The
DPAA2 objects created at boot time and their connections)

Quoted 1 line

Is it the amount of time it takes to load (and execute?)

firmare?

Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 11 lines
Quoted 7 lines

Yes, bigger DPLs take longer to process by the MC.

Quoted 3 lines

Why isn't customer-specific firmware being loaded via linux? All u-boot needs is basic networking, pretty static
setup: fixed numbers for both memsize & timeout.

This is not customer-specific firmware. What is
customer-specific is

just the DPL.

Quoted 3 lines

In order to have networking in u-boot, we need to load the MC firmware in u-boot, For cases in which the target system has only DPAA2-based

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

network interfaces.

ok, for that case, when time comes for u-boot to do some DPAA2 networking arrives (i.e., we shouldn't have to be loading firmware at board boot- time), then we should load a minimal DPL for the number of singular, non- virtual/switch, etc., interfaces for that board just to tftp: this shouldn't be a big DPL at all,

and its time complexity is fixed.

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line

It is up to the customer to decide what kind of DPL they want to

have.

Quoted 9 lines
Quoted 9 lines

true, but in this case the 'customer' is the average upstream u-boot user, presumably whose DPL is the simplest ethernet use-case for tftp'ing kernels.

Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines
Quoted 4 lines

boot time of the MC and the amount of memory needed by the MC is dependent on how big/complex is the DPL used. Also, the memory needed by the MC needs to account for how much memory is needed for AIOP programs, which may depend on how

big/complex they are.

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

ok, that helps (modulo not knowing what 'DPL' is), but still, the massive customer configurations should be being loaded via

linux'

Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines
Quoted 17 lines

firmware loading infrastructure: u-boot should be using a static image for u-boot's needs.

Quoted 14 lines
Quoted 13 lines

Review

Quoted 11 lines
(quoted diff) +11 -0
+static int wait_for_mc(bool booting_mc, u32
+*final_reg_gsr) {
+ u32 reg_gsr;
+ u32 mc_fw_boot_status;  unsigned long timeout_ms =
+get_mc_boot_timeout_ms();  struct mc_ccsr_registers
+__iomem *mc_ccsr_regs = MC_CCSR_BASE_ADDR;
+
+ dmb();
+ debug("Polling mc_ccsr_regs->reg_gsr ...\n");
+ assert(timeout_ms > 0); for (;;) {
+         udelay(1000);   /* throttle polling */

does this really need to be a whole 1ms?

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 1 line

It is unlikely that the MC fw will boot in less than 1 ms.

is wait_for_mc() only called for the boot command, or all

commands?

Quoted 9 lines
Quoted 9 lines
Quoted 4 lines
Quoted 4 lines

I see: there's a udelay(500) in mc_send_command(), which is too high, too, IMO, but I'm not that familiar with the h/w: How long does the shortest command take?

Can you answer this?

Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Quoted 1 line

So, checking more frequently than 1 ms is not necessary.

Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 8 lines
Quoted 4 lines
Quoted 3 lines

yes it is, because e.g., if it takes 1.1ms we will have wasted 0.9ms on this.

How significant is to save 0.9ms of the whole boot time?

Why waste 0.9ms of boot time when there's no need? It already takes the boards *way* too long to boot, and now I'm understanding mc_send_command's delay should probably be adjusted,

too.

Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Quoted 1 line

I have not heard any complain about RDB/QDS boards taking too long to boot Due to this "wasteds 0.9ms".

Quoted 8 lines
Quoted 8 lines

I'm complaining now :)

And it's not just about this singleton constant; it's about the general approach to not optimizing the code, vis-a-vis the mc_send_command() delay I bring up above.

Quoted 2 lines

Can you support your statement about LS2 RDB/QDS boards taking too long to boot with actual numbers? Otherwise, I will not make any

change.

Quoted 13 lines
Quoted 13 lines

A board takes anywhere from 17 to 35 seconds to boot, and, from the prompts, a lot - if not most - of this time is spent during MC processing. If we take boot time down to say half of that, that would work miracles in how we spend our development time on them.

Quoted 7 lines
Quoted 7 lines
Quoted 7 lines

As the comment in the code says, the intent was to throttle down the polling, to reduce traffic on the system bus due to polling. This traffic competes with the MC itself accessing the system bus, as it boots. Having the polling traffic get in the way of the MC traffic may increase the MC boot time. Too small delay between polls may cause the MC boot time to increase more than the .9ms you are concerned of

Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines

wasting in the delay.

Quoted 2 lines

What value would you suggest to use for the delay instead

1000ms?

Quoted 14 lines
Quoted 14 lines
Quoted 6 lines
Quoted 4 lines

I don't know MC h/w: what's the shortest boot time given a standard simple "DPL"?: A small fraction of that.

I will not make any change at this time as there is no evidence that this optimization is actually needed.

this kind of attitude leaves a lot to be desired...:(

Kim
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#31 lore raw

PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture

Quoted 22 lines · On Thu, 26 Mar 2015 18:57:02 -0500 Rivera Jose-B46482…
Quoted 13 lines

From: Kim Phillips [mailto:kim.phillips at freescale.com]
Sent: Wednesday, March 25, 2015 4:13 PM

Quoted 6 lines · On Tue, 24 Mar 2015 21:32:56 -0500 Stuart Yoder <[email protected]> wrote:

On a system with the MC running with caches on, u-boot took 20 seconds
to boot. The MC took about 5 seconds of that, most of that in DPL
processing.

We would welcome help analyzing u-boot boot time and where the time is
going. But, seriously, saving 1 ms is not going to help at all.

Quoted 9 lines

I did a quick experiment and saved ~50ms when setting both udelays down to 50, which, sure, isn't a big deal given it's out of the order of 10sec, but it's something, and, like I said, development time for our users can be seriously helped if MC initialization were omitted from the main u-boot boot sequence, and occurred only when necessary, i.e., when users want to use one of the DP net interfaces. Most of the time when we boot today, we don't use DP net interfaces, so MC init - with or without DPL processing - is just a waste of our time!

Quoted 7 lines

The 50ms improvement you claim will not make any difference to save time For development users, since 50ms is not something humans can perceive. As Stuart said, we (the MC team) should first analyze where is the bulk of The DPL processing by the MC fw is being spent, to see how much we can reduce the 5 seconds spent there. That is, we should be concerned first about where we can save big bucks, before being concerned about where we can save one penny or two.

my point is that all 10 seconds of MC processing should be removed from u-boot startup time, and moved to only when u-boot needs to use MC-based ethernet, e.g., when a tftp command is invoked.

and, fwiw, the 50ms figure will improve as MC firmware performance improves.

Kim

author
#32 lore raw

PATCH 15/28 net/memac_phy: reuse driver for little endian SoCs

In reply to York Sun

From: Shaohui Xie <[email protected]>

The memac for PHY management on little endian SoCs is similar on big endian SoCs, so we modify the driver by using I/O accessor function to handle the endianness, so the driver can be reused on little endian SoCs, we introduce CONFIG_SYS_MEMAC_LITTLE_ENDIAN for little endian SoCs, if the CONFIG_SYS_MEMAC_LITTLE_ENDIAN is defined, the I/O access is little endian, if not, the I/O access is big endian. Move fsl_memac.h out of powerpc include.

CC Joe Hershberger <[email protected]>
---
 arch/arm/include/asm/arch-fsl-lsch3/config.h      |    1 +
 drivers/net/Makefile                              |    1 +
 drivers/net/fm/eth.c                              |    2 +-
 drivers/net/fm/memac.c                            |    2 +-
 drivers/net/fm/memac_phy.c                        |   62 ++++++++++++++-------
 drivers/net/vsc9953.c                             |    2 +-
 {arch/powerpc/include/asm => include}/fsl_memac.h |    0
 7 files changed, 46 insertions(+), 24 deletions(-)
 rename {arch/powerpc/include/asm => include}/fsl_memac.h (100%)
arch/arm/include/asm/arch-fsl-lsch3/config.h +1 -0
index 98db1ef..684c70f 100644
@@ -109,6 +109,7 @@
 
 /* IFC */
 #define CONFIG_SYS_FSL_IFC_LE
+#define CONFIG_SYS_MEMAC_LITTLE_ENDIAN
 
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR			(CONFIG_SYS_IMMR + 0x2400000)
drivers/net/Makefile +1 -0
index 5497934..d871093 100644
@@ -66,4 +66,5 @@ obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o xilinx_ll_temac_mdio.o \
 obj-$(CONFIG_ZYNQ_GEM) += zynq_gem.o
 obj-$(CONFIG_FSL_MC_ENET) += fsl-mc/
 obj-$(CONFIG_FSL_MC_ENET) += ldpaa_eth/
+obj-$(CONFIG_FSL_MEMAC) += fm/memac_phy.o
 obj-$(CONFIG_VSC9953) += vsc9953.o
drivers/net/fm/eth.c +1 -1
index 1d1089d..a7a5c69 100644
@@ -15,7 +15,7 @@
 #include <phy.h>
 #include <asm/fsl_dtsec.h>
 #include <asm/fsl_tgec.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 
 #include "fm.h"
 
drivers/net/fm/memac.c +1 -1
index 60e898c..81a64bf 100644
@@ -12,7 +12,7 @@
 #include <phy.h>
 #include <asm/types.h>
 #include <asm/io.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 
 #include "fm.h"
 
drivers/net/fm/memac_phy.c +41 -21

128 lines not on this page · raw message

drivers/net/vsc9953.c +1 -1
index 9fc3c18..fed7358 100644
@@ -9,7 +9,7 @@
 #include <asm/io.h>
 #include <asm/fsl_serdes.h>
 #include <fm_eth.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 #include <vsc9953.h>
 
 static struct vsc9953_info vsc9953_l2sw = {
include/fsl_memac.h renamed from arch/powerpc/include/asm/fsl_memac.h +0 -0
similarity index 100%
rename from arch/powerpc/include/asm/fsl_memac.h
rename to include/fsl_memac.h
Signature · 1 line
1.7.9.5
#33 lore raw

PATCH 15/28 net/memac_phy: reuse driver for little endian SoCs

Hi Shaohui Xie,

Quoted 11 lines · York Sun

From: Shaohui Xie <[email protected]>

The memac for PHY management on little endian SoCs is similar on big endian SoCs, so we modify the driver by using I/O accessor function to handle the endianness, so the driver can be reused on little endian SoCs, we introduce CONFIG_SYS_MEMAC_LITTLE_ENDIAN for little endian SoCs, if the CONFIG_SYS_MEMAC_LITTLE_ENDIAN is defined, the I/O access is little endian, if not, the I/O access is big endian. Move fsl_memac.h out of powerpc include.

Quoted 8 lines
CC Joe Hershberger <[email protected]>
---
 arch/arm/include/asm/arch-fsl-lsch3/config.h      |    1 +
 drivers/net/Makefile                              |    1 +
 drivers/net/fm/eth.c                              |    2 +-
 drivers/net/fm/memac.c                            |    2 +-
 drivers/net/fm/memac_phy.c                        |   62

++++++++++++++-------

Review

Quoted 6 lines
 drivers/net/vsc9953.c                             |    2 +-
 {arch/powerpc/include/asm => include}/fsl_memac.h |    0
 7 files changed, 46 insertions(+), 24 deletions(-)
 rename {arch/powerpc/include/asm => include}/fsl_memac.h (100%)
(quoted diff) +0 -0

b/arch/arm/include/asm/arch-fsl-lsch3/config.h

arch/arm/include/asm/arch-fsl-lsch3/config.h line 112

Quoted 8 lines

index 98db1ef..684c70f 100644

arch/arm/include/asm/arch-fsl-lsch3/config.h +1 -0
@@ -109,6 +109,7 @@
 
 /* IFC */
 #define CONFIG_SYS_FSL_IFC_LE
+#define CONFIG_SYS_MEMAC_LITTLE_ENDIAN

It seems tedious to have to define this. Can't you just use the functions available?

arch/arm/include/asm/arch-fsl-lsch3/config.h line 114

Quoted 2 lines
arch/arm/include/asm/arch-fsl-lsch3/config.h +0 -0
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR                  (CONFIG_SYS_IMMR +

0x2400000)

drivers/net/Makefile obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o

Quoted 5 lines
drivers/net/Makefile +0 -0
index 5497934..d871093 100644
@@ -66,4 +66,5 @@ obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o

xilinx_ll_temac_mdio.o \

Quoted 36 lines
drivers/net/Makefile +1 -0
 obj-$(CONFIG_ZYNQ_GEM) += zynq_gem.o
 obj-$(CONFIG_FSL_MC_ENET) += fsl-mc/
 obj-$(CONFIG_FSL_MC_ENET) += ldpaa_eth/
+obj-$(CONFIG_FSL_MEMAC) += fm/memac_phy.o
 obj-$(CONFIG_VSC9953) += vsc9953.o
drivers/net/fm/eth.c +1 -1
index 1d1089d..a7a5c69 100644
@@ -15,7 +15,7 @@
 #include <phy.h>
 #include <asm/fsl_dtsec.h>
 #include <asm/fsl_tgec.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 
 #include "fm.h"
 
drivers/net/fm/memac.c +1 -1
index 60e898c..81a64bf 100644
@@ -12,7 +12,7 @@
 #include <phy.h>
 #include <asm/types.h>
 #include <asm/io.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 
 #include "fm.h"
 
drivers/net/fm/memac_phy.c +0 -0
index a155d89..4ab78e6 100644

drivers/net/fm/memac_phy.c line 16

Quoted 8 lines
drivers/net/fm/memac_phy.c +2 -1
@@ -10,9 +10,28 @@
 #include <miiphy.h>
 #include <phy.h>
 #include <asm/io.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 #include <fm_eth.h>
 
+#ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN

This can already be detected, right?

#if __BYTE_ORDER == __LITTLE_ENDIAN

Quoted 7 lines
drivers/net/fm/memac_phy.c +7 -0
+#define memac_out_32(a, v)     out_le32(a, v)
+#define memac_clrbits_32(a, v) clrbits_le32(a, v)
+#define memac_setbits_32(a, v) setbits_le32(a, v)
+#else
+#define memac_out_32(a, v)     out_be32(a, v)
+#define memac_clrbits_32(a, v) clrbits_be32(a, v)
+#define memac_setbits_32(a, v) setbits_be32(a, v)

drivers/net/fm/memac_phy.c line 33

Quoted 10 lines
drivers/net/fm/memac_phy.c +10 -0
+#endif
+
+static u32 memac_in_32(u32 *reg)
+{
+#ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN
+       return in_le32(reg);
+#else
+       return in_be32(reg);
+#endif
+}

Another option you have is to take the approach that you don't care the endianness. Something like using the this type of pattern:

value = ntohl(in_be32(reg));
out_be32(reg, htonl(value));

drivers/net/fm/memac_phy.c

Quoted 3 lines
drivers/net/fm/memac_phy.c +1 -0
+
 /*
  * Write value to the PHY for this device to the register at regnum,

waiting

drivers/net/fm/memac_phy.c line 37

Quoted 1 line
drivers/net/fm/memac_phy.c +0 -0
  * until the write is done before it returns.  All PHY configuration has

to be

drivers/net/fm/memac_phy.c int memac_mdio_write(struct mii_dev *bus, int

Quoted 1 line
drivers/net/fm/memac_phy.c +0 -0
@@ -28,31 +47,31 @@ int memac_mdio_write(struct mii_dev *bus, int

port_addr, int dev_addr,

Quoted 6 lines
drivers/net/fm/memac_phy.c +1 -1
        if (dev_addr == MDIO_DEVAD_NONE) {
                c45 = 0; /* clause 22 */
                dev_addr = regnum & 0x1f;
-               clrbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_clrbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
        } else

drivers/net/fm/memac_phy.c int memac_mdio_write(struct mii_dev *bus, int port_addr, int dev_addr,

Quoted 10 lines
drivers/net/fm/memac_phy.c +2 -2
-               setbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_setbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Set the port and dev addr */
        mdio_ctl = MDIO_CTL_PORT_ADDR(port_addr) |

MDIO_CTL_DEV_ADDR(dev_addr);

drivers/net/fm/memac_phy.c int memac_mdio_read(struct mii_dev *bus, int

Quoted 24 lines
drivers/net/fm/memac_phy.c +5 -5
-       out_be32(&regs->mdio_ctl, mdio_ctl);
+       memac_out_32(&regs->mdio_ctl, mdio_ctl);
 
        /* Set the register address */
        if (c45)
-               out_be32(&regs->mdio_addr, regnum & 0xffff);
+               memac_out_32(&regs->mdio_addr, regnum & 0xffff);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Write the value to the register */
-       out_be32(&regs->mdio_data, MDIO_DATA(value));
+       memac_out_32(&regs->mdio_data, MDIO_DATA(value));
 
        /* Wait till the MDIO write is complete */
-       while ((in_be32(&regs->mdio_data)) & MDIO_DATA_BSY)
+       while ((memac_in_32(&regs->mdio_data)) & MDIO_DATA_BSY)
                ;
 
        return 0;
@@ -75,39 +94,39 @@ int memac_mdio_read(struct mii_dev *bus, int

port_addr, int dev_addr,

Quoted 6 lines
drivers/net/fm/memac_phy.c +1 -1
                        return 0xffff;
                c45 = 0; /* clause 22 */
                dev_addr = regnum & 0x1f;
-               clrbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_clrbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
        } else

drivers/net/fm/memac_phy.c int memac_mdio_read(struct mii_dev *bus, int port_addr, int dev_addr,

Quoted 10 lines
drivers/net/fm/memac_phy.c +2 -2
-               setbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_setbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Set the Port and Device Addrs */
        mdio_ctl = MDIO_CTL_PORT_ADDR(port_addr) |

MDIO_CTL_DEV_ADDR(dev_addr);

drivers/net/fm/memac_phy.c int fm_memac_mdio_init(bd_t *bis, struct

Quoted 34 lines
drivers/net/fm/memac_phy.c +7 -7
-       out_be32(&regs->mdio_ctl, mdio_ctl);
+       memac_out_32(&regs->mdio_ctl, mdio_ctl);
 
        /* Set the register address */
        if (c45)
-               out_be32(&regs->mdio_addr, regnum & 0xffff);
+               memac_out_32(&regs->mdio_addr, regnum & 0xffff);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Initiate the read */
        mdio_ctl |= MDIO_CTL_READ;
-       out_be32(&regs->mdio_ctl, mdio_ctl);
+       memac_out_32(&regs->mdio_ctl, mdio_ctl);
 
        /* Wait till the MDIO write is complete */
-       while ((in_be32(&regs->mdio_data)) & MDIO_DATA_BSY)
+       while ((memac_in_32(&regs->mdio_data)) & MDIO_DATA_BSY)
                ;
 
        /* Return all Fs if nothing was there */
-       if (in_be32(&regs->mdio_stat) & MDIO_STAT_RD_ER)
+       if (memac_in_32(&regs->mdio_stat) & MDIO_STAT_RD_ER)
                return 0xffff;
 
-       return in_be32(&regs->mdio_data) & 0xffff;
+       return memac_in_32(&regs->mdio_data) & 0xffff;
 }
 
 int memac_mdio_reset(struct mii_dev *bus)
@@ -143,8 +162,9 @@ int fm_memac_mdio_init(bd_t *bis, struct

memac_mdio_info *info)

drivers/net/fm/memac_phy.c int fm_memac_mdio_init(bd_t *bis, struct · line 162

Quoted 1 line
drivers/net/fm/memac_phy.c +0 -0
         * like T2080QDS, this bit default is '0', which leads to MDIO

failure

drivers/net/fm/memac_phy.c int fm_memac_mdio_init(bd_t *bis, struct memac_mdio_info *info)

Quoted 3 lines
drivers/net/fm/memac_phy.c +0 -1
         * on XAUI PHY, so set this bit definitely.
         */
-       setbits_be32(&((struct memac_mdio_controller

*)info->regs)->mdio_stat,

Quoted 31 lines
drivers/net/fm/memac_phy.c +3 -1
-                    MDIO_STAT_CLKDIV(258) | MDIO_STAT_NEG);
+       memac_setbits_32(
+               &((struct memac_mdio_controller *)info->regs)->mdio_stat,
+               MDIO_STAT_CLKDIV(258) | MDIO_STAT_NEG);
 
        return mdio_register(bus);
 }
drivers/net/vsc9953.c +1 -1
index 9fc3c18..fed7358 100644
@@ -9,7 +9,7 @@
 #include <asm/io.h>
 #include <asm/fsl_serdes.h>
 #include <fm_eth.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 #include <vsc9953.h>
 
 static struct vsc9953_info vsc9953_l2sw = {
include/fsl_memac.h renamed from arch/powerpc/include/asm/fsl_memac.h +0 -1
similarity index 100%
rename from arch/powerpc/include/asm/fsl_memac.h
rename to include/fsl_memac.h
--

1.7.9.5

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#34 lore raw

PATCH 15/28 net/memac_phy: reuse driver for little endian SoCs

Hello Joe,

Thank you for reviewing this patch!
Please see inline.

Best Regards,
Shaohui Xie

From: Joe Hershberger [mailto:joe.hershberger at gmail.com]
Sent: Friday, March 20, 2015 2:04 AM
To: Sun York-R58495
Cc: u-boot; Joe Hershberger; Xie Shaohui-B21989
Subject: Re: [U-Boot] [PATCH 15/28] net/memac_phy: reuse driver for little endian SoCs

Hi Shaohui Xie,

Quoted 29 lines · On Thu, Mar 19, 2015 at 11:45 AM, York Sun <yorksun at…

From: Shaohui Xie <Shaohui.Xie at freescale.com<mailto:[email protected]>>

The memac for PHY management on little endian SoCs is similar on big endian SoCs, so we modify the driver by using I/O accessor function to handle the endianness, so the driver can be reused on little endian SoCs, we introduce CONFIG_SYS_MEMAC_LITTLE_ENDIAN for little endian SoCs, if the CONFIG_SYS_MEMAC_LITTLE_ENDIAN is defined, the I/O access is little endian, if not, the I/O access is big endian. Move fsl_memac.h out of powerpc include.

Signed-off-by Shaohui Xie <Shaohui.Xie at freescale.com<mailto:[email protected]>>
CC Joe Hershberger <joe.hershberger at ni.com<mailto:[email protected]>>
---
 arch/arm/include/asm/arch-fsl-lsch3/config.h      |    1 +
 drivers/net/Makefile                              |    1 +
 drivers/net/fm/eth.c                              |    2 +-
 drivers/net/fm/memac.c                            |    2 +-
 drivers/net/fm/memac_phy.c                        |   62 ++++++++++++++-------
 drivers/net/vsc9953.c                             |    2 +-
 {arch/powerpc/include/asm => include}/fsl_memac.h |    0
 7 files changed, 46 insertions(+), 24 deletions(-)
 rename {arch/powerpc/include/asm => include}/fsl_memac.h (100%)
arch/arm/include/asm/arch-fsl-lsch3/config.h +0 -0
index 98db1ef..684c70f 100644

arch/arm/include/asm/arch-fsl-lsch3/config.h line 112

Quoted 4 lines
arch/arm/include/asm/arch-fsl-lsch3/config.h +1 -0
@@ -109,6 +109,7 @@
 
 /* IFC */
 #define CONFIG_SYS_FSL_IFC_LE
+#define CONFIG_SYS_MEMAC_LITTLE_ENDIAN

It seems tedious to have to define this. Can't you just use the functions available?
[S.H] To use a define is based on a concern that we cannot assume the I/O access of an IP share same endianness as the Soc(s), we cannot assume on little endian Soc the I/O access is little endian, on big endian Soc the I/O access is big endian, the I/O access could be little endian on big endian Soc and vice versa.

Quoted 43 lines
arch/arm/include/asm/arch-fsl-lsch3/config.h +0 -0
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR                  (CONFIG_SYS_IMMR + 0x2400000)
drivers/net/Makefile +1 -0
index 5497934..d871093 100644
@@ -66,4 +66,5 @@ obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o xilinx_ll_temac_mdio.o \
 obj-$(CONFIG_ZYNQ_GEM) += zynq_gem.o
 obj-$(CONFIG_FSL_MC_ENET) += fsl-mc/
 obj-$(CONFIG_FSL_MC_ENET) += ldpaa_eth/
+obj-$(CONFIG_FSL_MEMAC) += fm/memac_phy.o
 obj-$(CONFIG_VSC9953) += vsc9953.o
drivers/net/fm/eth.c +1 -1
index 1d1089d..a7a5c69 100644
@@ -15,7 +15,7 @@
 #include <phy.h>
 #include <asm/fsl_dtsec.h>
 #include <asm/fsl_tgec.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 
 #include "fm.h"
 
drivers/net/fm/memac.c +1 -1
index 60e898c..81a64bf 100644
@@ -12,7 +12,7 @@
 #include <phy.h>
 #include <asm/types.h>
 #include <asm/io.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 
 #include "fm.h"
 
drivers/net/fm/memac_phy.c +0 -0
index a155d89..4ab78e6 100644

drivers/net/fm/memac_phy.c line 16

Quoted 8 lines
drivers/net/fm/memac_phy.c +2 -1
@@ -10,9 +10,28 @@
 #include <miiphy.h>
 #include <phy.h>
 #include <asm/io.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 #include <fm_eth.h>
 
+#ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN

This can already be detected, right?

#if __BYTE_ORDER == __LITTLE_ENDIAN
[S.H] The issue is the IP?s I/O access order on LS2 is different from big endian Soc(s).

Quoted 7 lines
drivers/net/fm/memac_phy.c +7 -0
+#define memac_out_32(a, v)     out_le32(a, v)
+#define memac_clrbits_32(a, v) clrbits_le32(a, v)
+#define memac_setbits_32(a, v) setbits_le32(a, v)
+#else
+#define memac_out_32(a, v)     out_be32(a, v)
+#define memac_clrbits_32(a, v) clrbits_be32(a, v)
+#define memac_setbits_32(a, v) setbits_be32(a, v)

drivers/net/fm/memac_phy.c line 33

Quoted 10 lines
drivers/net/fm/memac_phy.c +10 -0
+#endif
+
+static u32 memac_in_32(u32 *reg)
+{
+#ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN
+       return in_le32(reg);
+#else
+       return in_be32(reg);
+#endif
+}

Another option you have is to take the approach that you don't care the endianness. Something like using the this type of pattern:

value = ntohl(in_be32(reg));
out_be32(reg, htonl(value));
[S.H] same concern as above.

Quoted 130 lines
drivers/net/fm/memac_phy.c +22 -20
+
 /*
  * Write value to the PHY for this device to the register at regnum, waiting
  * until the write is done before it returns.  All PHY configuration has to be
@@ -28,31 +47,31 @@ int memac_mdio_write(struct mii_dev *bus, int port_addr, int dev_addr,
        if (dev_addr == MDIO_DEVAD_NONE) {
                c45 = 0; /* clause 22 */
                dev_addr = regnum & 0x1f;
-               clrbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_clrbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
        } else
-               setbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_setbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Set the port and dev addr */
        mdio_ctl = MDIO_CTL_PORT_ADDR(port_addr) | MDIO_CTL_DEV_ADDR(dev_addr);
-       out_be32(&regs->mdio_ctl, mdio_ctl);
+       memac_out_32(&regs->mdio_ctl, mdio_ctl);
 
        /* Set the register address */
        if (c45)
-               out_be32(&regs->mdio_addr, regnum & 0xffff);
+               memac_out_32(&regs->mdio_addr, regnum & 0xffff);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Write the value to the register */
-       out_be32(&regs->mdio_data, MDIO_DATA(value));
+       memac_out_32(&regs->mdio_data, MDIO_DATA(value));
 
        /* Wait till the MDIO write is complete */
-       while ((in_be32(&regs->mdio_data)) & MDIO_DATA_BSY)
+       while ((memac_in_32(&regs->mdio_data)) & MDIO_DATA_BSY)
                ;
 
        return 0;
@@ -75,39 +94,39 @@ int memac_mdio_read(struct mii_dev *bus, int port_addr, int dev_addr,
                        return 0xffff;
                c45 = 0; /* clause 22 */
                dev_addr = regnum & 0x1f;
-               clrbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_clrbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
        } else
-               setbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_setbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Set the Port and Device Addrs */
        mdio_ctl = MDIO_CTL_PORT_ADDR(port_addr) | MDIO_CTL_DEV_ADDR(dev_addr);
-       out_be32(&regs->mdio_ctl, mdio_ctl);
+       memac_out_32(&regs->mdio_ctl, mdio_ctl);
 
        /* Set the register address */
        if (c45)
-               out_be32(&regs->mdio_addr, regnum & 0xffff);
+               memac_out_32(&regs->mdio_addr, regnum & 0xffff);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Initiate the read */
        mdio_ctl |= MDIO_CTL_READ;
-       out_be32(&regs->mdio_ctl, mdio_ctl);
+       memac_out_32(&regs->mdio_ctl, mdio_ctl);
 
        /* Wait till the MDIO write is complete */
-       while ((in_be32(&regs->mdio_data)) & MDIO_DATA_BSY)
+       while ((memac_in_32(&regs->mdio_data)) & MDIO_DATA_BSY)
                ;
 
        /* Return all Fs if nothing was there */
-       if (in_be32(&regs->mdio_stat) & MDIO_STAT_RD_ER)
+       if (memac_in_32(&regs->mdio_stat) & MDIO_STAT_RD_ER)
                return 0xffff;
 
-       return in_be32(&regs->mdio_data) & 0xffff;
+       return memac_in_32(&regs->mdio_data) & 0xffff;
 }
 
 int memac_mdio_reset(struct mii_dev *bus)
@@ -143,8 +162,9 @@ int fm_memac_mdio_init(bd_t *bis, struct memac_mdio_info *info)
         * like T2080QDS, this bit default is '0', which leads to MDIO failure
         * on XAUI PHY, so set this bit definitely.
         */
-       setbits_be32(&((struct memac_mdio_controller *)info->regs)->mdio_stat,
-                    MDIO_STAT_CLKDIV(258) | MDIO_STAT_NEG);
+       memac_setbits_32(
+               &((struct memac_mdio_controller *)info->regs)->mdio_stat,
+               MDIO_STAT_CLKDIV(258) | MDIO_STAT_NEG);
 
        return mdio_register(bus);
 }
drivers/net/vsc9953.c +1 -1
index 9fc3c18..fed7358 100644
@@ -9,7 +9,7 @@
 #include <asm/io.h>
 #include <asm/fsl_serdes.h>
 #include <fm_eth.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 #include <vsc9953.h>
 
 static struct vsc9953_info vsc9953_l2sw = {
include/fsl_memac.h renamed from arch/powerpc/include/asm/fsl_memac.h +0 -1
similarity index 100%
rename from arch/powerpc/include/asm/fsl_memac.h
rename to include/fsl_memac.h
--

1.7.9.5

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de<mailto:[email protected]>
http://lists.denx.de/mailman/listinfo/u-boot

#35 lore raw

PATCH 15/28 net/memac_phy: reuse driver for little endian SoCs

Quoted 17 lines · Shaohui Xie

Hello Joe,

Thank you for reviewing this patch!

Please see inline.

Best Regards,

Shaohui Xie

Quoted 5 lines

From: Joe Hershberger [mailto:joe.hershberger at gmail.com]
Sent: Friday, March 20, 2015 2:04 AM
To: Sun York-R58495
Cc: u-boot; Joe Hershberger; Xie Shaohui-B21989
Subject: Re: [U-Boot] [PATCH 15/28] net/memac_phy: reuse driver for

little endian SoCs

Quoted 25 lines

Hi Shaohui Xie,

Quoted 19 lines · York Sun

From: Shaohui Xie <[email protected]>

The memac for PHY management on little endian SoCs is similar on big endian SoCs, so we modify the driver by using I/O accessor function to handle the endianness, so the driver can be reused on little endian SoCs, we introduce CONFIG_SYS_MEMAC_LITTLE_ENDIAN for little endian SoCs, if the CONFIG_SYS_MEMAC_LITTLE_ENDIAN is defined, the I/O access is little endian, if not, the I/O access is big endian. Move fsl_memac.h out of powerpc include.

CC Joe Hershberger <[email protected]>
---
 arch/arm/include/asm/arch-fsl-lsch3/config.h      |    1 +
 drivers/net/Makefile                              |    1 +
 drivers/net/fm/eth.c                              |    2 +-
 drivers/net/fm/memac.c                            |    2 +-
 drivers/net/fm/memac_phy.c                        |   62

++++++++++++++-------

Quoted 6 lines

Review

Quoted 6 lines
 drivers/net/vsc9953.c                             |    2 +-
 {arch/powerpc/include/asm => include}/fsl_memac.h |    0
 7 files changed, 46 insertions(+), 24 deletions(-)
 rename {arch/powerpc/include/asm => include}/fsl_memac.h (100%)
(quoted diff) +0 -0

b/arch/arm/include/asm/arch-fsl-lsch3/config.h

Quoted 10 lines

arch/arm/include/asm/arch-fsl-lsch3/config.h line 112

Quoted 8 lines

index 98db1ef..684c70f 100644

arch/arm/include/asm/arch-fsl-lsch3/config.h +1 -0
@@ -109,6 +109,7 @@
 
 /* IFC */
 #define CONFIG_SYS_FSL_IFC_LE
+#define CONFIG_SYS_MEMAC_LITTLE_ENDIAN

It seems tedious to have to define this. Can't you just use the functions

available?

Quoted 2 lines

[S.H] To use a define is based on a concern that we cannot assume the I/O

access of an IP share same endianness as the Soc(s), we cannot assume on little endian Soc the I/O access is little endian, on big endian Soc the I/O access is big endian, the I/O access could be little endian on big endian Soc and vice versa.

You're saying that the IP is expected to be in different endianness? If that is practically the case, then I'm fine with this patch. I just want to ensure that it is not just speculative generality.

Quoted 2 lines

arch/arm/include/asm/arch-fsl-lsch3/config.h line 114

Quoted 2 lines
arch/arm/include/asm/arch-fsl-lsch3/config.h +0 -0
 /* PCIe */
 #define CONFIG_SYS_PCIE1_ADDR                  (CONFIG_SYS_IMMR +

0x2400000)

Quoted 5 lines

drivers/net/Makefile obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o

Quoted 5 lines
drivers/net/Makefile +0 -0
index 5497934..d871093 100644
@@ -66,4 +66,5 @@ obj-$(CONFIG_XILINX_LL_TEMAC) += xilinx_ll_temac.o

xilinx_ll_temac_mdio.o \

Quoted 49 lines
Quoted 36 lines
drivers/net/Makefile +1 -0
 obj-$(CONFIG_ZYNQ_GEM) += zynq_gem.o
 obj-$(CONFIG_FSL_MC_ENET) += fsl-mc/
 obj-$(CONFIG_FSL_MC_ENET) += ldpaa_eth/
+obj-$(CONFIG_FSL_MEMAC) += fm/memac_phy.o
 obj-$(CONFIG_VSC9953) += vsc9953.o
drivers/net/fm/eth.c +1 -1
index 1d1089d..a7a5c69 100644
@@ -15,7 +15,7 @@
 #include <phy.h>
 #include <asm/fsl_dtsec.h>
 #include <asm/fsl_tgec.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 
 #include "fm.h"
 
drivers/net/fm/memac.c +1 -1
index 60e898c..81a64bf 100644
@@ -12,7 +12,7 @@
 #include <phy.h>
 #include <asm/types.h>
 #include <asm/io.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 
 #include "fm.h"
 
drivers/net/fm/memac_phy.c +0 -0
index a155d89..4ab78e6 100644

drivers/net/fm/memac_phy.c line 16

Quoted 8 lines
drivers/net/fm/memac_phy.c +2 -1
@@ -10,9 +10,28 @@
 #include <miiphy.h>
 #include <phy.h>
 #include <asm/io.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 #include <fm_eth.h>
 
+#ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN

This can already be detected, right?

Quoted 3 lines

#if __BYTE_ORDER == __LITTLE_ENDIAN

[S.H] The issue is the IP?s I/O access order on LS2 is different from big

endian Soc(s).

Quoted 12 lines
Quoted 12 lines
drivers/net/fm/memac_phy.c +11 -0
+#define memac_out_32(a, v)     out_le32(a, v)
+#define memac_clrbits_32(a, v) clrbits_le32(a, v)
+#define memac_setbits_32(a, v) setbits_le32(a, v)
+#else
+#define memac_out_32(a, v)     out_be32(a, v)
+#define memac_clrbits_32(a, v) clrbits_be32(a, v)
+#define memac_setbits_32(a, v) setbits_be32(a, v)
+#endif
+
+static u32 memac_in_32(u32 *reg)
+{
Quoted 8 lines

drivers/net/fm/memac_phy.c line 33

Quoted 6 lines
drivers/net/fm/memac_phy.c +6 -0
+#ifdef CONFIG_SYS_MEMAC_LITTLE_ENDIAN
+       return in_le32(reg);
+#else
+       return in_be32(reg);
+#endif
+}

Another option you have is to take the approach that you don't care the

endianness. Something like using the this type of pattern:

Quoted 14 lines

value = ntohl(in_be32(reg));

out_be32(reg, htonl(value));

[S.H] same concern as above.

Quoted 3 lines
drivers/net/fm/memac_phy.c +1 -0
+
 /*
  * Write value to the PHY for this device to the register at regnum,

waiting

Quoted 1 line

drivers/net/fm/memac_phy.c line 37

Quoted 1 line
drivers/net/fm/memac_phy.c +0 -0
  * until the write is done before it returns.  All PHY configuration

has to be

Quoted 1 line

drivers/net/fm/memac_phy.c int memac_mdio_write(struct mii_dev *bus, int

Quoted 1 line
drivers/net/fm/memac_phy.c +0 -0
@@ -28,31 +47,31 @@ int memac_mdio_write(struct mii_dev *bus, int

port_addr, int dev_addr,

Quoted 9 lines
Quoted 9 lines
drivers/net/fm/memac_phy.c +2 -2
        if (dev_addr == MDIO_DEVAD_NONE) {
                c45 = 0; /* clause 22 */
                dev_addr = regnum & 0x1f;
-               clrbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_clrbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
        } else
-               setbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_setbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
 
Quoted 7 lines

drivers/net/fm/memac_phy.c int memac_mdio_write(struct mii_dev *bus, int port_addr, int dev_addr,

Quoted 7 lines
drivers/net/fm/memac_phy.c +1 -1
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Set the port and dev addr */
        mdio_ctl = MDIO_CTL_PORT_ADDR(port_addr) |

MDIO_CTL_DEV_ADDR(dev_addr);

Quoted 17 lines
Quoted 17 lines
drivers/net/fm/memac_phy.c +4 -4
-       out_be32(&regs->mdio_ctl, mdio_ctl);
+       memac_out_32(&regs->mdio_ctl, mdio_ctl);
 
        /* Set the register address */
        if (c45)
-               out_be32(&regs->mdio_addr, regnum & 0xffff);
+               memac_out_32(&regs->mdio_addr, regnum & 0xffff);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Write the value to the register */
-       out_be32(&regs->mdio_data, MDIO_DATA(value));
+       memac_out_32(&regs->mdio_data, MDIO_DATA(value));
 
Quoted 7 lines

drivers/net/fm/memac_phy.c int memac_mdio_read(struct mii_dev *bus, int

Quoted 7 lines
drivers/net/fm/memac_phy.c +1 -1
        /* Wait till the MDIO write is complete */
-       while ((in_be32(&regs->mdio_data)) & MDIO_DATA_BSY)
+       while ((memac_in_32(&regs->mdio_data)) & MDIO_DATA_BSY)
                ;
 
        return 0;
@@ -75,39 +94,39 @@ int memac_mdio_read(struct mii_dev *bus, int

port_addr, int dev_addr,

Quoted 9 lines
Quoted 9 lines
drivers/net/fm/memac_phy.c +2 -2
                        return 0xffff;
                c45 = 0; /* clause 22 */
                dev_addr = regnum & 0x1f;
-               clrbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_clrbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
        } else
-               setbits_be32(&regs->mdio_stat, MDIO_STAT_ENC);
+               memac_setbits_32(&regs->mdio_stat, MDIO_STAT_ENC);
 
Quoted 7 lines

drivers/net/fm/memac_phy.c int memac_mdio_read(struct mii_dev *bus, int port_addr, int dev_addr,

Quoted 7 lines
drivers/net/fm/memac_phy.c +1 -1
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Set the Port and Device Addrs */
        mdio_ctl = MDIO_CTL_PORT_ADDR(port_addr) |

MDIO_CTL_DEV_ADDR(dev_addr);

Quoted 28 lines
Quoted 28 lines
drivers/net/fm/memac_phy.c +6 -6
-       out_be32(&regs->mdio_ctl, mdio_ctl);
+       memac_out_32(&regs->mdio_ctl, mdio_ctl);
 
        /* Set the register address */
        if (c45)
-               out_be32(&regs->mdio_addr, regnum & 0xffff);
+               memac_out_32(&regs->mdio_addr, regnum & 0xffff);
 
        /* Wait till the bus is free */
-       while ((in_be32(&regs->mdio_stat)) & MDIO_STAT_BSY)
+       while ((memac_in_32(&regs->mdio_stat)) & MDIO_STAT_BSY)
                ;
 
        /* Initiate the read */
        mdio_ctl |= MDIO_CTL_READ;
-       out_be32(&regs->mdio_ctl, mdio_ctl);
+       memac_out_32(&regs->mdio_ctl, mdio_ctl);
 
        /* Wait till the MDIO write is complete */
-       while ((in_be32(&regs->mdio_data)) & MDIO_DATA_BSY)
+       while ((memac_in_32(&regs->mdio_data)) & MDIO_DATA_BSY)
                ;
 
        /* Return all Fs if nothing was there */
-       if (in_be32(&regs->mdio_stat) & MDIO_STAT_RD_ER)
+       if (memac_in_32(&regs->mdio_stat) & MDIO_STAT_RD_ER)
                return 0xffff;
 
Quoted 6 lines

drivers/net/fm/memac_phy.c int fm_memac_mdio_init(bd_t *bis, struct

Quoted 6 lines
drivers/net/fm/memac_phy.c +1 -1
-       return in_be32(&regs->mdio_data) & 0xffff;
+       return memac_in_32(&regs->mdio_data) & 0xffff;
 }
 
 int memac_mdio_reset(struct mii_dev *bus)
@@ -143,8 +162,9 @@ int fm_memac_mdio_init(bd_t *bis, struct

memac_mdio_info *info)

Quoted 1 line

drivers/net/fm/memac_phy.c int fm_memac_mdio_init(bd_t *bis, struct · line 162

Quoted 1 line
drivers/net/fm/memac_phy.c +0 -0
         * like T2080QDS, this bit default is '0', which leads to MDIO

failure

Quoted 3 lines

drivers/net/fm/memac_phy.c int fm_memac_mdio_init(bd_t *bis, struct memac_mdio_info *info)

Quoted 3 lines
drivers/net/fm/memac_phy.c +0 -1
         * on XAUI PHY, so set this bit definitely.
         */
-       setbits_be32(&((struct memac_mdio_controller

*)info->regs)->mdio_stat,

Quoted 3 lines

drivers/net/fm/memac_phy.c int fm_memac_mdio_init(bd_t *bis, struct memac_mdio_info *info)

Quoted 3 lines
drivers/net/fm/memac_phy.c +2 -1
-                    MDIO_STAT_CLKDIV(258) | MDIO_STAT_NEG);
+       memac_setbits_32(
+               &((struct memac_mdio_controller

*)info->regs)->mdio_stat,

Quoted 28 lines
Quoted 28 lines
drivers/net/fm/memac_phy.c +1 -0
+               MDIO_STAT_CLKDIV(258) | MDIO_STAT_NEG);
 
        return mdio_register(bus);
 }
drivers/net/vsc9953.c +1 -1
index 9fc3c18..fed7358 100644
@@ -9,7 +9,7 @@
 #include <asm/io.h>
 #include <asm/fsl_serdes.h>
 #include <fm_eth.h>
-#include <asm/fsl_memac.h>
+#include <fsl_memac.h>
 #include <vsc9953.h>
 
 static struct vsc9953_info vsc9953_l2sw = {
include/fsl_memac.h renamed from arch/powerpc/include/asm/fsl_memac.h +0 -1
similarity index 100%
rename from arch/powerpc/include/asm/fsl_memac.h
rename to include/fsl_memac.h
--

1.7.9.5

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

#36 lore raw

PATCH 15/28 net/memac_phy: reuse driver for little endian SoCs

Quoted 9 lines
Quoted 5 lines

/* IFC */
#define CONFIG_SYS_FSL_IFC_LE
+#define CONFIG_SYS_MEMAC_LITTLE_ENDIAN

It seems tedious to have to define this. Can't you just use the functions available?

[S.H] To use a define is based on a concern that we cannot assume the I/O access of an IP share same endianness as the Soc(s), we cannot assume on little endian Soc the I/O access is little endian, on big endian Soc the I/O access is big endian, the I/O access could be little endian on big endian Soc and vice versa.

You're saying that the IP is expected to be in different endianness? If that is practically the case, then I'm fine with this patch. I just want to ensure that it is not just speculative generality. [S.H] Yes. The IP is in different endianness, i.e. little endian on LS2, big endian on PowerPc Soc(s).
Thank you!
Shaohui

#37 lore raw

PATCH 15/28 net/memac_phy: reuse driver for little endian SoCs

Quoted 5 lines · Shaohui Xie
Quoted 5 lines
Quoted 3 lines

/* IFC */
#define CONFIG_SYS_FSL_IFC_LE
+#define CONFIG_SYS_MEMAC_LITTLE_ENDIAN

It seems tedious to have to define this. Can't you just use the

functions available?

Quoted 2 lines
Quoted 2 lines

[S.H] To use a define is based on a concern that we cannot assume the

I/O access of an IP share same endianness as the Soc(s), we cannot assume on little endian Soc the I/O access is little endian, on big endian Soc the I/O access is big endian, the I/O access could be little endian on big endian Soc and vice versa.

Quoted 2 lines

You're saying that the IP is expected to be in different endianness? If

that is practically the case, then I'm fine with this patch. I just want to ensure that it is not just speculative generality.

Quoted 2 lines

[S.H] Yes. The IP is in different endianness, i.e. little endian on LS2,

big endian on PowerPc Soc(s).

OK. It seems that in both of your examples the IP endianness matches the SoC endianness, which is why I recommended what I did in the first reply.

If you think that this is needed flexibility, then,

author
#38 lore raw

PATCH 16/28 armv8/fsl-ch3: Add support to print RCW configuration

In reply to York Sun

From: Bhupesh Sharma <[email protected]>

This patch adds support to print out the Reset Configuration Word information.

---
 arch/arm/cpu/armv8/fsl-lsch3/cpu.c |   14 ++++++++++++++
 1 file changed, 14 insertions(+)
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +14 -0
index caa48f2..07064a3 100644
@@ -371,6 +371,7 @@ u32 fsl_qoriq_core_to_type(unsigned int core)
 #ifdef CONFIG_DISPLAY_CPUINFO
 int print_cpuinfo(void)
 {
+	struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
 	struct sys_info sysinfo;
 	char buf[32];
 	unsigned int i, core;
@@ -394,6 +395,19 @@ int print_cpuinfo(void)
 	printf("     DP-DDR:   %-4s MHz", strmhz(buf, sysinfo.freq_ddrbus2));
 	puts("\n");
 
+	/* Display the RCW, so that no one gets confused as to what RCW
+	 * we're actually using for this boot.
+	 */
+	puts("Reset Configuration Word (RCW):");
+	for (i = 0; i < ARRAY_SIZE(gur->rcwsr); i++) {
+		u32 rcw = in_le32(&gur->rcwsr[i]);
+
+		if ((i % 4) == 0)
+			printf("\n       %02x:", i * 4);
+		printf(" %08x", rcw);
+	}
+	puts("\n");
+
 	return 0;
 }
 #endif
Signature · 1 line
1.7.9.5
author
#39 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

In reply to York Sun

From: Scott Wood <[email protected]>

This lets us see the problems (close to) when they happen, rather than Linux hanging when it enables them prior to having a working console.

---
 arch/arm/cpu/armv8/fsl-lsch3/cpu.c |    4 ++++
 1 file changed, 4 insertions(+)
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +4 -0
index 07064a3..22b5fb2 100644
@@ -263,6 +263,10 @@ int arch_cpu_init(void)
 	__asm_invalidate_tlb_all();
 	early_mmu_setup();
 	set_sctlr(get_sctlr() | CR_C);
+
+	/* Enable system error aborts */
+	asm volatile("msr daifclr, #4" : : : "memory");
+
 	return 0;
 }
 
Signature · 1 line
1.7.9.5
#40 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 5 lines · York Sun

From: Scott Wood <[email protected]>

This lets us see the problems (close to) when they happen, rather than Linux hanging when it enables them prior to having a working console.

FYI, if the Linux driver for your UART supports earlycon, that should work since commit 7a9c43bed891d1f8 ("setup: Move unmask of async interrupts after possible earlycon setup").

I hope that SError is masked again prior to entering Linux, as required by the boot protocol?

Mark.

Quoted 28 lines
---
 arch/arm/cpu/armv8/fsl-lsch3/cpu.c |    4 ++++
 1 file changed, 4 insertions(+)
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +4 -0
index 07064a3..22b5fb2 100644
@@ -263,6 +263,10 @@ int arch_cpu_init(void)
 	__asm_invalidate_tlb_all();
 	early_mmu_setup();
 	set_sctlr(get_sctlr() | CR_C);
+
+	/* Enable system error aborts */
+	asm volatile("msr daifclr, #4" : : : "memory");
+
 	return 0;
 }
 
Signature · 6 lines
1.7.9.5

_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
#41 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 10 lines · Mark Rutland
Quoted 5 lines · York Sun

From: Scott Wood <[email protected]>

This lets us see the problems (close to) when they happen, rather than Linux hanging when it enables them prior to having a working console.

FYI, if the Linux driver for your UART supports earlycon, that should work since commit 7a9c43bed891d1f8 ("setup: Move unmask of async interrupts after possible earlycon setup").

I wrote this patch in the context of board bringup, where I was stuck using an older kernel. In any case, when U-Boot causes a problem we want to see it in U-Boot.

Quoted 2 lines

I hope that SError is masked again prior to entering Linux, as required by the boot protocol?

Doesn't look like it based on grepping for daifset.

Where is the boot protocol documented? Just for future reference -- I agree that leaving this enabled during the handover would be a bad thing.

Quoted 3 lines

Mark.

Quoted 1 line

York, where's your signoff since you're the one submitting the patch?

-Scott

author
#42 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 25 lines · Scott Wood
Quoted 10 lines · Mark Rutland
Quoted 5 lines · York Sun

From: Scott Wood <[email protected]>

This lets us see the problems (close to) when they happen, rather than Linux hanging when it enables them prior to having a working console.

FYI, if the Linux driver for your UART supports earlycon, that should work since commit 7a9c43bed891d1f8 ("setup: Move unmask of async interrupts after possible earlycon setup").

I wrote this patch in the context of board bringup, where I was stuck using an older kernel. In any case, when U-Boot causes a problem we want to see it in U-Boot.

Quoted 2 lines

I hope that SError is masked again prior to entering Linux, as required by the boot protocol?

Doesn't look like it based on grepping for daifset.

Where is the boot protocol documented? Just for future reference -- I agree that leaving this enabled during the handover would be a bad thing.

Quoted 5 lines
Quoted 3 lines

Mark.

Quoted 1 line

York, where's your signoff since you're the one submitting the patch?

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

York

#43 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 10 lines · York Sun
Quoted 5 lines · Scott Wood
Quoted 2 lines · Mark Rutland
Quoted 1 line · York Sun

York, where's your signoff since you're the one submitting the patch?

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well?

-Scott

author
#44 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 9 lines · Scott Wood
Quoted 8 lines · York Sun
Quoted 5 lines · Scott Wood
Quoted 2 lines · Mark Rutland
Quoted 1 line · York Sun

York, where's your signoff since you're the one submitting the patch?

Quoted 8 lines
Quoted 2 lines

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well?

I don't have the answer myself. I haven't added any of my signed-off-by for the patches I squashed/tested/sent. For small patch set, I would request the original author to send each patch. For large set with dependency, I send patch on behalf of the authors. I don't want to take credit for the patch I didn't contribute the change. I test all of them though.

If the signed-off-by has different meanings, I am OK to change my practice.

York

#45 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 20 lines · York Sun
Quoted 9 lines · Scott Wood
Quoted 8 lines · York Sun
Quoted 5 lines · Scott Wood
Quoted 2 lines · Mark Rutland
Quoted 1 line · York Sun

York, where's your signoff since you're the one submitting the patch?

Quoted 8 lines
Quoted 2 lines

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well?

Quoted 5 lines

I don't have the answer myself. I haven't added any of my signed-off-by for the patches I squashed/tested/sent. For small patch set, I would request the original author to send each patch. For large set with dependency, I send patch on behalf of the authors. I don't want to take credit for the patch I didn't contribute the change. I test all of them though.

The From: line is for giving credit. Signed-off-by shows the path the patch took. Plus, leaving your name off puts all the blame on the author, when they weren't the ones who decided the patch was ready to submit. :-)

-Scott

author
#46 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 27 lines · Scott Wood
Quoted 20 lines · York Sun
Quoted 9 lines · Scott Wood
Quoted 8 lines · York Sun
Quoted 5 lines · Scott Wood
Quoted 2 lines · Mark Rutland
Quoted 1 line · York Sun

York, where's your signoff since you're the one submitting the patch?

Quoted 8 lines
Quoted 2 lines

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well?

Quoted 5 lines

I don't have the answer myself. I haven't added any of my signed-off-by for the patches I squashed/tested/sent. For small patch set, I would request the original author to send each patch. For large set with dependency, I send patch on behalf of the authors. I don't want to take credit for the patch I didn't contribute the change. I test all of them though.

Quoted 5 lines

The From: line is for giving credit. Signed-off-by shows the path the patch took. Plus, leaving your name off puts all the blame on the author, when they weren't the ones who decided the patch was ready to submit. :-)

When multiple patches are squashed, I put authors' name in signed-off-by. For this reason, I think adding my signoff will be confusing.

But I agree with you that I should have my name somewhere for the patches I sent. Doesn't the email "from" qualify?

York

#47 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 29 lines · York Sun
Quoted 27 lines · Scott Wood
Quoted 25 lines · York Sun
Quoted 9 lines · Scott Wood
Quoted 8 lines · York Sun
Quoted 5 lines · Scott Wood
Quoted 2 lines · Mark Rutland
Quoted 1 line · York Sun

York, where's your signoff since you're the one submitting the patch?

Quoted 8 lines
Quoted 2 lines

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well?

I don't have the answer myself. I haven't added any of my signed-off-by for the patches I squashed/tested/sent. For small patch set, I would request the original author to send each patch. For large set with dependency, I send patch on behalf of the authors. I don't want to take credit for the patch I didn't contribute the change. I test all of them though.

Quoted 8 lines
Quoted 5 lines

The From: line is for giving credit. Signed-off-by shows the path the patch took. Plus, leaving your name off puts all the blame on the author, when they weren't the ones who decided the patch was ready to submit. :-)

When multiple patches are squashed, I put authors' name in signed-off-by. For this reason, I think adding my signoff will be confusing.

If there are multiple authors you can give credit with an explicit statement in the changelog.

Quoted 2 lines

But I agree with you that I should have my name somewhere for the patches I sent. Doesn't the email "from" qualify?

The email "from" doesn't go in the git history.

-Scott

author
#48 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 39 lines · Scott Wood
Quoted 29 lines · York Sun
Quoted 27 lines · Scott Wood
Quoted 25 lines · York Sun
Quoted 9 lines · Scott Wood
Quoted 8 lines · York Sun
Quoted 5 lines · Scott Wood
Quoted 2 lines · Mark Rutland
Quoted 1 line · York Sun

York, where's your signoff since you're the one submitting the patch?

Quoted 8 lines
Quoted 2 lines

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well?

I don't have the answer myself. I haven't added any of my signed-off-by for the patches I squashed/tested/sent. For small patch set, I would request the original author to send each patch. For large set with dependency, I send patch on behalf of the authors. I don't want to take credit for the patch I didn't contribute the change. I test all of them though.

Quoted 8 lines
Quoted 5 lines

The From: line is for giving credit. Signed-off-by shows the path the patch took. Plus, leaving your name off puts all the blame on the author, when they weren't the ones who decided the patch was ready to submit. :-)

When multiple patches are squashed, I put authors' name in signed-off-by. For this reason, I think adding my signoff will be confusing.

Quoted 7 lines

If there are multiple authors you can give credit with an explicit statement in the changelog.

Quoted 2 lines

But I agree with you that I should have my name somewhere for the patches I sent. Doesn't the email "from" qualify?

The email "from" doesn't go in the git history.

Changelog doesn't goes to git history either.

Anyway, adding my signed-off-by is not a burden to me.

York

#49 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 44 lines · York Sun
Quoted 42 lines · Scott Wood
Quoted 29 lines · York Sun
Quoted 27 lines · Scott Wood
Quoted 25 lines · York Sun
Quoted 9 lines · Scott Wood
Quoted 8 lines · York Sun
Quoted 5 lines · Scott Wood
Quoted 2 lines · Mark Rutland
Quoted 1 line · York Sun

York, where's your signoff since you're the one submitting the patch?

Quoted 8 lines
Quoted 2 lines

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well?

I don't have the answer myself. I haven't added any of my signed-off-by for the patches I squashed/tested/sent. For small patch set, I would request the original author to send each patch. For large set with dependency, I send patch on behalf of the authors. I don't want to take credit for the patch I didn't contribute the change. I test all of them though.

Quoted 8 lines
Quoted 5 lines

The From: line is for giving credit. Signed-off-by shows the path the patch took. Plus, leaving your name off puts all the blame on the author, when they weren't the ones who decided the patch was ready to submit. :-)

When multiple patches are squashed, I put authors' name in signed-off-by. For this reason, I think adding my signoff will be confusing.

If there are multiple authors you can give credit with an explicit statement in the changelog.

Quoted 6 lines
Quoted 4 lines
Quoted 2 lines

But I agree with you that I should have my name somewhere for the patches I sent. Doesn't the email "from" qualify?

The email "from" doesn't go in the git history.

Changelog doesn't goes to git history either.

Yes, it does. I'm not talking about the comments below the --- that are sometimes used to give history of the patch itself or other transient info. The stuff above the --- is the git changelog.

-Scott

author
#50 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 48 lines · Scott Wood
Quoted 47 lines · York Sun
Quoted 45 lines · Scott Wood
Quoted 29 lines · York Sun
Quoted 27 lines · Scott Wood
Quoted 25 lines · York Sun
Quoted 9 lines · Scott Wood
Quoted 8 lines · York Sun
Quoted 5 lines · Scott Wood
Quoted 2 lines · Mark Rutland
Quoted 1 line · York Sun

York, where's your signoff since you're the one submitting the patch?

Quoted 8 lines
Quoted 2 lines

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well?

I don't have the answer myself. I haven't added any of my signed-off-by for the patches I squashed/tested/sent. For small patch set, I would request the original author to send each patch. For large set with dependency, I send patch on behalf of the authors. I don't want to take credit for the patch I didn't contribute the change. I test all of them though.

Quoted 8 lines
Quoted 5 lines

The From: line is for giving credit. Signed-off-by shows the path the patch took. Plus, leaving your name off puts all the blame on the author, when they weren't the ones who decided the patch was ready to submit. :-)

When multiple patches are squashed, I put authors' name in signed-off-by. For this reason, I think adding my signoff will be confusing.

If there are multiple authors you can give credit with an explicit statement in the changelog.

Quoted 2 lines

But I agree with you that I should have my name somewhere for the patches I sent. Doesn't the email "from" qualify?

Quoted 8 lines
Quoted 3 lines
Quoted 1 line

The email "from" doesn't go in the git history.

Changelog doesn't goes to git history either.

Yes, it does. I'm not talking about the comments below the --- that are sometimes used to give history of the patch itself or other transient info. The stuff above the --- is the git changelog.

Can you show me some examples so I can follow?

Back to this patch, it is not critical for u-boot to operate. Do you want to drop this patch?

York

#51 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

Quoted 52 lines · York Sun
Quoted 50 lines · Scott Wood
Quoted 49 lines · York Sun
Quoted 46 lines · Scott Wood
Quoted 29 lines · York Sun
Quoted 27 lines · Scott Wood
Quoted 25 lines · York Sun
Quoted 9 lines · Scott Wood
Quoted 8 lines · York Sun
Quoted 5 lines · Scott Wood
Quoted 2 lines · Mark Rutland
Quoted 1 line · York Sun

York, where's your signoff since you're the one submitting the patch?

Quoted 8 lines
Quoted 2 lines

I am sending many patches in this set. Since I didn't contribute to this patch, I didn't add my signed-off-by.

That's not what signed-off-by means. I realize (though never understood why) the U-Boot project differs from Linux rules in terms of whether custodians are expected to sign off patches when applying, but does that extend to submitting patches by e-mail as well?

I don't have the answer myself. I haven't added any of my signed-off-by for the patches I squashed/tested/sent. For small patch set, I would request the original author to send each patch. For large set with dependency, I send patch on behalf of the authors. I don't want to take credit for the patch I didn't contribute the change. I test all of them though.

Quoted 8 lines
Quoted 5 lines

The From: line is for giving credit. Signed-off-by shows the path the patch took. Plus, leaving your name off puts all the blame on the author, when they weren't the ones who decided the patch was ready to submit. :-)

When multiple patches are squashed, I put authors' name in signed-off-by. For this reason, I think adding my signoff will be confusing.

If there are multiple authors you can give credit with an explicit statement in the changelog.

Quoted 2 lines

But I agree with you that I should have my name somewhere for the patches I sent. Doesn't the email "from" qualify?

The email "from" doesn't go in the git history.

Quoted 8 lines
Quoted 6 lines
Quoted 1 line

Changelog doesn't goes to git history either.

Yes, it does. I'm not talking about the comments below the --- that are sometimes used to give history of the patch itself or other transient info. The stuff above the --- is the git changelog.

Can you show me some examples so I can follow?

"This patch includes work by <name>, <name>, and <name>."

Quoted 2 lines

Back to this patch, it is not critical for u-boot to operate. Do you want to drop this patch?

From this patchset, sure. But it ought to be fixed and resubmitted at some point.

-Scott

#52 lore raw

PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts

In reply to Scott Wood
Quoted 8 lines · Scott Wood
Quoted 7 lines · Mark Rutland
Quoted 5 lines · York Sun

From: Scott Wood <[email protected]>

This lets us see the problems (close to) when they happen, rather than Linux hanging when it enables them prior to having a working console.

Quoted 7 lines
Quoted 3 lines

FYI, if the Linux driver for your UART supports earlycon, that should work since commit 7a9c43bed891d1f8 ("setup: Move unmask of async interrupts after possible earlycon setup").

I wrote this patch in the context of board bringup, where I was stuck using an older kernel. In any case, when U-Boot causes a problem we want to see it in U-Boot.

Sure.

The Linux patch helps when Linux triggers an SError after taking ownership of the vectors.

Quoted 4 lines
Quoted 2 lines

I hope that SError is masked again prior to entering Linux, as required by the boot protocol?

Doesn't look like it based on grepping for daifset.

Ok. That should happen before you call the kernel. Otherwise if the kernel triggers an SError between setting up the vectors and discovering the UART, you won't get any output.

Linux requires that all the DAIF exceptions are masked prior to entry.

Quoted 3 lines

Where is the boot protocol documented? Just for future reference -- I agree that leaving this enabled during the handover would be a bad thing.

In the Linux kernel tree see Documentation/arm64/booting.txt [1]. This is periodically updated with clarifications and updates for new architectural features, though it should always remain compatible.

Mark.

[1] https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/arm64/booting.txt

author
#53 lore raw

PATCH 18/28 driver/ldpaa: Add support of WRIOP static data structure

In reply to York Sun

From: Prabhakar Kushwaha <[email protected]>

Wire rate IO Processor (WRIOP) provide support of receive and transmit ethernet frames from the ethernet MAC. Here Each WRIOP block supports upto 64 DPMACs.

Create a house keeping data structure to support upto 16 DPMACs and store external phy related information.

---
 arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c   |    7 +-
 arch/arm/include/asm/arch-fsl-lsch3/config.h      |    3 +
 arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h |   24 ++++
 drivers/net/ldpaa_eth/Makefile                    |    2 +-
 drivers/net/ldpaa_eth/ldpaa_eth.h                 |    4 -
 drivers/net/ldpaa_eth/ldpaa_wriop.c               |  146 +++++++++++++++++++++
 include/fsl-mc/ldpaa_wriop.h                      |   70 ++++++++++
 7 files changed, 250 insertions(+), 6 deletions(-)
 create mode 100644 drivers/net/ldpaa_eth/ldpaa_wriop.c
 create mode 100644 include/fsl-mc/ldpaa_wriop.h
arch/arm/cpu/armv8/fsl-lsch3/fsl_lsch3_serdes.c +6 -1
index 78b9210..02ca126 100644
@@ -9,6 +9,7 @@
 #include <asm/errno.h>
 #include <asm/arch/fsl_serdes.h>
 #include <asm/arch-fsl-lsch3/immap_lsch3.h>
+#include <fsl-mc/ldpaa_wriop.h>
 
 #ifdef CONFIG_SYS_FSL_SRDS_1
 static u8 serdes1_prtcl_map[SERDES_PRCTL_COUNT];
@@ -86,8 +87,12 @@ void serdes_init(u32 sd, u32 sd_addr, u32 sd_prctl_mask, u32 sd_prctl_shift,
 		enum srds_prtcl lane_prtcl = serdes_get_prtcl(sd, cfg, lane);
 		if (unlikely(lane_prtcl >= SERDES_PRCTL_COUNT))
 			debug("Unknown SerDes lane protocol %d\n", lane_prtcl);
-		else
+		else {
 			serdes_prtcl_map[lane_prtcl] = 1;
+#ifdef CONFIG_FSL_MC_ENET
+			wriop_init_dpmac(sd, lane + 1, (int)lane_prtcl);
+#endif
+		}
 	}
 }
 
arch/arm/include/asm/arch-fsl-lsch3/config.h +3 -0
index 684c70f..403b2ef 100644
@@ -38,6 +38,9 @@
 #define CONFIG_SYS_FSL_PMU_CLTBENR		(CONFIG_SYS_FSL_PMU_ADDR + \
 						 0x18A0)
 
+#define CONFIG_SYS_FSL_WRIOP1_ADDR		(CONFIG_SYS_IMMR + 0x7B80000)
+#define CONFIG_SYS_FSL_WRIOP1_MDIO1	(CONFIG_SYS_FSL_WRIOP1_ADDR + 0x16000)
+#define CONFIG_SYS_FSL_WRIOP1_MDIO2	(CONFIG_SYS_FSL_WRIOP1_ADDR + 0x17000)
 #define CONFIG_SYS_FSL_LSCH3_SERDES_ADDR	(CONFIG_SYS_IMMR + 0xEA0000)
 
 /* SP (Cortex-A5) related */
arch/arm/include/asm/arch-fsl-lsch3/immap_lsch3.h +24 -0
index 91cf68b..d6bee60 100644
@@ -47,6 +47,30 @@ struct ccsr_gur {
 	u32	devdisr5;	/* Device disable control 5 */
 	u32	devdisr6;	/* Device disable control 6 */
 	u32	devdisr7;	/* Device disable control 7 */
+#define FSL_CHASSIS3_DEVDISR2_DPMAC1	0x00000001
+#define FSL_CHASSIS3_DEVDISR2_DPMAC2	0x00000002
+#define FSL_CHASSIS3_DEVDISR2_DPMAC3	0x00000004
+#define FSL_CHASSIS3_DEVDISR2_DPMAC4	0x00000008
+#define FSL_CHASSIS3_DEVDISR2_DPMAC5	0x00000010
+#define FSL_CHASSIS3_DEVDISR2_DPMAC6	0x00000020
+#define FSL_CHASSIS3_DEVDISR2_DPMAC7	0x00000040
+#define FSL_CHASSIS3_DEVDISR2_DPMAC8	0x00000080
+#define FSL_CHASSIS3_DEVDISR2_DPMAC9	0x00000100
+#define FSL_CHASSIS3_DEVDISR2_DPMAC10	0x00000200
+#define FSL_CHASSIS3_DEVDISR2_DPMAC11	0x00000400
+#define FSL_CHASSIS3_DEVDISR2_DPMAC12	0x00000800
+#define FSL_CHASSIS3_DEVDISR2_DPMAC13	0x00001000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC14	0x00002000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC15	0x00004000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC16	0x00008000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC17	0x00010000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC18	0x00020000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC19	0x00040000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC20	0x00080000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC21	0x00100000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC22	0x00200000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC23	0x00400000
+#define FSL_CHASSIS3_DEVDISR2_DPMAC24	0x00800000
 	u8	res_08c[0x90-0x8c];
 	u32	coredisru;	/* uppper portion for support of 64 cores */
 	u32	coredisrl;	/* lower portion for support of 64 cores */
drivers/net/ldpaa_eth/Makefile +1 -1
index 3b1a60b..d32d67e 100644
@@ -4,5 +4,5 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-# Layerscape LDPAA driver
+obj-y += ldpaa_wriop.o
 obj-y += ldpaa_eth.o
drivers/net/ldpaa_eth/ldpaa_eth.h +0 -4
index c7760ef..3107ab6 100644
@@ -132,11 +132,7 @@ struct ldpaa_eth_priv {
 	uint16_t tx_flow_id;
 
 	enum ldpaa_eth_type type;	/* 1G or 10G ethernet */
-	phy_interface_t enet_if;
-	struct mii_dev *bus;
 	struct phy_device *phydev;
-	int phyaddr;
-
 };
 
 extern struct fsl_mc_io *dflt_mc_io;
drivers/net/ldpaa_eth/ldpaa_wriop.c new file +146 -0

146 lines not on this page · raw message

include/fsl-mc/ldpaa_wriop.h new file +70 -0

70 lines not on this page · raw message

Signature · 1 line
1.7.9.5
author
#54 lore raw

PATCH 19/28 armv8/ls2085aqds: Add support of LS2085AQDS platform

In reply to York Sun

The LS2080AQDS is an evaluatoin platform that supports the LS2080A family SoCs. This patch add basic support of the platform.

---
 arch/arm/Kconfig                                   |   11 +
 arch/arm/cpu/armv8/fsl-lsch3/README                |   70 ++++-
 board/freescale/{ls1021aqds => ls2085aqds}/Kconfig |    9 +-
 board/freescale/ls2085aqds/MAINTAINERS             |    7 +
 board/freescale/ls2085aqds/Makefile                |    8 +
 board/freescale/ls2085aqds/README                  |  129 +++++++++
 board/freescale/{ls2085a => ls2085aqds}/ddr.c      |  126 ++++-----
 board/freescale/{ls2085a => ls2085aqds}/ddr.h      |   28 +-
 board/freescale/ls2085aqds/ls2085aqds.c            |  287 ++++++++++++++++++++
 .../ls2085aqds_qixis.h}                            |   19 +-
 ...qds_ddr4_nor_defconfig => ls2085aqds_defconfig} |    2 +-
 include/configs/ls2085a_common.h                   |   38 ++-
 include/configs/ls2085aqds.h                       |  283 +++++++++++++++++++
 include/fsl_ddr_sdram.h                            |    1 +
 14 files changed, 902 insertions(+), 116 deletions(-)
 copy board/freescale/{ls1021aqds => ls2085aqds}/Kconfig (54%)
 create mode 100644 board/freescale/ls2085aqds/MAINTAINERS
 create mode 100644 board/freescale/ls2085aqds/Makefile
 create mode 100644 board/freescale/ls2085aqds/README
 copy board/freescale/{ls2085a => ls2085aqds}/ddr.c (64%)
 copy board/freescale/{ls2085a => ls2085aqds}/ddr.h (63%)
 create mode 100644 board/freescale/ls2085aqds/ls2085aqds.c
 copy board/freescale/{ls1021aqds/ls1021aqds_qixis.h => ls2085aqds/ls2085aqds_qixis.h} (53%)
 copy configs/{ls1021aqds_ddr4_nor_defconfig => ls2085aqds_defconfig} (66%)
 create mode 100644 include/configs/ls2085aqds.h
arch/arm/Kconfig +11 -0
index b9ebee1..f4a7851 100644
@@ -648,6 +648,16 @@ config TARGET_LS2085A_SIMU
 	select ARM64
 	select ARMV8_MULTIENTRY
 
+config TARGET_LS2085AQDS
+	bool "Support ls2085aqds"
+	select ARM64
+	select ARMV8_MULTIENTRY
+	help
+	  Support for Freescale LS2085AQDS platform
+	  The LS2085A Development System (QDS) is a high-performance
+	  development platform that supports the QorIQ LS2085A
+	  Layerscape Architecture processor.
+
 config TARGET_LS1021AQDS
 	bool "Support ls1021aqds"
 	select CPU_V7
@@ -793,6 +803,7 @@ source "board/denx/m53evk/Kconfig"
 source "board/embest/mx6boards/Kconfig"
 source "board/esg/ima3-mx53/Kconfig"
 source "board/freescale/ls2085a/Kconfig"
+source "board/freescale/ls2085aqds/Kconfig"
 source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
arch/arm/cpu/armv8/fsl-lsch3/README +62 -8

90 lines not on this page · raw message

board/freescale/ls2085aqds/Kconfig renamed from board/freescale/ls1021aqds/Kconfig +5 -4
similarity index 54%
copy from board/freescale/ls1021aqds/Kconfig
copy to board/freescale/ls2085aqds/Kconfig
index 119b955..deb640d 100644
@@ -1,15 +1,16 @@
-if TARGET_LS1021AQDS
+
+if TARGET_LS2085AQDS
 
 config SYS_BOARD
-	default "ls1021aqds"
+	default "ls2085aqds"
 
 config SYS_VENDOR
 	default "freescale"
 
 config SYS_SOC
-	default "ls102xa"
+	default "fsl-lsch3"
 
 config SYS_CONFIG_NAME
-	default "ls1021aqds"
+	default "ls2085aqds"
 
 endif
board/freescale/ls2085aqds/MAINTAINERS new file +7 -0
new file mode 100644
index 0000000..74b3721
@@ -0,0 +1,7 @@
+LS2085A BOARD
+M:	Prabhakar Kushwaha <[email protected]>
+S:	Maintained
+F:	board/freescale/ls2085aqds/
+F:	board/freescale/ls2085a/ls2085aqds.c
+F:	include/configs/ls2085aqds.h
+F:	configs/ls2085aqds_defconfig
board/freescale/ls2085aqds/Makefile new file +8 -0
new file mode 100644
index 0000000..f174f33
@@ -0,0 +1,8 @@
+#
+# Copyright 2015 Freescale Semiconductor
+#
+# SPDX-License-Identifier:	GPL-2.0+
+#
+
+obj-y += ls2085aqds.o
+obj-y += ddr.o
board/freescale/ls2085aqds/README new file +129 -0

129 lines not on this page · raw message

board/freescale/ls2085aqds/ddr.c renamed from board/freescale/ls2085a/ddr.c +56 -70

173 lines not on this page · raw message

board/freescale/ls2085aqds/ddr.h renamed from board/freescale/ls2085a/ddr.h +17 -11
similarity index 63%
copy from board/freescale/ls2085a/ddr.h
copy to board/freescale/ls2085aqds/ddr.h
index 9958a68..b76ea61 100644
@@ -1,5 +1,5 @@
 /*
- * Copyright 2014 Freescale Semiconductor, Inc.
+ * Copyright 2015 Freescale Semiconductor, Inc.
  *
  * SPDX-License-Identifier:	GPL-2.0+
  */
@@ -28,8 +28,10 @@ static const struct board_specific_parameters udimm0[] = {
 	 *   num|  hi| rank|  clk| wrlvl |   wrlvl   |  wrlvl
 	 * ranks| mhz| GB  |adjst| start |   ctl2    |  ctl3
 	 */
-	{2,  2140, 0, 4,     4, 0x0, 0x0},
-	{1,  2140, 0, 4,     4, 0x0, 0x0},
+	{2,  1350, 0, 4,     6, 0x0708090B, 0x0C0D0E09,},
+	{2,  1666, 0, 4,     7, 0x08090A0C, 0x0D0F100B,},
+	{2,  1900, 0, 4,     7, 0x09090B0D, 0x0E10120B,},
+	{2,  2300, 0, 4,     8, 0x090A0C0F, 0x1012130C,},
 	{}
 };
 
@@ -40,8 +42,10 @@ static const struct board_specific_parameters udimm2[] = {
 	 *   num|  hi| rank|  clk| wrlvl |   wrlvl   |  wrlvl
 	 * ranks| mhz| GB  |adjst| start |   ctl2    |  ctl3
 	 */
-	{2,  2140, 0, 4,     4, 0x0, 0x0},
-	{1,  2140, 0, 4,     4, 0x0, 0x0},
+	{2,  1350, 0, 4,   0xd, 0x0C0A0A00, 0x00000009,},
+	{2,  1666, 0, 4,   0xd, 0x0C0A0A00, 0x00000009,},
+	{2,  1900, 0, 4,   0xe, 0x0D0C0B00, 0x0000000A,},
+	{2,  2200, 0, 4,   0xe, 0x0D0C0B00, 0x0000000A,},
 	{}
 };
 
@@ -51,9 +55,10 @@ static const struct board_specific_parameters rdimm0[] = {
 	 *   num|  hi| rank|  clk| wrlvl |   wrlvl   |  wrlvl
 	 * ranks| mhz| GB  |adjst| start |   ctl2    |  ctl3
 	 */
-	{4,  2140, 0, 5,     4, 0x0, 0x0},
-	{2,  2140, 0, 5,     4, 0x0, 0x0},
-	{1,  2140, 0, 4,     4, 0x0, 0x0},
+	{2,  1350, 0, 4,     6, 0x0708090B, 0x0C0D0E09,},
+	{2,  1666, 0, 4,     7, 0x08090A0C, 0x0D0F100B,},
+	{2,  1900, 0, 4,     7, 0x09090B0D, 0x0E10120B,},
+	{2,  2200, 0, 4,     8, 0x090A0C0F, 0x1012130C,},
 	{}
 };
 
@@ -64,9 +69,10 @@ static const struct board_specific_parameters rdimm2[] = {
 	 *   num|  hi| rank|  clk| wrlvl |   wrlvl   |  wrlvl
 	 * ranks| mhz| GB  |adjst| start |   ctl2    |  ctl3
 	 */
-	{4,  2140, 0, 5,     4, 0x0, 0x0},
-	{2,  2140, 0, 5,     4, 0x0, 0x0},
-	{1,  2140, 0, 4,     4, 0x0, 0x0},
+	{2,  1350, 0, 4,     6, 0x0708090B, 0x0C0D0E09,},
+	{2,  1666, 0, 4,     7, 0x0B0A090C, 0x0D0F100B,},
+	{2,  1900, 0, 4,     7, 0x09090B0D, 0x0E10120B,},
+	{2,  2200, 0, 4,     8, 0x090A0C0F, 0x1012130C,},
 	{}
 };
 
board/freescale/ls2085aqds/ls2085aqds.c new file +287 -0

287 lines not on this page · raw message

board/freescale/ls2085aqds/ls2085aqds_qixis.h renamed from board/freescale/ls1021aqds/ls1021aqds_qixis.h +4 -15
similarity index 53%
copy from board/freescale/ls1021aqds/ls1021aqds_qixis.h
copy to board/freescale/ls2085aqds/ls2085aqds_qixis.h
index 8e482eb..bb43e65 100644
@@ -1,17 +1,11 @@
 /*
- * Copyright 2014 Freescale Semiconductor, Inc.
+ * Copyright 2015 Freescale Semiconductor, Inc.
  *
  * SPDX-License-Identifier:	GPL-2.0+
  */
 
-#ifndef __LS1021AQDS_QIXIS_H__
-#define __LS1021AQDS_QIXIS_H__
-
-/* Definitions of QIXIS Registers for LS1021AQDS */
-
-/* BRDCFG4[4:7]] select EC1 and EC2 as a pair */
-#define BRDCFG4_EMISEL_MASK		0xe0
-#define BRDCFG4_EMISEL_SHIFT		5
+#ifndef __LS2_QDS_QIXIS_H__
+#define __LS2_QDS_QIXIS_H__
 
 /* SYSCLK */
 #define QIXIS_SYSCLK_66			0x0
@@ -22,7 +16,6 @@
 #define QIXIS_SYSCLK_150		0x5
 #define QIXIS_SYSCLK_160		0x6
 #define QIXIS_SYSCLK_166		0x7
-#define QIXIS_SYSCLK_64			0x8
 
 /* DDRCLK */
 #define QIXIS_DDRCLK_66			0x0
@@ -30,8 +23,4 @@
 #define QIXIS_DDRCLK_125		0x2
 #define QIXIS_DDRCLK_133		0x3
 
-#define QIXIS_SRDS1CLK_100		0x0
-
-#define QIXIS_DCU_BRDCFG5		0x55
-
-#endif
+#endif /*__LS2_QDS_QIXIS_H__*/
configs/ls2085aqds_defconfig renamed from configs/ls1021aqds_ddr4_nor_defconfig +1 -1
similarity index 66%
copy from configs/ls1021aqds_ddr4_nor_defconfig
copy to configs/ls2085aqds_defconfig
index 3c57481..e3a17a3 100644
@@ -1,3 +1,3 @@
 CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4"
 CONFIG_ARM=y
-CONFIG_TARGET_LS1021AQDS=y
+CONFIG_TARGET_LS2085AQDS=y
include/configs/ls2085a_common.h +31 -7
index c0e4314..95a5e56 100644
@@ -92,7 +92,7 @@
 #define CONFIG_SYS_I2C_MXC
 
 /* Serial Port */
-#define CONFIG_CONS_INDEX       2
+#define CONFIG_CONS_INDEX       1
 #define CONFIG_SYS_NS16550
 #define CONFIG_SYS_NS16550_SERIAL
 #define CONFIG_SYS_NS16550_REG_SIZE     1
@@ -105,18 +105,35 @@
 #define CONFIG_FSL_IFC
 
 /*
- * During booting, CS0 needs to be at the region of 0x30000000, i.e. the IFC
- * address 0. But this region is limited to 256MB. To accommodate bigger NOR
- * flash and other devices, we will map CS0 to 0x580000000 after relocation.
+ * During booting, IFC is mapped at the region of 0x30000000.
+ * But this region is limited to 256MB. To accommodate NOR, promjet
+ * and FPGA. This region is divided as below:
+ * 0x30000000 - 0x37ffffff : 128MB : NOR flash
+ * 0x38000000 - 0x3BFFFFFF : 64MB  : Promjet
+ * 0x3C000000 - 0x40000000 : 64MB  : FPGA etc
+ *
+ * To accommodate bigger NOR flash and other devices, we will map IFC
+ * chip selects to as below:
+ * 0x5_1000_0000..0x5_1fff_ffff	Memory Hole
+ * 0x5_2000_0000..0x5_3fff_ffff	IFC CSx (FPGA, NAND and others 512MB)
+ * 0x5_4000_0000..0x5_7fff_ffff	ASIC or others 1GB
+ * 0x5_8000_0000..0x5_bfff_ffff	IFC CS0 1GB (NOR/Promjet)
+ * 0x5_C000_0000..0x5_ffff_ffff	IFC CS1 1GB (NOR/Promjet)
+ *
+ * For e.g. NOR flash@CS0 will be mapped to 0x580000000 after relocation.
  * CONFIG_SYS_FLASH_BASE has the final address (core view)
  * CONFIG_SYS_FLASH_BASE_PHYS has the final address (IFC view)
  * CONFIG_SYS_FLASH_BASE_PHYS_EARLY has the temporary IFC address
  * CONFIG_SYS_TEXT_BASE is linked to 0x30000000 for booting
  */
+
 #define CONFIG_SYS_FLASH_BASE			0x580000000ULL
 #define CONFIG_SYS_FLASH_BASE_PHYS		0x80000000
 #define CONFIG_SYS_FLASH_BASE_PHYS_EARLY	0x00000000
 
+#define CONFIG_SYS_FLASH1_BASE_PHYS		0xC0000000
+#define CONFIG_SYS_FLASH1_BASE_PHYS_EARLY	0x8000000
+
 #ifndef CONFIG_SYS_NO_FLASH
 #define CONFIG_FLASH_CFI_DRIVER
 #define CONFIG_SYS_FLASH_CFI
@@ -124,8 +141,15 @@
 #define CONFIG_SYS_FLASH_QUIET_TEST
 #endif
 
-#define CONFIG_SYS_NAND_BASE		0x520000000
-#define CONFIG_SYS_NAND_BASE_PHYS	0x20000000
+#ifndef __ASSEMBLY__
+unsigned long long get_qixis_addr(void);
+#endif
+#define QIXIS_BASE				get_qixis_addr()
+#define QIXIS_BASE_PHYS				0x20000000
+#define QIXIS_BASE_PHYS_EARLY			0xC000000
+
+#define CONFIG_SYS_NAND_BASE			0x530000000ULL
+#define CONFIG_SYS_NAND_BASE_PHYS		0x30000000
 
 /* Debug Server firmware */
 #define CONFIG_SYS_DEBUG_SERVER_DRAM_BLOCK_MIN_SIZE	(512UL * 1024 * 1024)
@@ -223,7 +247,7 @@
 				"hugepages=16"
 #define CONFIG_BOOTCOMMAND		"cp.b $kernel_start $kernel_load "     \
 					"$kernel_size && bootm $kernel_load"
-#define CONFIG_BOOTDELAY		1
+#define CONFIG_BOOTDELAY		10
 
 /* Monitor Command Prompt */
 #define CONFIG_SYS_CBSIZE		512	/* Console I/O Buffer Size */
include/configs/ls2085aqds.h new file +283 -0

283 lines not on this page · raw message

include/fsl_ddr_sdram.h +1 -0
index 6358b6f..e5b6e03 100644
@@ -167,6 +167,7 @@ typedef struct ddr4_spd_eeprom_s generic_spd_eeprom_t;
 #define DDR_CDR2_ODT(x) (x & DDR_CDR2_ODT_MASK)
 #define DDR_CDR2_VREF_OVRD(x)	(0x00008080 | ((((x) - 37) & 0x3F) << 8))
 #define DDR_CDR2_VREF_TRAIN_EN	0x00000080
+#define DDR_CDR2_VREF_RANGE_2	0x00000040
 
 #if (defined(CONFIG_SYS_FSL_DDR_VER) && \
 	(CONFIG_SYS_FSL_DDR_VER >= FSL_DDR_VER_4_7))
Signature · 1 line
1.7.9.5
author
#55 lore raw

PATCH 20/28 armv8/ls2085ardb: Add support of LS2085ARDB platform

In reply to York Sun

The LS2080ARDB is a evaluation platform that supports LS2080A family SoCs. This patch add sbasic support for the platform.

Change-Id I7744b17f074488989de998ab7d487c437cc8eedf
---
 arch/arm/Kconfig                                   |   11 +++
 arch/arm/cpu/armv8/fsl-lsch3/README                |    4 +-
 board/freescale/{ls2085aqds => ls2085ardb}/Kconfig |    6 +-
 board/freescale/ls2085ardb/MAINTAINERS             |    7 ++
 .../freescale/{ls2085aqds => ls2085ardb}/Makefile  |    2 +-
 board/freescale/{ls2085aqds => ls2085ardb}/README  |   46 ++++--------
 board/freescale/{ls2085aqds => ls2085ardb}/ddr.c   |    0
 board/freescale/{ls2085aqds => ls2085ardb}/ddr.h   |    6 +-
 .../ls2085aqds.c => ls2085ardb/ls2085ardb.c}       |   54 +++------------
 .../ls2085ardb_qixis.h}                            |   12 +---
 ...qds_ddr4_nor_defconfig => ls2085ardb_defconfig} |    2 +-
 include/configs/{ls2085aqds.h => ls2085ardb.h}     |   73 ++++++++------------
 12 files changed, 80 insertions(+), 143 deletions(-)
 copy board/freescale/{ls2085aqds => ls2085ardb}/Kconfig (66%)
 create mode 100644 board/freescale/ls2085ardb/MAINTAINERS
 copy board/freescale/{ls2085aqds => ls2085ardb}/Makefile (81%)
 copy board/freescale/{ls2085aqds => ls2085ardb}/README (73%)
 copy board/freescale/{ls2085aqds => ls2085ardb}/ddr.c (100%)
 copy board/freescale/{ls2085aqds => ls2085ardb}/ddr.h (93%)
 copy board/freescale/{ls2085aqds/ls2085aqds.c => ls2085ardb/ls2085ardb.c} (76%)
 copy board/freescale/{ls2085aqds/ls2085aqds_qixis.h => ls2085ardb/ls2085ardb_qixis.h} (61%)
 copy configs/{ls1021aqds_ddr4_nor_defconfig => ls2085ardb_defconfig} (66%)
 copy include/configs/{ls2085aqds.h => ls2085ardb.h} (80%)
arch/arm/Kconfig +11 -0
index f4a7851..7478eb4 100644
@@ -658,6 +658,16 @@ config TARGET_LS2085AQDS
 	  development platform that supports the QorIQ LS2085A
 	  Layerscape Architecture processor.
 
+config TARGET_LS2085ARDB
+	bool "Support ls2085ardb"
+	select ARM64
+	select ARMV8_MULTIENTRY
+	help
+	  Support for Freescale LS2085ARDB platform.
+	  The LS2080A Reference design board (RDB) is a high-performance
+	  development platform that supports the QorIQ LS2085A
+	  LayerScape Architecture processor.
+
 config TARGET_LS1021AQDS
 	bool "Support ls1021aqds"
 	select CPU_V7
@@ -804,6 +814,7 @@ source "board/embest/mx6boards/Kconfig"
 source "board/esg/ima3-mx53/Kconfig"
 source "board/freescale/ls2085a/Kconfig"
 source "board/freescale/ls2085aqds/Kconfig"
+source "board/freescale/ls2085ardb/Kconfig"
 source "board/freescale/ls1021aqds/Kconfig"
 source "board/freescale/ls1021atwr/Kconfig"
 source "board/freescale/mx23evk/Kconfig"
arch/arm/cpu/armv8/fsl-lsch3/README +2 -2
index 817ea1b..4f36e2a 100644
@@ -38,7 +38,7 @@ Flash Layout
 	32-MB NOR flash layout for pre-silicon platforms (simulator and emulator)
 
 (2) A typical layout of various images (including Linux and other firmware images)
-    is shown below considering a 128MB NOR flash device present on QDS
+    is shown below considering a 128MB NOR flash device present on QDS and RDB
     boards:
 	----------------------------------------- ----> 0x5_8800_0000 ---
 	|	.. Unused .. (7M)		|			|
@@ -86,7 +86,7 @@ Flash Layout
 	|	RCW and PBI (1M) 		|			|
 	----------------------------------------- ----> 0x5_8000_0000 ---
 
-	128-MB NOR flash layout for QDS board
+	128-MB NOR flash layout for QDS and RDB boards
 
 Environment Variables
 =====================
board/freescale/ls2085ardb/Kconfig renamed from board/freescale/ls2085aqds/Kconfig +3 -3
similarity index 66%
copy from board/freescale/ls2085aqds/Kconfig
copy to board/freescale/ls2085ardb/Kconfig
index deb640d..85a3dcd 100644
@@ -1,8 +1,8 @@
 
-if TARGET_LS2085AQDS
+if TARGET_LS2085ARDB
 
 config SYS_BOARD
-	default "ls2085aqds"
+	default "ls2085ardb"
 
 config SYS_VENDOR
 	default "freescale"
@@ -11,6 +11,6 @@ config SYS_SOC
 	default "fsl-lsch3"
 
 config SYS_CONFIG_NAME
-	default "ls2085aqds"
+	default "ls2085ardb"
 
 endif
board/freescale/ls2085ardb/MAINTAINERS new file +7 -0
new file mode 100644
index 0000000..436039f
@@ -0,0 +1,7 @@
+LS2085A BOARD
+M:	Prabhakar Kushwaha <[email protected]>
+S:	Maintained
+F:	board/freescale/ls2085ardb/
+F:	board/freescale/ls2085a/ls2085ardb.c
+F:	include/configs/ls2085ardb.h
+F:	configs/ls2085ardb_defconfig
board/freescale/ls2085ardb/Makefile renamed from board/freescale/ls2085aqds/Makefile +1 -1
similarity index 81%
copy from board/freescale/ls2085aqds/Makefile
copy to board/freescale/ls2085ardb/Makefile
index f174f33..0bfe21c 100644
@@ -4,5 +4,5 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-obj-y += ls2085aqds.o
+obj-y += ls2085ardb.o
 obj-y += ddr.o
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +13 -33

88 lines not on this page · raw message

board/freescale/ls2085ardb/ddr.c renamed from board/freescale/ls2085aqds/ddr.c +0 -0
similarity index 100%
copy from board/freescale/ls2085aqds/ddr.c
copy to board/freescale/ls2085ardb/ddr.c
board/freescale/ls2085ardb/ddr.h renamed from board/freescale/ls2085aqds/ddr.h +3 -3
similarity index 93%
copy from board/freescale/ls2085aqds/ddr.h
copy to board/freescale/ls2085ardb/ddr.h
index b76ea61..bda9d4a 100644
@@ -29,9 +29,9 @@ static const struct board_specific_parameters udimm0[] = {
 	 * ranks| mhz| GB  |adjst| start |   ctl2    |  ctl3
 	 */
 	{2,  1350, 0, 4,     6, 0x0708090B, 0x0C0D0E09,},
-	{2,  1666, 0, 4,     7, 0x08090A0C, 0x0D0F100B,},
-	{2,  1900, 0, 4,     7, 0x09090B0D, 0x0E10120B,},
-	{2,  2300, 0, 4,     8, 0x090A0C0F, 0x1012130C,},
+	{2,  1666, 0, 4,     8, 0x08090B0D, 0x0E10100C,},
+	{2,  1900, 0, 4,     8, 0x090A0C0E, 0x1012120D,},
+	{2,  2300, 0, 4,     9, 0x0A0B0C10, 0x1114140E,},
 	{}
 };
 
board/freescale/ls2085ardb/ls2085ardb.c renamed from board/freescale/ls2085aqds/ls2085aqds.c +8 -46

94 lines not on this page · raw message

board/freescale/ls2085ardb/ls2085ardb_qixis.h renamed from board/freescale/ls2085aqds/ls2085aqds_qixis.h +3 -9
similarity index 61%
copy from board/freescale/ls2085aqds/ls2085aqds_qixis.h
copy to board/freescale/ls2085ardb/ls2085ardb_qixis.h
index bb43e65..cb60c00 100644
@@ -4,8 +4,8 @@
  * SPDX-License-Identifier:	GPL-2.0+
  */
 
-#ifndef __LS2_QDS_QIXIS_H__
-#define __LS2_QDS_QIXIS_H__
+#ifndef __LS2_RDB_QIXIS_H__
+#define __LS2_RDB_QIXIS_H__
 
 /* SYSCLK */
 #define QIXIS_SYSCLK_66			0x0
@@ -17,10 +17,4 @@
 #define QIXIS_SYSCLK_160		0x6
 #define QIXIS_SYSCLK_166		0x7
 
-/* DDRCLK */
-#define QIXIS_DDRCLK_66			0x0
-#define QIXIS_DDRCLK_100		0x1
-#define QIXIS_DDRCLK_125		0x2
-#define QIXIS_DDRCLK_133		0x3
-
-#endif /*__LS2_QDS_QIXIS_H__*/
+#endif /*__LS2_RDB_QIXIS_H__*/
configs/ls2085ardb_defconfig renamed from configs/ls1021aqds_ddr4_nor_defconfig +1 -1
similarity index 66%
copy from configs/ls1021aqds_ddr4_nor_defconfig
copy to configs/ls2085ardb_defconfig
index 3c57481..6b64f71 100644
@@ -1,3 +1,3 @@
 CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4"
 CONFIG_ARM=y
-CONFIG_TARGET_LS1021AQDS=y
+CONFIG_TARGET_LS2085ARDB=y
include/configs/ls2085ardb.h renamed from include/configs/ls2085aqds.h +28 -45

140 lines not on this page · raw message

Signature · 1 line
1.7.9.5
#56 lore raw

PATCH 20/28 armv8/ls2085ardb: Add support of LS2085ARDB platform

Quoted 2 lines · York Sun

The LS2080ARDB is a evaluation platform that supports LS2080A family SoCs. This patch add sbasic support for the platform.

s/2080/2085/

Quoted 22 lines
board/freescale/ls2085ardb/Makefile renamed from board/freescale/ls2085aqds/Makefile +1 -1
similarity index 81%
copy from board/freescale/ls2085aqds/Makefile
copy to board/freescale/ls2085ardb/Makefile
index f174f33..0bfe21c 100644
@@ -4,5 +4,5 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-obj-y += ls2085aqds.o
+obj-y += ls2085ardb.o
 obj-y += ddr.o
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +0 -0
similarity index 73%
copy from board/freescale/ls2085aqds/README
copy to board/freescale/ls2085ardb/README
index a4d7b53..19f9d2a 100644

board/freescale/ls2085ardb/README line 5

Quoted 9 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +2 -4
@@ -1,10 +1,8 @@
 Overview
 --------
-The LS2080A Development System (QDS) is a high-performance computing,
+The LS2080A Reference Design (RDB) is a high-performance computing,
 evaluation, and development platform that supports the QorIQ LS2080A
-LayerScape Architecture processor. The LS2080AQDS provides validation and
-SW development platform for the Freescale LS2080A processor series, with
-a complete debugging environment.
+LayerScape Architecture processor.

I don't think Layerscape is supposed to be capitalized that way.

board/freescale/ls2085ardb/README The LS2085A SoC includes the following function and features: · line 51

Quoted 8 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +1 -1
 LS2085A SoC Overview
 ------------------
@@ -50,14 +48,11 @@ The LS2085A SoC includes the following function and features:
  - Service processor (SP) provides pre-boot initialization and secure-boot
   capabilities
 
- LS2080AQDS board Overview
+ LS2080aRDB board Overview

Inconsistent capitalization

board/freescale/ls2085ardb/README The LS2085A SoC includes the following function and features: · line 58

Quoted 9 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +1 -2
 #ifndef __ASSEMBLY__
 unsigned long get_board_sys_clk(void);
-unsigned long get_board_ddr_clk(void);
 #endif
 
 #define CONFIG_SYS_CLK_FREQ		get_board_sys_clk()
-#define CONFIG_DDR_CLK_FREQ		get_board_ddr_clk()
+#define CONFIG_DDR_CLK_FREQ		133333333
 #define COUNTER_FREQUENCY_REAL		(CONFIG_SYS_CLK_FREQ/4)

Why?

board/freescale/ls2085ardb/README unsigned long get_board_ddr_clk(void); · line 39

Quoted 11 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +2 -2
@@ -30,8 +32,8 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_MEM_INIT_VALUE		0xdeadbeef
 #define SPD_EEPROM_ADDRESS1	0x51
 #define SPD_EEPROM_ADDRESS2	0x52
-#define SPD_EEPROM_ADDRESS3	0x53
-#define SPD_EEPROM_ADDRESS4	0x54
+#define SPD_EEPROM_ADDRESS3	0x54
+#define SPD_EEPROM_ADDRESS4	0x53	/* Bard error */
 #define SPD_EEPROM_ADDRESS5	0x55
 #define SPD_EEPROM_ADDRESS6	0x56	/* dummy address */
 #define SPD_EEPROM_ADDRESS	SPD_EEPROM_ADDRESS1

I suspect this should be s/Bard/Board/

board/freescale/ls2085ardb/README unsigned long get_board_ddr_clk(void); · line 111

Quoted 10 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +3 -3
@@ -114,24 +106,24 @@ unsigned long get_board_ddr_clk(void);
 				| CSOR_NAND_ECC_DEC_EN  /* ECC on decode */ \
 				| CSOR_NAND_ECC_MODE_4  /* 4-bit ECC */ \
 				| CSOR_NAND_RAL_3	/* RAL = 2Byes */ \
-				| CSOR_NAND_PGS_2K	/* Page Size = 2K */ \
-				| CSOR_NAND_SPRZ_64/* Spare size = 64 */ \
-				| CSOR_NAND_PB(64))	/*Pages Per Block = 64*/
+				| CSOR_NAND_PGS_4K	/* Page Size = 2K */ \
+				| CSOR_NAND_SPRZ_224	/* Spare size = 64 */ \
+				| CSOR_NAND_PB(128))	/*Pages Per Block = 64*/

Comments don't match code.

board/freescale/ls2085ardb/README unsigned long get_board_ddr_clk(void); · line 146

Quoted 8 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +1 -0
@@ -148,6 +140,7 @@ unsigned long get_board_ddr_clk(void);
 #define QIXIS_LBMAP_DFLTBANK		0x00
 #define QIXIS_LBMAP_ALTBANK		0x04
 #define QIXIS_RST_CTL_RESET		0x31
+#define QIXIS_RST_CTL_RESET_EN		0x30
 #define QIXIS_RCFG_CTL_RECONFIG_IDLE	0x20
 #define QIXIS_RCFG_CTL_RECONFIG_START	0x21
 #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE	0x08

Is this really a difference between the two boards?

-Scott

author
#57 lore raw

PATCH 20/28 armv8/ls2085ardb: Add support of LS2085ARDB platform

Quoted 56 lines · Scott Wood
Quoted 2 lines · York Sun

The LS2080ARDB is a evaluation platform that supports LS2080A family SoCs. This patch add sbasic support for the platform.

s/2080/2085/

Quoted 22 lines
board/freescale/ls2085ardb/Makefile renamed from board/freescale/ls2085aqds/Makefile +1 -1
similarity index 81%
copy from board/freescale/ls2085aqds/Makefile
copy to board/freescale/ls2085ardb/Makefile
index f174f33..0bfe21c 100644
@@ -4,5 +4,5 @@
 # SPDX-License-Identifier:	GPL-2.0+
 #
 
-obj-y += ls2085aqds.o
+obj-y += ls2085ardb.o
 obj-y += ddr.o
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +0 -0
similarity index 73%
copy from board/freescale/ls2085aqds/README
copy to board/freescale/ls2085ardb/README
index a4d7b53..19f9d2a 100644

board/freescale/ls2085ardb/README line 5

Quoted 9 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +2 -4
@@ -1,10 +1,8 @@
 Overview
 --------
-The LS2080A Development System (QDS) is a high-performance computing,
+The LS2080A Reference Design (RDB) is a high-performance computing,
 evaluation, and development platform that supports the QorIQ LS2080A
-LayerScape Architecture processor. The LS2080AQDS provides validation and
-SW development platform for the Freescale LS2080A processor series, with
-a complete debugging environment.
+LayerScape Architecture processor.

I don't think Layerscape is supposed to be capitalized that way.

board/freescale/ls2085ardb/README The LS2085A SoC includes the following function and features: · line 51

Quoted 8 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +1 -1
 LS2085A SoC Overview
 ------------------
@@ -50,14 +48,11 @@ The LS2085A SoC includes the following function and features:
  - Service processor (SP) provides pre-boot initialization and secure-boot
   capabilities
 
- LS2080AQDS board Overview
+ LS2080aRDB board Overview

Inconsistent capitalization

Quoted 5 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +0 -1
 #ifndef __ASSEMBLY__
 unsigned long get_board_sys_clk(void);
-unsigned long get_board_ddr_clk(void);
 #endif
 
Quoted 6 lines

board/freescale/ls2085ardb/README The LS2085A SoC includes the following function and features: · line 58

Quoted 4 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +1 -1
 #define CONFIG_SYS_CLK_FREQ		get_board_sys_clk()
-#define CONFIG_DDR_CLK_FREQ		get_board_ddr_clk()
+#define CONFIG_DDR_CLK_FREQ		133333333
 #define COUNTER_FREQUENCY_REAL		(CONFIG_SYS_CLK_FREQ/4)

Why?

The timer clock source is not a fixed clock. It derives from system clock, dividing by 4. For this board, the system clock is fixed on board. But I don't think the timer clock should be hard-coded.

Quoted 14 lines

board/freescale/ls2085ardb/README unsigned long get_board_ddr_clk(void); · line 39

Quoted 12 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +2 -2
@@ -30,8 +32,8 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_MEM_INIT_VALUE		0xdeadbeef
 #define SPD_EEPROM_ADDRESS1	0x51
 #define SPD_EEPROM_ADDRESS2	0x52
-#define SPD_EEPROM_ADDRESS3	0x53
-#define SPD_EEPROM_ADDRESS4	0x54
+#define SPD_EEPROM_ADDRESS3	0x54
+#define SPD_EEPROM_ADDRESS4	0x53	/* Bard error */
 #define SPD_EEPROM_ADDRESS5	0x55
 #define SPD_EEPROM_ADDRESS6	0x56	/* dummy address */
 #define SPD_EEPROM_ADDRESS	SPD_EEPROM_ADDRESS1

I suspect this should be s/Bard/Board/

Right.

Quoted 13 lines

board/freescale/ls2085ardb/README unsigned long get_board_ddr_clk(void); · line 111

Quoted 11 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +3 -3
@@ -114,24 +106,24 @@ unsigned long get_board_ddr_clk(void);
 				| CSOR_NAND_ECC_DEC_EN  /* ECC on decode */ \
 				| CSOR_NAND_ECC_MODE_4  /* 4-bit ECC */ \
 				| CSOR_NAND_RAL_3	/* RAL = 2Byes */ \
-				| CSOR_NAND_PGS_2K	/* Page Size = 2K */ \
-				| CSOR_NAND_SPRZ_64/* Spare size = 64 */ \
-				| CSOR_NAND_PB(64))	/*Pages Per Block = 64*/
+				| CSOR_NAND_PGS_4K	/* Page Size = 2K */ \
+				| CSOR_NAND_SPRZ_224	/* Spare size = 64 */ \
+				| CSOR_NAND_PB(128))	/*Pages Per Block = 64*/

Comments don't match code.

Result of squashing. Will fix in next version.

Quoted 12 lines

board/freescale/ls2085ardb/README unsigned long get_board_ddr_clk(void); · line 146

Quoted 9 lines
board/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +1 -0
@@ -148,6 +140,7 @@ unsigned long get_board_ddr_clk(void);
 #define QIXIS_LBMAP_DFLTBANK		0x00
 #define QIXIS_LBMAP_ALTBANK		0x04
 #define QIXIS_RST_CTL_RESET		0x31
+#define QIXIS_RST_CTL_RESET_EN		0x30
 #define QIXIS_RCFG_CTL_RECONFIG_IDLE	0x20
 #define QIXIS_RCFG_CTL_RECONFIG_START	0x21
 #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE	0x08

Is this really a difference between the two boards?

RDB is designed to be compatible in many ways to QDS, but it is still different. The QIXIS is compatible with most common registers, but not all of them.

I will send out a new version soon.

York

#58 lore raw

PATCH 20/28 armv8/ls2085ardb: Add support of LS2085ARDB platform

Quoted 15 lines · York Sun
Quoted 6 lines · Scott Wood
Quoted 5 lines · York Sun

#ifndef __ASSEMBLY__
unsigned long get_board_sys_clk(void);
-unsigned long get_board_ddr_clk(void);
#endif

Quoted 6 lines

include/configs/ls2085ardb.h line 27

Quoted 4 lines

#define CONFIG_SYS_CLK_FREQ get_board_sys_clk()

include/configs/ls2085ardb.h renamed from include/configs/ls2085aqds.h +1 -1
-#define CONFIG_DDR_CLK_FREQ		get_board_ddr_clk()
+#define CONFIG_DDR_CLK_FREQ		133333333
 #define COUNTER_FREQUENCY_REAL		(CONFIG_SYS_CLK_FREQ/4)

Why?

Quoted 3 lines

The timer clock source is not a fixed clock. It derives from system clock, dividing by 4. For this board, the system clock is fixed on board. But I don't think the timer clock should be hard-coded.

I was referring to the DDR clock change.

Quoted 12 lines
Quoted 11 lines

include/configs/ls2085ardb.h unsigned long get_board_ddr_clk(void); · line 146

Quoted 8 lines
include/configs/ls2085ardb.h renamed from include/configs/ls2085aqds.h +1 -0
@@ -148,6 +140,7 @@ unsigned long get_board_ddr_clk(void);
 #define QIXIS_LBMAP_DFLTBANK		0x00
 #define QIXIS_LBMAP_ALTBANK		0x04
 #define QIXIS_RST_CTL_RESET		0x31
+#define QIXIS_RST_CTL_RESET_EN		0x30
 #define QIXIS_RCFG_CTL_RECONFIG_IDLE	0x20
 #define QIXIS_RCFG_CTL_RECONFIG_START	0x21
 #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE	0x08

Is this really a difference between the two boards?

Quoted 2 lines

RDB is designed to be compatible in many ways to QDS, but it is still different. The QIXIS is compatible with most common registers, but not all of them.

OK. I wasn't sure if it was just something that got added by someone working on RDB, that also exists on QDS.

-Scott

author
#59 lore raw

PATCH 20/28 armv8/ls2085ardb: Add support of LS2085ARDB platform

Quoted 16 lines · Scott Wood
Quoted 15 lines · York Sun
Quoted 12 lines · Scott Wood

include/configs/ls2085ardb.h line 27

Quoted 9 lines · York Sun

#ifndef __ASSEMBLY__
unsigned long get_board_sys_clk(void);

include/configs/ls2085ardb.h renamed from include/configs/ls2085aqds.h +1 -2
-unsigned long get_board_ddr_clk(void);
 #endif
 
 #define CONFIG_SYS_CLK_FREQ		get_board_sys_clk()
-#define CONFIG_DDR_CLK_FREQ		get_board_ddr_clk()
+#define CONFIG_DDR_CLK_FREQ		133333333
 #define COUNTER_FREQUENCY_REAL		(CONFIG_SYS_CLK_FREQ/4)

Why?

Quoted 5 lines
Quoted 3 lines

The timer clock source is not a fixed clock. It derives from system clock, dividing by 4. For this board, the system clock is fixed on board. But I don't think the timer clock should be hard-coded.

I was referring to the DDR clock change.

DDR reference clock is fixed on RDB.

Quoted 13 lines
Quoted 13 lines
Quoted 12 lines

include/configs/ls2085ardb.h unsigned long get_board_ddr_clk(void); · line 146

Quoted 9 lines
include/configs/ls2085ardb.h renamed from include/configs/ls2085aqds.h +1 -0
@@ -148,6 +140,7 @@ unsigned long get_board_ddr_clk(void);
 #define QIXIS_LBMAP_DFLTBANK		0x00
 #define QIXIS_LBMAP_ALTBANK		0x04
 #define QIXIS_RST_CTL_RESET		0x31
+#define QIXIS_RST_CTL_RESET_EN		0x30
 #define QIXIS_RCFG_CTL_RECONFIG_IDLE	0x20
 #define QIXIS_RCFG_CTL_RECONFIG_START	0x21
 #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE	0x08

Is this really a difference between the two boards?

Quoted 6 lines
Quoted 2 lines

RDB is designed to be compatible in many ways to QDS, but it is still different. The QIXIS is compatible with most common registers, but not all of them.

OK. I wasn't sure if it was just something that got added by someone working on RDB, that also exists on QDS.

The RST_CTL_RESET_EN bit? It was enabled by default on QDS, but disable on RDB. We need to enable it in order to use "reset" command.

York

author
#60 lore raw

PATCH 21/28 drivers/fsl-mc: Autoload AOIP image from NOR flash

In reply to York Sun

From: "J. German Rivera" <[email protected]>

Load AIOP image from NOR flash into DDR so that the MC firmware the MC fw can start it at boot time.

Change-Id I19e23d983e7f947a4398e0421600057e0d7be6a3
[York Sun: This is a debug commit. Will drop once AIOP is loaded by Linux]
---
 drivers/net/fsl-mc/mc.c          |   24 ++++++++++++++++++++++++
 include/configs/ls2085a_common.h |    2 ++
 include/configs/ls2085aqds.h     |    3 +++
 include/configs/ls2085ardb.h     |    3 +++
 4 files changed, 32 insertions(+)
drivers/net/fsl-mc/mc.c +24 -0
index c5c44bc..e6f6d55 100644
@@ -298,6 +298,24 @@ static int load_mc_dpl(u64 mc_ram_addr, size_t mc_ram_size)
 	return 0;
 }
 
+#ifdef CONFIG_SYS_LS_MC_AIOP_IMG_IN_NOR
+static int load_mc_aiop_img(u64 mc_ram_addr, size_t mc_ram_size)
+{
+	void *aiop_img;
+
+	/*
+	 * Load the MC AIOP image in the MC private DRAM block:
+	 */
+
+	aiop_img = (void *)CONFIG_SYS_LS_MC_AIOP_IMG_ADDR;
+	mc_copy_image("MC AIOP image",
+		      (u64)aiop_img, CONFIG_SYS_LS_MC_AIOP_IMG_MAX_LENGTH,
+		      mc_ram_addr + CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET);
+
+	return 0;
+}
+#endif
+
 /**
  * Return the MC boot timeout value in milliseconds
  */
@@ -454,6 +472,12 @@ int mc_init(void)
 	if (error != 0)
 		goto out;
 
+#ifdef CONFIG_SYS_LS_MC_AIOP_IMG_IN_NOR
+	error = load_mc_aiop_img(mc_ram_addr, mc_ram_size);
+	if (error != 0)
+		goto out;
+#endif
+
 	debug("mc_ccsr_regs %p\n", mc_ccsr_regs);
 	dump_mc_ccsr_regs(mc_ccsr_regs);
 
include/configs/ls2085a_common.h +2 -0
index 95a5e56..3fee92a 100644
@@ -164,6 +164,8 @@ unsigned long long get_qixis_addr(void);
 #define CONFIG_SYS_LS_MC_DRAM_DPC_OFFSET    0x00F00000
 #define CONFIG_SYS_LS_MC_DPL_MAX_LENGTH	    0x20000
 #define CONFIG_SYS_LS_MC_DRAM_DPL_OFFSET    0x00F20000
+#define CONFIG_SYS_LS_MC_AIOP_IMG_MAX_LENGTH	0x200000
+#define CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET	0x1f800000
 
 /* Carve out a DDR region which will not be used by u-boot/Linux */
 #if defined(CONFIG_FSL_MC_ENET) || defined(CONFIG_FSL_DEBUG_SERVER)
include/configs/ls2085aqds.h +3 -0
index 70162e7..961e4dd 100644
@@ -218,6 +218,9 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_SYS_LS_MC_DPC_IN_NOR
 #define CONFIG_SYS_LS_MC_DPC_ADDR	0x580800000ULL
 
+#define CONFIG_SYS_LS_MC_AIOP_IMG_IN_NOR
+#define CONFIG_SYS_LS_MC_AIOP_IMG_ADDR	0x580900000ULL
+
 #define CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS 5000
 
 /*
include/configs/ls2085ardb.h +3 -0
index 5f7ea7b..24400e4 100644
@@ -201,6 +201,9 @@ unsigned long get_board_sys_clk(void);
 #define CONFIG_SYS_LS_MC_DPC_IN_NOR
 #define CONFIG_SYS_LS_MC_DPC_ADDR	0x580800000ULL
 
+#define CONFIG_SYS_LS_MC_AIOP_IMG_IN_NOR
+#define CONFIG_SYS_LS_MC_AIOP_IMG_ADDR	0x580900000ULL
+
 #define CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS 5000
 
 /*
Signature · 1 line
1.7.9.5
author
#61 lore raw

PATCH 22/28 board/ls2085qds: Add support ethernet

In reply to York Sun

From: Prabhakar Kushwaha <[email protected]>

Add support of ethernet:
- eth.c: mapping lane to slot for (0x2A, 0x07)
- ls2085a.c: To enable/disable dpmac and get link type

Change-Id I6d79a9633f3e31b3c23c839b9e9660ee59f0cc0c
---
 board/freescale/ls2085aqds/Makefile           |    1 +
 board/freescale/ls2085aqds/eth.c              |  380 +++++++++++++++++++++++++
 board/freescale/ls2085aqds/ls2085aqds.c       |   13 -
 board/freescale/ls2085aqds/ls2085aqds_qixis.h |    4 +
 drivers/net/ldpaa_eth/Makefile                |    1 +
 drivers/net/ldpaa_eth/ls2085a.c               |   83 ++++++
 include/configs/ls2085aqds.h                  |   19 ++
 7 files changed, 488 insertions(+), 13 deletions(-)
 create mode 100644 board/freescale/ls2085aqds/eth.c
 create mode 100644 drivers/net/ldpaa_eth/ls2085a.c
board/freescale/ls2085aqds/Makefile +1 -0
index f174f33..da69a7d 100644
@@ -6,3 +6,4 @@
 
 obj-y += ls2085aqds.o
 obj-y += ddr.o
+obj-y += eth.o
board/freescale/ls2085aqds/eth.c new file +380 -0

380 lines not on this page · raw message

board/freescale/ls2085aqds/ls2085aqds.c +0 -13
index f7ed5b9..6a22122 100644
@@ -214,19 +214,6 @@ unsigned long get_dram_size_to_hide(void)
 	return dram_to_hide;
 }
 
-int board_eth_init(bd_t *bis)
-{
-	int error = 0;
-
-#ifdef CONFIG_FSL_MC_ENET
-	error = cpu_eth_init(bis);
-#endif
-
-	error = pci_eth_init(bis);
-
-	return error;
-}
-
 #ifdef CONFIG_FSL_MC_ENET
 void fdt_fixup_board_enet(void *fdt)
 {
board/freescale/ls2085aqds/ls2085aqds_qixis.h +4 -0
index bb43e65..e281e5f 100644
@@ -23,4 +23,8 @@
 #define QIXIS_DDRCLK_125		0x2
 #define QIXIS_DDRCLK_133		0x3
 
+#define BRDCFG4_EMISEL_MASK		0xE0
+#define BRDCFG4_EMISEL_SHIFT		5
+#define BRDCFG9_SFPTX_MASK		0x10
+#define BRDCFG9_SFPTX_SHIFT		4
 #endif /*__LS2_QDS_QIXIS_H__*/
drivers/net/ldpaa_eth/Makefile +1 -0
index d32d67e..c37633f 100644
@@ -6,3 +6,4 @@
 
 obj-y += ldpaa_wriop.o
 obj-y += ldpaa_eth.o
+obj-$(CONFIG_LS2085A) += ls2085a.o
drivers/net/ldpaa_eth/ls2085a.c new file +83 -0

83 lines not on this page · raw message

include/configs/ls2085aqds.h +19 -0
index 961e4dd..5ac5b63 100644
@@ -283,4 +283,23 @@ unsigned long get_board_ddr_clk(void);
 	"kernel_load=0xa0000000\0"		\
 	"kernel_size=0x1000000\0"
 
+#ifdef CONFIG_FSL_MC_ENET
+#define CONFIG_FSL_MEMAC
+#define	CONFIG_PHYLIB
+#define CONFIG_PHYLIB_10G
+#define	CONFIG_CMD_MII
+#define CONFIG_PHY_VITESSE
+#define CONFIG_PHY_REALTEK
+#define CONFIG_PHY_TERANETICS
+#define SGMII_CARD_PORT1_PHY_ADDR 0x1C
+#define SGMII_CARD_PORT2_PHY_ADDR 0x1d
+#define SGMII_CARD_PORT3_PHY_ADDR 0x1E
+#define SGMII_CARD_PORT4_PHY_ADDR 0x1F
+
+#define CONFIG_MII		/* MII PHY management */
+#define CONFIG_ETHPRIME		"DPNI1"
+#define CONFIG_PHY_GIGE		/* Include GbE speed/duplex detection */
+
+#endif
+
 #endif /* __LS2_QDS_H */
Signature · 1 line
1.7.9.5
author
#62 lore raw

PATCH 23/28 driver/ifc: Add 64KB page support

In reply to York Sun

From: Jaiprakash Singh <[email protected]>

IFC has two register pages.Till IFC version 1.4 each register page is 4KB each.But IFC ver 2.0 register page size is 64KB each.IFC regiters structure is break into two viz FCM and RUNTIME.FCM(Flash control machine) registers are defined in PAGE0 and controls IFC generic functionality. RUNTIME registers are defined in PAGE1 and controls NAND and GPCM funcinality.

FCM and RUNTIME structures defination is common for IFC version 1.4 and 2.0.

Change-Id I64800b3ed1a32c77ae3f2ac007e289e3078c2c09
---
 arch/arm/cpu/armv7/ls102xa/clock.c        |    4 +-
 arch/arm/cpu/armv8/fsl-lsch3/speed.c      |    4 +-
 arch/powerpc/cpu/mpc85xx/cpu_init_early.c |    8 +--
 arch/powerpc/cpu/mpc85xx/speed.c          |    4 +-
 board/freescale/bsc9132qds/bsc9132qds.c   |    4 +-
 board/freescale/c29xpcie/c29xpcie.c       |    4 +-
 board/freescale/p1010rdb/p1010rdb.c       |    5 +-
 board/freescale/p1010rdb/spl.c            |    4 +-
 drivers/mtd/nand/fsl_ifc_nand.c           |   53 ++++++++++--------
 drivers/mtd/nand/fsl_ifc_spl.c            |   23 ++++++--
 include/fsl_ifc.h                         |   84 +++++++++++++++++++----------
 11 files changed, 126 insertions(+), 71 deletions(-)
arch/arm/cpu/armv7/ls102xa/clock.c +2 -2
index 8f80c61..7a337e1 100644
@@ -20,7 +20,7 @@ void get_sys_info(struct sys_info *sys_info)
 {
 	struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
 #ifdef CONFIG_FSL_IFC
-	struct fsl_ifc *ifc_regs = (void *)CONFIG_SYS_IFC_ADDR;
+	struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
 	u32 ccr;
 #endif
 	struct ccsr_clk *clk = (void *)(CONFIG_SYS_FSL_LS1_CLK_ADDR);
@@ -74,7 +74,7 @@ void get_sys_info(struct sys_info *sys_info)
 	}
 
 #if defined(CONFIG_FSL_IFC)
-	ccr = in_be32(&ifc_regs->ifc_ccr);
+	ccr = in_be32(&ifc_regs.gregs->ifc_ccr);
 	ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1;
 
 	sys_info->freq_localbus = sys_info->freq_systembus / ccr;
arch/arm/cpu/armv8/fsl-lsch3/speed.c +2 -2
index 2b140cd..cac4f92 100644
@@ -26,7 +26,7 @@ void get_sys_info(struct sys_info *sys_info)
 {
 	struct ccsr_gur __iomem *gur = (void *)(CONFIG_SYS_FSL_GUTS_ADDR);
 #ifdef CONFIG_FSL_IFC
-	struct fsl_ifc *ifc_regs = (void *)CONFIG_SYS_IFC_ADDR;
+	struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
 	u32 ccr;
 #endif
 	struct ccsr_clk_cluster_group __iomem *clk_grp[2] = {
@@ -118,7 +118,7 @@ void get_sys_info(struct sys_info *sys_info)
 	}
 
 #if defined(CONFIG_FSL_IFC)
-	ccr = in_le32(&ifc_regs->ifc_ccr);
+	ccr = in_le32(&ifc_regs.gregs->ifc_ccr);
 	ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1;
 
 	sys_info->freq_localbus = sys_info->freq_systembus / ccr;
arch/powerpc/cpu/mpc85xx/cpu_init_early.c +4 -4
index 5ca9bf5..235a635 100644
@@ -15,7 +15,7 @@ DECLARE_GLOBAL_DATA_PTR;
 #ifdef CONFIG_A003399_NOR_WORKAROUND
 void setup_ifc(void)
 {
-	struct fsl_ifc *ifc_regs = (void *)CONFIG_SYS_IFC_ADDR;
+	struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
 	u32 _mas0, _mas1, _mas2, _mas3, _mas7;
 	phys_addr_t flash_phys = CONFIG_SYS_FLASH_BASE_PHYS;
 
@@ -70,9 +70,9 @@ void setup_ifc(void)
 #endif
 
 	/* Change flash's physical address */
-	ifc_out32(&(ifc_regs->cspr_cs[0].cspr), CONFIG_SYS_CSPR0);
-	ifc_out32(&(ifc_regs->csor_cs[0].csor), CONFIG_SYS_CSOR0);
-	ifc_out32(&(ifc_regs->amask_cs[0].amask), CONFIG_SYS_AMASK0);
+	ifc_out32(&(ifc_regs.gregs->cspr_cs[0].cspr), CONFIG_SYS_CSPR0);
+	ifc_out32(&(ifc_regs.gregs->csor_cs[0].csor), CONFIG_SYS_CSOR0);
+	ifc_out32(&(ifc_regs.gregs->amask_cs[0].amask), CONFIG_SYS_AMASK0);
 
 	return ;
 }
arch/powerpc/cpu/mpc85xx/speed.c +2 -2
index e24b857..321ade2 100644
@@ -28,7 +28,7 @@ void get_sys_info(sys_info_t *sys_info)
 {
 	volatile ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
 #ifdef CONFIG_FSL_IFC
-	struct fsl_ifc *ifc_regs = (void *)CONFIG_SYS_IFC_ADDR;
+	struct fsl_ifc ifc_regs = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
 	u32 ccr;
 #endif
 #ifdef CONFIG_FSL_CORENET
@@ -597,7 +597,7 @@ void get_sys_info(sys_info_t *sys_info)
 #endif
 
 #if defined(CONFIG_FSL_IFC)
-	ccr = ifc_in32(&ifc_regs->ifc_ccr);
+	ccr = ifc_in32(&ifc_regs.gregs->ifc_ccr);
 	ccr = ((ccr & IFC_CCR_CLK_DIV_MASK) >> IFC_CCR_CLK_DIV_SHIFT) + 1;
 
 	sys_info->freq_localbus = sys_info->freq_systembus / ccr;
board/freescale/bsc9132qds/bsc9132qds.c +2 -2
index 36a68db..586dacc 100644
@@ -36,9 +36,9 @@ DECLARE_GLOBAL_DATA_PTR;
 
 int board_early_init_f(void)
 {
-	struct fsl_ifc *ifc = (void *)CONFIG_SYS_IFC_ADDR;
+	struct fsl_ifc ifc = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
 
-	setbits_be32(&ifc->ifc_gcr, 1 << IFC_GCR_TBCTL_TRN_TIME_SHIFT);
+	setbits_be32(&ifc.gregs->ifc_gcr, 1 << IFC_GCR_TBCTL_TRN_TIME_SHIFT);
 
 	return 0;
 }
board/freescale/c29xpcie/c29xpcie.c +2 -2
index d757709..f42d373 100644
@@ -38,10 +38,10 @@ int checkboard(void)
 
 int board_early_init_f(void)
 {
-	struct fsl_ifc *ifc = (void *)CONFIG_SYS_IFC_ADDR;
+	struct fsl_ifc ifc = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
 
 	/* Clock configuration to access CPLD using IFC(GPCM) */
-	setbits_be32(&ifc->ifc_gcr, 1 << IFC_GCR_TBCTL_TRN_TIME_SHIFT);
+	setbits_be32(&ifc.gregs->ifc_gcr, 1 << IFC_GCR_TBCTL_TRN_TIME_SHIFT);
 
 	return 0;
 }
board/freescale/p1010rdb/p1010rdb.c +2 -3
index 1cf0ab7..ebffe9a 100644
@@ -77,10 +77,9 @@ struct cpld_data {
 int board_early_init_f(void)
 {
 	ccsr_gpio_t *pgpio = (void *)(CONFIG_SYS_MPC85xx_GPIO_ADDR);
-	struct fsl_ifc *ifc = (void *)CONFIG_SYS_IFC_ADDR;
-
+	struct fsl_ifc ifc = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
 	/* Clock configuration to access CPLD using IFC(GPCM) */
-	setbits_be32(&ifc->ifc_gcr, 1 << IFC_GCR_TBCTL_TRN_TIME_SHIFT);
+	setbits_be32(&ifc.gregs->ifc_gcr, 1 << IFC_GCR_TBCTL_TRN_TIME_SHIFT);
 	/*
 	* Reset PCIe slots via GPIO4
 	*/
board/freescale/p1010rdb/spl.c +2 -2
index 11bd9cf..ee873b0 100644
@@ -23,12 +23,12 @@ void board_init_f(ulong bootflag)
 {
 	u32 plat_ratio;
 	ccsr_gur_t *gur = (void *)CONFIG_SYS_MPC85xx_GUTS_ADDR;
-	struct fsl_ifc *ifc = (void *)CONFIG_SYS_IFC_ADDR;
+	struct fsl_ifc ifc = {(void *)CONFIG_SYS_IFC_ADDR, (void *)NULL};
 
 	console_init_f();
 
 	/* Clock configuration to access CPLD using IFC(GPCM) */
-	setbits_be32(&ifc->ifc_gcr, 1 << IFC_GCR_TBCTL_TRN_TIME_SHIFT);
+	setbits_be32(&ifc.gregs->ifc_gcr, 1 << IFC_GCR_TBCTL_TRN_TIME_SHIFT);
 
 #ifdef CONFIG_P1010RDB_PB
 	setbits_be32(&gur->pmuxcr2, MPC85xx_PMUXCR2_GPIO01_DRVVBUS);
drivers/mtd/nand/fsl_ifc_nand.c +32 -21

153 lines not on this page · raw message

drivers/mtd/nand/fsl_ifc_spl.c +20 -3
index fb827c5..2fb9fb1 100644
@@ -48,9 +48,23 @@ static inline int check_read_ecc(uchar *buf, u32 *eccstat,
 	return 0;
 }
 
+static inline struct fsl_ifc_runtime *runtime_regs_address(void)
+{
+	struct fsl_ifc regs = {(void *)CONFIG_SYS_IFC_ADDR, NULL};
+	int ver = 0;
+
+	ver = ifc_in32(&regs.gregs->ifc_rev);
+	if (ver >= FSL_IFC_V2_0_0)
+		regs.rregs = (void *)CONFIG_SYS_IFC_ADDR + IFC_RREGS_64KOFFSET;
+	else
+		regs.rregs = (void *)CONFIG_SYS_IFC_ADDR + IFC_RREGS_4KOFFSET;
+
+	return regs.rregs;
+}
+
 static inline void nand_wait(uchar *buf, int bufnum, int page_size)
 {
-	struct fsl_ifc *ifc = IFC_BASE_ADDR;
+	struct fsl_ifc_runtime *ifc = runtime_regs_address();
 	u32 status;
 	u32 eccstat[4];
 	int bufperpage = page_size / 512;
@@ -90,7 +104,8 @@ static inline int bad_block(uchar *marker, int port_size)
 
 int nand_spl_load_image(uint32_t offs, unsigned int uboot_size, void *vdst)
 {
-	struct fsl_ifc *ifc = IFC_BASE_ADDR;
+	struct fsl_ifc_fcm *gregs = (void *)CONFIG_SYS_IFC_ADDR;
+	struct fsl_ifc_runtime *ifc = NULL;
 	uchar *buf = (uchar *)CONFIG_SYS_NAND_BASE;
 	int page_size;
 	int port_size;
@@ -107,6 +122,8 @@ int nand_spl_load_image(uint32_t offs, unsigned int uboot_size, void *vdst)
 	int pg_no;
 	uchar *dst = vdst;
 
+	ifc = runtime_regs_address();
+
 	/* Get NAND Flash configuration */
 	csor = CONFIG_SYS_NAND_CSOR;
 	cspr = CONFIG_SYS_NAND_CSPR;
@@ -130,7 +147,7 @@ int nand_spl_load_image(uint32_t offs, unsigned int uboot_size, void *vdst)
 			bad_marker = 5;
 	}
 
-	ver = ifc_in32(&ifc->ifc_rev);
+	ver = ifc_in32(&gregs->ifc_rev);
 	if (ver >= FSL_IFC_V2_0_0)
 		bufnum_mask = (bufnum_mask * 2) + 1;
 
include/fsl_ifc.h +56 -28

135 lines not on this page · raw message

Signature · 1 line
1.7.9.5
author
#63 lore raw

PATCH 24/28 armv8/ls2085aqds: NAND boot support

In reply to York Sun

From: Scott Wood <[email protected]>

This adds NAND boot support for LS2085AQDS, using SPL framework.

To form a NAND image, append u-boot-with-spl.bin after a proper nand boot RCW and flash to the beginning of NAND.

---
 arch/arm/Kconfig                                  |    1 +
 arch/arm/cpu/armv8/fsl-lsch3/soc.c                |   48 +++++++++++++
 arch/arm/cpu/armv8/{u-boot.lds => u-boot-spl.lds} |   74 +++++++++------------
 arch/arm/include/asm/arch-fsl-lsch3/config.h      |    9 +++
 arch/arm/lib/crt0_64.S                            |    7 ++
 board/freescale/ls2085aqds/ddr.c                  |    4 ++
 common/spl/spl.c                                  |    2 +-
 common/spl/spl_nand.c                             |    2 +-
 configs/ls2085aqds_nand_defconfig                 |    4 ++
 drivers/misc/fsl_ifc.c                            |   12 ++++
 drivers/mtd/nand/fsl_ifc_spl.c                    |    2 +-
 include/configs/ls2085a_common.h                  |   29 ++++++++
 include/configs/ls2085aqds.h                      |   50 ++++++++++++--
 13 files changed, 193 insertions(+), 51 deletions(-)
 copy arch/arm/cpu/armv8/{u-boot.lds => u-boot-spl.lds} (57%)
 create mode 100644 configs/ls2085aqds_nand_defconfig
arch/arm/Kconfig +1 -0
index 7478eb4..46a48a0 100644
@@ -652,6 +652,7 @@ config TARGET_LS2085AQDS
 	bool "Support ls2085aqds"
 	select ARM64
 	select ARMV8_MULTIENTRY
+	select SUPPORT_SPL
 	help
 	  Support for Freescale LS2085AQDS platform
 	  The LS2085A Development System (QDS) is a high-performance
arch/arm/cpu/armv8/fsl-lsch3/soc.c +48 -0

64 lines not on this page · raw message

arch/arm/cpu/armv8/u-boot-spl.lds renamed from arch/arm/cpu/armv8/u-boot.lds +31 -43

111 lines not on this page · raw message

arch/arm/include/asm/arch-fsl-lsch3/config.h +9 -0
index 403b2ef..77c20ab 100644
@@ -130,6 +130,15 @@
 #define CCI_MN_DVM_DOMAIN_CTL		0x200
 #define CCI_MN_DVM_DOMAIN_CTL_SET	0x210
 
+/* Device Configuration */
+#define DCFG_BASE		0x01e00000
+#define DCFG_PORSR1			0x000
+#define DCFG_PORSR1_RCW_SRC		0xff800000
+#define DCFG_PORSR1_RCW_SRC_NOR		0x12f00000
+
+#define DCFG_DCSR_BASE		0X700100000ULL
+#define DCFG_DCSR_PORCR1		0x000
+
 /* Supplemental Configuration */
 #define SCFG_BASE		0x01fc0000
 #define SCFG_USB3PRM1CR			0x000
arch/arm/lib/crt0_64.S +7 -0
index 7756396..bf4ca99 100644
@@ -61,13 +61,18 @@ ENTRY(_main)
 /*
  * Set up initial C runtime environment and call board_init_f(0).
  */
+#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_SPL_STACK)
+	ldr	x0, =(CONFIG_SPL_STACK)
+#else
 	ldr	x0, =(CONFIG_SYS_INIT_SP_ADDR)
+#endif
 	sub	x0, x0, #GD_SIZE	/* allocate one GD above SP */
 	bic	sp, x0, #0xf	/* 16-byte alignment for ABI compliance */
 	mov	x18, sp			/* GD is above SP */
 	mov	x0, #0
 	bl	board_init_f
 
+#if !defined(CONFIG_SPL_BUILD)
 /*
  * Set up intermediate environment (new sp and gd) and call
  * relocate_code(addr_moni). Trick here is that we'll return
@@ -110,4 +115,6 @@ clear_loop:
 
 	/* NOTREACHED - board_init_r() does not return */
 
+#endif /* !CONFIG_SPL_BUILD */
+
 ENDPROC(_main)
board/freescale/ls2085aqds/ddr.c +4 -0
index 6cd5e8b..8d71ae1 100644
@@ -147,9 +147,13 @@ phys_size_t initdram(int board_type)
 {
 	phys_size_t dram_size;
 
+#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD)
+	return fsl_ddr_sdram_size();
+#else
 	puts("Initializing DDR....using SPD\n");
 
 	dram_size = fsl_ddr_sdram();
+#endif
 
 	return dram_size;
 }
common/spl/spl.c +1 -1
index cd75bbc..6d5cb0e 100644
@@ -113,7 +113,7 @@ __weak void __noreturn jump_to_image_no_args(struct spl_image_info *spl_image)
 	typedef void __noreturn (*image_entry_noargs_t)(void);
 
 	image_entry_noargs_t image_entry =
-			(image_entry_noargs_t) spl_image->entry_point;
+		(image_entry_noargs_t)(unsigned long)spl_image->entry_point;
 
 	debug("image entry point: 0x%X\n", spl_image->entry_point);
 	image_entry();
common/spl/spl_nand.c +1 -1
index b7801cb..b8c369d 100644
@@ -91,7 +91,7 @@ void spl_nand_load_image(void)
 		sizeof(*header), (void *)header);
 	spl_parse_image_header(header);
 	nand_spl_load_image(CONFIG_SYS_NAND_U_BOOT_OFFS,
-		spl_image.size, (void *)spl_image.load_addr);
+		spl_image.size, (void *)(unsigned long)spl_image.load_addr);
 	nand_deselect();
 }
 #endif
configs/ls2085aqds_nand_defconfig new file +4 -0
new file mode 100644
index 0000000..446206a
@@ -0,0 +1,4 @@
+CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,NAND"
+CONFIG_SPL=y
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_LS2085AQDS=y
drivers/misc/fsl_ifc.c +12 -0
index 45d299c..a33efdb 100644
@@ -168,13 +168,25 @@ void init_final_memctl_regs(void)
 #ifdef CONFIG_SYS_CSPR0_FINAL
 	set_ifc_cspr(IFC_CS0, CONFIG_SYS_CSPR0_FINAL);
 #endif
+#ifdef CONFIG_SYS_AMASK0_FINAL
+	set_ifc_amask(IFC_CS0, CONFIG_SYS_AMASK0);
+#endif
 #ifdef CONFIG_SYS_CSPR1_FINAL
 	set_ifc_cspr(IFC_CS1, CONFIG_SYS_CSPR1_FINAL);
 #endif
 #ifdef CONFIG_SYS_AMASK1_FINAL
 	set_ifc_amask(IFC_CS1, CONFIG_SYS_AMASK1_FINAL);
 #endif
+#ifdef CONFIG_SYS_CSPR2_FINAL
+	set_ifc_cspr(IFC_CS2, CONFIG_SYS_CSPR2_FINAL);
+#endif
+#ifdef CONFIG_SYS_AMASK2_FINAL
+	set_ifc_amask(IFC_CS2, CONFIG_SYS_AMASK2);
+#endif
 #ifdef CONFIG_SYS_CSPR3_FINAL
 	set_ifc_cspr(IFC_CS3, CONFIG_SYS_CSPR3_FINAL);
 #endif
+#ifdef CONFIG_SYS_AMASK3_FINAL
+	set_ifc_amask(IFC_CS3, CONFIG_SYS_AMASK3);
+#endif
 }
drivers/mtd/nand/fsl_ifc_spl.c +1 -1
index 2fb9fb1..fccbfb5 100644
@@ -66,7 +66,7 @@ static inline void nand_wait(uchar *buf, int bufnum, int page_size)
 {
 	struct fsl_ifc_runtime *ifc = runtime_regs_address();
 	u32 status;
-	u32 eccstat[4];
+	u32 eccstat[8];
 	int bufperpage = page_size / 512;
 	int bufnum_end, i;
 
include/configs/ls2085a_common.h +29 -0
index 3fee92a..febf4da 100644
@@ -28,7 +28,11 @@
 #define CONFIG_ARCH_MISC_INIT
 
 /* Link Definitions */
+#ifdef CONFIG_SPL
+#define CONFIG_SYS_TEXT_BASE		0x80400000
+#else
 #define CONFIG_SYS_TEXT_BASE		0x30100000
+#endif
 
 #ifdef CONFIG_EMU
 #define CONFIG_SYS_NO_FLASH
@@ -47,7 +51,9 @@
 #define CONFIG_FIT
 #define CONFIG_FIT_VERBOSE	/* enable fit_format_{error,warning}() */
 
+#ifndef CONFIG_SPL
 #define CONFIG_FSL_DDR_INTERACTIVE	/* Interactive debugging */
+#endif
 #ifndef CONFIG_SYS_FSL_DDR4
 #define CONFIG_SYS_FSL_DDR3		/* Use DDR3 memory */
 #define CONFIG_SYS_DDR_RAW_TIMING
@@ -270,4 +276,27 @@ unsigned long get_dram_size_to_hide(void);
 
 #define CONFIG_PANIC_HANG	/* do not reset board on panic */
 
+#define CONFIG_SPL_BSS_START_ADDR	0x80100000
+#define CONFIG_SPL_BSS_MAX_SIZE		0x00100000
+#define CONFIG_SPL_DRIVERS_MISC_SUPPORT
+#define CONFIG_SPL_ENV_SUPPORT
+#define CONFIG_SPL_FRAMEWORK
+#define CONFIG_SPL_I2C_SUPPORT
+#define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv8/u-boot-spl.lds"
+#define CONFIG_SPL_LIBCOMMON_SUPPORT
+#define CONFIG_SPL_LIBGENERIC_SUPPORT
+#define CONFIG_SPL_MAX_SIZE		0x16000
+#define CONFIG_SPL_MPC8XXX_INIT_DDR_SUPPORT
+#define CONFIG_SPL_NAND_SUPPORT
+#define CONFIG_SPL_SERIAL_SUPPORT
+#define CONFIG_SPL_STACK		(CONFIG_SYS_FSL_OCRAM_BASE + 0x9ff0)
+#define CONFIG_SPL_TARGET		"u-boot-with-spl.bin"
+#define CONFIG_SPL_TEXT_BASE		0x1800a000
+
+#define CONFIG_SYS_NAND_U_BOOT_DST	0x80400000
+#define CONFIG_SYS_NAND_U_BOOT_START	CONFIG_SYS_NAND_U_BOOT_DST
+#define CONFIG_SYS_SPL_MALLOC_SIZE	0x00100000
+#define CONFIG_SYS_SPL_MALLOC_START	0x80200000
+#define CONFIG_SYS_MONITOR_LEN		(512 * 1024)
+
 #endif /* __LS2_COMMON_H */
include/configs/ls2085aqds.h +45 -5

78 lines not on this page · raw message

Signature · 1 line
1.7.9.5
author
#64 lore raw

PATCH 25/28 freescale/qixis: Add support for booting from NAND

In reply to York Sun

From: Scott Wood <[email protected]>

Use "qixis_reset nand" to reset the board to boot from NAND.

---
 board/freescale/common/qixis.c |   31 +++++++++++++++++++++----------
 1 file changed, 21 insertions(+), 10 deletions(-)
board/freescale/common/qixis.c +21 -10
index a49e300..9f6b0e7 100644
@@ -138,24 +138,23 @@ void qixis_bank_reset(void)
 	QIXIS_WRITE(rcfg_ctl, QIXIS_RCFG_CTL_RECONFIG_START);
 }
 
-/* Set the boot bank to the power-on default bank */
-void clear_altbank(void)
+static void __maybe_unused set_lbmap(int lbmap)
 {
 	u8 reg;
 
 	reg = QIXIS_READ(brdcfg[0]);
-	reg = (reg & ~QIXIS_LBMAP_MASK) | QIXIS_LBMAP_DFLTBANK;
+	reg = (reg & ~QIXIS_LBMAP_MASK) | lbmap;
 	QIXIS_WRITE(brdcfg[0], reg);
 }
 
-/* Set the boot bank to the alternate bank */
-void set_altbank(void)
+static void __maybe_unused set_rcw_src(int rcw_src)
 {
 	u8 reg;
 
-	reg = QIXIS_READ(brdcfg[0]);
-	reg = (reg & ~QIXIS_LBMAP_MASK) | QIXIS_LBMAP_ALTBANK;
-	QIXIS_WRITE(brdcfg[0], reg);
+	reg = QIXIS_READ(dutcfg[1]);
+	reg = (reg & ~1) | (rcw_src & 1);
+	QIXIS_WRITE(dutcfg[1], reg);
+	QIXIS_WRITE(dutcfg[0], (rcw_src >> 1) & 0xff);
 }
 
 static void qixis_dump_regs(void)
@@ -201,11 +200,22 @@ int qixis_reset_cmd(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[])
 	int i;
 
 	if (argc <= 1) {
-		clear_altbank();
+		set_lbmap(QIXIS_LBMAP_DFLTBANK);
 		qixis_reset();
 	} else if (strcmp(argv[1], "altbank") == 0) {
-		set_altbank();
+		set_lbmap(QIXIS_LBMAP_ALTBANK);
 		qixis_bank_reset();
+	} else if (strcmp(argv[1], "nand") == 0) {
+#ifdef QIXIS_LBMAP_NAND
+		QIXIS_WRITE(rst_ctl, 0x30);
+		QIXIS_WRITE(rcfg_ctl, 0);
+		set_lbmap(QIXIS_LBMAP_NAND);
+		set_rcw_src(QIXIS_RCW_SRC_NAND);
+		QIXIS_WRITE(rcfg_ctl, 0x20);
+		QIXIS_WRITE(rcfg_ctl, 0x21);
+#else
+		printf("Not implemented\n");
+#endif
 	} else if (strcmp(argv[1], "watchdog") == 0) {
 		static char *period[9] = {"2s", "4s", "8s", "16s", "32s",
 					  "1min", "2min", "4min", "8min"};
@@ -244,6 +254,7 @@ U_BOOT_CMD(
 	"Reset the board using the FPGA sequencer",
 	"- hard reset to default bank\n"
 	"qixis_reset altbank - reset to alternate bank\n"
+	"qixis_reset nand - reset to nand\n"
 	"qixis watchdog <watchdog_period> - set the watchdog period\n"
 	"	period: 1s 2s 4s 8s 16s 32s 1min 2min 4min 8min\n"
 	"qixis_reset dump - display the QIXIS registers\n"
Signature · 1 line
1.7.9.5
author
#65 lore raw

PATCH 26/28 armv8/ls2085ardb: Enable NAND SPL support

In reply to York Sun

From: Scott Wood <[email protected]>

Enable NAND boot support using SPL framework. To boot from NAND, either use DIP switches on board, or "qixis_reset nand" command.

---
 arch/arm/Kconfig                  |    1 +
 board/freescale/ls2085ardb/ddr.c  |    4 ++++
 configs/ls2085ardb_nand_defconfig |    4 ++++
 include/configs/ls2085ardb.h      |   40 ++++++++++++++++++++++++++++++++-----
 4 files changed, 44 insertions(+), 5 deletions(-)
 create mode 100644 configs/ls2085ardb_nand_defconfig
arch/arm/Kconfig +1 -0
index 46a48a0..7cbbf37 100644
@@ -663,6 +663,7 @@ config TARGET_LS2085ARDB
 	bool "Support ls2085ardb"
 	select ARM64
 	select ARMV8_MULTIENTRY
+	select SUPPORT_SPL
 	help
 	  Support for Freescale LS2085ARDB platform.
 	  The LS2080A Reference design board (RDB) is a high-performance
board/freescale/ls2085ardb/ddr.c +4 -0
index 6cd5e8b..8d71ae1 100644
@@ -147,9 +147,13 @@ phys_size_t initdram(int board_type)
 {
 	phys_size_t dram_size;
 
+#if defined(CONFIG_SPL) && !defined(CONFIG_SPL_BUILD)
+	return fsl_ddr_sdram_size();
+#else
 	puts("Initializing DDR....using SPD\n");
 
 	dram_size = fsl_ddr_sdram();
+#endif
 
 	return dram_size;
 }
configs/ls2085ardb_nand_defconfig new file +4 -0
new file mode 100644
index 0000000..39ba8c5
@@ -0,0 +1,4 @@
++S:CONFIG_SYS_EXTRA_OPTIONS="SYS_FSL_DDR4,NAND"
++S:CONFIG_SPL=y
++S:CONFIG_ARM=y
++S:CONFIG_TARGET_LS2085ARDB=y
include/configs/ls2085ardb.h +35 -5
index 24400e4..34aa3e5 100644
@@ -139,11 +139,13 @@ unsigned long get_board_sys_clk(void);
 #define QIXIS_LBMAP_SHIFT		0
 #define QIXIS_LBMAP_DFLTBANK		0x00
 #define QIXIS_LBMAP_ALTBANK		0x04
+#define QIXIS_LBMAP_NAND		0x09
 #define QIXIS_RST_CTL_RESET		0x31
 #define QIXIS_RST_CTL_RESET_EN		0x30
 #define QIXIS_RCFG_CTL_RECONFIG_IDLE	0x20
 #define QIXIS_RCFG_CTL_RECONFIG_START	0x21
 #define QIXIS_RCFG_CTL_WATCHDOG_ENBLE	0x08
+#define QIXIS_RCW_SRC_NAND		0x119
 #define	QIXIS_RST_FORCE_MEM		0x01
 
 #define CONFIG_SYS_CSPR3_EXT	(0x0)
@@ -169,6 +171,33 @@ unsigned long get_board_sys_clk(void);
 					FTIM2_GPCM_TWP(0x3E))
 #define CONFIG_SYS_CS3_FTIM3		0x0
 
+#if defined(CONFIG_SPL) && defined(CONFIG_NAND)
+#define CONFIG_SYS_CSPR2_EXT		CONFIG_SYS_NOR0_CSPR_EXT
+#define CONFIG_SYS_CSPR2		CONFIG_SYS_NOR0_CSPR_EARLY
+#define CONFIG_SYS_CSPR2_FINAL		CONFIG_SYS_NOR0_CSPR
+#define CONFIG_SYS_AMASK2		CONFIG_SYS_NOR_AMASK
+#define CONFIG_SYS_CSOR2		CONFIG_SYS_NOR_CSOR
+#define CONFIG_SYS_CS2_FTIM0		CONFIG_SYS_NOR_FTIM0
+#define CONFIG_SYS_CS2_FTIM1		CONFIG_SYS_NOR_FTIM1
+#define CONFIG_SYS_CS2_FTIM2		CONFIG_SYS_NOR_FTIM2
+#define CONFIG_SYS_CS2_FTIM3		CONFIG_SYS_NOR_FTIM3
+#define CONFIG_SYS_CSPR0_EXT		CONFIG_SYS_NAND_CSPR_EXT
+#define CONFIG_SYS_CSPR0		CONFIG_SYS_NAND_CSPR
+#define CONFIG_SYS_AMASK0		CONFIG_SYS_NAND_AMASK
+#define CONFIG_SYS_CSOR0		CONFIG_SYS_NAND_CSOR
+#define CONFIG_SYS_CS0_FTIM0		CONFIG_SYS_NAND_FTIM0
+#define CONFIG_SYS_CS0_FTIM1		CONFIG_SYS_NAND_FTIM1
+#define CONFIG_SYS_CS0_FTIM2		CONFIG_SYS_NAND_FTIM2
+#define CONFIG_SYS_CS0_FTIM3		CONFIG_SYS_NAND_FTIM3
+
+#define CONFIG_ENV_IS_IN_NAND
+#define CONFIG_ENV_OFFSET		(1536 * 1024)
+#define CONFIG_ENV_SECT_SIZE		0x20000
+#define CONFIG_ENV_SIZE			0x2000
+#define CONFIG_SPL_PAD_TO		0x7ff40
+#define CONFIG_SYS_NAND_U_BOOT_OFFS	(512 * 1024)
+#define CONFIG_SYS_NAND_U_BOOT_SIZE	(512 * 1024)
+#else
 #define CONFIG_SYS_CSPR0_EXT		CONFIG_SYS_NOR0_CSPR_EXT
 #define CONFIG_SYS_CSPR0		CONFIG_SYS_NOR0_CSPR_EARLY
 #define CONFIG_SYS_CSPR0_FINAL		CONFIG_SYS_NOR0_CSPR
@@ -187,6 +216,12 @@ unsigned long get_board_sys_clk(void);
 #define CONFIG_SYS_CS2_FTIM2		CONFIG_SYS_NAND_FTIM2
 #define CONFIG_SYS_CS2_FTIM3		CONFIG_SYS_NAND_FTIM3
 
+#define CONFIG_ENV_IS_IN_FLASH
+#define CONFIG_ENV_ADDR			(CONFIG_SYS_FLASH_BASE + 0x200000)
+#define CONFIG_ENV_SECT_SIZE		0x20000
+#define CONFIG_ENV_SIZE			0x2000
+#endif
+
 /* Debug Server firmware */
 #define CONFIG_SYS_DEBUG_SERVER_FW_IN_NOR
 #define CONFIG_SYS_DEBUG_SERVER_FW_ADDR	0x580D00000ULL
@@ -232,11 +267,6 @@ unsigned long get_board_sys_clk(void);
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_BITS 3
 #define CONFIG_SYS_EEPROM_PAGE_WRITE_DELAY_MS 5
 
-#define CONFIG_ENV_IS_IN_FLASH
-#define CONFIG_ENV_ADDR			(CONFIG_SYS_FLASH_BASE + 0x200000)
-#define CONFIG_ENV_SECT_SIZE		0x20000
-#define CONFIG_ENV_SIZE			0x2000
-
 #define CONFIG_FSL_MEMAC
 #define CONFIG_PCI		/* Enable PCIE */
 #define CONFIG_PCIE_LAYERSCAPE	/* Use common FSL Layerscape PCIe code */
Signature · 1 line
1.7.9.5
author
#66 lore raw

PATCH 27/28 ls2085a: esdhc: Add esdhc support for ls2085a

In reply to York Sun

From: Yangbo Lu <[email protected]>

This patch adds esdhc support for ls2085a.

---
 arch/arm/cpu/armv8/fsl-lsch3/cpu.c           |   10 +++++++
 arch/arm/cpu/armv8/fsl-lsch3/fdt.c           |    7 +++++
 arch/arm/include/asm/arch-fsl-lsch3/config.h |    2 ++
 drivers/mmc/fsl_esdhc.c                      |   36 ++++++++++++++++++++++++--
 include/configs/ls2085a_common.h             |    5 ++--
 include/configs/ls2085aqds.h                 |   19 +++++++++++++-
 include/configs/ls2085ardb.h                 |   11 +++++++-
 include/fsl_esdhc.h                          |    4 +++
 8 files changed, 88 insertions(+), 6 deletions(-)
arch/arm/cpu/armv8/fsl-lsch3/cpu.c +10 -0
index 22b5fb2..e738c49 100644
@@ -13,6 +13,9 @@
 #include <fsl_debug_server.h>
 #include <fsl-mc/fsl_mc.h>
 #include <asm/arch/fsl_serdes.h>
+#ifdef CONFIG_FSL_ESDHC
+#include <fsl_esdhc.h>
+#endif
 #include "cpu.h"
 #include "mp.h"
 #include "speed.h"
@@ -416,6 +419,13 @@ int print_cpuinfo(void)
 }
 #endif
 
+#ifdef CONFIG_FSL_ESDHC
+int cpu_mmc_init(bd_t *bis)
+{
+	return fsl_esdhc_mmc_init(bis);
+}
+#endif
+
 int cpu_eth_init(bd_t *bis)
 {
 	int error = 0;
arch/arm/cpu/armv8/fsl-lsch3/fdt.c +7 -0
index 42c5b58..d370023 100644
@@ -7,6 +7,9 @@
 #include <common.h>
 #include <libfdt.h>
 #include <fdt_support.h>
+#ifdef CONFIG_FSL_ESDHC
+#include <fsl_esdhc.h>
+#endif
 #include "mp.h"
 
 #ifdef CONFIG_MP
@@ -65,4 +68,8 @@ void ft_cpu_setup(void *blob, bd_t *bd)
 	do_fixup_by_compat_u32(blob, "fsl,ns16550",
 			       "clock-frequency", CONFIG_SYS_NS16550_CLK, 1);
 #endif
+
+#if defined(CONFIG_FSL_ESDHC)
+	fdt_fixup_esdhc(blob, bd);
+#endif
 }
arch/arm/include/asm/arch-fsl-lsch3/config.h +2 -0
index 77c20ab..ca8d38c 100644
@@ -31,6 +31,7 @@
 #define CONFIG_SYS_FSL_CH3_CLK_GRPA_ADDR	(CONFIG_SYS_IMMR + 0x00300000)
 #define CONFIG_SYS_FSL_CH3_CLK_GRPB_ADDR	(CONFIG_SYS_IMMR + 0x00310000)
 #define CONFIG_SYS_FSL_CH3_CLK_CTRL_ADDR	(CONFIG_SYS_IMMR + 0x00370000)
+#define CONFIG_SYS_FSL_ESDHC_ADDR		(CONFIG_SYS_IMMR + 0x01140000)
 #define CONFIG_SYS_IFC_ADDR			(CONFIG_SYS_IMMR + 0x01240000)
 #define CONFIG_SYS_NS16550_COM1			(CONFIG_SYS_IMMR + 0x011C0500)
 #define CONFIG_SYS_NS16550_COM2			(CONFIG_SYS_IMMR + 0x011C0600)
@@ -110,6 +111,7 @@
 #define CONFIG_MAX_MEM_MAPPED		CONFIG_SYS_LS2_DDR_BLOCK1_SIZE
 #define CONFIG_SYS_FSL_DDR_VER		FSL_DDR_VER_5_0
 
+#define CONFIG_SYS_FSL_ESDHC_LE
 /* IFC */
 #define CONFIG_SYS_FSL_IFC_LE
 #define CONFIG_SYS_MEMAC_LITTLE_ENDIAN
drivers/mmc/fsl_esdhc.c +34 -2
index c5e270d..7528b9d 100644
@@ -105,7 +105,8 @@ static uint esdhc_xfertyp(struct mmc_cmd *cmd, struct mmc_data *data)
 	else if (cmd->resp_type & MMC_RSP_PRESENT)
 		xfertyp |= XFERTYP_RSPTYP_48;
 
-#if defined(CONFIG_MX53) || defined(CONFIG_PPC_T4240) || defined(CONFIG_LS102XA)
+#if defined(CONFIG_MX53) || defined(CONFIG_PPC_T4240) || \
+	defined(CONFIG_LS102XA) || defined(CONFIG_LS2085A)
 	if (cmd->cmdidx == MMC_CMD_STOP_TRANSMISSION)
 		xfertyp |= XFERTYP_CMDTYP_ABORT;
 #endif
@@ -183,7 +184,9 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data)
 	int timeout;
 	struct fsl_esdhc_cfg *cfg = mmc->priv;
 	struct fsl_esdhc *regs = (struct fsl_esdhc *)cfg->esdhc_base;
-
+#ifdef CONFIG_LS2085A
+	dma_addr_t addr;
+#endif
 	uint wml_value;
 
 	wml_value = data->blocksize/4;
@@ -194,8 +197,16 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data)
 
 		esdhc_clrsetbits32(&regs->wml, WML_RD_WML_MASK, wml_value);
 #ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
+#ifdef CONFIG_LS2085A
+		addr = virt_to_phys((void *)(data->dest));
+		if (upper_32_bits(addr))
+			printf("Error found for upper 32 bits\n");
+		else
+			esdhc_write32(&regs->dsaddr, lower_32_bits(addr));
+#else
 		esdhc_write32(&regs->dsaddr, (u32)data->dest);
 #endif
+#endif
 	} else {
 #ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
 		flush_dcache_range((ulong)data->src,
@@ -212,8 +223,16 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data)
 		esdhc_clrsetbits32(&regs->wml, WML_WR_WML_MASK,
 					wml_value << 16);
 #ifndef CONFIG_SYS_FSL_ESDHC_USE_PIO
+#ifdef CONFIG_LS2085A
+		addr = virt_to_phys((void *)(data->src));
+		if (upper_32_bits(addr))
+			printf("Error found for upper 32 bits\n");
+		else
+			esdhc_write32(&regs->dsaddr, lower_32_bits(addr));
+#else
 		esdhc_write32(&regs->dsaddr, (u32)data->src);
 #endif
+#endif
 	}
 
 	esdhc_write32(&regs->blkattr, data->blocks << 16 | data->blocksize);
@@ -259,10 +278,23 @@ static int esdhc_setup_data(struct mmc *mmc, struct mmc_data *data)
 static void check_and_invalidate_dcache_range
 	(struct mmc_cmd *cmd,
 	 struct mmc_data *data) {
+#ifdef CONFIG_LS2085A
+	unsigned start = 0;
+#else
 	unsigned start = (unsigned)data->dest ;
+#endif
 	unsigned size = roundup(ARCH_DMA_MINALIGN,
 				data->blocks*data->blocksize);
 	unsigned end = start+size ;
+#ifdef CONFIG_LS2085A
+	dma_addr_t addr;
+
+	addr = virt_to_phys((void *)(data->dest));
+	if (upper_32_bits(addr))
+		printf("Error found for upper 32 bits\n");
+	else
+		start = lower_32_bits(addr);
+#endif
 	invalidate_dcache_range(start, end);
 }
 #endif
include/configs/ls2085a_common.h +3 -2
index febf4da..01ae2ef 100644
@@ -153,6 +153,9 @@ unsigned long long get_qixis_addr(void);
 #define QIXIS_BASE				get_qixis_addr()
 #define QIXIS_BASE_PHYS				0x20000000
 #define QIXIS_BASE_PHYS_EARLY			0xC000000
+#define QIXIS_STAT_PRES1			0xb
+#define QIXIS_SDID_MASK				0x07
+#define QIXIS_ESDHC_NO_ADAPTER			0x7
 
 #define CONFIG_SYS_NAND_BASE			0x530000000ULL
 #define CONFIG_SYS_NAND_BASE_PHYS		0x30000000
@@ -217,8 +220,6 @@ unsigned long long get_qixis_addr(void);
 #define CONFIG_CMD_BOOTD
 #define CONFIG_CMD_ECHO
 #define CONFIG_CMD_SOURCE
-#define CONFIG_CMD_FAT
-#define CONFIG_DOS_PARTITION
 
 /* Miscellaneous configurable options */
 #define CONFIG_SYS_LOAD_ADDR	(CONFIG_SYS_DDR_SDRAM_BASE + 0x10000000)
include/configs/ls2085aqds.h +18 -1
index 0203276..d11568c 100644
@@ -278,6 +278,14 @@ unsigned long get_board_ddr_clk(void);
 #define I2C_MUX_CH_DEFAULT      0x8
 
 /*
+ * MMC
+ */
+#ifdef CONFIG_MMC
+#define CONFIG_ESDHC_DETECT_QUIRK ((readb(QIXIS_BASE + QIXIS_STAT_PRES1) & \
+	QIXIS_SDID_MASK) != QIXIS_ESDHC_NO_ADAPTER)
+#endif
+
+/*
  * RTC configuration
  */
 #define RTC
@@ -307,7 +315,16 @@ unsigned long get_board_ddr_clk(void);
 #define CONFIG_CMD_NET
 #endif
 
-
+/*  MMC  */
+#define CONFIG_MMC
+#ifdef CONFIG_MMC
+#define CONFIG_CMD_MMC
+#define CONFIG_FSL_ESDHC
+#define CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33
+#define CONFIG_GENERIC_MMC
+#define CONFIG_CMD_FAT
+#define CONFIG_DOS_PARTITION
+#endif
 
 /* Initial environment variables */
 #undef CONFIG_EXTRA_ENV_SETTINGS
include/configs/ls2085ardb.h +10 -1
index 34aa3e5..af3052e 100644
@@ -280,7 +280,16 @@ unsigned long get_board_sys_clk(void);
 #define CONFIG_CMD_NET
 #endif
 
-
+/*  MMC  */
+#define CONFIG_MMC
+#ifdef CONFIG_MMC
+#define CONFIG_CMD_MMC
+#define CONFIG_FSL_ESDHC
+#define CONFIG_SYS_FSL_MMC_HAS_CAPBLT_VS33
+#define CONFIG_GENERIC_MMC
+#define CONFIG_CMD_FAT
+#define CONFIG_DOS_PARTITION
+#endif
 
 /* Initial environment variables */
 #undef CONFIG_EXTRA_ENV_SETTINGS
include/fsl_esdhc.h +4 -0
index 57295b4..41bf05b 100644
@@ -158,7 +158,11 @@
 #define ESDHC_VENDORSPEC_VSELECT 0x00000002 /* Use 1.8V */
 
 struct fsl_esdhc_cfg {
+#ifdef CONFIG_LS2085A
+	u64	esdhc_base;
+#else
 	u32	esdhc_base;
+#endif
 	u32	sdhc_clk;
 	u8	max_bus_width;
 	struct mmc_config cfg;
Signature · 1 line
1.7.9.5
author
#67 lore raw

PATCH 28/28 armv8/fsl-lsch3: Implement workaround for I2C issue

In reply to York Sun

This erratum requires setting GLITCH_EN bit in debug register.

---
 arch/arm/cpu/armv8/fsl-lsch3/soc.c |   30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)
arch/arm/cpu/armv8/fsl-lsch3/soc.c +30 -0
index ca00108..4d9df20 100644
@@ -37,11 +37,41 @@ static void erratum_rcw_src(void)
 #endif
 }
 
+#define I2C_DEBUG_REG 0x6
+#define I2C_GLITCH_EN 0x8
+static void erratum_i2c(void)
+{
+	u8 __iomem *ptr;
+#ifdef CONFIG_SYS_I2C
+#ifdef I2C1_BASE_ADDR
+	ptr = (u8 __iomem *)(I2C1_BASE_ADDR + I2C_DEBUG_REG);
+
+	writeb(I2C_GLITCH_EN, ptr);
+#endif
+#ifdef I2C2_BASE_ADDR
+	ptr = (u8 __iomem *)(I2C2_BASE_ADDR + I2C_DEBUG_REG);
+
+	writeb(I2C_GLITCH_EN, ptr);
+#endif
+#ifdef I2C3_BASE_ADDR
+	ptr = (u8 __iomem *)(I2C3_BASE_ADDR + I2C_DEBUG_REG);
+
+	writeb(I2C_GLITCH_EN, ptr);
+#endif
+#ifdef I2C4_BASE_ADDR
+	ptr = (u8 __iomem *)(I2C4_BASE_ADDR + I2C_DEBUG_REG);
+
+	writeb(I2C_GLITCH_EN, ptr);
+#endif
+#endif
+}
+
 void fsl_lsch3_early_init_f(void)
 {
 	erratum_a008751();
 	erratum_rcw_src();
 	init_early_memctl_regs();	/* tighten IFC timing */
+	erratum_i2c();
 }
 
 #ifdef CONFIG_SPL_BUILD
Signature · 1 line
1.7.9.5
#68 lore raw

PATCH 28/28 armv8/fsl-lsch3: Implement workaround for I2C issue

Hello York,

Am 19.03.2015 17:45, schrieb York Sun:

Quoted 12 lines

This erratum requires setting GLITCH_EN bit in debug register.

---
  arch/arm/cpu/armv8/fsl-lsch3/soc.c |   30 ++++++++++++++++++++++++++++++
  1 file changed, 30 insertions(+)
arch/arm/cpu/armv8/fsl-lsch3/soc.c +0 -0
index ca00108..4d9df20 100644

arch/arm/cpu/armv8/fsl-lsch3/soc.c static void erratum_rcw_src(void) · line 42

Quoted 6 lines
arch/arm/cpu/armv8/fsl-lsch3/soc.c +3 -0
@@ -37,11 +37,41 @@ static void erratum_rcw_src(void)
  #endif
  }
 
+#define I2C_DEBUG_REG 0x6
+#define I2C_GLITCH_EN 0x8
+static void erratum_i2c(void)

Could you add here a short comment, where to find some info about this erratum? Thanks!

arch/arm/cpu/armv8/fsl-lsch3/soc.c static void erratum_rcw_src(void) · line 47

Quoted 5 lines
arch/arm/cpu/armv8/fsl-lsch3/soc.c +5 -0
+{
+	u8 __iomem *ptr;
+#ifdef CONFIG_SYS_I2C
+#ifdef I2C1_BASE_ADDR
+	ptr = (u8 __iomem *)(I2C1_BASE_ADDR + I2C_DEBUG_REG);

using a struct here would be nicer ...

bye,
Heiko

Quoted 31 lines
arch/arm/cpu/armv8/fsl-lsch3/soc.c +22 -0
+
+	writeb(I2C_GLITCH_EN, ptr);
+#endif
+#ifdef I2C2_BASE_ADDR
+	ptr = (u8 __iomem *)(I2C2_BASE_ADDR + I2C_DEBUG_REG);
+
+	writeb(I2C_GLITCH_EN, ptr);
+#endif
+#ifdef I2C3_BASE_ADDR
+	ptr = (u8 __iomem *)(I2C3_BASE_ADDR + I2C_DEBUG_REG);
+
+	writeb(I2C_GLITCH_EN, ptr);
+#endif
+#ifdef I2C4_BASE_ADDR
+	ptr = (u8 __iomem *)(I2C4_BASE_ADDR + I2C_DEBUG_REG);
+
+	writeb(I2C_GLITCH_EN, ptr);
+#endif
+#endif
+}
+
  void fsl_lsch3_early_init_f(void)
  {
  	erratum_a008751();
  	erratum_rcw_src();
  	init_early_memctl_regs();	/* tighten IFC timing */
+	erratum_i2c();
  }
 
  #ifdef CONFIG_SPL_BUILD
Signature · 2 lines
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
author
#69 lore raw

PATCH 28/28 armv8/fsl-lsch3: Implement workaround for I2C issue

Quoted 18 lines · Heiko Schocher

Hello York,

Am 19.03.2015 17:45, schrieb York Sun:

Quoted 15 lines

This erratum requires setting GLITCH_EN bit in debug register.

---
  arch/arm/cpu/armv8/fsl-lsch3/soc.c |   30 ++++++++++++++++++++++++++++++
  1 file changed, 30 insertions(+)
arch/arm/cpu/armv8/fsl-lsch3/soc.c +0 -0
index ca00108..4d9df20 100644
@@ -37,11 +37,41 @@ static void erratum_rcw_src(void)
  #endif
  }
 
Quoted 6 lines

arch/arm/cpu/armv8/fsl-lsch3/soc.c static void erratum_rcw_src(void) · line 42

Quoted 3 lines
arch/arm/cpu/armv8/fsl-lsch3/soc.c +3 -0
+#define I2C_DEBUG_REG 0x6
+#define I2C_GLITCH_EN 0x8
+static void erratum_i2c(void)

Could you add here a short comment, where to find some info about this erratum? Thanks!

Sure I can add some comment. I am still waiting for design team to finalize the document so users can access. The purpose of posting this patch now is to help users to overcome this issue as boards are being shipped out.

Quoted 9 lines

arch/arm/cpu/armv8/fsl-lsch3/soc.c static void erratum_rcw_src(void) · line 47

Quoted 6 lines
arch/arm/cpu/armv8/fsl-lsch3/soc.c +5 -0
+{
+	u8 __iomem *ptr;
+#ifdef CONFIG_SYS_I2C
+#ifdef I2C1_BASE_ADDR
+	ptr = (u8 __iomem *)(I2C1_BASE_ADDR + I2C_DEBUG_REG);

using a struct here would be nicer ...

I agree it would look better. But my concern is this debug register is new and only exists on this SoC. Since I am reusing the driver, I am reluctant to add this register for the purpose of the workaround.

York