* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size @ 2015-11-20 20:43 Marek Vasut 2015-11-20 21:24 ` Stefano Babic 2015-11-20 21:40 ` Tim Harvey 0 siblings, 2 replies; 14+ messages in thread From: Marek Vasut @ 2015-11-20 20:43 UTC (permalink / raw) To: u-boot 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@denx.de> Cc: Stefano Babic <sbabic@denx.de> Cc: Tim Harvey <tharvey@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 ^ permalink raw reply related [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-20 20:43 [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size Marek Vasut @ 2015-11-20 21:24 ` Stefano Babic 2015-11-20 21:40 ` Tim Harvey 1 sibling, 0 replies; 14+ messages in thread From: Stefano Babic @ 2015-11-20 21:24 UTC (permalink / raw) To: u-boot On 20/11/2015 21:43, Marek Vasut 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. You're absolutely right ! Nice catch ! > > Signed-off-by: Marek Vasut <marex@denx.de> > Cc: Stefano Babic <sbabic@denx.de> > Cc: Tim Harvey <tharvey@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 > Tested-by: Stefano Babic <sbabic@denx.de> Best regards, Stefano Babic -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de ===================================================================== ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-20 20:43 [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size Marek Vasut 2015-11-20 21:24 ` Stefano Babic @ 2015-11-20 21:40 ` Tim Harvey 2015-11-25 10:40 ` Przemyslaw Marczak 1 sibling, 1 reply; 14+ messages in thread From: Tim Harvey @ 2015-11-20 21:40 UTC (permalink / raw) To: u-boot On Fri, Nov 20, 2015 at 12:43 PM, Marek Vasut <marex@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@denx.de> > Cc: Stefano Babic <sbabic@denx.de> > Cc: Tim Harvey <tharvey@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@gateworks.com> thanks for dropping 2 secs off our time to boot! Tim ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-20 21:40 ` Tim Harvey @ 2015-11-25 10:40 ` Przemyslaw Marczak 2015-11-25 10:56 ` Marek Vasut 0 siblings, 1 reply; 14+ messages in thread From: Przemyslaw Marczak @ 2015-11-25 10:40 UTC (permalink / raw) To: u-boot 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@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@denx.de> >> Cc: Stefano Babic <sbabic@denx.de> >> Cc: Tim Harvey <tharvey@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@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). Then it doesn't matter what is the size of malloc pool but it's not cleared - so needs check if malloc() calls should be changed to calloc(). Best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marczak at samsung.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-25 10:40 ` Przemyslaw Marczak @ 2015-11-25 10:56 ` Marek Vasut 2015-11-25 12:00 ` Przemyslaw Marczak 0 siblings, 1 reply; 14+ messages in thread From: Marek Vasut @ 2015-11-25 10:56 UTC (permalink / raw) To: u-boot 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@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@denx.de> > >> Cc: Stefano Babic <sbabic@denx.de> > >> Cc: Tim Harvey <tharvey@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@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. > Then it doesn't matter what is the size of malloc pool but it's not > cleared - so needs check if malloc() calls should be changed to calloc(). > > Best regards, Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-25 10:56 ` Marek Vasut @ 2015-11-25 12:00 ` Przemyslaw Marczak 2015-11-25 12:16 ` Marek Vasut 0 siblings, 1 reply; 14+ messages in thread From: Przemyslaw Marczak @ 2015-11-25 12:00 UTC (permalink / raw) To: u-boot 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@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@denx.de> >>>> Cc: Stefano Babic <sbabic@denx.de> >>>> Cc: Tim Harvey <tharvey@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@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. >> Then it doesn't matter what is the size of malloc pool but it's not >> cleared - so needs check if malloc() calls should be changed to calloc(). >> >> Best regards, > > Best regards, > Marek Vasut > Best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marczak at samsung.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-25 12:00 ` Przemyslaw Marczak @ 2015-11-25 12:16 ` Marek Vasut 2015-11-25 13:15 ` Przemyslaw Marczak 0 siblings, 1 reply; 14+ messages in thread From: Marek Vasut @ 2015-11-25 12:16 UTC (permalink / raw) To: u-boot 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@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@denx.de> > >>>> Cc: Stefano Babic <sbabic@denx.de> > >>>> Cc: Tim Harvey <tharvey@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@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 ? 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 . ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-25 12:16 ` Marek Vasut @ 2015-11-25 13:15 ` Przemyslaw Marczak 2015-11-25 13:32 ` Marek Vasut 0 siblings, 1 reply; 14+ messages in thread From: Przemyslaw Marczak @ 2015-11-25 13:15 UTC (permalink / raw) To: u-boot 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@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@denx.de> >>>>>> Cc: Stefano Babic <sbabic@denx.de> >>>>>> Cc: Tim Harvey <tharvey@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@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. > > 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. Best regards, -- Przemyslaw Marczak Samsung R&D Institute Poland Samsung Electronics p.marczak at samsung.com ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-25 13:15 ` Przemyslaw Marczak @ 2015-11-25 13:32 ` Marek Vasut 2015-11-30 18:56 ` Tim Harvey 0 siblings, 1 reply; 14+ messages in thread From: Marek Vasut @ 2015-11-25 13:32 UTC (permalink / raw) To: u-boot 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@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@denx.de> > >>>>>> Cc: Stefano Babic <sbabic@denx.de> > >>>>>> Cc: Tim Harvey <tharvey@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@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 ;-) ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-25 13:32 ` Marek Vasut @ 2015-11-30 18:56 ` Tim Harvey 2015-11-30 23:31 ` Marek Vasut 0 siblings, 1 reply; 14+ messages in thread From: Tim Harvey @ 2015-11-30 18:56 UTC (permalink / raw) To: u-boot On Wed, Nov 25, 2015 at 5:32 AM, Marek Vasut <marex@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@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@denx.de> >> >>>>>> Cc: Stefano Babic <sbabic@denx.de> >> >>>>>> Cc: Tim Harvey <tharvey@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@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. Tim ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-30 18:56 ` Tim Harvey @ 2015-11-30 23:31 ` Marek Vasut 2015-12-01 14:13 ` Tim Harvey 2015-12-01 14:18 ` Stefano Babic 0 siblings, 2 replies; 14+ messages in thread From: Marek Vasut @ 2015-11-30 23:31 UTC (permalink / raw) To: u-boot 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@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@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@denx.de> > >> >>>>>> Cc: Stefano Babic <sbabic@denx.de> > >> >>>>>> Cc: Tim Harvey <tharvey@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@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. ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-30 23:31 ` Marek Vasut @ 2015-12-01 14:13 ` Tim Harvey 2015-12-01 14:16 ` Marek Vasut 2015-12-01 14:18 ` Stefano Babic 1 sibling, 1 reply; 14+ messages in thread From: Tim Harvey @ 2015-12-01 14:13 UTC (permalink / raw) To: u-boot On Mon, Nov 30, 2015 at 3:31 PM, Marek Vasut <marex@denx.de> wrote: >> >> 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. Marek, I checked and Falcon mode does load images directly into RAM so large malloc still doesn't make sense and should be reduced. I think 1MB is a fine value. Tim ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-12-01 14:13 ` Tim Harvey @ 2015-12-01 14:16 ` Marek Vasut 0 siblings, 0 replies; 14+ messages in thread From: Marek Vasut @ 2015-12-01 14:16 UTC (permalink / raw) To: u-boot On Tuesday, December 01, 2015 at 03:13:17 PM, Tim Harvey wrote: > On Mon, Nov 30, 2015 at 3:31 PM, Marek Vasut <marex@denx.de> wrote: > >> 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. > > Marek, Hi Tim, > I checked and Falcon mode does load images directly into RAM so large > malloc still doesn't make sense and should be reduced. I think 1MB is > a fine value. Thank you! Best regards, Marek Vasut ^ permalink raw reply [flat|nested] 14+ messages in thread
* [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size 2015-11-30 23:31 ` Marek Vasut 2015-12-01 14:13 ` Tim Harvey @ 2015-12-01 14:18 ` Stefano Babic 1 sibling, 0 replies; 14+ messages in thread From: Stefano Babic @ 2015-12-01 14:18 UTC (permalink / raw) To: u-boot Hi Marek, On 01/12/2015 00:31, Marek Vasut wrote: >> >> 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. No, it copies directly into the RAM. Large malloc area are not needed for Falcon Mode, and I have not idea who needs a large area. More as instantiating SPI or I2C is generally not needed. Best regards, Stefano Babic -- ===================================================================== DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sbabic at denx.de ===================================================================== ^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2015-12-01 14:18 UTC | newest] Thread overview: 14+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2015-11-20 20:43 [U-Boot] [PATCH] arm: mx6: Reduce SPL malloc pool size Marek Vasut 2015-11-20 21:24 ` Stefano Babic 2015-11-20 21:40 ` Tim Harvey 2015-11-25 10:40 ` Przemyslaw Marczak 2015-11-25 10:56 ` Marek Vasut 2015-11-25 12:00 ` Przemyslaw Marczak 2015-11-25 12:16 ` Marek Vasut 2015-11-25 13:15 ` Przemyslaw Marczak 2015-11-25 13:32 ` Marek Vasut 2015-11-30 18:56 ` Tim Harvey 2015-11-30 23:31 ` Marek Vasut 2015-12-01 14:13 ` Tim Harvey 2015-12-01 14:16 ` Marek Vasut 2015-12-01 14:18 ` Stefano Babic
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox