[PATCH v2 0/2] fastboot/mach-meson: release usb_gadget on reboot commands
When host issues "fastboot reboot fastboot", it's expected that the board drops the USB connection before resetting.
On some boards, such as Khadas VIM3L and SEI610, this is not the case.
We observe the following error: $ fastboot reboot fastboot Rebooting into fastboot OKAY [ 0.004s] fastboot: error: Failed to boot into userspace fastboot; one or more components might be unbootable.
This does not happen when we use the RST button on the board. It can be reproduced in linux with: $ echo b > /proc/sysrq-trigger
In this case, we hit a undefined hardware behavior, where D+ and D- are in an unknown state. Therefore the host can't detect usb disconnection.
This series proposes 2 approaches for this problem: * generic fix, which ensures that usb_gadget_disconnect() is called when the board receives any "fastboot reboot" commands * platform specific reset implementation for g12a to ensure that the usb controller gets properly reset.
Changes in v2: * Transformed into a series to provide both generic and platform specific fix (Marek) * Simplified generic fix via g_dnl_trigger_detach() (Marek) * Link to v1: https://lore.kernel.org/r/20220721135955.360195-1-mkorpershoek@baylibre.com
Signed-off-by: Mattijs Korpershoek mkorpershoek@baylibre.com
--- Mattijs Korpershoek (2): usb: gadget: fastboot: detach usb on reboot commands mach-meson: g12a: reset usb controller in reset_misc()
arch/arm/mach-meson/board-g12a.c | 14 ++++++++++++++ cmd/fastboot.c | 2 +- configs/bananapi-m5_defconfig | 2 ++ configs/beelink-gsking-x_defconfig | 2 ++ configs/beelink-gtking_defconfig | 2 ++ configs/beelink-gtkingpro_defconfig | 2 ++ configs/khadas-vim3_android_ab_defconfig | 2 ++ configs/khadas-vim3_android_defconfig | 2 ++ configs/khadas-vim3_defconfig | 2 ++ configs/khadas-vim3l_android_ab_defconfig | 2 ++ configs/khadas-vim3l_android_defconfig | 2 ++ configs/khadas-vim3l_defconfig | 2 ++ configs/odroid-c4_defconfig | 2 ++ configs/odroid-hc4_defconfig | 2 ++ configs/odroid-n2_defconfig | 2 ++ configs/radxa-zero_defconfig | 2 ++ configs/u200_defconfig | 2 ++ drivers/usb/gadget/f_fastboot.c | 1 + 18 files changed, 46 insertions(+), 1 deletion(-) --- base-commit: 2d4591353452638132d711551fec3495b7644731 change-id: 20220728-reset-usb-controller-1b54be54b9d8
Best regards,
When host issues "fastboot reboot fastboot", it's expected that the board drops the USB connection before resetting.
On some boards, such as Khadas VIM3L and SEI610, this is not the case.
We observe the following error: $ fastboot reboot fastboot Rebooting into fastboot OKAY [ 0.004s] fastboot: error: Failed to boot into userspace fastboot; one or more components might be unbootable.
This does not happen when we use the RST button on the board. It can be reproduced in linux with: # echo b > /proc/sysrq-trigger
In this case, we hit a undefined hardware behavior, where D+ and D- are in an unknown state. Therefore the host can't detect usb disconnection.
Make sure we always call usb_gadget_release() when a "fastboot reboot" command is issued.
Note: usb_gadget_release() should be called before g_dnl_unregister() because g_dnl_unregister() triggers a complete() call on each endpoint (thus calling do_reset()).
Signed-off-by: Mattijs Korpershoek mkorpershoek@baylibre.com --- cmd/fastboot.c | 2 +- drivers/usb/gadget/f_fastboot.c | 1 + 2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/cmd/fastboot.c b/cmd/fastboot.c index dd223b1554da..b498e4b22bb3 100644 --- a/cmd/fastboot.c +++ b/cmd/fastboot.c @@ -83,9 +83,9 @@ static int do_fastboot_usb(int argc, char *const argv[], ret = CMD_RET_SUCCESS;
exit: + usb_gadget_release(controller_index); g_dnl_unregister(); g_dnl_clear_detach(); - usb_gadget_release(controller_index);
return ret; #else diff --git a/drivers/usb/gadget/f_fastboot.c b/drivers/usb/gadget/f_fastboot.c index d0e92c7a071f..07b1681c8a9a 100644 --- a/drivers/usb/gadget/f_fastboot.c +++ b/drivers/usb/gadget/f_fastboot.c @@ -544,6 +544,7 @@ static void rx_handler_command(struct usb_ep *ep, struct usb_request *req) case FASTBOOT_COMMAND_REBOOT_FASTBOOTD: case FASTBOOT_COMMAND_REBOOT_RECOVERY: fastboot_func->in_req->complete = compl_do_reset; + g_dnl_trigger_detach(); break; #if CONFIG_IS_ENABLED(FASTBOOT_UUU_SUPPORT) case FASTBOOT_COMMAND_ACMD:
On 10/7/22 11:38, Mattijs Korpershoek wrote:
When host issues "fastboot reboot fastboot", it's expected that the board drops the USB connection before resetting.
On some boards, such as Khadas VIM3L and SEI610, this is not the case.
We observe the following error: $ fastboot reboot fastboot Rebooting into fastboot OKAY [ 0.004s] fastboot: error: Failed to boot into userspace fastboot; one or more components might be unbootable.
This does not happen when we use the RST button on the board. It can be reproduced in linux with: # echo b > /proc/sysrq-trigger
In this case, we hit a undefined hardware behavior, where D+ and D- are in an unknown state. Therefore the host can't detect usb disconnection.
Make sure we always call usb_gadget_release() when a "fastboot reboot" command is issued.
Note: usb_gadget_release() should be called before g_dnl_unregister() because g_dnl_unregister() triggers a complete() call on each endpoint (thus calling do_reset()).
Applied to usb/master , thanks
On some g12a boards like the VIM3L and the SEI610, with some USB cables/hosts, there is a long (5s) delay before between "fastboot reboot" and the host detecting a USB reset.
This breaks tools relying on "fastboot reboot fastboot" which assume that 1s after the command send, the board should disconnect on usb.
To reproduce, enable fastboot in U-Boot console: => fastboot usb 0
Then, on the host, run: # echo "running fastboot reboot bootloader" > /dev/kmsg && fastboot reboot bootloader Rebooting into bootloader OKAY [ 0.003s] Finished. Total time: 3.033s
[54074.251551] running fastboot reboot bootloader ... there is a delay of 5s before we detect a disconnection ... [54079.041238] usb 1-7.4: USB disconnect, device number 72 [54079.239625] usb 1-7.4: new high-speed USB device number 73 using xhci_hcd [54079.359103] usb 1-7.4: New USB device found, idVendor=1b8e, idProduct=fada, bcdDevice= 2.27 [54079.359110] usb 1-7.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [54079.359112] usb 1-7.4: Product: USB download gadget [54079.359114] usb 1-7.4: Manufacturer: U-Boot [54079.359116] usb 1-7.4: SerialNumber: C8631470CC41
Note: this does not happen when we use the RST button on the board.
To fix this, re-implement a platform reset which calls board_usb_cleanup() before resetting the board.
Signed-off-by: Mattijs Korpershoek mkorpershoek@baylibre.com --- arch/arm/mach-meson/board-g12a.c | 14 ++++++++++++++ configs/bananapi-m5_defconfig | 2 ++ configs/beelink-gsking-x_defconfig | 2 ++ configs/beelink-gtking_defconfig | 2 ++ configs/beelink-gtkingpro_defconfig | 2 ++ configs/khadas-vim3_android_ab_defconfig | 2 ++ configs/khadas-vim3_android_defconfig | 2 ++ configs/khadas-vim3_defconfig | 2 ++ configs/khadas-vim3l_android_ab_defconfig | 2 ++ configs/khadas-vim3l_android_defconfig | 2 ++ configs/khadas-vim3l_defconfig | 2 ++ configs/odroid-c4_defconfig | 2 ++ configs/odroid-hc4_defconfig | 2 ++ configs/odroid-n2_defconfig | 2 ++ configs/radxa-zero_defconfig | 2 ++ configs/u200_defconfig | 2 ++ 16 files changed, 44 insertions(+)
diff --git a/arch/arm/mach-meson/board-g12a.c b/arch/arm/mach-meson/board-g12a.c index 2e59eee8f792..df7d1959aa74 100644 --- a/arch/arm/mach-meson/board-g12a.c +++ b/arch/arm/mach-meson/board-g12a.c @@ -17,7 +17,9 @@ #include <asm/io.h> #include <asm/armv8/mmu.h> #include <linux/sizes.h> +#include <linux/psci.h> #include <usb.h> +#include <reset.h> #include <linux/usb/otg.h> #include <asm/arch/usb.h> #include <usb/dwc2_udc.h> @@ -217,3 +219,15 @@ int board_usb_cleanup(int index, enum usb_init_type init) return 0; } #endif + +#if !CONFIG_IS_ENABLED(PSCI_RESET) +void reset_misc(void) +{ + struct udevice *dev; + + board_usb_cleanup(0, USB_INIT_UNKNOWN); + + uclass_get_device_by_name(UCLASS_FIRMWARE, "psci", &dev); + invoke_psci_fn(PSCI_0_2_FN_SYSTEM_RESET, 0, 0, 0); +} +#endif diff --git a/configs/bananapi-m5_defconfig b/configs/bananapi-m5_defconfig index 6ab2d8ef0c44..df4fbb292a61 100644 --- a/configs/bananapi-m5_defconfig +++ b/configs/bananapi-m5_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -9,6 +10,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING="bpi-m5" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/beelink-gsking-x_defconfig b/configs/beelink-gsking-x_defconfig index 2c8c642dcb2d..aa90e49f715e 100644 --- a/configs/beelink-gsking-x_defconfig +++ b/configs/beelink-gsking-x_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="beelink-s922x" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -10,6 +11,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" beelink" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/beelink-gtking_defconfig b/configs/beelink-gtking_defconfig index 9848252e7e95..c5ff7821997e 100644 --- a/configs/beelink-gtking_defconfig +++ b/configs/beelink-gtking_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="beelink-s922x" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -10,6 +11,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" beelink" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/beelink-gtkingpro_defconfig b/configs/beelink-gtkingpro_defconfig index 484e039fe034..2f698a2f5210 100644 --- a/configs/beelink-gtkingpro_defconfig +++ b/configs/beelink-gtkingpro_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="beelink-s922x" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -10,6 +11,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" beelink" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/khadas-vim3_android_ab_defconfig b/configs/khadas-vim3_android_ab_defconfig index f3e9f11a8edf..73916ea3b2db 100644 --- a/configs/khadas-vim3_android_ab_defconfig +++ b/configs/khadas-vim3_android_ab_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="vim3" CONFIG_SYS_CONFIG_NAME="khadas-vim3_android" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -11,6 +12,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" khadas-vim3" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/khadas-vim3_android_defconfig b/configs/khadas-vim3_android_defconfig index f076b6e4e564..fe10741adf89 100644 --- a/configs/khadas-vim3_android_defconfig +++ b/configs/khadas-vim3_android_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="vim3" CONFIG_SYS_CONFIG_NAME="khadas-vim3_android" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -11,6 +12,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" khadas-vim3" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/khadas-vim3_defconfig b/configs/khadas-vim3_defconfig index 0cf4bac809b9..bff664726df9 100644 --- a/configs/khadas-vim3_defconfig +++ b/configs/khadas-vim3_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="vim3" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -10,6 +11,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" khadas-vim3" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/khadas-vim3l_android_ab_defconfig b/configs/khadas-vim3l_android_ab_defconfig index 828ce6dee9dd..66676dca609a 100644 --- a/configs/khadas-vim3l_android_ab_defconfig +++ b/configs/khadas-vim3l_android_ab_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="vim3" CONFIG_SYS_CONFIG_NAME="khadas-vim3l_android" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -11,6 +12,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" khadas-vim3l" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/khadas-vim3l_android_defconfig b/configs/khadas-vim3l_android_defconfig index ee1fa5c31f82..03ccff90e275 100644 --- a/configs/khadas-vim3l_android_defconfig +++ b/configs/khadas-vim3l_android_defconfig @@ -1,6 +1,7 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="vim3" CONFIG_SYS_CONFIG_NAME="khadas-vim3l_android" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -11,6 +12,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" khadas-vim3l" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/khadas-vim3l_defconfig b/configs/khadas-vim3l_defconfig index f1524f562acb..6b26fedd22c2 100644 --- a/configs/khadas-vim3l_defconfig +++ b/configs/khadas-vim3l_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="vim3" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -10,6 +11,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" khadas-vim3l" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/odroid-c4_defconfig b/configs/odroid-c4_defconfig index d244e71866e7..5c2dd96c62b9 100644 --- a/configs/odroid-c4_defconfig +++ b/configs/odroid-c4_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="odroid-n2" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -10,6 +11,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" odroid-c4/hc4" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/odroid-hc4_defconfig b/configs/odroid-hc4_defconfig index fe70d5f12a16..418fc0271ad7 100644 --- a/configs/odroid-hc4_defconfig +++ b/configs/odroid-hc4_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="odroid-n2" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -10,6 +11,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" odroid-hc4" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_AHCI=y diff --git a/configs/odroid-n2_defconfig b/configs/odroid-n2_defconfig index 3703d7e17cee..1d6384817555 100644 --- a/configs/odroid-n2_defconfig +++ b/configs/odroid-n2_defconfig @@ -1,5 +1,6 @@ CONFIG_ARM=y CONFIG_SYS_BOARD="odroid-n2" +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -10,6 +11,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" odroid-n2/n2-plus" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/radxa-zero_defconfig b/configs/radxa-zero_defconfig index d3744f48a31b..a0a0a82a650f 100644 --- a/configs/radxa-zero_defconfig +++ b/configs/radxa-zero_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -9,6 +10,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" radxa-zero" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y diff --git a/configs/u200_defconfig b/configs/u200_defconfig index b4f2f21d7eda..d4eb0123c3d7 100644 --- a/configs/u200_defconfig +++ b/configs/u200_defconfig @@ -1,4 +1,5 @@ CONFIG_ARM=y +CONFIG_ARM_SMCCC=y CONFIG_ARCH_MESON=y CONFIG_SYS_TEXT_BASE=0x01000000 CONFIG_NR_DRAM_BANKS=1 @@ -9,6 +10,7 @@ CONFIG_MESON_G12A=y CONFIG_DEBUG_UART_BASE=0xff803000 CONFIG_DEBUG_UART_CLOCK=24000000 CONFIG_IDENT_STRING=" u200" +# CONFIG_PSCI_RESET is not set CONFIG_SYS_LOAD_ADDR=0x1000000 CONFIG_DEBUG_UART=y CONFIG_HAS_CUSTOM_SYS_INIT_SP_ADDR=y
On 10/7/22 11:38, Mattijs Korpershoek wrote:
On some g12a boards like the VIM3L and the SEI610, with some USB cables/hosts, there is a long (5s) delay before between "fastboot reboot" and the host detecting a USB reset.
This breaks tools relying on "fastboot reboot fastboot" which assume that 1s after the command send, the board should disconnect on usb.
To reproduce, enable fastboot in U-Boot console: => fastboot usb 0
Then, on the host, run: # echo "running fastboot reboot bootloader" > /dev/kmsg && fastboot reboot bootloader Rebooting into bootloader OKAY [ 0.003s] Finished. Total time: 3.033s
[54074.251551] running fastboot reboot bootloader ... there is a delay of 5s before we detect a disconnection ... [54079.041238] usb 1-7.4: USB disconnect, device number 72 [54079.239625] usb 1-7.4: new high-speed USB device number 73 using xhci_hcd [54079.359103] usb 1-7.4: New USB device found, idVendor=1b8e, idProduct=fada, bcdDevice= 2.27 [54079.359110] usb 1-7.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [54079.359112] usb 1-7.4: Product: USB download gadget [54079.359114] usb 1-7.4: Manufacturer: U-Boot [54079.359116] usb 1-7.4: SerialNumber: C8631470CC41
Note: this does not happen when we use the RST button on the board.
To fix this, re-implement a platform reset which calls board_usb_cleanup() before resetting the board.
Shouldn't that call happen somewhere in drivers/usb/ .remove() callback instead ?
Hi,
On 10/10/2022 18:09, Marek Vasut wrote:
On 10/7/22 11:38, Mattijs Korpershoek wrote:
On some g12a boards like the VIM3L and the SEI610, with some USB cables/hosts, there is a long (5s) delay before between "fastboot reboot" and the host detecting a USB reset.
This breaks tools relying on "fastboot reboot fastboot" which assume that 1s after the command send, the board should disconnect on usb.
To reproduce, enable fastboot in U-Boot console: => fastboot usb 0
Then, on the host, run: # echo "running fastboot reboot bootloader" > /dev/kmsg && fastboot reboot bootloader Rebooting into bootloader OKAY [ 0.003s] Finished. Total time: 3.033s
[54074.251551] running fastboot reboot bootloader ... there is a delay of 5s before we detect a disconnection ... [54079.041238] usb 1-7.4: USB disconnect, device number 72 [54079.239625] usb 1-7.4: new high-speed USB device number 73 using xhci_hcd [54079.359103] usb 1-7.4: New USB device found, idVendor=1b8e, idProduct=fada, bcdDevice= 2.27 [54079.359110] usb 1-7.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [54079.359112] usb 1-7.4: Product: USB download gadget [54079.359114] usb 1-7.4: Manufacturer: U-Boot [54079.359116] usb 1-7.4: SerialNumber: C8631470CC41
Note: this does not happen when we use the RST button on the board.
To fix this, re-implement a platform reset which calls board_usb_cleanup() before resetting the board.
Shouldn't that call happen somewhere in drivers/usb/ .remove() callback instead ?
No since dwc2 isn't DM yet, handling is done in arch/arm/mac-meson board_usb_*() for now
Neil
On 10/10/22 18:22, Neil Armstrong wrote:
Hi,
Hi,
On 10/10/2022 18:09, Marek Vasut wrote:
On 10/7/22 11:38, Mattijs Korpershoek wrote:
On some g12a boards like the VIM3L and the SEI610, with some USB cables/hosts, there is a long (5s) delay before between "fastboot reboot" and the host detecting a USB reset.
This breaks tools relying on "fastboot reboot fastboot" which assume that 1s after the command send, the board should disconnect on usb.
To reproduce, enable fastboot in U-Boot console: => fastboot usb 0
Then, on the host, run: # echo "running fastboot reboot bootloader" > /dev/kmsg && fastboot reboot bootloader Rebooting into bootloader OKAY [ 0.003s] Finished. Total time: 3.033s
[54074.251551] running fastboot reboot bootloader ... there is a delay of 5s before we detect a disconnection ... [54079.041238] usb 1-7.4: USB disconnect, device number 72 [54079.239625] usb 1-7.4: new high-speed USB device number 73 using xhci_hcd [54079.359103] usb 1-7.4: New USB device found, idVendor=1b8e, idProduct=fada, bcdDevice= 2.27 [54079.359110] usb 1-7.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [54079.359112] usb 1-7.4: Product: USB download gadget [54079.359114] usb 1-7.4: Manufacturer: U-Boot [54079.359116] usb 1-7.4: SerialNumber: C8631470CC41
Note: this does not happen when we use the RST button on the board.
To fix this, re-implement a platform reset which calls board_usb_cleanup() before resetting the board.
Shouldn't that call happen somewhere in drivers/usb/ .remove() callback instead ?
No since dwc2 isn't DM yet, handling is done in arch/arm/mac-meson board_usb_*() for now
Seems DWC2 is DM:
$ git grep U_BOOT_DRIVER drivers/usb/ | grep dwc2 drivers/usb/gadget/dwc2_udc_otg.c:U_BOOT_DRIVER(dwc2_udc_otg) = { drivers/usb/host/dwc2.c:U_BOOT_DRIVER(usb_dwc2) = {
On 10/10/2022 19:16, Marek Vasut wrote:
On 10/10/22 18:22, Neil Armstrong wrote:
Hi,
Hi,
On 10/10/2022 18:09, Marek Vasut wrote:
On 10/7/22 11:38, Mattijs Korpershoek wrote:
On some g12a boards like the VIM3L and the SEI610, with some USB cables/hosts, there is a long (5s) delay before between "fastboot reboot" and the host detecting a USB reset.
This breaks tools relying on "fastboot reboot fastboot" which assume that 1s after the command send, the board should disconnect on usb.
To reproduce, enable fastboot in U-Boot console: => fastboot usb 0
Then, on the host, run: # echo "running fastboot reboot bootloader" > /dev/kmsg && fastboot reboot bootloader Rebooting into bootloader OKAY [ 0.003s] Finished. Total time: 3.033s
[54074.251551] running fastboot reboot bootloader ... there is a delay of 5s before we detect a disconnection ... [54079.041238] usb 1-7.4: USB disconnect, device number 72 [54079.239625] usb 1-7.4: new high-speed USB device number 73 using xhci_hcd [54079.359103] usb 1-7.4: New USB device found, idVendor=1b8e, idProduct=fada, bcdDevice= 2.27 [54079.359110] usb 1-7.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [54079.359112] usb 1-7.4: Product: USB download gadget [54079.359114] usb 1-7.4: Manufacturer: U-Boot [54079.359116] usb 1-7.4: SerialNumber: C8631470CC41
Note: this does not happen when we use the RST button on the board.
To fix this, re-implement a platform reset which calls board_usb_cleanup() before resetting the board.
Shouldn't that call happen somewhere in drivers/usb/ .remove() callback instead ?
No since dwc2 isn't DM yet, handling is done in arch/arm/mac-meson board_usb_*() for now
Seems DWC2 is DM:
$ git grep U_BOOT_DRIVER drivers/usb/ | grep dwc2 drivers/usb/gadget/dwc2_udc_otg.c:U_BOOT_DRIVER(dwc2_udc_otg) = { drivers/usb/host/dwc2.c:U_BOOT_DRIVER(usb_dwc2) = {
My bad, seems I missed the dwc2 otg DM wagon...
We will need to switch to this now then, thanks,
Neil
On 10/11/22 09:12, neil.armstrong@linaro.org wrote:
On 10/10/2022 19:16, Marek Vasut wrote:
On 10/10/22 18:22, Neil Armstrong wrote:
Hi,
Hi,
On 10/10/2022 18:09, Marek Vasut wrote:
On 10/7/22 11:38, Mattijs Korpershoek wrote:
On some g12a boards like the VIM3L and the SEI610, with some USB cables/hosts, there is a long (5s) delay before between "fastboot reboot" and the host detecting a USB reset.
This breaks tools relying on "fastboot reboot fastboot" which assume that 1s after the command send, the board should disconnect on usb.
To reproduce, enable fastboot in U-Boot console: => fastboot usb 0
Then, on the host, run: # echo "running fastboot reboot bootloader" > /dev/kmsg && fastboot reboot bootloader Rebooting into bootloader OKAY [ 0.003s] Finished. Total time: 3.033s
[54074.251551] running fastboot reboot bootloader ... there is a delay of 5s before we detect a disconnection ... [54079.041238] usb 1-7.4: USB disconnect, device number 72 [54079.239625] usb 1-7.4: new high-speed USB device number 73 using xhci_hcd [54079.359103] usb 1-7.4: New USB device found, idVendor=1b8e, idProduct=fada, bcdDevice= 2.27 [54079.359110] usb 1-7.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [54079.359112] usb 1-7.4: Product: USB download gadget [54079.359114] usb 1-7.4: Manufacturer: U-Boot [54079.359116] usb 1-7.4: SerialNumber: C8631470CC41
Note: this does not happen when we use the RST button on the board.
To fix this, re-implement a platform reset which calls board_usb_cleanup() before resetting the board.
Shouldn't that call happen somewhere in drivers/usb/ .remove() callback instead ?
No since dwc2 isn't DM yet, handling is done in arch/arm/mac-meson board_usb_*() for now
Seems DWC2 is DM:
$ git grep U_BOOT_DRIVER drivers/usb/ | grep dwc2 drivers/usb/gadget/dwc2_udc_otg.c:U_BOOT_DRIVER(dwc2_udc_otg) = { drivers/usb/host/dwc2.c:U_BOOT_DRIVER(usb_dwc2) = {
My bad, seems I missed the dwc2 otg DM wagon...
We will need to switch to this now then, thanks,
Thanks. I picked 1/2 at least, so you can only focus on 2/2 and send just that.
On Tue, Oct 11, 2022 at 17:39, Marek Vasut marex@denx.de wrote:
On 10/11/22 09:12, neil.armstrong@linaro.org wrote:
On 10/10/2022 19:16, Marek Vasut wrote:
On 10/10/22 18:22, Neil Armstrong wrote:
Hi,
Hi,
On 10/10/2022 18:09, Marek Vasut wrote:
On 10/7/22 11:38, Mattijs Korpershoek wrote:
On some g12a boards like the VIM3L and the SEI610, with some USB cables/hosts, there is a long (5s) delay before between "fastboot reboot" and the host detecting a USB reset.
This breaks tools relying on "fastboot reboot fastboot" which assume that 1s after the command send, the board should disconnect on usb.
To reproduce, enable fastboot in U-Boot console: => fastboot usb 0
Then, on the host, run: # echo "running fastboot reboot bootloader" > /dev/kmsg && fastboot reboot bootloader Rebooting into bootloader OKAY [ 0.003s] Finished. Total time: 3.033s
[54074.251551] running fastboot reboot bootloader ... there is a delay of 5s before we detect a disconnection ... [54079.041238] usb 1-7.4: USB disconnect, device number 72 [54079.239625] usb 1-7.4: new high-speed USB device number 73 using xhci_hcd [54079.359103] usb 1-7.4: New USB device found, idVendor=1b8e, idProduct=fada, bcdDevice= 2.27 [54079.359110] usb 1-7.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [54079.359112] usb 1-7.4: Product: USB download gadget [54079.359114] usb 1-7.4: Manufacturer: U-Boot [54079.359116] usb 1-7.4: SerialNumber: C8631470CC41
Note: this does not happen when we use the RST button on the board.
To fix this, re-implement a platform reset which calls board_usb_cleanup() before resetting the board.
Shouldn't that call happen somewhere in drivers/usb/ .remove() callback instead ?
No since dwc2 isn't DM yet, handling is done in arch/arm/mac-meson board_usb_*() for now
Seems DWC2 is DM:
$ git grep U_BOOT_DRIVER drivers/usb/ | grep dwc2 drivers/usb/gadget/dwc2_udc_otg.c:U_BOOT_DRIVER(dwc2_udc_otg) = { drivers/usb/host/dwc2.c:U_BOOT_DRIVER(usb_dwc2) = {
My bad, seems I missed the dwc2 otg DM wagon...
We will need to switch to this now then, thanks,
Thanks. I picked 1/2 at least, so you can only focus on 2/2 and send just that.
Yes, thank you for picking 1/2
Neil, do you want me to look into converting the meson arch which uses DWC2 to DM? I'm not sure I'm confident to do these changes properly but I'm willing to give it a try. If you plan to do it yourself, fine by me. I'll respin 2/2 after that.
On 11/10/2022 18:36, Mattijs Korpershoek wrote:
On Tue, Oct 11, 2022 at 17:39, Marek Vasut marex@denx.de wrote:
On 10/11/22 09:12, neil.armstrong@linaro.org wrote:
On 10/10/2022 19:16, Marek Vasut wrote:
On 10/10/22 18:22, Neil Armstrong wrote:
Hi,
Hi,
On 10/10/2022 18:09, Marek Vasut wrote:
On 10/7/22 11:38, Mattijs Korpershoek wrote: > On some g12a boards like the VIM3L and the SEI610, with some > USB cables/hosts, there is a long (5s) delay before > between "fastboot reboot" and the host detecting a USB reset. > > This breaks tools relying on "fastboot reboot fastboot" which assume > that 1s after the command send, the board should disconnect on usb. > > To reproduce, enable fastboot in U-Boot console: > => fastboot usb 0 > > Then, on the host, run: > # echo "running fastboot reboot bootloader" > /dev/kmsg && > fastboot reboot bootloader > Rebooting into bootloader OKAY [ 0.003s] > Finished. Total time: 3.033s > > [54074.251551] running fastboot reboot bootloader > ... there is a delay of 5s before we detect a disconnection ... > [54079.041238] usb 1-7.4: USB disconnect, device number 72 > [54079.239625] usb 1-7.4: new high-speed USB device number 73 > using xhci_hcd > [54079.359103] usb 1-7.4: New USB device found, idVendor=1b8e, > idProduct=fada, bcdDevice= 2.27 > [54079.359110] usb 1-7.4: New USB device strings: Mfr=1, > Product=2, SerialNumber=3 > [54079.359112] usb 1-7.4: Product: USB download gadget > [54079.359114] usb 1-7.4: Manufacturer: U-Boot > [54079.359116] usb 1-7.4: SerialNumber: C8631470CC41 > > Note: this does not happen when we use the RST button on the board. > > To fix this, re-implement a platform reset which calls > board_usb_cleanup() before resetting the board.
Shouldn't that call happen somewhere in drivers/usb/ .remove() callback instead ?
No since dwc2 isn't DM yet, handling is done in arch/arm/mac-meson board_usb_*() for now
Seems DWC2 is DM:
$ git grep U_BOOT_DRIVER drivers/usb/ | grep dwc2 drivers/usb/gadget/dwc2_udc_otg.c:U_BOOT_DRIVER(dwc2_udc_otg) = { drivers/usb/host/dwc2.c:U_BOOT_DRIVER(usb_dwc2) = {
My bad, seems I missed the dwc2 otg DM wagon...
We will need to switch to this now then, thanks,
Thanks. I picked 1/2 at least, so you can only focus on 2/2 and send just that.
Yes, thank you for picking 1/2
Neil, do you want me to look into converting the meson arch which uses DWC2 to DM? I'm not sure I'm confident to do these changes properly but I'm willing to give it a try. If you plan to do it yourself, fine by me. I'll respin 2/2 after that.
Sure, give a try, if you don't manage I can help!
Neil
On Tue, Oct 11, 2022 at 19:57, neil.armstrong@linaro.org wrote:
On 11/10/2022 18:36, Mattijs Korpershoek wrote:
On Tue, Oct 11, 2022 at 17:39, Marek Vasut marex@denx.de wrote:
On 10/11/22 09:12, neil.armstrong@linaro.org wrote:
On 10/10/2022 19:16, Marek Vasut wrote:
On 10/10/22 18:22, Neil Armstrong wrote:
Hi,
Hi,
On 10/10/2022 18:09, Marek Vasut wrote: > On 10/7/22 11:38, Mattijs Korpershoek wrote: >> On some g12a boards like the VIM3L and the SEI610, with some >> USB cables/hosts, there is a long (5s) delay before >> between "fastboot reboot" and the host detecting a USB reset. >> >> This breaks tools relying on "fastboot reboot fastboot" which assume >> that 1s after the command send, the board should disconnect on usb. >> >> To reproduce, enable fastboot in U-Boot console: >> => fastboot usb 0 >> >> Then, on the host, run: >> # echo "running fastboot reboot bootloader" > /dev/kmsg && >> fastboot reboot bootloader >> Rebooting into bootloader OKAY [ 0.003s] >> Finished. Total time: 3.033s >> >> [54074.251551] running fastboot reboot bootloader >> ... there is a delay of 5s before we detect a disconnection ... >> [54079.041238] usb 1-7.4: USB disconnect, device number 72 >> [54079.239625] usb 1-7.4: new high-speed USB device number 73 >> using xhci_hcd >> [54079.359103] usb 1-7.4: New USB device found, idVendor=1b8e, >> idProduct=fada, bcdDevice= 2.27 >> [54079.359110] usb 1-7.4: New USB device strings: Mfr=1, >> Product=2, SerialNumber=3 >> [54079.359112] usb 1-7.4: Product: USB download gadget >> [54079.359114] usb 1-7.4: Manufacturer: U-Boot >> [54079.359116] usb 1-7.4: SerialNumber: C8631470CC41 >> >> Note: this does not happen when we use the RST button on the board. >> >> To fix this, re-implement a platform reset which calls >> board_usb_cleanup() before resetting the board. > > Shouldn't that call happen somewhere in drivers/usb/ .remove() > callback instead ?
No since dwc2 isn't DM yet, handling is done in arch/arm/mac-meson board_usb_*() for now
Seems DWC2 is DM:
$ git grep U_BOOT_DRIVER drivers/usb/ | grep dwc2 drivers/usb/gadget/dwc2_udc_otg.c:U_BOOT_DRIVER(dwc2_udc_otg) = { drivers/usb/host/dwc2.c:U_BOOT_DRIVER(usb_dwc2) = {
My bad, seems I missed the dwc2 otg DM wagon...
We will need to switch to this now then, thanks,
Thanks. I picked 1/2 at least, so you can only focus on 2/2 and send just that.
Yes, thank you for picking 1/2
Neil, do you want me to look into converting the meson arch which uses DWC2 to DM? I'm not sure I'm confident to do these changes properly but I'm willing to give it a try. If you plan to do it yourself, fine by me. I'll respin 2/2 after that.
Sure, give a try, if you don't manage I can help!
Done here:
https://lore.kernel.org/u-boot/20221024-meson-dm-usb-v1-0-2ab077a503b9@bayli...
Neil
participants (4)
-
Marek Vasut -
Mattijs Korpershoek -
Neil Armstrong -
neil.armstrong＠linaro.org