[U-Boot] [PATCH 0/2] ARM: cache: clean up the code to drop the empty stub functions
This series is based on the patch I sent: http://patchwork.ozlabs.org/patch/481095/ As above introduces the default empty function for invalidate_dcache_range() & flush_dcache_range() in arch/arm/lib/cache.c. So in this series, we can drop the empty stubs in arch/arm/cpu/ Also this series introduces a default function for flush_cache(). Josh Wu (2): ARM: cache: drop the empty dcache functions as we have it in lib/cache.c ARM: cache: implement a default flush_cache() function arch/arm/cpu/arm1136/cpu.c | 17 - arch/arm/cpu/arm926ejs/cache.c | 17 - arch/arm/cpu/armv7/cache_v7.c | 21 - arch/arm/cpu/armv8/cache_v8.c | 16 arch/arm/lib/cache.c | 26 +- 5 files changed, 5 insertions(+), 92 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: cache: implement a default flush_cache() function
It will just call flush_dcache_range().
As ARM1136 & ARM926ejs already implemented their own flush_cache(), those
code in weak function in arch/arm/lib/cache.c can be dropped.
Signed-off-by: Josh Wu
---
arch/arm/cpu/arm1136/cpu.c | 9 -
arch/arm/cpu/arm926ejs/cache.c | 9 -
arch/arm/cpu/armv7/cache_v7.c | 13 -
arch/arm/cpu/armv8/cache_v8.c | 8
arch/arm/lib/cache.c | 26 +-
5 files changed, 5 insertions(+), 60 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index b4d1d54..f092ffc 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -120,11 +120,6 @@ void flush_dcache_range(unsigned long start, unsigned long
stop)
asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
}
-void flush_cache(unsigned long start, unsigned long size)
-{
- flush_dcache_range(start, start + size);
-}
-
#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
void invalidate_dcache_all(void)
{
@@ -133,10 +128,6 @@ void invalidate_dcache_all(void)
void flush_dcache_all(void)
{
}
-
-void flush_cache(unsigned long start, unsigned long size)
-{
-}
#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
#if !defined(CONFIG_SYS_ICACHE_OFF) || !defined(CONFIG_SYS_DCACHE_OFF)
diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
index 99d1a13..e5c1a6a 100644
--- a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ -69,11 +69,6 @@ void flush_dcache_range(unsigned long start, unsigned long
stop)
asm volatile("mcr p15, 0, %0, c7, c10, 4\n" : : "r"(0));
}
-
-void flush_cache(unsigned long start, unsigned long size)
-{
- flush_dcache_range(start, start + size);
-}
#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
void invalidate_dcache_all(void)
{
@@ -82,10 +77,6 @@ void invalidate_dcache_all(void)
void flush_dcache_all(void)
{
}
-
-void flush_cache(unsigned long start, unsigned long size)
-{
-}
#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
/*
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 4f0e406..a5aa4fa 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -286,15 +286,6 @@ void mmu_page_table_flush(unsigned long start, unsigned
long stop)
flush_dcache_range(start, stop);
v7_inval_tlb();
}
-
-/*
- * Flush range from all levels of d-cache/unified-cache used:
- * Affects the range [start, start + size - 1]
- */
-void flush_cache(unsigned long start, unsigned long size)
-{
- flush_dcache_range(start, start + size);
-}
#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
void invalidate_dcache_all(void)
{
@@ -308,10 +299,6 @@ void arm_init_before_mmu(void)
{
}
-void flush_cache(unsigned long start, unsigned long size)
-{
-}
-
void mmu_page_table_flush(unsigned long start, unsigned long stop)
{
}
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index f8c17cc..92b66c3 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -217,11 +217,3 @@ void __weak enable_caches(void)
icache_enable();
dcache_enable();
}
-
-/*
- * Flush range from all levels of d-cache/unified-cache
- */
-void flush_cache(unsigned long start, unsigned long size)
-{
- flush_dcache_range(start, start + size);
-}
diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index bc48f53..cd13db3 100644
--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -10,29 +10,13 @@
#include
#include
+/*
+ * Flush range from all levels of d-cache/unified-cache.
+ * Affects the range [start, start + size - 1].
+ */
__weak void flush_cache(unsigned long start, unsigned long size)
{
-#if defined(CONFIG_CPU_ARM1136)
-
-#if !defined(CONFIG_SYS_ICACHE_OFF)
- asm("mcr p15, 0, r1, c7, c5, 0"); /* invalidate I cache */
-#endif
-
-#if !defined(CONFIG_SYS_DCACHE_OFF)
- asm("mcr p15, 0, r1, c7, c14, 0"); /* Clean+invalidate D cache */
-#endif
-
-#endif /* CONFIG_CPU_ARM1136 */
-
-#ifdef CONFIG_CPU_ARM926EJS
-#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
- /* test and clean, page 2-23 of arm926ejs manual */
- asm("0: mrc p15, 0, r15, c7, c10, 3\n\t" "bne 0b\n" : : : "memory");
- /* disable write buffer as well (page 2-22) */
- asm("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
-#endif
-#endif /* CONFIG_CPU_ARM926EJS */
- return;
+ flush_dcache_range(start, start + size);
}
/*
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: davinci_emac: don't teardown inactive rx channel
* Joe Hershberger [150610 07:26]: > Hi Jeroen, > > On Sun, Jun 7, 2015 at 10:30 AM, Jeroen Hofstee wrote: > > Tearing down an unitialized rx channel causes a pending address hole > > event to be queued. When booting linux it will report this pending > > as something like "Address Hole seen by USB_OTG at address 57fff584", > > since u-boot did not handled this interrupt. Prevent that by not > > tearing down the rx channel, when not receiving. > > > > Signed-off-by: Jeroen Hofstee > > --- > > To replicate this: > > - ROMcode must not use the emac > > - U-Boot must use the emac > > - only on cold start > > --- > > I don't know the hardware, but it sounds like a reasonable > explanation. Look good to you, Tony? Sure. Tony ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: cache: drop the empty dcache functions as we have it in lib/cache.c
As there are empty function invalidate_dcache_range(), flush_dcache_range()
in arch/arm/lib/cache.c. So we can reuse it by just drop them in arch/arm/cpu/.
Signed-off-by: Josh Wu
---
arch/arm/cpu/arm1136/cpu.c | 8
arch/arm/cpu/arm926ejs/cache.c | 8
arch/arm/cpu/armv7/cache_v7.c | 8
arch/arm/cpu/armv8/cache_v8.c | 8
4 files changed, 32 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index a7aed4b..b4d1d54 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -134,14 +134,6 @@ void flush_dcache_all(void)
{
}
-void invalidate_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
-void flush_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
void flush_cache(unsigned long start, unsigned long size)
{
}
diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
index 8d7873c..99d1a13 100644
--- a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ -83,14 +83,6 @@ void flush_dcache_all(void)
{
}
-void invalidate_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
-void flush_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
void flush_cache(unsigned long start, unsigned long size)
{
}
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index e8ee875..4f0e406 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -304,14 +304,6 @@ void flush_dcache_all(void)
{
}
-void invalidate_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
-void flush_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
void arm_init_before_mmu(void)
{
}
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index c5ec529..f8c17cc 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -149,14 +149,6 @@ void flush_dcache_all(void)
{
}
-void invalidate_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
-void flush_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
void dcache_enable(void)
{
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/2] ARM: cache: implement a default flush_cache() function
It will just call flush_dcache_range().
As ARM1136 & ARM926ejs already implemented their own flush_cache(), those
code in weak function in arch/arm/lib/cache.c can be dropped.
Signed-off-by: Josh Wu
---
arch/arm/cpu/arm1136/cpu.c | 9 -
arch/arm/cpu/arm926ejs/cache.c | 9 -
arch/arm/cpu/armv7/cache_v7.c | 13 -
arch/arm/cpu/armv8/cache_v8.c | 8
arch/arm/lib/cache.c | 26 +-
5 files changed, 5 insertions(+), 60 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index b4d1d54..f092ffc 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -120,11 +120,6 @@ void flush_dcache_range(unsigned long start, unsigned long
stop)
asm volatile("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
}
-void flush_cache(unsigned long start, unsigned long size)
-{
- flush_dcache_range(start, start + size);
-}
-
#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
void invalidate_dcache_all(void)
{
@@ -133,10 +128,6 @@ void invalidate_dcache_all(void)
void flush_dcache_all(void)
{
}
-
-void flush_cache(unsigned long start, unsigned long size)
-{
-}
#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
#if !defined(CONFIG_SYS_ICACHE_OFF) || !defined(CONFIG_SYS_DCACHE_OFF)
diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
index 99d1a13..e5c1a6a 100644
--- a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ -69,11 +69,6 @@ void flush_dcache_range(unsigned long start, unsigned long
stop)
asm volatile("mcr p15, 0, %0, c7, c10, 4\n" : : "r"(0));
}
-
-void flush_cache(unsigned long start, unsigned long size)
-{
- flush_dcache_range(start, start + size);
-}
#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
void invalidate_dcache_all(void)
{
@@ -82,10 +77,6 @@ void invalidate_dcache_all(void)
void flush_dcache_all(void)
{
}
-
-void flush_cache(unsigned long start, unsigned long size)
-{
-}
#endif /* #ifndef CONFIG_SYS_DCACHE_OFF */
/*
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 4f0e406..a5aa4fa 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -286,15 +286,6 @@ void mmu_page_table_flush(unsigned long start, unsigned
long stop)
flush_dcache_range(start, stop);
v7_inval_tlb();
}
-
-/*
- * Flush range from all levels of d-cache/unified-cache used:
- * Affects the range [start, start + size - 1]
- */
-void flush_cache(unsigned long start, unsigned long size)
-{
- flush_dcache_range(start, start + size);
-}
#else /* #ifndef CONFIG_SYS_DCACHE_OFF */
void invalidate_dcache_all(void)
{
@@ -308,10 +299,6 @@ void arm_init_before_mmu(void)
{
}
-void flush_cache(unsigned long start, unsigned long size)
-{
-}
-
void mmu_page_table_flush(unsigned long start, unsigned long stop)
{
}
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index f8c17cc..92b66c3 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -217,11 +217,3 @@ void __weak enable_caches(void)
icache_enable();
dcache_enable();
}
-
-/*
- * Flush range from all levels of d-cache/unified-cache
- */
-void flush_cache(unsigned long start, unsigned long size)
-{
- flush_dcache_range(start, start + size);
-}
diff --git a/arch/arm/lib/cache.c b/arch/arm/lib/cache.c
index bc48f53..cd13db3 100644
--- a/arch/arm/lib/cache.c
+++ b/arch/arm/lib/cache.c
@@ -10,29 +10,13 @@
#include
#include
+/*
+ * Flush range from all levels of d-cache/unified-cache.
+ * Affects the range [start, start + size - 1].
+ */
__weak void flush_cache(unsigned long start, unsigned long size)
{
-#if defined(CONFIG_CPU_ARM1136)
-
-#if !defined(CONFIG_SYS_ICACHE_OFF)
- asm("mcr p15, 0, r1, c7, c5, 0"); /* invalidate I cache */
-#endif
-
-#if !defined(CONFIG_SYS_DCACHE_OFF)
- asm("mcr p15, 0, r1, c7, c14, 0"); /* Clean+invalidate D cache */
-#endif
-
-#endif /* CONFIG_CPU_ARM1136 */
-
-#ifdef CONFIG_CPU_ARM926EJS
-#if !(defined(CONFIG_SYS_ICACHE_OFF) && defined(CONFIG_SYS_DCACHE_OFF))
- /* test and clean, page 2-23 of arm926ejs manual */
- asm("0: mrc p15, 0, r15, c7, c10, 3\n\t" "bne 0b\n" : : : "memory");
- /* disable write buffer as well (page 2-22) */
- asm("mcr p15, 0, %0, c7, c10, 4" : : "r" (0));
-#endif
-#endif /* CONFIG_CPU_ARM926EJS */
- return;
+ flush_dcache_range(start, start + size);
}
/*
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [resend][PATCH 0/2] ARM: cache: clean up the code to drop the empty stub functions
This series is based on the patch I sent: http://patchwork.ozlabs.org/patch/481095/ As above introduces the default empty function for invalidate_dcache_range() & flush_dcache_range() in arch/arm/lib/cache.c. So in this series, we can drop the empty stubs in arch/arm/cpu/ Also this series introduces a default function for flush_cache(). Josh Wu (2): ARM: cache: drop the empty dcache functions as we have it in lib/cache.c ARM: cache: implement a default flush_cache() function arch/arm/cpu/arm1136/cpu.c | 17 - arch/arm/cpu/arm926ejs/cache.c | 17 - arch/arm/cpu/armv7/cache_v7.c | 21 - arch/arm/cpu/armv8/cache_v8.c | 16 arch/arm/lib/cache.c | 26 +- 5 files changed, 5 insertions(+), 92 deletions(-) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] ARM: cache: add an empty stub function for invalidate/flush dcache
On 6/10/2015 5:58 PM, Marek Vasut wrote: On Wednesday, June 10, 2015 at 11:49:54 AM, Josh Wu wrote: On 6/9/2015 9:11 PM, Tom Rini wrote: On Tue, Jun 09, 2015 at 11:54:14AM +0800, Josh Wu wrote: Hi, Tom On 6/8/2015 9:20 PM, Tom Rini wrote: On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote: On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote: Hi, Marek On 6/5/2015 9:18 PM, Marek Vasut wrote: On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote: Since some driver like ohci, lcd used dcache functions. But some ARM cpu don't implement the invalidate_dcache_range()/flush_dcache_range() functions. To avoid compiling errors this patch adds an weak empty stub function for all ARM cpu. And each cpu can implement its own implementation. If not implemented by default it will use an empty function. Signed-off-by: Josh Wu --- Changes in v2: new added arch/arm/lib/cache.c | 9 + 1 file changed, 9 insertions(+) So, why exactly can't this be entirely common code , but a CPU-specific code ? :) Do you mean to make those empty functions as common code for all arch cpu to use? Yes. It seems there is no place to put common code for all arch cpu. Isn't that what the common/ directory is for ? ;-) No, this is making something common for the sake of making it common rather than good architecutre of the code I think. We aren't going to share real cache functions just these dummy ones. So it is the right place: arch/arm/lib/cache.c to put the dummy cache function. Yes. We may re-evaluate our dummy ones at some point in the future when people try and use some particular combination harder, see for example the PowerPC dummy cache functions we just recently dropped. Thanks! If this patch set are ok for you. I will sent more patches to drop the dummy cache functions in /cpu/ folders. Right, that's the best palce I think, baring an existing arch having a location for weak cache functions already (like arm does). Also the flush_cache() in arch/arm/lib/cache.c can be dropped and just call flush_dcache_range() as the ARM1136, ARM926ejs alreay implemented their own flush_cache(). Nope, other things fail if you do that (vpac270_nor_256 and 24 others at least so far in my test build). Does it fail to compile or on running? As I don't have the board to test the binary, but I don't find any compile error when I apply such a patch. Maybe it is better to sent out my patch for you to check. VPAC is PXA270 and to my knowledge, PXA has no cache support in place at all. ok, so use a empty function is reasonable for pxa. Marek, Tom I just sent out another two patches: first one is drop the invalidate_dcache_range()/flush_dcache_range(). second one is drop the flush_cache() function. Could you check those two patches? thank you. Best Regards, Josh Wu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/2] ARM: cache: drop the empty dcache functions as we have it in lib/cache.c
Signed-off-by: Josh Wu
---
arch/arm/cpu/arm1136/cpu.c | 8
arch/arm/cpu/arm926ejs/cache.c | 8
arch/arm/cpu/armv7/cache_v7.c | 8
arch/arm/cpu/armv8/cache_v8.c | 8
4 files changed, 32 deletions(-)
diff --git a/arch/arm/cpu/arm1136/cpu.c b/arch/arm/cpu/arm1136/cpu.c
index a7aed4b..b4d1d54 100644
--- a/arch/arm/cpu/arm1136/cpu.c
+++ b/arch/arm/cpu/arm1136/cpu.c
@@ -134,14 +134,6 @@ void flush_dcache_all(void)
{
}
-void invalidate_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
-void flush_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
void flush_cache(unsigned long start, unsigned long size)
{
}
diff --git a/arch/arm/cpu/arm926ejs/cache.c b/arch/arm/cpu/arm926ejs/cache.c
index 8d7873c..99d1a13 100644
--- a/arch/arm/cpu/arm926ejs/cache.c
+++ b/arch/arm/cpu/arm926ejs/cache.c
@@ -83,14 +83,6 @@ void flush_dcache_all(void)
{
}
-void invalidate_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
-void flush_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
void flush_cache(unsigned long start, unsigned long size)
{
}
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index e8ee875..4f0e406 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -304,14 +304,6 @@ void flush_dcache_all(void)
{
}
-void invalidate_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
-void flush_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
void arm_init_before_mmu(void)
{
}
diff --git a/arch/arm/cpu/armv8/cache_v8.c b/arch/arm/cpu/armv8/cache_v8.c
index c5ec529..f8c17cc 100644
--- a/arch/arm/cpu/armv8/cache_v8.c
+++ b/arch/arm/cpu/armv8/cache_v8.c
@@ -149,14 +149,6 @@ void flush_dcache_all(void)
{
}
-void invalidate_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
-void flush_dcache_range(unsigned long start, unsigned long stop)
-{
-}
-
void dcache_enable(void)
{
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] No maintainer info
Hi Simon, Tom, 2015-06-05 0:17 GMT+09:00 Simon Glass : > Hi, > > The genboardsconfig.py script reports a growing list of warnings: > > WARNING: no status info for 'axs103' > WARNING: no maintainers for 'axs103' > WARNING: no status info for 'at91sam9g20ek_2mmc' > WARNING: no maintainers for 'at91sam9g20ek_2mmc' > WARNING: no status info for 'at91sam9rlek_mmc' > WARNING: no maintainers for 'at91sam9rlek_mmc' > WARNING: no status info for 'socfpga_arria5' > WARNING: no maintainers for 'socfpga_arria5' > WARNING: no status info for 'cairo' > WARNING: no maintainers for 'cairo' > WARNING: no status info for 'odroid-xu3' > WARNING: no maintainers for 'odroid-xu3' > WARNING: no status info for 'db-88f6820-gp' > WARNING: no maintainers for 'db-88f6820-gp' > > Does anyone have ideas on how to avoid this growing further? U-Boot traditionally requires a maintainer for each board, but people tend to forget to add MAINTAINERS. My question is: Does it make sense to continue per-board maintainer scheme? If so, what need to do is to figure out who was the initial author and add the MAINTAINERS file. If not, stop such WARNING messages. -- Best Regards Masahiro Yamada ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 00/18] dm: Introduce device tree support in SPL (for Rockchip)
Hi Tom, On 4 June 2015 at 17:48, Simon Glass wrote: > Hi Tom, > > On 12 May 2015 at 14:55, Simon Glass wrote: >> With driver model SPL support in place the remaining driver difference >> between U-Boot proper and SPL is that SPL does not support device tree. >> This series adds this support, using a Rockchip board as an example. > > I'd like to apply some of these - they are assigned to you in > patchwork. I need to be a little careful with the device tree SPL > change to make sure it does not affect any existing boards (and do a > final test with the boards I have). Is this OK with you or would you > prefer to apply some yourself? > > For now I don't want to apply all the Rockchip patches, as I have a > much more functional port now and want to avoid churn. I'll tidy those > patches up and see how we get them applied later. > > [snip] I'll go ahead and apply these and send a pull request. It tests out OK on the platforms I have. Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sunxi master
Hi, On 10 June 2015 at 08:56, Tom Rini wrote: > On Wed, Jun 10, 2015 at 04:54:50PM +0200, Hans de Goede wrote: > >> Hi Tom, >> >> Please pull u-boot-sunxi/master into master for 2 small bug-fixes: >> >> The following changes since commit 3d0158ae18bef2ac89979f4c90419d3add436c71: >> >> Prepare v2015.07-rc2 (2015-06-08 17:48:33 -0400) >> >> are available in the git repository at: >> >> http://git.denx.de/u-boot-sunxi.git master >> >> for you to fetch changes up to 0751b138064db28f0866f0c2439afb8b3975180c: >> >> sunxi: Enable CONFIG_SYS_64BIT_LBA when AHCI is used (2015-06-10 16:52:12 >> +0200) >> > > Applied to u-boot/master, thanks! I don't see this patch on the mailing list or I would reply there. But for my toolchain I get errors: crosfw -b Orangepi_mini -w # # configuration written to .config # /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(bpabi.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(bpabi.o) /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_divdi3.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_divdi3.o) /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: error: /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_udivdi3.o) uses VFP register arguments, u-boot does not /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/arm-linux-gnueabihf-ld.bfd: failed to merge target specific data of file /opt/linaro/gcc-linaro-arm-linux-gnueabihf-4.8-2013.10_linux/bin/../lib/gcc/arm-linux-gnueabihf/4.8.2/libgcc.a(_udivdi3.o) make[1]: *** [u-boot] Error 1 make[1]: *** Waiting for unfinished jobs Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] please pull u-boot-samsung master
On Thu, Jun 11, 2015 at 10:43:49AM +0900, Minkyu Kang wrote: > Dear Tom, > > The following changes since commit 3d0158ae18bef2ac89979f4c90419d3add436c71: > > Prepare v2015.07-rc2 (2015-06-08 17:48:33 -0400) > > are available in the git repository at: > > http://git.denx.de/u-boot-samsung > > for you to fetch changes up to 91432d2f2fab4a780d860bd6cb4922ca11b2aac8: > > odroid: dts: cleanup of MAX77686 regulators (2015-06-10 14:09:20 +0900) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] please pull u-boot-samsung master
Dear Tom, The following changes since commit 3d0158ae18bef2ac89979f4c90419d3add436c71: Prepare v2015.07-rc2 (2015-06-08 17:48:33 -0400) are available in the git repository at: http://git.denx.de/u-boot-samsung for you to fetch changes up to 91432d2f2fab4a780d860bd6cb4922ca11b2aac8: odroid: dts: cleanup of MAX77686 regulators (2015-06-10 14:09:20 +0900) Przemyslaw Marczak (1): odroid: dts: cleanup of MAX77686 regulators arch/arm/dts/exynos4412-odroid.dts | 80 +--- -- Thanks, Minkyu Kang. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] drivers/fsl-mc: Autoload AOIP image from NOR flash
> -Original Message- > From: Sun York-R58495 > Sent: Wednesday, June 10, 2015 8:06 PM > To: Kushwaha Prabhakar-B32579; u-boot@lists.denx.de > Cc: Rivera Jose-B46482 > Subject: Re: [PATCH 03/13] drivers/fsl-mc: Autoload AOIP image from NOR > flash > > > > On 06/10/2015 03:39 AM, Prabhakar Kushwaha wrote: > > From: "J. German Rivera" > > > > Load AIOP image from NOR flash into DDR so that the MC firmware the MC > > fw can start it at boot time > > > > Signed-off-by: J. German Rivera > > Signed-off-by: Prabhakar Kushwaha > > Prabhakar, > > Do we need this feature? It was written for bring-up. AIOP image should be > loaded by Linux later for normal use. > I have no visibility when AIOP loader will be available in Linux. I am not seeing any plan of completing in next 1month or so. This is the reason I am having this feature. It is under #ifdef. If required it can be disabled.. --prabhakar ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MinnowBoard Max uboot
Hi Thomas, On 10 June 2015 at 12:38, Beaman, Thomas wrote: > Hi Simon, > > I have just picked up u-boot-2015.07-rc2 with your support for multiple CPUs > on the minnowboard max. I can see using the uboot cpu list command that both > CPUs now show up. But the kernel does not see 2 CPUs in /proc/cpuinfo. If I > boot the same kernel using an EFI BIOS I do see 2 CPUs in /proc/cpuinfo. Is > there some uboot to kernel hand off I do not have configured properly ? I am > not sure how the number of CPUs gets transferred from the boot to the kernel. > > Thanks for any input you may have. > Tom > > => cpu list > 0: cpu@0 Intel(R) Atom(TM) CPU E3825 @ 1.33GHz > 1: cpu@1 Intel(R) Atom(TM) CPU E3825 @ 1.33GHz > > ## minnow max when booted from uboot 2015-07.rc2 > root@atom_230:~# cat /proc/cpuinfo | grep processor > processor : 0 > > ## minnow max when booted from BIOS > root@atom_230:~# cat /proc/cpuinfo | grep processor > processor : 0 > processor : 1 Do you have the output from the kernel boot please? Regards, Simon > > > > -Original Message- > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass > Sent: Tuesday, March 10, 2015 1:21 PM > To: Beaman, Thomas > Cc: u-boot@lists.denx.de; Bin Meng; gabriel huau > Subject: Re: MinnowBoard Max uboot > > Hi Tom, > > On 10 March 2015 at 05:24, Beaman, Thomas wrote: >> Hi Simon, >> >> Do you know what will be the timeframe of when someone may be able to >> look at this in more detail. I will be able to help test any updates >> if needed >> > > I will take a look once I have things lined up for the next release, likely > mid April. > > Regards, > Simon > >> Thanks, >> Tom >> >> -Original Message- >> From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass >> Sent: Monday, March 09, 2015 11:49 AM >> To: Beaman, Thomas >> Cc: u-boot@lists.denx.de; Bin Meng; gabriel huau >> Subject: Re: MinnowBoard Max uboot >> >> +Bin and Gabriel >> >> Hi Tom, >> >> On 9 March 2015 at 08:08, Beaman, Thomas wrote: >>> >>> >>> Hi Simon, >>> >>> >>> >>> I see you have put support for the MinnowBoard Max in the u-boot mainline. >>> Thanks this is a very useful addition. I have been able to follow >>> your readme and build a working bare metal uboot. Using the built >>> uboot I can load and bring up a Linux Kernel. >>> >>> >>> >>> What I noticed from the running kernel is that only one of the two >>> cores on the E3825 is running. In the power PC uboots I usually see a >>> section for the multiple cores in the .dts file. My questions is how >>> do I get both CPUs running on this board. Is it a uboot .dts file >>> setup that will enable this, or is something in the kernel start up that >>> does this. >>> >>> >>> >>> As a test I boot the same kernel using the EFI BIOS on the minnow >>> board and both CPUs are running. >>> >>> >>> >>> Any suggestions or comments you have would be welcomed. >>> >>> >> >> My guess is that the LAPIC CPU start-up is missing. It isn't 100% clear what >> the FSP does and does not do, but perhaps it does not do that. >> >> I did make something of a start on this with ivybridge but it isn't >> complete, and it seems to be needed here. >> >> Regards, >> Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Regarding learning reference of uboot loading secondary uboot
Hi, On 27 May 2015 at 21:41, wrote: > Hi Simon, > Thanks for of your time and quick replies. The idea seems > to be good, but still confused with the way to implement it. Please help me > to give a final thought to solve this with the existing framework, sorry for > my inexperience with u-boot, kindly enlighten with the following: > > 1) How to sign the primary and secondary u-boot image with the same key, > after that do i need to write a routine similar to “bootm_find_os” or > “bootm_find_loadables" to find the secondary uboot image and load it into > the memory, If the first U-Boot is in read-only flash then it cannot be updated, so does not need to be signed. If it is in read-write flash, then you probably can't prevent it being overwritten. You could protect half of the flash, perhaps, and put the read-only U-Boot in the proetced half. Yes you can write a simple routine to load it. > 2) can we have a dummy fit image with only secondary u-boot image within the > .its file for the first u-boot loader I don't understand this sorry. > 3)Sorry to ask you this, do you have any partial code i can follow and > shred some light to carry on further. I don't have anything that reads a read-write U-Boot and jumps to it, other than the Chrome OS code that i think you have. > > > I really thanks you to answer my all questions with patience,i would have > not disturbed you, but because of project dead-line i was forced to be > carried out with the situation. OK. Please try to make the questions clear so that I can understand what you are asking. > > Thanks, > pratap > Regards, Simon > > > > > > > On May 23, 2015, at 2:12 PM, Simon Glass wrote: > > Hi, > > On 23 May 2015 at 13:02, Maddimsetty Pratap wrote: > > Hi Simon, > Thanks for you quick reply and sorry for the confusion over > forum,here is my request for help > > 1) Do you know any repository which had already did it > "verify second u-boot signature" over beaglebone. > > > I'm not sure if this was done or not. You could look in cros/amxx here: > > https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/chromeos-v2013.06 > > or a newer version that doesn't currently support beaglebone. > > https://chromium.googlesource.com/chromiumos/third_party/u-boot/+/chromeos-v2015.07-rc1 > > The Chrome OS implementation uses the same crypto but has custom > binary data structures. I'm working a bit on trying to bridge the gap > but we are not there yet. > > So the easiest way to make this work is probably to use the FIT > signature verification and put your second U-Boot into the FIT. That > should handle the verification and then after it loads you can turn > off the cache and jump to it. It already works on Beaglebone and the > only difference is that it is currently set up to load a kernel, but > you want to load U-Boot. > > > 2) Please verify and confirm the following link, if i was going > in the right direction. > > http://git.chromium.org/gitweb/?p=chromiumos/third_party/u-boot.git;a=commit;h=b9e8864294d8f2143ce17b4e0d4ba019b6348199 > > Thanks, > pratap > > > Regards, > Simon > > > Thanks, > pratap > > On Thu, May 21, 2015 at 6:32 PM, Simon Glass wrote: > > > Hi, > > It's here: > > https://chromium.googlesource.com/chromiumos/third_party/u-boot > > in branch chromeos-v2013.06. It is implemented for chromeos_peach. > > If you have further questions, please send them to the U-Boot mailing list > and cc me. > > Regards, > Simon > > > On 21 May 2015 at 17:25, Maddimsetty Pratap wrote: > > > Hi Simon, > I am apologize to e-mail you directly. In one of your > presentations regarding FIT, you had stated uboot loading a signed secondary > uboot loader in chromium. I would be glad if you provide me with any > reference regarding the same. > > > Here is the statement from LWN.net. > > > "Chrome OS starts up U-Boot, loads and verifies a second U-Boot, loads > and verifies a kernel and jumps to it all in under 700ms on a modern SoC" > > Thanks, > pratap > > > > > > > > > > > -- > pratap naidu > > ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] Nokia RX-51: Fix calculating return address in save_boot_params
Hi Pali, On 9 June 2015 at 12:27, Pali Rohár wrote: > > On Tuesday 09 June 2015 20:11:22 Simon Glass wrote: > > On 9 June 2015 at 10:05, Pali Rohár wrote: > > > Commit e11c6c279d823dc0d2f470c5c2e3c0a9854a640f broke calculating > > > lr register in function save_boot_params() and caused U-Boot to > > > crash at early boot time on Nokia N900 board. > > > > > > This patch fix calculating return address in lr register and make > > > Nokia N900 board bootable again. Patch was tested in qemu and also > > > on real N900 HW. > > > > > > Signed-off-by: Pali Rohár > > > --- > > > > > > board/nokia/rx51/lowlevel_init.S |4 > > > 1 file changed, 4 deletions(-) > > > > Reviewed-by: Simon Glass > > Tom, can you please apply this patch for 2015.07? > > Simon & others: in future, please can you CC me all patches which touch > Nokia N900 board code? We can prevent such breakage. Also you can test > u-boot for n900 in qemu. Here's the list patman generates for that patch: Cc: Rob Herring Cc: Simon Glass Cc: Tom Warren Cc: Thierry Reding Cc: Siarhei Siamashka Cc: Bryan Brinsko Cc: Ian Campbell Cc: York Sun Cc: Nishanth Menon Cc: Hans de Goede Cc: u-boot@lists.denx.de Cc: Tom Rini Cc: Albert Aribaud Cc: Peng Fan Cc: Georges Savoundararadj Cc: Minkyu Kang Cc: "Pali Rohár" I was probably just unwilling to email so many people, but in future I will be more willing. > > > -- > Pali Rohár > pali.ro...@gmail.com Regards, Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ti: am335x/am437x/omap5 devices: Fix breakage when CONFIG_CMD_NET is not used
On Wed, Jun 10, 2015 at 08:54:02AM -0500, Franklin S Cooper Jr wrote: > Currently there is no default value for NETARGS if CONFIG_CMD_NET=y isn't set. > This results in build errors which was first discovered when trying to run > make env. > > By defining a blank NETARGS these errors can be avoided. > > Signed-off-by: Franklin S Cooper Jr Reviewed-by: Tom Rini -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC 02/11] mtd/nand: add ONFI timing mode to nand_timings converter
On Wed, 2015-06-10 at 10:33 +0200, Hans de Goede wrote: > Hi Scott, > > On June 8, 2015, 8:24 p.m., Scott Wood wrote: > > > > >> Correct, my apologies as I should have clarified that "work by > Boris > >> Brezillon" does not > >> mean "upsteam work". The code comes from Boris' github tree[1] > and > >> contains work > >> that was not yet brought upstream, yet is required for NAND on > sunxi > >> to work. > >>> It would probably be better to handle this as part of a general > >>> sync > >>> with the Linux mtd code. > >> Ideally yes, but. In upstream Linux MTD we have a few issues to > >> address as shown > >> by Boris' patch-set, most importantly: > >> - NAND chip timings (patch 1 to 3) > > > > Patches 1-3 are already in Linux (if there are subtle differences > > needed those should be followup patches, with an explanation of > why it > > needs to differ from Linux), except that patch 3 for some reason > has > > "onfi_timing_mode_ds" where Linux has "onfi_timing_mode_default". > > > > I will try to do a sync soon. > > If you could do that that would be great, that should at least shrink > the size of this patch-set by 3 patches. > > I assume that you will not be sending a pull-req for this sync for > v2015.07, No, it's too late for that even if I had it ready now. > if you can make a git branch with the sync available > somewhere for us to build on top of, then that would be great. OK. -Scott ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/3] am43xx: Update CONFIG_SPL_TEXT_BASE
On Wed, Jun 10, 2015 at 03:04:15PM +0530, Mugunthan V N wrote: > From: Tom Rini > > With 1.2 silicon this is now the documented starting usable point for > downloading images to (and corrects a problem with peripheral booting > with prior silicon). Prior silicon is OK using this address as well. > > Signed-off-by: Tom Rini > Signed-off-by: Mugunthan V N Reviewed-by: Tom Rini -- Tom ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/3] am43xx_evm: add usb host boot support
On Wed, Jun 10, 2015 at 03:04:16PM +0530, Mugunthan V N wrote: > While booting via usb host mode, ROM uses DMA to copy MLO over USB so > ARM internal RAM cannot be used. Adding USB host boot support by > introducing new config target which sets SPL_TEXT_BASE to OCMC ram. > > Signed-off-by: Mugunthan V N > --- > configs/am43xx_evm_usbhost_boot_defconfig | 5 + > include/configs/am43xx_evm.h | 9 + > 2 files changed, 14 insertions(+) > create mode 100644 configs/am43xx_evm_usbhost_boot_defconfig > > diff --git a/configs/am43xx_evm_usbhost_boot_defconfig > b/configs/am43xx_evm_usbhost_boot_defconfig > new file mode 100644 > index 000..9455707 > --- /dev/null > +++ b/configs/am43xx_evm_usbhost_boot_defconfig > @@ -0,0 +1,5 @@ > +CONFIG_ARM=y > +CONFIG_TARGET_AM43XX_EVM=y > +CONFIG_SPL=y > +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,USBHOST_BOOT" > +CONFIG_CMD_NET=y We need to be adding USBHOST_BOOT in Kconfig and that's a bit too generic of a name. It should perhaps be removed all together and only set CONFIG_SPL_USB_HOST_SUPPORT for this build and not include it in the rest. -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 3/3] am43xx_evm: add eth boot support
On Wed, Jun 10, 2015 at 03:04:17PM +0530, Mugunthan V N wrote: > add cpsw ethernet boot mode support to download spl and > u-boot.img via tftp protocol. Also adding a seperate config > for ethernet boot mode as the default build falcon mode and > environment on MMC is defined for ethernet boot mode > environment should be set to nowhere. > > Signed-off-by: Mugunthan V N The same comments apply here about re-using CONFIG_SPL_ETH_SUPPORT (and then only set CONFIG_SPL_NET_SUPPORT and anything else). -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] MinnowBoard Max uboot
Hi Simon, I have just picked up u-boot-2015.07-rc2 with your support for multiple CPUs on the minnowboard max. I can see using the uboot cpu list command that both CPUs now show up. But the kernel does not see 2 CPUs in /proc/cpuinfo. If I boot the same kernel using an EFI BIOS I do see 2 CPUs in /proc/cpuinfo. Is there some uboot to kernel hand off I do not have configured properly ? I am not sure how the number of CPUs gets transferred from the boot to the kernel. Thanks for any input you may have. Tom => cpu list 0: cpu@0 Intel(R) Atom(TM) CPU E3825 @ 1.33GHz 1: cpu@1 Intel(R) Atom(TM) CPU E3825 @ 1.33GHz ## minnow max when booted from uboot 2015-07.rc2 root@atom_230:~# cat /proc/cpuinfo | grep processor processor : 0 ## minnow max when booted from BIOS root@atom_230:~# cat /proc/cpuinfo | grep processor processor : 0 processor : 1 -Original Message- From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass Sent: Tuesday, March 10, 2015 1:21 PM To: Beaman, Thomas Cc: u-boot@lists.denx.de; Bin Meng; gabriel huau Subject: Re: MinnowBoard Max uboot Hi Tom, On 10 March 2015 at 05:24, Beaman, Thomas wrote: > Hi Simon, > > Do you know what will be the timeframe of when someone may be able to > look at this in more detail. I will be able to help test any updates > if needed > I will take a look once I have things lined up for the next release, likely mid April. Regards, Simon > Thanks, > Tom > > -Original Message- > From: s...@google.com [mailto:s...@google.com] On Behalf Of Simon Glass > Sent: Monday, March 09, 2015 11:49 AM > To: Beaman, Thomas > Cc: u-boot@lists.denx.de; Bin Meng; gabriel huau > Subject: Re: MinnowBoard Max uboot > > +Bin and Gabriel > > Hi Tom, > > On 9 March 2015 at 08:08, Beaman, Thomas wrote: >> >> >> Hi Simon, >> >> >> >> I see you have put support for the MinnowBoard Max in the u-boot mainline. >> Thanks this is a very useful addition. I have been able to follow >> your readme and build a working bare metal uboot. Using the built >> uboot I can load and bring up a Linux Kernel. >> >> >> >> What I noticed from the running kernel is that only one of the two >> cores on the E3825 is running. In the power PC uboots I usually see a >> section for the multiple cores in the .dts file. My questions is how >> do I get both CPUs running on this board. Is it a uboot .dts file >> setup that will enable this, or is something in the kernel start up that >> does this. >> >> >> >> As a test I boot the same kernel using the EFI BIOS on the minnow >> board and both CPUs are running. >> >> >> >> Any suggestions or comments you have would be welcomed. >> >> > > My guess is that the LAPIC CPU start-up is missing. It isn't 100% clear what > the FSP does and does not do, but perhaps it does not do that. > > I did make something of a start on this with ivybridge but it isn't complete, > and it seems to be needed here. > > Regards, > Simon ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] ARM: cache: add an empty stub function for invalidate/flush dcache
On Wed, Jun 10, 2015 at 05:49:54PM +0800, Josh Wu wrote: > On 6/9/2015 9:11 PM, Tom Rini wrote: > >On Tue, Jun 09, 2015 at 11:54:14AM +0800, Josh Wu wrote: > >>Hi, Tom > >> > >>On 6/8/2015 9:20 PM, Tom Rini wrote: > >>>On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote: > On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote: > >Hi, Marek > > > >On 6/5/2015 9:18 PM, Marek Vasut wrote: > >>On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote: > >>>Since some driver like ohci, lcd used dcache functions. But some ARM > >>>cpu don't implement the invalidate_dcache_range()/flush_dcache_range() > >>>functions. > >>> > >>>To avoid compiling errors this patch adds an weak empty stub function > >>>for all ARM cpu. > >>> > >>>And each cpu can implement its own implementation. If not implemented > >>>by default it will use an empty function. > >>> > >>>Signed-off-by: Josh Wu > >>>--- > >>> > >>>Changes in v2: new added > >>> > >>> arch/arm/lib/cache.c | 9 + > >>> 1 file changed, 9 insertions(+) > >>So, why exactly can't this be entirely common code , but a CPU-specific > >>code ? :) > >Do you mean to make those empty functions as common code for all arch > >cpu to use? > Yes. > > >It seems there is no place to put common code for all arch cpu. > Isn't that what the common/ directory is for ? ;-) > >>>No, this is making something common for the sake of making it common > >>>rather than good architecutre of the code I think. We aren't going to > >>>share real cache functions just these dummy ones. > >>So it is the right place: arch/arm/lib/cache.c to put the dummy > >>cache function. > >Yes. > > > >>>We may re-evaluate > >>>our dummy ones at some point in the future when people try and use some > >>>particular combination harder, see for example the PowerPC dummy cache > >>>functions we just recently dropped. Thanks! > >>If this patch set are ok for you. I will sent more patches to drop > >>the dummy cache functions in /cpu/ folders. > >Right, that's the best palce I think, baring an existing arch having a > >location for weak cache functions already (like arm does). > > > >>Also the flush_cache() in arch/arm/lib/cache.c can be dropped and > >>just call flush_dcache_range() as the ARM1136, ARM926ejs alreay > >>implemented their own flush_cache(). > >Nope, other things fail if you do that (vpac270_nor_256 and 24 others at > >least so far in my test build). > > Does it fail to compile or on running? As I don't have the board to > test the binary, but I don't find any compile error when I apply > such a patch. It was a link failure for me when I just dropped flush_cache() from arch/arm/lib/cache.c -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Make RBTREE selectable by Kconfig
Hi Lars, On Wed, Jun 10, 2015 at 10:08 AM, Lars Poeschel wrote: > On Wed, Jun 10, 2015 at 08:49:28AM -0500, Joe Hershberger wrote: >> Hi Lars, >> >> On Wed, Jun 10, 2015 at 3:40 AM, Lars Poeschel wrote: >> > Users who want to use RBTREE can now select it by Kconfig. >> > Selecting it by board config include is still possible. >> > >> > Signed-off-by: Lars Poeschel >> > --- >> >> I beat you to it: http://lists.denx.de/pipermail/u-boot/2015-May/214261.html > > Well, ... ok. You won ;-) Your patchset is by far more comprehensive than > mine. > If I see this right in the archives, you did not receive any comments > since nearly a month. That is true. I really would like a little feedback on it... or maybe I can just drop the controversial one and only include these things... they seem to be mostly straightforward. > This was RFC will you resend this as a "real" PATCH ? Yes. > Could you then include two of the dependencies from my patches: > I think CMD_UBI has to depend on MTD_PARTITIONS and obivously CMD_UBIFS > has to depend on CMD_UBI. Will do. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Make RBTREE selectable by Kconfig
On Wed, Jun 10, 2015 at 08:49:28AM -0500, Joe Hershberger wrote: > Hi Lars, > > On Wed, Jun 10, 2015 at 3:40 AM, Lars Poeschel wrote: > > Users who want to use RBTREE can now select it by Kconfig. > > Selecting it by board config include is still possible. > > > > Signed-off-by: Lars Poeschel > > --- > > I beat you to it: http://lists.denx.de/pipermail/u-boot/2015-May/214261.html Well, ... ok. You won ;-) Your patchset is by far more comprehensive than mine. If I see this right in the archives, you did not receive any comments since nearly a month. This was RFC will you resend this as a "real" PATCH ? Could you then include two of the dependencies from my patches: I think CMD_UBI has to depend on MTD_PARTITIONS and obivously CMD_UBIFS has to depend on CMD_UBI. Thanks, Lars ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH v2] usb.h: Always declare usb function prototypes
There is no harm in declaring the function prototypes even if nothing
implements them, and when CONFIG_DM_USB=y the various usb functions are
available regardless of any controller drivers being enabled.
This fixes compile warnings due to missing prototypes on ARCHs where
the ARCH Kconfig always enables CONFIG_DM_USB and various usb drivers.
One could argue that in the case of no controllers CONFIG_DM_USB should not
be set, but this problem is typically seen during bringup of boards which
do actually have usb controllers.
Signed-off-by: Hans de Goede
---
Changes in v2:
-Simply always define the function prototypes instead of adding yet another
condition to the already unwieldly #if def ... || def ... condition
---
include/usb.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/include/usb.h b/include/usb.h
index c709ce2..dca512d 100644
--- a/include/usb.h
+++ b/include/usb.h
@@ -171,17 +171,6 @@ enum usb_init_type {
* this is how the lowlevel part communicate with the outer world
*/
-#if defined(CONFIG_USB_UHCI) || defined(CONFIG_USB_OHCI) || \
- defined(CONFIG_USB_EHCI) || defined(CONFIG_USB_OHCI_NEW) || \
- defined(CONFIG_USB_SL811HS) || defined(CONFIG_USB_ISP116X_HCD) || \
- defined(CONFIG_USB_R8A66597_HCD) || defined(CONFIG_USB_DAVINCI) || \
- defined(CONFIG_USB_OMAP3) || defined(CONFIG_USB_DA8XX) || \
- defined(CONFIG_USB_BLACKFIN) || defined(CONFIG_USB_AM35X) || \
- defined(CONFIG_USB_MUSB_DSPS) || defined(CONFIG_USB_MUSB_AM35X) || \
- defined(CONFIG_USB_MUSB_OMAP2PLUS) || defined(CONFIG_USB_MUSB_SUNXI) ||
\
- defined(CONFIG_USB_XHCI) || defined(CONFIG_USB_DWC2) || \
- defined(CONFIG_USB_EMUL)
-
int usb_lowlevel_init(int index, enum usb_init_type init, void **controller);
int usb_lowlevel_stop(int index);
@@ -216,12 +205,8 @@ void *poll_int_queue(struct usb_device *dev, struct
int_queue *queue);
* in boards init functions e.g. udc_disconnect() used for
* forced device disconnection from host.
*/
-#elif defined(CONFIG_USB_GADGET_PXA2XX)
-
extern void udc_disconnect(void);
-#endif
-
/*
* board-specific hardware initialization, called by
* usb drivers and u-boot commands
--
2.4.2
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Please pull u-boot-sunxi master
On Wed, Jun 10, 2015 at 04:54:50PM +0200, Hans de Goede wrote: > Hi Tom, > > Please pull u-boot-sunxi/master into master for 2 small bug-fixes: > > The following changes since commit 3d0158ae18bef2ac89979f4c90419d3add436c71: > > Prepare v2015.07-rc2 (2015-06-08 17:48:33 -0400) > > are available in the git repository at: > > http://git.denx.de/u-boot-sunxi.git master > > for you to fetch changes up to 0751b138064db28f0866f0c2439afb8b3975180c: > > sunxi: Enable CONFIG_SYS_64BIT_LBA when AHCI is used (2015-06-10 16:52:12 > +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Please pull u-boot-sunxi master
Hi Tom, Please pull u-boot-sunxi/master into master for 2 small bug-fixes: The following changes since commit 3d0158ae18bef2ac89979f4c90419d3add436c71: Prepare v2015.07-rc2 (2015-06-08 17:48:33 -0400) are available in the git repository at: http://git.denx.de/u-boot-sunxi.git master for you to fetch changes up to 0751b138064db28f0866f0c2439afb8b3975180c: sunxi: Enable CONFIG_SYS_64BIT_LBA when AHCI is used (2015-06-10 16:52:12 +0200) Bernhard Nortmann (1): sunxi: Enable CONFIG_SYS_64BIT_LBA when AHCI is used Hans de Goede (1): sunxi: Request macpwr gpio before using it arch/arm/cpu/armv7/sunxi/board.c | 1 + include/configs/sunxi-common.h | 1 + 2 files changed, 2 insertions(+) Regards, Hans ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Pull request: u-boot-tegra/master
On Tue, Jun 09, 2015 at 10:06:57AM -0700, Tom Warren wrote: > Tom, > > Please pull u-boot-tegra/master into U-Boot/master. Thanks! > > ./MAKEALL -s tegra is OK, nyan-big verified by Simon. > > The following changes since commit 3d0158ae18bef2ac89979f4c90419d3add436c71: > > Prepare v2015.07-rc2 (2015-06-08 17:48:33 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-tegra.git master > > for you to fetch changes up to b7160fabf11f423e879ee9cdcf8f7d0de7964509: > > tegra: config: nyan-big: Add options required by Chrome OS boot > (2015-06-09 09:56:16 -0700) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PULL] u-boot-avr32/master -> u-boot/master
On Wed, Jun 10, 2015 at 02:12:19PM +0200, Andreas Bießmann wrote: > Hi Tom, > > this pull request finally removes avr32 specific board.c code and all > unmaintained boards that used it. > > The following changes since commit 3d0158ae18bef2ac89979f4c90419d3add436c71: > > Prepare v2015.07-rc2 (2015-06-08 17:48:33 -0400) > > are available in the git repository at: > > git://git.denx.de/u-boot-avr32.git master > > for you to fetch changes up to b5614f9a7fb25521823a84fc0e4b5bb21dc45331: > > avr32: delete ancient board.c (2015-06-10 14:03:26 +0200) > Applied to u-boot/master, thanks! -- Tom signature.asc Description: Digital signature ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 03/13] drivers/fsl-mc: Autoload AOIP image from NOR flash
On 06/10/2015 03:39 AM, Prabhakar Kushwaha wrote: > From: "J. German Rivera" > > Load AIOP image from NOR flash into DDR so that the MC firmware > the MC fw can start it at boot time > > Signed-off-by: J. German Rivera > Signed-off-by: Prabhakar Kushwaha Prabhakar, Do we need this feature? It was written for bring-up. AIOP image should be loaded by Linux later for normal use. York ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 2/2] net: Add support for Marvell 88E1510 PHY
Hi Clemens, On Sat, Jun 6, 2015 at 7:44 AM, Clemens Gruber wrote: > Support the 88E1510 PHY which is very similar to the 88E1518. > I also set the INTn output and configured the LEDs. > > Signed-off-by: Clemens Gruber > Cc: Joe Hershberger > Cc: Hao Zhang > Cc: Michal Simek > > --- > This replaces the previously sent patch > http://patchwork.ozlabs.org/patch/478488/ > --- Acked-by: Joe Hershberger I'll pull this into the u-boot-net tree. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] ti: am335x/am437x/omap5 devices: Fix breakage when CONFIG_CMD_NET is not used
On Wed, Jun 10, 2015 at 08:54:02AM -0500, Franklin S Cooper Jr wrote:
> Currently there is no default value for NETARGS if CONFIG_CMD_NET=y isn't set.
> This results in build errors which was first discovered when trying to run
> make env.
>
> By defining a blank NETARGS these errors can be avoided.
>
> Signed-off-by: Franklin S Cooper Jr
> ---
> include/configs/ti_armv7_common.h | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/configs/ti_armv7_common.h
> b/include/configs/ti_armv7_common.h
> index f882942..d1c390f 100644
> --- a/include/configs/ti_armv7_common.h
> +++ b/include/configs/ti_armv7_common.h
> @@ -301,7 +301,8 @@
> "run netloadfdt; " \
> "run netargs; " \
> "bootz ${loadaddr} - ${fdtaddr}\0"
> -
> +#else
> +#define NETARGS ""
> #endif
>
> #endif /* __CONFIG_TI_ARMV7_COMMON_H__ */
> --
Build tested for am335x_evm, am43xx_evm and omap5_uevm.
Tested-by: Maxin B. John
Best Regards,
Maxin
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/2] net: Improve 88E151x PHY initialization
Hi Clemens, On Sat, Jun 6, 2015 at 7:44 AM, Clemens Gruber wrote: > - The EEE fixup magic should also be enabled for RGMII > - Improved comments > > Signed-off-by: Clemens Gruber > Cc: Joe Hershberger > Cc: Hao Zhang > Cc: Michal Simek > --- Acked-by: Joe Hershberger I'll pull this into the u-boot-net tree. Cheers, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] net: davinci_emac: don't teardown inactive rx channel
Hi Jeroen, On Sun, Jun 7, 2015 at 10:30 AM, Jeroen Hofstee wrote: > Tearing down an unitialized rx channel causes a pending address hole > event to be queued. When booting linux it will report this pending > as something like "Address Hole seen by USB_OTG at address 57fff584", > since u-boot did not handled this interrupt. Prevent that by not > tearing down the rx channel, when not receiving. > > Signed-off-by: Jeroen Hofstee > --- > To replicate this: > - ROMcode must not use the emac > - U-Boot must use the emac > - only on cold start > --- I don't know the hardware, but it sounds like a reasonable explanation. Look good to you, Tony? Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] moveconfig: Add a new --git-ref option
Hi Masahiro-san, On Thu, Jun 4, 2015 at 11:54 PM, Masahiro Yamada wrote: > Hi Joe, > > > 2015-05-30 6:23 GMT+09:00 Joe Hershberger : >> This option allows the 'make *_defconfig' step to run against a former >> repo state, while the savedefconfig step runs against the current repo >> state. This is convenient for the case where something in the Kconfig >> has changed such that the defconfig is no longer complete with the new >> Kconfigs. This feature allows the .config to be built assuming those old >> Kconfigs, but then savedefconfig based on the new state of the Kconfigs. >> >> Signed-off-by: Joe Hershberger > > > This idea seems nice, but I have some comments about the implementation. > > > >> +defconfig_src_dir = '' >> + >> +if options.git_ref: >> +work_dir = WorkDir() >> +defconfig_src_dir = work_dir.get() >> +cwd = os.getcwd() >> +print 'Cloning git repo for \'make *_defconfig\' step...' > > You can use signle quotes without escape sequences inside "...", and vice > versa. OK >> diff --git a/tools/patman/gitutil.py b/tools/patman/gitutil.py >> index 9e739d8..138f989 100644 >> --- a/tools/patman/gitutil.py >> +++ b/tools/patman/gitutil.py >> @@ -61,6 +61,21 @@ def CountCommitsToBranch(): >> patch_count = int(stdout) >> return patch_count >> >> +def CommitHash(commit_ref): >> +"""Gets the hash for a commit >> + >> +Args: >> +commit_ref: Commit ref to look up >> + >> +Return: >> +Hash of revision, if any, else None >> +""" >> +pipe = ['git', 'rev-parse', '--short', commit_ref] >> +stdout = command.RunPipe([pipe], capture=True, oneline=True).stdout >> + >> +hash = stdout.strip() >> +return hash >> + >> def NameRevision(commit_hash): >> """Gets the revision name for a commit > > > > Finally, this tool is going to depend on patman. I am afraid this > tool is getting messy. > > gitutils.py depends on command.py, and then command.py depends on > cros_subprocess.py. > > Do you really need to invoke such a chain of libraries > to run a sub-process? Why does that matter? > For example, you can get a hash in a single line like this: > > subprocess.check_output(['git', 'rev-parse', '--short', 'HEAD']) I certainly can do that, but it seems better to reuse the common functionality. This tool doesn't seem so useful elsewhere that a person would want it to work easily outside of u-boot. In u-boot, patman exists. Simon did the same thing for buildman. I can change it to call the git commands directly sine what I'm doing is simple, but I don't see any value in doing it. Simon, what do you think? Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 0/6] Remove sh boards that we have no tool-chain for.
Hi Masahiro-san, On Sat, Jun 6, 2015 at 8:09 AM, Masahiro Yamada wrote: > Hi Joe, > > > > 2015-05-11 17:40 GMT+09:00 Phil Edworthy : >> Hi Joe, >> >>> -Original Message- >>> From: U-Boot [mailto:u-boot-boun...@lists.denx.de] On Behalf Of Joe >>> Hershberger >>> Sent: 10 May 2015 21:23 >>> To: u-boot@lists.denx.de >>> Cc: Rob Herring; Thierry Reding; Stephen Warren; Joe Hershberger; Hisashi >>> Nakamura; Masahiro Yamada; Tom Rini; York Sun; Stefan Roese >>> Subject: [U-Boot] [PATCH 0/6] Remove sh boards that we have no tool-chain >>> for. >>> >>> >>> These 6 boards are the last that cannot be built with a public >>> configuration of tool-chains. Remove them. This includes the SH2 and SH3 >>> cpus, which are the actual cause for not being able to build these >>> boards. >> I haven't been keeping an eye on the ml, so didn't see the mails about this. >> For the sh2a boards, the last toolchain I used was an old CodeSourcery one >> from 2011 that can be downloaded from >> http://sourcery.mentor.com/public/gnu_toolchain/sh-uclinux/ >> >>> They can always be added back if the situation changes. >> I haven't built any sh2a targets for years and I suspect no one else has >> either, sh3 is probably even less used. Personally, I think it makes sense >> to remove all support for sh2a and sh3 now. > > > I attended an interesting talk at LinuxCon Japan 2015. > > I realized there is on-going movement to leverage patent-free sh2 processor. > > Visit this for the abstract: > http://lccojapan2015.sched.org/event/860288ccda595208a5d7337d31c6075c?iframe=no&w=i:0;&sidebar=yes&bg=no#.VXLwxlXtlBd > > > I recommend to keep sh2 support for U-Boot now and keep an eye on this > activity. > > > Anyway, you can build all the sh2 boards with the sourcery toolchain, > so your motivation to delete them is lost. Sounds good. -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH] sunxi: Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default
Hi Tom, On Fri, Jun 5, 2015 at 11:25 AM, Tom Rini wrote: > On Fri, Jun 05, 2015 at 01:02:16PM +0900, Masahiro Yamada wrote: >> Hi Joe, >> >> >> 2015-06-05 2:54 GMT+09:00 Joe Hershberger : >> > Hi Masahiro-san, >> > >> > On Thu, Jun 4, 2015 at 12:29 PM, Masahiro Yamada >> > wrote: >> >> Hi. >> >> >> >> >> >> 2015-06-04 7:55 GMT+09:00 Joe Hershberger : >> >>> On Wed, Jun 3, 2015 at 5:26 PM, Tom Rini wrote: >> On Wed, Jun 03, 2015 at 05:21:44PM -0500, Joe Hershberger wrote: >> > Hi Tom, >> > >> > On Wed, Jun 3, 2015 at 5:12 PM, Tom Rini wrote: >> > > On Wed, Jun 03, 2015 at 08:12:16PM +0200, Hans de Goede wrote: >> > > >> > >> Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default rather then >> > >> needing to have this in every sunxi defconfig file. >> > >> >> > >> This also fixes the Merrii_A80_Optimus defconfig no longer building. >> > >> >> > >> Cc: Maxin B. John >> > >> Reported-by: Maxin B. John >> > >> Signed-off-by: Hans de Goede >> > > >> > > Joe? Masahiro? It feels like something has gone wrong with the >> > > conversion here. Or do people need to get used to the defconfig >> > > files >> > > being a non-trivial size? Or do we need some more default y if ... >> > > lines around things? Or a few of the above? Thanks! >> >> >> >> >> >> I think too much (ab)use of "default y if ..." in board Kconfigs is wrong. >> > >> > I completely agree. I'd like to see them all go away, but maybe that's >> > just me. Doing this even causes the help for the option to incorrectly >> > indicate where that token is defined - it indicates the first default >> > setting inside some arch that's not even yours and not the real >> > definition location. >> >> Joe, you are not alone. > > I hope that we can largely move away from "default y if ..." in the long > term but still have "default y" (because it can be set to off). > >> I see another problem for adding default entries to board Kconfigs. >> >> If you see commit ece26f623c93afe95821f89d4dd53ae8f3cfa1b6, >> you will notice CONFIG_NET=y and CONFIG_NET_RANDOM_ETHADDR=y >> were added to separate places in defconfig files. >> (Please note the defconfigs were sorted by savedefconfig.) >> >> They should have been lined up together because their real definitions >> are placed in net/Kconfig. >> >> At the point when I posted the patch, board/sunxi/Kconfig had the >> default setting: >> >> config NET >> default y >> >> so savedefconfig put CONFIG_NET=y much earlier than it should be. >> >> >> Periodical attempt for cleaning defconfigs by savedefconfig comes to nothing >> because the order changes every single time someone adds a default >> entry into his board Kconfig. > > I think what we're seeing here is the conflicts between "we do not want > to enable many things by default", "we do not want to suddenly break > users" and "we do not want super huge defconfigs". This reordering issue makes it much worse of a problem. I think we should simply disallow it completely. I can make a patch that removes all of them and updates their defconfigs to include the configs. >> > It seems we should select good defaults. Maybe we should try to agree >> > which way we should err. Make u-boot bigger by default, and boards >> > that are limited can disable features? Or should we enable commands on >> > boards that "need" a feature and keep u-boot slim by default? >> > >> > I don't like the half measure of defining a different default for one >> > platform than another unless it is actually something inherent in the >> > platform, and in that case it should be enabled by a "selects" under >> > the platform Kconfig. >> > >> > I agree we want to have smaller defconfigs rather than bigger, but >> > there are lots of features and many boards will not agree, so the >> > defconfigs of many boards will have to contain something. >> >> The first thing that pops to mind is that if it used to be in >> config_cmd_default.h it should be on by default and disabled when needed >> (and this means we can be smart about CMD_FLASH / CMD_IMLS). Otherwise >> we need to think hard on if something new should be on by default or >> not. >> >>> >> >>> I have the gut feeling that things that depend on hardware existing >> >>> (such as CMD_NET) should not be default. However, I guess if it's >> >>> totally ubiquitous (such as CMD_MEMORY - though it's already in >> >>> config_cmd_default.h) then it should be default just to shrink the >> >>> defconfigs. >> >> >> >> >> >> Even if your board has a network device, >> >> you may not want to enable it by default in some cases. >> > >> > This is the reason for not making it a platform "selects X_FEATURE", >> > but defaults are just that. >> > >> >> Network functions are often useful during development and debugging, >> >> but might not for mass-production, for example. >> > >> > Do you thin
Re: [U-Boot] [PATCH] sunxi: Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default
Hi Masahiro-san, On Thu, Jun 4, 2015 at 11:02 PM, Masahiro Yamada wrote: > Hi Joe, > > > 2015-06-05 2:54 GMT+09:00 Joe Hershberger : >> Hi Masahiro-san, >> >> On Thu, Jun 4, 2015 at 12:29 PM, Masahiro Yamada >> wrote: >>> Hi. >>> >>> >>> 2015-06-04 7:55 GMT+09:00 Joe Hershberger : On Wed, Jun 3, 2015 at 5:26 PM, Tom Rini wrote: > On Wed, Jun 03, 2015 at 05:21:44PM -0500, Joe Hershberger wrote: >> Hi Tom, >> >> On Wed, Jun 3, 2015 at 5:12 PM, Tom Rini wrote: >> > On Wed, Jun 03, 2015 at 08:12:16PM +0200, Hans de Goede wrote: >> > >> >> Select CONFIG_CMD_NET and CONFIG_CMD_SETEXPR by default rather then >> >> needing to have this in every sunxi defconfig file. >> >> >> >> This also fixes the Merrii_A80_Optimus defconfig no longer building. >> >> >> >> Cc: Maxin B. John >> >> Reported-by: Maxin B. John >> >> Signed-off-by: Hans de Goede >> > >> > Joe? Masahiro? It feels like something has gone wrong with the >> > conversion here. Or do people need to get used to the defconfig files >> > being a non-trivial size? Or do we need some more default y if ... >> > lines around things? Or a few of the above? Thanks! >>> >>> >>> I think too much (ab)use of "default y if ..." in board Kconfigs is wrong. >> >> I completely agree. I'd like to see them all go away, but maybe that's >> just me. Doing this even causes the help for the option to incorrectly >> indicate where that token is defined - it indicates the first default >> setting inside some arch that's not even yours and not the real >> definition location. > > Joe, you are not alone. > > I see another problem for adding default entries to board Kconfigs. > > If you see commit ece26f623c93afe95821f89d4dd53ae8f3cfa1b6, > you will notice CONFIG_NET=y and CONFIG_NET_RANDOM_ETHADDR=y > were added to separate places in defconfig files. > (Please note the defconfigs were sorted by savedefconfig.) > > They should have been lined up together because their real definitions > are placed in net/Kconfig. > > At the point when I posted the patch, board/sunxi/Kconfig had the > default setting: > > config NET > default y > > so savedefconfig put CONFIG_NET=y much earlier than it should be. > > > Periodical attempt for cleaning defconfigs by savedefconfig comes to nothing > because the order changes every single time someone adds a default > entry into his board Kconfig. I had not noticed that, but it's an even more compelling reason to simply disallow it entirely. >> It seems we should select good defaults. Maybe we should try to agree >> which way we should err. Make u-boot bigger by default, and boards >> that are limited can disable features? Or should we enable commands on >> boards that "need" a feature and keep u-boot slim by default? >> >> I don't like the half measure of defining a different default for one >> platform than another unless it is actually something inherent in the >> platform, and in that case it should be enabled by a "selects" under >> the platform Kconfig. >> >> I agree we want to have smaller defconfigs rather than bigger, but >> there are lots of features and many boards will not agree, so the >> defconfigs of many boards will have to contain something. > > The first thing that pops to mind is that if it used to be in > config_cmd_default.h it should be on by default and disabled when needed > (and this means we can be smart about CMD_FLASH / CMD_IMLS). Otherwise > we need to think hard on if something new should be on by default or > not. I have the gut feeling that things that depend on hardware existing (such as CMD_NET) should not be default. However, I guess if it's totally ubiquitous (such as CMD_MEMORY - though it's already in config_cmd_default.h) then it should be default just to shrink the defconfigs. >>> >>> >>> Even if your board has a network device, >>> you may not want to enable it by default in some cases. >> >> This is the reason for not making it a platform "selects X_FEATURE", >> but defaults are just that. >> >>> Network functions are often useful during development and debugging, >>> but might not for mass-production, for example. >> >> Do you think many (or any) boards are mass-produced based on the >> main-line defconfigs? > > No, I think they are mostly for development boards. > > Anyway, U-boot without network makes sense. For sure! Ian, you indicated that you thought CMD_NET should be a default since it is usually wanted. It seems that is generally the case. It looks like 94% of boards enable CMD_NET, which makes it pretty much ubiquitous. Perhaps that should be the metric for deciding (probably with flexibility for making an argument to the contrary)... if more that 80% (good enough water-mark?) of the boards enable a feature, then it should be the default? 50% would op
Re: [U-Boot] Compilation of env error u-boot 2015.07-rc2
> -Original Message- > From: Maxin B. John [mailto:maxin.j...@enea.com] > Sent: Wednesday, June 10, 2015 4:10 AM > To: Thirumalesha N > Cc: u-boot@lists.denx.de; Cooper Jr., Franklin; tr...@konsulko.com > Subject: Re: [U-Boot] Compilation of env error u-boot 2015.07-rc2 > > Hi, > > On Wed, Jun 10, 2015 at 10:29:47AM +0530, Thirumalesha N wrote: > > Hi all, > > > > I have pulled latest code from u-boot main line through git. > > > > Using linaro tool chain for am335x board > > > > I'm trying to compile tools/env but its giving an error > > > > #make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- env > > > > HOSTCC tools/env/fw_env.o > > > > arm-linux-gnueabihf/include/search.h:173:1 erro: expected '}' before > > 'NETARGS' > > make[1]: *** [ tools/env/few.env.o] error 1 > > I have managed to re-create the same problem. > > Revert this commit: 2320866b978fc12904eeba37236f35d12b4aec30 > ie: > # git revert 2320866b978fc12904eeba37236f35d12b4aec30 > > and then try building again. > > Apparently network arguments were moved to ti_armv7_common.h. > However, it wasn't included in the am335x config. [Franklin] I haven't used make env before but from my understanding there is no config for it. The other configs for am335x that I saw all had CONFIG_CMD_NET enabled. So I'm guessing that when doing make env CONFIG_CMD_NET isn't enabled which is why we get that error. I just sent a patch that fixed this error. > > > > > With same tool chain I'm able compile 2014 u-boot > > > > Regards, > > Thiru N > > Best Regards, > Maxin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [RFC PATCH v1] README: Describe CONFIG_SYS_NO_FLASH
On 10.06.2015 12:06, Chris Packham wrote: Unlike most configuration options defining this actually disables support for a feature (parallel flash). Eventually the logic behind this should probably be flipped so that '#ifndef CONFIG_SYS_NO_FLASH' becomes '#ifdef CONFIG_HAS_PARALLEL_FLASH' Yes, this should be the ultimate goal. But definitely a quite complex task. but for now lets document the existing behaviour. Ack. Signed-off-by: Chris Packham Reviewed-by: Stefan Roese Thanks, Stefan ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ti: am335x/am437x/omap5 devices: Fix breakage when CONFIG_CMD_NET is not used
Currently there is no default value for NETARGS if CONFIG_CMD_NET=y isn't set.
This results in build errors which was first discovered when trying to run
make env.
By defining a blank NETARGS these errors can be avoided.
Signed-off-by: Franklin S Cooper Jr
---
include/configs/ti_armv7_common.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/include/configs/ti_armv7_common.h
b/include/configs/ti_armv7_common.h
index f882942..d1c390f 100644
--- a/include/configs/ti_armv7_common.h
+++ b/include/configs/ti_armv7_common.h
@@ -301,7 +301,8 @@
"run netloadfdt; " \
"run netargs; " \
"bootz ${loadaddr} - ${fdtaddr}\0"
-
+#else
+#define NETARGS ""
#endif
#endif /* __CONFIG_TI_ARMV7_COMMON_H__ */
--
2.4.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/5] Make RBTREE selectable by Kconfig
Hi Lars, On Wed, Jun 10, 2015 at 3:40 AM, Lars Poeschel wrote: > Users who want to use RBTREE can now select it by Kconfig. > Selecting it by board config include is still possible. > > Signed-off-by: Lars Poeschel > --- I beat you to it: http://lists.denx.de/pipermail/u-boot/2015-May/214261.html Also, you need to use the tools/moveconfig.py tool to update the headers and defconfigs. So... NAK Thanks, -Joe ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,7/7] avr32: delete ancient board.c
Dear =?utf-8?q?Andreas_Bie=C3=9Fmann?=, Andreas Devel writes: >Signed-off-by: Andreas Bießmann >--- > > arch/avr32/lib/Makefile | 3 - > arch/avr32/lib/board.c | 256 > 2 files changed, 259 deletions(-) > delete mode 100644 arch/avr32/lib/board.c applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,6/7] avr32: take maintainership for atstk1002
Dear =?utf-8?q?Andreas_Bie=C3=9Fmann?=, Andreas Devel writes: >I have this board at work, so I can trun tests on it. > >Signed-off-by: Andreas Bießmann >--- > > board/atmel/atstk1000/MAINTAINERS | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,4/7] avr32: delete non generic board mimc200
Dear =?utf-8?q?Andreas_Bie=C3=9Fmann?=, Andreas Devel writes: >Signed-off-by: Andreas Bießmann >--- > arch/avr32/Kconfig | 4 - > board/mimc/mimc200/Kconfig | 15 > board/mimc/mimc200/MAINTAINERS | 6 -- > board/mimc/mimc200/Makefile| 6 -- > board/mimc/mimc200/mimc200.c | 197 - > configs/mimc200_defconfig | 3 - > include/configs/mimc200.h | 176 > 7 files changed, 407 deletions(-) > delete mode 100644 board/mimc/mimc200/Kconfig > delete mode 100644 board/mimc/mimc200/MAINTAINERS > delete mode 100644 board/mimc/mimc200/Makefile > delete mode 100644 board/mimc/mimc200/mimc200.c > delete mode 100644 configs/mimc200_defconfig > delete mode 100644 include/configs/mimc200.h applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,2/7] avr32: delete non generic board favr-32-ezkit
Dear =?utf-8?q?Andreas_Bie=C3=9Fmann?=, Andreas Devel writes: >Signed-off-by: Andreas Bießmann >--- > arch/avr32/Kconfig | 4 - > board/earthlcd/favr-32-ezkit/Kconfig | 15 -- > board/earthlcd/favr-32-ezkit/MAINTAINERS | 6 - > board/earthlcd/favr-32-ezkit/Makefile| 9 -- > board/earthlcd/favr-32-ezkit/favr-32-ezkit.c | 81 -- > board/earthlcd/favr-32-ezkit/flash.c | 216 --- > configs/favr-32-ezkit_defconfig | 7 - > include/configs/favr-32-ezkit.h | 171 - > 8 files changed, 509 deletions(-) > delete mode 100644 board/earthlcd/favr-32-ezkit/Kconfig > delete mode 100644 board/earthlcd/favr-32-ezkit/MAINTAINERS > delete mode 100644 board/earthlcd/favr-32-ezkit/Makefile > delete mode 100644 board/earthlcd/favr-32-ezkit/favr-32-ezkit.c > delete mode 100644 board/earthlcd/favr-32-ezkit/flash.c > delete mode 100644 configs/favr-32-ezkit_defconfig > delete mode 100644 include/configs/favr-32-ezkit.h applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,3/7] avr32: delete non generic board hammerhead
Dear =?utf-8?q?Andreas_Bie=C3=9Fmann?=, Andreas Devel writes: >Signed-off-by: Andreas Bießmann >--- > arch/avr32/Kconfig | 4 - > board/miromico/hammerhead/Kconfig | 15 > board/miromico/hammerhead/MAINTAINERS | 6 -- > board/miromico/hammerhead/Makefile | 6 -- > board/miromico/hammerhead/hammerhead.c | 91 > configs/hammerhead_defconfig | 7 -- > include/configs/hammerhead.h | 147 - > 7 files changed, 276 deletions(-) > delete mode 100644 board/miromico/hammerhead/Kconfig > delete mode 100644 board/miromico/hammerhead/MAINTAINERS > delete mode 100644 board/miromico/hammerhead/Makefile > delete mode 100644 board/miromico/hammerhead/hammerhead.c > delete mode 100644 configs/hammerhead_defconfig > delete mode 100644 include/configs/hammerhead.h applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [U-Boot,5/7] avr32: delete non generic board's atstk100{3, 4, 6}
Dear =?utf-8?q?Andreas_Bie=C3=9Fmann?=, Andreas Devel writes: >Signed-off-by: Andreas Bießmann >--- > arch/avr32/Kconfig| 9 -- > board/atmel/atstk1000/Kconfig | 48 --- > board/atmel/atstk1000/MAINTAINERS | 6 -- > board/atmel/atstk1000/atstk1000.c | 23 +- > configs/atstk1003_defconfig | 6 -- > configs/atstk1004_defconfig | 6 -- > configs/atstk1006_defconfig | 7 -- > include/configs/atstk1003.h | 150 -- > include/configs/atstk1004.h | 150 -- > include/configs/atstk1006.h | 168 -- > 10 files changed, 1 insertion(+), 572 deletions(-) > delete mode 100644 configs/atstk1003_defconfig > delete mode 100644 configs/atstk1004_defconfig > delete mode 100644 configs/atstk1006_defconfig > delete mode 100644 include/configs/atstk1003.h > delete mode 100644 include/configs/atstk1004.h > delete mode 100644 include/configs/atstk1006.h applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] atngw100: convert to generic board
Dear =?utf-8?q?Andreas_Bie=C3=9Fmann?=, Andreas Devel writes: >Signed-off-by: Andreas Bießmann >--- >Tested on an atngw100 thankfully provided by Waldemar. Thus >http://patchwork.ozlabs.org/patch/470705/ is not required. > > include/configs/atngw100.h |4 > 1 file changed, 4 insertions(+) applied to u-boot-avr32/master, thanks! Best regards, Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device
On Wednesday 10 June 2015 12:58:11 Paul Kocialkowski wrote: > Le mercredi 10 juin 2015 à 12:42 +0200, Pali Rohár a écrit : > > On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > > > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > > > I would be very glad to see board maintainers give a go > > > > > > > at the changeset before it gets merged, especially on devices like > > > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > > > (see other email thread). Until somebody fix that broken commit, I > > > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > > > > > Now I tested this patch series on top of u-boot master with applied > > > > > my > > > > > patch "Nokia RX-51: Fix calculating return address in > > > > > save_boot_params". > > > > > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > > > > > I'm confused here -- did you try booting on the actual device or in > > > > qemu? > > > > > > > > > > I tested your changes only in qemu. But because you removed (or better > > > masked) required lowlevel asm code, it will not work on real n900 too. > > > > > > > > So this patch series is NAK from my side. > > > > > > > > Thanks for testing. Of course, the point is to make another version of > > > > the patch set that fits the N900 too, since we really need to integrate > > > > the omap3 to the common omap boot mechanism anyways. > > > > > > > > > > Make sure that asm function in rx51 lowlevel asm file is called > > > immediately from start.S. It is required. Basically no modification to > > > that function should be needed (maybe just fixing return address in lr). > > The problem is that this declaration conflicts with the one from > omap-common's lowlevel_init.S. I understand that it is not needed for > the RX-51 since it is not loaded by the U-Boot SPL or by the bootrom. > Yes. > Perhaps the best way to do things here would be to have a config option > clearly stating that it should not expect the booting device information > structure in r0. This situation is not specific to the RX-51 anyways. > Sounds good. > > > > I may be able to get my hands on a N900 in a short while. > > > > > > Do you have n900 device? Or are you going to use qemu? > > > > > > Really, for development u-boot for n900 is easier to use qemu as you can > > > easier debug code... > > I didin't know it was possible, perhaps I'll try it. I have a friend who > owns a N900, I could certainly borrow it for a while to ensure that this > patch set goes smoothly on it. > Look at this email with information how to build u-boot and run in qemu: http://lists.denx.de/pipermail/u-boot/2015-January/200171.html > > > > If you're interested, you're welcome to look at the issue and suggest > > > > what changes should be made to make the set compatible with the N900! > > > > > > > > > > Do not hide/mask/remove that required asm function. That should be all. > > > And why is change to file board/nokia/rx51/lowlevel_init.S required? > > See my comment above. > -- Pali Rohár pali.ro...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device
Le mercredi 10 juin 2015 à 12:42 +0200, Pali Rohár a écrit : > On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > > I would be very glad to see board maintainers give a go > > > > > > at the changeset before it gets merged, especially on devices like > > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > > (see other email thread). Until somebody fix that broken commit, I > > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > > > I'm confused here -- did you try booting on the actual device or in > > > qemu? > > > > > > > I tested your changes only in qemu. But because you removed (or better > > masked) required lowlevel asm code, it will not work on real n900 too. > > > > > > So this patch series is NAK from my side. > > > > > > Thanks for testing. Of course, the point is to make another version of > > > the patch set that fits the N900 too, since we really need to integrate > > > the omap3 to the common omap boot mechanism anyways. > > > > > > > Make sure that asm function in rx51 lowlevel asm file is called > > immediately from start.S. It is required. Basically no modification to > > that function should be needed (maybe just fixing return address in lr). The problem is that this declaration conflicts with the one from omap-common's lowlevel_init.S. I understand that it is not needed for the RX-51 since it is not loaded by the U-Boot SPL or by the bootrom. Perhaps the best way to do things here would be to have a config option clearly stating that it should not expect the booting device information structure in r0. This situation is not specific to the RX-51 anyways. > > > I may be able to get my hands on a N900 in a short while. > > > > Do you have n900 device? Or are you going to use qemu? > > > > Really, for development u-boot for n900 is easier to use qemu as you can > > easier debug code... I didin't know it was possible, perhaps I'll try it. I have a friend who owns a N900, I could certainly borrow it for a while to ensure that this patch set goes smoothly on it. > > > If you're interested, you're welcome to look at the issue and suggest > > > what changes should be made to make the set compatible with the N900! > > > > > > > Do not hide/mask/remove that required asm function. That should be all. > And why is change to file board/nokia/rx51/lowlevel_init.S required? See my comment above. -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device
On Wednesday 10 June 2015 12:34:39 Pali Rohár wrote: > On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > > I would be very glad to see board maintainers give a go > > > > > at the changeset before it gets merged, especially on devices like > > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > > (see other email thread). Until somebody fix that broken commit, I > > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > > > Now I tested this patch series on top of u-boot master with applied my > > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > > > I'm confused here -- did you try booting on the actual device or in > > qemu? > > > > I tested your changes only in qemu. But because you removed (or better > masked) required lowlevel asm code, it will not work on real n900 too. > > > > So this patch series is NAK from my side. > > > > Thanks for testing. Of course, the point is to make another version of > > the patch set that fits the N900 too, since we really need to integrate > > the omap3 to the common omap boot mechanism anyways. > > > > Make sure that asm function in rx51 lowlevel asm file is called > immediately from start.S. It is required. Basically no modification to > that function should be needed (maybe just fixing return address in lr). > > > I may be able to get my hands on a N900 in a short while. > > Do you have n900 device? Or are you going to use qemu? > > Really, for development u-boot for n900 is easier to use qemu as you can > easier debug code... > > > If you're interested, you're welcome to look at the issue and suggest > > what changes should be made to make the set compatible with the N900! > > > > Do not hide/mask/remove that required asm function. That should be all. > And why is change to file board/nokia/rx51/lowlevel_init.S required? -- Pali Rohár pali.ro...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 13/13] driver/ldpaa_eth:Avoid infinite loop in QBMAN buf release
Change infinite loop mechanism to timer based polling.
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/ldpaa_eth/ldpaa_eth.c | 13 +++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index 839e78a..fe8f189 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -31,6 +31,8 @@ static void ldpaa_eth_rx(struct ldpaa_eth_priv *priv,
uint32_t fd_length;
struct ldpaa_fas *fas;
uint32_t status, err;
+ u32 timeo = (CONFIG_SYS_HZ * 2) / 1000;
+ u32 time_start;
struct qbman_release_desc releasedesc;
struct qbman_swp *swp = dflt_dpio->sw_portal;
@@ -65,10 +67,15 @@ 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);
+ time_start = get_timer(0);
do {
/* Release buffer into the QBMAN */
err = qbman_swp_release(swp, &releasedesc, &fd_addr, 1);
- } while (err == -EBUSY);
+ } while (get_timer(time_start) < timeo && err == -EBUSY);
+
+ if (get_timer(time_start) >= timeo)
+ printf("Rx frame: QBMAN buffer release fails\n");
+
return;
}
@@ -195,11 +202,13 @@ static int ldpaa_eth_tx(struct eth_device *net_dev, void
*buf, int len)
error:
qbman_release_desc_clear(&releasedesc);
qbman_release_desc_set_bpid(&releasedesc, dflt_dpbp->dpbp_attr.bpid);
+ time_start = get_timer(0);
do {
/* Release buffer into the QBMAN */
err = qbman_swp_release(swp, &releasedesc, &buffer_start, 1);
- } while (err == -EBUSY);
+ } while (get_timer(time_start) < timeo && err == -EBUSY);
+ printf("TX data: QBMAN buffer release fails\n");
return err;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 12/13] driver/ldpaa_eth: Avoid TX conf frames
Polling of TX conf frames is not a mandatory option.
Packets can be transferred via WRIOP without TX conf frame.
Configure ldpaa_eth driver to use TX path without confirmation frame
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/ldpaa_eth/ldpaa_eth.c | 114 ++
drivers/net/ldpaa_eth/ldpaa_eth.h | 1 -
2 files changed, 4 insertions(+), 111 deletions(-)
diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index adb964c..839e78a 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -112,7 +112,7 @@ static int ldpaa_eth_pull_dequeue_rx(struct eth_device *dev)
debug("No frame delivered\n");
qbman_swp_dqrr_consume(swp, dq);
- break;
+ continue;
}
fd = ldpaa_dq_fd(dq);
@@ -131,98 +131,6 @@ static int ldpaa_eth_pull_dequeue_rx(struct eth_device
*dev)
return err;
}
-static void ldpaa_eth_tx_conf(struct ldpaa_eth_priv *priv,
- const struct dpaa_fd *fd)
-{
- uint64_t fd_addr;
- struct ldpaa_fas *fas;
- uint32_t status, err;
- struct qbman_release_desc releasedesc;
- struct qbman_swp *swp = dflt_dpio->sw_portal;
-
- fd_addr = ldpaa_fd_get_addr(fd);
-
-
- debug("TX Conf frame:data addr=0x%p\n", (u64 *)fd_addr);
-
- /* Check the status from the Frame Annotation */
- if (fd->simple.frc & LDPAA_FD_FRC_FASV) {
- fas = (struct ldpaa_fas *)
- ((uint8_t *)(fd_addr) +
- priv->buf_layout.private_data_size);
- status = le32_to_cpu(fas->status);
- if (status & LDPAA_ETH_TXCONF_ERR_MASK) {
- printf("TxConf frame error(s): 0x%08x\n",
- status & LDPAA_ETH_TXCONF_ERR_MASK);
- }
- }
-
- 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 {
- /* Release buffer into the QBMAN */
- err = qbman_swp_release(swp, &releasedesc, &fd_addr, 1);
- } while (err == -EBUSY);
-}
-
-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;
- u32 timeo = (CONFIG_SYS_HZ * 10) / 1000;
- u32 time_start;
- static struct qbman_pull_desc pulldesc;
- struct qbman_swp *swp = dflt_dpio->sw_portal;
-
- 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;
- }
-
- time_start = get_timer(0);
-
-do {
- dq = qbman_swp_dqrr_next(swp);
- } while (get_timer(time_start) < timeo && !dq);
-
- if (dq) {
- /* Check for valid frame. If not sent a consume
-* confirmation to QBMAN otherwise give it to NADK
-* application and then send consume confirmation to
-* QBMAN.
-*/
- status = (uint8_t)ldpaa_dq_flags(dq);
- if ((status & LDPAA_DQ_STAT_VALIDFRAME) == 0) {
- debug("Dequeue TX conf frames:");
- debug("No frame is delivered\n");
-
- qbman_swp_dqrr_consume(swp, dq);
- break;
- }
- fd = ldpaa_dq_fd(dq);
-
- ldpaa_eth_tx_conf(priv, fd);
- qbman_swp_dqrr_consume(swp, dq);
- break;
- } else {
- err = -1;
- debug("No DQRR entries\n");
- break;
- }
- }
-
- return err;
-}
-
static int ldpaa_eth_tx(struct eth_device *net_dev, void *buf, int len)
{
struct ldpaa_eth_priv *priv = (struct ldpaa_eth_priv *)net_dev->priv;
@@ -282,12 +190,6 @@ static int ldpaa_eth_tx(struct eth_device *net_dev, void
*buf, int len)
if (err < 0)
goto error;
- mdelay(1);
-
- err = ldpaa_eth_pull_dequeue_tx_conf(priv);
- if (err < 0)
- printf("error Tx Conf frame\n");
-
return err;
error:
@@ -305,7 +207,6 @@ static int ldpaa_
[U-Boot] [PATCH 11/13] driver/ldpaa_eth: Add timeout handling DQRR entry read
Volatile command does not return frame immidiately, need to wait till a frame
is available in DQRR. Ideally it should be a blocking call.
Add timeout handling for DQRR frame instead of retry counter.
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/ldpaa_eth/ldpaa_eth.c | 36 ++--
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index 2716f6c..adb964c 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -77,7 +77,9 @@ 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, loop = 20;
+ int i = 5, err = 0, status;
+ u32 timeo = (CONFIG_SYS_HZ * 2) / 1000;
+ u32 time_start;
static struct qbman_pull_desc pulldesc;
struct qbman_swp *swp = dflt_dpio->sw_portal;
@@ -92,13 +94,11 @@ static int ldpaa_eth_pull_dequeue_rx(struct eth_device *dev)
continue;
}
- do {
- loop--;
- dq = qbman_swp_dqrr_next(swp);
+ time_start = get_timer(0);
- if (!loop)
- break;
- } while (!dq);
+do {
+ dq = qbman_swp_dqrr_next(swp);
+ } while (get_timer(time_start) < timeo && !dq);
if (dq) {
/* Check for valid frame. If not sent a consume
@@ -121,6 +121,10 @@ static int ldpaa_eth_pull_dequeue_rx(struct eth_device
*dev)
ldpaa_eth_rx(priv, fd);
qbman_swp_dqrr_consume(swp, dq);
break;
+ } else {
+ err = -1;
+ debug("No DQRR entries\n");
+ break;
}
}
@@ -167,7 +171,9 @@ 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, loop = 20;
+ int i = 5, status;
+ u32 timeo = (CONFIG_SYS_HZ * 10) / 1000;
+ u32 time_start;
static struct qbman_pull_desc pulldesc;
struct qbman_swp *swp = dflt_dpio->sw_portal;
@@ -182,13 +188,11 @@ static int ldpaa_eth_pull_dequeue_tx_conf(struct
ldpaa_eth_priv *priv)
continue;
}
- do {
- loop--;
- dq = qbman_swp_dqrr_next(swp);
+ time_start = get_timer(0);
- if (!loop)
- break;
- } while (!dq);
+do {
+ dq = qbman_swp_dqrr_next(swp);
+ } while (get_timer(time_start) < timeo && !dq);
if (dq) {
/* Check for valid frame. If not sent a consume
@@ -209,6 +213,10 @@ static int ldpaa_eth_pull_dequeue_tx_conf(struct
ldpaa_eth_priv *priv)
ldpaa_eth_tx_conf(priv, fd);
qbman_swp_dqrr_consume(swp, dq);
break;
+ } else {
+ err = -1;
+ debug("No DQRR entries\n");
+ break;
}
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 09/13] armv8/fsl-lsch3: device tree fixups for PCI stream IDs
From: Stuart Yoder
This patch adds the infrastructure to update device
tree nodes to convey SMMU stream IDs in the device
tree. Fixups are implemented for PCI controllers
initially.
Signed-off-by: Stuart Yoder
Signed-off-by: Prabhakar Kushwaha
---
arch/arm/cpu/armv8/fsl-lsch3/fdt.c| 108 ++
arch/arm/include/asm/arch-fsl-lsch3/fdt.h | 9 +++
drivers/pci/pcie_layerscape.c | 62 +
3 files changed, 179 insertions(+)
create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/fdt.h
diff --git a/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
b/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
index b9fd559..a9d96d8 100644
--- a/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
+++ b/arch/arm/cpu/armv8/fsl-lsch3/fdt.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_FSL_ESDHC
#include
#endif
@@ -58,6 +59,111 @@ void ft_fixup_cpu(void *blob)
}
#endif
+/*
+ * the burden is on the the caller to not request a count
+ * exceeding the bounds of the stream_ids[] array
+ */
+void alloc_stream_ids(int start_id, int count, u32 *stream_ids, int max_cnt)
+{
+ int i;
+
+ if (count > max_cnt) {
+ printf("\n%s: ERROR: max per-device stream ID count exceed\n",
+ __func__);
+ return;
+ }
+
+ for (i = 0; i < count; i++)
+ stream_ids[i] = start_id++;
+}
+
+/*
+ * This function updates the mmu-masters property on the SMMU
+ * node as per the SMMU binding-- phandle and list of stream IDs
+ * for each MMU master.
+ */
+void append_mmu_masters(void *blob, const char *smmu_path,
+ const char *master_name, u32 *stream_ids, int count)
+{
+ u32 phandle;
+ int smmu_nodeoffset;
+ int master_nodeoffset;
+ int i;
+
+ /* get phandle of mmu master device */
+ master_nodeoffset = fdt_path_offset(blob, master_name);
+ if (master_nodeoffset < 0) {
+ printf("\n%s: ERROR: master not found\n", __func__);
+ return;
+ }
+ phandle = fdt_get_phandle(blob, master_nodeoffset);
+ if (!phandle) { /* if master has no phandle, create one */
+ phandle = fdt_create_phandle(blob, master_nodeoffset);
+ if (!phandle) {
+ printf("\n%s: ERROR: unable to create phandle\n",
+ __func__);
+ return;
+ }
+ }
+
+ /* append it to mmu-masters */
+ smmu_nodeoffset = fdt_path_offset(blob, smmu_path);
+ if (fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
+ phandle) < 0) {
+ printf("\n%s: ERROR: unable to update SMMU node\n", __func__);
+ return;
+ }
+
+ /* for each stream ID, append to mmu-masters */
+ for (i = 0; i < count; i++) {
+ fdt_appendprop_u32(blob, smmu_nodeoffset, "mmu-masters",
+ stream_ids[i]);
+ }
+
+ /* fix up #stream-id-cells with stream ID count */
+ if (fdt_setprop_u32(blob, master_nodeoffset, "#stream-id-cells",
+ count) < 0)
+ printf("\n%s: ERROR: unable to update #stream-id-cells\n",
+ __func__);
+}
+
+
+/*
+ * The info below summarizes how streamID partitioning works
+ * for ls2085a and how it is conveyed to the OS via the device tree.
+ *
+ * -non-PCI legacy, platform devices (USB, SD/MMC, SATA, DMA)
+ * -all legacy devices get a unique ICID assigned and programmed in
+ * their AMQR registers by u-boot
+ * -u-boot updates the hardware device tree with streamID properties
+ * for each platform/legacy device (smmu-masters property)
+ *
+ * -PCIe
+ * -for each PCI controller that is active (as per RCW settings),
+ * u-boot will allocate a range of ICID and convey that to Linux via
+ * the device tree (smmu-masters property)
+ *
+ * -DPAA2
+ * -u-boot will allocate a range of ICIDs to be used by the Management
+ * Complex for containers and will set these values in the MC DPC image.
+ * -the MC is responsible for allocating and setting up ICIDs
+ * for all DPAA2 devices.
+ *
+ */
+static void fdt_fixup_smmu(void *blob)
+{
+ int nodeoffset;
+
+ nodeoffset = fdt_path_offset(blob, "/iommu@500");
+ if (nodeoffset < 0) {
+ printf("\n%s: WARNING: no SMMU node found\n", __func__);
+ return;
+ }
+
+ /* fixup for all PCI controllers */
+ fdt_fixup_smmu_pcie(blob);
+}
+
void ft_cpu_setup(void *blob, bd_t *bd)
{
#ifdef CONFIG_MP
@@ -76,4 +182,6 @@ void ft_cpu_setup(void *blob, bd_t *bd)
#if defined(CONFIG_FSL_ESDHC)
fdt_fixup_esdhc(blob, bd);
#endif
+
+ fdt_fixup_smmu(blob);
}
diff --git a/arch/arm/include/asm/arch-fsl-lsch3/fdt.h
b/arch/arm/include/asm/arch-fsl-lsch3/fdt.h
new file mode 100644
index 000..92b1e5f
--- /dev/null
+++
[U-Boot] [PATCH 10/13] driver/ldpaa_eth: Retry enqueue if portal was busy
Do not immediately return if the enqueue function returns -EBUSY; re-try
mulitple times.
if timeout occures, release the buffer.
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/ldpaa_eth/ldpaa_eth.c | 26 --
1 file changed, 24 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index 5636511..2716f6c 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -221,8 +221,11 @@ static int ldpaa_eth_tx(struct eth_device *net_dev, void
*buf, int len)
struct dpaa_fd fd;
u64 buffer_start;
int data_offset, err;
+ u32 timeo = (CONFIG_SYS_HZ * 10) / 1000;
+ u32 time_start;
struct qbman_swp *swp = dflt_dpio->sw_portal;
struct qbman_eq_desc ed;
+ struct qbman_release_desc releasedesc;
/* Setup the FD fields */
memset(&fd, 0, sizeof(fd));
@@ -258,9 +261,18 @@ static int ldpaa_eth_tx(struct eth_device *net_dev, void
*buf, int len)
qbman_eq_desc_clear(&ed);
qbman_eq_desc_set_no_orp(&ed, 0);
qbman_eq_desc_set_qd(&ed, priv->tx_qdid, priv->tx_flow_id, 0);
- err = qbman_swp_enqueue(swp, &ed, (const struct qbman_fd *)(&fd));
+
+ time_start = get_timer(0);
+
+ while (get_timer(time_start) < timeo) {
+ err = qbman_swp_enqueue(swp, &ed,
+ (const struct qbman_fd *)(&fd));
+ if (err != -EBUSY)
+ break;
+ }
+
if (err < 0)
- printf("error enqueueing Tx frame\n");
+ goto error;
mdelay(1);
@@ -269,6 +281,16 @@ static int ldpaa_eth_tx(struct eth_device *net_dev, void
*buf, int len)
printf("error Tx Conf frame\n");
return err;
+
+error:
+ qbman_release_desc_clear(&releasedesc);
+ qbman_release_desc_set_bpid(&releasedesc, dflt_dpbp->dpbp_attr.bpid);
+ do {
+ /* Release buffer into the QBMAN */
+ err = qbman_swp_release(swp, &releasedesc, &buffer_start, 1);
+ } while (err == -EBUSY);
+
+ return err;
}
static int ldpaa_eth_open(struct eth_device *net_dev, bd_t *bd)
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 08/13] drivers/fsl-mc: dynamically create ICID pool in DPC
From: Stuart Yoder
delete any existing ICID pools in the DPC and create
a new one based on the stream ID partitioning for
the SoC
Signed-off-by: Stuart Yoder
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/fsl-mc/mc.c | 36
1 file changed, 36 insertions(+)
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 8bb8f7b..2820883 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -3,8 +3,11 @@
*
* SPDX-License-Identifier:GPL-2.0+
*/
+#include
#include
#include
+#include
+#include
#include
#include
#include
@@ -185,6 +188,36 @@ static int calculate_mc_private_ram_params(u64
mc_private_ram_start_addr,
return 0;
}
+static int mc_fixup_dpc(u64 dpc_addr)
+{
+ void *blob = (void *)dpc_addr;
+ int nodeoffset;
+
+ /* delete any existing ICID pools */
+ nodeoffset = fdt_path_offset(blob, "/resources/icid_pools");
+ if (fdt_del_node(blob, nodeoffset) < 0)
+ printf("\nfsl-mc: WARNING: could not delete ICID pool\n");
+
+ /* add a new pool */
+ nodeoffset = fdt_path_offset(blob, "/resources");
+ if (nodeoffset < 0) {
+ printf("\nfsl-mc: ERROR: DPC is missing /resources\n");
+ return -EINVAL;
+ }
+ nodeoffset = fdt_add_subnode(blob, nodeoffset, "icid_pools");
+ nodeoffset = fdt_add_subnode(blob, nodeoffset, "icid_pool@0");
+ do_fixup_by_path_u32(blob, "/resources/icid_pools/icid_pool@0",
+"base_icid", FSL_DPAA2_STREAM_ID_START, 1);
+ do_fixup_by_path_u32(blob, "/resources/icid_pools/icid_pool@0",
+"num",
+FSL_DPAA2_STREAM_ID_END -
+FSL_DPAA2_STREAM_ID_START + 1, 1);
+
+ flush_dcache_range(dpc_addr, dpc_addr + fdt_totalsize(blob));
+
+ return 0;
+}
+
static int load_mc_dpc(u64 mc_ram_addr, size_t mc_ram_size)
{
u64 mc_dpc_offset;
@@ -239,6 +272,9 @@ static int load_mc_dpc(u64 mc_ram_addr, size_t mc_ram_size)
(u64)dpc_fdt_hdr, dpc_size, mc_ram_addr + mc_dpc_offset);
#endif /* not defined CONFIG_SYS_LS_MC_DPC_IN_DDR */
+ if (mc_fixup_dpc(mc_ram_addr + mc_dpc_offset))
+ return -EINVAL;
+
dump_ram_words("DPC", (void *)(mc_ram_addr + mc_dpc_offset));
return 0;
}
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 05/13] drivers: fsl-mc: Update qbman driver
Update qbman driver
- As per latest available qbman driver
- Use of atomic APIs
Signed-off-by: Prabhakar Kushwaha
CC: Geoff Thorpe
CC: Haiying Wang
CC: Roy Pledge
---
drivers/net/fsl-mc/dpio/qbman_portal.c | 66 ++---
drivers/net/fsl-mc/dpio/qbman_portal.h | 22 ---
drivers/net/fsl-mc/dpio/qbman_private.h | 2 +-
3 files changed, 53 insertions(+), 37 deletions(-)
diff --git a/drivers/net/fsl-mc/dpio/qbman_portal.c
b/drivers/net/fsl-mc/dpio/qbman_portal.c
index dd2a7de..5fa8d95 100644
--- a/drivers/net/fsl-mc/dpio/qbman_portal.c
+++ b/drivers/net/fsl-mc/dpio/qbman_portal.c
@@ -64,7 +64,7 @@ enum qbman_sdqcr_fc {
struct qbman_swp *qbman_swp_init(const struct qbman_swp_desc *d)
{
int ret;
- struct qbman_swp *p = kmalloc(sizeof(*p), GFP_KERNEL);
+ struct qbman_swp *p = malloc(sizeof(struct qbman_swp));
if (!p)
return NULL;
@@ -77,7 +77,7 @@ struct qbman_swp *qbman_swp_init(const struct qbman_swp_desc
*d)
qb_attr_code_encode(&code_sdqcr_dct, &p->sdq, qbman_sdqcr_dct_prio_ics);
qb_attr_code_encode(&code_sdqcr_fc, &p->sdq, qbman_sdqcr_fc_up_to_3);
qb_attr_code_encode(&code_sdqcr_tok, &p->sdq, 0xbb);
- p->vdq.busy = 0; /* TODO: convert to atomic_t */
+ atomic_set(&p->vdq.busy, 1);
p->vdq.valid_bit = QB_VALID_BIT;
p->dqrr.next_idx = 0;
p->dqrr.valid_bit = QB_VALID_BIT;
@@ -165,7 +165,6 @@ static struct qb_attr_code code_eq_qd_bin = QB_CODE(4, 0,
16);
static struct qb_attr_code code_eq_qd_pri = QB_CODE(4, 16, 4);
static struct qb_attr_code code_eq_rsp_stash = QB_CODE(5, 16, 1);
static struct qb_attr_code code_eq_rsp_lo = QB_CODE(6, 0, 32);
-static struct qb_attr_code code_eq_rsp_hi = QB_CODE(7, 0, 32);
enum qbman_eq_cmd_e {
/* No enqueue, primarily for plugging ORP gaps for dropped frames */
@@ -197,8 +196,7 @@ void qbman_eq_desc_set_response(struct qbman_eq_desc *d,
{
uint32_t *cl = qb_cl(d);
- qb_attr_code_encode(&code_eq_rsp_lo, cl, lower32(storage_phys));
- qb_attr_code_encode(&code_eq_rsp_hi, cl, upper32(storage_phys));
+ qb_attr_code_encode_64(&code_eq_rsp_lo, (uint64_t *)cl, storage_phys);
qb_attr_code_encode(&code_eq_rsp_stash, cl, !!stash);
}
@@ -253,7 +251,6 @@ static struct qb_attr_code code_pull_numframes = QB_CODE(0,
8, 4);
static struct qb_attr_code code_pull_token = QB_CODE(0, 16, 8);
static struct qb_attr_code code_pull_dqsource = QB_CODE(1, 0, 24);
static struct qb_attr_code code_pull_rsp_lo = QB_CODE(2, 0, 32);
-static struct qb_attr_code code_pull_rsp_hi = QB_CODE(3, 0, 32);
enum qb_pull_dt_e {
qb_pull_dt_channel,
@@ -282,8 +279,7 @@ void qbman_pull_desc_set_storage(struct qbman_pull_desc *d,
}
qb_attr_code_encode(&code_pull_rls, cl, 1);
qb_attr_code_encode(&code_pull_stash, cl, !!stash);
- qb_attr_code_encode(&code_pull_rsp_lo, cl, lower32(storage_phys));
- qb_attr_code_encode(&code_pull_rsp_hi, cl, upper32(storage_phys));
+ qb_attr_code_encode_64(&code_pull_rsp_lo, (uint64_t *)cl, storage_phys);
}
void qbman_pull_desc_set_numframes(struct qbman_pull_desc *d, uint8_t
numframes)
@@ -316,10 +312,10 @@ int qbman_swp_pull(struct qbman_swp *s, struct
qbman_pull_desc *d)
uint32_t *p;
uint32_t *cl = qb_cl(d);
- /* TODO: convert to atomic_t */
- if (s->vdq.busy)
+ if (!atomic_dec_and_test(&s->vdq.busy)) {
+ atomic_inc(&s->vdq.busy);
return -EBUSY;
- s->vdq.busy = 1;
+ }
s->vdq.storage = *(void **)&cl[4];
s->vdq.token = qb_attr_code_decode(&code_pull_token, cl);
p = qbman_cena_write_start(&s->sys, QBMAN_CENA_SWP_VDQCR);
@@ -359,36 +355,44 @@ const struct ldpaa_dq *qbman_swp_dqrr_next(struct
qbman_swp *s)
{
uint32_t verb;
uint32_t response_verb;
- const struct ldpaa_dq *dq = qbman_cena_read(&s->sys,
- QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx));
- const uint32_t *p = qb_cl(dq);
+ uint32_t flags;
+ const struct ldpaa_dq *dq;
+ const uint32_t *p;
+ dq = qbman_cena_read(&s->sys, QBMAN_CENA_SWP_DQRR(s->dqrr.next_idx));
+ p = qb_cl(dq);
verb = qb_attr_code_decode(&code_dqrr_verb, p);
- /* If the valid-bit isn't of the expected polarity, nothing there */
+
+ /* If the valid-bit isn't of the expected polarity, nothing there. Note,
+* in the DQRR reset bug workaround, we shouldn't need to skip these
+* check, because we've already determined that a new entry is available
+* and we've invalidated the cacheline before reading it, so the
+* valid-bit behaviour is repaired and should tell us what we already
+* knew from reading PI.
+*/
if ((verb & QB_VALID_BIT) != s->dqrr.valid_bit) {
qbman_cena_invalidate_prefetch(&s->sys,
-
[U-Boot] [PATCH 06/13] drivers: fsl-mc: Return error for major version mismatch
Management complex major version should match to the firmware present in flash.
Return error during mismatch of major version.
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/fsl-mc/mc.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 2094595..c4406c6 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -518,9 +518,14 @@ int mc_init(void)
goto out;
}
- if (MC_VER_MAJOR != mc_ver_info.major)
+ if (MC_VER_MAJOR != mc_ver_info.major) {
printf("fsl-mc: ERROR: Firmware major version mismatch (found:
%d, expected: %d)\n",
mc_ver_info.major, MC_VER_MAJOR);
+ printf("fsl-mc: Update the Management Complex firmware\n");
+
+ error = 1;
+ goto out;
+ }
if (MC_VER_MINOR != mc_ver_info.minor)
printf("fsl-mc: WARNING: Firmware minor version mismatch
(found: %d, expected: %d)\n",
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 07/13] armv8/fsl-lsch3: partition stream IDs
From: Stuart Yoder Stream IDs on ls2085a devices are not hardwired and are programmed by sw. There are a limited number of stream IDs available, and the partitioning of them is scenario dependent. This header defines the partitioning between legacy, PCI, and DPAA2 devices. Signed-off-by: Stuart Yoder Signed-off-by: Prabhakar Kushwaha --- .../include/asm/arch-fsl-lsch3/ls2085a_stream_id.h | 64 ++ drivers/net/fsl-mc/mc.c| 2 +- include/configs/ls2085a_common.h | 1 + include/fsl-mc/fsl_mc.h| 4 -- 4 files changed, 66 insertions(+), 5 deletions(-) create mode 100644 arch/arm/include/asm/arch-fsl-lsch3/ls2085a_stream_id.h diff --git a/arch/arm/include/asm/arch-fsl-lsch3/ls2085a_stream_id.h b/arch/arm/include/asm/arch-fsl-lsch3/ls2085a_stream_id.h new file mode 100644 index 000..5c94530 --- /dev/null +++ b/arch/arm/include/asm/arch-fsl-lsch3/ls2085a_stream_id.h @@ -0,0 +1,64 @@ +/* + * Copyright 2014 Freescale Semiconductor, Inc. + * + * SPDX-License-Identifier:GPL-2.0+ + * + */ +#ifndef __FSL_STREAM_ID_H +#define __FSL_STREAM_ID_H + +/* Stream IDs on ls2085a devices are not hardwired and are + * programmed by sw. There are a limited number of stream IDs + * available, and the partitioning of them is scenario dependent. + * This header defines the partitioning between legacy, PCI, + * and DPAA2 devices. + * + * This partitiong can be customized in this file depending + * on the specific hardware config-- e.g. perhaps not all + * PEX controllers are in use. + * + * On LS2085 stream IDs are programmed in AMQ registers (32-bits) for + * each of the different bus masters. The relationship between + * the AMQ registers and stream IDs is defined in the table below: + * AMQ bitstreamID bit + * --- + * PL[18] 9 + * BMT[17] 8 + * VA[16] 7 + * [15] - + * ICID[14:7] - + * ICID[6:0]6-0 + * + */ + +#define AMQ_PL_MASK(0x1 << 18) /* priviledge bit */ +#define AMQ_BMT_MASK (0x1 << 17) /* bypass bit */ + +#define FSL_INVALID_STREAM_ID 0 + +#define FSL_BYPASS_AMQ (AMQ_PL_MASK | AMQ_BMT_MASK) + +/* legacy devices */ +#define FSL_USB1_STREAM_ID 1 +#define FSL_USB2_STREAM_ID 2 +#define FSL_SDMMC_STREAM_ID3 +#define FSL_SATA1_STREAM_ID4 +#define FSL_SATA2_STREAM_ID5 +#define FSL_DMA_STREAM_ID 6 + +/* PCI - programmed in PEXn_LUT by OS */ +/* 4 IDs per controller */ +#define FSL_PEX1_STREAM_ID_START 7 +#define FSL_PEX1_STREAM_ID_END 10 +#define FSL_PEX2_STREAM_ID_START 11 +#define FSL_PEX2_STREAM_ID_END 14 +#define FSL_PEX3_STREAM_ID_START 15 +#define FSL_PEX3_STREAM_ID_END 18 +#define FSL_PEX4_STREAM_ID_START 19 +#define FSL_PEX4_STREAM_ID_END 22 + +/* DPAA2 - set in MC DPC and alloced by MC */ +#define FSL_DPAA2_STREAM_ID_START 23 +#define FSL_DPAA2_STREAM_ID_END63 + +#endif diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c index c4406c6..8bb8f7b 100644 --- a/drivers/net/fsl-mc/mc.c +++ b/drivers/net/fsl-mc/mc.c @@ -474,7 +474,7 @@ int mc_init(void) out_le32(&mc_ccsr_regs->reg_mcfbalr, reg_mcfbalr); out_le32(&mc_ccsr_regs->reg_mcfbahr, (u32)(mc_ram_aligned_base_addr >> 32)); - out_le32(&mc_ccsr_regs->reg_mcfapr, MCFAPR_BYPASS_ICID_MASK); + out_le32(&mc_ccsr_regs->reg_mcfapr, FSL_BYPASS_AMQ); /* * Tell the MC that we want delayed DPL deployment. diff --git a/include/configs/ls2085a_common.h b/include/configs/ls2085a_common.h index d095151..5248e2a 100644 --- a/include/configs/ls2085a_common.h +++ b/include/configs/ls2085a_common.h @@ -19,6 +19,7 @@ #define CONFIG_ARM_ERRATA_828024 #define CONFIG_ARM_ERRATA_826974 +#include #include #if (defined(CONFIG_SYS_FSL_SRDS_1) || defined(CONFIG_SYS_FSL_SRDS_2)) #defineCONFIG_SYS_HAS_SERDES diff --git a/include/fsl-mc/fsl_mc.h b/include/fsl-mc/fsl_mc.h index 0e799f5..9106f25 100644 --- a/include/fsl-mc/fsl_mc.h +++ b/include/fsl-mc/fsl_mc.h @@ -21,10 +21,6 @@ #define GCR1_M2_DE_RST BIT(14) #define GCR1_M_ALL_DE_RST (GCR1_M1_DE_RST | GCR1_M2_DE_RST) #define GSR_FS_MASK0x3fff -#define MCFAPR_PL_MASK (0x1 << 18) -#define MCFAPR_BMT_MASK(0x1 << 17) -#define MCFAPR_BYPASS_ICID_MASK\ - (MCFAPR_PL_MASK | MCFAPR_BMT_MASK) #define SOC_MC_PORTALS_BASE_ADDR((void __iomem *)0x00080C00) #define SOC_QBMAN_PORTALS_BASE_ADDR ((void __iomem *)0x00081800) -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 04/13] drivers: fsl-mc: Update flibs to mc-0.6.0.1
Update flibs changes to mc-0.6.0.1 for dpmang, dprc, dpni and dpio objects
Also rename qbman_portal_ce/ci_paddr to qbman_portal_ce/ci_offset in
dpio_attr. These are now offsets from the SoC QBMan portals base.
Signed-off-by: J. German Rivera
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/fsl-mc/dpni.c | 2 +-
drivers/net/fsl-mc/mc.c| 12 ++--
include/fsl-mc/fsl_dpio.h | 32 --
include/fsl-mc/fsl_dpmng.h | 2 +-
include/fsl-mc/fsl_dpni.h | 144 ++---
include/fsl-mc/fsl_dprc.h | 64 +---
include/fsl-mc/fsl_mc.h| 1 +
7 files changed, 199 insertions(+), 58 deletions(-)
diff --git a/drivers/net/fsl-mc/dpni.c b/drivers/net/fsl-mc/dpni.c
index b384401..7bc2504 100644
--- a/drivers/net/fsl-mc/dpni.c
+++ b/drivers/net/fsl-mc/dpni.c
@@ -313,7 +313,7 @@ int dpni_set_counter(struct fsl_mc_io *mc_io,
int dpni_set_link_cfg(struct fsl_mc_io *mc_io,
uint16_t token,
-struct dpni_link_cfg *cfg)
+const struct dpni_link_cfg *cfg)
{
struct mc_command cmd = { 0 };
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index 2b38b50..2094595 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -610,14 +610,16 @@ int dpio_init(struct dprc_obj_desc obj_desc)
printf("dpio_enable() failed %d\n", err);
goto err_get_enable;
}
- debug("ce_paddr=0x%llx, ci_paddr=0x%llx, portalid=%d, prios=%d\n",
- attr.qbman_portal_ce_paddr,
- attr.qbman_portal_ci_paddr,
+ debug("ce_offset=0x%llx, ci_offset=0x%llx, portalid=%d, prios=%d\n",
+ attr.qbman_portal_ce_offset,
+ attr.qbman_portal_ci_offset,
attr.qbman_portal_id,
attr.num_priorities);
- p_des.cena_bar = (void *)attr.qbman_portal_ce_paddr;
- p_des.cinh_bar = (void *)attr.qbman_portal_ci_paddr;
+ p_des.cena_bar = (void *)(SOC_QBMAN_PORTALS_BASE_ADDR
+ + attr.qbman_portal_ce_offset);
+ p_des.cinh_bar = (void *)(SOC_QBMAN_PORTALS_BASE_ADDR
+ + attr.qbman_portal_ci_offset);
dflt_dpio->sw_portal = qbman_swp_init(&p_des);
if (dflt_dpio->sw_portal == NULL) {
diff --git a/include/fsl-mc/fsl_dpio.h b/include/fsl-mc/fsl_dpio.h
index e84b419..e779909 100644
--- a/include/fsl-mc/fsl_dpio.h
+++ b/include/fsl-mc/fsl_dpio.h
@@ -8,8 +8,8 @@
#define _FSL_DPIO_H
/* DPIO Version */
-#define DPIO_VER_MAJOR 2
-#define DPIO_VER_MINOR 1
+#define DPIO_VER_MAJOR 3
+#define DPIO_VER_MINOR 0
/* Command IDs */
#define DPIO_CMDID_CLOSE 0x800
@@ -31,8 +31,8 @@ do { \
MC_RSP_OP(cmd, 0, 32, 16, uint16_t, attr->qbman_portal_id);\
MC_RSP_OP(cmd, 0, 48, 8, uint8_t, attr->num_priorities);\
MC_RSP_OP(cmd, 0, 56, 4, enum dpio_channel_mode, attr->channel_mode);\
- MC_RSP_OP(cmd, 1, 0, 64, uint64_t, attr->qbman_portal_ce_paddr);\
- MC_RSP_OP(cmd, 2, 0, 64, uint64_t, attr->qbman_portal_ci_paddr);\
+ MC_RSP_OP(cmd, 1, 0, 64, uint64_t, attr->qbman_portal_ce_offset);\
+ MC_RSP_OP(cmd, 2, 0, 64, uint64_t, attr->qbman_portal_ci_offset);\
MC_RSP_OP(cmd, 3, 0, 16, uint16_t, attr->version.major);\
MC_RSP_OP(cmd, 3, 16, 16, uint16_t, attr->version.minor);\
} while (0)
@@ -42,6 +42,7 @@ do { \
*/
struct fsl_mc_io;
+
/**
* dpio_open() - Open a control session for the specified object
* @mc_io: Pointer to MC portal's I/O object
@@ -61,18 +62,9 @@ struct fsl_mc_io;
int dpio_open(struct fsl_mc_io *mc_io, int dpio_id, uint16_t *token);
/**
- * dpio_open() - Open a control session for the specified object
+ * dpio_close() - Close the control session of the object
* @mc_io: Pointer to MC portal's I/O object
- * @dpio_id: DPIO unique ID
- * @token: Returned token; use in subsequent API calls
- *
- * This function can be used to open a control session for an
- * already created object; an object may have been declared in
- * the DPL or by calling the dpio_create() function.
- * This function returns a unique authentication token,
- * associated with the specific object ID and the specific MC
- * portal; this token must be used in all subsequent commands for
- * this specific object.
+ * @token: Token of DPIO object
*
* Return: '0' on Success; Error code otherwise.
*/
@@ -121,10 +113,8 @@ int dpio_reset(struct fsl_mc_io *mc_io, uint16_t token);
* struct dpio_attr - Structure representing DPIO attributes
* @id: DPIO object ID
* @version: DPIO version
- * @qbman_portal_ce_paddr: Physical address of the software portal
- * cache-enabled area
- * @qbman_portal_ci_paddr: Physical address of the software portal
- *
[U-Boot] [PATCH 03/13] drivers/fsl-mc: Autoload AOIP image from NOR flash
From: "J. German Rivera"
Load AIOP image from NOR flash into DDR so that the MC firmware
the MC fw can start it at boot time
Signed-off-by: J. German Rivera
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/fsl-mc/mc.c | 23 +++
include/configs/ls2085a_common.h | 2 ++
include/configs/ls2085aqds.h | 2 ++
include/configs/ls2085ardb.h | 2 ++
4 files changed, 29 insertions(+)
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index d02da9d..2b38b50 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -321,6 +321,23 @@ static unsigned long get_mc_boot_timeout_ms(void)
return timeout_ms;
}
+#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
static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr)
{
u32 reg_gsr;
@@ -440,6 +457,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);
diff --git a/include/configs/ls2085a_common.h b/include/configs/ls2085a_common.h
index cf51909..d095151 100644
--- a/include/configs/ls2085a_common.h
+++ b/include/configs/ls2085a_common.h
@@ -174,6 +174,8 @@ unsigned long long get_qixis_addr(void);
#define CONFIG_SYS_LS_MC_DRAM_DPC_OFFSET0x00F0
#define CONFIG_SYS_LS_MC_DPL_MAX_LENGTH0x2
#define CONFIG_SYS_LS_MC_DRAM_DPL_OFFSET0x00F2
+#define CONFIG_SYS_LS_MC_AIOP_IMG_MAX_LENGTH 0x20
+#define CONFIG_SYS_LS_MC_DRAM_AIOP_IMG_OFFSET 0x0700
/*
* Carve out a DDR region which will not be used by u-boot/Linux
diff --git a/include/configs/ls2085aqds.h b/include/configs/ls2085aqds.h
index 731eca2..3d9655d 100644
--- a/include/configs/ls2085aqds.h
+++ b/include/configs/ls2085aqds.h
@@ -261,6 +261,8 @@ unsigned long get_board_ddr_clk(void);
#define CONFIG_SYS_LS_MC_DPC_ADDR 0x58080ULL
#define CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS 5000
+#define CONFIG_SYS_LS_MC_AIOP_IMG_IN_NOR
+#define CONFIG_SYS_LS_MC_AIOP_IMG_ADDR 0x58090ULL
/*
* I2C
diff --git a/include/configs/ls2085ardb.h b/include/configs/ls2085ardb.h
index a0f0f6c..9f0a96f 100644
--- a/include/configs/ls2085ardb.h
+++ b/include/configs/ls2085ardb.h
@@ -234,6 +234,8 @@ unsigned long get_board_sys_clk(void);
#define CONFIG_SYS_LS_MC_DPC_ADDR 0x58080ULL
#define CONFIG_SYS_LS_MC_BOOT_TIMEOUT_MS 5000
+#define CONFIG_SYS_LS_MC_AIOP_IMG_IN_NOR
+#define CONFIG_SYS_LS_MC_AIOP_IMG_ADDR 0x58090ULL
/*
* I2C
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 02/13] driver/ldpaa_eth:Flush buffer before seeding BMAN after TX_conf
Flush buffer before releasing to BMan after TX_conf to ensure, the core does
not have any cachelines that the WRIOP will DMA to.
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/ldpaa_eth/ldpaa_eth.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/ldpaa_eth/ldpaa_eth.c
b/drivers/net/ldpaa_eth/ldpaa_eth.c
index d4be1ba..5636511 100644
--- a/drivers/net/ldpaa_eth/ldpaa_eth.c
+++ b/drivers/net/ldpaa_eth/ldpaa_eth.c
@@ -153,6 +153,7 @@ static void ldpaa_eth_tx_conf(struct ldpaa_eth_priv *priv,
}
}
+ 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 {
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 01/13] drivers/fsl-mc: Make MC boot error messages more readable
From: "J. German Rivera"
Make it easier for the user to notice when the MC firmware
had problems booting.
Signed-off-by: J. German Rivera
Signed-off-by: Prabhakar Kushwaha
---
drivers/net/fsl-mc/mc.c | 31 +--
1 file changed, 13 insertions(+), 18 deletions(-)
diff --git a/drivers/net/fsl-mc/mc.c b/drivers/net/fsl-mc/mc.c
index f4a050a..d02da9d 100644
--- a/drivers/net/fsl-mc/mc.c
+++ b/drivers/net/fsl-mc/mc.c
@@ -224,13 +224,13 @@ static int load_mc_dpc(u64 mc_ram_addr, size_t
mc_ram_size)
* Don't return with error here, since the MC firmware can
* still boot without a DPC
*/
- printf("fsl-mc: WARNING: No DPC image found\n");
+ printf("\nfsl-mc: WARNING: No DPC image found");
return 0;
}
dpc_size = fdt_totalsize(dpc_fdt_hdr);
if (dpc_size > CONFIG_SYS_LS_MC_DPC_MAX_LENGTH) {
- printf("fsl-mc: ERROR: Bad DPC image (too large: %d)\n",
+ printf("\nfsl-mc: ERROR: Bad DPC image (too large: %d)\n",
dpc_size);
return -EINVAL;
}
@@ -278,13 +278,13 @@ static int load_mc_dpl(u64 mc_ram_addr, size_t
mc_ram_size)
error = fdt_check_header(dpl_fdt_hdr);
if (error != 0) {
- printf("fsl-mc: ERROR: Bad DPL image (bad header)\n");
+ printf("\nfsl-mc: ERROR: Bad DPL image (bad header)\n");
return error;
}
dpl_size = fdt_totalsize(dpl_fdt_hdr);
if (dpl_size > CONFIG_SYS_LS_MC_DPL_MAX_LENGTH) {
- printf("fsl-mc: ERROR: Bad DPL image (too large: %d)\n",
+ printf("\nfsl-mc: ERROR: Bad DPL image (too large: %d)\n",
dpl_size);
return -EINVAL;
}
@@ -329,7 +329,6 @@ static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr)
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 */
@@ -344,10 +343,7 @@ static int wait_for_mc(bool booting_mc, u32 *final_reg_gsr)
}
if (timeout_ms == 0) {
- if (booting_mc)
- printf("fsl-mc: timeout booting management complex
firmware\n");
- else
- printf("fsl-mc: timeout deploying data path layout\n");
+ printf("ERROR: timeout\n");
/* TODO: Get an error status from an MC CCSR register */
return -ETIMEDOUT;
@@ -360,15 +356,13 @@ static int wait_for_mc(bool booting_mc, u32
*final_reg_gsr)
* appropriate errno, so that the status property is set to
* failure in the fsl,dprc device tree node.
*/
- if (booting_mc) {
- printf("fsl-mc: WARNING: Firmware booted with error
(GSR: %#x)\n",
- reg_gsr);
- } else {
- printf("fsl-mc: WARNING: Data path layout deployed with
error (GSR: %#x)\n",
- reg_gsr);
- }
+ printf("WARNING: Firmware returned an error (GSR: %#x)\n",
+ reg_gsr);
+ } else {
+ printf("SUCCESS\n");
}
+
*final_reg_gsr = reg_gsr;
return 0;
}
@@ -464,7 +458,7 @@ int mc_init(void)
*/
out_le32(&mc_ccsr_regs->reg_gsr, 0xDD00);
- printf("\nfsl-mc: Booting Management Complex ...\n");
+ printf("\nfsl-mc: Booting Management Complex ... ");
/*
* Deassert reset and release MC core 0 to run
@@ -517,10 +511,11 @@ int mc_init(void)
* Tell the MC to deploy the DPL:
*/
out_le32(&mc_ccsr_regs->reg_gsr, 0x0);
- printf("\nfsl-mc: Deploying data path layout ...\n");
+ printf("fsl-mc: Deploying data path layout ... ");
error = wait_for_mc(false, ®_gsr);
if (error != 0)
goto out;
+
out:
if (error != 0)
mc_boot_status = -error;
--
1.9.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/4] zynqmp: Provide option to enable uart dcc support for zynqmp
Provide option to enable uart dcc support for zynqmp This config can be enabled as per board config file. Signed-off-by: Siva Durga Prasad Paladugu --- include/configs/xilinx_zynqmp.h |9 - 1 files changed, 8 insertions(+), 1 deletions(-) diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index 8189add..2594696 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -52,7 +52,14 @@ #define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 0x40) /* Serial setup */ -#define CONFIG_ZYNQ_SERIAL +#if defined(CONFIG_ZYNQMP_DCC) +# define CONFIG_ARM_DCC +# define CONFIG_CPU_ARMV8 +#else +# if defined(CONFIG_ZYNQ_SERIAL_UART0) || defined(CONFIG_ZYNQ_SERIAL_UART1) +# define CONFIG_ZYNQ_SERIAL +# endif +#endif #define CONFIG_CONS_INDEX 0 #define CONFIG_BAUDRATE115200 -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/4] zynqmp: Kconfig: Move zynqmp Kconfig
Move the zynqmp Kconfig from board to arch
as there may be different boards under same
architecture.
Signed-off-by: Siva Durga Prasad Paladugu
---
arch/arm/Kconfig |3 ++-
.../xilinx => arch/arm/cpu/armv8}/zynqmp/Kconfig |0
2 files changed, 2 insertions(+), 1 deletions(-)
rename {board/xilinx => arch/arm/cpu/armv8}/zynqmp/Kconfig (100%)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 2985e6e..ca2c410 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -850,6 +850,8 @@ source "arch/arm/mach-zynq/Kconfig"
source "arch/arm/cpu/armv7/Kconfig"
+source "arch/arm/cpu/armv8/zynqmp/Kconfig"
+
source "arch/arm/cpu/armv8/Kconfig"
source "arch/arm/imx-common/Kconfig"
@@ -967,7 +969,6 @@ source "board/warp/Kconfig"
source "board/woodburn/Kconfig"
source "board/work-microwave/work_92105/Kconfig"
source "board/xaeniax/Kconfig"
-source "board/xilinx/zynqmp/Kconfig"
source "board/zipitz2/Kconfig"
source "arch/arm/Kconfig.debug"
diff --git a/board/xilinx/zynqmp/Kconfig b/arch/arm/cpu/armv8/zynqmp/Kconfig
similarity index 100%
rename from board/xilinx/zynqmp/Kconfig
rename to arch/arm/cpu/armv8/zynqmp/Kconfig
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/4] zynqmp: Define ep config for ZynqMP
Define a new config "zynqmp_ep" for ZynqMP instead
of xilinx_zynqmp. This defconfig supports all emulation
platforms of ZynqMP. Also renamed TARGET_XILINX_ZYNQMP
to ARCH_ZYNQMP.
Signed-off-by: Siva Durga Prasad Paladugu
---
arch/arm/Kconfig |2 +-
arch/arm/cpu/armv8/Makefile|2 +-
arch/arm/cpu/armv8/zynqmp/Kconfig | 12 +++-
...xilinx_zynqmp_defconfig => zynqmp_ep_defconfig} |5 ++-
include/configs/xilinx_zynqmp.h|8 -
include/configs/zynqmp_ep.h| 29
6 files changed, 44 insertions(+), 14 deletions(-)
rename configs/{xilinx_zynqmp_defconfig => zynqmp_ep_defconfig} (71%)
create mode 100644 include/configs/zynqmp_ep.h
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index ca2c410..ab2f211 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -659,7 +659,7 @@ config ARCH_ZYNQ
select SUPPORT_SPL
select DM
-config TARGET_XILINX_ZYNQMP
+config ARCH_ZYNQMP
bool "Support Xilinx ZynqMP Platform"
select ARM64
diff --git a/arch/arm/cpu/armv8/Makefile b/arch/arm/cpu/armv8/Makefile
index dee5e25..6466ebb 100644
--- a/arch/arm/cpu/armv8/Makefile
+++ b/arch/arm/cpu/armv8/Makefile
@@ -16,4 +16,4 @@ obj-y += tlb.o
obj-y += transition.o
obj-$(CONFIG_FSL_LSCH3) += fsl-lsch3/
-obj-$(CONFIG_TARGET_XILINX_ZYNQMP) += zynqmp/
+obj-$(CONFIG_ARCH_ZYNQMP) += zynqmp/
diff --git a/arch/arm/cpu/armv8/zynqmp/Kconfig
b/arch/arm/cpu/armv8/zynqmp/Kconfig
index b07932e..cf80b08 100644
--- a/arch/arm/cpu/armv8/zynqmp/Kconfig
+++ b/arch/arm/cpu/armv8/zynqmp/Kconfig
@@ -1,4 +1,12 @@
-if TARGET_XILINX_ZYNQMP
+if ARCH_ZYNQMP
+
+choice
+ prompt "Xilinx ZynqMP board select"
+
+config TARGET_ZYNQMP_EP
+ bool "ZynqMP EP Board"
+
+endchoice
config SYS_BOARD
default "zynqmp"
@@ -10,6 +18,6 @@ config SYS_SOC
default "zynqmp"
config SYS_CONFIG_NAME
- default "xilinx_zynqmp"
+ default "zynqmp_ep" if TARGET_ZYNQMP_EP
endif
diff --git a/configs/xilinx_zynqmp_defconfig b/configs/zynqmp_ep_defconfig
similarity index 71%
rename from configs/xilinx_zynqmp_defconfig
rename to configs/zynqmp_ep_defconfig
index c512e9c..6b29eca 100644
--- a/configs/xilinx_zynqmp_defconfig
+++ b/configs/zynqmp_ep_defconfig
@@ -1,6 +1,7 @@
CONFIG_ARM=y
-CONFIG_TARGET_XILINX_ZYNQMP=y
-CONFIG_DEFAULT_DEVICE_TREE="zynqmp"
+CONFIG_ARCH_ZYNQMP=y
+CONFIG_TARGET_ZYNQMP_EP=y
+CONFIG_DEFAULT_DEVICE_TREE="zynqmp-ep"
CONFIG_CMD_BDI=y
CONFIG_CMD_BOOTD=y
CONFIG_CMD_RUN=y
diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h
index 880d29c..18cd15b 100644
--- a/include/configs/xilinx_zynqmp.h
+++ b/include/configs/xilinx_zynqmp.h
@@ -53,7 +53,6 @@
#define CONFIG_SYS_MALLOC_LEN (CONFIG_ENV_SIZE + 0x40)
/* Serial setup */
-#define CONFIG_ZYNQ_SERIAL_UART0
#define CONFIG_ZYNQ_SERIAL
#define CONFIG_CONS_INDEX 0
@@ -61,8 +60,6 @@
#define CONFIG_SYS_BAUDRATE_TABLE \
{ 4800, 9600, 19200, 38400, 57600, 115200 }
-#define CONFIG_ZYNQ_SDHCI0
-
/* Command line configuration */
#define CONFIG_CMD_ENV
#define CONFIG_CMD_EXT2
@@ -129,9 +126,6 @@
#define CONFIG_CMDLINE_EDITING
#define CONFIG_SYS_MAXARGS 64
-#define CONFIG_ZYNQ_I2C0
-#define CONFIG_SYS_I2C_ZYNQ
-
/* I2C */
#if defined(CONFIG_SYS_I2C_ZYNQ)
# define CONFIG_CMD_I2C
@@ -140,8 +134,6 @@
# define CONFIG_SYS_I2C_ZYNQ_SLAVE 0
#endif
-#define CONFIG_ZYNQMP_EEPROM
-
/* EEPROM */
#ifdef CONFIG_ZYNQMP_EEPROM
# define CONFIG_CMD_EEPROM
diff --git a/include/configs/zynqmp_ep.h b/include/configs/zynqmp_ep.h
new file mode 100644
index 000..26dd300
--- /dev/null
+++ b/include/configs/zynqmp_ep.h
@@ -0,0 +1,29 @@
+/*
+ * Configuration for Xilinx ZynqMP emulation
+ * platforms. See zynqmp-common.h for ZynqMP
+ * common configs
+ *
+ * (C) Copyright 2014 - 2015 Xilinx, Inc.
+ * Michal Simek
+ * Siva Durga Prasad Paladugu
+ *
+ * Based on Configuration for Versatile Express
+ *
+ * SPDX-License-Identifier:GPL-2.0+
+ */
+
+#ifndef __CONFIG_ZYNQMP_EP_H
+#define __CONFIG_ZYNQMP_EP_H
+
+#define CONFIG_ZYNQ_GEM0
+#define CONFIG_ZYNQ_GEM_PHY_ADDR0 7
+
+#define CONFIG_ZYNQ_SERIAL_UART0
+#define CONFIG_ZYNQ_SDHCI0
+#define CONFIG_ZYNQ_I2C0
+#define CONFIG_SYS_I2C_ZYNQ
+#define CONFIG_ZYNQ_EEPROM
+
+#include
+
+#endif /* __CONFIG_ZYNQMP_EP_H */
--
1.7.1
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/4] Kconfig: zynqMP: Move CONFIG_SYS_TEXT_BASE to defconfig
Move CONFIG_SYS_TEXT_BASE of ZynqMP_ep to its respective defconfig Signed-off-by: Siva Durga Prasad Paladugu --- Kconfig |2 +- configs/zynqmp_ep_defconfig |1 + include/configs/xilinx_zynqmp.h |1 - 3 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Kconfig b/Kconfig index 15e15af..fc69189 100644 --- a/Kconfig +++ b/Kconfig @@ -178,7 +178,7 @@ config SYS_EXTRA_OPTIONS new boards should not use this option. config SYS_TEXT_BASE - depends on SPARC || ARC || X86 || ARCH_UNIPHIER + depends on SPARC || ARC || X86 || ARCH_UNIPHIER || ARCH_ZYNQMP hex "Text Base" help TODO: Move CONFIG_SYS_TEXT_BASE for all the architecture diff --git a/configs/zynqmp_ep_defconfig b/configs/zynqmp_ep_defconfig index 6b29eca..bba62bd 100644 --- a/configs/zynqmp_ep_defconfig +++ b/configs/zynqmp_ep_defconfig @@ -13,3 +13,4 @@ CONFIG_CMD_SOURCE=y CONFIG_CMD_TIME=y CONFIG_CMD_MISC=y CONFIG_CMD_TIMER=y +CONFIG_SYS_TEXT_BASE=0x800 diff --git a/include/configs/xilinx_zynqmp.h b/include/configs/xilinx_zynqmp.h index 18cd15b..8189add 100644 --- a/include/configs/xilinx_zynqmp.h +++ b/include/configs/xilinx_zynqmp.h @@ -40,7 +40,6 @@ #define CONFIG_IDENT_STRING" Xilinx ZynqMP" -#define CONFIG_SYS_TEXT_BASE 0x800 #define CONFIG_SYS_INIT_SP_ADDR(CONFIG_SYS_SDRAM_BASE + 0x7fff0) /* Flat Device Tree Definitions */ -- 1.7.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device
On Wednesday 10 June 2015 11:54:00 Paul Kocialkowski wrote: > Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > I would be very glad to see board maintainers give a go > > > > at the changeset before it gets merged, especially on devices like > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > > (see other email thread). Until somebody fix that broken commit, I > > > cannot test your new patches in qemu or on (real) Nokia N900. > > > > Now I tested this patch series on top of u-boot master with applied my > > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. > > I'm confused here -- did you try booting on the actual device or in > qemu? > I tested your changes only in qemu. But because you removed (or better masked) required lowlevel asm code, it will not work on real n900 too. > > So this patch series is NAK from my side. > > Thanks for testing. Of course, the point is to make another version of > the patch set that fits the N900 too, since we really need to integrate > the omap3 to the common omap boot mechanism anyways. > Make sure that asm function in rx51 lowlevel asm file is called immediately from start.S. It is required. Basically no modification to that function should be needed (maybe just fixing return address in lr). > I may be able to get my hands on a N900 in a short while. Do you have n900 device? Or are you going to use qemu? Really, for development u-boot for n900 is easier to use qemu as you can easier debug code... > If you're interested, you're welcome to look at the issue and suggest > what changes should be made to make the set compatible with the N900! > Do not hide/mask/remove that required asm function. That should be all. -- Pali Rohár pali.ro...@gmail.com ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] ARM: AM43x: Fix MAX_RAM_BANK_SIZE
On AM437x-GP Evm there is 2GB of DDR3 memory available as stated in AM437x GP EVM HardwareUser's guide http://www.ti.com/lit/ug/spruhw7/spruhw7.pdf. But MAX_RAM_BANK_SIZE is defined as 1GB. Fixing MAX_RAM_BANK_SIZE to 2GB on AM43xx. Reported-by: Shivasharan Nagalikar Signed-off-by: Lokesh Vutla --- Tested on AM437x GP Evm, AM437x SK. include/configs/am43xx_evm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index d4f4c23..5d1049e 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -17,7 +17,7 @@ #define CONFIG_BOARD_LATE_INIT #define CONFIG_ARCH_CPU_INIT #define CONFIG_SYS_CACHELINE_SIZE 32 -#define CONFIG_MAX_RAM_BANK_SIZE (1024 << 20)/* 1GB */ +#define CONFIG_MAX_RAM_BANK_SIZE (1024 << 21)/* 2GB */ #define CONFIG_SYS_TIMERBASE 0x4804 /* Use Timer2 */ #include -- 1.9.1 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] imx: mx6qp: Adjust AQos settings for peripherals
Hi Stefano, On Wed, Jun 10, 2015 at 11:44:34AM +0200, Stefano Babic wrote: >Hi Peng, > >On 10/06/2015 10:06, Peng Fan wrote: >> From: "Ye.Li" >> >> To resolve USB camera bandwidth issue, the patch sets recommended AQoS >> setting from IC team value for peripheral and only on imx6qp. >> >> The address is: 0xbb0608, the value is: 0x8201 >> > >I understand that, if you fight against this issue, the comment can be >clear and maybe redundant. Please add comments in code describing the >issue, and extend the commit log to better explain the issue and the >solution. ok. Will add more info. > >> Signed-off-by: Ye.Li >> Signed-off-by: Peng Fan >> --- >> arch/arm/cpu/armv7/mx6/soc.c | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c >> index 5eea9d9..0de71d56 100644 >> --- a/arch/arm/cpu/armv7/mx6/soc.c >> +++ b/arch/arm/cpu/armv7/mx6/soc.c >> @@ -424,6 +424,9 @@ int arch_cpu_init(void) >> >> init_src(); >> >> +if (is_mx6dqp()) >> +writel(0x8201, 0xbb0608); >> + >> return 0; >> } >> >> > >Best regards, >Stefano Babic > >-- >= >DENX Software Engineering GmbH, Managing Director: Wolfgang Denk >HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de >= Regards, Peng. -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] imx: mx6qpsabreauto: Add MX6QP SABREAUTO CPU3 board support
Hi, Stefano On Wed, Jun 10, 2015 at 11:40:38AM +0200, Stefano Babic wrote: >Hi Peng, > >On 10/06/2015 10:06, Peng Fan wrote: >> 1. Add DDR script for mx6qpsabreauto board. >> 2. On CPU3 board, enet RGMII tx clock is from internal PLL. Set the GPR5[9] >>and init the enet pll output to 125Mhz. >> 3. On CPU3 board, SW1ABC=VDDSOC_IN, SW2=VDDARM_IN. >> >> Build target: mx6qpsabreauto_config >> >> U-Boot 2015.07-rc2-8-g594f506 (Jun 10 2015 - 16:01:36 +0800) >> >> Boot Log: >> CPU: Freescale i.MX6Q rev2.0 996 MHz (running at 792 MHz) >> CPU: Automotive temperature grade (-40C to 125C) at 36C >> Reset cause: POR >> Board: MX6Q-Sabreauto revA >> I2C: ready >> DRAM: 2 GiB >> PMIC: PFUZE100 ID=0x10 >> Flash: 32 MiB >> NAND: 4096 MiB >> MMC: FSL_SDHC: 0 >> *** Warning - bad CRC, using default environment >> >> No panel detected: default to HDMI >> Display: HDMI (1024x768) >> In:serial >> Out: serial >> Err: serial >> Net: FEC [PRIME] >> Error: FEC address not set. >> >> Hit any key to stop autoboot: 0 >> >> Signed-off-by: Robin Gong >> Signed-off-by: Ye.Li >> Signed-off-by: Peng Fan >> --- >> board/freescale/mx6qsabreauto/mx6qp.cfg | 158 >> ++ >> board/freescale/mx6qsabreauto/mx6qsabreauto.c | 32 +- >> configs/mx6qpsabreauto_defconfig | 5 + >> include/configs/mx6qsabreauto.h | 5 +- >> 4 files changed, 194 insertions(+), 6 deletions(-) >> create mode 100644 board/freescale/mx6qsabreauto/mx6qp.cfg >> create mode 100644 configs/mx6qpsabreauto_defconfig >> >> diff --git a/board/freescale/mx6qsabreauto/mx6qp.cfg >> b/board/freescale/mx6qsabreauto/mx6qp.cfg >> new file mode 100644 >> index 000..5d55bcc >> --- /dev/null >> +++ b/board/freescale/mx6qsabreauto/mx6qp.cfg >> @@ -0,0 +1,158 @@ >> +/* >> + * Copyright (C) 2015 Freescale Semiconductor, Inc. >> + * >> + * SPDX-License-Identifier: GPL-2.0+ >> + * >> + * Refer doc/README.imximage for more details about how-to configure >> + * and create imximage boot image >> + * >> + * The syntax is taken as close as possible with the kwbimage >> + */ >> +/* image version */ >> + >> +#define __ASSEMBLY__ >> +#include >> + >> +IMAGE_VERSION 2 >> + >> +/* >> + * Boot Device : one of spi, sd, eimnor, nand, sata: >> + * spinor: flash_offset: 0x0400 >> + * nand: flash_offset: 0x0400 >> + * sata: flash_offset: 0x0400 >> + * sd/mmc: flash_offset: 0x0400 >> + * eimnor: flash_offset: 0x1000 >> + */ >> + >> +#if defined(CONFIG_SYS_BOOT_EIMNOR) > > >? Will remove this in v2. > >Not defined in U-Boot mainline. > >> +BOOT_FROM nor >> +#else /* others has the same flash_offset as sd */ >> +BOOT_FROM sd >> +#endif >> + >> +#ifdef CONFIG_USE_PLUGIN >> +/*PLUGINplugin-binary-fileIRAM_FREE_START_ADDR*/ >> +PLUGIN board/freescale/mx6qsabreauto/plugin.bin 0x00907000 > >Ditto, Will remove this in v2. > >> +#else >> + >> +#ifdef CONFIG_SECURE_BOOT >> +CSF 0x2000 >> +#endif >> + >> +/* >> + * Device Configuration Data (DCD) >> + * >> + * Each entry must have the format: >> + * Addr-type AddressValue >> + * >> + * where: >> + * Addr-type register length (1,2 or 4 bytes) >> + * Address absolute address of the register >> + * value value to be stored in the register >> + */ >> +DATA 4 0x020e0798 0x000C >> +DATA 4 0x020e0758 0x >> +DATA 4 0x020e0588 0x0030 >> +DATA 4 0x020e0594 0x0030 >> +DATA 4 0x020e056c 0x0030 >> +DATA 4 0x020e0578 0x0030 >> +DATA 4 0x020e074c 0x0030 >> +DATA 4 0x020e057c 0x0030 >> +DATA 4 0x020e058c 0x >> +DATA 4 0x020e059c 0x0030 >> +DATA 4 0x020e05a0 0x0030 >> +DATA 4 0x020e078c 0x0030 >> +DATA 4 0x020e0750 0x0002 > >Until here, the same as mx6qsabreauto > > >> +DATA 4 0x020e05a8 0x0030 >> +DATA 4 0x020e05b0 0x0030 >> +DATA 4 0x020e0524 0x0030 >> +DATA 4 0x020e051c 0x0030 >> +DATA 4 0x020e0518 0x0030 >> +DATA 4 0x020e050c 0x0030 >> +DATA 4 0x020e05b8 0x0030 >> +DATA 4 0x020e05c0 0x0030 > >Here is 40 ohm (reset value, do you need to set it ?) instead of 48 ohm >as on 6qauto. Anyway, is there some chance to add SPL support for this >board ? DDR setup can be then managed inside SPL code dropping this part >and a single image for sabreauto6q and sabreauto6qp could be possible. > We get the script from IC team, so there maybe many duplicated configuration. I get your concern that SPL can give many benifits. Current, we do not have plan to add SPL support. >Of course, I will not block the patchset if this is not planned, but >maybe you can consider it. In any case, some factorizing must be done >instead of duplicating the cfg code. Using SPL, we can remove duplicated ddr cfg, but using cfg file, not that easy. I'll try. > >> +DATA 4 0x020e0774 0x0002 >> +DATA 4 0x020e0784 0x0030 >> +DATA 4 0x020e0788 0x0030 >> +DATA 4 0x020e0794 0x0030 >> +DATA 4 0x020e079c 0x0030 >> +DATA 4 0x020e07a0 0x0030 >> +DATA
Re: [U-Boot] [PATCH 2/8] imx: mx6: Add MX6DQP CPU rev type
Hi Peng, On 10/06/2015 12:01, Peng Fan wrote: >>> +#define is_mx6dqp() ((is_cpu_type(MXC_CPU_MX6Q) || \ >>> +is_cpu_type(MXC_CPU_MX6D)) && \ >>> +(is_soc_rev(CHIP_REV_2_0) >= 0)) >>> + >> >> As "insider" you could better explain me: it looks like there will be >> not a Quad/Dual with an increased chip revision. The new chip revision >> for i.MX6 is really the QP (P=perfect, as I see some workaround can be >> removed !) >> >> Is it correct ? Else this conflicts if a 6Q with a revision > 2 will be >> released. > P mean plus. I know, it was only a joke ;-). There is not "perfect" SOC. > It is from 6Q, since ic did not give new chip id for id, we use > revision. This is ok now until a 6Q with revision 2 or greater will be released. Then there is a conflict and u-boot cannot identify a 6QP from a 6Q. But it is still ok if Freescale will *never* plan to release a newer 6Q. Is it ? Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [RFC PATCH v1] README: Describe CONFIG_SYS_NO_FLASH
Unlike most configuration options defining this actually disables support for a feature (parallel flash). Eventually the logic behind this should probably be flipped so that '#ifndef CONFIG_SYS_NO_FLASH' becomes '#ifdef CONFIG_HAS_PARALLEL_FLASH' but for now lets document the existing behaviour. Signed-off-by: Chris Packham --- So this is my attempt to describe (my understanding of) how this option should be used. Any suggestions for improvement are most welcome. README | 13 + 1 file changed, 13 insertions(+) diff --git a/README b/README index 3b406c2..c3fa549 100644 --- a/README +++ b/README @@ -3037,6 +3037,19 @@ CBFS (Coreboot Filesystem) support this is instead controlled by the value of /config/load-environment. +- Parallel Flash support: + CONFIG_SYS_NO_FLASH + + Traditionally U-boot was run on systems with parallel NOR + flash. This option is used to disable support for parallel NOR + flash. This option should be defined if the board does not have + parallel flash. + + If this option is not defined one of the generic flash drivers + (e.g. CONFIG_FLASH_CFI_DRIVER or CONFIG_ST_SMI) must be + selected or the board must provide an implementation of the + flash API (see include/flash.h). + - DataFlash Support: CONFIG_HAS_DATAFLASH -- 2.3.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] imx: mx6qp: Enable PRG clock for IPU
On Wed, Jun 10, 2015 at 11:24:04AM +0200, Stefano Babic wrote: >On 10/06/2015 10:06, Peng Fan wrote: >> From: "Ye.Li" >> >> The i.MX6QP has a PRG module, need to enable its clock for using >> IPU. >> >> Signed-off-by: Peng Fan >> Signed-off-by: Brown Oliver >> Signed-off-by: Ye.Li >> --- >> arch/arm/cpu/armv7/mx6/clock.c | 6 ++ >> 1 file changed, 6 insertions(+) >> >> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c >> index 36cd5a8..ae1b4cc 100644 >> --- a/arch/arm/cpu/armv7/mx6/clock.c >> +++ b/arch/arm/cpu/armv7/mx6/clock.c >> @@ -861,6 +861,12 @@ void enable_ipu_clock(void) >> reg = readl(&mxc_ccm->CCGR3); >> reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK; >> writel(reg, &mxc_ccm->CCGR3); >> + >> +#ifdef CONFIG_MX6QP >> +reg = readl(&mxc_ccm->CCGR6); >> +reg |= MXC_CCM_CCGR6_PRG_CLK0_MASK; >> +writel(reg, &mxc_ccm->CCGR6); > >This is easy to replace with runtime detection. Will fix in v2. > >> +#endif >> } >> #endif >> /***/ >> > >Best regards, >Stefano Babic > >-- >= >DENX Software Engineering GmbH, Managing Director: Wolfgang Denk >HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de >= Regards, Peng -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] imx: mx6: ccm: Change the clock settings for i.MX6QP
Hi Stefano,
On Wed, Jun 10, 2015 at 11:23:10AM +0200, Stefano Babic wrote:
>Hi Peng,
>
>On 10/06/2015 10:06, Peng Fan wrote:
>> Since i.MX6QP changes some CCM registers, so modify the clocks settings to
>> follow the hardware changes.
>>
>> A new CONFIG_MX6QP is introduced here and is used for the CCM difference.
>> At default CONFIG_MX6Q is enabled along with the CONFIG_MX6QP.
>>
>> Signed-off-by: Ye.Li
>> Signed-off-by: Peng Fan
>> ---
>> arch/arm/cpu/armv7/mx6/clock.c | 13 +---
>> arch/arm/cpu/armv7/mx6/soc.c | 5 ++-
>> arch/arm/include/asm/arch-mx6/crm_regs.h | 55
>>
>> include/configs/mx6_common.h | 3 ++
>> 4 files changed, 57 insertions(+), 19 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
>> index ae99945..36cd5a8 100644
>> --- a/arch/arm/cpu/armv7/mx6/clock.c
>> +++ b/arch/arm/cpu/armv7/mx6/clock.c
>> @@ -323,7 +323,7 @@ static u32 get_ipg_per_clk(void)
>> u32 reg, perclk_podf;
>>
>> reg = __raw_readl(&imx_ccm->cscmr1);
>> -#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
>> +#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX) ||
>> defined(CONFIG_MX6QP))
>> if (reg & MXC_CCM_CSCMR1_PER_CLK_SEL_MASK)
>> return MXC_HCLK; /* OSC 24Mhz */
>
>I have a general issue. We already manage to have support for multiple
>variants of MX6 (at least, dual/quad/solo) with a single image. We get
>it dropping nasty #ifdef in case of quad/dual. I assume there are only
>slight changes in layout for the 6QP. Cannot we manage these changes at
>runtime instead of introducing a compiler switch ?
Yeah, better do runtime check. Will fix this in v2.
>
>> #endif
>> @@ -337,7 +337,7 @@ static u32 get_uart_clk(void)
>> u32 reg, uart_podf;
>> u32 freq = decode_pll(PLL_USBOTG, MXC_HCLK) / 6; /* static divider */
>> reg = __raw_readl(&imx_ccm->cscdr1);
>> -#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
>> +#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX) ||
>> defined(CONFIG_MX6QP))
>> if (reg & MXC_CCM_CSCDR1_UART_CLK_SEL)
>> freq = MXC_HCLK;
>> #endif
>> @@ -352,8 +352,13 @@ static u32 get_cspi_clk(void)
>> u32 reg, cspi_podf;
>>
>> reg = __raw_readl(&imx_ccm->cscdr2);
>> -reg &= MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK;
>> -cspi_podf = reg >> MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
>> +cspi_podf = (reg & MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK)
>> +>> MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
>> +
>> +#if defined(CONFIG_MX6QP)
>> +if (reg & MXC_CCM_CSCDR2_ECSPI_CLK_SEL_MASK)
>> +return MXC_HCLK / (cspi_podf + 1);
>> +#endif
>>
>> return decode_pll(PLL_USBOTG, MXC_HCLK) / (8 * (cspi_podf + 1));
>> }
>> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
>> index e3474e7..5eea9d9 100644
>> --- a/arch/arm/cpu/armv7/mx6/soc.c
>> +++ b/arch/arm/cpu/armv7/mx6/soc.c
>> @@ -335,9 +335,12 @@ static void set_ahb_rate(u32 val)
>> static void clear_mmdc_ch_mask(void)
>> {
>> struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
>> +u32 reg;
>> +reg = readl(&mxc_ccm->ccdr);
>>
>> /* Clear MMDC channel mask */
>> -writel(0, &mxc_ccm->ccdr);
>> +reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK | MXC_CCM_CCDR_MMDC_CH0_HS_MASK);
>> +writel(reg, &mxc_ccm->ccdr);
>> }
>>
>> static void init_bandgap(void)
>> diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
>> b/arch/arm/include/asm/arch-mx6/crm_regs.h
>> index 887d048..576dabe 100644
>> --- a/arch/arm/include/asm/arch-mx6/crm_regs.h
>> +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
>> @@ -113,7 +113,7 @@ struct mxc_ccm_reg {
>> #define MXC_CCM_CCR_WB_COUNT_MASK 0x7
>> #define MXC_CCM_CCR_WB_COUNT_OFFSET (1 << 16)
>> #define MXC_CCM_CCR_COSC_EN (1 << 12)
>> -#ifdef CONFIG_MX6SX
>> +#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6QP))
>> #define MXC_CCM_CCR_OSCNT_MASK 0x7F
>> #else
>> #define MXC_CCM_CCR_OSCNT_MASK 0xFF
>> @@ -123,6 +123,9 @@ struct mxc_ccm_reg {
>> /* Define the bits in register CCDR */
>> #define MXC_CCM_CCDR_MMDC_CH1_HS_MASK (1 << 16)
>> #define MXC_CCM_CCDR_MMDC_CH0_HS_MASK (1 << 17)
>> +#ifdef CONFIG_MX6QP
>> +#define MXC_CCM_CCDR_MMDC_CH1_AXI_ROOT_CG (1 << 18)
>> +#endif
>>
>> /* Define the bits in register CSR */
>> #define MXC_CCM_CSR_COSC_READY (1 << 5)
>> @@ -196,7 +199,11 @@ struct mxc_ccm_reg {
>> #define MXC_CCM_CBCMR_GPU3D_CORE_CLK_SEL_MASK (0x3 << 4)
>> #define MXC_CCM_CBCMR_GPU3D_CORE_CLK_SEL_OFFSET 4
>> #ifndef CONFIG_MX6SX
>> +#ifdef CONFIG_MX6QP
>> +#define MXC_CCM_CBCMR_PRE_CLK_SEL (1 << 1)
>> +#else
>> #define MXC_CCM_CBCMR_GPU3D_AXI_CLK_SEL (1 << 1)
>> +#endif
>> #define
Re: [U-Boot] [PATCH 2/8] imx: mx6: Add MX6DQP CPU rev type
Hi Stefano,
On Wed, Jun 10, 2015 at 11:19:07AM +0200, Stefano Babic wrote:
>Hi Peng,
>
>On 10/06/2015 10:06, Peng Fan wrote:
>> Add new cpu type for i.MX6DQP and providing a dynamical
>> detecting function.
>>
>> Signed-off-by: Peng Fan
>> Signed-off-by: Ye.Li
>> ---
>> arch/arm/cpu/armv7/mx6/soc.c | 4 +++-
>> arch/arm/include/asm/arch-mx6/imx-regs.h | 1 +
>> arch/arm/include/asm/arch-mx6/sys_proto.h | 6 ++
>> 3 files changed, 10 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
>> index b21bd03..29de624 100644
>> --- a/arch/arm/cpu/armv7/mx6/soc.c
>> +++ b/arch/arm/cpu/armv7/mx6/soc.c
>> @@ -62,6 +62,7 @@ u32 get_cpu_rev(void)
>> struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
>> u32 reg = readl(&anatop->digprog_sololite);
>> u32 type = ((reg >> 16) & 0xff);
>> +u32 major;
>>
>> if (type != MXC_CPU_MX6SL) {
>> reg = readl(&anatop->digprog);
>> @@ -79,8 +80,9 @@ u32 get_cpu_rev(void)
>> }
>>
>> }
>> +major = ((reg >> 8) & 0xff);
>> reg &= 0xff;/* mx6 silicon revision */
>> -return (type << 12) | (reg + 0x10);
>> +return (type << 12) | (reg + (0x10 * (major + 1)));
>> }
>>
>> /*
>> diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
>> b/arch/arm/include/asm/arch-mx6/imx-regs.h
>> index 0d38d45..35a324c 100644
>> --- a/arch/arm/include/asm/arch-mx6/imx-regs.h
>> +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
>> @@ -312,6 +312,7 @@
>> #define CHIP_REV_1_0 0x10
>> #define CHIP_REV_1_2 0x12
>> #define CHIP_REV_1_5 0x15
>> +#define CHIP_REV_2_0 0x20
>> #ifndef CONFIG_MX6SX
>> #define IRAM_SIZE0x0004
>> #else
>> diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h
>> b/arch/arm/include/asm/arch-mx6/sys_proto.h
>> index 9c827c9..c1d9c6d 100644
>> --- a/arch/arm/include/asm/arch-mx6/sys_proto.h
>> +++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
>> @@ -2,6 +2,8 @@
>> * (C) Copyright 2009
>> * Stefano Babic, DENX Software Engineering, sba...@denx.de.
>> *
>> + * (C) Copyright 2009-2015 Freescale Semiconductor, Inc.
>> + *
>> * SPDX-License-Identifier: GPL-2.0+
>> */
>>
>
>mmhhh..we have already discussed this topic, Copyright should not be
>changed by small changes in a file.
oh. I missed to remove this. Thanks for correcting me.
>
>> @@ -30,6 +32,10 @@ const char *get_imx_type(u32 imxtype);
>> unsigned imx_ddr_size(void);
>> void set_chipselect_size(int const);
>>
>> +#define is_mx6dqp() ((is_cpu_type(MXC_CPU_MX6Q) || \
>> + is_cpu_type(MXC_CPU_MX6D)) && \
>> + (is_soc_rev(CHIP_REV_2_0) >= 0))
>> +
>
>As "insider" you could better explain me: it looks like there will be
>not a Quad/Dual with an increased chip revision. The new chip revision
>for i.MX6 is really the QP (P=perfect, as I see some workaround can be
>removed !)
>
>Is it correct ? Else this conflicts if a 6Q with a revision > 2 will be
>released.
P mean plus. It is from 6Q, since ic did not give new chip id for id, we use
revision.
>
>Best regards,
>Stefano Babic
>
Regards,
Peng.
>--
>=
>DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
>HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
>Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
>=
--
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device
On Wednesday, June 10, 2015 at 09:45:40 AM, Pali Rohár wrote: > On Wednesday 10 June 2015 06:27:37 Marek Vasut wrote: > > On Tuesday, June 09, 2015 at 06:28:29 PM, Pali Rohár wrote: > > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > > I would be very glad to see board maintainers give a go > > > > at the changeset before it gets merged, especially on devices like > > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f (see > > > other email thread > > > > Would be nice if you added a link to the thread in some mail archive ... > > What about searching for last emails ;-) "See other email thread" is making my search very easy indeed ... > It took me less then minute: > http://lists.denx.de/pipermail/u-boot/2015-June/216237.html > > Patch with my fix there: > http://lists.denx.de/pipermail/u-boot/2015-June/216241.html Best regards, Marek Vasut ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] ARM: cache: add an empty stub function for invalidate/flush dcache
On Wednesday, June 10, 2015 at 11:49:54 AM, Josh Wu wrote: > On 6/9/2015 9:11 PM, Tom Rini wrote: > > On Tue, Jun 09, 2015 at 11:54:14AM +0800, Josh Wu wrote: > >> Hi, Tom > >> > >> On 6/8/2015 9:20 PM, Tom Rini wrote: > >>> On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote: > On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote: > > Hi, Marek > > > > On 6/5/2015 9:18 PM, Marek Vasut wrote: > >> On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote: > >>> Since some driver like ohci, lcd used dcache functions. But some > >>> ARM cpu don't implement the > >>> invalidate_dcache_range()/flush_dcache_range() functions. > >>> > >>> To avoid compiling errors this patch adds an weak empty stub > >>> function for all ARM cpu. > >>> > >>> And each cpu can implement its own implementation. If not > >>> implemented by default it will use an empty function. > >>> > >>> Signed-off-by: Josh Wu > >>> --- > >>> > >>> Changes in v2: new added > >>> > >>>arch/arm/lib/cache.c | 9 + > >>>1 file changed, 9 insertions(+) > >> > >> So, why exactly can't this be entirely common code , but a > >> CPU-specific code ? :) > > > > Do you mean to make those empty functions as common code for all arch > > cpu to use? > > Yes. > > > It seems there is no place to put common code for all arch cpu. > > Isn't that what the common/ directory is for ? ;-) > >>> > >>> No, this is making something common for the sake of making it common > >>> rather than good architecutre of the code I think. We aren't going to > >>> share real cache functions just these dummy ones. > >> > >> So it is the right place: arch/arm/lib/cache.c to put the dummy > >> cache function. > > > > Yes. > > > >>> We may re-evaluate > >>> our dummy ones at some point in the future when people try and use some > >>> particular combination harder, see for example the PowerPC dummy cache > >>> functions we just recently dropped. Thanks! > >> > >> If this patch set are ok for you. I will sent more patches to drop > >> the dummy cache functions in /cpu/ folders. > > > > Right, that's the best palce I think, baring an existing arch having a > > location for weak cache functions already (like arm does). > > > >> Also the flush_cache() in arch/arm/lib/cache.c can be dropped and > >> just call flush_dcache_range() as the ARM1136, ARM926ejs alreay > >> implemented their own flush_cache(). > > > > Nope, other things fail if you do that (vpac270_nor_256 and 24 others at > > least so far in my test build). > > Does it fail to compile or on running? As I don't have the board to test > the binary, but I don't find any compile error when I apply such a patch. > Maybe it is better to sent out my patch for you to check. VPAC is PXA270 and to my knowledge, PXA has no cache support in place at all. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 0/8] omap-common: Common boot code OMAP3 support and SYS_BOOT-based fallback boot device
Le mardi 09 juin 2015 à 20:34 +0200, Pali Rohár a écrit : > On Tuesday 09 June 2015 18:28:29 Pali Rohár wrote: > > On Monday 08 June 2015 23:24:18 Paul Kocialkowski wrote: > > > I would be very glad to see board maintainers give a go > > > at the changeset before it gets merged, especially on devices like > > > the Nokia RX-51 (N900) where some specific adaptation was needed. > > > > So U-Boot is broken since e11c6c279d823dc0d2f470c5c2e3c0a9854a640f > > (see other email thread). Until somebody fix that broken commit, I > > cannot test your new patches in qemu or on (real) Nokia N900. > > Now I tested this patch series on top of u-boot master with applied my > patch "Nokia RX-51: Fix calculating return address in save_boot_params". > > And it really as I thought broke booting U-Boot on Nokia N900 in qemu. I'm confused here -- did you try booting on the actual device or in qemu? > So this patch series is NAK from my side. Thanks for testing. Of course, the point is to make another version of the patch set that fits the N900 too, since we really need to integrate the omap3 to the common omap boot mechanism anyways. I may be able to get my hands on a N900 in a short while. If you're interested, you're welcome to look at the issue and suggest what changes should be made to make the set compatible with the N900! -- Paul Kocialkowski, Replicant developer Replicant is a fully free Android distribution running on several devices, a free software mobile operating system putting the emphasis on freedom and privacy/security. Website: http://www.replicant.us/ Blog: http://blog.replicant.us/ Wiki/tracker/forums: http://redmine.replicant.us/ signature.asc Description: This is a digitally signed message part ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v2 1/3] ARM: cache: add an empty stub function for invalidate/flush dcache
On 6/9/2015 9:11 PM, Tom Rini wrote: On Tue, Jun 09, 2015 at 11:54:14AM +0800, Josh Wu wrote: Hi, Tom On 6/8/2015 9:20 PM, Tom Rini wrote: On Mon, Jun 08, 2015 at 10:26:29AM +0200, Marek Vasut wrote: On Monday, June 08, 2015 at 04:05:04 AM, Josh Wu wrote: Hi, Marek On 6/5/2015 9:18 PM, Marek Vasut wrote: On Friday, June 05, 2015 at 09:47:30 AM, Josh Wu wrote: Since some driver like ohci, lcd used dcache functions. But some ARM cpu don't implement the invalidate_dcache_range()/flush_dcache_range() functions. To avoid compiling errors this patch adds an weak empty stub function for all ARM cpu. And each cpu can implement its own implementation. If not implemented by default it will use an empty function. Signed-off-by: Josh Wu --- Changes in v2: new added arch/arm/lib/cache.c | 9 + 1 file changed, 9 insertions(+) So, why exactly can't this be entirely common code , but a CPU-specific code ? :) Do you mean to make those empty functions as common code for all arch cpu to use? Yes. It seems there is no place to put common code for all arch cpu. Isn't that what the common/ directory is for ? ;-) No, this is making something common for the sake of making it common rather than good architecutre of the code I think. We aren't going to share real cache functions just these dummy ones. So it is the right place: arch/arm/lib/cache.c to put the dummy cache function. Yes. We may re-evaluate our dummy ones at some point in the future when people try and use some particular combination harder, see for example the PowerPC dummy cache functions we just recently dropped. Thanks! If this patch set are ok for you. I will sent more patches to drop the dummy cache functions in /cpu/ folders. Right, that's the best palce I think, baring an existing arch having a location for weak cache functions already (like arm does). Also the flush_cache() in arch/arm/lib/cache.c can be dropped and just call flush_dcache_range() as the ARM1136, ARM926ejs alreay implemented their own flush_cache(). Nope, other things fail if you do that (vpac270_nor_256 and 24 others at least so far in my test build). Does it fail to compile or on running? As I don't have the board to test the binary, but I don't find any compile error when I apply such a patch. Maybe it is better to sent out my patch for you to check. Best Regards, Josh Wu ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 8/8] imx: mx6qp: Adjust AQos settings for peripherals
Hi Peng, On 10/06/2015 10:06, Peng Fan wrote: > From: "Ye.Li" > > To resolve USB camera bandwidth issue, the patch sets recommended AQoS > setting from IC team value for peripheral and only on imx6qp. > > The address is: 0xbb0608, the value is: 0x8201 > I understand that, if you fight against this issue, the comment can be clear and maybe redundant. Please add comments in code describing the issue, and extend the commit log to better explain the issue and the solution. > Signed-off-by: Ye.Li > Signed-off-by: Peng Fan > --- > arch/arm/cpu/armv7/mx6/soc.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c > index 5eea9d9..0de71d56 100644 > --- a/arch/arm/cpu/armv7/mx6/soc.c > +++ b/arch/arm/cpu/armv7/mx6/soc.c > @@ -424,6 +424,9 @@ int arch_cpu_init(void) > > init_src(); > > + if (is_mx6dqp()) > + writel(0x8201, 0xbb0608); > + > return 0; > } > > Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 7/8] imx: mx6qpsabreauto: Add MX6QP SABREAUTO CPU3 board support
Hi Peng, On 10/06/2015 10:06, Peng Fan wrote: > 1. Add DDR script for mx6qpsabreauto board. > 2. On CPU3 board, enet RGMII tx clock is from internal PLL. Set the GPR5[9] >and init the enet pll output to 125Mhz. > 3. On CPU3 board, SW1ABC=VDDSOC_IN, SW2=VDDARM_IN. > > Build target: mx6qpsabreauto_config > > U-Boot 2015.07-rc2-8-g594f506 (Jun 10 2015 - 16:01:36 +0800) > > Boot Log: > CPU: Freescale i.MX6Q rev2.0 996 MHz (running at 792 MHz) > CPU: Automotive temperature grade (-40C to 125C) at 36C > Reset cause: POR > Board: MX6Q-Sabreauto revA > I2C: ready > DRAM: 2 GiB > PMIC: PFUZE100 ID=0x10 > Flash: 32 MiB > NAND: 4096 MiB > MMC: FSL_SDHC: 0 > *** Warning - bad CRC, using default environment > > No panel detected: default to HDMI > Display: HDMI (1024x768) > In:serial > Out: serial > Err: serial > Net: FEC [PRIME] > Error: FEC address not set. > > Hit any key to stop autoboot: 0 > > Signed-off-by: Robin Gong > Signed-off-by: Ye.Li > Signed-off-by: Peng Fan > --- > board/freescale/mx6qsabreauto/mx6qp.cfg | 158 > ++ > board/freescale/mx6qsabreauto/mx6qsabreauto.c | 32 +- > configs/mx6qpsabreauto_defconfig | 5 + > include/configs/mx6qsabreauto.h | 5 +- > 4 files changed, 194 insertions(+), 6 deletions(-) > create mode 100644 board/freescale/mx6qsabreauto/mx6qp.cfg > create mode 100644 configs/mx6qpsabreauto_defconfig > > diff --git a/board/freescale/mx6qsabreauto/mx6qp.cfg > b/board/freescale/mx6qsabreauto/mx6qp.cfg > new file mode 100644 > index 000..5d55bcc > --- /dev/null > +++ b/board/freescale/mx6qsabreauto/mx6qp.cfg > @@ -0,0 +1,158 @@ > +/* > + * Copyright (C) 2015 Freescale Semiconductor, Inc. > + * > + * SPDX-License-Identifier: GPL-2.0+ > + * > + * Refer doc/README.imximage for more details about how-to configure > + * and create imximage boot image > + * > + * The syntax is taken as close as possible with the kwbimage > + */ > +/* image version */ > + > +#define __ASSEMBLY__ > +#include > + > +IMAGE_VERSION 2 > + > +/* > + * Boot Device : one of spi, sd, eimnor, nand, sata: > + * spinor: flash_offset: 0x0400 > + * nand: flash_offset: 0x0400 > + * sata: flash_offset: 0x0400 > + * sd/mmc: flash_offset: 0x0400 > + * eimnor: flash_offset: 0x1000 > + */ > + > +#if defined(CONFIG_SYS_BOOT_EIMNOR) ? Not defined in U-Boot mainline. > +BOOT_FROMnor > +#else /* others has the same flash_offset as sd */ > +BOOT_FROMsd > +#endif > + > +#ifdef CONFIG_USE_PLUGIN > +/*PLUGINplugin-binary-fileIRAM_FREE_START_ADDR*/ > +PLUGIN board/freescale/mx6qsabreauto/plugin.bin 0x00907000 Ditto, > +#else > + > +#ifdef CONFIG_SECURE_BOOT > +CSF 0x2000 > +#endif > + > +/* > + * Device Configuration Data (DCD) > + * > + * Each entry must have the format: > + * Addr-type AddressValue > + * > + * where: > + * Addr-type register length (1,2 or 4 bytes) > + * Address absolute address of the register > + * value value to be stored in the register > + */ > +DATA 4 0x020e0798 0x000C > +DATA 4 0x020e0758 0x > +DATA 4 0x020e0588 0x0030 > +DATA 4 0x020e0594 0x0030 > +DATA 4 0x020e056c 0x0030 > +DATA 4 0x020e0578 0x0030 > +DATA 4 0x020e074c 0x0030 > +DATA 4 0x020e057c 0x0030 > +DATA 4 0x020e058c 0x > +DATA 4 0x020e059c 0x0030 > +DATA 4 0x020e05a0 0x0030 > +DATA 4 0x020e078c 0x0030 > +DATA 4 0x020e0750 0x0002 Until here, the same as mx6qsabreauto > +DATA 4 0x020e05a8 0x0030 > +DATA 4 0x020e05b0 0x0030 > +DATA 4 0x020e0524 0x0030 > +DATA 4 0x020e051c 0x0030 > +DATA 4 0x020e0518 0x0030 > +DATA 4 0x020e050c 0x0030 > +DATA 4 0x020e05b8 0x0030 > +DATA 4 0x020e05c0 0x0030 Here is 40 ohm (reset value, do you need to set it ?) instead of 48 ohm as on 6qauto. Anyway, is there some chance to add SPL support for this board ? DDR setup can be then managed inside SPL code dropping this part and a single image for sabreauto6q and sabreauto6qp could be possible. Of course, I will not block the patchset if this is not planned, but maybe you can consider it. In any case, some factorizing must be done instead of duplicating the cfg code. > +DATA 4 0x020e0774 0x0002 > +DATA 4 0x020e0784 0x0030 > +DATA 4 0x020e0788 0x0030 > +DATA 4 0x020e0794 0x0030 > +DATA 4 0x020e079c 0x0030 > +DATA 4 0x020e07a0 0x0030 > +DATA 4 0x020e07a4 0x0030 > +DATA 4 0x020e07a8 0x0030 > +DATA 4 0x020e0748 0x0030 > +DATA 4 0x020e05ac 0x0030 > +DATA 4 0x020e05b4 0x0030 > +DATA 4 0x020e0528 0x0030 > +DATA 4 0x020e0520 0x0030 > +DATA 4 0x020e0514 0x0030 > +DATA 4 0x020e0510 0x0030 > +DATA 4 0x020e05bc 0x0030 > +DATA 4 0x020e05c4 0x0030 > +DATA 4 0x021b0800 0xa1390003 > +DATA 4 0x021b080c 0x001b001e > +DATA 4 0x021b0810 0x002e0029 > +DATA 4 0x021b480c 0x001b002a > +DATA 4 0x021b4810 0x0019002c > +DATA 4 0x021b083c 0x43240334 > +DATA 4 0x021b
[U-Boot] [PATCH 3/3] am43xx_evm: add eth boot support
add cpsw ethernet boot mode support to download spl and u-boot.img via tftp protocol. Also adding a seperate config for ethernet boot mode as the default build falcon mode and environment on MMC is defined for ethernet boot mode environment should be set to nowhere. Signed-off-by: Mugunthan V N --- configs/am43xx_evm_ethboot_defconfig | 5 + include/configs/am43xx_evm.h | 10 +- 2 files changed, 14 insertions(+), 1 deletion(-) create mode 100644 configs/am43xx_evm_ethboot_defconfig diff --git a/configs/am43xx_evm_ethboot_defconfig b/configs/am43xx_evm_ethboot_defconfig new file mode 100644 index 000..9e0af18 --- /dev/null +++ b/configs/am43xx_evm_ethboot_defconfig @@ -0,0 +1,5 @@ +CONFIG_ARM=y +CONFIG_TARGET_AM43XX_EVM=y +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,ETH_BOOT_SUPPORT" +CONFIG_CMD_NET=y diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index 3bd9abd..1be8a20 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -314,11 +314,11 @@ #endif +#ifndef CONFIG_SPL_BUILD /* CPSW Ethernet */ #define CONFIG_CMD_DHCP #define CONFIG_CMD_PING #define CONFIG_CMD_MII -#define CONFIG_DRIVER_TI_CPSW #define CONFIG_MII #define CONFIG_BOOTP_DEFAULT #define CONFIG_BOOTP_DNS @@ -328,11 +328,19 @@ #define CONFIG_BOOTP_SUBNETMASK #define CONFIG_NET_RETRY_COUNT 10 #define CONFIG_PHY_GIGE +#endif + +#define CONFIG_DRIVER_TI_CPSW #define CONFIG_PHYLIB #define CONFIG_SPL_ENV_SUPPORT #define CONFIG_SPL_NET_VCI_STRING "AM43xx U-Boot SPL" +#if defined(CONFIG_SPL_BUILD) && defined(CONFIG_ETH_BOOT_SUPPORT) +#undef CONFIG_ENV_IS_IN_FAT +#define CONFIG_ENV_IS_NOWHERE +#endif + #define CONFIG_SPL_ETH_SUPPORT #define CONFIG_SPL_NET_SUPPORT #define CONFIG_SYS_RX_ETH_BUFFER 64 -- 2.4.2.387.gf86f31a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/3] am43xx_evm: add usb host boot support
While booting via usb host mode, ROM uses DMA to copy MLO over USB so ARM internal RAM cannot be used. Adding USB host boot support by introducing new config target which sets SPL_TEXT_BASE to OCMC ram. Signed-off-by: Mugunthan V N --- configs/am43xx_evm_usbhost_boot_defconfig | 5 + include/configs/am43xx_evm.h | 9 + 2 files changed, 14 insertions(+) create mode 100644 configs/am43xx_evm_usbhost_boot_defconfig diff --git a/configs/am43xx_evm_usbhost_boot_defconfig b/configs/am43xx_evm_usbhost_boot_defconfig new file mode 100644 index 000..9455707 --- /dev/null +++ b/configs/am43xx_evm_usbhost_boot_defconfig @@ -0,0 +1,5 @@ +CONFIG_ARM=y +CONFIG_TARGET_AM43XX_EVM=y +CONFIG_SPL=y +CONFIG_SYS_EXTRA_OPTIONS="SERIAL1,CONS_INDEX=1,NAND,USBHOST_BOOT" +CONFIG_CMD_NET=y diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index e5b10ad..3bd9abd 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -42,7 +42,16 @@ #define CONFIG_POWER_TPS62362 /* SPL defines. */ +#ifdef CONFIG_USBHOST_BOOT +/* + * For USB host boot, ROM uses DMA for copying MLO from USB storage + * and ARM internal ram is not accessible for DMA, so SPL text base + * should be in OCMC ram + */ +#define CONFIG_SPL_TEXT_BASE 0x40300350 +#else #define CONFIG_SPL_TEXT_BASE 0x402F4000 +#endif #define CONFIG_SPL_MAX_SIZE(220 << 10) /* 220KB */ #define CONFIG_SYS_SPL_ARGS_ADDR (CONFIG_SYS_SDRAM_BASE + \ (128 << 20)) -- 2.4.2.387.gf86f31a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 0/3] Add usb host and ethernet boot support
This patch set adds support for usb host boot and ethernet boot support Mugunthan V N (2): am43xx_evm: add usb host boot support am43xx_evm: add eth boot support Tom Rini (1): am43xx: Update CONFIG_SPL_TEXT_BASE configs/am43xx_evm_ethboot_defconfig | 5 + configs/am43xx_evm_usbhost_boot_defconfig | 5 + include/configs/am43xx_evm.h | 19 ++- 3 files changed, 28 insertions(+), 1 deletion(-) create mode 100644 configs/am43xx_evm_ethboot_defconfig create mode 100644 configs/am43xx_evm_usbhost_boot_defconfig -- 2.4.2.387.gf86f31a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 1/3] am43xx: Update CONFIG_SPL_TEXT_BASE
From: Tom Rini With 1.2 silicon this is now the documented starting usable point for downloading images to (and corrects a problem with peripheral booting with prior silicon). Prior silicon is OK using this address as well. Signed-off-by: Tom Rini Signed-off-by: Mugunthan V N --- include/configs/am43xx_evm.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/configs/am43xx_evm.h b/include/configs/am43xx_evm.h index d4f4c23..e5b10ad 100644 --- a/include/configs/am43xx_evm.h +++ b/include/configs/am43xx_evm.h @@ -42,7 +42,7 @@ #define CONFIG_POWER_TPS62362 /* SPL defines. */ -#define CONFIG_SPL_TEXT_BASE 0x40300350 +#define CONFIG_SPL_TEXT_BASE 0x402F4000 #define CONFIG_SPL_MAX_SIZE(220 << 10) /* 220KB */ #define CONFIG_SYS_SPL_ARGS_ADDR (CONFIG_SYS_SDRAM_BASE + \ (128 << 20)) -- 2.4.2.387.gf86f31a ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 6/8] imx: mx6qp: Enable PRG clock for IPU
On 10/06/2015 10:06, Peng Fan wrote: > From: "Ye.Li" > > The i.MX6QP has a PRG module, need to enable its clock for using > IPU. > > Signed-off-by: Peng Fan > Signed-off-by: Brown Oliver > Signed-off-by: Ye.Li > --- > arch/arm/cpu/armv7/mx6/clock.c | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c > index 36cd5a8..ae1b4cc 100644 > --- a/arch/arm/cpu/armv7/mx6/clock.c > +++ b/arch/arm/cpu/armv7/mx6/clock.c > @@ -861,6 +861,12 @@ void enable_ipu_clock(void) > reg = readl(&mxc_ccm->CCGR3); > reg |= MXC_CCM_CCGR3_IPU1_IPU_MASK; > writel(reg, &mxc_ccm->CCGR3); > + > +#ifdef CONFIG_MX6QP > + reg = readl(&mxc_ccm->CCGR6); > + reg |= MXC_CCM_CCGR6_PRG_CLK0_MASK; > + writel(reg, &mxc_ccm->CCGR6); This is easy to replace with runtime detection. > +#endif > } > #endif > /***/ > Best regards, Stefano Babic -- = DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de = ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 4/8] imx: mx6: ccm: Change the clock settings for i.MX6QP
Hi Peng,
On 10/06/2015 10:06, Peng Fan wrote:
> Since i.MX6QP changes some CCM registers, so modify the clocks settings to
> follow the hardware changes.
>
> A new CONFIG_MX6QP is introduced here and is used for the CCM difference.
> At default CONFIG_MX6Q is enabled along with the CONFIG_MX6QP.
>
> Signed-off-by: Ye.Li
> Signed-off-by: Peng Fan
> ---
> arch/arm/cpu/armv7/mx6/clock.c | 13 +---
> arch/arm/cpu/armv7/mx6/soc.c | 5 ++-
> arch/arm/include/asm/arch-mx6/crm_regs.h | 55
>
> include/configs/mx6_common.h | 3 ++
> 4 files changed, 57 insertions(+), 19 deletions(-)
>
> diff --git a/arch/arm/cpu/armv7/mx6/clock.c b/arch/arm/cpu/armv7/mx6/clock.c
> index ae99945..36cd5a8 100644
> --- a/arch/arm/cpu/armv7/mx6/clock.c
> +++ b/arch/arm/cpu/armv7/mx6/clock.c
> @@ -323,7 +323,7 @@ static u32 get_ipg_per_clk(void)
> u32 reg, perclk_podf;
>
> reg = __raw_readl(&imx_ccm->cscmr1);
> -#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
> +#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX) || defined(CONFIG_MX6QP))
> if (reg & MXC_CCM_CSCMR1_PER_CLK_SEL_MASK)
> return MXC_HCLK; /* OSC 24Mhz */
I have a general issue. We already manage to have support for multiple
variants of MX6 (at least, dual/quad/solo) with a single image. We get
it dropping nasty #ifdef in case of quad/dual. I assume there are only
slight changes in layout for the 6QP. Cannot we manage these changes at
runtime instead of introducing a compiler switch ?
> #endif
> @@ -337,7 +337,7 @@ static u32 get_uart_clk(void)
> u32 reg, uart_podf;
> u32 freq = decode_pll(PLL_USBOTG, MXC_HCLK) / 6; /* static divider */
> reg = __raw_readl(&imx_ccm->cscdr1);
> -#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX))
> +#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6SX) || defined(CONFIG_MX6QP))
> if (reg & MXC_CCM_CSCDR1_UART_CLK_SEL)
> freq = MXC_HCLK;
> #endif
> @@ -352,8 +352,13 @@ static u32 get_cspi_clk(void)
> u32 reg, cspi_podf;
>
> reg = __raw_readl(&imx_ccm->cscdr2);
> - reg &= MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK;
> - cspi_podf = reg >> MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
> + cspi_podf = (reg & MXC_CCM_CSCDR2_ECSPI_CLK_PODF_MASK)
> + >> MXC_CCM_CSCDR2_ECSPI_CLK_PODF_OFFSET;
> +
> +#if defined(CONFIG_MX6QP)
> + if (reg & MXC_CCM_CSCDR2_ECSPI_CLK_SEL_MASK)
> + return MXC_HCLK / (cspi_podf + 1);
> +#endif
>
> return decode_pll(PLL_USBOTG, MXC_HCLK) / (8 * (cspi_podf + 1));
> }
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index e3474e7..5eea9d9 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -335,9 +335,12 @@ static void set_ahb_rate(u32 val)
> static void clear_mmdc_ch_mask(void)
> {
> struct mxc_ccm_reg *mxc_ccm = (struct mxc_ccm_reg *)CCM_BASE_ADDR;
> + u32 reg;
> + reg = readl(&mxc_ccm->ccdr);
>
> /* Clear MMDC channel mask */
> - writel(0, &mxc_ccm->ccdr);
> + reg &= ~(MXC_CCM_CCDR_MMDC_CH1_HS_MASK | MXC_CCM_CCDR_MMDC_CH0_HS_MASK);
> + writel(reg, &mxc_ccm->ccdr);
> }
>
> static void init_bandgap(void)
> diff --git a/arch/arm/include/asm/arch-mx6/crm_regs.h
> b/arch/arm/include/asm/arch-mx6/crm_regs.h
> index 887d048..576dabe 100644
> --- a/arch/arm/include/asm/arch-mx6/crm_regs.h
> +++ b/arch/arm/include/asm/arch-mx6/crm_regs.h
> @@ -113,7 +113,7 @@ struct mxc_ccm_reg {
> #define MXC_CCM_CCR_WB_COUNT_MASK0x7
> #define MXC_CCM_CCR_WB_COUNT_OFFSET (1 << 16)
> #define MXC_CCM_CCR_COSC_EN (1 << 12)
> -#ifdef CONFIG_MX6SX
> +#if (defined(CONFIG_MX6SL) || defined(CONFIG_MX6QP))
> #define MXC_CCM_CCR_OSCNT_MASK 0x7F
> #else
> #define MXC_CCM_CCR_OSCNT_MASK 0xFF
> @@ -123,6 +123,9 @@ struct mxc_ccm_reg {
> /* Define the bits in register CCDR */
> #define MXC_CCM_CCDR_MMDC_CH1_HS_MASK(1 << 16)
> #define MXC_CCM_CCDR_MMDC_CH0_HS_MASK(1 << 17)
> +#ifdef CONFIG_MX6QP
> +#define MXC_CCM_CCDR_MMDC_CH1_AXI_ROOT_CG(1 << 18)
> +#endif
>
> /* Define the bits in register CSR */
> #define MXC_CCM_CSR_COSC_READY (1 << 5)
> @@ -196,7 +199,11 @@ struct mxc_ccm_reg {
> #define MXC_CCM_CBCMR_GPU3D_CORE_CLK_SEL_MASK(0x3 << 4)
> #define MXC_CCM_CBCMR_GPU3D_CORE_CLK_SEL_OFFSET 4
> #ifndef CONFIG_MX6SX
> +#ifdef CONFIG_MX6QP
> +#define MXC_CCM_CBCMR_PRE_CLK_SEL(1 << 1)
> +#else
> #define MXC_CCM_CBCMR_GPU3D_AXI_CLK_SEL (1 << 1)
> +#endif
> #define MXC_CCM_CBCMR_GPU2D_AXI_CLK_SEL (1 << 0)
> #endif
>
> @@ -229,7 +236,7 @@ struct mxc_ccm_reg {
> #define MXC_CCM_CSCMR1_QSPI1_CLK_SEL_MASK(0x7 << 7)
> #define MXC_CCM_CSCMR1_QSPI
Re: [U-Boot] [PATCH 2/8] imx: mx6: Add MX6DQP CPU rev type
Hi Peng,
On 10/06/2015 10:06, Peng Fan wrote:
> Add new cpu type for i.MX6DQP and providing a dynamical
> detecting function.
>
> Signed-off-by: Peng Fan
> Signed-off-by: Ye.Li
> ---
> arch/arm/cpu/armv7/mx6/soc.c | 4 +++-
> arch/arm/include/asm/arch-mx6/imx-regs.h | 1 +
> arch/arm/include/asm/arch-mx6/sys_proto.h | 6 ++
> 3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm/cpu/armv7/mx6/soc.c b/arch/arm/cpu/armv7/mx6/soc.c
> index b21bd03..29de624 100644
> --- a/arch/arm/cpu/armv7/mx6/soc.c
> +++ b/arch/arm/cpu/armv7/mx6/soc.c
> @@ -62,6 +62,7 @@ u32 get_cpu_rev(void)
> struct anatop_regs *anatop = (struct anatop_regs *)ANATOP_BASE_ADDR;
> u32 reg = readl(&anatop->digprog_sololite);
> u32 type = ((reg >> 16) & 0xff);
> + u32 major;
>
> if (type != MXC_CPU_MX6SL) {
> reg = readl(&anatop->digprog);
> @@ -79,8 +80,9 @@ u32 get_cpu_rev(void)
> }
>
> }
> + major = ((reg >> 8) & 0xff);
> reg &= 0xff;/* mx6 silicon revision */
> - return (type << 12) | (reg + 0x10);
> + return (type << 12) | (reg + (0x10 * (major + 1)));
> }
>
> /*
> diff --git a/arch/arm/include/asm/arch-mx6/imx-regs.h
> b/arch/arm/include/asm/arch-mx6/imx-regs.h
> index 0d38d45..35a324c 100644
> --- a/arch/arm/include/asm/arch-mx6/imx-regs.h
> +++ b/arch/arm/include/asm/arch-mx6/imx-regs.h
> @@ -312,6 +312,7 @@
> #define CHIP_REV_1_0 0x10
> #define CHIP_REV_1_2 0x12
> #define CHIP_REV_1_5 0x15
> +#define CHIP_REV_2_0 0x20
> #ifndef CONFIG_MX6SX
> #define IRAM_SIZE0x0004
> #else
> diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h
> b/arch/arm/include/asm/arch-mx6/sys_proto.h
> index 9c827c9..c1d9c6d 100644
> --- a/arch/arm/include/asm/arch-mx6/sys_proto.h
> +++ b/arch/arm/include/asm/arch-mx6/sys_proto.h
> @@ -2,6 +2,8 @@
> * (C) Copyright 2009
> * Stefano Babic, DENX Software Engineering, sba...@denx.de.
> *
> + * (C) Copyright 2009-2015 Freescale Semiconductor, Inc.
> + *
> * SPDX-License-Identifier: GPL-2.0+
> */
>
mmhhh..we have already discussed this topic, Copyright should not be
changed by small changes in a file.
> @@ -30,6 +32,10 @@ const char *get_imx_type(u32 imxtype);
> unsigned imx_ddr_size(void);
> void set_chipselect_size(int const);
>
> +#define is_mx6dqp() ((is_cpu_type(MXC_CPU_MX6Q) || \
> + is_cpu_type(MXC_CPU_MX6D)) && \
> + (is_soc_rev(CHIP_REV_2_0) >= 0))
> +
As "insider" you could better explain me: it looks like there will be
not a Quad/Dual with an increased chip revision. The new chip revision
for i.MX6 is really the QP (P=perfect, as I see some workaround can be
removed !)
Is it correct ? Else this conflicts if a 6Q with a revision > 2 will be
released.
Best regards,
Stefano Babic
--
=
DENX Software Engineering GmbH, Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de
=
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Compilation of env error u-boot 2015.07-rc2
Hi, On Wed, Jun 10, 2015 at 10:29:47AM +0530, Thirumalesha N wrote: > Hi all, > > I have pulled latest code from u-boot main line through git. > > Using linaro tool chain for am335x board > > I'm trying to compile tools/env but its giving an error > > #make ARCH=arm CROSS_COMPILE=arm-linux-gnueabihf- env > > HOSTCC tools/env/fw_env.o > > arm-linux-gnueabihf/include/search.h:173:1 erro: expected '}' before > 'NETARGS' > make[1]: *** [ tools/env/few.env.o] error 1 I have managed to re-create the same problem. Revert this commit: 2320866b978fc12904eeba37236f35d12b4aec30 ie: # git revert 2320866b978fc12904eeba37236f35d12b4aec30 and then try building again. Apparently network arguments were moved to ti_armv7_common.h. However, it wasn't included in the am335x config. > > With same tool chain I'm able compile 2014 u-boot > > Regards, > Thiru N Best Regards, Maxin ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH] add CONFIG_SYS_64BIT_LBA
>From c02e4e8d6f89889255f8f8ec78abc7f33faac3b5 Mon Sep 17 00:00:00 2001 From: Bernhard Nortmann Date: Wed, 10 Jun 2015 10:23:13 +0200 Subject: [PATCH] add CONFIG_SYS_64BIT_LBA Due to absence of CONFIG_SYS_64BIT_LBA, u-boot-sunxi currently has no support for the (GPT) partioning scheme of large disks > 2TB. While the AHCI driver seems to handle this nicely, the problem is that lbaint_t values get truncated to 32-bit. This patch sets CONFIG_SYS_64BIT_LBA from sunxi_common.h for all SoCs that support AHCI (CONFIG_SUNXI_AHCI). Signed-off-by: Bernhard Nortmann --- include/configs/sunxi-common.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h index 2a2f38a..be984f4 100644 --- a/include/configs/sunxi-common.h +++ b/include/configs/sunxi-common.h @@ -87,6 +87,7 @@ #define CONFIG_SCSI_AHCI #define CONFIG_SCSI_AHCI_PLAT #define CONFIG_SUNXI_AHCI +#define CONFIG_SYS_64BIT_LBA 1 #define CONFIG_SYS_SCSI_MAX_SCSI_ID1 #define CONFIG_SYS_SCSI_MAX_LUN1 #define CONFIG_SYS_SCSI_MAX_DEVICE (CONFIG_SYS_SCSI_MAX_SCSI_ID * \ -- 2.0.5 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH 1/8] imx: mx6 cast return type of is_soc_rev to int
Hi Stefano, On Wed, Jun 10, 2015 at 10:20:38AM +0200, Stefano Babic wrote: >Hi Peng, > >On 10/06/2015 10:06, Peng Fan wrote: >> is_soc_rev should be casted to signed int, otherwise >> may incur errors when detecting cpu types, since we use >> such pieces of code: >> " >> if (is_soc_rev(CHIP_REV_1_0) > 0) .. >> if (is_soc_rev(CHIP_REV_2_0) >= 0) .. >> " >> > >We are mishandling the function. From the name, is_soc_rev() should >really return a boolean value. We should call so_rev() instead of >is_soc_rev() when we compare versions. ok. Will address patch 2/8 using soc_rev() and discard this patch. Wait for more comments to patch from 2/8 - 8/8, then send out v2. > >> Signed-off-by: Peng Fan >> --- >> arch/arm/include/asm/arch-mx6/sys_proto.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/arch/arm/include/asm/arch-mx6/sys_proto.h >> b/arch/arm/include/asm/arch-mx6/sys_proto.h >> index c583291..9c827c9 100644 >> --- a/arch/arm/include/asm/arch-mx6/sys_proto.h >> +++ b/arch/arm/include/asm/arch-mx6/sys_proto.h >> @@ -12,7 +12,7 @@ >> #include "../arch-imx/cpu.h" >> >> #define soc_rev() (get_cpu_rev() & 0xFF) >> -#define is_soc_rev(rev)(soc_rev() - rev) >> +#define is_soc_rev(rev)(int)(soc_rev() - rev) >> >> u32 get_nr_cpus(void); >> u32 get_cpu_rev(void); >> > >Best regards, >Stefano Babic Regards, Peng. > >-- >= >DENX Software Engineering GmbH, Managing Director: Wolfgang Denk >HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany >Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de >= -- ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 2/5] Make MTD_PARTITIONS selectable by Kconfig
Users who want to use MTD_PARTITIONS can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel --- drivers/mtd/Kconfig | 11 ++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/drivers/mtd/Kconfig b/drivers/mtd/Kconfig index 59278d1..787b1cd 100644 --- a/drivers/mtd/Kconfig +++ b/drivers/mtd/Kconfig @@ -1,3 +1,12 @@ -source "drivers/mtd/nand/Kconfig" +menu "Memory Technology Device (MTD) support" + +config MTD_PARTITIONS + bool "mtd partitions support" + help + Adds the MTD partitioning infrastructure from the Linux + kernel. Needed for UBI support. +endmenu + +source "drivers/mtd/nand/Kconfig" source "drivers/mtd/spi/Kconfig" -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 5/5] Make ubifs selectable by Kconfig
Users who want to use ubifs can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel --- fs/ubifs/Kconfig | 8 1 file changed, 8 insertions(+) diff --git a/fs/ubifs/Kconfig b/fs/ubifs/Kconfig index e69de29..c5f9714 100644 --- a/fs/ubifs/Kconfig +++ b/fs/ubifs/Kconfig @@ -0,0 +1,8 @@ +config CMD_UBIFS + bool "ubifs" + depends on CMD_UBI + select LZO + help + UBIFS is a file system for flash devices which works on top of UBI. + Please, consult the MTD web site for more details + (www.linux-mtd.infradead.org) -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 4/5] Make lzo decompression selectable by Kconfig
Users who want to use lzo decompression can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel --- lib/Kconfig | 6 ++ 1 file changed, 6 insertions(+) diff --git a/lib/Kconfig b/lib/Kconfig index fc2be56..0fe4932 100644 --- a/lib/Kconfig +++ b/lib/Kconfig @@ -54,6 +54,12 @@ config RBTREE tree, used for storing sortable key/value data pairs. This is currently used in u-boot for ubi and ubifs. +config LZO + bool "lzo decompression support" + help + This adds a library for lzo decrompression. + This is currently used in u-boot for ubifs. + source lib/rsa/Kconfig menu "Hashing Support" -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] [PATCH 3/5] Make ubi selectable by Kconfig
Users who want to use ubi can now select it by Kconfig. Selecting it by board config include is still possible. Signed-off-by: Lars Poeschel --- common/Kconfig | 10 ++ 1 file changed, 10 insertions(+) diff --git a/common/Kconfig b/common/Kconfig index f6478fa..bc2836a 100644 --- a/common/Kconfig +++ b/common/Kconfig @@ -310,6 +310,16 @@ config CMD_FPGA help FPGA support. +config CMD_UBI + bool "ubi" + select RBTREE + depends on MTD_PARTITIONS + help + UBI is a software layer above MTD layer which admits of LVM-like + logical volumes on top of MTD devices, hides some complexities of + flash chips like wear and bad blocks and provides some other useful + capabilities. Please, consult the MTD web site for more details + (www.linux-mtd.infradead.org). endmenu -- 2.1.4 ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
