arm: a few steps to reduce the boot time

This commit enables the following configs:
- CONFIG_USE_ARCH_MEMCPY
- CONFIG_USE_ARCH_MEMSET
This increases the performance of memcpy/memset
and also reduces the boot time.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1527ms - before this change (arch memset enabled for .bss clear)
- ~1384ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Minkyu Kang <[email protected]>

Cc Akshay Saraswat <[email protected]>

Cc Simon Glass <[email protected]>

Cc Sjoerd Simons <[email protected]>

---
 include/configs/exynos-common.h | 3 +++
 1 file changed, 3 insertions(+)

Quoted 11 lines · Przemyslaw Marczak

This commit enables the following configs:
- CONFIG_USE_ARCH_MEMCPY
- CONFIG_USE_ARCH_MEMSET
This increases the performance of memcpy/memset
and also reduces the boot time.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1527ms - before this change (arch memset enabled for .bss clear)
- ~1384ms - after this change

Quoted 8 lines

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Minkyu Kang <[email protected]>

Cc Akshay Saraswat <[email protected]>

Cc Simon Glass <[email protected]>

Cc Sjoerd Simons <[email protected]>

---
  include/configs/exynos-common.h | 3 +++
  1 file changed, 3 insertions(+)

Reviewed-by Simon Glass <[email protected]>

BTW in case you are interested, in the Chromium U-Boot tree (chromeos-v2013.06 branch) we have exynos support for turning on the cache in SPL and leaving it on through to the end of U-Boot. It runs two SPLs and two U-Boots (with verified boot and kernel verification) in a total of about 750ms. This shipped last year with Pit and Pi (Samsung Chromebook 2).

Might be some interesting patches there...

Regards,
Simon

For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY, will highly increase the memset/memcpy performance. This is able thanks to the ARM multiple register instructions.

Unfortunatelly the relocation is done without the cache enabled, so it takes some time, but zeroing the BSS memory takes much more longer, especially for the configs with big static buffers.

A quick test confirms, that the boot time improvement after using the arch memcpy for relocation has no significant meaning. The same test confirms that enable the memset for zeroing BSS, reduces the boot time.

So this patch enables the arch memset for zeroing the BSS after the relocation process. For ARM boards, this can be enabled in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1384ms - before this change
- ~888ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Tom Rini <[email protected]>

---
  arch/arm/lib/crt0.S | 10 +++++++++-
  1 file changed, 9 insertions(+), 1 deletion(-)

arch/arm/lib/crt0.S +8 -1

index 22df3e5..fab3d2c 100644
@@ -115,14 +115,22 @@ here:
  	bl	c_runtime_cpu_setup	/* we still call old routine here */
 
  	ldr	r0, =__bss_start	/* this is auto-relocated! */
-	ldr	r1, =__bss_end		/* this is auto-relocated! */
 
+#ifdef CONFIG_USE_ARCH_MEMSET
+	ldr	r3, =__bss_end		/* this is auto-relocated! */
+	mov	r1, #0x00000000		/* prepare zero to clear BSS */
+
+	subs	r2, r3, r0		/* r2 = memset len */
+	bl	memset
+#else
+	ldr	r1, =__bss_end		/* this is auto-relocated! */

Hello,

Quoted 57 lines · Przemyslaw Marczak

For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY, will highly increase the memset/memcpy performance. This is able thanks to the ARM multiple register instructions.

Unfortunatelly the relocation is done without the cache enabled, so it takes some time, but zeroing the BSS memory takes much more longer, especially for the configs with big static buffers.

A quick test confirms, that the boot time improvement after using the arch memcpy for relocation has no significant meaning. The same test confirms that enable the memset for zeroing BSS, reduces the boot time.

So this patch enables the arch memset for zeroing the BSS after the relocation process. For ARM boards, this can be enabled in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1384ms - before this change
- ~888ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Tom Rini <[email protected]>

---
  arch/arm/lib/crt0.S | 10 +++++++++-
  1 file changed, 9 insertions(+), 1 deletion(-)

arch/arm/lib/crt0.S +9 -1

index 22df3e5..fab3d2c 100644
@@ -115,14 +115,22 @@ here:
        bl      c_runtime_cpu_setup     /* we still call old routine here
 */
 
        ldr     r0, =__bss_start        /* this is auto-relocated! */
-       ldr     r1, =__bss_end          /* this is auto-relocated! */
 
+#ifdef CONFIG_USE_ARCH_MEMSET
+       ldr     r3, =__bss_end          /* this is auto-relocated! */
+       mov     r1, #0x00000000         /* prepare zero to clear BSS */
+
+       subs    r2, r3, r0              /* r2 = memset len */
+       bl      memset
+#else
+       ldr     r1, =__bss_end          /* this is auto-relocated! */
        mov     r2, #0x00000000         /* prepare zero to clear BSS */
 
  clbss_l:cmp   r0, r1                  /* while not at end of BSS */
        strlo   r2, [r0]                /* clear 32-bit BSS word */
        addlo   r0, r0, #4              /* move to next */
        blo     clbss_l
+#endif
 

Quoted 3 lines

arch/arm/lib/crt0.S +0 -0

        bl coloured_LED_init

bl red_led_on

This commit left unchanged. After boot time test using oscilloscope and the clock cycle counter I didn't noticed a time difference in more then one ms. In this case I think that insert a duplicated code here, has no sense.

Hi Przemyslaw,

Quoted 61 lines · Przemyslaw Marczak

Hello,

Quoted 57 lines · Przemyslaw Marczak

For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY, will highly increase the memset/memcpy performance. This is able thanks to the ARM multiple register instructions.

Unfortunatelly the relocation is done without the cache enabled, so it takes some time, but zeroing the BSS memory takes much more longer, especially for the configs with big static buffers.

A quick test confirms, that the boot time improvement after using the arch memcpy for relocation has no significant meaning. The same test confirms that enable the memset for zeroing BSS, reduces the boot time.

So this patch enables the arch memset for zeroing the BSS after the relocation process. For ARM boards, this can be enabled in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1384ms - before this change
- ~888ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Tom Rini <[email protected]>

---
   arch/arm/lib/crt0.S | 10 +++++++++-
   1 file changed, 9 insertions(+), 1 deletion(-)

arch/arm/lib/crt0.S +9 -1

index 22df3e5..fab3d2c 100644
@@ -115,14 +115,22 @@ here:
         bl      c_runtime_cpu_setup     /* we still call old routine here
 */
 
         ldr     r0, =__bss_start        /* this is auto-relocated! */
-       ldr     r1, =__bss_end          /* this is auto-relocated! */
 
