[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Sandy Patterson]

I wasn't able to load the linux kernel using a Rock2 board
using the latest master branch. The board hangs after it has
handed executing over to the kernel. I found that the latest release
that worked was v2016.03.

I did some searching and I suspect the problem may be cache related.

This patchset allows the kernel to start by reverting two problem
commits and disabling EFI_LOADER which I suspect rubs the caching the
wrong way. We also found that the 512M limit for fdt and initrd is now 256M.
I'm not sure why this is.

This still doesn't work 100%. I think it's not initializing the SD card
volages correctly, but at least the Kernel is loading.

I also am not sure changing the caching for all armv7 is the right
answer. I wasn't too sure about the revert. I am not very familiar with
this low level stuff.

Sandy Patterson


Sandy Patterson (4):
  Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL)
    with asm code"
  Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with
    asm code"
  Disable CONFIG_EFI_LOADER for rock2.
  RK3288 needs fdt and initrd below 256M now.

 arch/arm/cpu/armv7/Makefile                  |   2 +-
 arch/arm/cpu/armv7/cache_v7.c                | 135 ++++++++++++++++++++++-
 arch/arm/cpu/armv7/cache_v7_asm.S            | 154 ---------------------------
 arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++++++++++-
 configs/rock2_defconfig                      |   1 +
 include/configs/rk3288_common.h              |   6 +-
 6 files changed, 201 insertions(+), 164 deletions(-)
 delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S

-- 
1.9.1

[U-Boot] [PATCH 1/4] Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL) with asm code"

[Sandy Patterson]

This reverts commit c09d29057ab0b04db0857d319c6bff74de31b9c3.

Conflicts:
	arch/arm/cpu/armv7/cache_v7.c
	arch/arm/cpu/armv7/cache_v7_asm.S

Signed-off-by: Sandy Patterson <apatterson@sightlogix.com>
---

 arch/arm/cpu/armv7/Makefile                  |   2 +-
 arch/arm/cpu/armv7/cache_v7.c                | 119 +++++++++++++++++++--
 arch/arm/cpu/armv7/cache_v7_asm.S            | 154 ---------------------------
 arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++++++++++-
 4 files changed, 180 insertions(+), 162 deletions(-)
 delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S

diff --git a/arch/arm/cpu/armv7/Makefile b/arch/arm/cpu/armv7/Makefile
index ddd8d12..34bd42b 100644
--- a/arch/arm/cpu/armv7/Makefile
+++ b/arch/arm/cpu/armv7/Makefile
@@ -7,7 +7,7 @@
 
 extra-y	:= start.o
 
-obj-y	+= cache_v7.o cache_v7_asm.o
+obj-y	+= cache_v7.o
 
 obj-y	+= cpu.o cp15.o
 obj-y	+= syslib.o
diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index dc309da..85b0b0e 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -14,11 +14,6 @@
 #define ARMV7_DCACHE_CLEAN_INVAL_RANGE	2
 
 #ifndef CONFIG_SYS_DCACHE_OFF
-
-/* Asm functions from cache_v7_asm.S */
-void v7_flush_dcache_all(void);
-void v7_invalidate_dcache_all(void);
-
 static int check_cache_range(unsigned long start, unsigned long stop)
 {
 	int ok = 1;
@@ -45,6 +40,118 @@ static u32 get_ccsidr(void)
 	return ccsidr;
 }
 
+static u32 get_clidr(void)
+{
+	u32 clidr;
+
+	/* Read current CP15 Cache Level ID Register */
+	asm volatile ("mrc p15,1,%0,c0,c0,1" : "=r" (clidr));
+	return clidr;
+}
+
+static void v7_inval_dcache_level_setway(u32 level, u32 num_sets,
+					 u32 num_ways, u32 way_shift,
+					 u32 log2_line_len)
+{
+	int way, set;
+	u32 setway;
+
+	/*
+	 * For optimal assembly code:
+	 *	a. count down
+	 *	b. have bigger loop inside
+	 */
+	for (way = num_ways - 1; way >= 0 ; way--) {
+		for (set = num_sets - 1; set >= 0; set--) {
+			setway = (level << 1) | (set << log2_line_len) |
+				 (way << way_shift);
+			/* Invalidate data/unified cache line by set/way */
+			asm volatile ("	mcr p15, 0, %0, c7, c6, 2"
+					: : "r" (setway));
+		}
+	}
+	/* DSB to make sure the operation is complete */
+	DSB;
+}
+
+static void v7_clean_inval_dcache_level_setway(u32 level, u32 num_sets,
+					       u32 num_ways, u32 way_shift,
+					       u32 log2_line_len)
+{
+	int way, set;
+	u32 setway;
+
+	/*
+	 * For optimal assembly code:
+	 *	a. count down
+	 *	b. have bigger loop inside
+	 */
+	for (way = num_ways - 1; way >= 0 ; way--) {
+		for (set = num_sets - 1; set >= 0; set--) {
+			setway = (level << 1) | (set << log2_line_len) |
+				 (way << way_shift);
+			/*
+			 * Clean & Invalidate data/unified
+			 * cache line by set/way
+			 */
+			asm volatile ("	mcr p15, 0, %0, c7, c14, 2"
+					: : "r" (setway));
+		}
+	}
+	/* DSB to make sure the operation is complete */
+	DSB;
+}
+
+static void v7_maint_dcache_level_setway(u32 level, u32 operation)
+{
+	u32 ccsidr;
+	u32 num_sets, num_ways, log2_line_len, log2_num_ways;
+	u32 way_shift;
+
+	set_csselr(level, ARMV7_CSSELR_IND_DATA_UNIFIED);
+
+	ccsidr = get_ccsidr();
+
+	log2_line_len = ((ccsidr & CCSIDR_LINE_SIZE_MASK) >>
+				CCSIDR_LINE_SIZE_OFFSET) + 2;
+	/* Converting from words to bytes */
+	log2_line_len += 2;
+
+	num_ways  = ((ccsidr & CCSIDR_ASSOCIATIVITY_MASK) >>
+			CCSIDR_ASSOCIATIVITY_OFFSET) + 1;
+	num_sets  = ((ccsidr & CCSIDR_NUM_SETS_MASK) >>
+			CCSIDR_NUM_SETS_OFFSET) + 1;
+	/*
+	 * According to ARMv7 ARM number of sets and number of ways need
+	 * not be a power of 2
+	 */
+	log2_num_ways = log_2_n_round_up(num_ways);
+
+	way_shift = (32 - log2_num_ways);
+	if (operation == ARMV7_DCACHE_INVAL_ALL) {
+		v7_inval_dcache_level_setway(level, num_sets, num_ways,
+				      way_shift, log2_line_len);
+	} else if (operation == ARMV7_DCACHE_CLEAN_INVAL_ALL) {
+		v7_clean_inval_dcache_level_setway(level, num_sets, num_ways,
+						   way_shift, log2_line_len);
+	}
+}
+
+static void v7_maint_dcache_all(u32 operation)
+{
+	u32 level, cache_type, level_start_bit = 0;
+	u32 clidr = get_clidr();
+
+	for (level = 0; level < 7; level++) {
+		cache_type = (clidr >> level_start_bit) & 0x7;
+		if ((cache_type == ARMV7_CLIDR_CTYPE_DATA_ONLY) ||
+		    (cache_type == ARMV7_CLIDR_CTYPE_INSTRUCTION_DATA) ||
+		    (cache_type == ARMV7_CLIDR_CTYPE_UNIFIED))
+			v7_maint_dcache_level_setway(level, operation);
+		level_start_bit += 3;
+	}
+}
+
 static void v7_dcache_clean_inval_range(u32 start, u32 stop, u32 line_len)
 {
 	u32 mva;
@@ -142,7 +249,7 @@ void invalidate_dcache_all(void)
  */
 void flush_dcache_all(void)
 {
-	v7_flush_dcache_all();
+	v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL);
 
 	v7_outer_cache_flush_all();
 }
