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 */