+#ifdef CONFIG_USE_ARCH_MEMSET
+       ldr     r3, =__bss_end          /* this is auto-relocated! */
+       mov     r1, #0x00000000         /* prepare zero to clear BSS */
+
+       subs    r2, r3, r0              /* r2 = memset len */
+       bl      memset
+#else
+       ldr     r1, =__bss_end          /* this is auto-relocated! */
         mov     r2, #0x00000000         /* prepare zero to clear BSS */
 
   clbss_l:cmp   r0, r1                  /* while not at end of BSS */
         strlo   r2, [r0]                /* clear 32-bit BSS word */
         addlo   r0, r0, #4              /* move to next */
         blo     clbss_l
+#endif
 

Quoted 7 lines

Quoted 3 lines

arch/arm/lib/crt0.S +0 -0

         bl coloured_LED_init

bl red_led_on

This commit left unchanged. After boot time test using oscilloscope and the clock cycle counter I didn't noticed a time difference in more then one ms. In this case I think that insert a duplicated code here, has no sense.

I don't understand this comment, sorry.

Regards,
Simon

Hello,

Quoted 80 lines · Simon Glass

Hi Przemyslaw,

Quoted 64 lines · Przemyslaw Marczak

Hello,

Quoted 59 lines · Przemyslaw Marczak

For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY, will highly increase the memset/memcpy performance. This is able thanks to the ARM multiple register instructions.

Unfortunatelly the relocation is done without the cache enabled, so it takes some time, but zeroing the BSS memory takes much more longer, especially for the configs with big static buffers.

A quick test confirms, that the boot time improvement after using the arch memcpy for relocation has no significant meaning. The same test confirms that enable the memset for zeroing BSS, reduces the boot time.

So this patch enables the arch memset for zeroing the BSS after the relocation process. For ARM boards, this can be enabled in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1384ms - before this change
- ~888ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Tom Rini <[email protected]>

---
   arch/arm/lib/crt0.S | 10 +++++++++-
   1 file changed, 9 insertions(+), 1 deletion(-)

arch/arm/lib/crt0.S +0 -0

index 22df3e5..fab3d2c 100644
@@ -115,14 +115,22 @@ here:
         bl      c_runtime_cpu_setup     /* we still call old routine

here
*/

ldr r0, =__bss_start /* this is auto-relocated! */

arch/arm/lib/crt0.S +9 -1

-       ldr     r1, =__bss_end          /* this is auto-relocated! */
 
+#ifdef CONFIG_USE_ARCH_MEMSET
+       ldr     r3, =__bss_end          /* this is auto-relocated! */
+       mov     r1, #0x00000000         /* prepare zero to clear BSS */
+
+       subs    r2, r3, r0              /* r2 = memset len */
+       bl      memset
+#else
+       ldr     r1, =__bss_end          /* this is auto-relocated! */
         mov     r2, #0x00000000         /* prepare zero to clear BSS */
 
   clbss_l:cmp   r0, r1                  /* while not at end of BSS */
         strlo   r2, [r0]                /* clear 32-bit BSS word */
         addlo   r0, r0, #4              /* move to next */
         blo     clbss_l
+#endif

Quoted 9 lines

Quoted 3 lines

bl coloured_LED_init
bl red_led_on

This commit left unchanged. After boot time test using oscilloscope and the
clock cycle counter I didn't noticed a time difference in more then one ms.
In this case I think that insert a duplicated code here, has no sense.

Quoted 5 lines

I don't understand this comment, sorry.

Regards,
Simon

Sorry for the misleading message.
When I send this patch set, I forgot about adding the message-id of the previous thread as "in-reply-to".

There was a discussion about insert the memory zeroing routines as an asm here, instead of using the 'memset' call. But I tested that there is no difference in the performance. So in this case, it's better to use the common lib and this commit is the same as it was in the first version.

(I missed the changelog)

For writing files, DFU implementation requires the file buffer with the len at least of file size. For big files it requires the same big buffer.

Previously the file buffer was allocated as a static variable, so it was a part of U-Boot .bss section. For 32MiB len of buffer we have 32MiB of additional space, required for this section.

The .bss needs to be cleared after the relocation.
This introduces an additional boot delay at every start, but usually the dfu feature is not required at the standard boot, so the buffer should be allocated only if required.

This patch removes the static allocation of this buffer, and alloc it with memalign after first call of function:
- dfu_fill_entity_mmc()
and the buffer is freed on dfu_free_entity() call.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~888ms - before this change (arch memset enabled for .bss clear)
- ~464ms - after this change

This commit introduces new config: CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING.

Before this change, the all amount of memory reserved for the malloc, was set to zero in mem_malloc_init(). When the malloc reserved memory exceeds few MiB, then the boot process can slow down.

So enabling this config, is an option to reduce the boot time.

Note:
After enable this option, only calloc() will return the pointer to zeroed memory area. Previously, without this option, the memory pointed to untouched malloc memory region, was filled with zeros. So it means, that code with malloc() calls should be reexamined.

Signed-off-by Przemyslaw Marczak <[email protected]>

---
 common/dlmalloc.c | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

common/dlmalloc.c +7 -4

index 6453ee9..63f68ed 100644
@@ -1535,9 +1535,9 @@ void mem_malloc_init(ulong start, ulong size)
 
        debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
              mem_malloc_end);
-
-       memset((void *)mem_malloc_start, 0, size);
-
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
+       memset((void *)mem_malloc_start, 0x0, size);
+#endif
        malloc_bin_reloc();
 }
 

@@ -2948,10 +2948,12 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
 
   /* check if expand_top called, in which case don't need to clear */
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
 #if MORECORE_CLEARS
   mchunkptr oldtop = top;
   INTERNAL_SIZE_T oldtopsize = chunksize(top);
 #endif
+#endif
   Void_t* mem = mALLOc (sz);
 
   if ((long)n < 0) return NULL;

@@ -2977,6 +2979,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
     csz = chunksize(p);
 
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
 #if MORECORE_CLEARS
     if (p == oldtop && csz > oldtopsize)
     {

@@ -2984,6 +2987,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
       csz = oldtopsize;
     }
 #endif
+#endif
 
     MALLOC_ZERO(mem, csz - SIZE_SZ);
     return mem;
--

1.9.1

Signed-off-by Przemyslaw Marczak <[email protected]>

---
 README | 7 +++++++
 1 file changed, 7 insertions(+)

README +0 -0

index fefa71c..8673640 100644

Kconfig +19 -8

 menuconfig EXPERT