diff --git a/arch/arm/cpu/armv7/cache_v7_asm.S b/arch/arm/cpu/armv7/cache_v7_asm.S
deleted file mode 100644
index a433628..0000000
--- a/arch/arm/cpu/armv7/cache_v7_asm.S
+++ /dev/null
@@ -1,154 +0,0 @@
-/*
- * SPDX-License-Identifier:	GPL-2.0+
- */
-
-#include <config.h>
-#include <linux/linkage.h>
-#include <linux/sizes.h>
-#include <asm/system.h>
-
-#ifdef CONFIG_SYS_THUMB_BUILD
-#define ARM(x...)
-#define THUMB(x...)	x
-#else
-#define ARM(x...)	x
-#define THUMB(x...)
-#endif
-
-/*
- *	v7_flush_dcache_all()
- *
- *	Flush the whole D-cache.
- *
- *	Corrupted registers: r0-r7, r9-r11 (r6 only in Thumb mode)
- *
- *	Note: copied from arch/arm/mm/cache-v7.S of Linux 4.4
- */
-ENTRY(__v7_flush_dcache_all)
-	dmb					@ ensure ordering with previous memory accesses
-	mrc	p15, 1, r0, c0, c0, 1		@ read clidr
-	mov	r3, r0, lsr #23			@ move LoC into position
-	ands	r3, r3, #7 << 1			@ extract LoC*2 from clidr
-	beq	finished			@ if loc is 0, then no need to clean
-start_flush_levels:
-	mov	r10, #0				@ start clean at cache level 0
-flush_levels:
-	add	r2, r10, r10, lsr #1		@ work out 3x current cache level
-	mov	r1, r0, lsr r2			@ extract cache type bits from clidr
-	and	r1, r1, #7			@ mask of the bits for current cache only
-	cmp	r1, #2				@ see what cache we have at this level
-	blt	skip				@ skip if no cache, or just i-cache
-	mcr	p15, 2, r10, c0, c0, 0		@ select current cache level in cssr
-	isb					@ isb to sych the new cssr&csidr
-	mrc	p15, 1, r1, c0, c0, 0		@ read the new csidr
-	and	r2, r1, #7			@ extract the length of the cache lines
-	add	r2, r2, #4			@ add 4 (line length offset)
-	movw	r4, #0x3ff
-	ands	r4, r4, r1, lsr #3		@ find maximum number on the way size
-	clz	r5, r4				@ find bit position of way size increment
-	movw	r7, #0x7fff
-	ands	r7, r7, r1, lsr #13		@ extract max number of the index size
-loop1:
-	mov	r9, r7				@ create working copy of max index
-loop2:
- ARM(	orr	r11, r10, r4, lsl r5	)	@ factor way and cache number into r11
- THUMB(	lsl	r6, r4, r5		)
- THUMB(	orr	r11, r10, r6		)	@ factor way and cache number into r11
- ARM(	orr	r11, r11, r9, lsl r2	)	@ factor index number into r11
- THUMB(	lsl	r6, r9, r2		)
- THUMB(	orr	r11, r11, r6		)	@ factor index number into r11
-	mcr	p15, 0, r11, c7, c14, 2		@ clean & invalidate by set/way
-	subs	r9, r9, #1			@ decrement the index
-	bge	loop2
-	subs	r4, r4, #1			@ decrement the way
-	bge	loop1
-skip:
-	add	r10, r10, #2			@ increment cache number
-	cmp	r3, r10
-	bgt	flush_levels
-finished:
-	mov	r10, #0				@ swith back to cache level 0
-	mcr	p15, 2, r10, c0, c0, 0		@ select current cache level in cssr
-	dsb	st
-	isb
-	bx	lr
-ENDPROC(__v7_flush_dcache_all)
-
-ENTRY(v7_flush_dcache_all)
- ARM(	stmfd	sp!, {r4-r5, r7, r9-r11, lr}	)
- THUMB(	stmfd	sp!, {r4-r7, r9-r11, lr}	)
-	bl	__v7_flush_dcache_all
- ARM(	ldmfd	sp!, {r4-r5, r7, r9-r11, lr}	)
- THUMB(	ldmfd	sp!, {r4-r7, r9-r11, lr}	)
-	bx	lr
-ENDPROC(v7_flush_dcache_all)
-
-/*
- *	v7_invalidate_dcache_all()
- *
- *	Invalidate the whole D-cache.
- *
- *	Corrupted registers: r0-r7, r9-r11 (r6 only in Thumb mode)
- *
- *	Note: copied from __v7_flush_dcache_all above with
- *	mcr     p15, 0, r11, c7, c14, 2
- *	Replaced with:
- *	mcr     p15, 0, r11, c7, c6, 2
- */
-ENTRY(__v7_invalidate_dcache_all)
-	dmb					@ ensure ordering with previous memory accesses
-	mrc	p15, 1, r0, c0, c0, 1		@ read clidr
-	mov	r3, r0, lsr #23			@ move LoC into position
-	ands	r3, r3, #7 << 1			@ extract LoC*2 from clidr
-	beq	inval_finished			@ if loc is 0, then no need to clean
-	mov	r10, #0				@ start clean at cache level 0
-inval_levels:
-	add	r2, r10, r10, lsr #1		@ work out 3x current cache level
-	mov	r1, r0, lsr r2			@ extract cache type bits from clidr
-	and	r1, r1, #7			@ mask of the bits for current cache only
-	cmp	r1, #2				@ see what cache we have at this level
-	blt	inval_skip			@ skip if no cache, or just i-cache
-	mcr	p15, 2, r10, c0, c0, 0		@ select current cache level in cssr
-	isb					@ isb to sych the new cssr&csidr
-	mrc	p15, 1, r1, c0, c0, 0		@ read the new csidr
-	and	r2, r1, #7			@ extract the length of the cache lines
-	add	r2, r2, #4			@ add 4 (line length offset)
-	movw	r4, #0x3ff
-	ands	r4, r4, r1, lsr #3		@ find maximum number on the way size
-	clz	r5, r4				@ find bit position of way size increment
-	movw	r7, #0x7fff
-	ands	r7, r7, r1, lsr #13		@ extract max number of the index size
-inval_loop1:
-	mov	r9, r7				@ create working copy of max index
-inval_loop2:
- ARM(	orr	r11, r10, r4, lsl r5	)	@ factor way and cache number into r11
- THUMB(	lsl	r6, r4, r5		)
- THUMB(	orr	r11, r10, r6		)	@ factor way and cache number into r11
- ARM(	orr	r11, r11, r9, lsl r2	)	@ factor index number into r11
- THUMB(	lsl	r6, r9, r2		)
- THUMB(	orr	r11, r11, r6		)	@ factor index number into r11
-	mcr	p15, 0, r11, c7, c6, 2		@ invalidate by set/way
-	subs	r9, r9, #1			@ decrement the index
-	bge	inval_loop2
-	subs	r4, r4, #1			@ decrement the way
-	bge	inval_loop1
-inval_skip:
-	add	r10, r10, #2			@ increment cache number
-	cmp	r3, r10
-	bgt	inval_levels
-inval_finished:
-	mov	r10, #0				@ swith back to cache level 0
-	mcr	p15, 2, r10, c0, c0, 0		@ select current cache level in cssr
-	dsb	st
-	isb
-	bx	lr
-ENDPROC(__v7_invalidate_dcache_all)
-
-ENTRY(v7_invalidate_dcache_all)
- ARM(	stmfd	sp!, {r4-r5, r7, r9-r11, lr}	)
- THUMB(	stmfd	sp!, {r4-r7, r9-r11, lr}	)
-	bl	__v7_invalidate_dcache_all
- ARM(	ldmfd	sp!, {r4-r5, r7, r9-r11, lr}	)
- THUMB(	ldmfd	sp!, {r4-r7, r9-r11, lr}	)
-	bx	lr
-ENDPROC(v7_invalidate_dcache_all)
diff --git a/arch/arm/mach-uniphier/arm32/lowlevel_init.S b/arch/arm/mach-uniphier/arm32/lowlevel_init.S
index cc34116..6f05abf 100644
--- a/arch/arm/mach-uniphier/arm32/lowlevel_init.S
+++ b/arch/arm/mach-uniphier/arm32/lowlevel_init.S
@@ -38,7 +38,7 @@ ENTRY(lowlevel_init)
 	 * to do next is to create a page table and switch over to it.
 	 */
 	bl	create_page_table
