[U-Boot,1/1] zynq: Kconfig: extend the bootstrap malloc() pool

Signed-off-by: Anton Gerasimov <tossel@gmail.com>
---
 arch/arm/mach-zynq/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

On 20. 12. 18 22:57, Anton Gerasimov wrote:
> Signed-off-by: Anton Gerasimov <tossel@gmail.com>
> ---
>  arch/arm/mach-zynq/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/mach-zynq/Kconfig b/arch/arm/mach-zynq/Kconfig
> index a599ed63ee..21dfebf5c0 100644
> --- a/arch/arm/mach-zynq/Kconfig
> +++ b/arch/arm/mach-zynq/Kconfig
> @@ -55,7 +55,7 @@ config SYS_CONFIG_NAME
>  	  will be used for board configuration.
>  
>  config SYS_MALLOC_F_LEN
> -	default 0x600
> +	default 0x800
>  
>  config SYS_MALLOC_LEN
>  	default 0x1400000
> 

I have not a problem with this change but it has to be done based on
more information. It means you should look what requires that memory
and if make sense that these components need it at that time.

Note: in v2 please write reasonable commit message directly to the patch
too.

Thanks,
Michal

> I have not a problem with this change but it has to be done based on
> more information. It means you should look what requires that memory
> and if make sense that these components need it at that time.

Thank you for  the advice, that was quite fruitful. So most of the
heap (0x5f4 of 0x600) before the relocation is being consumed in
device_bind_common function which binds device tree entries to
the drivers.

If I remove 'u-boot,dm-pre-alloc' from uart0 node, that is not
being used as far as I can see, it drops to 0x5a0, which lets the board
boot, but still looks pretty tight. So maybe it's worth extending the heap
anyway unless you need more information to take the decision.

Thanks,
Anton

On 21. 12. 18 11:39, Anton Gerasimov wrote:
>> I have not a problem with this change but it has to be done based on
>> more information. It means you should look what requires that memory
>> and if make sense that these components need it at that time.
> 
> Thank you for  the advice, that was quite fruitful. So most of the
> heap (0x5f4 of 0x600) before the relocation is being consumed in
> device_bind_common function which binds device tree entries to
> the drivers.
> 
> If I remove 'u-boot,dm-pre-alloc' from uart0 node, that is not
> being used as far as I can see, it drops to 0x5a0, which lets the board
> boot, but still looks pretty tight. So maybe it's worth extending the heap
> anyway unless you need more information to take the decision.

I understand all of this but will be good to know what consumes that
0x5xx space and if we mark nodes properly that maybe something is not
used and we should remove that marking.

It means expected data is that uarts consumes 0xXXX, axi 0xXXX, sd
0xXXX, etc.

Thanks,
Michal

Hi Michal,

> I understand all of this but will be good to know what consumes that
> 0x5xx space and if we mark nodes properly that maybe something is not
> used and we should remove that marking.
>
> It means expected data is that uarts consumes 0xXXX, axi 0xXXX, sd
> 0xXXX, etc.

measuring only the memory consumed in device_bind_common, I've got
the following results (in decimal):

   root_driver:               108
   mod_exp_sw:                108
   amba:                      120
   serial@e0000000 aka uart0: 112
   serial@e0001000 aka uart1: 88
   spi@e000d000 aka qspi:     120
   sdhci@e0100000 aka mmc0:   455
   sdhci@e0100000.blk:        208
   slcr@f8000000:             96
   clkc@100:                  72
   (total)                    1487 = 0x5cf of 0x600

So the most memory is being consumed by mmc0 (not quite sure what is
this '.blk' device, but it is probably also required), but it's not
dominating, other seemingly useful devices also have a decent share.

Thanks,
Anton

Hi,

On 20. 01. 19 12:29, Anton Gerasimov wrote:
> Hi Michal,
> 
>> I understand all of this but will be good to know what consumes that
>> 0x5xx space and if we mark nodes properly that maybe something is not
>> used and we should remove that marking.
>>
>> It means expected data is that uarts consumes 0xXXX, axi 0xXXX, sd
>> 0xXXX, etc.
> 
> measuring only the memory consumed in device_bind_common, I've got
> the following results (in decimal):
> 
>   root_driver:               108
>   mod_exp_sw:                108
>   amba:                      120
>   serial@e0000000 aka uart0: 112
>   serial@e0001000 aka uart1: 88
>   spi@e000d000 aka qspi:     120
>   sdhci@e0100000 aka mmc0:   455
>   sdhci@e0100000.blk:        208
>   slcr@f8000000:             96
>   clkc@100:                  72
>   (total)                    1487 = 0x5cf of 0x600
> 
> So the most memory is being consumed by mmc0 (not quite sure what is
> this '.blk' device, but it is probably also required), but it's not
> dominating, other seemingly useful devices also have a decent share.

ok. Thanks for this list. I have extended that commit message with this
and applied. We can look at these separately to find out if we can tune
it a little bit.

Thanks,
Michal