-        bool "Configure standard U-Boot features (expert users)"
-        help
-          This option allows certain base U-Boot options and settings
-          to be disabled or tweaked. This is for specialized
-          environments which can tolerate a "non-standard" U-Boot.
-          Only use this if you really know what you are doing.
-
+       bool "Configure standard U-Boot features (expert users)"
+       help
+         This option allows certain base U-Boot options and settings
+         to be disabled or tweaked. This is for specialized
+         environments which can tolerate a "non-standard" U-Boot.
+         Only use this if you really know what you are doing.
+
+if EXPERT
+       config SYS_MALLOC_INIT_SKIP_ZEROING
+       bool "Skip memset at malloc init (reduce boot time)"
+       help
+        This avoids zeroing memory reserved for malloc at malloc init.
+        Significant boot time reduction is visible for configs in which
+        CONFIG_SYS_MALLOC_LEN value, has more than few MiB.
+        Useful for bzip2, bmp logo.
+        Warning:
+        When enable, make sure that calloc() is used when zeroed
+        memory is needed.
+endif
 endmenu                # General setup
 
 menu "Boot images"
--

1.9.1

Hi Przemyslaw,

Quoted 5 lines · Przemyslaw Marczak

Signed-off-by Przemyslaw Marczak <[email protected]>

---
  Kconfig | 26 +++++++++++++++++++-------
  1 file changed, 19 insertions(+), 7 deletions(-)

Kconfig config CC_OPTIMIZE_FOR_SIZE · line 57

Quoted 6 lines

Kconfig +0 -0

index 4157da3..e08e44a 100644
@@ -57,13 +57,25 @@ config CC_OPTIMIZE_FOR_SIZE
           This option is enabled by default for U-Boot.

Ah, you have done this. Then I think you can merge this patch with the dlmalloc patch and drop the README one.

Quoted 30 lines

Kconfig +19 -7

  menuconfig EXPERT
-        bool "Configure standard U-Boot features (expert users)"
-        help
-          This option allows certain base U-Boot options and settings
-          to be disabled or tweaked. This is for specialized
-          environments which can tolerate a "non-standard" U-Boot.
-          Only use this if you really know what you are doing.
-
+       bool "Configure standard U-Boot features (expert users)"
+       help
+         This option allows certain base U-Boot options and settings
+         to be disabled or tweaked. This is for specialized
+         environments which can tolerate a "non-standard" U-Boot.
+         Only use this if you really know what you are doing.
+
+if EXPERT
+       config SYS_MALLOC_INIT_SKIP_ZEROING
+       bool "Skip memset at malloc init (reduce boot time)"
+       help
+        This avoids zeroing memory reserved for malloc at malloc init.
+        Significant boot time reduction is visible for configs in which
+        CONFIG_SYS_MALLOC_LEN value, has more than few MiB.
+        Useful for bzip2, bmp logo.
+        Warning:
+        When enable, make sure that calloc() is used when zeroed
+        memory is needed.
+endif
  endmenu                # General setup
 

Quoted 4 lines

Kconfig +0 -1

  menu "Boot images"
--

1.9.1

Regards,
Simon

Hi Simon,

Quoted 11 lines · Simon Glass

Hi Przemyslaw,

Quoted 6 lines · Przemyslaw Marczak

Signed-off-by Przemyslaw Marczak <[email protected]>

---
  Kconfig | 26 +++++++++++++++++++-------
  1 file changed, 19 insertions(+), 7 deletions(-)

Quoted 11 lines

Kconfig config CC_OPTIMIZE_FOR_SIZE · line 57

Quoted 6 lines

Kconfig +0 -0

index 4157da3..e08e44a 100644
@@ -57,13 +57,25 @@ config CC_OPTIMIZE_FOR_SIZE
           This option is enabled by default for U-Boot.

Ah, you have done this. Then I think you can merge this patch with the dlmalloc patch and drop the README one.

Shouldn't we keep both, README and Kconfig help?
Kconfig is just a configuration tool, README is a documentation. Sometimes it could be faster to find something in the text instead of config.

Quoted 32 lines

Quoted 32 lines

Kconfig +19 -7

  menuconfig EXPERT
-        bool "Configure standard U-Boot features (expert users)"
-        help
-          This option allows certain base U-Boot options and settings
-          to be disabled or tweaked. This is for specialized
-          environments which can tolerate a "non-standard" U-Boot.
-          Only use this if you really know what you are doing.
-
+       bool "Configure standard U-Boot features (expert users)"
+       help
+         This option allows certain base U-Boot options and settings
+         to be disabled or tweaked. This is for specialized
+         environments which can tolerate a "non-standard" U-Boot.
+         Only use this if you really know what you are doing.
+
+if EXPERT
+       config SYS_MALLOC_INIT_SKIP_ZEROING
+       bool "Skip memset at malloc init (reduce boot time)"
+       help
+        This avoids zeroing memory reserved for malloc at malloc init.
+        Significant boot time reduction is visible for configs in which
+        CONFIG_SYS_MALLOC_LEN value, has more than few MiB.
+        Useful for bzip2, bmp logo.
+        Warning:
+        When enable, make sure that calloc() is used when zeroed
+        memory is needed.
+endif
  endmenu                # General setup
 

Quoted 1 line

Kconfig config CC_OPTIMIZE_FOR_SIZE · line 81

Quoted 1 line

Kconfig +0 -0

  menu "Boot images"

+Masahiro

Hi,

Quoted 26 lines · Przemyslaw Marczak

Hi Simon,

Quoted 22 lines · Simon Glass

Hi Przemyslaw,

Kconfig config CC_OPTIMIZE_FOR_SIZE · line 57

Quoted 12 lines · Przemyslaw Marczak

Signed-off-by Przemyslaw Marczak <[email protected]>

---
  Kconfig | 26 +++++++++++++++++++-------
  1 file changed, 19 insertions(+), 7 deletions(-)

Kconfig +0 -0

index 4157da3..e08e44a 100644
@@ -57,13 +57,25 @@ config CC_OPTIMIZE_FOR_SIZE
           This option is enabled by default for U-Boot.

Ah, you have done this. Then I think you can merge this patch with the dlmalloc patch and drop the README one.

Quoted 4 lines

Shouldn't we keep both, README and Kconfig help?
Kconfig is just a configuration tool, README is a documentation. Sometimes it could be faster to find something in the text instead of config.

Agreed, but isn't it going to be a pain to add it in both places and keep it in sync? Maybe we could create a script which creates a README.kconfig containing all the options and help.

Quoted 31 lines · On Thu, 19 Feb 2015 11:59:07 -0700 Simon Glass <[email protected]> wrote:

+Masahiro

Hi,

Quoted 26 lines · Przemyslaw Marczak

Hi Simon,

Quoted 22 lines · Simon Glass

Hi Przemyslaw,

Kconfig config CC_OPTIMIZE_FOR_SIZE · line 57

Quoted 12 lines · Przemyslaw Marczak

Signed-off-by Przemyslaw Marczak <[email protected]>

---
   Kconfig | 26 +++++++++++++++++++-------
   1 file changed, 19 insertions(+), 7 deletions(-)

Kconfig +0 -0

