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.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 ...).
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
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
