[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation

[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation

[Simon Glass]

There has been talk on and off of a pre-relocation malloc() implementation.
Driver model needs this so that it can work before relocation.

A previous implementation was sent in a v1 series.

This implementation works by allocating space on the stack. The benefit is
that boards do not need to specify the address of the malloc() area, only
the size. The down-side is that due to the way board_init_f() is called,
architecture-specific code needs to be used to allocate the space.

No clever algorithms are used to allocate space, free() is a nop and
realloc() is not supported. This fits well with the desire to avoid wasting
space on bucket tables and the hassle of supporting BSS data before
relocation. We don't expect 'churn' in the pre-relocation case - we just
want to allocate small amounts of memory temporarily.

After relocation a new malloc() pool is created and the old one is lost,
although pointers into it will survive the immediate process of relocation.

Implementations are provided for sandbox and arm (32-bit only).

A related change is made to the early init for each arch to make this work.

Changes in v3:
- Fix assembler code comment in crt0.S to say GD, not BSS
- Ensure that aarch64 stays as it was
- Add newline after clr_gd label
- Remove redundant mov r0, #0
- Rebase on earlier patch
- Put the two CONFIG changes together in sandbox.h

Changes in v2:
- Tidy up commit message typo

Simon Glass (9):
  Remove form-feeds from dlmalloc.c
  arm: Set up global data before board_init_f()
  sandbox: Set up global data before board_init_f()
  Add a simple malloc() implementation for pre-relocation
  arm: Support pre-relocation malloc()
  exynos: Enable pre-relocation malloc()
  sandbox: Support pre-relocation malloc()
  sandbox: config: Enable pre-relocation malloc()
  sandbox: Always enable malloc debug

 README                            | 16 ++++++++
 arch/arm/include/asm/config.h     |  2 +
 arch/arm/lib/crt0.S               | 12 ++++++
 arch/sandbox/cpu/start.c          |  8 ++++
 arch/sandbox/include/asm/config.h |  1 -
 common/board_f.c                  | 12 ++++++
 common/board_r.c                  |  4 ++
 common/dlmalloc.c                 | 85 ++++++++++++++++++++++++++++-----------
 include/asm-generic/global_data.h |  5 +++
 include/configs/exynos5-dt.h      |  4 +-
 include/configs/sandbox.h         |  4 +-
 lib/asm-offsets.c                 |  3 ++
 12 files changed, 129 insertions(+), 27 deletions(-)

-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 1/9] Remove form-feeds from dlmalloc.c

[Simon Glass]

These don't really serve any purpose in the modern age. On the other hand
they show up as annoying control characters in my editor, which then happily
removes them.

I believe we can drop these characters from the file.

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

Changes in v3: None
Changes in v2:
- Tidy up commit message typo

 common/dlmalloc.c | 46 +++++++++++++++++++++++-----------------------
 1 file changed, 23 insertions(+), 23 deletions(-)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 3c70d5d..d1cd561 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -220,7 +220,7 @@
 
 */
 
-\f
+
 
 /* Preliminaries */
 
@@ -1132,7 +1132,7 @@ gAllocatedSize))
 
 #endif
 
-\f
+
 
 /*
   Type declarations
@@ -1272,7 +1272,7 @@ nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        serviced via calls to mmap, and then later released via munmap.
 
 */
-\f
+
 /*  sizes, alignments */
 
 #define SIZE_SZ                (sizeof(INTERNAL_SIZE_T))
@@ -1297,7 +1297,7 @@ nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 #define aligned_OK(m)    (((unsigned long)((m)) & (MALLOC_ALIGN_MASK)) == 0)
 
 
-\f
+
 
 /*
   Physical chunk operations
@@ -1332,7 +1332,7 @@ nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 #define chunk_at_offset(p, s)  ((mchunkptr)(((char*)(p)) + (s)))
 
 
-\f
+
 
 /*
   Dealing with use bits
@@ -1371,7 +1371,7 @@ nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  (((mchunkptr)(((char*)(p)) + (s)))->size &= ~(PREV_INUSE))
 
 
-\f
+
 
 /*
   Dealing with size fields
@@ -1394,7 +1394,7 @@ nextchunk-> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 #define set_foot(p, s)   (((mchunkptr)((char*)(p) + (s)))->prev_size = (s))
 
 
-\f
+
 
 
 /*
@@ -1566,7 +1566,7 @@ void mem_malloc_init(ulong start, ulong size)
 
 #define is_small_request(nb) (nb < MAX_SMALLBIN_SIZE - SMALLBIN_WIDTH)
 
-\f
+
 
 /*
     To help compensate for the large number of bins, a one-level index
@@ -1590,7 +1590,7 @@ void mem_malloc_init(ulong start, ulong size)
 #define clear_binblock(ii)  (binblocks_w = (mbinptr)(binblocks_r & ~(idx2binblock(ii))))
 
 
-\f
+
 
 
 /*  Other static bookkeeping data */
@@ -1628,7 +1628,7 @@ static unsigned int max_n_mmaps = 0;
 static unsigned long max_mmapped_mem = 0;
 #endif
 
-\f
+
 
 /*
   Debugging support
@@ -1769,7 +1769,7 @@ static void do_check_malloced_chunk(p, s) mchunkptr p; INTERNAL_SIZE_T s;
 #define check_malloced_chunk(P,N)
 #endif
 
-\f
+
 
 /*
   Macro-based internal utilities
@@ -1841,7 +1841,7 @@ static void do_check_malloced_chunk(p, s) mchunkptr p; INTERNAL_SIZE_T s;
   (last_remainder->fd = last_remainder->bk = last_remainder)
 
 
-\f
+
 
 
 /* Routines dealing with mmap(). */
@@ -1972,7 +1972,7 @@ static mchunkptr mremap_chunk(p, new_size) mchunkptr p; size_t new_size;
 #endif /* HAVE_MMAP */
 
 
-\f
+
 
 /*
   Extend the top-most chunk by obtaining memory from system.
@@ -2089,7 +2089,7 @@ static void malloc_extend_top(nb) INTERNAL_SIZE_T nb;
 }
 
 
-\f
+
 
 /* Main public routines */
 
@@ -2396,7 +2396,7 @@ Void_t* mALLOc(bytes) size_t bytes;
 }
 
 