index 4157da3..e08e44a 100644
@@ -57,13 +57,25 @@ config CC_OPTIMIZE_FOR_SIZE
            This option is enabled by default for U-Boot.

Ah, you have done this. Then I think you can merge this patch with the dlmalloc patch and drop the README one.

Quoted 9 lines

Quoted 4 lines

Shouldn't we keep both, README and Kconfig help?
Kconfig is just a configuration tool, README is a documentation. Sometimes it could be faster to find something in the text instead of config.

Agreed, but isn't it going to be a pain to add it in both places and keep it in sync? Maybe we could create a script which creates a README.kconfig containing all the options and help.

I agree with Simon.

README is useful when we need a wider and more general explanation about a feature, for ex. doc/driver-model/README.txt

Per-config explanation should be documented in Kconfig only.

Another reasone I prefer Kconfig help is:
When we remove a CONFIG from Kconfig, the documentation in a separete README might be left over.

BTW, I did not know that U-Boot filled all the malloc space with zero.

I guess our consensus is that malloc() returns uninitialized memory.

So, I am happy with this patch. (Perhaps, could it be enabled by default? )

Best Regards
Masahiro Yamada

Reduce the boot time of Trats2 by disabling the memset at malloc init.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~464ms - before this change (arch memset enabled for .bss clear)
- ~341ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

---
 configs/trats2_defconfig | 2 ++
 1 file changed, 2 insertions(+)

Reduce the boot time of Odroid X2/U3 by disabling the memset at malloc init.

This was tested on Odroid X2.
A quick test with checking gpio pin state using the oscilloscope. Boot time from start to bootcmd (change gpio state by memory write command):
- ~228ms - before this change (arch memset enabled for .bss clear)
- ~100ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Quoted 9 lines · Przemyslaw Marczak

Reduce the boot time of Odroid X2/U3 by disabling the memset at malloc init.

This was tested on Odroid X2.
A quick test with checking gpio pin state using the oscilloscope. Boot time from start to bootcmd (change gpio state by memory write command):
- ~228ms - before this change (arch memset enabled for .bss clear)
- ~100ms - after this change

Quoted 1 line

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

This patchset reduces the boot time for ARM architecture, Exynos boards, and boards with DFU enabled.

Quoted 2 lines · Przemyslaw Marczak

This patchset reduces the boot time for ARM architecture, Exynos boards, and boards with DFU enabled.

I tested this series on NVIDIA's Jetson TK1 board. It doesn't seem to introduce any new issues, but I did find a couple have crept in recently:

I'm running the following in U-Boot:

setenv dfu_alt_info "/dfu_test.bin ext4 0 1;/dfudummy.bin ext4 0 1" dfu 0 mmc 0

1)

Whenever any file is uploaded through DFU, I see:

#File System is consistent
file found deleting
update journal finished
File System is consistent
update journal finished
18425346722729591336 bytes written in 4070 ms (3.9 EiB/s)

Notice that the byte count is way off (that's from a 4KB file). The byte count is always the same invalid number. I'm not sure if this message comes from the ext4 or DFU code.

Quoted 23 lines · Stephen Warren

Quoted 2 lines · Przemyslaw Marczak

This patchset reduces the boot time for ARM architecture, Exynos boards, and boards with DFU enabled.

I tested this series on NVIDIA's Jetson TK1 board. It doesn't seem to introduce any new issues, but I did find a couple have crept in recently:

I'm running the following in U-Boot:

setenv dfu_alt_info "/dfu_test.bin ext4 0 1;/dfudummy.bin ext4 0 1" dfu 0 mmc 0

1)

Whenever any file is uploaded through DFU, I see:

#File System is consistent
file found deleting
update journal finished
File System is consistent
update journal finished
18425346722729591336 bytes written in 4070 ms (3.9 EiB/s)

Quoted 3 lines

Notice that the byte count is way off (that's from a 4KB file). The byte count is always the same invalid number. I'm not sure if this message comes from the ext4 or DFU code.

For the record in this thread, this is fixed by:
[PATCH] fs: ext4 write: return file len on success

This commit introduces new config: CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING.

Before this change, the all amount of memory reserved for the malloc, was set to zero in mem_malloc_init(). When the malloc reserved memory exceeds few MiB, then the boot process can slow down.

So enabling this config, is an option to reduce the boot time.

This option can be enabled by Kconfig.

Note:
After enable this option, only calloc() will return the pointer to zeroed memory area. Previously, without this option, the memory pointed to untouched malloc memory region, was filled with zeros. So it means, that code with malloc() calls should be reexamined.

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---
Changes v3:
- squash the commit with the Kconfig option

---
 Kconfig           | 26 +++++++++++++++++++-------
 common/dlmalloc.c | 10 +++++++---
 2 files changed, 26 insertions(+), 10 deletions(-)

Kconfig +19 -7

index 75bab7f..87d4daf 100644
@@ -76,13 +76,25 @@ config SYS_MALLOC_F_LEN
 	  initial serial device and any others that are needed.
 
 menuconfig EXPERT
-        bool "Configure standard U-Boot features (expert users)"
-        help
-          This option allows certain base U-Boot options and settings
-          to be disabled or tweaked. This is for specialized
-          environments which can tolerate a "non-standard" U-Boot.
-          Only use this if you really know what you are doing.
-
+	bool "Configure standard U-Boot features (expert users)"
+	help
+	  This option allows certain base U-Boot options and settings
+	  to be disabled or tweaked. This is for specialized
+	  environments which can tolerate a "non-standard" U-Boot.
+	  Only use this if you really know what you are doing.
+
+if EXPERT
+	config SYS_MALLOC_INIT_SKIP_ZEROING
+	bool "Skip memset at malloc init (reduce boot time)"
+	help
+	  This avoids zeroing memory reserved for malloc at malloc init.
+	  Significant boot time reduction is visible for configs in which
+	  CONFIG_SYS_MALLOC_LEN value, has more than few MiB.
+	  Useful for bzip2, bmp logo.
+	  Warning:
+	  When enabling this, please check if malloc calls, maybe
+	  should be replaced by calloc - if expects zeroed memory.
+endif
 endmenu		# General setup
 
 menu "Boot images"

common/dlmalloc.c +6 -3

index 6453ee9..63f68ed 100644
@@ -1535,9 +1535,9 @@ void mem_malloc_init(ulong start, ulong size)
 
 	debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
 	      mem_malloc_end);
-
-	memset((void *)mem_malloc_start, 0, size);
-
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
+	memset((void *)mem_malloc_start, 0x0, size);
+#endif
 	malloc_bin_reloc();
 }
 

@@ -2948,10 +2948,12 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
 
   /* check if expand_top called, in which case don't need to clear */
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
 #if MORECORE_CLEARS
   mchunkptr oldtop = top;
   INTERNAL_SIZE_T oldtopsize = chunksize(top);
 #endif
