[U-Boot] [PATCH 1/5] arm: Use r2 instead of r0 in start.S

[U-Boot] [PATCH 1/5] arm: Use r2 instead of r0 in start.S

[Simon Glass]

Allow r0 to be used for other purposes in this file.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 arch/arm/cpu/armv7/start.S | 88 +++++++++++++++++++++++-----------------------
 1 file changed, 44 insertions(+), 44 deletions(-)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 70048c1..c5f94ef 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -38,13 +38,13 @@ reset:
 	 * disable interrupts (FIQ and IRQ), also set the cpu to SVC32 mode,
 	 * except if in HYP mode already
 	 */
-	mrs	r0, cpsr
-	and	r1, r0, #0x1f		@ mask mode bits
+	mrs	r2, cpsr
+	and	r1, r2, #0x1f		@ mask mode bits
 	teq	r1, #0x1a		@ test for HYP mode
-	bicne	r0, r0, #0x1f		@ clear all mode bits
-	orrne	r0, r0, #0x13		@ set SVC mode
-	orr	r0, r0, #0xc0		@ disable FIQ and IRQ
-	msr	cpsr,r0
+	bicne	r2, r2, #0x1f		@ clear all mode bits
+	orrne	r2, r2, #0x13		@ set SVC mode
+	orr	r2, r2, #0xc0		@ disable FIQ and IRQ
+	msr	cpsr, r2
 
 /*
  * Setup vector:
@@ -53,13 +53,13 @@ reset:
  */
 #if !(defined(CONFIG_OMAP44XX) && defined(CONFIG_SPL_BUILD))
 	/* Set V=0 in CP15 SCTLR register - for VBAR to point to vector */
-	mrc	p15, 0, r0, c1, c0, 0	@ Read CP15 SCTLR Register
-	bic	r0, #CR_V		@ V = 0
-	mcr	p15, 0, r0, c1, c0, 0	@ Write CP15 SCTLR Register
+	mrc	p15, 0, r2, c1, c0, 0	@ Read CP15 SCTLR Register
+	bic	r2, #CR_V		@ V = 0
+	mcr	p15, 0, r2, c1, c0, 0	@ Write CP15 SCTLR Register
 
 	/* Set vector address in CP15 VBAR register */
-	ldr	r0, =_start
-	mcr	p15, 0, r0, c12, c0, 0	@Set VBAR
+	ldr	r2, =_start
+	mcr	p15, 0, r2, c12, c0, 0	@Set VBAR
 #endif
 
 	/* the mask ROM code should have PLL and others stable */
@@ -77,9 +77,9 @@ ENTRY(c_runtime_cpu_setup)
  * If I-cache is enabled invalidate it
  */
 #ifndef CONFIG_SYS_ICACHE_OFF
-	mcr	p15, 0, r0, c7, c5, 0	@ invalidate icache
-	mcr     p15, 0, r0, c7, c10, 4	@ DSB
-	mcr     p15, 0, r0, c7, c5, 4	@ ISB
+	mcr	p15, 0, r2, c7, c5, 0	@ invalidate icache
+	mcr     p15, 0, r2, c7, c10, 4	@ DSB
+	mcr     p15, 0, r2, c7, c5, 4	@ ISB
 #endif
 
 	bx	lr
@@ -88,7 +88,7 @@ ENDPROC(c_runtime_cpu_setup)
 
 /*************************************************************************
  *
- * void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+ * void save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
  *	__attribute__((weak));
  *
  * Stack pointer is not yet initialized at this moment
@@ -112,55 +112,55 @@ ENTRY(cpu_init_cp15)
 	/*
 	 * Invalidate L1 I/D
 	 */
-	mov	r0, #0			@ set up for MCR
-	mcr	p15, 0, r0, c8, c7, 0	@ invalidate TLBs
-	mcr	p15, 0, r0, c7, c5, 0	@ invalidate icache
-	mcr	p15, 0, r0, c7, c5, 6	@ invalidate BP array
-	mcr     p15, 0, r0, c7, c10, 4	@ DSB
-	mcr     p15, 0, r0, c7, c5, 4	@ ISB
+	mov	r2, #0			@ set up for MCR
+	mcr	p15, 0, r2, c8, c7, 0	@ invalidate TLBs
+	mcr	p15, 0, r2, c7, c5, 0	@ invalidate icache
+	mcr	p15, 0, r2, c7, c5, 6	@ invalidate BP array
+	mcr     p15, 0, r2, c7, c10, 4	@ DSB
+	mcr     p15, 0, r2, c7, c5, 4	@ ISB
 
 	/*
 	 * disable MMU stuff and caches
 	 */
-	mrc	p15, 0, r0, c1, c0, 0
-	bic	r0, r0, #0x00002000	@ clear bits 13 (--V-)
-	bic	r0, r0, #0x00000007	@ clear bits 2:0 (-CAM)
-	orr	r0, r0, #0x00000002	@ set bit 1 (--A-) Align
-	orr	r0, r0, #0x00000800	@ set bit 11 (Z---) BTB
+	mrc	p15, 0, r2, c1, c0, 0
+	bic	r2, r2, #0x00002000	@ clear bits 13 (--V-)
+	bic	r2, r2, #0x00000007	@ clear bits 2:0 (-CAM)
+	orr	r2, r2, #0x00000002	@ set bit 1 (--A-) Align
+	orr	r2, r2, #0x00000800	@ set bit 11 (Z---) BTB
 #ifdef CONFIG_SYS_ICACHE_OFF
-	bic	r0, r0, #0x00001000	@ clear bit 12 (I) I-cache
+	bic	r2, r2, #0x00001000	@ clear bit 12 (I) I-cache
 #else
-	orr	r0, r0, #0x00001000	@ set bit 12 (I) I-cache
+	orr	r2, r2, #0x00001000	@ set bit 12 (I) I-cache
 #endif
-	mcr	p15, 0, r0, c1, c0, 0
+	mcr	p15, 0, r2, c1, c0, 0
 
 #ifdef CONFIG_ARM_ERRATA_716044
-	mrc	p15, 0, r0, c1, c0, 0	@ read system control register
-	orr	r0, r0, #1 << 11	@ set bit #11
-	mcr	p15, 0, r0, c1, c0, 0	@ write system control register
+	mrc	p15, 0, r2, c1, c0, 0	@ read system control register
+	orr	r2, r2, #1 << 11	@ set bit #11
+	mcr	p15, 0, r2, c1, c0, 0	@ write system control register
 #endif
 
 #if (defined(CONFIG_ARM_ERRATA_742230) || defined(CONFIG_ARM_ERRATA_794072))
-	mrc	p15, 0, r0, c15, c0, 1	@ read diagnostic register
-	orr	r0, r0, #1 << 4		@ set bit #4
-	mcr	p15, 0, r0, c15, c0, 1	@ write diagnostic register
+	mrc	p15, 0, r2, c15, c0, 1	@ read diagnostic register
+	orr	r2, r2, #1 << 4		@ set bit #4
+	mcr	p15, 0, r2, c15, c0, 1	@ write diagnostic register
 #endif
 
 #ifdef CONFIG_ARM_ERRATA_743622
-	mrc	p15, 0, r0, c15, c0, 1	@ read diagnostic register
-	orr	r0, r0, #1 << 6		@ set bit #6
-	mcr	p15, 0, r0, c15, c0, 1	@ write diagnostic register
+	mrc	p15, 0, r2, c15, c0, 1	@ read diagnostic register
+	orr	r2, r2, #1 << 6		@ set bit #6
+	mcr	p15, 0, r2, c15, c0, 1	@ write diagnostic register
 #endif
 
 #ifdef CONFIG_ARM_ERRATA_751472
-	mrc	p15, 0, r0, c15, c0, 1	@ read diagnostic register
-	orr	r0, r0, #1 << 11	@ set bit #11
-	mcr	p15, 0, r0, c15, c0, 1	@ write diagnostic register
+	mrc	p15, 0, r2, c15, c0, 1	@ read diagnostic register
+	orr	r2, r2, #1 << 11	@ set bit #11
+	mcr	p15, 0, r2, c15, c0, 1	@ write diagnostic register
 #endif
 #ifdef CONFIG_ARM_ERRATA_761320
