On Tue, Nov 10, 2015 at 7:52 PM, Simon Glass wrote:
> That suggests that gd->malloc_base is not being set up, or is being
> overwritten later. Presumably it should not be NULL?
Yes, gd->malloc_base is NULL. I just prepared a patch to fix this
issue and will submit it soon.
Regards,
Fabio Estev
Hi Fabio,
On 10 November 2015 at 14:47, Fabio Estevam wrote:
> On Tue, Nov 10, 2015 at 7:29 PM, Simon Glass wrote:
>
>> Are you able to check what is happening in malloc_simple()? It is a
>> really simple function.
>
> Yes, I turned on debug inside malloc_simple() and it returns NULL:
>
> U-Boot
On Tue, Nov 10, 2015 at 7:29 PM, Simon Glass wrote:
> Are you able to check what is happening in malloc_simple()? It is a
> really simple function.
Yes, I turned on debug inside malloc_simple() and it returns NULL:
U-Boot SPL 2015.10-00523-ge490ad2-dirty (Nov 10 2015 - 19:44:06)
malloc_simple:
Hi Fabio,
On 10 November 2015 at 14:23, Fabio Estevam wrote:
> Hi Simon,
>
> On Tue, Nov 10, 2015 at 7:19 PM, Simon Glass wrote:
>
>> Then I wonder why malloc() is failing? Is it because there is too much
>
> In the example I sent I only allocate 64 bytes. malloc() does fail
> even if I decrease
Hi Simon,
On Tue, Nov 10, 2015 at 7:19 PM, Simon Glass wrote:
> Then I wonder why malloc() is failing? Is it because there is too much
In the example I sent I only allocate 64 bytes. malloc() does fail
even if I decrease this number.
> being allocated, or is the simple malloc region not being
Hi Fabio,
On 10 November 2015 at 14:16, Fabio Estevam wrote:
> On Tue, Nov 10, 2015 at 1:38 PM, Fabio Estevam wrote:
>
>>> Are you using CONFIG_SYS_MALLOC_F?
>>
>> No, I am not, but I have also tried adding CONFIG_SYS_MALLOC_F_LEN
>> inside configs/mx6sabresd_spl_defconfig, but it did not help.
On Tue, Nov 10, 2015 at 1:38 PM, Fabio Estevam wrote:
>> Are you using CONFIG_SYS_MALLOC_F?
>
> No, I am not, but I have also tried adding CONFIG_SYS_MALLOC_F_LEN
> inside configs/mx6sabresd_spl_defconfig, but it did not help.
Sorry, you asked for CONFIG_SYS_MALLOC_F. I do have CONFIG_SYS_MALLOC
On Tue, Nov 10, 2015 at 1:21 PM, Simon Glass wrote:
> Is this patch against mainline or does your tree have other changes?
This change is against a clean mainline tree.
>> /* DDR initialization */
>> spl_dram_init();
>>
>> It is the ame issue I reported back in August:
>> http://list
Hi Fabio,
On 10 November 2015 at 06:50, Fabio Estevam wrote:
> Hi Simon,
>
> On Tue, Nov 10, 2015 at 12:41 PM, Simon Glass wrote:
>
>> We're at the very start the release process, so I wonder if we can try
>> to figure out what is wrong here?
>>
>> Is it because malloc() is not working, perhaps?
Hello Simon,
On Tue, 10 Nov 2015 06:41:25 -0800, Simon Glass
wrote:
> Hi Fabio,
>
> On 10 November 2015 at 04:40, Fabio Estevam
> wrote:
> > This reverts commit 5ba534d247d418e09c5b4fe5fb7fa780aac08e49.
> >
> > This commit causes cgtqmx6eval to not boot anymore:
> >
> > U-Boot SPL 2015.10-0052
Hi Simon,
On Tue, Nov 10, 2015 at 12:41 PM, Simon Glass wrote:
> We're at the very start the release process, so I wonder if we can try
> to figure out what is wrong here?
>
> Is it because malloc() is not working, perhaps?
Yes, exactly. malloc() is not working.
Issue happens on Congatec board
Hi Fabio,
On 10 November 2015 at 04:40, Fabio Estevam wrote:
> This reverts commit 5ba534d247d418e09c5b4fe5fb7fa780aac08e49.
>
> This commit causes cgtqmx6eval to not boot anymore:
>
> U-Boot SPL 2015.10-00527-g8800bee (Nov 09 2015 - 21:23:54)
> mxc_spi: SPI Slave not allocated !
>
> Signed-off-b
This reverts commit 5ba534d247d418e09c5b4fe5fb7fa780aac08e49.
This commit causes cgtqmx6eval to not boot anymore:
U-Boot SPL 2015.10-00527-g8800bee (Nov 09 2015 - 21:23:54)
mxc_spi: SPI Slave not allocated !
Signed-off-by: Fabio Estevam
---
arch/arm/lib/crt0.S | 28
13 matches
Mail list logo