+#endif
   Void_t* mem = mALLOc (sz);
 
   if ((long)n < 0) return NULL;

@@ -2977,6 +2979,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
     csz = chunksize(p);
 
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
 #if MORECORE_CLEARS
     if (p == oldtop && csz > oldtopsize)
     {

Hi Przemyslaw,

Quoted 103 lines · On Fri, 20 Feb 2015 12:06:17 +0100 Przemyslaw Marczak <[email protected]>…

This commit introduces new config: CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING.

Before this change, the all amount of memory reserved for the malloc, was set to zero in mem_malloc_init(). When the malloc reserved memory exceeds few MiB, then the boot process can slow down.

So enabling this config, is an option to reduce the boot time.

This option can be enabled by Kconfig.

Note:
After enable this option, only calloc() will return the pointer to zeroed memory area. Previously, without this option, the memory pointed to untouched malloc memory region, was filled with zeros. So it means, that code with malloc() calls should be reexamined.

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---
Changes v3:
- squash the commit with the Kconfig option

---
  Kconfig           | 26 +++++++++++++++++++-------
  common/dlmalloc.c | 10 +++++++---
  2 files changed, 26 insertions(+), 10 deletions(-)

Kconfig +19 -7

index 75bab7f..87d4daf 100644
@@ -76,13 +76,25 @@ config SYS_MALLOC_F_LEN
  	  initial serial device and any others that are needed.
 
  menuconfig EXPERT
-        bool "Configure standard U-Boot features (expert users)"
-        help
-          This option allows certain base U-Boot options and settings
-          to be disabled or tweaked. This is for specialized
-          environments which can tolerate a "non-standard" U-Boot.
-          Only use this if you really know what you are doing.
-
+	bool "Configure standard U-Boot features (expert users)"
+	help
+	  This option allows certain base U-Boot options and settings
+	  to be disabled or tweaked. This is for specialized
+	  environments which can tolerate a "non-standard" U-Boot.
+	  Only use this if you really know what you are doing.
+
+if EXPERT
+	config SYS_MALLOC_INIT_SKIP_ZEROING
+	bool "Skip memset at malloc init (reduce boot time)"
+	help
+	  This avoids zeroing memory reserved for malloc at malloc init.
+	  Significant boot time reduction is visible for configs in which
+	  CONFIG_SYS_MALLOC_LEN value, has more than few MiB.
+	  Useful for bzip2, bmp logo.
+	  Warning:
+	  When enabling this, please check if malloc calls, maybe
+	  should be replaced by calloc - if expects zeroed memory.
+endif
  endmenu		# General setup
 
  menu "Boot images"

common/dlmalloc.c +6 -3

index 6453ee9..63f68ed 100644
@@ -1535,9 +1535,9 @@ void mem_malloc_init(ulong start, ulong size)
 
  	debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
  	      mem_malloc_end);
-
-	memset((void *)mem_malloc_start, 0, size);
-
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
+	memset((void *)mem_malloc_start, 0x0, size);
+#endif
  	malloc_bin_reloc();
  }
 

@@ -2948,10 +2948,12 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
 
    /* check if expand_top called, in which case don't need to clear */
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
  #if MORECORE_CLEARS
    mchunkptr oldtop = top;
    INTERNAL_SIZE_T oldtopsize = chunksize(top);
  #endif
+#endif
    Void_t* mem = mALLOc (sz);
 
    if ((long)n < 0) return NULL;

@@ -2977,6 +2979,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
      csz = chunksize(p);
 
+#ifndef CONFIG_SYS_MALLOC_INIT_SKIP_ZEROING
  #if MORECORE_CLEARS
      if (p == oldtop && csz > oldtopsize)
      {

common/dlmalloc.c Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size; · line 2993

Quoted 7 lines

common/dlmalloc.c +1 -0

@@ -2984,6 +2987,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
        csz = oldtopsize;
      }
  #endif
+#endif
 
      MALLOC_ZERO(mem, csz - SIZE_SZ);
      return mem;

You are adding only "ifndef" conditionals.

IMHO,
Isn't "#ifdef CONFIG_SYS_MALLOC_INIT_ZEROING" better?
(Generally speaking, CONFIG options that disable a feature are not preferable.)

You also need to add "default y" to the Kconfig
and add "# CONIFG_SYS_MALLOC_INIT_ZEROING is not set" to your defconfig.

Best Regards
Masahiro Yamada

This commit introduces new config: CONFIG_SYS_MALLOC_INIT_DO_ZEROING.

This config is an expert option and is enabled by default.

The all amount of memory reserved for the malloc, is by default set to zero in mem_malloc_init(). When the malloc reserved memory exceeds few MiB, then the boot process can slow down.

So disabling this config, is an expert option to reduce the boot time, and can be disabled by Kconfig.

Note:
After disable this option, only calloc() will return the pointer to the zeroed memory area. Previously, without this option, the memory pointed to untouched malloc memory region, was filled with zeros. So it means, that code with malloc() calls should be reexamined.

Signed-off-by Przemyslaw Marczak <[email protected]>

---
Changes v3:
- squash the commit with the Kconfig option

Changes v4:
- adjust commit message for the new config

---
 Kconfig           | 32 +++++++++++++++++++++++++-------
 common/dlmalloc.c | 10 +++++++---
 2 files changed, 32 insertions(+), 10 deletions(-)

Kconfig +25 -7

index 75bab7f..9ea99b5 100644
@@ -76,13 +76,31 @@ config SYS_MALLOC_F_LEN
          initial serial device and any others that are needed.
 
 menuconfig EXPERT
-        bool "Configure standard U-Boot features (expert users)"
-        help
-          This option allows certain base U-Boot options and settings
-          to be disabled or tweaked. This is for specialized
-          environments which can tolerate a "non-standard" U-Boot.
-          Only use this if you really know what you are doing.
-
+       bool "Configure standard U-Boot features (expert users)"
+       default y
+       help
+         This option allows certain base U-Boot options and settings
+         to be disabled or tweaked. This is for specialized
+         environments which can tolerate a "non-standard" U-Boot.
+         Only use this if you really know what you are doing.
+
+if EXPERT
+       config SYS_MALLOC_INIT_DO_ZEROING
+       bool "Init with zeros the memory reserved for malloc (slow)"
+       default y
+       help
+         This setting is enabled by default. The reserved malloc
+         memory is initialized with zeros, so first malloc calls
+         will return the pointer to the zeroed memory. But this
+         slows the boot time.
+
+         It is recommended to disable it, when CONFIG_SYS_MALLOC_LEN
+         value, has more than few MiB, e.g. when uses bzip2 or bmp logo.
+         Then the boot time can be significantly reduced.
+         Warning:
+         When disabling this, please check if malloc calls, maybe
+         should be replaced by calloc - if expects zeroed memory.
+endif
 endmenu                # General setup
 
 menu "Boot images"