-	bl	__v7_flush_dcache_all
+	bl	v7_flush_dcache_all
 
 	/* Disable MMU and Dcache before switching Page Table */
 	mrc	p15, 0, r0, c1, c0, 0	@ SCTLR (System Control Register)
@@ -140,3 +140,68 @@ ENTRY(create_page_table)
 	str	r0, [r12, #4]		@ mark the second section as Normal
 	mov	pc, lr
 ENDPROC(create_page_table)
+
+/* We don't use Thumb instructions for now */
+#define ARM(x...)	x
+#define THUMB(x...)
+
+/*
+ *	v7_flush_dcache_all()
+ *
+ *	Flush the whole D-cache.
+ *
+ *	Corrupted registers: r0-r7, r9-r11 (r6 only in Thumb mode)
+ *
+ *	- mm    - mm_struct describing address space
+ *
+ *	Note: copied from arch/arm/mm/cache-v7.S of Linux 4.4
+ */
+ENTRY(v7_flush_dcache_all)
+	dmb					@ ensure ordering with previous memory accesses
+	mrc	p15, 1, r0, c0, c0, 1		@ read clidr
+	mov	r3, r0, lsr #23			@ move LoC into position
+	ands	r3, r3, #7 << 1			@ extract LoC*2 from clidr
+	beq	finished			@ if loc is 0, then no need to clean
+start_flush_levels:
+	mov	r10, #0				@ start clean at cache level 0
+flush_levels:
+	add	r2, r10, r10, lsr #1		@ work out 3x current cache level
+	mov	r1, r0, lsr r2			@ extract cache type bits from clidr
+	and	r1, r1, #7			@ mask of the bits for current cache only
+	cmp	r1, #2				@ see what cache we have@this level
+	blt	skip				@ skip if no cache, or just i-cache
+	mcr	p15, 2, r10, c0, c0, 0		@ select current cache level in cssr
+	isb					@ isb to sych the new cssr&csidr
+	mrc	p15, 1, r1, c0, c0, 0		@ read the new csidr
+	and	r2, r1, #7			@ extract the length of the cache lines
+	add	r2, r2, #4			@ add 4 (line length offset)
+	movw	r4, #0x3ff
+	ands	r4, r4, r1, lsr #3		@ find maximum number on the way size
+	clz	r5, r4				@ find bit position of way size increment
+	movw	r7, #0x7fff
+	ands	r7, r7, r1, lsr #13		@ extract max number of the index size
+loop1:
+	mov	r9, r7				@ create working copy of max index
+loop2:
+ ARM(	orr	r11, r10, r4, lsl r5	)	@ factor way and cache number into r11
+ THUMB(	lsl	r6, r4, r5		)
+ THUMB(	orr	r11, r10, r6		)	@ factor way and cache number into r11
+ ARM(	orr	r11, r11, r9, lsl r2	)	@ factor index number into r11
+ THUMB(	lsl	r6, r9, r2		)
+ THUMB(	orr	r11, r11, r6		)	@ factor index number into r11
+	mcr	p15, 0, r11, c7, c14, 2		@ clean & invalidate by set/way
+	subs	r9, r9, #1			@ decrement the index
+	bge	loop2
+	subs	r4, r4, #1			@ decrement the way
+	bge	loop1
+skip:
+	add	r10, r10, #2			@ increment cache number
+	cmp	r3, r10
+	bgt	flush_levels
+finished:
+	mov	r10, #0				@ swith back to cache level 0
+	mcr	p15, 2, r10, c0, c0, 0		@ select current cache level in cssr
+	dsb	st
+	isb
+	mov	pc, lr
+ENDPROC(v7_flush_dcache_all)
-- 
1.9.1

[U-Boot] [PATCH 2/4] Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with asm code"

[Sandy Patterson]

This reverts commit df120142f36b6ff8b12187b8860269763b2b3203.

Conflicts:
	arch/arm/cpu/armv7/cache_v7.c
	arch/arm/cpu/armv7/cache_v7_asm.S

Signed-off-by: Sandy Patterson <apatterson@sightlogix.com>
---

 arch/arm/cpu/armv7/cache_v7.c | 24 +++++++++++++++++++++---
 1 file changed, 21 insertions(+), 3 deletions(-)

diff --git a/arch/arm/cpu/armv7/cache_v7.c b/arch/arm/cpu/armv7/cache_v7.c
index 85b0b0e..3e1ea2c 100644
--- a/arch/arm/cpu/armv7/cache_v7.c
+++ b/arch/arm/cpu/armv7/cache_v7.c
@@ -10,10 +10,16 @@
 #include <asm/armv7.h>
 #include <asm/utils.h>
 
-#define ARMV7_DCACHE_INVAL_RANGE	1
-#define ARMV7_DCACHE_CLEAN_INVAL_RANGE	2
+#define ARMV7_DCACHE_INVAL_ALL		1
+#define ARMV7_DCACHE_CLEAN_INVAL_ALL	2
+#define ARMV7_DCACHE_INVAL_RANGE	3
+#define ARMV7_DCACHE_CLEAN_INVAL_RANGE	4
 
 #ifndef CONFIG_SYS_DCACHE_OFF
+
+/* Asm functions from cache_v7_asm.S */
+void v7_flush_dcache_all(void);
+
 static int check_cache_range(unsigned long start, unsigned long stop)
 {
 	int ok = 1;
@@ -31,6 +37,18 @@ static int check_cache_range(unsigned long start, unsigned long stop)
 	return ok;
 }
 
+/*
+ * Write the level and type you want to Cache Size Selection Register(CSSELR)
+ * to get size details from Current Cache Size ID Register(CCSIDR)
+ */
+static void set_csselr(u32 level, u32 type)
+{
+	u32 csselr = level << 1 | type;
+
+	/* Write to Cache Size Selection Register(CSSELR) */
+	asm volatile ("mcr p15, 2, %0, c0, c0, 0" : : "r" (csselr));
+}
+
 static u32 get_ccsidr(void)
 {
 	u32 ccsidr;
@@ -238,7 +256,7 @@ static void v7_inval_tlb(void)
 
 void invalidate_dcache_all(void)
 {
-	v7_invalidate_dcache_all();
+	v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL);
 
 	v7_outer_cache_inval_all();
 }
-- 
1.9.1

[U-Boot] [PATCH 3/4] Disable CONFIG_EFI_LOADER for rock2.

[Sandy Patterson]

I'm not sure why this breaks kernel loading.

Signed-off-by: Sandy Patterson <apatterson@sightlogix.com>
---

 configs/rock2_defconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configs/rock2_defconfig b/configs/rock2_defconfig
index 3e16b80..3a06b7e 100644
--- a/configs/rock2_defconfig
+++ b/configs/rock2_defconfig
@@ -67,3 +67,4 @@ CONFIG_USE_PRIVATE_LIBGCC=y
 CONFIG_USE_TINY_PRINTF=y
 CONFIG_CMD_DHRYSTONE=y
 CONFIG_ERRNO_STR=y
+# CONFIG_EFI_LOADER is not set
-- 
1.9.1

[U-Boot] [PATCH 4/4] RK3288 needs fdt and initrd below 256M now.

[Sandy Patterson]

I am not sure why this limit is changing. But my kernel
doesn't load when it's above 256. This was testing on the
rock2 board.

Signed-off-by: Sandy Patterson <apatterson@sightlogix.com>
---

 include/configs/rk3288_common.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
index 9d50d83..b88e7e5 100644
--- a/include/configs/rk3288_common.h
+++ b/include/configs/rk3288_common.h
@@ -97,11 +97,11 @@
 
 #include <config_distro_bootcmd.h>
 
-/* Linux fails to load the fdt if it's loaded above 512M on a Rock 2 board, so
+/* Linux fails to load the fdt if it's loaded above 256M on a Rock 2 board, so
  * limit the fdt reallocation to that */
 #define CONFIG_EXTRA_ENV_SETTINGS \
-	"fdt_high=0x1fffffff\0" \
-	"initrd_high=0x1fffffff\0" \
+	"fdt_high=0x0fffffff\0" \
+	"initrd_high=0x0fffffff\0" \
 	ENV_MEM_LAYOUT_SETTINGS \
 	ROCKCHIP_DEVICE_SETTINGS \
 	BOOTENV
-- 
1.9.1

[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Sandy Patterson]

I did a little more on this, and talked to someone else here. It seems that
my problem with loading the kernel including these patches is specific to
our kernel and after applying a local patch we have, it appears to load
fine.

So this patchset gets me back to the same functionality in v2016.03.

We're left with the puzzle of what's wrong on the RK3288 regarding caching
and memory.

Sandy Patterson

On Mon, Jul 11, 2016 at 1:38 PM, Sandy Patterson <apatterson@sightlogix.com>
wrote:

> I wasn't able to load the linux kernel using a Rock2 board
> using the latest master branch. The board hangs after it has
> handed executing over to the kernel. I found that the latest release
> that worked was v2016.03.
>
> I did some searching and I suspect the problem may be cache related.
>
> This patchset allows the kernel to start by reverting two problem
> commits and disabling EFI_LOADER which I suspect rubs the caching the
> wrong way. We also found that the 512M limit for fdt and initrd is now
> 256M.
> I'm not sure why this is.
>
> This still doesn't work 100%. I think it's not initializing the SD card
> volages correctly, but at least the Kernel is loading.
>
> I also am not sure changing the caching for all armv7 is the right
> answer. I wasn't too sure about the revert. I am not very familiar with
> this low level stuff.
>
> Sandy Patterson
>
>
> Sandy Patterson (4):
>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL)
>     with asm code"
>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with
>     asm code"
>   Disable CONFIG_EFI_LOADER for rock2.
>   RK3288 needs fdt and initrd below 256M now.
>
>  arch/arm/cpu/armv7/Makefile                  |   2 +-
>  arch/arm/cpu/armv7/cache_v7.c                | 135 ++++++++++++++++++++++-
>  arch/arm/cpu/armv7/cache_v7_asm.S            | 154
> ---------------------------
>  arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++++++++++-
>  configs/rock2_defconfig                      |   1 +
>  include/configs/rk3288_common.h              |   6 +-
>  6 files changed, 201 insertions(+), 164 deletions(-)
>  delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S
>
> --
> 1.9.1
>
>

