Hi Lokesh,
thanks for having a look!
On 02/02/17 05:35, Lokesh Vutla wrote:
>
>
> On 2/2/2017 5:18 AM, André Przywara wrote:
>> On 27/01/17 16:39, Andrew F. Davis wrote:
>>
>> Hi,
>>
>>> spl_init on some boards is called after stack and heap relocation, on
>>> some platforms spl_relocate_stack_gd is called to handle setting the
>>> limit to its value CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN when simple
>>> SPL malloc is enabled during relocation. spl_init should then not
>>> re-assign the old pre-relocation limit when this is defined.
>>
>> I am sorry to say this, but this very patch breaks SPL boot on sunxi
>> boards (tested on the Pine64, the Orangepi PC2 (with a similar ARMv8
>> SoC) and the OrangePi Zero (ARMv7 Allwinner H3 SoC).
>>
>> U-Boot SPL 2017.03-rc1-00022-gf77309d (Feb 01 2017 - 23:27:19)
>> DRAM: 1024 MiB
>> Trying to boot from MMC1
>> MMC Device 0 not found
>> spl: could not find mmc device. error: -19
>> SPL: failed to boot from all boot devices
>> ### ERROR ### Please RESET the board ###
>>
>> sunxi boards both use the default CONFIG_SYS_MALLOC_F_LEN=0x400 and
>> CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN=0x100000.
>
> In your case, before this patch malloc_limit is MALLOC_F_LEN(0x400),
> after this patch malloc_limit is SPL_STACK_R_MALLOC_SIMPLE_LEN(0x100000)
> . Stack relocated address is 0x4fe00000(is this in DDR?). SPL_STACK_R is
> mainly targetted for relocating SPL stack to DDR.
Yes, this is at DDR (which starts at 1G).
> - Is 1MB available at 0x4fe00000?
Yes, the smallest board I have has 256MB, though I've seen this on
boards with one GB as well. But even in the worst case this is 2 MB
below end of DDR.
The BSS is at 0x4ff80000, but that shouldn't conflict then.
Is this address actually the _starting_ address for the malloc heap? So
malloc uses memory above this address, the stack below? Or does malloc
use some stack allocation for its purpose?
> - Can you reduce the size or change SPL_STACK_R to DDR and verify?
I will check tonight (no boards here at the moment).
Thanks for the explanation and the pointers, this gives me something to
debug on.
Cheers,
Andre
>
> Thanks and regards,
> Lokesh
>
>>
>> At the moment the code there is beyond me, so I can't really say how
>> this breaks, but it clearly does: reverting this patch makes U-Boot
>> happy again.
>>
>> Any ideas?
>>
>> Cheers,
>> Andre.
>>
>>>
>>> Signed-off-by: Andrew F. Davis <a...@ti.com>
>>> ---
>>> common/spl/spl.c | 7 ++++++-
>>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/common/spl/spl.c b/common/spl/spl.c
>>> index 462c3a2b97..a3808a988b 100644
>>> --- a/common/spl/spl.c
>>> +++ b/common/spl/spl.c
>>> @@ -183,7 +183,12 @@ int spl_init(void)
>>> int ret;
>>>
>>> debug("spl_init()\n");
>>> -#if defined(CONFIG_SYS_MALLOC_F_LEN)
>>> +/*
>>> + * with CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN we set malloc_base and
>>> + * malloc_limit in spl_relocate_stack_gd
>>> + */
>>> +#if defined(CONFIG_SYS_MALLOC_F_LEN) && \
>>> + !defined(CONFIG_SPL_STACK_R_MALLOC_SIMPLE_LEN)
>>> #ifdef CONFIG_MALLOC_F_ADDR
>>> gd->malloc_base = CONFIG_MALLOC_F_ADDR;
>>> #endif
>>>
>>
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
