[U-Boot] [PATCH 10/13] sunxi: Make the fastboot buffer larger

[Maxime Ripard <maxime.ripard@free-electrons.com>]

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 <hdegoede@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.ripard@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.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20150901/d4ac449b/attachment.sig>