On Tue, Sep 1, 2015 at 2:14 AM, Maxime Ripard <maxime.rip...@free-electrons.com> wrote: > On Mon, Aug 31, 2015 at 02:17:50PM -0500, Rob Herring wrote: >> On Mon, Aug 31, 2015 at 10:01 AM, Hans de Goede <hdego...@redhat.com> wrote: >> > Hi, >> > >> > 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 <maxime.rip...@free-electrons.com> >> >> --- >> >> 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 ...). >> >> I don't think this needs to be so big with current fastboot tool. It >> will break up the files if needed. However, IIRC this only works for >> sparse images, so I think this needs to be sized large enough for your >> biggest bootimage. > > Hmm, interesting. > > Do you know how it works exactly ? Are we expected to just go on with > writing data at the offset we previously stopped in such a case? I > don't think we support that currently.
The hard work is on the client side. The client will retrieve the maxdownloadsize variable and then split the sparse image into smaller hunks if needed. So the u-boot side doesn't have to do anything special if 2 chunks happen to be contiguous. Rob _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