-\f
+
 
 /*
 
@@ -2513,7 +2513,7 @@ void fREe(mem) Void_t* mem;
 }
 
 
-\f
+
 
 
 /*
@@ -2750,7 +2750,7 @@ Void_t* rEALLOc(oldmem, bytes) Void_t* oldmem; size_t bytes;
 }
 
 
-\f
+
 
 /*
 
@@ -2868,7 +2868,7 @@ Void_t* mEMALIGn(alignment, bytes) size_t alignment; size_t bytes;
 
 }
 
-\f
+
 
 
 /*
@@ -2975,7 +2975,7 @@ void cfree(mem) Void_t *mem;
 }
 #endif
 
-\f
+
 
 /*
 
@@ -3056,7 +3056,7 @@ int malloc_trim(pad) size_t pad;
   }
 }
 
-\f
+
 
 /*
   malloc_usable_size:
@@ -3092,7 +3092,7 @@ size_t malloc_usable_size(mem) Void_t* mem;
 }
 
 
-\f
+
 
 /* Utility to update current_mallinfo for malloc_stats and mallinfo() */
 
@@ -3136,7 +3136,7 @@ static void malloc_update_mallinfo()
 }
 #endif	/* DEBUG */
 
-\f
+
 
 /*
 
@@ -3183,7 +3183,7 @@ struct mallinfo mALLINFo()
 #endif	/* DEBUG */
 
 
-\f
+
 
 /*
   mallopt:
-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 2/9] arm: Set up global data before board_init_f()

[Simon Glass]

At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that
the global_data pointer is set up in board_init_f(). However it is
actually set up before this, it just isn't zeroed.

If we zero the global data before calling board_init_f() then we
don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.

Make this change (on arm32 only) to simplify the init process. I
don't have the ability to test aarch64 yet.

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

Changes in v3:
- Fix assembler code comment in crt0.S to say GD, not BSS
- Ensure that aarch64 stays as it was
- Add newline after clr_gd label
- Remove redundant mov r0, #0

Changes in v2: None

 arch/arm/include/asm/config.h | 2 ++
 arch/arm/lib/crt0.S           | 9 +++++++++
 2 files changed, 11 insertions(+)

diff --git a/arch/arm/include/asm/config.h b/arch/arm/include/asm/config.h
index d3433da..5f2a5f4 100644
--- a/arch/arm/include/asm/config.h
+++ b/arch/arm/include/asm/config.h
@@ -7,7 +7,9 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
+#ifdef __aarch64__
 #define CONFIG_SYS_GENERIC_GLOBAL_DATA
+#endif
 
 #define CONFIG_LMB
 #define CONFIG_SYS_BOOT_RAMDISK_HIGH
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index dfc2de9..43aa212 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -67,10 +67,19 @@ ENTRY(_main)
 	ldr	sp, =(CONFIG_SYS_INIT_SP_ADDR)
 #endif
 	bic	sp, sp, #7	/* 8-byte alignment for ABI compliance */
+	mov	r2, sp
 	sub	sp, sp, #GD_SIZE	/* allocate one GD above SP */
 	bic	sp, sp, #7	/* 8-byte alignment for ABI compliance */
 	mov	r9, sp		/* GD is above SP */
+	mov	r1, sp
 	mov	r0, #0
+clr_gd:
+	cmp	r1, r2			/* while not at end of GD */
+	strlo	r0, [r1]		/* clear 32-bit GD word */
+	addlo	r1, r1, #4		/* move to next */
+	blo	clr_gd
+
+	/* mov r0, #0 not needed due to above code */
 	bl	board_init_f
 
 #if ! defined(CONFIG_SPL_BUILD)
-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 3/9] sandbox: Set up global data before board_init_f()

[Simon Glass]

At present sandbox defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that
the global_data pointer is set up in board_init_f().

If we set up and zero the global data before calling board_init_f() then we
don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.

Make this change to simplify the init process.

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

Changes in v3: None
Changes in v2: None

 arch/sandbox/cpu/start.c          | 5 +++++
 arch/sandbox/include/asm/config.h | 1 -
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index aad3b8b..5289291 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -6,6 +6,7 @@
 #include <common.h>
 #include <os.h>
 #include <asm/getopt.h>
+#include <asm/io.h>
 #include <asm/sections.h>
 #include <asm/state.h>
 
