[U-Boot] [PATCH] ARM: crt0: Pass malloc base address

[Simon Glass <sjg@chromium.org>]

Hi Fabio,

On 11 November 2015 at 14:24, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Simon,
>
> On Wed, Nov 11, 2015 at 7:08 PM, Simon Glass <sjg@chromium.org> wrote:
>
>> That test is intended to avoid setting up simple malloc() if we plan
>> to use full malloc() in SPL. Of course, full malloc() is set up a
>> little later (in spl_init()). But we should not need both - either we
>> use simple malloc() or full malloc().
>>
>> But for your board I see:
>>
>> $ grep CONFIG_SYS_SPL_MALLOC_SIZE b/mx6sabresd_spl/u-boot.cfg
>> #define CONFIG_SYS_SPL_MALLOC_SIZE 0x3200000
>>
>> So you will not be able to use simple malloc(). I'd suggest calling
>> spl_init() from board_init_f() if you need malloc() there. But it
>
> Yes, I do call spl_init() from board_init_f() prior to calling
> malloc() and this has been working fine prior to 5ba534d247d418.
>
>> presumably needs to be done after you have SDRAM up. So perhaps
>
> The trick here is that I need malloc to work prior to have SDRAM configured.
>
> On cgtqmx6eval we need to read SPI NOR to determine what kind of DDR
> we will need to configure.
>
> Otavio has sent the SPL support for cgtqmx6eval, but it has not
> reached U-boot mainline yet.
>
> I am reproducing the problem on a mx6sabresd_spl target with the
> simple example code I sent previously.

I see. That's not a use case I have seen before.

I'd suggest changing the #ifdef to always set up early malloc() if
CONFIG_SYS_MALLOC_F is set. There will of course be a new malloc()
once spi_init() is called, but that does not matter.

In your patch, please be careful to add some docs to the README on
this point (the early malloc() is only there to permit DRAM init,
etc.). It could get quite confusing...

Regards,
Simon