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

[Hans de Goede]

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 <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 ...).
>
> 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