-	mrc	p15, 0, r0, c15, c0, 1	@ read diagnostic register
-	orr	r0, r0, #1 << 21	@ set bit #21
-	mcr	p15, 0, r0, c15, c0, 1	@ write diagnostic register
+	mrc	p15, 0, r2, c15, c0, 1	@ read diagnostic register
+	orr	r2, r2, #1 << 21	@ set bit #21
+	mcr	p15, 0, r2, c15, c0, 1	@ write diagnostic register
 #endif
 
 	mov	pc, lr			@ back to my caller
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 2/5] arm: Allow reset init to be controlled

[Simon Glass]

Some boards want to skip the normal reset init. For example OMAP4 SPL
does not want to touch VBAR and many boards don't want to set up
CP15.

Provide a return value from save_boot_params() which allows the board
to indicate what reset processing should be done.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 arch/arm/cpu/armv7/exynos/spl_boot.c |  5 ++++-
 arch/arm/cpu/armv7/start.S           | 11 ++++++++---
 arch/arm/include/asm/system.h        | 15 +++++++++++++++
 3 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c b/arch/arm/cpu/armv7/exynos/spl_boot.c
index bc237c9..6e249f1 100644
--- a/arch/arm/cpu/armv7/exynos/spl_boot.c
+++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
@@ -309,4 +309,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
 	while (1)
 		;
 }
-void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) {}
+u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
+{
+	return 0;
+}
diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index c5f94ef..0ba26f7 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -52,6 +52,9 @@ reset:
  * Continue to use ROM code vector only in OMAP4 spl)
  */
 #if !(defined(CONFIG_OMAP44XX) && defined(CONFIG_SPL_BUILD))
+	teq	r0, #RESET_SKIP_VBVAR
+	bne	vbar_done
+
 	/* Set V=0 in CP15 SCTLR register - for VBAR to point to vector */
 	mrc	p15, 0, r2, c1, c0, 0	@ Read CP15 SCTLR Register
 	bic	r2, #CR_V		@ V = 0
@@ -61,10 +64,11 @@ reset:
 	ldr	r2, =_start
 	mcr	p15, 0, r2, c12, c0, 0	@Set VBAR
 #endif
-
+vbar_done:
 	/* the mask ROM code should have PLL and others stable */
 #ifndef CONFIG_SKIP_LOWLEVEL_INIT
-	bl	cpu_init_cp15
+	teq	r0, #RESET_SKIP_CP15
+	bleq	cpu_init_cp15
 	bl	cpu_init_crit
 #endif
 
@@ -88,11 +92,12 @@ ENDPROC(c_runtime_cpu_setup)
 
 /*************************************************************************
  *
- * void save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
+ * u32 save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
  *	__attribute__((weak));
  *
  * Stack pointer is not yet initialized at this moment
  * Don't save anything to stack even if compiled with -O0
+ * Return flags - see RESET_... in system.h
  *
  *************************************************************************/
 ENTRY(save_boot_params)
diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
index 89f2294..98e49a7 100644
--- a/arch/arm/include/asm/system.h
+++ b/arch/arm/include/asm/system.h
@@ -140,8 +140,23 @@ void flush_l3_cache(void);
  */
 #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
 
+/* Control bits for reset processing */
+#define RESET_SKIP_VBVAR	(1 << 0)	/* Skip vector address setup */
+#define RESET_SKIP_CP15		(1 << 1)	/* Skip CP15 setup */
+
 #ifndef __ASSEMBLY__
 
+/**
+ * save_boot_params() - Save boot parameters before starting reset sequence
+ *
+ * @r0:		Value of r0
+ * @r1:		Value of r1
+ * @r2:		Value of r2
+ * @r3:		Value of r3
+ * @return reset flags (see RESET_... above)
+ */
+u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3);
+
 #define isb() __asm__ __volatile__ ("" : : : "memory")
 
 #define nop() __asm__ __volatile__("mov\tr0,r0\t@ nop\n\t");
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 3/5] arm: Allow lr to be saved by board code

[Simon Glass]

The link register value can be required on some boards (e.g. FEL mode on
sunxi) so stash it to r4 before jumping to save_boot_params().

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 arch/arm/cpu/armv7/start.S | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
index 0ba26f7..8207d66 100644
--- a/arch/arm/cpu/armv7/start.S
+++ b/arch/arm/cpu/armv7/start.S
@@ -33,6 +33,7 @@
 	.globl	reset
 
 reset:
+	mov	r4, lr
 	bl	save_boot_params
 	/*
 	 * disable interrupts (FIQ and IRQ), also set the cpu to SVC32 mode,
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 4/5] arm: spl: Provide for a board-specific loader

[Simon Glass]

Some boards have a special way of loading U-Boot that does not fit with
the existing SPL code. For example sunxi uses an 'FEL' mode where U-Boot
is loaded over USB. Add a CONFIG option and boot mode for this.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 arch/arm/include/asm/spl.h | 4 ++++
 common/spl/spl.c           | 5 +++++
 2 files changed, 9 insertions(+)

diff --git a/arch/arm/include/asm/spl.h b/arch/arm/include/asm/spl.h
index 8acd7cd..17b6f54 100644
--- a/arch/arm/include/asm/spl.h
+++ b/arch/arm/include/asm/spl.h
@@ -26,10 +26,14 @@ enum {
 	BOOT_DEVICE_SPI,
 	BOOT_DEVICE_SATA,
 	BOOT_DEVICE_I2C,
+	BOOT_DEVICE_BOARD,
 	BOOT_DEVICE_NONE
 };
 #endif
 
+/* Board-specific load method */
+void spl_board_load_image(void);
+
 /* Linker symbols. */
 extern char __bss_start[], __bss_end[];
 
diff --git a/common/spl/spl.c b/common/spl/spl.c
index daaeb50..ded0f30 100644
--- a/common/spl/spl.c
+++ b/common/spl/spl.c
@@ -229,6 +229,11 @@ void board_init_r(gd_t *dummy1, ulong dummy2)
 		spl_sata_load_image();
 		break;
 #endif
+#ifdef CONFIG_SPL_BOARD_LOAD_IMAGE
+	case BOOT_DEVICE_BOARD:
+		spl_board_load_image();
+		break;
+#endif
 	default:
 #if defined(CONFIG_SPL_SERIAL_SUPPORT) && defined(CONFIG_SPL_LIBCOMMON_SUPPORT)
 		puts("SPL: Unsupported Boot Device!\n");
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support

[Simon Glass]

(What does FEL stand for?)

This is an attempt to make sunxi's FEL code fit with the normal U-Boot
boot sequence instead of creating its own.

Most of the FEL special-case code is removed, although I may have gone too
far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
FEL is enabled. This may not be possible since the MMC stack makes SPL
too large for FEL anyway, although it may be possible for other boot
mediums.

This series is available at u-boot-dm, branch sunxi-working.

Signed-off-by: Simon Glass <sjg@chromium.org>
---

 arch/arm/cpu/armv7/sunxi/Makefile           |  4 +-
 arch/arm/cpu/armv7/sunxi/board.c            | 21 ++++++++
 arch/arm/cpu/armv7/sunxi/config.mk          |  2 -
 arch/arm/cpu/armv7/sunxi/fel_utils.S        | 26 +++++++++
 arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds | 82 -----------------------------
 arch/arm/include/asm/arch-sunxi/sys_proto.h | 10 ++++
 board/sunxi/Kconfig                         | 10 ++++
 include/configs/sunxi-common.h              |  6 +--
 scripts/Makefile.spl                        |  2 -
 9 files changed, 70 insertions(+), 93 deletions(-)
 create mode 100644 arch/arm/cpu/armv7/sunxi/fel_utils.S
 delete mode 100644 arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds

diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile
index 48db744..c1b975a 100644
--- a/arch/arm/cpu/armv7/sunxi/Makefile
+++ b/arch/arm/cpu/armv7/sunxi/Makefile
@@ -38,7 +38,5 @@ obj-$(CONFIG_MACH_SUN5I)	+= dram_sun4i.o
 obj-$(CONFIG_MACH_SUN6I)	+= dram_sun6i.o
 obj-$(CONFIG_MACH_SUN7I)	+= dram_sun4i.o
 obj-$(CONFIG_MACH_SUN8I)	+= dram_sun8i.o
-ifdef CONFIG_SPL_FEL
-obj-y	+= start.o
-endif
+obj-y	+= fel_utils.o
 endif
diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
index 6e28bcd..b7492ac 100644
--- a/arch/arm/cpu/armv7/sunxi/board.c
+++ b/arch/arm/cpu/armv7/sunxi/board.c
@@ -27,6 +27,13 @@
 
 #include <linux/compiler.h>
 
