[U-Boot] [PATCH v2 5/6] spl: support using full malloc with SYS_MALLOC_F_LEN

[Simon Goldschmidt]

Hi Simon,

On Fri, Mar 22, 2019 at 8:53 AM Simon Glass <sjg at chromium.org> wrote:
>
> Hi,
>
> On Sat, 16 Mar 2019 at 04:14, Simon Goldschmidt
> <simon.k.r.goldschmidt at gmail.com> wrote:
> >
> > Some platforms (like socfpga A10) need a big hep before SDRAM is available
>
> heap
>
> > (e.g. because FAT is used). For such platforms, simple_malloc is often not
> > a good option as it does not support freeing memory. These platforms often
>
> Does the lack of free() actually cause any problems on this platform?

Yes. Without free(), the available SRAM is not enough to provide the
heap required.

>
> > use the non-Kconfig defines CONFIG_SYS_SPL_MALLOC_START (and its SIZE).
> >
> > This patch allows enabling CONFIG_SPL_SYS_MALLOC_F_LEN while leaving
> > CONFIG_SPL_SYS_MALLOC_SIMPLE disabled. In this case, the full malloc heap
> > is made available as early as the simple_malloc heap would be normally.
>
> Why not init SDRAM before using FAT?

Because the SDRAM controller is not available yet. As I understood,
his is an FPGA
platform where the initial FPGA image has to be loaded to get SDRAM running.

If that initial FPGA image is to be loaded from FAT, you just need a
rather big heap.

Currently, the non-Kconfig CONFIG_SYS_SPL_MALLOC_START is used. I don't
think using this one is a good approach as it is yet another way of
ad-hoc memory
allocation plus it's quite confusing to have full and simple malloc
use a different way
to allocate the heap region.

Regards,
Simon

>
> >
> > This way, platforms can drop the non-Kconfig options to set up the full
> > heap and rely on the same automatically calculated heap allocation used
> > for simple heap.
> >
> > Signed-off-by: Simon Goldschmidt <simon.k.r.goldschmidt at gmail.com>
> > ---
> >
> > Changes in v2: None
> >
> >  common/spl/spl.c | 5 +++++
> >  1 file changed, 5 insertions(+)
>
> Regards,
> Simon