From mboxrd@z Thu Jan 1 00:00:00 1970 From: Hans de Goede Date: Tue, 1 Sep 2015 10:59:52 +0200 Subject: [U-Boot] [PATCH 10/13] sunxi: Make the fastboot buffer larger In-Reply-To: <20150901070525.GG29389@lukather> References: <1441032373-16992-1-git-send-email-maxime.ripard@free-electrons.com> <1441032373-16992-11-git-send-email-maxime.ripard@free-electrons.com> <55E46C56.4000507@redhat.com> <20150901070525.GG29389@lukather> Message-ID: <55E56908.9070706@redhat.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi, On 01-09-15 09:05, Maxime Ripard wrote: > Hi, > > On Mon, Aug 31, 2015 at 05:01:42PM +0200, Hans de Goede wrote: >> On 31-08-15 16:46, Maxime Ripard wrote: >>> When using fastboot and flashing a larger image such as the main partition >>> of a system, the current 32MB limit for the buffer is quite small. >>> >>> Increase it to something that looks decent for such a use case. >>> >>> Signed-off-by: Maxime Ripard >>> --- >>> include/configs/sunxi-common.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/include/configs/sunxi-common.h b/include/configs/sunxi-common.h >>> index 1abf73c31179..710521c617f5 100644 >>> --- a/include/configs/sunxi-common.h >>> +++ b/include/configs/sunxi-common.h >>> @@ -363,7 +363,7 @@ extern int soft_i2c_gpio_scl; >>> #ifdef CONFIG_USB_FUNCTION_FASTBOOT >>> #define CONFIG_CMD_FASTBOOT >>> #define CONFIG_FASTBOOT_BUF_ADDR CONFIG_SYS_LOAD_ADDR >>> -#define CONFIG_FASTBOOT_BUF_SIZE 0x2000000 >>> +#define CONFIG_FASTBOOT_BUF_SIZE (256 << 20) >> >> Hmm, where / how does this get allocated? On some boards we only >> have 256M RAM, so this is not going to fit ... also if this comes >> out of the heap, the current heap is only 4M and the wip sunxi >> nand patches boost it to 64 (I still need to verify this works on >> a 256M board, this may need a tweak to bootm_size to make sure >> the bootm code does not try to put the kernel where it conflicts >> with the heap ...). > > It's not allocated, it just uses the RAM directly, starting at the > offset CONFIG_FASTBOOT_BUF_ADDR (0x42000000 in our case), just like > any *load function for example. > > The only thing we have to make sure is that we won't overwrite U-boot > itself, which will be an issue on those 256MB boards... Well the only 256M board is the A13-OLinuXino-MICRO, all other boards have at least 512M and the A13-OLinuXino-MICRO does not have nand, so I guess we do not really need to worry about this. Regards, Hans