[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Simon Glass]

HI Sandy,

On 13 July 2016 at 11:51, Sandy Patterson <apatterson@sightlogix.com> wrote:
> I did a little more on this, and talked to someone else here. It seems that
> my problem with loading the kernel including these patches is specific to
> our kernel and after applying a local patch we have, it appears to load
> fine.
>
> So this patchset gets me back to the same functionality in v2016.03.
>
> We're left with the puzzle of what's wrong on the RK3288 regarding caching
> and memory.

So what is the status of this patch set? Should it be withdrawn?

Regards,
Simon

>
> Sandy Patterson
>
> On Mon, Jul 11, 2016 at 1:38 PM, Sandy Patterson <apatterson@sightlogix.com>
> wrote:
>>
>> I wasn't able to load the linux kernel using a Rock2 board
>> using the latest master branch. The board hangs after it has
>> handed executing over to the kernel. I found that the latest release
>> that worked was v2016.03.
>>
>> I did some searching and I suspect the problem may be cache related.
>>
>> This patchset allows the kernel to start by reverting two problem
>> commits and disabling EFI_LOADER which I suspect rubs the caching the
>> wrong way. We also found that the 512M limit for fdt and initrd is now
>> 256M.
>> I'm not sure why this is.
>>
>> This still doesn't work 100%. I think it's not initializing the SD card
>> volages correctly, but at least the Kernel is loading.
>>
>> I also am not sure changing the caching for all armv7 is the right
>> answer. I wasn't too sure about the revert. I am not very familiar with
>> this low level stuff.
>>
>> Sandy Patterson
>>
>>
>> Sandy Patterson (4):
>>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL)
>>     with asm code"
>>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with
>>     asm code"
>>   Disable CONFIG_EFI_LOADER for rock2.
>>   RK3288 needs fdt and initrd below 256M now.
>>
>>  arch/arm/cpu/armv7/Makefile                  |   2 +-
>>  arch/arm/cpu/armv7/cache_v7.c                | 135
>> ++++++++++++++++++++++-
>>  arch/arm/cpu/armv7/cache_v7_asm.S            | 154
>> ---------------------------
>>  arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++++++++++-
>>  configs/rock2_defconfig                      |   1 +
>>  include/configs/rk3288_common.h              |   6 +-
>>  6 files changed, 201 insertions(+), 164 deletions(-)
>>  delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S
>>
>> --
>> 1.9.1
>>
>

