Hi Folks,
If you set CONFIG_FASTBOOT_BUF_ADDR to anything other than the same
as $loadaddr then the call to do_bootm() in the fastboot code
will call do_bootm on a memory region that has nothing to do with
the image downloaded. Sometimes the result is a hung system, other
times the system reboots.
I'm not sure of the correct fix. The possibilities are:
1. Get rid of CONFIG_FASTBOOT_BUF_ADDR and use $loadaddr
instead. All the defconfigs that enable fastboot currently set
CONFIG_FASTBOOT_BUF_ADDR to the same value as CONFIG_LOADADDR at
present.
2. memcpy from the downloaded image to $loadaddr if possible. This
would allow other payloads than ANDROID boot images, with a bit
more work. (For example, I'd love to be able to boot ELF images
using fastboot -- which doesn't work at present, because the
entry point in the elf header isn't used)
3. The simplest: call do_bootm() with the address where the
image has just been downloaded. The attached patch does this.
What do you think?
Peter C
drivers/usb/gadget/f_fastboot.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Index: u-boot/drivers/usb/gadget/f_fastboot.c
===================================================================
--- u-boot.orig/drivers/usb/gadget/f_fastboot.c 2016-09-06 14:10:55.791917017
+1000
+++ u-boot/drivers/usb/gadget/f_fastboot.c 2016-09-07 19:20:23.087155135
+1000
@@ -553,7 +553,7 @@ static void do_bootm_on_complete(struct
puts("Booting kernel..\n");
- sprintf(boot_addr_start, "0x%lx", load_addr);
+ sprintf(boot_addr_start, "0x%lx", CONFIG_FASTBOOT_BUF_ADDR);
do_bootm(NULL, 0, 2, bootm_args);
/* This only happens if image is somehow faulty so we start over */
--
Dr Peter Chubb Tel: +61 2 9490 5852 http://ts.data61.csiro.au/
Trustworthy Systems Group Data61 (formerly NICTA)
_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