+struct fel_stash {
+	uint32_t sp;
+	uint32_t lr;
+};
+
+struct fel_stash fel_stash __attribute__((section(".data")));
+
 static int gpio_init(void)
 {
 #if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
@@ -65,6 +72,12 @@ static int gpio_init(void)
 	return 0;
 }
 
+void spl_board_load_image(void)
+{
+	debug("Returning to FEL sp=%x, lr=%x\n", fel_stash.sp, fel_stash.lr);
+	return_to_fel(fel_stash.sp, fel_stash.lr);
+}
+
 void s_init(void)
 {
 #if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I
@@ -95,6 +108,14 @@ void s_init(void)
  */
 u32 spl_boot_device(void)
 {
+	/*
+	 * Have we been asked to return to the FEL portion of the boot ROM?
+	 * TODO: We need a more robust test here, or bracket this with
+	 * #ifdef CONFIG_SPL_FEL.
+	 */
+	if (fel_stash.lr >= 0xffff0000 && fel_stash.lr < 0xffff4000)
+		return BOOT_DEVICE_BOARD;
+
 	return BOOT_DEVICE_MMC1;
 }
 
diff --git a/arch/arm/cpu/armv7/sunxi/config.mk b/arch/arm/cpu/armv7/sunxi/config.mk
index 00f5ffc..76ffec9 100644
--- a/arch/arm/cpu/armv7/sunxi/config.mk
+++ b/arch/arm/cpu/armv7/sunxi/config.mk
@@ -1,8 +1,6 @@
 # Build a combined spl + u-boot image
 ifdef CONFIG_SPL
 ifndef CONFIG_SPL_BUILD
-ifndef CONFIG_SPL_FEL
 ALL-y += u-boot-sunxi-with-spl.bin
 endif
 endif
-endif
diff --git a/arch/arm/cpu/armv7/sunxi/fel_utils.S b/arch/arm/cpu/armv7/sunxi/fel_utils.S
new file mode 100644
index 0000000..42739df
--- /dev/null
+++ b/arch/arm/cpu/armv7/sunxi/fel_utils.S
@@ -0,0 +1,26 @@
+/*
+ * Utility functions for FEL mode.
+ *
+ * Copyright (c) 2015 Google, Inc
+ *
+ * SPDX-License-Identifier:	GPL-2.0+
+ */
+
+#include <asm-offsets.h>
+#include <config.h>
+#include <asm/system.h>
+#include <linux/linkage.h>
+
+ENTRY(save_boot_params)
+	ldr	r0, =fel_stash
+	str	sp, [r0, #0]
+	str	r4, [r0, #4]	/* Store lr */
+	mov	r0, #RESET_SKIP_VBVAR | RESET_SKIP_CP15
+	bx	lr
+ENDPROC(save_boot_params)
+
+ENTRY(return_to_fel)
+	mov	sp, r0
+	mov	lr, r1
+	bx	lr
+ENDPROC(return_to_fel)
diff --git a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
deleted file mode 100644
index 928b7c1..0000000
--- a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
+++ /dev/null
@@ -1,82 +0,0 @@
-/*
- * (C) Copyright 2013
- * Henrik Nordstrom <henrik@henriknordstrom.net>
- *
- * SPDX-License-Identifier:	GPL-2.0+
- */
-OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
-OUTPUT_ARCH(arm)
-ENTRY(s_init)
-SECTIONS
-{
-	. = 0x00002000;
-
-	. = ALIGN(4);
-	.text :
-	{
-		*(.text.s_init)
-		*(.text*)
-	}
-
-	. = ALIGN(4);
-	.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
-
-	. = ALIGN(4);
-	.data : {
-		*(.data*)
-	}
-
-	. = ALIGN(4);
-	.u_boot_list : {
-		KEEP(*(SORT(.u_boot_list*)));
-	}
-
-	. = ALIGN(4);
-	. = .;
-
-	. = ALIGN(4);
-	.rel.dyn : {
-		__rel_dyn_start = .;
-		*(.rel*)
-		__rel_dyn_end = .;
-	}
-
-	.dynsym : {
-		__dynsym_start = .;
-		*(.dynsym)
-	}
-
-	. = ALIGN(4);
-	.note.gnu.build-id :
-	{
-		*(.note.gnu.build-id)
-	}
-	_end = .;
-
-	. = ALIGN(4096);
-	.mmutable : {
-		*(.mmutable)
-	}
-
-	.bss_start __rel_dyn_start (OVERLAY) : {
-		KEEP(*(.__bss_start));
-		__bss_base = .;
-	}
-
-	.bss __bss_base (OVERLAY) : {
-		*(.bss*)
-		. = ALIGN(4);
-		__bss_limit = .;
-	}
-
-	.bss_end __bss_limit (OVERLAY) : {
-		KEEP(*(.__bss_end));
-	}
-
-	/DISCARD/ : { *(.dynstr*) }
-	/DISCARD/ : { *(.dynamic*) }
-	/DISCARD/ : { *(.plt*) }
-	/DISCARD/ : { *(.interp*) }
-	/DISCARD/ : { *(.gnu*) }
-	/DISCARD/ : { *(.note*) }
-}
diff --git a/arch/arm/include/asm/arch-sunxi/sys_proto.h b/arch/arm/include/asm/arch-sunxi/sys_proto.h
index c3e636e..60a5bd8 100644
--- a/arch/arm/include/asm/arch-sunxi/sys_proto.h
+++ b/arch/arm/include/asm/arch-sunxi/sys_proto.h
@@ -13,4 +13,14 @@
 
 void sdelay(unsigned long);
 
+/* return_to_fel() - Return to BROM from SPL
+ *
+ * This returns back into the BROM after U-Boot SPL has performed its initial
+ * init. It uses the provided lr and sp to do so.
+ *
+ * @lr:		BROM link register value (return address)
+ * @sp:		BROM stack pointer
+ */
+void return_to_fel(uint32_t lr, uint32_t sp);
+
 #endif
diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
index 4a21589..c50cffe 100644
--- a/board/sunxi/Kconfig
+++ b/board/sunxi/Kconfig
@@ -149,6 +149,16 @@ config SPL_FEL
 	bool "SPL/FEL mode support"
 	depends on SPL
 	default n
+	help
+	  This enables support for <insert_full_name_here> (FEL) mode. This
+	  allows U-Boot to be loaded to the board over USB by the on-chip
+	  boot rom. U-Boot should be sent in two parts: SPL first, with
+	  'fel write 0x2000 u-boot-spl.bin; fel exe 0x2000' then U-Boot with
+	  'fel write 0x4a000000 u-boot.bin; fel exe 0x4a000000'. This option
+	  shrinks the amount of SRAM available to SPL, so only enable it if
+	  you need FEL (why? what do we lose?). Note that enabling this option
+	  only allows FEL to be used; it is still possible to boot U-Boot from
+	  boot media. U-Boot SPL detects when it is being loaded using FEL.
 
 config UART0_PORT_F
 	bool "UART0 on MicroSD breakout board"
diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 6cfd7e1..3becb4f 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -18,10 +18,8 @@
  */
 #define CONFIG_SUNXI		/* sunxi family */
 #ifdef CONFIG_SPL_BUILD
-#ifndef CONFIG_SPL_FEL
 #define CONFIG_SYS_THUMB_BUILD	/* Thumbs mode to save space in SPL */
 #endif
-#endif
 
 #include <asm/arch/cpu.h>	/* get chip and board defs */
 
@@ -146,10 +144,10 @@
 #define CONFIG_SPL_SERIAL_SUPPORT
 #define CONFIG_SPL_LIBGENERIC_SUPPORT
 
+#define CONFIG_SPL_BOARD_LOAD_IMAGE
+
 #ifdef CONFIG_SPL_FEL
 
-#define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds"
-#define CONFIG_SPL_START_S_PATH "arch/arm/cpu/armv7/sunxi"
 #define CONFIG_SPL_TEXT_BASE		0x2000
 #define CONFIG_SPL_MAX_SIZE		0x4000		/* 16 KiB */
 
diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
index ecf3037..5a1962b 100644
--- a/scripts/Makefile.spl
+++ b/scripts/Makefile.spl
@@ -153,10 +153,8 @@ ALL-y	+= $(obj)/$(BOARD)-spl.bin
 endif
 
 ifdef CONFIG_SUNXI
-ifndef CONFIG_SPL_FEL
 ALL-y	+= $(obj)/sunxi-spl.bin
 endif
-endif
 
 ifeq ($(CONFIG_SYS_SOC),"at91")
 ALL-y	+= boot.bin
-- 
2.2.0.rc0.207.ga3a616c

[U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support

[Hans de Goede]

Hi,

On 04-02-15 05:18, Simon Glass wrote:
> (What does FEL stand for?)
>
> This is an attempt to make sunxi's FEL code fit with the normal U-Boot
> boot sequence instead of creating its own.
>
> Most of the FEL special-case code is removed, although I may have gone too
> far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
> FEL is enabled. This may not be possible since the MMC stack makes SPL
> too large for FEL anyway, although it may be possible for other boot
> mediums.
>
> This series is available at u-boot-dm, branch sunxi-working.

Thanks for working on this, I like the direction where this is heading,
if Albert is ok with the start.S changes this would be an excellent way
to fix FEL mode for v2015.04.

WRT you going to far when also building a u-boot-sunxi-with-spl.bin when
FEL is enabled, your right, AFAIK that binary will not work when written
to sdcard because FEL mode has a CONFIG_SPL_TEXT_BASE of 0x2000 where
as non FEL has CONFIG_SPL_TEXT_BASE set to 0x0020.

But we've discussed in the past to use 0x2000 everywhere, this would mean
moving the stack pointer to 0x2000 instead of 0x8000, and then making
the normal SPL fit between 0x2000 - 0x8000.

All you need to change then AFAIK is tools/mksunxiboot.c so that the jump
instruction which is the first 32 bit word of the header it generates jumps
to 0x2000 rather then 0x0020, and then we may be able to have a unified
build which does both FEL and regular SPL for sdcard boot.

Regards,

Hans


>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
>   arch/arm/cpu/armv7/sunxi/Makefile           |  4 +-
>   arch/arm/cpu/armv7/sunxi/board.c            | 21 ++++++++
>   arch/arm/cpu/armv7/sunxi/config.mk          |  2 -
>   arch/arm/cpu/armv7/sunxi/fel_utils.S        | 26 +++++++++
>   arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds | 82 -----------------------------
>   arch/arm/include/asm/arch-sunxi/sys_proto.h | 10 ++++
>   board/sunxi/Kconfig                         | 10 ++++
>   include/configs/sunxi-common.h              |  6 +--
>   scripts/Makefile.spl                        |  2 -
>   9 files changed, 70 insertions(+), 93 deletions(-)
>   create mode 100644 arch/arm/cpu/armv7/sunxi/fel_utils.S
>   delete mode 100644 arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
>
> diff --git a/arch/arm/cpu/armv7/sunxi/Makefile b/arch/arm/cpu/armv7/sunxi/Makefile
> index 48db744..c1b975a 100644
> --- a/arch/arm/cpu/armv7/sunxi/Makefile
> +++ b/arch/arm/cpu/armv7/sunxi/Makefile
> @@ -38,7 +38,5 @@ obj-$(CONFIG_MACH_SUN5I)	+= dram_sun4i.o
>   obj-$(CONFIG_MACH_SUN6I)	+= dram_sun6i.o
>   obj-$(CONFIG_MACH_SUN7I)	+= dram_sun4i.o
>   obj-$(CONFIG_MACH_SUN8I)	+= dram_sun8i.o
> -ifdef CONFIG_SPL_FEL
> -obj-y	+= start.o
> -endif
> +obj-y	+= fel_utils.o
>   endif
> diff --git a/arch/arm/cpu/armv7/sunxi/board.c b/arch/arm/cpu/armv7/sunxi/board.c
> index 6e28bcd..b7492ac 100644
> --- a/arch/arm/cpu/armv7/sunxi/board.c
> +++ b/arch/arm/cpu/armv7/sunxi/board.c
> @@ -27,6 +27,13 @@
>
>   #include <linux/compiler.h>
>
> +struct fel_stash {
> +	uint32_t sp;
> +	uint32_t lr;
> +};
> +
> +struct fel_stash fel_stash __attribute__((section(".data")));
> +
>   static int gpio_init(void)
>   {
>   #if CONFIG_CONS_INDEX == 1 && defined(CONFIG_UART0_PORT_F)
> @@ -65,6 +72,12 @@ static int gpio_init(void)
>   	return 0;
>   }
>
> +void spl_board_load_image(void)
> +{
> +	debug("Returning to FEL sp=%x, lr=%x\n", fel_stash.sp, fel_stash.lr);
> +	return_to_fel(fel_stash.sp, fel_stash.lr);
> +}
> +
>   void s_init(void)
>   {
>   #if defined CONFIG_MACH_SUN6I || defined CONFIG_MACH_SUN8I
> @@ -95,6 +108,14 @@ void s_init(void)
>    */
>   u32 spl_boot_device(void)
>   {
> +	/*
> +	 * Have we been asked to return to the FEL portion of the boot ROM?
> +	 * TODO: We need a more robust test here, or bracket this with
> +	 * #ifdef CONFIG_SPL_FEL.
> +	 */
> +	if (fel_stash.lr >= 0xffff0000 && fel_stash.lr < 0xffff4000)
> +		return BOOT_DEVICE_BOARD;
> +
>   	return BOOT_DEVICE_MMC1;
>   }
>
> diff --git a/arch/arm/cpu/armv7/sunxi/config.mk b/arch/arm/cpu/armv7/sunxi/config.mk
> index 00f5ffc..76ffec9 100644
> --- a/arch/arm/cpu/armv7/sunxi/config.mk
> +++ b/arch/arm/cpu/armv7/sunxi/config.mk
> @@ -1,8 +1,6 @@
>   # Build a combined spl + u-boot image
>   ifdef CONFIG_SPL
>   ifndef CONFIG_SPL_BUILD
> -ifndef CONFIG_SPL_FEL
>   ALL-y += u-boot-sunxi-with-spl.bin
>   endif
>   endif
> -endif
> diff --git a/arch/arm/cpu/armv7/sunxi/fel_utils.S b/arch/arm/cpu/armv7/sunxi/fel_utils.S
> new file mode 100644
> index 0000000..42739df
> --- /dev/null
> +++ b/arch/arm/cpu/armv7/sunxi/fel_utils.S
> @@ -0,0 +1,26 @@
> +/*
> + * Utility functions for FEL mode.
> + *
> + * Copyright (c) 2015 Google, Inc
> + *
> + * SPDX-License-Identifier:	GPL-2.0+
> + */
> +
> +#include <asm-offsets.h>
> +#include <config.h>
> +#include <asm/system.h>
> +#include <linux/linkage.h>
> +
> +ENTRY(save_boot_params)
> +	ldr	r0, =fel_stash
> +	str	sp, [r0, #0]
> +	str	r4, [r0, #4]	/* Store lr */
> +	mov	r0, #RESET_SKIP_VBVAR | RESET_SKIP_CP15
> +	bx	lr
> +ENDPROC(save_boot_params)
> +
> +ENTRY(return_to_fel)
> +	mov	sp, r0
> +	mov	lr, r1
> +	bx	lr
> +ENDPROC(return_to_fel)
> diff --git a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds b/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
> deleted file mode 100644
> index 928b7c1..0000000
> --- a/arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds
> +++ /dev/null
> @@ -1,82 +0,0 @@
> -/*
> - * (C) Copyright 2013
> - * Henrik Nordstrom <henrik@henriknordstrom.net>
> - *
> - * SPDX-License-Identifier:	GPL-2.0+
> - */
> -OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm")
> -OUTPUT_ARCH(arm)
> -ENTRY(s_init)
> -SECTIONS
> -{
> -	. = 0x00002000;
> -
> -	. = ALIGN(4);
> -	.text :
> -	{
> -		*(.text.s_init)
> -		*(.text*)
> -	}
> -
> -	. = ALIGN(4);
> -	.rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) }
> -
> -	. = ALIGN(4);
> -	.data : {
> -		*(.data*)
> -	}
> -
> -	. = ALIGN(4);
> -	.u_boot_list : {
> -		KEEP(*(SORT(.u_boot_list*)));
> -	}
> -
> -	. = ALIGN(4);
> -	. = .;
> -
> -	. = ALIGN(4);
> -	.rel.dyn : {
> -		__rel_dyn_start = .;
> -		*(.rel*)
> -		__rel_dyn_end = .;
> -	}
> -
> -	.dynsym : {
> -		__dynsym_start = .;
> -		*(.dynsym)
> -	}
> -
> -	. = ALIGN(4);
> -	.note.gnu.build-id :
> -	{
> -		*(.note.gnu.build-id)
> -	}
> -	_end = .;
> -
> -	. = ALIGN(4096);
> -	.mmutable : {
> -		*(.mmutable)
> -	}
> -
> -	.bss_start __rel_dyn_start (OVERLAY) : {
> -		KEEP(*(.__bss_start));
> -		__bss_base = .;
> -	}
> -
> -	.bss __bss_base (OVERLAY) : {
> -		*(.bss*)
> -		. = ALIGN(4);
> -		__bss_limit = .;
> -	}
> -
> -	.bss_end __bss_limit (OVERLAY) : {
> -		KEEP(*(.__bss_end));
> -	}
> -
> -	/DISCARD/ : { *(.dynstr*) }
> -	/DISCARD/ : { *(.dynamic*) }
> -	/DISCARD/ : { *(.plt*) }
> -	/DISCARD/ : { *(.interp*) }
> -	/DISCARD/ : { *(.gnu*) }
> -	/DISCARD/ : { *(.note*) }
> -}
> diff --git a/arch/arm/include/asm/arch-sunxi/sys_proto.h b/arch/arm/include/asm/arch-sunxi/sys_proto.h
> index c3e636e..60a5bd8 100644
> --- a/arch/arm/include/asm/arch-sunxi/sys_proto.h
> +++ b/arch/arm/include/asm/arch-sunxi/sys_proto.h
> @@ -13,4 +13,14 @@
>
>   void sdelay(unsigned long);
>
> +/* return_to_fel() - Return to BROM from SPL
> + *
> + * This returns back into the BROM after U-Boot SPL has performed its initial
> + * init. It uses the provided lr and sp to do so.
> + *
> + * @lr:		BROM link register value (return address)
> + * @sp:		BROM stack pointer
> + */
> +void return_to_fel(uint32_t lr, uint32_t sp);
> +
>   #endif
> diff --git a/board/sunxi/Kconfig b/board/sunxi/Kconfig
> index 4a21589..c50cffe 100644
> --- a/board/sunxi/Kconfig
> +++ b/board/sunxi/Kconfig
> @@ -149,6 +149,16 @@ config SPL_FEL
>   	bool "SPL/FEL mode support"
>   	depends on SPL
>   	default n
> +	help
> +	  This enables support for <insert_full_name_here> (FEL) mode. This
> +	  allows U-Boot to be loaded to the board over USB by the on-chip
> +	  boot rom. U-Boot should be sent in two parts: SPL first, with
> +	  'fel write 0x2000 u-boot-spl.bin; fel exe 0x2000' then U-Boot with
> +	  'fel write 0x4a000000 u-boot.bin; fel exe 0x4a000000'. This option
> +	  shrinks the amount of SRAM available to SPL, so only enable it if
> +	  you need FEL (why? what do we lose?). Note that enabling this option
> +	  only allows FEL to be used; it is still possible to boot U-Boot from
> +	  boot media. U-Boot SPL detects when it is being loaded using FEL.
>
>   config UART0_PORT_F
>   	bool "UART0 on MicroSD breakout board"
> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
> index 6cfd7e1..3becb4f 100644
> --- a/include/configs/sunxi-common.h
> +++ b/include/configs/sunxi-common.h
> @@ -18,10 +18,8 @@
>    */
>   #define CONFIG_SUNXI		/* sunxi family */
>   #ifdef CONFIG_SPL_BUILD
> -#ifndef CONFIG_SPL_FEL
>   #define CONFIG_SYS_THUMB_BUILD	/* Thumbs mode to save space in SPL */
>   #endif
> -#endif
>
>   #include <asm/arch/cpu.h>	/* get chip and board defs */
>
> @@ -146,10 +144,10 @@
>   #define CONFIG_SPL_SERIAL_SUPPORT
>   #define CONFIG_SPL_LIBGENERIC_SUPPORT
>
> +#define CONFIG_SPL_BOARD_LOAD_IMAGE
> +
>   #ifdef CONFIG_SPL_FEL
>
> -#define CONFIG_SPL_LDSCRIPT "arch/arm/cpu/armv7/sunxi/u-boot-spl-fel.lds"
> -#define CONFIG_SPL_START_S_PATH "arch/arm/cpu/armv7/sunxi"
>   #define CONFIG_SPL_TEXT_BASE		0x2000
>   #define CONFIG_SPL_MAX_SIZE		0x4000		/* 16 KiB */
>
> diff --git a/scripts/Makefile.spl b/scripts/Makefile.spl
> index ecf3037..5a1962b 100644
> --- a/scripts/Makefile.spl
> +++ b/scripts/Makefile.spl
> @@ -153,10 +153,8 @@ ALL-y	+= $(obj)/$(BOARD)-spl.bin
>   endif
>
>   ifdef CONFIG_SUNXI
> -ifndef CONFIG_SPL_FEL
>   ALL-y	+= $(obj)/sunxi-spl.bin
>   endif
> -endif
>
>   ifeq ($(CONFIG_SYS_SOC),"at91")
>   ALL-y	+= boot.bin
>

[U-Boot] [PATCH 2/5] arm: Allow reset init to be controlled

[Albert ARIBAUD]

Hello Simon,

On Tue,  3 Feb 2015 21:18:51 -0700, Simon Glass <sjg@chromium.org>
wrote:
> Some boards want to skip the normal reset init. For example OMAP4 SPL
> does not want to touch VBAR and many boards don't want to set up
> CP15.
> 
> Provide a return value from save_boot_params() which allows the board
> to indicate what reset processing should be done.

Does this have to be at run-time? I'd rather it were a build-time
config option.

> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
> 
>  arch/arm/cpu/armv7/exynos/spl_boot.c |  5 ++++-
>  arch/arm/cpu/armv7/start.S           | 11 ++++++++---
>  arch/arm/include/asm/system.h        | 15 +++++++++++++++
>  3 files changed, 27 insertions(+), 4 deletions(-)
> 
> diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c b/arch/arm/cpu/armv7/exynos/spl_boot.c
> index bc237c9..6e249f1 100644
> --- a/arch/arm/cpu/armv7/exynos/spl_boot.c
> +++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
> @@ -309,4 +309,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
>  	while (1)
>  		;
>  }
> -void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) {}
> +u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
> +{
> +	return 0;
> +}
> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
> index c5f94ef..0ba26f7 100644
> --- a/arch/arm/cpu/armv7/start.S
> +++ b/arch/arm/cpu/armv7/start.S
> @@ -52,6 +52,9 @@ reset:
>   * Continue to use ROM code vector only in OMAP4 spl)
>   */
>  #if !(defined(CONFIG_OMAP44XX) && defined(CONFIG_SPL_BUILD))
> +	teq	r0, #RESET_SKIP_VBVAR
> +	bne	vbar_done
> +
>  	/* Set V=0 in CP15 SCTLR register - for VBAR to point to vector */
>  	mrc	p15, 0, r2, c1, c0, 0	@ Read CP15 SCTLR Register
>  	bic	r2, #CR_V		@ V = 0
> @@ -61,10 +64,11 @@ reset:
>  	ldr	r2, =_start
>  	mcr	p15, 0, r2, c12, c0, 0	@Set VBAR
>  #endif
> -
> +vbar_done:
>  	/* the mask ROM code should have PLL and others stable */
>  #ifndef CONFIG_SKIP_LOWLEVEL_INIT
> -	bl	cpu_init_cp15
> +	teq	r0, #RESET_SKIP_CP15
> +	bleq	cpu_init_cp15
>  	bl	cpu_init_crit
>  #endif
>  
> @@ -88,11 +92,12 @@ ENDPROC(c_runtime_cpu_setup)
>  
>  /*************************************************************************
>   *
> - * void save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
> + * u32 save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
>   *	__attribute__((weak));
>   *
>   * Stack pointer is not yet initialized at this moment
>   * Don't save anything to stack even if compiled with -O0
> + * Return flags - see RESET_... in system.h
>   *
>   *************************************************************************/
>  ENTRY(save_boot_params)
> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
> index 89f2294..98e49a7 100644
> --- a/arch/arm/include/asm/system.h
> +++ b/arch/arm/include/asm/system.h
> @@ -140,8 +140,23 @@ void flush_l3_cache(void);
>   */
>  #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
>  
> +/* Control bits for reset processing */
> +#define RESET_SKIP_VBVAR	(1 << 0)	/* Skip vector address setup */
> +#define RESET_SKIP_CP15		(1 << 1)	/* Skip CP15 setup */
> +
>  #ifndef __ASSEMBLY__
>  
> +/**
> + * save_boot_params() - Save boot parameters before starting reset sequence
> + *
> + * @r0:		Value of r0
> + * @r1:		Value of r1
> + * @r2:		Value of r2
> + * @r3:		Value of r3
> + * @return reset flags (see RESET_... above)
> + */
> +u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3);
> +
>  #define isb() __asm__ __volatile__ ("" : : : "memory")
>  
>  #define nop() __asm__ __volatile__("mov\tr0,r0\t@ nop\n\t");
> -- 
> 2.2.0.rc0.207.ga3a616c
> 



Amicalement,
-- 
Albert.

[U-Boot] [PATCH 1/5] arm: Use r2 instead of r0 in start.S

[Albert ARIBAUD]

Hello Simon,

(sorry for the dupe)

On Tue,  3 Feb 2015 21:18:50 -0700, Simon Glass <sjg@chromium.org>
wrote:

> Allow r0 to be used for other purposes in this file.  

These purposes should be made clear -- possibly even, merged with the
code that actually needs it.

> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---  

Amicalement,
-- 
Albert.

[U-Boot] [PATCH 3/5] arm: Allow lr to be saved by board code

[Albert ARIBAUD]

Hello Simon,

On Tue,  3 Feb 2015 21:18:52 -0700, Simon Glass <sjg@chromium.org>
wrote:
> The link register value can be required on some boards (e.g. FEL mode on
> sunxi) so stash it to r4 before jumping to save_boot_params().

I'd rather not make this there; I would like save_boot_params to start
with as unmodified a core state as possible, because r4 might
actually, now or in the future, contain important data.

I'd even go as far as saying that save_boot_params should be branched
into rather than called, and should branch back to a fixed label right
after reset, so that even lr is preserved. For SoCs which do not need
to save any boot parameters, a weak version of save_boot_params would
just do the branching back.

(this should help merging all start.S instances into a singe one,
which I still want to achieve one day)

> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---

Amicalement,
-- 
Albert.

[U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support

[Albert ARIBAUD]

Hello Hans,

On Wed, 04 Feb 2015 09:47:41 +0100, Hans de Goede <hdegoede@redhat.com>
wrote:
> Hi,
> 
> On 04-02-15 05:18, Simon Glass wrote:
> > (What does FEL stand for?)
> >
> > This is an attempt to make sunxi's FEL code fit with the normal U-Boot
> > boot sequence instead of creating its own.
> >
> > Most of the FEL special-case code is removed, although I may have gone too
> > far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
> > FEL is enabled. This may not be possible since the MMC stack makes SPL
> > too large for FEL anyway, although it may be possible for other boot
> > mediums.
> >
> > This series is available at u-boot-dm, branch sunxi-working.
> 
> Thanks for working on this, I like the direction where this is heading,
> if Albert is ok with the start.S changes this would be an excellent way
> to fix FEL mode for v2015.04.

Even though the series came in after window close and after -rc1, I'm
fine with considering it for 2015.04.

Amicalement,
-- 
Albert.

[U-Boot] [PATCH 1/5] arm: Use r2 instead of r0 in start.S

[Simon Glass]

Hi Albert,

On 4 February 2015 at 01:57, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> Hello Simon,
>
> (sorry for the dupe)
>
> On Tue,  3 Feb 2015 21:18:50 -0700, Simon Glass <sjg@chromium.org>
> wrote:
>
>> Allow r0 to be used for other purposes in this file.
>
> These purposes should be made clear -- possibly even, merged with the
> code that actually needs it.

OK I'll wait until we figure out the other patches, then either add
the purpose or merge this one.

Regards,
Simon

[U-Boot] [PATCH 2/5] arm: Allow reset init to be controlled

[Simon Glass]

Hi Albert,

On 4 February 2015 at 01:50, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> Hello Simon,
>
> On Tue,  3 Feb 2015 21:18:51 -0700, Simon Glass <sjg@chromium.org>
> wrote:
>> Some boards want to skip the normal reset init. For example OMAP4 SPL
>> does not want to touch VBAR and many boards don't want to set up
>> CP15.
>>
>> Provide a return value from save_boot_params() which allows the board
>> to indicate what reset processing should be done.
>
> Does this have to be at run-time? I'd rather it were a build-time
> config option.

For sunxi, my objective is to remove the special-case FEL code.

Unfortunately when running in FEL mode it does not work if this init
is done. I would ideally like to have SPL determine what mode it is
running in, and work in each case (i.e. not hang). Yes we could make
this a compile-time option, but only at the expense of having two
different SPLs, one for FEL and one for everything else. See Hans'
work on trying to unify these also.

>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>>  arch/arm/cpu/armv7/exynos/spl_boot.c |  5 ++++-
>>  arch/arm/cpu/armv7/start.S           | 11 ++++++++---
>>  arch/arm/include/asm/system.h        | 15 +++++++++++++++
>>  3 files changed, 27 insertions(+), 4 deletions(-)
>>
>> diff --git a/arch/arm/cpu/armv7/exynos/spl_boot.c b/arch/arm/cpu/armv7/exynos/spl_boot.c
>> index bc237c9..6e249f1 100644
>> --- a/arch/arm/cpu/armv7/exynos/spl_boot.c
>> +++ b/arch/arm/cpu/armv7/exynos/spl_boot.c
>> @@ -309,4 +309,7 @@ void board_init_r(gd_t *id, ulong dest_addr)
>>       while (1)
>>               ;
>>  }
>> -void save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3) {}
>> +u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3)
>> +{
>> +     return 0;
>> +}
>> diff --git a/arch/arm/cpu/armv7/start.S b/arch/arm/cpu/armv7/start.S
>> index c5f94ef..0ba26f7 100644
>> --- a/arch/arm/cpu/armv7/start.S
>> +++ b/arch/arm/cpu/armv7/start.S
>> @@ -52,6 +52,9 @@ reset:
>>   * Continue to use ROM code vector only in OMAP4 spl)
>>   */
>>  #if !(defined(CONFIG_OMAP44XX) && defined(CONFIG_SPL_BUILD))
>> +     teq     r0, #RESET_SKIP_VBVAR
>> +     bne     vbar_done
>> +
>>       /* Set V=0 in CP15 SCTLR register - for VBAR to point to vector */
>>       mrc     p15, 0, r2, c1, c0, 0   @ Read CP15 SCTLR Register
>>       bic     r2, #CR_V               @ V = 0
>> @@ -61,10 +64,11 @@ reset:
>>       ldr     r2, =_start
>>       mcr     p15, 0, r2, c12, c0, 0  @Set VBAR
>>  #endif
>> -
>> +vbar_done:
>>       /* the mask ROM code should have PLL and others stable */
>>  #ifndef CONFIG_SKIP_LOWLEVEL_INIT
>> -     bl      cpu_init_cp15
>> +     teq     r0, #RESET_SKIP_CP15
>> +     bleq    cpu_init_cp15
>>       bl      cpu_init_crit
>>  #endif
>>
>> @@ -88,11 +92,12 @@ ENDPROC(c_runtime_cpu_setup)
>>
>>  /*************************************************************************
>>   *
>> - * void save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
>> + * u32 save_boot_params(u32 r2, u32 r1, u32 r2, u32 r3)
>>   *   __attribute__((weak));
>>   *
>>   * Stack pointer is not yet initialized at this moment
>>   * Don't save anything to stack even if compiled with -O0
>> + * Return flags - see RESET_... in system.h
>>   *
>>   *************************************************************************/
>>  ENTRY(save_boot_params)
>> diff --git a/arch/arm/include/asm/system.h b/arch/arm/include/asm/system.h
>> index 89f2294..98e49a7 100644
>> --- a/arch/arm/include/asm/system.h
>> +++ b/arch/arm/include/asm/system.h
>> @@ -140,8 +140,23 @@ void flush_l3_cache(void);
>>   */
>>  #define __asmeq(x, y)  ".ifnc " x "," y " ; .err ; .endif\n\t"
>>
>> +/* Control bits for reset processing */
>> +#define RESET_SKIP_VBVAR     (1 << 0)        /* Skip vector address setup */
>> +#define RESET_SKIP_CP15              (1 << 1)        /* Skip CP15 setup */
>> +
>>  #ifndef __ASSEMBLY__
>>
>> +/**
>> + * save_boot_params() - Save boot parameters before starting reset sequence
>> + *
>> + * @r0:              Value of r0
>> + * @r1:              Value of r1
>> + * @r2:              Value of r2
>> + * @r3:              Value of r3
>> + * @return reset flags (see RESET_... above)
>> + */
>> +u32 save_boot_params(u32 r0, u32 r1, u32 r2, u32 r3);
>> +
>>  #define isb() __asm__ __volatile__ ("" : : : "memory")
>>
>>  #define nop() __asm__ __volatile__("mov\tr0,r0\t@ nop\n\t");
>> --
>> 2.2.0.rc0.207.ga3a616c