[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Sandy Patterson]

Hi Simon,

I think I screwed up submitting, and didn't cc the maintainers for the
reverts. I can resubmit and get patman to behave. What do you suggest?

I still think this is the best patch to getting rock2 to load kernels again.

I just retested with a patch specific to my kernel. I think 3.14 linux has
some quirks in how it wants the dram setup, and I get instability without
some changes to the dram init. I don't have enough of a system to test for
this instability using the latest mainline kernel, so I left that patch out.

Ziyuan had an alternative fix for efi_loader, but it looks like it may
break efi_loader for others, and I don't know how to test the efi
functionality, so I think disabling for RK3288 is best. I think I should
move the CONFIG_EFI_LOADER patch to somehow patching rk3288_common.h
instead (can I #undef config vars in that file?)

Sandy



On Thu, Jul 14, 2016 at 11:19 PM, Simon Glass <sjg@chromium.org> wrote:

> HI Sandy,
>
> On 13 July 2016 at 11:51, Sandy Patterson <apatterson@sightlogix.com>
> wrote:
> > I did a little more on this, and talked to someone else here. It seems
> that
> > my problem with loading the kernel including these patches is specific to
> > our kernel and after applying a local patch we have, it appears to load
> > fine.
> >
> > So this patchset gets me back to the same functionality in v2016.03.
> >
> > We're left with the puzzle of what's wrong on the RK3288 regarding
> caching
> > and memory.
>
> So what is the status of this patch set? Should it be withdrawn?
>
> Regards,
> Simon
>
> >
> > Sandy Patterson
> >
> > On Mon, Jul 11, 2016 at 1:38 PM, Sandy Patterson <
> apatterson at sightlogix.com>
> > wrote:
> >>
> >> I wasn't able to load the linux kernel using a Rock2 board
> >> using the latest master branch. The board hangs after it has
> >> handed executing over to the kernel. I found that the latest release
> >> that worked was v2016.03.
> >>
> >> I did some searching and I suspect the problem may be cache related.
> >>
> >> This patchset allows the kernel to start by reverting two problem
> >> commits and disabling EFI_LOADER which I suspect rubs the caching the
> >> wrong way. We also found that the 512M limit for fdt and initrd is now
> >> 256M.
> >> I'm not sure why this is.
> >>
> >> This still doesn't work 100%. I think it's not initializing the SD card
> >> volages correctly, but at least the Kernel is loading.
> >>
> >> I also am not sure changing the caching for all armv7 is the right
> >> answer. I wasn't too sure about the revert. I am not very familiar with
> >> this low level stuff.
> >>
> >> Sandy Patterson
> >>
> >>
> >> Sandy Patterson (4):
> >>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL)
> >>     with asm code"
> >>   Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL) with
> >>     asm code"
> >>   Disable CONFIG_EFI_LOADER for rock2.
> >>   RK3288 needs fdt and initrd below 256M now.
> >>
> >>  arch/arm/cpu/armv7/Makefile                  |   2 +-
> >>  arch/arm/cpu/armv7/cache_v7.c                | 135
> >> ++++++++++++++++++++++-
> >>  arch/arm/cpu/armv7/cache_v7_asm.S            | 154
> >> ---------------------------
> >>  arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++++++++++-
> >>  configs/rock2_defconfig                      |   1 +
> >>  include/configs/rk3288_common.h              |   6 +-
> >>  6 files changed, 201 insertions(+), 164 deletions(-)
> >>  delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S
> >>
> >> --
> >> 1.9.1
> >>
> >
>