common/dlmalloc.c +7 -4

index 6453ee9..21e103b 100644
@@ -1535,9 +1535,9 @@ void mem_malloc_init(ulong start, ulong size)
 
        debug("using memory %#lx-%#lx for malloc()\n", mem_malloc_start,
              mem_malloc_end);
-
-       memset((void *)mem_malloc_start, 0, size);
-
+#ifdef CONFIG_SYS_MALLOC_INIT_DO_ZEROING
+       memset((void *)mem_malloc_start, 0x0, size);
+#endif
        malloc_bin_reloc();
 }
 

@@ -2948,10 +2948,12 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
 
   /* check if expand_top called, in which case don't need to clear */
+#ifdef CONFIG_SYS_MALLOC_INIT_DO_ZEROING
 #if MORECORE_CLEARS
   mchunkptr oldtop = top;
   INTERNAL_SIZE_T oldtopsize = chunksize(top);
 #endif
+#endif
   Void_t* mem = mALLOc (sz);
 
   if ((long)n < 0) return NULL;

@@ -2977,6 +2979,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
 
     csz = chunksize(p);
 
+#ifdef CONFIG_SYS_MALLOC_INIT_DO_ZEROING
 #if MORECORE_CLEARS
     if (p == oldtop && csz > oldtopsize)
     {

@@ -2984,6 +2987,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t elem_size;
       csz = oldtopsize;
     }
 #endif
+#endif
 
     MALLOC_ZERO(mem, csz - SIZE_SZ);
     return mem;
--

1.9.1

Hi Przemyslaw,

Quoted 2 lines · Przemyslaw Marczak

This commit introduces new config: CONFIG_SYS_MALLOC_INIT_DO_ZEROING.

Minor nit: CONFIG_SYS_MALLOC_CLEAR_ON_INIT might be better.

This commit enables the following configs:
- CONFIG_USE_ARCH_MEMCPY
- CONFIG_USE_ARCH_MEMSET
This increases the performance of memcpy/memset
and also reduces the boot time.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1527ms - before this change (arch memset enabled for .bss clear)
- ~1384ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Cc Minkyu Kang <[email protected]>

Cc Akshay Saraswat <[email protected]>

Cc Simon Glass <[email protected]>

Cc Sjoerd Simons <[email protected]>

---
Changes V3, V4, V5
- none

---
 include/configs/exynos-common.h | 3 +++
 1 file changed, 3 insertions(+)

(quoted diff) +0 -0

b/include/configs/exynos-common.h index 59676ae..87f8db0 100644

For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY, will highly increase the memset/memcpy performance. This is able thanks to the ARM multiple register instructions.

Unfortunatelly the relocation is done without the cache enabled, so it takes some time, but zeroing the BSS memory takes much more longer, especially for the configs with big static buffers.

A quick test confirms, that the boot time improvement after using the arch memcpy for relocation has no significant meaning. The same test confirms that enable the memset for zeroing BSS, reduces the boot time.

So this patch enables the arch memset for zeroing the BSS after the relocation process. For ARM boards, this can be enabled in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1384ms - before this change
- ~888ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Tom Rini <[email protected]>

---
Changes V3, V4, V5
- none

---
 arch/arm/lib/crt0.S | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

arch/arm/lib/crt0.S +0 -0

index 22df3e5..fab3d2c 100644
@@ -115,14 +115,22 @@ here:
 	bl	c_runtime_cpu_setup	/* we still call old

routine here */
ldr r0, =__bss_start /* this is
auto-relocated! */

arch/arm/lib/crt0.S +0 -1

-	ldr	r1, =__bss_end		/* this is

auto-relocated! */

arch/arm/lib/crt0.S +2 -0

+#ifdef CONFIG_USE_ARCH_MEMSET
+	ldr	r3, =__bss_end		/* this is

auto-relocated! */

arch/arm/lib/crt0.S +1 -0

+	mov	r1, #0x00000000		/* prepare zero to

clear BSS */ +

arch/arm/lib/crt0.S +4 -0

+	subs	r2, r3, r0		/* r2 = memset len */
+	bl	memset
+#else
+	ldr	r1, =__bss_end		/* this is

auto-relocated! */ mov r2, #0x00000000 /*
prepare zero to clear BSS */
clbss_l:cmp r0, r1 /* while not at end
of BSS */ strlo r2, [r0] /* clear 32-bit BSS
word */ addlo r0, r0, #4 /* move to next */

For writing files, DFU implementation requires the file buffer with the len at least of file size. For big files it requires the same big buffer.

Previously the file buffer was allocated as a static variable, so it was a part of U-Boot .bss section. For 32MiB len of buffer we have 32MiB of additional space, required for this section.

The .bss needs to be cleared after the relocation.
This introduces an additional boot delay at every start, but usually the dfu feature is not required at the standard boot, so the buffer should be allocated only if required.

This patch removes the static allocation of this buffer, and alloc it with memalign after first call of function:
- dfu_fill_entity_mmc()
and the buffer is freed on dfu_free_entity() call.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~888ms - before this change (arch memset enabled for .bss clear)
- ~464ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Cc Lukasz Majewski <[email protected]>

Cc Stephen Warren <[email protected]>

Cc Pantelis Antoniou <[email protected]>

Cc Tom Rini <[email protected]>

Cc Marek Vasut <[email protected]>

---
Changes V3, V4, V5
- none

---
 drivers/dfu/dfu_mmc.c | 25 ++++++++++++++++++++++---
 1 file changed, 22 insertions(+), 3 deletions(-)

drivers/dfu/dfu_mmc.c +0 -2

index 62d72fe..fd865e1 100644
@@ -16,8 +16,7 @@
 #include <fat.h>
 #include <mmc.h>
 
-static unsigned char __aligned(CONFIG_SYS_CACHELINE_SIZE)
-

dfu_file_buf[CONFIG_SYS_DFU_MAX_FILE_SIZE]; +static unsigned char *dfu_file_buf; static long dfu_file_buf_len;

static int mmc_access_part(struct dfu_entity *dfu, struct mmc *mmc,
int part) @@ -211,7 +210,7 @@ int dfu_flush_medium_mmc(struct dfu_entity *dfu)

