[U-Boot] [PATCH] sunxi: Tweak various memory addresses

[U-Boot] [PATCH] sunxi: Tweak various memory addresses

[Hans de Goede]

For the upcoming nand support we need a bigger heap, esp. ubi[fs] uses
quite a bit of memory, increase the heap size to 64 MB.

Our video code returns unused reserved framebuffer memory to the kernel
before booting it. Drop the #ifdef-ery and simply always reserve 16 MB.

Adjust bootm_size for the above changes.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 include/configs/sunxi-common.h | 14 +++++---------
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h
index 8ada7e2..cf348b3 100644
--- a/include/configs/sunxi-common.h
+++ b/include/configs/sunxi-common.h
@@ -173,8 +173,8 @@
 #define CONFIG_SYS_MMC_ENV_DEV		0	/* first detected MMC controller */
 #endif
 
-/* 4MB of malloc() pool */
-#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (4 << 20))
+/* 64MB of malloc() pool */
+#define CONFIG_SYS_MALLOC_LEN		(CONFIG_ENV_SIZE + (64 << 20))
 
 /*
  * Miscellaneous configurable options
@@ -303,11 +303,7 @@ extern int soft_i2c_gpio_scl;
  * The amount of RAM to keep free at the top of RAM when relocating u-boot,
  * to use as framebuffer. This must be a multiple of 4096.
  */
-#ifdef CONFIG_VIDEO_LCD_PANEL_EDP_4_LANE_1620M_VIA_ANX9804
-#define CONFIG_SUNXI_MAX_FB_SIZE (12 << 20)
-#else
-#define CONFIG_SUNXI_MAX_FB_SIZE (9 << 20)
-#endif
+#define CONFIG_SUNXI_MAX_FB_SIZE (16 << 20)
 
 /* Do we want to initialize a simple FB? */
 #define CONFIG_VIDEO_DT_SIMPLEFB
@@ -414,12 +410,12 @@ extern int soft_i2c_gpio_scl;
 #define CONFIG_PRE_CON_BUF_SZ		4096 /* Aprox 2 80*25 screens */
 
 /*
- * 240M RAM (256M minimum minus space for the framebuffer),
+ * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc.
  * 32M uncompressed kernel, 16M compressed kernel, 1M fdt,
  * 1M script, 1M pxe and the ramdisk@the end.
  */
 #define MEM_LAYOUT_ENV_SETTINGS \
-	"bootm_size=0xf000000\0" \
+	"bootm_size=0xa000000\0" \
 	"kernel_addr_r=" __stringify(SDRAM_OFFSET(2000000)) "\0" \
 	"fdt_addr_r=" __stringify(SDRAM_OFFSET(3000000)) "\0" \
 	"scriptaddr=" __stringify(SDRAM_OFFSET(3100000)) "\0" \
-- 
2.4.3

[U-Boot] [PATCH] sunxi: Tweak various memory addresses

[Ian Campbell]

On Sun, 2015-09-13 at 17:25 +0200, Hans de Goede wrote:
> For the upcoming nand support we need a bigger heap, esp. ubi[fs]
> uses
> quite a bit of memory, increase the heap size to 64 MB.
> 
> Our video code returns unused reserved framebuffer memory to the
> kernel
> before booting it. Drop the #ifdef-ery and simply always reserve 16
> MB.
> 
> Adjust bootm_size for the above changes.
> 
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Acked-by: Ian Campbell <ijc@hellion.org.uk>

[U-Boot] [PATCH] sunxi: Tweak various memory addresses

[Hans de Goede]

Hi,

On 13-09-15 18:54, Karsten Merker wrote:
> On Sun, Sep 13, 2015 at 05:25:57PM +0200, Hans de Goede wrote:
>
>> For the upcoming nand support we need a bigger heap, esp. ubi[fs] uses
>> quite a bit of memory, increase the heap size to 64 MB.
> [...]
>>   /*
>> - * 240M RAM (256M minimum minus space for the framebuffer),
>> + * 160M RAM (256M minimum minus 64MB heap + 32MB for u-boot, stack, fb, etc.
>>    * 32M uncompressed kernel, 16M compressed kernel, 1M fdt,
>>    * 1M script, 1M pxe and the ramdisk at the end.
>>    */
>>   #define MEM_LAYOUT_ENV_SETTINGS \
>> -	"bootm_size=0xf000000\0" \
>> +	"bootm_size=0xa000000\0" \
>>   	"kernel_addr_r=" __stringify(SDRAM_OFFSET(2000000)) "\0" \
>>   	"fdt_addr_r=" __stringify(SDRAM_OFFSET(3000000)) "\0" \
>>   	"scriptaddr=" __stringify(SDRAM_OFFSET(3100000)) "\0" \
>
> Hello,
>
> I am just thinking about the case where somebody upgrades an
> existing u-boot on an SD card to a new version with NAND support
> and then tries to run NAND-related commands.  In that case there
> would still be the old bootm_size setting in the environment, so
> that NAND-related commands might fail due to not enough heap.
>
> Is there some kind of "release notes" document where we could
> note that on upgrading the user should run "env default
> bootm_size; saveenv" or something alike?

Actually bootm_size is only used to determine where to relocate
the kernel / initrd when doing a bootm command, and that relocation
rarely happens. And the new bootm_size is only needed on 256M boards,
of which we have only 1.

Moreover I do not expect a lot people to have ever done a saveenv
command.

Regards,

Hans