Hi Simon, On Fri, Mar 22, 2019 at 8:53 AM Simon Glass <s...@chromium.org> wrote: > > Hi, > > On Sat, 16 Mar 2019 at 04:14, Simon Goldschmidt > <simon.k.r.goldschm...@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.goldschm...@gmail.com> > > --- > > > > Changes in v2: None > > > > common/spl/spl.c | 5 +++++ > > 1 file changed, 5 insertions(+) > > Regards, > Simon _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
