[U-Boot] [PATCH 10/13] sunxi: Make the fastboot buffer larger
Maxime Ripard
maxime.ripard at free-electrons.com
Tue Sep 1 09:14:35 CEST 2015
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.
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>
More information about the U-Boot
mailing list