[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Ziyuan Xu]

Hi Standy,

On 2016?07?14? 01:51, Sandy Patterson wrote:
> I did a little more on this, and talked to someone else here. It seems 
> that my problem with loading the kernel including these patches is 
> specific to our kernel and after applying a local patch we have, it 
> appears to load fine.
>
> So this patchset gets me back to the same functionality in v2016.03.
>
> We're left with the puzzle of what's wrong on the RK3288 regarding 
> caching and memory.
>
> Sandy Patterson
>
> On Mon, Jul 11, 2016 at 1:38 PM, Sandy Patterson 
> <apatterson at sightlogix.com <mailto:apatterson@sightlogix.com>> wrote:
>
>     I wasn't able to load the linux kernel using a Rock2 board
>     using the latest master branch. The board hangs after it has
>     handed executing over to the kernel. I found that the latest release
>     that worked was v2016.03.
>
>     I did some searching and I suspect the problem may be cache related.
>
>     This patchset allows the kernel to start by reverting two problem
>     commits and disabling EFI_LOADER which I suspect rubs the caching the
>     wrong way. We also found that the 512M limit for fdt and initrd is
>     now 256M.
>     I'm not sure why this is.
>
I just tried to boot linux kernel on my rk3288 board with the latest 
u-boot. Everything looks sane.

board: rk3288-fennec
u-boot: branch u-boot-rockchip/master, also enable CONFIG_EFI_LOADER
boot device: eMMC
bootcmd: mmc dev 1; mmc read 0x2000000 0x14000 0x10000; bootz 0x2000000  
(custom partitions layout )

Could try again, let me know if you still have any problem.
>
>
>     This still doesn't work 100%. I think it's not initializing the SD
>     card
>     volages correctly, but at least the Kernel is loading.
>
>     I also am not sure changing the caching for all armv7 is the right
>     answer. I wasn't too sure about the revert. I am not very familiar
>     with
>     this low level stuff.
>
>     Sandy Patterson
>
>
>     Sandy Patterson (4):
>       Revert "arm: Replace
>     v7_maint_dcache_all(ARMV7_DCACHE_CLEAN_INVAL_ALL)
>         with asm code"
>       Revert "arm: Replace v7_maint_dcache_all(ARMV7_DCACHE_INVAL_ALL)
>     with
>         asm code"
>       Disable CONFIG_EFI_LOADER for rock2.
>       RK3288 needs fdt and initrd below 256M now.
>
>      arch/arm/cpu/armv7/Makefile                  |   2 +-
>      arch/arm/cpu/armv7/cache_v7.c                | 135
>     ++++++++++++++++++++++-
>      arch/arm/cpu/armv7/cache_v7_asm.S            | 154
>     ---------------------------
>      arch/arm/mach-uniphier/arm32/lowlevel_init.S |  67 +++++++++++-
>      configs/rock2_defconfig                      |   1 +
>      include/configs/rk3288_common.h              |   6 +-
>      6 files changed, 201 insertions(+), 164 deletions(-)
>      delete mode 100644 arch/arm/cpu/armv7/cache_v7_asm.S
>
>     --
>     1.9.1
>
>

[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Simon Glass]

+Hans, Tom

Hi Sandy,

