Message ID | 1442157957-11484-1-git-send-email-hdegoede@redhat.com |
---|---|
State | Accepted |
Delegated to: | Hans de Goede |
Headers | show |
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>
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? Regards, Karsten
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
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 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" \
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(-)