drivers/dfu/dfu_mmc.c +21 -1

 	if (dfu->layout != DFU_RAW_ADDR) {
 		/* Do stuff here. */
-		ret = mmc_file_op(DFU_OP_WRITE, dfu, &dfu_file_buf,
+		ret = mmc_file_op(DFU_OP_WRITE, dfu, dfu_file_buf,
 				&dfu_file_buf_len);
 
 		/* Now that we're done */

@@ -263,6 +262,14 @@ int dfu_read_medium_mmc(struct dfu_entity *dfu,
 u64 offset, void *buf, return ret;
 }
 
+void dfu_free_entity_mmc(struct dfu_entity *dfu)
+{
+	if (dfu_file_buf) {
+		free(dfu_file_buf);
+		dfu_file_buf = NULL;
+	}
+}
+
 /*
  * @param s Parameter string containing space-separated arguments:
  *	1st:

@@ -370,6 +377,18 @@ int dfu_fill_entity_mmc(struct dfu_entity *dfu,
 char *devstr, char *s) dfu->write_medium = dfu_write_medium_mmc;
 	dfu->flush_medium = dfu_flush_medium_mmc;
 	dfu->inited = 0;
+	dfu->free_entity = dfu_free_entity_mmc;
+
+	/* Check if file buffer is ready */
+	if (!dfu_file_buf) {
+		dfu_file_buf = memalign(CONFIG_SYS_CACHELINE_SIZE,
+
 CONFIG_SYS_DFU_MAX_FILE_SIZE);
+		if (!dfu_file_buf) {
+			error("Could not memalign 0x%x bytes",
+			      CONFIG_SYS_DFU_MAX_FILE_SIZE);
+			return -ENOMEM;
+		}
+	}
 
 	return 0;

}

This commit introduces new config: CONFIG_SYS_MALLOC_CLEAR_ON_INIT.

This config is an expert option and is enabled by default.

The all amount of memory reserved for the malloc, is by default set to zero in mem_malloc_init(). When the malloc reserved memory exceeds few MiB, then the boot process can slow down.

So disabling this config, is an expert option to reduce the boot time, and can be disabled by Kconfig.

Note:
After disable this option, only calloc() will return the pointer to the zeroed memory area. Previously, without this option, the memory pointed to untouched malloc memory region, was filled with zeros. So it means, that code with malloc() calls should be reexamined.

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---
Changes v3:
- squash the commit with the Kconfig option

Changes v4:
- adjust commit message for the new config

Changes v5:
- change config name to CONFIG_SYS_MALLOC_CLEAR_ON_INIT

---
 Kconfig           | 32 +++++++++++++++++++++++++-------
 common/dlmalloc.c | 10 +++++++---
 2 files changed, 32 insertions(+), 10 deletions(-)

Kconfig +20 -7

index 75bab7f..d6c75d5 100644
@@ -76,13 +76,31 @@ config SYS_MALLOC_F_LEN
 	  initial serial device and any others that are needed.
 
 menuconfig EXPERT
-        bool "Configure standard U-Boot features (expert users)"
-        help
-          This option allows certain base U-Boot options and settings
-          to be disabled or tweaked. This is for specialized
-          environments which can tolerate a "non-standard" U-Boot.
-          Only use this if you really know what you are doing.
-
+	bool "Configure standard U-Boot features (expert users)"
+	default y
+	help
+	  This option allows certain base U-Boot options and settings
+	  to be disabled or tweaked. This is for specialized
+	  environments which can tolerate a "non-standard" U-Boot.
+	  Only use this if you really know what you are doing.
+
+if EXPERT
+	config SYS_MALLOC_CLEAR_ON_INIT
+	bool "Init with zeros the memory reserved for malloc (slow)"
+	default y
+	help
+	  This setting is enabled by default. The reserved malloc
+	  memory is initialized with zeros, so first malloc calls
+	  will return the pointer to the zeroed memory. But this
+	  slows the boot time.
+
+	  It is recommended to disable it, when CONFIG_SYS_MALLOC_LEN
+	  value, has more than few MiB, e.g. when uses bzip2 or bmp

logo.

Kconfig +5 -0

+	  Then the boot time can be significantly reduced.
+	  Warning:
+	  When disabling this, please check if malloc calls, maybe
+	  should be replaced by calloc - if expects zeroed memory.
+endif
 endmenu		# General setup
 
 menu "Boot images"

common/dlmalloc.c +6 -3

index 6453ee9..b2ce063 100644
@@ -1535,9 +1535,9 @@ void mem_malloc_init(ulong start, ulong size)
 
 	debug("using memory %#lx-%#lx for malloc()\n",
 mem_malloc_start, mem_malloc_end);
-
-	memset((void *)mem_malloc_start, 0, size);
-
+#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
+	memset((void *)mem_malloc_start, 0x0, size);
+#endif
 	malloc_bin_reloc();
 }
 

@@ -2948,10 +2948,12 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t
 elem_size; 
 
   /* check if expand_top called, in which case don't need to clear */
+#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
 #if MORECORE_CLEARS
   mchunkptr oldtop = top;
   INTERNAL_SIZE_T oldtopsize = chunksize(top);
 #endif
+#endif
   Void_t* mem = mALLOc (sz);
 
   if ((long)n < 0) return NULL;

@@ -2977,6 +2979,7 @@ Void_t* cALLOc(n, elem_size) size_t n; size_t
 elem_size; 
     csz = chunksize(p);
 