@@ -218,6 +219,7 @@ SANDBOX_CMDLINE_OPT_SHORT(terminal, 't', 1,
 int main(int argc, char *argv[])
 {
 	struct sandbox_state *state;
+	gd_t data;
 	int ret;
 
 	ret = state_init();
@@ -236,6 +238,9 @@ int main(int argc, char *argv[])
 	if (state->ram_buf_rm && state->ram_buf_fname)
 		os_unlink(state->ram_buf_fname);
 
+	memset(&data, '\0', sizeof(data));
+	gd = &data;
+
 	/* Do pre- and post-relocation init */
 	board_init_f(0);
 
diff --git a/arch/sandbox/include/asm/config.h b/arch/sandbox/include/asm/config.h
index 6c1bff9..ec7729e 100644
--- a/arch/sandbox/include/asm/config.h
+++ b/arch/sandbox/include/asm/config.h
@@ -7,7 +7,6 @@
 #ifndef _ASM_CONFIG_H_
 #define _ASM_CONFIG_H_
 
-#define CONFIG_SYS_GENERIC_GLOBAL_DATA
 #define CONFIG_SANDBOX_ARCH
 
 /* Used by drivers/spi/sandbox_spi.c and arch/sandbox/include/asm/state.h */
-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 4/9] Add a simple malloc() implementation for pre-relocation

[Simon Glass]

If we are to have driver model before relocation we need to support some
way of calling memory allocation routines.

The standard malloc() is pretty complicated:

1. It uses some BSS memory for its state, and BSS is not available before
relocation

2. It supports algorithms for reducing memory fragmentation and improving
performace of free(). Before relocation we could happily just not support
free().

3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
this has been loaded anyway this is not really a problem.

The simplest way to support pre-relocation malloc() is to reserve an area
of memory and allocate it in increasing blocks as needed. This
implementation does this.

To enable it, you need to define the size of the malloc() pool as described
in the README. It will be located above the pre-relocation stack on
supported architectures.

Note that this implementation is only useful on machines which have some
memory available before dram_init() is called - this includes those that
do no DRAM init (like tegra) and those that do it in SPL (quite a few
boards). Enabling driver model preior to relocation for the rest of the
boards is left for a later exercise.

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

Changes in v3: None
Changes in v2: None

 README                            | 13 +++++++++++++
 common/board_f.c                  | 12 ++++++++++++
 common/board_r.c                  |  4 ++++
 common/dlmalloc.c                 | 35 +++++++++++++++++++++++++++++++++++
 include/asm-generic/global_data.h |  5 +++++
 lib/asm-offsets.c                 |  3 +++
 6 files changed, 72 insertions(+)

diff --git a/README b/README
index 4ac7399..11e9d31 100644
--- a/README
+++ b/README
@@ -3736,6 +3736,19 @@ Configuration Settings:
 - CONFIG_SYS_MALLOC_LEN:
 		Size of DRAM reserved for malloc() use.
 
+- CONFIG_SYS_MALLOC_F_LEN
+		Size of the malloc() pool for use before relocation. If
+		this is defined, then a very simple malloc() implementation
+		will become available before relocation. The address is just
+		below the global data, and the stack is moved down to make
+		space.
+
+		This feature allocates regions with increasing addresses
+		within the region. calloc() is supported, but realloc()
+		is not available. free() is supported but does nothing.
+		The memory will be freed (or in fact just forgotton) when
+		U-Boot relocates itself.
+
 - CONFIG_SYS_BOOTM_LEN:
 		Normally compressed uImages are limited to an
 		uncompressed size of 8 MBytes. If this is not enough,
diff --git a/common/board_f.c b/common/board_f.c
index 4ea4cb2..b5e2031 100644
--- a/common/board_f.c
+++ b/common/board_f.c
@@ -776,6 +776,17 @@ static int mark_bootstage(void)
 	return 0;
 }
 