Regards,
Simon

[U-Boot] [PATCH 3/5] arm: Allow lr to be saved by board code

[Simon Glass]

Hi Albert,

On 4 February 2015 at 01:59, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> Hello Simon,
>
> On Tue,  3 Feb 2015 21:18:52 -0700, Simon Glass <sjg@chromium.org>
> wrote:
>> The link register value can be required on some boards (e.g. FEL mode on
>> sunxi) so stash it to r4 before jumping to save_boot_params().
>
> I'd rather not make this there; I would like save_boot_params to start
> with as unmodified a core state as possible, because r4 might
> actually, now or in the future, contain important data.
>
> I'd even go as far as saying that save_boot_params should be branched
> into rather than called, and should branch back to a fixed label right
> after reset, so that even lr is preserved. For SoCs which do not need
> to save any boot parameters, a weak version of save_boot_params would
> just do the branching back.
>
> (this should help merging all start.S instances into a singe one,
> which I still want to achieve one day)

I did consider this but was worried that some save_boot_params()
functions are written in C (OMAP) so this would not work. But if we
can require it to be written in assembler, or provide an asm macro to
return from the C function, then I can do that. What do you think?

Regards,
Simon

[U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support

[Simon Glass]

Hi Hans,

On 4 February 2015 at 01:47, Hans de Goede <hdegoede@redhat.com> wrote:
> Hi,
>
> On 04-02-15 05:18, Simon Glass wrote:
>>
>> (What does FEL stand for?)
>>
>> This is an attempt to make sunxi's FEL code fit with the normal U-Boot
>> boot sequence instead of creating its own.
>>
>> Most of the FEL special-case code is removed, although I may have gone too
>> far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
>> FEL is enabled. This may not be possible since the MMC stack makes SPL
>> too large for FEL anyway, although it may be possible for other boot
>> mediums.
>>
>> This series is available at u-boot-dm, branch sunxi-working.
>
>
> Thanks for working on this, I like the direction where this is heading,
> if Albert is ok with the start.S changes this would be an excellent way
> to fix FEL mode for v2015.04.

OK great!

>
> WRT you going to far when also building a u-boot-sunxi-with-spl.bin when
> FEL is enabled, your right, AFAIK that binary will not work when written
> to sdcard because FEL mode has a CONFIG_SPL_TEXT_BASE of 0x2000 where
> as non FEL has CONFIG_SPL_TEXT_BASE set to 0x0020.
>
> But we've discussed in the past to use 0x2000 everywhere, this would mean
> moving the stack pointer to 0x2000 instead of 0x8000, and then making
> the normal SPL fit between 0x2000 - 0x8000.
>
> All you need to change then AFAIK is tools/mksunxiboot.c so that the jump
> instruction which is the first 32 bit word of the header it generates jumps
> to 0x2000 rather then 0x0020, and then we may be able to have a unified
> build which does both FEL and regular SPL for sdcard boot.

Interesting, I wondered about that.

I see your other series too so this could all fit quite nicely. I'll
focus on getting this series through with Albert's help.

Regards,
Simon

[U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support

[Hans de Goede]

Hi,

On 05-02-15 03:52, Simon Glass wrote:
> Hi Hans,
>
> On 4 February 2015 at 01:47, Hans de Goede <hdegoede@redhat.com> wrote:
>> Hi,
>>
>> On 04-02-15 05:18, Simon Glass wrote:
>>>
>>> (What does FEL stand for?)
>>>
>>> This is an attempt to make sunxi's FEL code fit with the normal U-Boot
>>> boot sequence instead of creating its own.
>>>
>>> Most of the FEL special-case code is removed, although I may have gone too
>>> far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
>>> FEL is enabled. This may not be possible since the MMC stack makes SPL
>>> too large for FEL anyway, although it may be possible for other boot
>>> mediums.
>>>
>>> This series is available at u-boot-dm, branch sunxi-working.
>>
>>
>> Thanks for working on this, I like the direction where this is heading,
>> if Albert is ok with the start.S changes this would be an excellent way
>> to fix FEL mode for v2015.04.
>
> OK great!
>
>>
>> WRT you going to far when also building a u-boot-sunxi-with-spl.bin when
>> FEL is enabled, your right, AFAIK that binary will not work when written
>> to sdcard because FEL mode has a CONFIG_SPL_TEXT_BASE of 0x2000 where
>> as non FEL has CONFIG_SPL_TEXT_BASE set to 0x0020.
>>
>> But we've discussed in the past to use 0x2000 everywhere, this would mean
>> moving the stack pointer to 0x2000 instead of 0x8000, and then making
>> the normal SPL fit between 0x2000 - 0x8000.
>>
>> All you need to change then AFAIK is tools/mksunxiboot.c so that the jump
>> instruction which is the first 32 bit word of the header it generates jumps
>> to 0x2000 rather then 0x0020, and then we may be able to have a unified
>> build which does both FEL and regular SPL for sdcard boot.
>
> Interesting, I wondered about that.
>
> I see your other series too so this could all fit quite nicely. I'll
> focus on getting this series through with Albert's help.

Great, thanks for working on this. About the having one unified SPL,
I believe that that is probably best left as something to do for
v2015.07, and that we should just try to get your work to fix FEL mode
to work in for v2015.04, do you agree ?

I'm asking because I'm wondering what the plan is wrt merging my
SPL size reduction series, we could in theory add that to v2015.04,
but it can also wait, and from a merge window pov it should wait.

If we want to add it to v2015.04 anyways I can take it upstream in its
entirety through u-boot-sunxi, or you can first merge the 2
malloc_simple patches through u-boot-dm.

Regards,

Hans

[U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support

[Siarhei Siamashka]

On Tue,  3 Feb 2015 21:18:54 -0700
Simon Glass <sjg@chromium.org> wrote:

> (What does FEL stand for?)

That's a good question. I believe that it might be based on
the "jump to fel" message from the console output of the
Allwinner's BOOT0 bootloader: http://linux-sunxi.org/FEL#Serial_output

Other than this, I don't know what this name stands for.

In fact the FEL code has a special entry point at 0xffff0020, which is
the target of this "jump to fel" action in BOOT0:
    https://github.com/hno/Allwinner-Info/blob/master/BROM/ffff0000.s#L9

It initializes the USB hardware again, and I believe that this is the
reason why I have some problems trying to use this method. So far the
flow looks like this:

1. The SPL is uploaded to SRAM and executed (to initialize DRAM) and
   other things.
2. As the last step in the SPL ('return_to_fel' in your code), we just
   transfer control directly to 0xffff0020 instead of using the address
   from the lr register.
3. The USB stack in my PC seems to be a bit confused by the MBUS
   hardware re-init. For example, the next "fel ver" command fails
   for me with a timeout. However the follow up fel commands work fine,
   and I can successfully "write" and "exe" the main u-boot binary.

The incomplete demo patch for the fel tool has been posted at
    http://lists.denx.de/pipermail/u-boot/2015-February/204024.html

> This is an attempt to make sunxi's FEL code fit with the normal U-Boot
> boot sequence instead of creating its own.
>
> Most of the FEL special-case code is removed, although I may have gone too
> far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
> FEL is enabled. This may not be possible since the MMC stack makes SPL
> too large for FEL anyway, although it may be possible for other boot
> mediums.

This is actually very good.

If we can resolve the jump to 0xffff0020 problems (try to perform a
clean USB shutdown before doing this?), then the SPL size limitation
for USB booting is gone and we get a unified SPL binary for both SD
card boot and boot over USB. With no need for a lot of special sunxi
things in the U-Boot boot sequence. I'm going to have another look
at it today in the evening to see if the remaining problems can be
resolved.

> This series is available at u-boot-dm, branch sunxi-working.

Thanks a lot for this work.

-- 
Best regards,
Siarhei Siamashka

[U-Boot] [PATCH 3/5] arm: Allow lr to be saved by board code

[Albert ARIBAUD]

Hello Simon,

On Wed, 4 Feb 2015 19:51:36 -0700, Simon Glass <sjg@chromium.org> wrote:
> Hi Albert,
> 
> On 4 February 2015 at 01:59, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> > Hello Simon,
> >
> > On Tue,  3 Feb 2015 21:18:52 -0700, Simon Glass <sjg@chromium.org>
> > wrote:
> >> The link register value can be required on some boards (e.g. FEL mode on
> >> sunxi) so stash it to r4 before jumping to save_boot_params().
> >
> > I'd rather not make this there; I would like save_boot_params to start
> > with as unmodified a core state as possible, because r4 might
> > actually, now or in the future, contain important data.
> >
> > I'd even go as far as saying that save_boot_params should be branched
> > into rather than called, and should branch back to a fixed label right
> > after reset, so that even lr is preserved. For SoCs which do not need
> > to save any boot parameters, a weak version of save_boot_params would
> > just do the branching back.
> >
> > (this should help merging all start.S instances into a singe one,
> > which I still want to achieve one day)
> 
> I did consider this but was worried that some save_boot_params()
> functions are written in C (OMAP) so this would not work. But if we
> can require it to be written in assembler, or provide an asm macro to
> return from the C function, then I can do that. What do you think?

I think that save_boot_params runs right at reset and cannot rely on any
C environment at all, and should indeed be written in asm and only deal
with *very urgent* savings; only those registers that would be lost
almost immediately, like r0-r14 and some system registers. Anything
else is less urgent and can be processed later, possibly even in
board_init_f().

That being said, OMAP does not have save_boot_params in C that I can
find; actualy, doing a 'git grep save_boot_param -- *.c' shows only
one occurrence, in arch/arm/cpu/armv7/exynos/spl_boot.c, ar line 312,
and it's an empty function. OMAP has an s_init C implementation,
though.

> Regards,
> Simon

Amicalement,
-- 
Albert.

[U-Boot] [PATCH 3/5] arm: Allow lr to be saved by board code

[Simon Glass]

Hi Albert,

On 5 February 2015 at 07:15, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> Hello Simon,
>
> On Wed, 4 Feb 2015 19:51:36 -0700, Simon Glass <sjg@chromium.org> wrote:
>> Hi Albert,
>>
>> On 4 February 2015 at 01:59, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
>> > Hello Simon,
>> >
>> > On Tue,  3 Feb 2015 21:18:52 -0700, Simon Glass <sjg@chromium.org>
>> > wrote:
>> >> The link register value can be required on some boards (e.g. FEL mode on
>> >> sunxi) so stash it to r4 before jumping to save_boot_params().
>> >
>> > I'd rather not make this there; I would like save_boot_params to start
>> > with as unmodified a core state as possible, because r4 might
>> > actually, now or in the future, contain important data.
>> >
>> > I'd even go as far as saying that save_boot_params should be branched
>> > into rather than called, and should branch back to a fixed label right
>> > after reset, so that even lr is preserved. For SoCs which do not need
>> > to save any boot parameters, a weak version of save_boot_params would
>> > just do the branching back.
>> >
>> > (this should help merging all start.S instances into a singe one,
>> > which I still want to achieve one day)
>>
>> I did consider this but was worried that some save_boot_params()
>> functions are written in C (OMAP) so this would not work. But if we
>> can require it to be written in assembler, or provide an asm macro to
>> return from the C function, then I can do that. What do you think?
>
> I think that save_boot_params runs right at reset and cannot rely on any
> C environment at all, and should indeed be written in asm and only deal
> with *very urgent* savings; only those registers that would be lost
> almost immediately, like r0-r14 and some system registers. Anything
> else is less urgent and can be processed later, possibly even in
> board_init_f().
>
> That being said, OMAP does not have save_boot_params in C that I can
> find; actualy, doing a 'git grep save_boot_param -- *.c' shows only
> one occurrence, in arch/arm/cpu/armv7/exynos/spl_boot.c, ar line 312,
> and it's an empty function. OMAP has an s_init C implementation,
> though.

Ah yes, I may have been thinking of exynos and since it is empty it
can be dropped. I'll go ahead and change this and resend once we have
the other issues resolved.

Regards,
Simon

[U-Boot] [PATCH 3/5] arm: Allow lr to be saved by board code

[Tom Rini]

On Wed, Feb 04, 2015 at 07:51:36PM -0700, Simon Glass wrote:
> Hi Albert,
> 
> On 4 February 2015 at 01:59, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote:
> > Hello Simon,
> >
> > On Tue,  3 Feb 2015 21:18:52 -0700, Simon Glass <sjg@chromium.org>
> > wrote:
> >> The link register value can be required on some boards (e.g. FEL mode on
> >> sunxi) so stash it to r4 before jumping to save_boot_params().
> >
> > I'd rather not make this there; I would like save_boot_params to start
> > with as unmodified a core state as possible, because r4 might
> > actually, now or in the future, contain important data.
> >
> > I'd even go as far as saying that save_boot_params should be branched
> > into rather than called, and should branch back to a fixed label right
> > after reset, so that even lr is preserved. For SoCs which do not need
> > to save any boot parameters, a weak version of save_boot_params would
> > just do the branching back.
> >
> > (this should help merging all start.S instances into a singe one,
> > which I still want to achieve one day)
> 
> I did consider this but was worried that some save_boot_params()
> functions are written in C (OMAP) so this would not work. But if we

Keep in mind that save_boot_params() isn't the same as
save_omap_boot_params().  On OMAP (well, OMAP/AM/etc) save_boot_params
is arch/arm/cpu/armv7/omap-common/lowlevel_init.S::save_boot_params
which copies a value from r1 to a magic SRAM location that
save_omap_boot_params() deals with.  So I agree with Albert, we can't
know what registers have important data in them and must not touch.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150205/783785a1/attachment.sig>

[U-Boot] [PATCH 5/5] RFC: sunxi: WIP FEL support

[Simon Glass]

Hi Siarhei,

On 5 February 2015 at 03:21, Siarhei Siamashka
<siarhei.siamashka@gmail.com> wrote:
> On Tue,  3 Feb 2015 21:18:54 -0700
> Simon Glass <sjg@chromium.org> wrote:
>
>> (What does FEL stand for?)
>
> That's a good question. I believe that it might be based on
> the "jump to fel" message from the console output of the
> Allwinner's BOOT0 bootloader: http://linux-sunxi.org/FEL#Serial_output
>
> Other than this, I don't know what this name stands for.

Can we ask the manufacturer? Maybe it is something like Firmware Early Loader?

>
> In fact the FEL code has a special entry point at 0xffff0020, which is
> the target of this "jump to fel" action in BOOT0:
>     https://github.com/hno/Allwinner-Info/blob/master/BROM/ffff0000.s#L9
>
> It initializes the USB hardware again, and I believe that this is the
> reason why I have some problems trying to use this method. So far the
> flow looks like this:
>
> 1. The SPL is uploaded to SRAM and executed (to initialize DRAM) and
>    other things.
> 2. As the last step in the SPL ('return_to_fel' in your code), we just
>    transfer control directly to 0xffff0020 instead of using the address
>    from the lr register.
> 3. The USB stack in my PC seems to be a bit confused by the MBUS
>    hardware re-init. For example, the next "fel ver" command fails
>    for me with a timeout. However the follow up fel commands work fine,
>    and I can successfully "write" and "exe" the main u-boot binary.
>
> The incomplete demo patch for the fel tool has been posted at
>     http://lists.denx.de/pipermail/u-boot/2015-February/204024.html
>
>> This is an attempt to make sunxi's FEL code fit with the normal U-Boot
>> boot sequence instead of creating its own.
>>
>> Most of the FEL special-case code is removed, although I may have gone too
>> far with my changes to generate a u-boot-sunxi-with-spl.bin file even when
>> FEL is enabled. This may not be possible since the MMC stack makes SPL
>> too large for FEL anyway, although it may be possible for other boot
>> mediums.
>
> This is actually very good.
>
> If we can resolve the jump to 0xffff0020 problems (try to perform a
> clean USB shutdown before doing this?), then the SPL size limitation
> for USB booting is gone and we get a unified SPL binary for both SD
> card boot and boot over USB. With no need for a lot of special sunxi
> things in the U-Boot boot sequence. I'm going to have another look
> at it today in the evening to see if the remaining problems can be
> resolved.
>
>> This series is available at u-boot-dm, branch sunxi-working.
>
> Thanks a lot for this work.

It looks like this might get improved quite a bit - despite the lack
of docs you seem to understand it very well :-)

In any case I'll be using FEL from now on on sunxi. It is much more convenient.

Regards,
Simon