+#ifdef CONFIG_SYS_MALLOC_CLEAR_ON_INIT
 #if MORECORE_CLEARS
     if (p == oldtop && csz > oldtopsize)
     {

Reduce the boot time of Trats2 by disabling the memset at malloc init.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~464ms - before this change (arch memset enabled for .bss clear)
- ~341ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---
Changes V3
- none

Changes V4
- trats2_defconfig: remove CONFIG_EXPERT
- trats2_defconfig: disable CONFIG_SYS_MALLOC_INIT_DO_ZEROING

Changes v5:
- update disabled config name to CONFIG_SYS_MALLOC_CLEAR_ON_INIT

---
 configs/trats2_defconfig | 1 +
 1 file changed, 1 insertion(+)

configs/trats2_defconfig +0 -0

index 1b98b73..9359706 100644

Reduce the boot time of Odroid X2/U3 by disabling the memset at malloc init.

This was tested on Odroid X2.
A quick test with checking gpio pin state using the oscilloscope. Boot time from start to bootcmd (change gpio state by memory write command):
- ~228ms - before this change (arch memset enabled for .bss clear)
- ~100ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

---
Changes V3
- update commit head

Changes V4
- odroid_defconfig: remove CONFIG_EXPERT
- odroid_defconfig: disable CONFIG_SYS_MALLOC_INIT_DO_ZEROING

Changes v5
- update disabled config name to CONFIG_SYS_MALLOC_CLEAR_ON_INIT

---
 configs/odroid_defconfig | 1 +
 1 file changed, 1 insertion(+)

configs/odroid_defconfig +0 -0

index a842837..aac9f5a 100644

Reduce the boot time of Odroid XU3 by disabling the memset at malloc init.

Signed-off-by Przemyslaw Marczak <[email protected]>

---
Changes v5
- new commit

---
 configs/odroid-xu3_defconfig | 2 ++
 1 file changed, 2 insertions(+)

(quoted diff) +0 -0

b/configs/odroid-xu3_defconfig index 74aa0cf..0fb4623 100644

This patchset reduces the boot time for ARM architecture, Exynos boards, and (ARM) boards with DFU enabled.

For tested Trats2 and Odroid X2/XU3 devices, this was done in four steps.

1. Enable the arch memcpy and memset - ARCH specific

2. Enable arch memset for .bss clear - ARCH specific

3. Reduce the .bss section small as possible by: (board specific)
- remove static dfu buffer (32MiB in .bss - Trats2), and use malloc

4. Skip zeroing the memory reserved for malloc at malloc init. For Trats2 it was 80MiB of memory.

The .bss section will grow if we have a lot of static variables. This section is cleared before jump to the relocated U-Boot, and it was done word by word. To reduce the time for this step, we can enable arch memset, which uses multiple ARM registers.

For configs with DFU enabled, we can find the dfu buffer in this section, which has at least 8MB (32MB for Trats2). This is a lot of useless data, which is not required for standard boot. So this buffer should be dynamic allocated.

So, actually the all was about unnecessary operations on 'big' data.

Przemyslaw Marczak (7):
exynos: config: enable arch memcpy and arch memset
arm: relocation: clear .bss section with arch memset if defined
dfu: mmc: file buffer: remove static allocation
dlmalloc: do memset in malloc init as new default config
trats2: defconfig: disable memset at malloc init
odroid: defconfig: disable memset at malloc init
odroid-xu3: defconfig: disable memset at malloc init

  Kconfig                         | 32 +++++++++++++++++++++++++-------
  arch/arm/lib/crt0.S             | 10 +++++++++-
  common/dlmalloc.c               | 10 +++++++---
  configs/odroid-xu3_defconfig    |  2 ++
  configs/odroid_defconfig        |  1 +
  configs/trats2_defconfig        |  1 +
  drivers/dfu/dfu_mmc.c           | 25 ++++++++++++++++++++++---
  include/configs/exynos-common.h |  3 +++
  8 files changed, 70 insertions(+), 14 deletions(-)

This commit enables the following configs:
- CONFIG_USE_ARCH_MEMCPY
- CONFIG_USE_ARCH_MEMSET
This increases the performance of memcpy/memset
and also reduces the boot time.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1527ms - before this change (arch memset enabled for .bss clear)
- ~1384ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Cc Minkyu Kang <[email protected]>

Cc Akshay Saraswat <[email protected]>

Cc Simon Glass <[email protected]>

Cc Sjoerd Simons <[email protected]>

For ARM architecture, enable the CONFIG_USE_ARCH_MEMSET/MEMCPY, will highly increase the memset/memcpy performance. This is able thanks to the ARM multiple register instructions.

Unfortunatelly the relocation is done without the cache enabled, so it takes some time, but zeroing the BSS memory takes much more longer, especially for the configs with big static buffers.

A quick test confirms, that the boot time improvement after using the arch memcpy for relocation has no significant meaning. The same test confirms that enable the memset for zeroing BSS, reduces the boot time.

So this patch enables the arch memset for zeroing the BSS after the relocation process. For ARM boards, this can be enabled in board configs by defining: 'CONFIG_USE_ARCH_MEMSET'.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~1384ms - before this change
- ~888ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Cc Albert Aribaud <[email protected]>

Cc Tom Rini <[email protected]>

For writing files, DFU implementation requires the file buffer with the len at least of file size. For big files it requires the same big buffer.

Previously the file buffer was allocated as a static variable, so it was a part of U-Boot .bss section. For 32MiB len of buffer we have 32MiB of additional space, required for this section.

The .bss needs to be cleared after the relocation.
This introduces an additional boot delay at every start, but usually the dfu feature is not required at the standard boot, so the buffer should be allocated only if required.

This patch removes the static allocation of this buffer, and alloc it with memalign after first call of function:
- dfu_fill_entity_mmc()
and the buffer is freed on dfu_free_entity() call.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~888ms - before this change (arch memset enabled for .bss clear)
- ~464ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Cc Lukasz Majewski <[email protected]>

Cc Stephen Warren <[email protected]>

Cc Pantelis Antoniou <[email protected]>

Cc Tom Rini <[email protected]>

Cc Marek Vasut <[email protected]>

This commit introduces new config: CONFIG_SYS_MALLOC_CLEAR_ON_INIT.

This config is an expert option and is enabled by default.

The all amount of memory reserved for the malloc, is by default set to zero in mem_malloc_init(). When the malloc reserved memory exceeds few MiB, then the boot process can slow down.

So disabling this config, is an expert option to reduce the boot time, and can be disabled by Kconfig.

Note:
After disable this option, only calloc() will return the pointer to the zeroed memory area. Previously, without this option, the memory pointed to untouched malloc memory region, was filled with zeros. So it means, that code with malloc() calls should be reexamined.

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Reduce the boot time of Trats2 by disabling the memset at malloc init.

This was tested on Trats2.
A quick test with trace. Boot time from start to main_loop() entry:
- ~464ms - before this change (arch memset enabled for .bss clear)
- ~341ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Reduce the boot time of Odroid X2/U3 by disabling the memset at malloc init.

This was tested on Odroid X2.
A quick test with checking gpio pin state using the oscilloscope. Boot time from start to bootcmd (change gpio state by memory write command):
- ~228ms - before this change (arch memset enabled for .bss clear)
- ~100ms - after this change

Signed-off-by Przemyslaw Marczak <[email protected]>

Reviewed-by Simon Glass <[email protected]>

Reduce the boot time of Odroid XU3 by disabling the memset at malloc init.

Signed-off-by Przemyslaw Marczak <[email protected]>

The dfu mmc file buffer, which was static, now is allocated by memalign(), so the malloc pool len should be also increased.

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Jagannadha Sutradharudu Teki <[email protected]>

Cc Michal Simek <[email protected]>

---
Changes v6:
- new commit

---
 include/configs/zynq-common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

include/configs/zynq-common.h +0 -0

index 864528a..485babd 100644

The dfu mmc file buffer, which was static, now is allocated by memalign(), so the malloc pool len should be also increased.

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Jagannadha Sutradharudu Teki <[email protected]>

Cc Michal Simek <[email protected]>

Acked-by Michal Simek <[email protected]>

The dfu mmc file buffer, which was static, now is allocated by memalign(), so the malloc pool len should be also increased.

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Tom Rini <[email protected]>

The dfu mmc file buffer, which was static, now is allocated by memalign(), so the malloc pool len should be also increased.

Signed-off-by Przemyslaw Marczak <[email protected]>

Cc Tom Warren <[email protected]>