[U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size

[Marek Vasut]

On Monday, November 30, 2015 at 07:56:55 PM, Tim Harvey wrote:
> On Wed, Nov 25, 2015 at 5:32 AM, Marek Vasut <marex at denx.de> wrote:
> > On Wednesday, November 25, 2015 at 02:15:13 PM, Przemyslaw Marczak wrote:
> >> On 11/25/2015 01:16 PM, Marek Vasut wrote:
> >> > On Wednesday, November 25, 2015 at 01:00:41 PM, Przemyslaw Marczak wrote:
> >> >> Hello Marek,
> >> >> 
> >> >> On 11/25/2015 11:56 AM, Marek Vasut wrote:
> >> >>> On Wednesday, November 25, 2015 at 11:40:36 AM, Przemyslaw Marczak 
wrote:
> >> >>>> Hello Tim, Marek
> >> >>>> 
> >> >>>> On 11/20/2015 10:40 PM, Tim Harvey wrote:
> >> >>>>> On Fri, Nov 20, 2015 at 12:43 PM, Marek Vasut <marex at denx.de> wrote:
> >> >>>>>> Using 50 MiB malloc pool in SPL is nonsense. Since the caches are
> >> >>>>>> not enabled in SPL, it takes 2 seconds to init the pool and has
> >> >>>>>> no obvious benefit. Reduce the size to 1 MiB.
> >> >>>>>> 
> >> >>>>>> Signed-off-by: Marek Vasut <marex at denx.de>
> >> >>>>>> Cc: Stefano Babic <sbabic at denx.de>
> >> >>>>>> Cc: Tim Harvey <tharvey at gateworks.com>
> >> >>>>>> ---
> >> >>>>>> 
> >> >>>>>>     include/configs/imx6_spl.h | 6 +++---
> >> >>>>>>     1 file changed, 3 insertions(+), 3 deletions(-)
> >> >>>>>> 
> >> >>>>>> diff --git a/include/configs/imx6_spl.h
> >> >>>>>> b/include/configs/imx6_spl.h index 1744f2c..43ce7fe 100644
> >> >>>>>> --- a/include/configs/imx6_spl.h
> >> >>>>>> +++ b/include/configs/imx6_spl.h
> >> >>>>>> @@ -63,15 +63,15 @@
> >> >>>>>> 
> >> >>>>>>     #if defined(CONFIG_MX6SX) || defined(CONFIG_MX6UL) ||
> >> >>>>>>     defined(CONFIG_MX6SL) #define CONFIG_SPL_BSS_START_ADDR
> >> >>>>>>     0x88200000
> >> >>>>>> 
> >> >>>>>> -#define CONFIG_SPL_BSS_MAX_SIZE        0x100000        /* 1 MB
> >> >>>>>> */ +#define CONFIG_SPL_BSS_MAX_SIZE        0x100000             
> >> >>>>>>   /* 1 MB */
> >> >>>>>> 
> >> >>>>>>     #define CONFIG_SYS_SPL_MALLOC_START    0x88300000
> >> >>>>>> 
> >> >>>>>> -#define CONFIG_SYS_SPL_MALLOC_SIZE     0x3200000       /* 50 MB
> >> >>>>>> */ +#define CONFIG_SYS_SPL_MALLOC_SIZE     0x100000             
> >> >>>>>>   /* 1 MB */
> >> >>>>>> 
> >> >>>>>>     #define CONFIG_SYS_TEXT_BASE           0x87800000
> >> >>>>>>     #else
> >> >>>>>>     #define CONFIG_SPL_BSS_START_ADDR      0x18200000
> >> >>>>>>     #define CONFIG_SPL_BSS_MAX_SIZE                0x100000
> >> >>>>>>     /* 1 MB */ #define CONFIG_SYS_SPL_MALLOC_START    0x18300000
> >> >>>>>> 
> >> >>>>>> -#define CONFIG_SYS_SPL_MALLOC_SIZE     0x3200000       /* 50 MB
> >> >>>>>> */ +#define CONFIG_SYS_SPL_MALLOC_SIZE     0x100000        /* 1
> >> >>>>>> MB */
> >> >>>>>> 
> >> >>>>>>     #define CONFIG_SYS_TEXT_BASE           0x17800000
> >> >>>>>>     #endif
> >> >>>>>>     #endif
> >> >>>>>> 
> >> >>>>>> --
> >> >>>>>> 2.1.4
> >> >>>>> 
> >> >>>>> Acked-by: Tim Harvey <tharvey at gateworks.com>
> >> >>>>> 
> >> >>>>> thanks for dropping 2 secs off our time to boot!
> >> >>>>> 
> >> >>>>> Tim
> >> >>>> 
> >> >>>> The boot time for SPL and U-Boot can be reduced more if
> >> >>>> CONFIG_SYS_MALLOC_CLEAR_ON_INIT is unset (default is set).
> >> >>> 
> >> >>> This might confuse DM, so I don't want this. DM checks if it's
> >> >>> structures were already inited and if we don't clear the malloc
> >> >>> area, they would be.
> >> >> 
> >> >> DM is safe - it uses calloc() for it's structures and also driver's
> >> >> static structures are zeroed. Only some private data which is not
> >> >> allocated by DM can be risky to use.
> >> >> 
> >> >> To be precise - we don't use malloc() to get pointer for zeroed
> >> >> memory, this is the job for the calloc().
> >> >> 
> >> >> So any code with bad use of malloc() should be fixed ASAP.
> >> >> 
> >> >> If you assume that clear the malloc pool at boot is safe to use, then
> >> >> I'm asking you, what about the sequence malloc/free/malloc for
> >> >> potentially the same area? You can't be sure that the second returned
> >> >> pointer after calling free() - points to the initially zeroed pool.
> >> >> 
> >> >> We don't clean the malloc pool for configs that we maintain and we
> >> >> didn't noticed any issues related to this. And the boot time is
> >> >> reduced significantly.
> >> > 
> >> > Do you use DM in SPL ?
> >> 
> >> No, we don't use the SPL - for the boards which we maintain.
> > 
> > OK
> > 
> >> > I just checked and I see it's probably only the GD which needs to be
> >> > cleared out, so we should indeed be safe.  In which case, patch is
> >> > welcome to enable CONFIG_SYS_MALLOC_CLEAR_ON_INIT .
> >> 
> >> Yes I can see also for the Exynos SPL, that GD is manually cleared.
> >> 
> >> But disabling the default CONFIG_SYS_MALLOC_CLEAR_ON_INIT, will help you
> >> in reducing the U-Boot init time.
> >> Just try and if you can easy measure the real difference for
> >> enable/disable this config - share the results - it can give us an
> >> interesting conclusions.
> > 
> > Sure, thanks for the hint, but I still don't see any reason for having 50
> > MiB malloc area in SPL ;-)
> 
> Perhaps the use case for a >1MB malloc area is falcon mode. While a
> 1MB area certainly works for loading and bootstrapping to u-boot.img I
> have used anywhere from 1MB to 8MB images for falcon mode.

Does the falcon mode load the image into malloc'd area or directly into
RAM location ? If it's the former, then yeah, large malloc pool makes
sense and MALLOC_CLEAR_ON_INIT makes sense as well I guess.