armv8/fsl-lsch3: Implement workaround for erratum A008585
Subsystems (9)
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
@@ -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 (); asmvolatile ("mrs %0, cntpct_el0" :"=r" (cntpct)); +#ifdef CONFIG_SYS_FSL_ERRATUM_A008585 + asmvolatile ("mrs %0, cntpct_el0" :"=r" (temp)); +while (temp != cntpct) { + asmvolatile ("mrs %0, cntpct_el0" :"=r" (cntpct)); + asmvolatile ("mrs %0, cntpct_el0" :"=r" (temp)); + } +#endif return cntpct; }
arch/arm/include/asm/arch-fsl-lsch3/config.h +1 -0
@@ -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
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
@@ -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
PATCH 3/28 armv8/fsl-lsch3: Fix platform clock calculation
In reply to York SunPlatform 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
@@ -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
PATCH 4/28 armv8/ls2085a: Fix generic timer clock source
In reply to York SunThe 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
@@ -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
@@ -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 */ + asmvolatile ("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
@@ -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
@@ -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
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.
Signed-off-by York Sun <[email protected]>--- 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@@ -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@@ -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 */ + asmvolatile ("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.
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 */ + asmvolatile ("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
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 */ + asmvolatile ("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.
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 */ + asmvolatile ("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_REALto 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
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 */ + asmvolatile ("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_REALto 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.
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 */ + asmvolatile ("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_REALto 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
PATCH 5/28 armv8/ls2085a: Add support for reset request
In reply to York SunFrom: 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
@@ -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
@@ -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
PATCH 6/28 armv8/fsl-lsch3: Set nodes in DVM domain
In reply to York SunFrom: 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
@@ -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
@@ -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
PATCH 7/28 armv8/fsl-lsch3: Update early MMU table
In reply to York SunDuring 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
@@ -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
@@ -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
PATCH 8/28 fsl-lsch3: Introduce place for common early SoC init
In reply to York SunFrom: 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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 9/28 armv8/ls2085a: Add workaround for USB erratum A-008751
In reply to York SunFrom: 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
@@ -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
@@ -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
PATCH 10/28 armv8/fsl-lsch3: Use correct compatible for serial clock fixup
In reply to York SunFrom: 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
@@ -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
PATCH 11/28 driver/ldpaa_eth: Update ldpaa ethernet driver
In reply to York SunFrom: 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
@@ -15,6 +15,7 @@#include "ldpaa_eth.h" +#undef CONFIG_PHYLIBstatic 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
PATCH 12/28 armv8: Add SerDes framework for LayerScape Architecture
In reply to York SunFrom: 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.harch/arm/cpu/armv8/fsl-lsch3/Makefile +1 -0
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 13/28 net/phy/cortina: Fix compilation warning
In reply to York SunFrom: 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
@@ -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
PATCH 13/28 net/phy/cortina: Fix compilation warning
Quoted 8 lines · York Sun
From: pankaj chauhan <[email protected]>
Fix comilation warning which is emitted when
firmware address is more than 32 bit.Signed-off-by pankaj chauhan <[email protected]>CC Joe Hershberger <[email protected]>
PATCH 14/28 drivers/fsl-mc: Changed MC firmware loading for new boot architecture
In reply to York SunFrom: "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
@@ -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
@@ -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
@@ -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
@@ -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
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
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 architectureQuoted 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
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 PMQuoted 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
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 architectureQuoted 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 PMQuoted 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
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 architectureQuoted 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 PMQuoted 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
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 architectureQuoted 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 architectureQuoted 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 PMQuoted 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
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 PMQuoted 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 PMQuoted 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 PMQuoted 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
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,
StuartQuoted 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 PMQuoted 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 PMQuoted 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 PMQuoted 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
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 architectureQuoted 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,
StuartQuoted 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 PMQuoted 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 PMQuoted 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 PMQuoted 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 isjust 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 allcommands?
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
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 PMQuoted 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
PATCH 15/28 net/memac_phy: reuse driver for little endian SoCs
In reply to York SunFrom: 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.
---
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
Signature · 1 line
1.7.9.5
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_ENDIANfor little endian SoCs, if theCONFIG_SYS_MEMAC_LITTLE_ENDIANis defined, the I/O access is little endian, if not, the I/O access is big endian. Movefsl_memac.hout of powerpc include.
Quoted 8 lines
Signed-off-by Shaohui Xie <[email protected]>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@@ -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
-0obj-$(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.odrivers/net/fm/eth.c +1
-1@@ -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@@ -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
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
-1if (dev_addr ==MDIO_DEVAD_NONE ) { c45 =0 ;/* clause 22 */ dev_addr = regnum &0x1f ; -clrbits_be32 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_clrbits_32 (®s->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 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_setbits_32 (®s->mdio_stat,MDIO_STAT_ENC );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->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 (®s->mdio_ctl, mdio_ctl); +memac_out_32 (®s->mdio_ctl, mdio_ctl);/* Set the register address */ if (c45) -out_be32 (®s->mdio_addr, regnum &0xffff ); +memac_out_32 (®s->mdio_addr, regnum &0xffff );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->mdio_stat)) &MDIO_STAT_BSY ) ;/* Write the value to the register */ -out_be32 (®s->mdio_data,MDIO_DATA (value)); +memac_out_32 (®s->mdio_data,MDIO_DATA (value));/* Wait till the MDIO write is complete */ -while ((in_be32 (®s->mdio_data)) &MDIO_DATA_BSY ) +while ((memac_in_32 (®s->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
-1return 0xffff ; c45 =0 ;/* clause 22 */ dev_addr = regnum &0x1f ; -clrbits_be32 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_clrbits_32 (®s->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 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_setbits_32 (®s->mdio_stat,MDIO_STAT_ENC );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->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 (®s->mdio_ctl, mdio_ctl); +memac_out_32 (®s->mdio_ctl, mdio_ctl);/* Set the register address */ if (c45) -out_be32 (®s->mdio_addr, regnum &0xffff ); +memac_out_32 (®s->mdio_addr, regnum &0xffff );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->mdio_stat)) &MDIO_STAT_BSY ) ;/* Initiate the read */ mdio_ctl |=MDIO_CTL_READ ; -out_be32 (®s->mdio_ctl, mdio_ctl); +memac_out_32 (®s->mdio_ctl, mdio_ctl);/* Wait till the MDIO write is complete */ -while ((in_be32 (®s->mdio_data)) &MDIO_DATA_BSY ) +while ((memac_in_32 (®s->mdio_data)) &MDIO_DATA_BSY ) ;/* Return all Fs if nothing was there */ -if (in_be32 (®s->mdio_stat) &MDIO_STAT_RD_ER ) +if (memac_in_32 (®s->mdio_stat) &MDIO_STAT_RD_ER )return 0xffff ; -return in_be32 (®s->mdio_data) &0xffff ; +return memac_in_32 (®s->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@@ -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--1.7.9.5
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
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_ENDIANfor little endian SoCs, if theCONFIG_SYS_MEMAC_LITTLE_ENDIANis defined, the I/O access is little endian, if not, the I/O access is big endian. Movefsl_memac.hout 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
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@@ -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.odrivers/net/fm/eth.c +1
-1@@ -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@@ -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
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 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_clrbits_32 (®s->mdio_stat,MDIO_STAT_ENC ); }else -setbits_be32 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_setbits_32 (®s->mdio_stat,MDIO_STAT_ENC );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->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 (®s->mdio_ctl, mdio_ctl); +memac_out_32 (®s->mdio_ctl, mdio_ctl);/* Set the register address */ if (c45) -out_be32 (®s->mdio_addr, regnum &0xffff ); +memac_out_32 (®s->mdio_addr, regnum &0xffff );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->mdio_stat)) &MDIO_STAT_BSY ) ;/* Write the value to the register */ -out_be32 (®s->mdio_data,MDIO_DATA (value)); +memac_out_32 (®s->mdio_data,MDIO_DATA (value));/* Wait till the MDIO write is complete */ -while ((in_be32 (®s->mdio_data)) &MDIO_DATA_BSY ) +while ((memac_in_32 (®s->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 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_clrbits_32 (®s->mdio_stat,MDIO_STAT_ENC ); }else -setbits_be32 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_setbits_32 (®s->mdio_stat,MDIO_STAT_ENC );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->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 (®s->mdio_ctl, mdio_ctl); +memac_out_32 (®s->mdio_ctl, mdio_ctl);/* Set the register address */ if (c45) -out_be32 (®s->mdio_addr, regnum &0xffff ); +memac_out_32 (®s->mdio_addr, regnum &0xffff );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->mdio_stat)) &MDIO_STAT_BSY ) ;/* Initiate the read */ mdio_ctl |=MDIO_CTL_READ ; -out_be32 (®s->mdio_ctl, mdio_ctl); +memac_out_32 (®s->mdio_ctl, mdio_ctl);/* Wait till the MDIO write is complete */ -while ((in_be32 (®s->mdio_data)) &MDIO_DATA_BSY ) +while ((memac_in_32 (®s->mdio_data)) &MDIO_DATA_BSY ) ;/* Return all Fs if nothing was there */ -if (in_be32 (®s->mdio_stat) &MDIO_STAT_RD_ER ) +if (memac_in_32 (®s->mdio_stat) &MDIO_STAT_RD_ER )return 0xffff ; -return in_be32 (®s->mdio_data) &0xffff ; +return memac_in_32 (®s->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@@ -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--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
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_ENDIANfor little endian SoCs, if theCONFIG_SYS_MEMAC_LITTLE_ENDIANis defined, the I/O access is little endian, if not, the I/O access is big endian. Movefsl_memac.hout of powerpc include.Signed-off-by Shaohui Xie <[email protected]>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@@ -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
-0obj-$(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.odrivers/net/fm/eth.c +1
-1@@ -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@@ -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
-0drivers/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
-2if (dev_addr ==MDIO_DEVAD_NONE ) { c45 =0 ;/* clause 22 */ dev_addr = regnum &0x1f ; -clrbits_be32 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_clrbits_32 (®s->mdio_stat,MDIO_STAT_ENC ); }else -setbits_be32 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_setbits_32 (®s->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 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->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 (®s->mdio_ctl, mdio_ctl); +memac_out_32 (®s->mdio_ctl, mdio_ctl);/* Set the register address */ if (c45) -out_be32 (®s->mdio_addr, regnum &0xffff ); +memac_out_32 (®s->mdio_addr, regnum &0xffff );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->mdio_stat)) &MDIO_STAT_BSY ) ;/* Write the value to the register */ -out_be32 (®s->mdio_data,MDIO_DATA (value)); +memac_out_32 (®s->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 (®s->mdio_data)) &MDIO_DATA_BSY ) +while ((memac_in_32 (®s->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
-2return 0xffff ; c45 =0 ;/* clause 22 */ dev_addr = regnum &0x1f ; -clrbits_be32 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_clrbits_32 (®s->mdio_stat,MDIO_STAT_ENC ); }else -setbits_be32 (®s->mdio_stat,MDIO_STAT_ENC ); +memac_setbits_32 (®s->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 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->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 (®s->mdio_ctl, mdio_ctl); +memac_out_32 (®s->mdio_ctl, mdio_ctl);/* Set the register address */ if (c45) -out_be32 (®s->mdio_addr, regnum &0xffff ); +memac_out_32 (®s->mdio_addr, regnum &0xffff );/* Wait till the bus is free */ -while ((in_be32 (®s->mdio_stat)) &MDIO_STAT_BSY ) +while ((memac_in_32 (®s->mdio_stat)) &MDIO_STAT_BSY ) ;/* Initiate the read */ mdio_ctl |=MDIO_CTL_READ ; -out_be32 (®s->mdio_ctl, mdio_ctl); +memac_out_32 (®s->mdio_ctl, mdio_ctl);/* Wait till the MDIO write is complete */ -while ((in_be32 (®s->mdio_data)) &MDIO_DATA_BSY ) +while ((memac_in_32 (®s->mdio_data)) &MDIO_DATA_BSY ) ;/* Return all Fs if nothing was there */ -if (in_be32 (®s->mdio_stat) &MDIO_STAT_RD_ER ) +if (memac_in_32 (®s->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 (®s->mdio_data) &0xffff ; +return memac_in_32 (®s->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@@ -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--1.7.9.5
_______________________________________________
U-Boot mailing list
U-Boot at lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
PATCH 15/28 net/memac_phy: reuse driver for little endian SoCs
Quoted 9 lines
Quoted 5 lines
/* IFC */
#defineCONFIG_SYS_FSL_IFC_LE
+#defineCONFIG_SYS_MEMAC_LITTLE_ENDIANIt 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
PATCH 15/28 net/memac_phy: reuse driver for little endian SoCs
Quoted 5 lines · Shaohui Xie
Quoted 5 lines
Quoted 3 lines
/* IFC */
#defineCONFIG_SYS_FSL_IFC_LE
+#defineCONFIG_SYS_MEMAC_LITTLE_ENDIANIt 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,
PATCH 16/28 armv8/fsl-ch3: Add support to print RCW configuration
In reply to York SunFrom: 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
@@ -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
PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts
In reply to York SunFrom: 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
@@ -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 */ + asmvolatile ("msr daifclr, #4" : : :"memory" ); +return 0 ; }
Signature · 1 line
1.7.9.5
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
Signed-off-by Scott Wood <[email protected]>--- arch/arm/cpu/armv8/fsl-lsch3/cpu.c | 4 ++++ 1 file changed, 4 insertions(+)arch/arm/cpu/armv8/fsl-lsch3/cpu.c +4
-0@@ -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 */ + asmvolatile ("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
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
Signed-off-by Scott Wood <[email protected]>
York, where's your signoff since you're the one submitting the patch?
-Scott
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
Signed-off-by Scott Wood <[email protected]>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
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
Signed-off-by Scott Wood <[email protected]>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
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
Signed-off-by Scott Wood <[email protected]>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
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
Signed-off-by Scott Wood <[email protected]>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
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
Signed-off-by Scott Wood <[email protected]>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
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
Signed-off-by Scott Wood <[email protected]>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
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
Signed-off-by Scott Wood <[email protected]>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
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
Signed-off-by Scott Wood <[email protected]>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
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
Signed-off-by Scott Wood <[email protected]>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
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
Signed-off-by Scott Wood <[email protected]>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
PATCH 17/28 armv8/fsl-lsch3: Enable system error aborts
In reply to Scott WoodQuoted 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
PATCH 18/28 driver/ldpaa: Add support of WRIOP static data structure
In reply to York SunFrom: 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
@@ -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
@@ -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
@@ -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 0x00800000u8 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
@@ -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
@@ -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
PATCH 19/28 armv8/ls2085aqds: Add support of LS2085AQDS platform
In reply to York SunThe 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.harch/arm/Kconfig +11 -0
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 20/28 armv8/ls2085ardb: Add support of LS2085ARDB platform
In reply to York SunThe LS2080ARDB is a evaluation platform that supports LS2080A family SoCs. This patch add sbasic support for the platform.
---
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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
board/freescale/ls2085ardb/ddr.h renamed from board/freescale/ls2085aqds/ddr.h +3 -3
@@ -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
@@ -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
@@ -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
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@@ -4,5 +4,5 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-y += ls2085aqds.o +obj-y += ls2085ardb.o obj-y += ddr.oboard/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +0
-0
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
-1LS2085A 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
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@@ -4,5 +4,5 @@ # SPDX-License-Identifier: GPL-2.0+ # -obj-y += ls2085aqds.o +obj-y += ls2085ardb.o obj-y += ddr.oboard/freescale/ls2085ardb/README renamed from board/freescale/ls2085aqds/README +0
-0board/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
-1LS2085A 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 OverviewInconsistent 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_ADDRESS1I 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 0x08Is 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
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 longget_board_sys_clk(void);
-unsigned longget_board_ddr_clk(void);
#endifQuoted 6 lines
include/configs/ls2085ardb.h line 27
Quoted 4 lines
#define
CONFIG_SYS_CLK_FREQget_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 0x08Is 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
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 longget_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 0x08Is 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
PATCH 21/28 drivers/fsl-mc: Autoload AOIP image from NOR flash
In reply to York SunFrom: "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.
--- 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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 22/28 board/ls2085qds: Add support ethernet
In reply to York SunFrom: 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
--- 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 23/28 driver/ifc: Add 64KB page support
In reply to York SunFrom: 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.
--- 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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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 (®s.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
PATCH 24/28 armv8/ls2085aqds: NAND boot support
In reply to York SunFrom: 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_defconfigarch/arm/Kconfig +1 -0
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 25/28 freescale/qixis: Add support for booting from NAND
In reply to York SunFrom: 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
@@ -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
PATCH 26/28 armv8/ls2085ardb: Enable NAND SPL support
In reply to York SunFrom: 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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 27/28 ls2085a: esdhc: Add esdhc support for ls2085a
In reply to York SunFrom: 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
@@ -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
@@ -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
@@ -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
@@ -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 (®s->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 (®s->dsaddr,lower_32_bits (addr)); +#else esdhc_write32 (®s->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 (®s->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 (®s->dsaddr,lower_32_bits (addr)); +#else esdhc_write32 (®s->dsaddr, (u32 )data->src);#endif +#endif }esdhc_write32 (®s->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
@@ -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
@@ -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
@@ -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
@@ -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
PATCH 28/28 armv8/fsl-lsch3: Implement workaround for I2C issue
In reply to York SunThis 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
@@ -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
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_ENbit in debug register.Signed-off-by York Sun <[email protected]>--- arch/arm/cpu/armv8/fsl-lsch3/soc.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)arch/arm/cpu/armv8/fsl-lsch3/soc.c +0
-0
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
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_ENbit in debug register.Signed-off-by York Sun <[email protected]>--- arch/arm/cpu/armv8/fsl-lsch3/soc.c | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+)arch/arm/cpu/armv8/fsl-lsch3/soc.c +0
-0@@ -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