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

[Rob Herring]

On Tue, Sep 1, 2015 at 2:14 AM, Maxime Ripard
<maxime.ripard at 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 <hdegoede at 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 at 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