+static int initf_malloc(void)
+{
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+	assert(gd->malloc_base);	/* Set up by crt0.S */
+	gd->malloc_limit = gd->malloc_base + CONFIG_SYS_MALLOC_F_LEN;
+	gd->malloc_ptr = 0;
+#endif
+
+	return 0;
+}
+
 static init_fnc_t init_sequence_f[] = {
 #ifdef CONFIG_SANDBOX
 	setup_ram_buf,
@@ -833,6 +844,7 @@ static init_fnc_t init_sequence_f[] = {
 	sdram_adjust_866,
 	init_timebase,
 #endif
+	initf_malloc,
 	init_baud_rate,		/* initialze baudrate settings */
 	serial_init,		/* serial communications setup */
 	console_init_f,		/* stage 1 init of console */
diff --git a/common/board_r.c b/common/board_r.c
index 602a239..86424a0 100644
--- a/common/board_r.c
+++ b/common/board_r.c
@@ -259,6 +259,10 @@ static int initr_malloc(void)
 {
 	ulong malloc_start;
 
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+	debug("Pre-reloc malloc() used %#lx bytes (%ld KB)\n", gd->malloc_ptr,
+	      gd->malloc_ptr / 1024);
+#endif
 	/* The malloc area is immediately below the monitor copy in DRAM */
 	malloc_start = gd->relocaddr - TOTAL_MALLOC_LEN;
 	mem_malloc_init((ulong)map_sysmem(malloc_start, TOTAL_MALLOC_LEN),
diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index d1cd561..26ba8fd 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -930,6 +930,8 @@ struct mallinfo mALLINFo();
 #endif	/* 0 */			/* Moved to malloc.h */
 
 #include <malloc.h>
+#include <asm/io.h>
+
 #ifdef DEBUG
 #if __STD_C
 static void malloc_update_mallinfo (void);
@@ -2174,6 +2176,20 @@ Void_t* mALLOc(bytes) size_t bytes;
 
   INTERNAL_SIZE_T nb;
 
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+	if (!(gd->flags & GD_FLG_RELOC)) {
+		ulong new_ptr;
+		void *ptr;
+
+		new_ptr = gd->malloc_ptr + bytes;
+		if (new_ptr > gd->malloc_limit)
+			panic("Out of pre-reloc memory");
+		ptr = map_sysmem(gd->malloc_base + gd->malloc_ptr, bytes);
+		gd->malloc_ptr = ALIGN(new_ptr, sizeof(new_ptr));
+		return ptr;
+	}
+#endif
+
   /* check if mem_malloc_init() was run */
   if ((mem_malloc_start == 0) && (mem_malloc_end == 0)) {
     /* not initialized yet */
@@ -2437,6 +2453,12 @@ void fREe(mem) Void_t* mem;
   mchunkptr fwd;       /* misc temp for linking */
   int       islr;      /* track whether merging with last_remainder */
 
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+	/* free() is a no-op - all the memory will be freed on relocation */
+	if (!(gd->flags & GD_FLG_RELOC))
+		return;
+#endif
+
   if (mem == NULL)                              /* free(0) has no effect */
     return;
 
@@ -2588,6 +2610,13 @@ Void_t* rEALLOc(oldmem, bytes) Void_t* oldmem; size_t bytes;
   /* realloc of null is supposed to be same as malloc */
   if (oldmem == NULL) return mALLOc(bytes);
 
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+	if (!(gd->flags & GD_FLG_RELOC)) {
+		/* This is harder to support and should not be needed */
+		panic("pre-reloc realloc() is not supported");
+	}
+#endif
+
   newp    = oldp    = mem2chunk(oldmem);
   newsize = oldsize = chunksize(oldp);
 
@@ -2933,6 +2962,12 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
     return NULL;
   else
   {
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+	if (!(gd->flags & GD_FLG_RELOC)) {
+		MALLOC_ZERO(mem, sz);
+		return mem;
+	}
+#endif
     p = mem2chunk(mem);
 
     /* Two optional cases in which clearing not necessary */
diff --git a/include/asm-generic/global_data.h b/include/asm-generic/global_data.h
index 2850ed8..f6a2a20 100644
--- a/include/asm-generic/global_data.h
+++ b/include/asm-generic/global_data.h
@@ -85,6 +85,11 @@ typedef struct global_data {
 #endif
 	unsigned long timebase_h;
 	unsigned long timebase_l;
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+	unsigned long malloc_base;	/* base address of early malloc() */
+	unsigned long malloc_limit;	/* limit address */
+	unsigned long malloc_ptr;	/* current address */
+#endif
 	struct arch_global_data arch;	/* architecture-specific data */
 } gd_t;
 #endif
diff --git a/lib/asm-offsets.c b/lib/asm-offsets.c
index 6ea7b03..129bc3e 100644
--- a/lib/asm-offsets.c
+++ b/lib/asm-offsets.c
@@ -28,6 +28,9 @@ int main(void)
 	DEFINE(GD_SIZE, sizeof(struct global_data));
 
 	DEFINE(GD_BD, offsetof(struct global_data, bd));
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+	DEFINE(GD_MALLOC_BASE, offsetof(struct global_data, malloc_base));
+#endif
 
 #if defined(CONFIG_ARM)
 
-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 5/9] arm: Support pre-relocation malloc()

[Simon Glass]

Add support for re-relocation malloc() in arm's start-up code.

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

Changes in v3:
- Rebase on earlier patch

Changes in v2: None

 README              | 3 +++
 arch/arm/lib/crt0.S | 5 ++++-
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/README b/README
index 11e9d31..73abbf0 100644
--- a/README
+++ b/README
@@ -3749,6 +3749,9 @@ Configuration Settings:
 		The memory will be freed (or in fact just forgotton) when
 		U-Boot relocates itself.
 
+		Pre-relocation malloc() is only supported on ARM at present
+		but is fairly easy to enable for other archs.
+
 - CONFIG_SYS_BOOTM_LEN:
 		Normally compressed uImages are limited to an
 		uncompressed size of 8 MBytes. If this is not enough,
diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
index 43aa212..29cdad0 100644
--- a/arch/arm/lib/crt0.S
+++ b/arch/arm/lib/crt0.S
@@ -78,7 +78,10 @@ clr_gd:
 	strlo	r0, [r1]		/* clear 32-bit GD word */
 	addlo	r1, r1, #4		/* move to next */
 	blo	clr_gd
-
+#if defined(CONFIG_SYS_MALLOC_F_LEN) && !defined(CONFIG_SPL_BUILD)
+	sub	sp, sp, #CONFIG_SYS_MALLOC_F_LEN
+	str	sp, [r9, #GD_MALLOC_BASE]
+#endif
 	/* mov r0, #0 not needed due to above code */
 	bl	board_init_f
 
-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 6/9] exynos: Enable pre-relocation malloc()

[Simon Glass]

Enable this feature to support driver model before relocation.

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

Changes in v3: None
Changes in v2: None

 include/configs/exynos5-dt.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/configs/exynos5-dt.h b/include/configs/exynos5-dt.h
index 3c2036e..fb03500 100644
--- a/include/configs/exynos5-dt.h
+++ b/include/configs/exynos5-dt.h
@@ -63,7 +63,8 @@
 #define INFORM2_OFFSET			0x808
 #define INFORM3_OFFSET			0x80c
 
-/* Size of malloc() pool */
+/* Size of malloc() pool before and after relocation */
+#define CONFIG_SYS_MALLOC_F_LEN	(1 << 10)
 #define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (4 << 20))
 
 /* select serial console configuration */
@@ -156,7 +157,6 @@
 #define CONFIG_SYS_MEMTEST_START	CONFIG_SYS_SDRAM_BASE
 #define CONFIG_SYS_MEMTEST_END		(CONFIG_SYS_SDRAM_BASE + 0x5E00000)
 #define CONFIG_SYS_LOAD_ADDR		(CONFIG_SYS_SDRAM_BASE + 0x3E00000)
-
 #define CONFIG_RD_LVL
 
 #define PHYS_SDRAM_1		CONFIG_SYS_SDRAM_BASE
-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 7/9] sandbox: Support pre-relocation malloc()

[Simon Glass]

Set up and zero global data before board_init_f() is called so that we can
remove the need for CONFIG_SYS_GENERIC_GLOBAL_DATA.

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

Changes in v3: None
Changes in v2: None

 README                   | 4 ++--
 arch/sandbox/cpu/start.c | 3 +++
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/README b/README
index 73abbf0..70beeeb 100644
--- a/README
+++ b/README
@@ -3749,8 +3749,8 @@ Configuration Settings:
 		The memory will be freed (or in fact just forgotton) when
 		U-Boot relocates itself.
 
-		Pre-relocation malloc() is only supported on ARM at present
-		but is fairly easy to enable for other archs.
+		Pre-relocation malloc() is only supported on ARM and sandbox
+		at present but is fairly easy to enable for other archs.
 
 - CONFIG_SYS_BOOTM_LEN:
 		Normally compressed uImages are limited to an
diff --git a/arch/sandbox/cpu/start.c b/arch/sandbox/cpu/start.c
index 5289291..b3d7051 100644
--- a/arch/sandbox/cpu/start.c
+++ b/arch/sandbox/cpu/start.c
@@ -240,6 +240,9 @@ int main(int argc, char *argv[])
 
 	memset(&data, '\0', sizeof(data));
 	gd = &data;
+#ifdef CONFIG_SYS_MALLOC_F_LEN
+	gd->malloc_base = CONFIG_MALLOC_F_ADDR;
+#endif
 
 	/* Do pre- and post-relocation init */
 	board_init_f(0);
-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 8/9] sandbox: config: Enable pre-relocation malloc()

[Simon Glass]

Enable this for sandbox so that we will be able to use driver model before
relocation.

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

Changes in v3:
- Put the two CONFIG changes together in sandbox.h

Changes in v2: None

 include/configs/sandbox.h | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/include/configs/sandbox.h b/include/configs/sandbox.h
index 12b69d9..bf2d25c 100644
--- a/include/configs/sandbox.h
+++ b/include/configs/sandbox.h
@@ -68,8 +68,10 @@
 #define CONFIG_EFI_PARTITION
 
 /*
- * Size of malloc() pool, although we don't actually use this yet.
+ * Size of malloc() pool, before and after relocation
  */
+#define CONFIG_SYS_MALLOC_F_LEN	(1 << 10)
+#define CONFIG_MALLOC_F_ADDR		0x0010000
 #define CONFIG_SYS_MALLOC_LEN		(32 << 20)	/* 32MB  */
 
 #define CONFIG_SYS_HUSH_PARSER
-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 9/9] sandbox: Always enable malloc debug

[Simon Glass]

Tun on DEBUG in malloc(). This adds code space and slows things down but
for sandbox this is acceptable. We gain the ability to check for memory
leaks in tests.

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

Changes in v3: None
Changes in v2: None

 common/dlmalloc.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/common/dlmalloc.c b/common/dlmalloc.c
index 26ba8fd..f987339 100644
--- a/common/dlmalloc.c
+++ b/common/dlmalloc.c
@@ -1,5 +1,9 @@
 #include <common.h>
 
+#ifdef CONFIG_SANDBOX
+#define DEBUG
+#endif
+
 #if 0	/* Moved to malloc.h */
 /* ---------- To make a malloc.h, start cutting here ------------ */
 
-- 
2.0.0.526.g5318336

[U-Boot] [PATCH v3 2/9] arm: Set up global data before board_init_f()

[Jeroen Hofstee]

Hello Simon,

On 11-07-14 06:23, Simon Glass wrote:
> At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that
> the global_data pointer is set up in board_init_f(). However it is
> actually set up before this, it just isn't zeroed.
>
> If we zero the global data before calling board_init_f() then we
> don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.
>
> Make this change (on arm32 only) to simplify the init process. I
> don't have the ability to test aarch64 yet.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v3:
> - Fix assembler code comment in crt0.S to say GD, not BSS
> - Ensure that aarch64 stays as it was
> - Add newline after clr_gd label
> - Remove redundant mov r0, #0
>
> Changes in v2: None
>
>   arch/arm/include/asm/config.h | 2 ++
>   arch/arm/lib/crt0.S           | 9 +++++++++
>   2 files changed, 11 insertions(+)
Looks good to me. I picked up this one instead
of my memset version.

Thanks, Jeroen

[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation

[Tom Rini]

On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:

> There has been talk on and off of a pre-relocation malloc() implementation.
> Driver model needs this so that it can work before relocation.
> 
> A previous implementation was sent in a v1 series.
> 
> This implementation works by allocating space on the stack. The benefit is
> that boards do not need to specify the address of the malloc() area, only
> the size. The down-side is that due to the way board_init_f() is called,
> architecture-specific code needs to be used to allocate the space.
> 
> No clever algorithms are used to allocate space, free() is a nop and
> realloc() is not supported. This fits well with the desire to avoid wasting
> space on bucket tables and the hassle of supporting BSS data before
> relocation. We don't expect 'churn' in the pre-relocation case - we just
> want to allocate small amounts of memory temporarily.
> 
> After relocation a new malloc() pool is created and the old one is lost,
> although pointers into it will survive the immediate process of relocation.
> 
> Implementations are provided for sandbox and arm (32-bit only).
> 
> A related change is made to the early init for each arch to make this work.

My concern without a fix right now is how to make use of this in SPL,
when we're able to move SPL over to using still more generic code rather
than re-inventing the board_init_{f,r} wheels, in the case where we init
DRAM.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140714/b900d0ee/attachment.pgp>

[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation

[Simon Glass]

Hi Tom,

On 14 July 2014 16:28, Tom Rini <trini@ti.com> wrote:
>
> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
>
> > There has been talk on and off of a pre-relocation malloc() implementation.
> > Driver model needs this so that it can work before relocation.
> >
> > A previous implementation was sent in a v1 series.
> >
> > This implementation works by allocating space on the stack. The benefit is
> > that boards do not need to specify the address of the malloc() area, only
> > the size. The down-side is that due to the way board_init_f() is called,
> > architecture-specific code needs to be used to allocate the space.
> >
> > No clever algorithms are used to allocate space, free() is a nop and
> > realloc() is not supported. This fits well with the desire to avoid wasting
> > space on bucket tables and the hassle of supporting BSS data before
> > relocation. We don't expect 'churn' in the pre-relocation case - we just
> > want to allocate small amounts of memory temporarily.
> >
> > After relocation a new malloc() pool is created and the old one is lost,
> > although pointers into it will survive the immediate process of relocation.
> >
> > Implementations are provided for sandbox and arm (32-bit only).
> >
> > A related change is made to the early init for each arch to make this work.
>
> My concern without a fix right now is how to make use of this in SPL,
> when we're able to move SPL over to using still more generic code rather
> than re-inventing the board_init_{f,r} wheels, in the case where we init
> DRAM.

One option would be to split this new code out into a separate file,
and have two malloc() implementations:

- big one - falls back to small one pre-relocation
- small one - used for SPL

Regards,
Simon

[U-Boot] [PATCH v3 2/9] arm: Set up global data before board_init_f()

[Simon Glass]

+Albert, Tom

Hi Albert,

On 11 July 2014 11:44, Jeroen Hofstee <dasuboot@myspectrum.nl> wrote:
> Hello Simon,
>
>
> On 11-07-14 06:23, Simon Glass wrote:
>>
>> At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that
>> the global_data pointer is set up in board_init_f(). However it is
>> actually set up before this, it just isn't zeroed.
>>
>> If we zero the global data before calling board_init_f() then we
>> don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.
>>
>> Make this change (on arm32 only) to simplify the init process. I
>> don't have the ability to test aarch64 yet.
>>
>> Signed-off-by: Simon Glass <sjg@chromium.org>
>> ---
>>
>> Changes in v3:
>> - Fix assembler code comment in crt0.S to say GD, not BSS
>> - Ensure that aarch64 stays as it was
>> - Add newline after clr_gd label
>> - Remove redundant mov r0, #0

Are you happy with this patch? I would like to apply to to the dm
repo, but would quite like to get an ack first.

>>
>> Changes in v2: None
>>
>>   arch/arm/include/asm/config.h | 2 ++
>>   arch/arm/lib/crt0.S           | 9 +++++++++
>>   2 files changed, 11 insertions(+)
>
> Looks good to me. I picked up this one instead
> of my memset version.

>
> Thanks, Jeroen

Regards,
Simon

[U-Boot] [PATCH v3 5/9] arm: Support pre-relocation malloc()

[Simon Glass]

+Tom

Hi Albert,

On 10 July 2014 22:23, Simon Glass <sjg@chromium.org> wrote:
> Add support for re-relocation malloc() in arm's start-up code.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>
> ---
>
> Changes in v3:
> - Rebase on earlier patch

Can you please take a look at this patch? I would like to apply it to
the dm repo.

>
> Changes in v2: None
>
>  README              | 3 +++
>  arch/arm/lib/crt0.S | 5 ++++-
>  2 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/README b/README
> index 11e9d31..73abbf0 100644
> --- a/README
> +++ b/README
> @@ -3749,6 +3749,9 @@ Configuration Settings:
>                 The memory will be freed (or in fact just forgotton) when
>                 U-Boot relocates itself.
>
> +               Pre-relocation malloc() is only supported on ARM at present
> +               but is fairly easy to enable for other archs.
> +
>  - CONFIG_SYS_BOOTM_LEN:
>                 Normally compressed uImages are limited to an
>                 uncompressed size of 8 MBytes. If this is not enough,
> diff --git a/arch/arm/lib/crt0.S b/arch/arm/lib/crt0.S
> index 43aa212..29cdad0 100644
> --- a/arch/arm/lib/crt0.S
> +++ b/arch/arm/lib/crt0.S
> @@ -78,7 +78,10 @@ clr_gd:
>         strlo   r0, [r1]                /* clear 32-bit GD word */
>         addlo   r1, r1, #4              /* move to next */
>         blo     clr_gd
> -
> +#if defined(CONFIG_SYS_MALLOC_F_LEN) && !defined(CONFIG_SPL_BUILD)
> +       sub     sp, sp, #CONFIG_SYS_MALLOC_F_LEN
> +       str     sp, [r9, #GD_MALLOC_BASE]
> +#endif
>         /* mov r0, #0 not needed due to above code */
>         bl      board_init_f
>
> --
> 2.0.0.526.g5318336
>

Regards,
Simon

[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation

[Simon Glass]

Hi,

On 14 July 2014 18:16, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
> On 14 July 2014 16:28, Tom Rini <trini@ti.com> wrote:
>>
>> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
>>
>> > There has been talk on and off of a pre-relocation malloc() implementation.
>> > Driver model needs this so that it can work before relocation.
>> >
>> > A previous implementation was sent in a v1 series.
>> >
>> > This implementation works by allocating space on the stack. The benefit is
>> > that boards do not need to specify the address of the malloc() area, only
>> > the size. The down-side is that due to the way board_init_f() is called,
>> > architecture-specific code needs to be used to allocate the space.
>> >
>> > No clever algorithms are used to allocate space, free() is a nop and
>> > realloc() is not supported. This fits well with the desire to avoid wasting
>> > space on bucket tables and the hassle of supporting BSS data before
>> > relocation. We don't expect 'churn' in the pre-relocation case - we just
>> > want to allocate small amounts of memory temporarily.
>> >
>> > After relocation a new malloc() pool is created and the old one is lost,
>> > although pointers into it will survive the immediate process of relocation.
>> >
>> > Implementations are provided for sandbox and arm (32-bit only).
>> >
>> > A related change is made to the early init for each arch to make this work.
>>
>> My concern without a fix right now is how to make use of this in SPL,
>> when we're able to move SPL over to using still more generic code rather
>> than re-inventing the board_init_{f,r} wheels, in the case where we init
>> DRAM.
>
> One option would be to split this new code out into a separate file,
> and have two malloc() implementations:
>
> - big one - falls back to small one pre-relocation
> - small one - used for SPL

I'm thinking of applying this to the dm repo now, except for the arm
patches where I would like to get Albert's ack (so I'll wait a few
more days).

Any objections?

Regards,
Simon

[U-Boot] [PATCH v3 2/9] arm: Set up global data before board_init_f()

[Tom Rini]

On Wed, Jul 23, 2014 at 06:16:52AM -0600, Simon Glass wrote:
> +Albert, Tom
> 
> Hi Albert,
> 
> On 11 July 2014 11:44, Jeroen Hofstee <dasuboot@myspectrum.nl> wrote:
> > Hello Simon,
> >
> >
> > On 11-07-14 06:23, Simon Glass wrote:
> >>
> >> At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that
> >> the global_data pointer is set up in board_init_f(). However it is
> >> actually set up before this, it just isn't zeroed.
> >>
> >> If we zero the global data before calling board_init_f() then we
> >> don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.
> >>
> >> Make this change (on arm32 only) to simplify the init process. I
> >> don't have the ability to test aarch64 yet.
> >>
> >> Signed-off-by: Simon Glass <sjg@chromium.org>
> >> ---
> >>
> >> Changes in v3:
> >> - Fix assembler code comment in crt0.S to say GD, not BSS
> >> - Ensure that aarch64 stays as it was
> >> - Add newline after clr_gd label
> >> - Remove redundant mov r0, #0
> 
> Are you happy with this patch? I would like to apply to to the dm
> repo, but would quite like to get an ack first.

Acked-by: Tom Rini <trini@ti.com>

But still want Albert to chime in too.  He should be back now :)

> 
> >>
> >> Changes in v2: None
> >>
> >>   arch/arm/include/asm/config.h | 2 ++
> >>   arch/arm/lib/crt0.S           | 9 +++++++++
> >>   2 files changed, 11 insertions(+)
> >
> > Looks good to me. I picked up this one instead
> > of my memset version.
> 
> >
> > Thanks, Jeroen
> 
> Regards,
> Simon
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140723/4a4cf86c/attachment.pgp>

[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation

[Tom Rini]

On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote:
> Hi,
> 
> On 14 July 2014 18:16, Simon Glass <sjg@chromium.org> wrote:
> > Hi Tom,
> >
> > On 14 July 2014 16:28, Tom Rini <trini@ti.com> wrote:
> >>
> >> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
> >>
> >> > There has been talk on and off of a pre-relocation malloc() implementation.
> >> > Driver model needs this so that it can work before relocation.
> >> >
> >> > A previous implementation was sent in a v1 series.
> >> >
> >> > This implementation works by allocating space on the stack. The benefit is
> >> > that boards do not need to specify the address of the malloc() area, only
> >> > the size. The down-side is that due to the way board_init_f() is called,
> >> > architecture-specific code needs to be used to allocate the space.
> >> >
> >> > No clever algorithms are used to allocate space, free() is a nop and
> >> > realloc() is not supported. This fits well with the desire to avoid wasting
> >> > space on bucket tables and the hassle of supporting BSS data before
> >> > relocation. We don't expect 'churn' in the pre-relocation case - we just
> >> > want to allocate small amounts of memory temporarily.
> >> >
> >> > After relocation a new malloc() pool is created and the old one is lost,
> >> > although pointers into it will survive the immediate process of relocation.
> >> >
> >> > Implementations are provided for sandbox and arm (32-bit only).
> >> >
> >> > A related change is made to the early init for each arch to make this work.
> >>
> >> My concern without a fix right now is how to make use of this in SPL,
> >> when we're able to move SPL over to using still more generic code rather
> >> than re-inventing the board_init_{f,r} wheels, in the case where we init
> >> DRAM.
> >
> > One option would be to split this new code out into a separate file,
> > and have two malloc() implementations:
> >
> > - big one - falls back to small one pre-relocation
> > - small one - used for SPL
> 
> I'm thinking of applying this to the dm repo now, except for the arm
> patches where I would like to get Albert's ack (so I'll wait a few
> more days).
> 
> Any objections?

I think we'll be OK.  I checked over the callpath again on OMAP parts
and we setup DDR prior to _main (in SPL) so we'll be fine.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140723/15273a2e/attachment.pgp>

[U-Boot] [PATCH v3 1/9] Remove form-feeds from dlmalloc.c

[Simon Glass]

On 11 July 2014 05:23, Simon Glass <sjg@chromium.org> wrote:
> These don't really serve any purpose in the modern age. On the other hand
> they show up as annoying control characters in my editor, which then happily
> removes them.
>
> I believe we can drop these characters from the file.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to dm/master.

[U-Boot] [PATCH v3 3/9] sandbox: Set up global data before board_init_f()

[Simon Glass]

On 11 July 2014 05:23, Simon Glass <sjg@chromium.org> wrote:
> At present sandbox defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that
> the global_data pointer is set up in board_init_f().
>
> If we set up and zero the global data before calling board_init_f() then we
> don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.
>
> Make this change to simplify the init process.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to dm/master.

[U-Boot] [PATCH v3 4/9] Add a simple malloc() implementation for pre-relocation

[Simon Glass]

On 11 July 2014 05:23, Simon Glass <sjg@chromium.org> wrote:
> If we are to have driver model before relocation we need to support some
> way of calling memory allocation routines.
>
> The standard malloc() is pretty complicated:
>
> 1. It uses some BSS memory for its state, and BSS is not available before
> relocation
>
> 2. It supports algorithms for reducing memory fragmentation and improving
> performace of free(). Before relocation we could happily just not support
> free().
>
> 3. It includes about 4KB of code (Thumb 2) and 1KB of data. However since
> this has been loaded anyway this is not really a problem.
>
> The simplest way to support pre-relocation malloc() is to reserve an area
> of memory and allocate it in increasing blocks as needed. This
> implementation does this.
>
> To enable it, you need to define the size of the malloc() pool as described
> in the README. It will be located above the pre-relocation stack on
> supported architectures.
>
> Note that this implementation is only useful on machines which have some
> memory available before dram_init() is called - this includes those that
> do no DRAM init (like tegra) and those that do it in SPL (quite a few
> boards). Enabling driver model preior to relocation for the rest of the
> boards is left for a later exercise.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to dm/master.

[U-Boot] [PATCH v3 7/9] sandbox: Support pre-relocation malloc()

[Simon Glass]

On 11 July 2014 05:23, Simon Glass <sjg@chromium.org> wrote:
> Set up and zero global data before board_init_f() is called so that we can
> remove the need for CONFIG_SYS_GENERIC_GLOBAL_DATA.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to dm/master.

[U-Boot] [PATCH v3 8/9] sandbox: config: Enable pre-relocation malloc()

[Simon Glass]

On 11 July 2014 05:23, Simon Glass <sjg@chromium.org> wrote:
> Enable this for sandbox so that we will be able to use driver model before
> relocation.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to dm/master.

[U-Boot] [PATCH v3 9/9] sandbox: Always enable malloc debug

[Simon Glass]

On 11 July 2014 05:23, Simon Glass <sjg@chromium.org> wrote:
> Tun on DEBUG in malloc(). This adds code space and slows things down but
> for sandbox this is acceptable. We gain the ability to check for memory
> leaks in tests.
>
> Signed-off-by: Simon Glass <sjg@chromium.org>

Applied to dm/master.

[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation

[Simon Glass]

Hi Tom,


On 23 July 2014 14:41, Tom Rini <trini@ti.com> wrote:
> On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote:
>> Hi,
>>
>> On 14 July 2014 18:16, Simon Glass <sjg@chromium.org> wrote:
>> > Hi Tom,
>> >
>> > On 14 July 2014 16:28, Tom Rini <trini@ti.com> wrote:
>> >>
>> >> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
>> >>
>> >> > There has been talk on and off of a pre-relocation malloc() implementation.
>> >> > Driver model needs this so that it can work before relocation.
>> >> >
>> >> > A previous implementation was sent in a v1 series.
>> >> >
>> >> > This implementation works by allocating space on the stack. The benefit is
>> >> > that boards do not need to specify the address of the malloc() area, only
>> >> > the size. The down-side is that due to the way board_init_f() is called,
>> >> > architecture-specific code needs to be used to allocate the space.
>> >> >
>> >> > No clever algorithms are used to allocate space, free() is a nop and
>> >> > realloc() is not supported. This fits well with the desire to avoid wasting
>> >> > space on bucket tables and the hassle of supporting BSS data before
>> >> > relocation. We don't expect 'churn' in the pre-relocation case - we just
>> >> > want to allocate small amounts of memory temporarily.
>> >> >
>> >> > After relocation a new malloc() pool is created and the old one is lost,
>> >> > although pointers into it will survive the immediate process of relocation.
>> >> >
>> >> > Implementations are provided for sandbox and arm (32-bit only).
>> >> >
>> >> > A related change is made to the early init for each arch to make this work.
>> >>
>> >> My concern without a fix right now is how to make use of this in SPL,
>> >> when we're able to move SPL over to using still more generic code rather
>> >> than re-inventing the board_init_{f,r} wheels, in the case where we init
>> >> DRAM.
>> >
>> > One option would be to split this new code out into a separate file,
>> > and have two malloc() implementations:
>> >
>> > - big one - falls back to small one pre-relocation
>> > - small one - used for SPL
>>
>> I'm thinking of applying this to the dm repo now, except for the arm
>> patches where I would like to get Albert's ack (so I'll wait a few
>> more days).
>>
>> Any objections?
>
> I think we'll be OK.  I checked over the callpath again on OMAP parts
> and we setup DDR prior to _main (in SPL) so we'll be fine.

OK, I'll prepare a pull request for the ARM-related malloc() patches
soon, along with the GPIO things (sandbox only at this stage as we
need to make progress on applying exynos patches first).

Regards,
Simon

[U-Boot] [PATCH v3 2/9] arm: Set up global data before board_init_f()

[Simon Glass]

Hi Albert,

On 23 July 2014 14:31, Tom Rini <trini@ti.com> wrote:
> On Wed, Jul 23, 2014 at 06:16:52AM -0600, Simon Glass wrote:
>> +Albert, Tom
>>
>> Hi Albert,
>>
>> On 11 July 2014 11:44, Jeroen Hofstee <dasuboot@myspectrum.nl> wrote:
>> > Hello Simon,
>> >
>> >
>> > On 11-07-14 06:23, Simon Glass wrote:
>> >>
>> >> At present arm defines CONFIG_SYS_GENERIC_GLOBAL_DATA, meaning that
>> >> the global_data pointer is set up in board_init_f(). However it is
>> >> actually set up before this, it just isn't zeroed.
>> >>
>> >> If we zero the global data before calling board_init_f() then we
>> >> don't need to define CONFIG_SYS_GENERIC_GLOBAL_DATA.
>> >>
>> >> Make this change (on arm32 only) to simplify the init process. I
>> >> don't have the ability to test aarch64 yet.
>> >>
>> >> Signed-off-by: Simon Glass <sjg@chromium.org>
>> >> ---
>> >>
>> >> Changes in v3:
>> >> - Fix assembler code comment in crt0.S to say GD, not BSS
>> >> - Ensure that aarch64 stays as it was
>> >> - Add newline after clr_gd label
>> >> - Remove redundant mov r0, #0
>>
>> Are you happy with this patch? I would like to apply to to the dm
>> repo, but would quite like to get an ack first.
>
> Acked-by: Tom Rini <trini@ti.com>
>
> But still want Albert to chime in too.  He should be back now :)
>

Any objections to me pulling this through the -dm repo?

Regards,
Simon

[U-Boot] [PATCH v3 0/9] Add a pre-relocation malloc() implementation

[Simon Glass]

Hi,

On 28 July 2014 06:16, Simon Glass <sjg@chromium.org> wrote:
> Hi Tom,
>
>
> On 23 July 2014 14:41, Tom Rini <trini@ti.com> wrote:
>> On Wed, Jul 23, 2014 at 06:24:08AM -0600, Simon Glass wrote:
>>> Hi,
>>>
>>> On 14 July 2014 18:16, Simon Glass <sjg@chromium.org> wrote:
>>> > Hi Tom,
>>> >
>>> > On 14 July 2014 16:28, Tom Rini <trini@ti.com> wrote:
>>> >>
>>> >> On Thu, Jul 10, 2014 at 10:23:24PM -0600, Simon Glass wrote:
>>> >>
>>> >> > There has been talk on and off of a pre-relocation malloc() implementation.
>>> >> > Driver model needs this so that it can work before relocation.
>>> >> >
>>> >> > A previous implementation was sent in a v1 series.
>>> >> >
>>> >> > This implementation works by allocating space on the stack. The benefit is
>>> >> > that boards do not need to specify the address of the malloc() area, only
>>> >> > the size. The down-side is that due to the way board_init_f() is called,
>>> >> > architecture-specific code needs to be used to allocate the space.
>>> >> >
>>> >> > No clever algorithms are used to allocate space, free() is a nop and
>>> >> > realloc() is not supported. This fits well with the desire to avoid wasting
>>> >> > space on bucket tables and the hassle of supporting BSS data before
>>> >> > relocation. We don't expect 'churn' in the pre-relocation case - we just
>>> >> > want to allocate small amounts of memory temporarily.
>>> >> >
>>> >> > After relocation a new malloc() pool is created and the old one is lost,
>>> >> > although pointers into it will survive the immediate process of relocation.
>>> >> >
>>> >> > Implementations are provided for sandbox and arm (32-bit only).
>>> >> >
>>> >> > A related change is made to the early init for each arch to make this work.
>>> >>
>>> >> My concern without a fix right now is how to make use of this in SPL,
>>> >> when we're able to move SPL over to using still more generic code rather
>>> >> than re-inventing the board_init_{f,r} wheels, in the case where we init
>>> >> DRAM.
>>> >
>>> > One option would be to split this new code out into a separate file,
>>> > and have two malloc() implementations:
>>> >
>>> > - big one - falls back to small one pre-relocation
>>> > - small one - used for SPL
>>>
>>> I'm thinking of applying this to the dm repo now, except for the arm
>>> patches where I would like to get Albert's ack (so I'll wait a few
>>> more days).
>>>
>>> Any objections?
>>
>> I think we'll be OK.  I checked over the callpath again on OMAP parts
>> and we setup DDR prior to _main (in SPL) so we'll be fine.
>
> OK, I'll prepare a pull request for the ARM-related malloc() patches
> soon, along with the GPIO things (sandbox only at this stage as we
> need to make progress on applying exynos patches first).

I haven't heard from Albert or Minkyu so will go ahead with this plan.

Regards,
Simon

[U-Boot] [PATCH v3 5/9] arm: Support pre-relocation malloc()

[Simon Glass]

Applied to u-boot-dm/master.

[U-Boot] [PATCH v3 2/9] arm: Set up global data before board_init_f()

[Simon Glass]

Applied to u-boot-dm/master.