On 15 July 2016 at 07:40, Sandy Patterson <apatterson@sightlogix.com> wrote:
> Hi Simon,
>
> I think I screwed up submitting, and didn't cc the maintainers for the
> reverts. I can resubmit and get patman to behave. What do you suggest?
>
> I still think this is the best patch to getting rock2 to load kernels again.
>
> I just retested with a patch specific to my kernel. I think 3.14 linux has
> some quirks in how it wants the dram setup, and I get instability without
> some changes to the dram init. I don't have enough of a system to test for
> this instability using the latest mainline kernel, so I left that patch out.
>
> Ziyuan had an alternative fix for efi_loader, but it looks like it may break
> efi_loader for others, and I don't know how to test the efi functionality,
> so I think disabling for RK3288 is best. I think I should move the
> CONFIG_EFI_LOADER patch to somehow patching rk3288_common.h instead (can I
> #undef config vars in that file?)

Yes please can you resend and cc the maintainers and original author.
Patman -t should do this automatically.

Also with the revert of Han's ARM patches, please can you describe the
problem so it is clear why we need to revert?

Regards,
Simon

[...]

[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Sandy Patterson]

Ziyuan,

I retested the kernel loading. I'm using 3.14 kernel. I also tested with
linux-4.7-rc6. I still require both the cache reverts and disabling
efi_loader on u-boot/master and u-boot-rockchip/master. (see below for
testing parameters)

Hans,
I have been unable to boot an RK3288 rock2 square board since v2016.03
release. The kernel fails to start.

Before reverting I get this on my console:

Starting kernel ...

### ERROR ### Please RESET the board ###

Another possibly related problem which has similar effect without the ERROR
potion above is a call to invalidate_icache_all() from efi_runtime.c.
Commenting out this line or disabled CONFIG_EFI_LOADER seems to allow the
kernel to boot.

testing:
board: radxa rock2 square
kernel: 3.14 custom, and linux-4.7-rc6 - multi_v7_defconfig zImage
rk3288-radxa-rock.dtb
toolchain: gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabi
loading from sd card - the actual loading seems fine though. I'm not sure
how emmc would change anything.

booting command for 4.7 (we use and care about 3.14, but i thought it would
be easier to show with 4.7-rc6. I get the same behavior with 3.14):
setenv bootargs root=/dev/mmcblk0p4
ext4load mmc 0:3 0x02000000 /zImage; ext4load mmc 0:3 0x01f00000
/rk3288-rock2-square.dtb
bootz 0x02000000 - 0x01f00000

u-boot/master: 95d52733036af7438a5285d729d53844ec48c63e
CONFIG_EFI_LOADER=n and cache reverts required to load kernel
*_high changes don't seem to be required anymore

u-boot-rockchip: 1781acd31b01225402167fbdb8fa97157cc269eb
CONFIG_EFI_LOADER=n and cache reverts required to load kernel
*_high changes don't seem to be required anymore

Sandy Patterson


On Thu, Jul 21, 2016 at 11:21 PM, Simon Glass <sjg@chromium.org> wrote:

> +Hans, Tom
>
> Hi Sandy,
>
> On 15 July 2016 at 07:40, Sandy Patterson <apatterson@sightlogix.com>
> wrote:
> > Hi Simon,
> >
> > I think I screwed up submitting, and didn't cc the maintainers for the
> > reverts. I can resubmit and get patman to behave. What do you suggest?
> >
> > I still think this is the best patch to getting rock2 to load kernels
> again.
> >
> > I just retested with a patch specific to my kernel. I think 3.14 linux
> has
> > some quirks in how it wants the dram setup, and I get instability without
> > some changes to the dram init. I don't have enough of a system to test
> for
> > this instability using the latest mainline kernel, so I left that patch
> out.
> >
> > Ziyuan had an alternative fix for efi_loader, but it looks like it may
> break
> > efi_loader for others, and I don't know how to test the efi
> functionality,
> > so I think disabling for RK3288 is best. I think I should move the
> > CONFIG_EFI_LOADER patch to somehow patching rk3288_common.h instead (can
> I
> > #undef config vars in that file?)
>
> Yes please can you resend and cc the maintainers and original author.
> Patman -t should do this automatically.
>
> Also with the revert of Han's ARM patches, please can you describe the
> problem so it is clear why we need to revert?
>
> Regards,
> Simon
>
> [...]
>

[U-Boot] [PATCH 0/4] Ability to load linux kernel on rock2 RK3288

[Ziyuan Xu]

?Alexander Graf

On 2016?07?22? 21:49, Sandy Patterson wrote:
> Ziyuan,
>
> I retested the kernel loading. I'm using 3.14 kernel. I also tested 
> with linux-4.7-rc6. I still require both the cache reverts and 
> disabling efi_loader on u-boot/master and u-boot-rockchip/master. (see 
> below for testing parameters)
>
> Hans,
> I have been unable to boot an RK3288 rock2 square board since v2016.03 
> release. The kernel fails to start.
>
> Before reverting I get this on my console:
>
> Starting kernel ...
>
> ### ERROR ### Please RESET the board ###
>
> Another possibly related problem which has similar effect without the 
> ERROR potion above is a call to invalidate_icache_all() from 
> efi_runtime.c. Commenting out this line or disabled CONFIG_EFI_LOADER 
> seems to allow the kernel to boot.
>
> testing:
> board: radxa rock2 square
> kernel: 3.14 custom, and linux-4.7-rc6 - multi_v7_defconfig zImage 
> rk3288-radxa-rock.dtb
> toolchain: gcc-linaro-5.3-2016.02-x86_64_arm-linux-gnueabi
> loading from sd card - the actual loading seems fine though. I'm not 
> sure how emmc would change anything.
>
> booting command for 4.7 (we use and care about 3.14, but i thought it 
> would be easier to show with 4.7-rc6. I get the same behavior with 3.14):
> setenv bootargs root=/dev/mmcblk0p4
> ext4load mmc 0:3 0x02000000 /zImage; ext4load mmc 0:3 0x01f00000 
> /rk3288-rock2-square.dtb
> bootz 0x02000000 - 0x01f00000
>
> u-boot/master: 95d52733036af7438a5285d729d53844ec48c63e
> CONFIG_EFI_LOADER=n and cache reverts required to load kernel
> *_high changes don't seem to be required anymore
>
> u-boot-rockchip: 1781acd31b01225402167fbdb8fa97157cc269eb
> CONFIG_EFI_LOADER=n and cache reverts required to load kernel
> *_high changes don't seem to be required anymore
>
> Sandy Patterson
>
>
> On Thu, Jul 21, 2016 at 11:21 PM, Simon Glass <sjg@chromium.org 
> <mailto:sjg@chromium.org>> wrote:
>
>     +Hans, Tom
>
>     Hi Sandy,
>
>     On 15 July 2016 at 07:40, Sandy Patterson
>     <apatterson at sightlogix.com <mailto:apatterson@sightlogix.com>> wrote:
>     > Hi Simon,
>     >
>     > I think I screwed up submitting, and didn't cc the maintainers
>     for the
>     > reverts. I can resubmit and get patman to behave. What do you
>     suggest?
>     >
>     > I still think this is the best patch to getting rock2 to load
>     kernels again.
>     >
>     > I just retested with a patch specific to my kernel. I think 3.14
>     linux has
>     > some quirks in how it wants the dram setup, and I get
>     instability without
>     > some changes to the dram init. I don't have enough of a system
>     to test for
>     > this instability using the latest mainline kernel, so I left
>     that patch out.
>     >
>     > Ziyuan had an alternative fix for efi_loader, but it looks like
>     it may break
>     > efi_loader for others, and I don't know how to test the efi
>     functionality,
>     > so I think disabling for RK3288 is best. I think I should move the
>     > CONFIG_EFI_LOADER patch to somehow patching rk3288_common.h
>     instead (can I
>     > #undef config vars in that file?)
>
>     Yes please can you resend and cc the maintainers and original author.
>     Patman -t should do this automatically.
>
>     Also with the revert of Han's ARM patches, please can you describe the
>     problem so it is clear why we need to revert?
>
>     Regards,
>     Simon
>
>     [...]
>
>

[U-Boot] [PATCH 4/4] RK3288 needs fdt and initrd below 256M now.

[Simon Glass]

Hi Sandy,

On 11 July 2016 at 11:38, Sandy Patterson <apatterson@sightlogix.com> wrote:
> I am not sure why this limit is changing. But my kernel
> doesn't load when it's above 256. This was testing on the
> rock2 board.
>
> Signed-off-by: Sandy Patterson <apatterson@sightlogix.com>
> ---
>
>  include/configs/rk3288_common.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

Is this patch not needed now?

>
> diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_common.h
> index 9d50d83..b88e7e5 100644
> --- a/include/configs/rk3288_common.h
> +++ b/include/configs/rk3288_common.h
> @@ -97,11 +97,11 @@
>
>  #include <config_distro_bootcmd.h>
>
> -/* Linux fails to load the fdt if it's loaded above 512M on a Rock 2 board, so
> +/* Linux fails to load the fdt if it's loaded above 256M on a Rock 2 board, so
>   * limit the fdt reallocation to that */
>  #define CONFIG_EXTRA_ENV_SETTINGS \
> -       "fdt_high=0x1fffffff\0" \
> -       "initrd_high=0x1fffffff\0" \
> +       "fdt_high=0x0fffffff\0" \
> +       "initrd_high=0x0fffffff\0" \
>         ENV_MEM_LAYOUT_SETTINGS \
>         ROCKCHIP_DEVICE_SETTINGS \
>         BOOTENV
> --
> 1.9.1
>

Regards,
Simon

[U-Boot] [PATCH 4/4] RK3288 needs fdt and initrd below 256M now.

[Sandy Patterson]

On Sat, Aug 27, 2016 at 12:06 PM, Simon Glass <sjg@chromium.org> wrote:

> Hi Sandy,
>
> On 11 July 2016 at 11:38, Sandy Patterson <apatterson@sightlogix.com>
> wrote:
> > I am not sure why this limit is changing. But my kernel
> > doesn't load when it's above 256. This was testing on the
> > rock2 board.
> >
> > Signed-off-by: Sandy Patterson <apatterson@sightlogix.com>
> > ---
> >
> >  include/configs/rk3288_common.h | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
>
> Is this patch not needed now?
>

I just retested with the latest from u-boot.git/master . This patch is
still required for booing on rock2. I tested with the same mainline kernel
version as before (4.7.0-rc6). I don't know why, and I haven't tried
searching back through the history to see if it used to work and what
changed, sorry.


>
> >
> > diff --git a/include/configs/rk3288_common.h b/include/configs/rk3288_
> common.h
> > index 9d50d83..b88e7e5 100644
> > --- a/include/configs/rk3288_common.h
> > +++ b/include/configs/rk3288_common.h
> > @@ -97,11 +97,11 @@
> >
> >  #include <config_distro_bootcmd.h>
> >
> > -/* Linux fails to load the fdt if it's loaded above 512M on a Rock 2
> board, so
> > +/* Linux fails to load the fdt if it's loaded above 256M on a Rock 2
> board, so
> >   * limit the fdt reallocation to that */
> >  #define CONFIG_EXTRA_ENV_SETTINGS \
> > -       "fdt_high=0x1fffffff\0" \
> > -       "initrd_high=0x1fffffff\0" \
> > +       "fdt_high=0x0fffffff\0" \
> > +       "initrd_high=0x0fffffff\0" \
> >         ENV_MEM_LAYOUT_SETTINGS \
> >         ROCKCHIP_DEVICE_SETTINGS \
> >         BOOTENV
> > --
> > 1.9.1
> >
>
> Regards,
> Simon
>

[U-Boot] [PATCH 4/4] RK3288 needs fdt and initrd below 256M now.

[Simon Glass]

On 27 August 2016 at 11:03, Sandy Patterson <apatterson@sightlogix.com> wrote:
>
>
> On Sat, Aug 27, 2016 at 12:06 PM, Simon Glass <sjg@chromium.org> wrote:
>>
>> Hi Sandy,
>>
>> On 11 July 2016 at 11:38, Sandy Patterson <apatterson@sightlogix.com>
>> wrote:
>> > I am not sure why this limit is changing. But my kernel
>> > doesn't load when it's above 256. This was testing on the
>> > rock2 board.
>> >
>> > Signed-off-by: Sandy Patterson <apatterson@sightlogix.com>
>> > ---
>> >
>> >  include/configs/rk3288_common.h | 6 +++---
>> >  1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> Is this patch not needed now?
>
>
> I just retested with the latest from u-boot.git/master . This patch is still
> required for booing on rock2. I tested with the same mainline kernel version
> as before (4.7.0-rc6). I don't know why, and I haven't tried searching back
> through the history to see if it used to work and what changed, sorry.

Still not tested tags for this.

Updated commit subject and:

Applied to u-boot-rockchip, thanks!