[U-Boot] [PATCH] axs103: add support of generic OHCI USB 1.1 controller
This commit adds support of USB 1.1 storage media on AXS103 board. For some yet unknown reason USB 2.0 doesn't work on AXS103 board issuing messages like this: ------------------------>8------------------- AXS# usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found ------------------------>8-------------------
As a work-around we're falling back to USB 1.1. Indeed it is much slower but at least USB storage devices are usable on AXS103.
Signed-off-by: Alexey Brodkin abrodkin@synopsys.com Cc: Marek Vasut marex@denx.de Cc: Simon Glass sjg@chromium.org --- arch/arc/dts/axs10x.dts | 6 ++++++ configs/axs103_defconfig | 3 +-- include/configs/axs101.h | 6 ++++++ 3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arc/dts/axs10x.dts b/arch/arc/dts/axs10x.dts index 80e6d6b..391d067 100644 --- a/arch/arc/dts/axs10x.dts +++ b/arch/arc/dts/axs10x.dts @@ -48,4 +48,10 @@ reg = < 0xe0040000 0x100 >; interrupts = < 8 >; }; + + ohci@0xe0060000 { + compatible = "generic-ohci"; + reg = < 0xe0060000 0x100 >; + interrupts = < 8 >; + }; }; diff --git a/configs/axs103_defconfig b/configs/axs103_defconfig index 3c65c83..a208a27 100644 --- a/configs/axs103_defconfig +++ b/configs/axs103_defconfig @@ -21,7 +21,6 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_DM_USB=y -CONFIG_USB_EHCI_HCD=y -CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_STORAGE=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/include/configs/axs101.h b/include/configs/axs101.h index 650d97d..c92cca2 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -105,6 +105,12 @@ #define CONFIG_DW_AUTONEG
/* + * USB 1.1 configuration + */ +#define CONFIG_USB_OHCI_NEW +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 1 + +/* * Commands still not supported in Kconfig */ #define CONFIG_CMD_FAT
On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin wrote:
This commit adds support of USB 1.1 storage media on AXS103 board. For some yet unknown reason USB 2.0 doesn't work on AXS103 board issuing messages like this: ------------------------>8------------------- AXS# usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found ------------------------>8-------------------
Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
As a work-around we're falling back to USB 1.1. Indeed it is much slower but at least USB storage devices are usable on AXS103.
Signed-off-by: Alexey Brodkin abrodkin@synopsys.com Cc: Marek Vasut marex@denx.de Cc: Simon Glass sjg@chromium.org
arch/arc/dts/axs10x.dts | 6 ++++++ configs/axs103_defconfig | 3 +-- include/configs/axs101.h | 6 ++++++ 3 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/arch/arc/dts/axs10x.dts b/arch/arc/dts/axs10x.dts index 80e6d6b..391d067 100644 --- a/arch/arc/dts/axs10x.dts +++ b/arch/arc/dts/axs10x.dts @@ -48,4 +48,10 @@ reg = < 0xe0040000 0x100 >; interrupts = < 8 >; };
- ohci@0xe0060000 {
compatible = "generic-ohci";reg = < 0xe0060000 0x100 >;interrupts = < 8 >;- };
}; diff --git a/configs/axs103_defconfig b/configs/axs103_defconfig index 3c65c83..a208a27 100644 --- a/configs/axs103_defconfig +++ b/configs/axs103_defconfig @@ -21,7 +21,6 @@ CONFIG_ETH_DESIGNWARE=y CONFIG_SYS_NS16550=y CONFIG_USB=y CONFIG_DM_USB=y -CONFIG_USB_EHCI_HCD=y -CONFIG_USB_EHCI_GENERIC=y +CONFIG_USB_OHCI_GENERIC=y CONFIG_USB_STORAGE=y CONFIG_USE_PRIVATE_LIBGCC=y diff --git a/include/configs/axs101.h b/include/configs/axs101.h index 650d97d..c92cca2 100644 --- a/include/configs/axs101.h +++ b/include/configs/axs101.h @@ -105,6 +105,12 @@ #define CONFIG_DW_AUTONEG
/*
- USB 1.1 configuration
- */
+#define CONFIG_USB_OHCI_NEW +#define CONFIG_SYS_USB_OHCI_MAX_ROOT_PORTS 1
+/*
- Commands still not supported in Kconfig
*/ #define CONFIG_CMD_FAT
Hi Marek,
On Wed, 2015-12-16 at 17:52 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin wrote:
This commit adds support of USB 1.1 storage media on AXS103 board. For some yet unknown reason USB 2.0 doesn't work on AXS103 board issuing messages like this: ------------------------>8------------------- AXS# usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found ------------------------>8-------------------
Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
Thanks for that tip but it made no difference to me. I need to look deeper into that problem.
Just a bit of a context here. I'm playing with ARC SP board which consists of 2 parts: [1] Baseboard with all peripherals and their connectors [2] Daughterboard with CPU and DDR
Baseboard is connected to CPU-board via AXI tunnel.
And when CPU-board is the one with ASIC based on ARC770 that runs at 700 MHz I see USB 2.0 working perfectly fine.
But if I use CPU-board that sports FPGA with ARC HS38 CPU running at 75 MHz I see the first asynchronous tarnsaction on US 2.0 never happens.
In particular in ehci_submit_async() after we enable async. schedule setting CMD_ASE command STS_ASS gets set but then token's status stays active forever i.e. following is always true: --------------------->8--------------------- QT_TOKEN_GET_STATUS(token) & QT_TOKEN_STATUS_ACTIVE --------------------->8---------------------
Note USB host controller, phy and usb dongle are exactly the same. And USB 1.1 (OHCI) works perfectly fine at the same time.
Any ideas what could be wrong?
-Alexey
On Wednesday, December 16, 2015 at 08:54:11 PM, Alexey Brodkin wrote:
Hi Marek,
Hi!
On Wed, 2015-12-16 at 17:52 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin wrote:
This commit adds support of USB 1.1 storage media on AXS103 board. For some yet unknown reason USB 2.0 doesn't work on AXS103 board issuing messages like this: ------------------------>8------------------- AXS# usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found ------------------------>8-------------------
Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
Thanks for that tip but it made no difference to me. I need to look deeper into that problem.
I remember seeing that stuff multiple times before, but it might be a different issue. It was usually triggered by some sort of corruption during the transfer. On ARM, that was often caused by cache issues.
Just a bit of a context here. I'm playing with ARC SP board which consists of 2 parts: [1] Baseboard with all peripherals and their connectors [2] Daughterboard with CPU and DDR
Baseboard is connected to CPU-board via AXI tunnel.
And when CPU-board is the one with ASIC based on ARC770 that runs at 700 MHz I see USB 2.0 working perfectly fine.
But if I use CPU-board that sports FPGA with ARC HS38 CPU running at 75 MHz I see the first asynchronous tarnsaction on US 2.0 never happens.
Connect signaltap or chipscope ? :)
In particular in ehci_submit_async() after we enable async. schedule setting CMD_ASE command STS_ASS gets set but then token's status stays active forever i.e. following is always true: --------------------->8--------------------- QT_TOKEN_GET_STATUS(token) & QT_TOKEN_STATUS_ACTIVE --------------------->8---------------------
Note USB host controller, phy and usb dongle are exactly the same. And USB 1.1 (OHCI) works perfectly fine at the same time.
Try adding #define DEBUG at the first line of common/usb.c , so we can get some more debugging info. Also adding the same into common/usb_hub.c helps.
Any ideas what could be wrong?
-Alexey
Best regards, Marek Vasut
Hi Marek,
On Thu, 2015-12-17 at 05:01 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 08:54:11 PM, Alexey Brodkin wrote:
Hi Marek,
Hi!
On Wed, 2015-12-16 at 17:52 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin wrote:
This commit adds support of USB 1.1 storage media on AXS103 board. For some yet unknown reason USB 2.0 doesn't work on AXS103 board issuing messages like this: ------------------------>8------------------- AXS# usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found ------------------------>8-------------------
Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
Thanks for that tip but it made no difference to me. I need to look deeper into that problem.
I remember seeing that stuff multiple times before, but it might be a different issue. It was usually triggered by some sort of corruption during the transfer. On ARM, that was often caused by cache issues.
Believe me I know how much of a grief caches bring so the first thing I do when seeing unexpected behavior I disable caches :)
Just a bit of a context here. I'm playing with ARC SP board which consists of 2 parts: [1] Baseboard with all peripherals and their connectors [2] Daughterboard with CPU and DDR
Baseboard is connected to CPU-board via AXI tunnel.
And when CPU-board is the one with ASIC based on ARC770 that runs at 700 MHz I see USB 2.0 working perfectly fine.
But if I use CPU-board that sports FPGA with ARC HS38 CPU running at 75 MHz I see the first asynchronous tarnsaction on US 2.0 never happens.
Connect signaltap or chipscope ? :)
Well I don't have either of those tools sitting on my desk but if absolutely required I'll do that :)
In particular in ehci_submit_async() after we enable async. schedule setting CMD_ASE command STS_ASS gets set but then token's status stays active forever i.e. following is always true: --------------------->8--------------------- QT_TOKEN_GET_STATUS(token) & QT_TOKEN_STATUS_ACTIVE --------------------->8---------------------
Note USB host controller, phy and usb dongle are exactly the same. And USB 1.1 (OHCI) works perfectly fine at the same time.
Try adding #define DEBUG at the first line of common/usb.c , so we can get some more debugging info. Also adding the same into common/usb_hub.c helps.
Did that and here's my log:
--------------------->8--------------------- starting USB... USB0: ehci_register: dev='ehci@0xe0040000', ctrl=9fd94100, hccr=e0040000, hcor=e0040010, init=0 Register 1111 NbrPorts 1 USB EHCI 1.00 scanning bus 0 for devices... ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe004000 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=5 (0x5), type=0 (0x0), value=1, index=0 USB_REQ_SET_ADDRESS Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=9 (0x9), type=0 (0x0), value=1, index=0 USB_REQ_SET_CONFIGURATION Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=768, index=0 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=769, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=770, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=160 (0xa0), value=0, index=0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=8, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=16, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=4, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=20, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7b100, udev->dev='usb_hub', portnr=1 dev=9fd7b100, pipe=80000083, buffer=9fd7ae00, length=64, req=9fd7ad00 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI timed out on TD - token=0x80008c80 dev=0, usbsts=0x1, p[1]=0x1005, p[2]=0x0 unable to get device descriptor (error=-1) ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=1, index=1 Len is 0 1 USB Device(s) found AXS# --------------------->8---------------------
Makes any sense?
Note in case of ARC770 the log is very similar except the fact that it goes further to successful device detection.
-Alexey
On Thursday, December 17, 2015 at 02:32:26 PM, Alexey Brodkin wrote:
Hi Marek,
On Thu, 2015-12-17 at 05:01 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 08:54:11 PM, Alexey Brodkin wrote:
Hi Marek,
Hi!
On Wed, 2015-12-16 at 17:52 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin wrote:
This commit adds support of USB 1.1 storage media on AXS103 board. For some yet unknown reason USB 2.0 doesn't work on AXS103 board issuing messages like this: ------------------------>8------------------- AXS# usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found ------------------------>8-------------------
Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
Thanks for that tip but it made no difference to me. I need to look deeper into that problem.
I remember seeing that stuff multiple times before, but it might be a different issue. It was usually triggered by some sort of corruption during the transfer. On ARM, that was often caused by cache issues.
Believe me I know how much of a grief caches bring so the first thing I do when seeing unexpected behavior I disable caches :)
Just a bit of a context here.
I'm playing with ARC SP board which consists of 2 parts: [1] Baseboard with all peripherals and their connectors [2] Daughterboard with CPU and DDR
Baseboard is connected to CPU-board via AXI tunnel.
And when CPU-board is the one with ASIC based on ARC770 that runs at 700 MHz I see USB 2.0 working perfectly fine.
But if I use CPU-board that sports FPGA with ARC HS38 CPU running at 75 MHz I see the first asynchronous tarnsaction on US 2.0 never happens.
Connect signaltap or chipscope ? :)
Well I don't have either of those tools sitting on my desk but if absolutely required I'll do that :)
In particular in ehci_submit_async() after we enable async. schedule setting CMD_ASE command STS_ASS gets set but then token's status stays active forever i.e. following is always true: --------------------->8--------------------- QT_TOKEN_GET_STATUS(token) & QT_TOKEN_STATUS_ACTIVE --------------------->8---------------------
Note USB host controller, phy and usb dongle are exactly the same. And USB 1.1 (OHCI) works perfectly fine at the same time.
Try adding #define DEBUG at the first line of common/usb.c , so we can get some more debugging info. Also adding the same into common/usb_hub.c helps.
Did that and here's my log:
--------------------->8--------------------- starting USB... USB0: ehci_register: dev='ehci@0xe0040000', ctrl=9fd94100, hccr=e0040000, hcor=e0040010, init=0 Register 1111 NbrPorts 1 USB EHCI 1.00 scanning bus 0 for devices... ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe004000 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=5 (0x5), type=0 (0x0), value=1, index=0 USB_REQ_SET_ADDRESS Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=9 (0x9), type=0 (0x0), value=1, index=0 USB_REQ_SET_CONFIGURATION Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=768, index=0 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=769, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=770, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=160 (0xa0), value=0, index=0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=8, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=16, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=4, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=20, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7b100, udev->dev='usb_hub', portnr=1 dev=9fd7b100, pipe=80000083, buffer=9fd7ae00, length=64, req=9fd7ad00 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI timed out on TD - token=0x80008c80 dev=0, usbsts=0x1, p[1]=0x1005, p[2]=0x0 unable to get device descriptor (error=-1) ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=1, index=1 Len is 0 1 USB Device(s) found AXS# --------------------->8---------------------
Makes any sense?
Am I reading it correctly that the root hub (the one built into the controller) is misbehaving here ?
Note in case of ARC770 the log is very similar except the fact that it goes further to successful device detection.
-Alexey
Hi Marek,
On Thu, 2015-12-17 at 16:08 +0100, Marek Vasut wrote:
On Thursday, December 17, 2015 at 02:32:26 PM, Alexey Brodkin wrote:
Hi Marek,
On Thu, 2015-12-17 at 05:01 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 08:54:11 PM, Alexey Brodkin wrote:
Hi Marek,
Hi!
On Wed, 2015-12-16 at 17:52 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin wrote:
This commit adds support of USB 1.1 storage media on AXS103 board. For some yet unknown reason USB 2.0 doesn't work on AXS103 board issuing messages like this: ------------------------>8------------------- AXS# usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found ------------------------>8-------------------
Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
Thanks for that tip but it made no difference to me. I need to look deeper into that problem.
I remember seeing that stuff multiple times before, but it might be a different issue. It was usually triggered by some sort of corruption during the transfer. On ARM, that was often caused by cache issues.
Believe me I know how much of a grief caches bring so the first thing I do when seeing unexpected behavior I disable caches :)
Just a bit of a context here.
I'm playing with ARC SP board which consists of 2 parts: [1] Baseboard with all peripherals and their connectors [2] Daughterboard with CPU and DDR
Baseboard is connected to CPU-board via AXI tunnel.
And when CPU-board is the one with ASIC based on ARC770 that runs at 700 MHz I see USB 2.0 working perfectly fine.
But if I use CPU-board that sports FPGA with ARC HS38 CPU running at 75 MHz I see the first asynchronous tarnsaction on US 2.0 never happens.
Connect signaltap or chipscope ? :)
Well I don't have either of those tools sitting on my desk but if absolutely required I'll do that :)
In particular in ehci_submit_async() after we enable async. schedule setting CMD_ASE command STS_ASS gets set but then token's status stays active forever i.e. following is always true: --------------------->8--------------------- QT_TOKEN_GET_STATUS(token) & QT_TOKEN_STATUS_ACTIVE --------------------->8---------------------
Note USB host controller, phy and usb dongle are exactly the same. And USB 1.1 (OHCI) works perfectly fine at the same time.
Try adding #define DEBUG at the first line of common/usb.c , so we can get some more debugging info. Also adding the same into common/usb_hub.c helps.
Did that and here's my log:
--------------------->8--------------------- starting USB... USB0: ehci_register: dev='ehci@0xe0040000', ctrl=9fd94100, hccr=e0040000, hcor=e0040010, init=0 Register 1111 NbrPorts 1 USB EHCI 1.00 scanning bus 0 for devices... ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe004000 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=5 (0x5), type=0 (0x0), value=1, index=0 USB_REQ_SET_ADDRESS Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=9 (0x9), type=0 (0x0), value=1, index=0 USB_REQ_SET_CONFIGURATION Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=768, index=0 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=769, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=770, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=160 (0xa0), value=0, index=0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=8, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=16, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=4, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=20, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7b100, udev->dev='usb_hub', portnr=1 dev=9fd7b100, pipe=80000083, buffer=9fd7ae00, length=64, req=9fd7ad00 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0
Problem happens here. As I wrote earlier active flag of the token gets never reset. All that happens later is just a consequence.
EHCI timed out on TD - token=0x80008c80 dev=0, usbsts=0x1, p[1]=0x1005, p[2]=0x0 unable to get device descriptor (error=-1) ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=1, index=1 Len is 0 1 USB Device(s) found AXS# --------------------->8---------------------
Makes any sense?
Am I reading it correctly that the root hub (the one built into the controller) is misbehaving here ?
Well I'm not an expert in USB so would need to get some explanation from you here.
-Alexey
Hi,
On Thu, 2015-12-17 at 16:08 +0100, Marek Vasut wrote:
On Thursday, December 17, 2015 at 02:32:26 PM, Alexey Brodkin wrote:
Hi Marek,
On Thu, 2015-12-17 at 05:01 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 08:54:11 PM, Alexey Brodkin wrote:
Hi Marek,
Hi!
On Wed, 2015-12-16 at 17:52 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin wrote:
This commit adds support of USB 1.1 storage media on AXS103 board. For some yet unknown reason USB 2.0 doesn't work on AXS103 board issuing messages like this: ------------------------>8------------------- AXS# usb start starting USB... USB0: USB EHCI 1.00 scanning bus 0 for devices... EHCI timed out on TD - token=0x80008c80 unable to get device descriptor (error=-1) 1 USB Device(s) found ------------------------>8-------------------
Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
Thanks for that tip but it made no difference to me. I need to look deeper into that problem.
I remember seeing that stuff multiple times before, but it might be a different issue. It was usually triggered by some sort of corruption during the transfer. On ARM, that was often caused by cache issues.
Believe me I know how much of a grief caches bring so the first thing I do when seeing unexpected behavior I disable caches :)
Just a bit of a context here.
I'm playing with ARC SP board which consists of 2 parts: [1] Baseboard with all peripherals and their connectors [2] Daughterboard with CPU and DDR
Baseboard is connected to CPU-board via AXI tunnel.
And when CPU-board is the one with ASIC based on ARC770 that runs at 700 MHz I see USB 2.0 working perfectly fine.
But if I use CPU-board that sports FPGA with ARC HS38 CPU running at 75 MHz I see the first asynchronous tarnsaction on US 2.0 never happens.
Connect signaltap or chipscope ? :)
Well I don't have either of those tools sitting on my desk but if absolutely required I'll do that :)
In particular in ehci_submit_async() after we enable async. schedule setting CMD_ASE command STS_ASS gets set but then token's status stays active forever i.e. following is always true: --------------------->8--------------------- QT_TOKEN_GET_STATUS(token) & QT_TOKEN_STATUS_ACTIVE --------------------->8---------------------
Note USB host controller, phy and usb dongle are exactly the same. And USB 1.1 (OHCI) works perfectly fine at the same time.
Try adding #define DEBUG at the first line of common/usb.c , so we can get some more debugging info. Also adding the same into common/usb_hub.c helps.
Did that and here's my log:
--------------------->8--------------------- starting USB... USB0: ehci_register: dev='ehci@0xe0040000', ctrl=9fd94100, hccr=e0040000, hcor=e0040010, init=0 Register 1111 NbrPorts 1 USB EHCI 1.00 scanning bus 0 for devices... ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe004000 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=5 (0x5), type=0 (0x0), value=1, index=0 USB_REQ_SET_ADDRESS Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=9 (0x9), type=0 (0x0), value=1, index=0 USB_REQ_SET_CONFIGURATION Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=768, index=0 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=769, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=770, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=160 (0xa0), value=0, index=0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=8, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=16, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=4, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=20, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7b100, udev->dev='usb_hub', portnr=1 dev=9fd7b100, pipe=80000083, buffer=9fd7ae00, length=64, req=9fd7ad00 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI timed out on TD - token=0x80008c80 dev=0, usbsts=0x1, p[1]=0x1005, p[2]=0x0 unable to get device descriptor (error=-1) ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=1, index=1 Len is 0 1 USB Device(s) found AXS# --------------------->8---------------------
Makes any sense?
Am I reading it correctly that the root hub (the one built into the controller) is misbehaving here ?
Note in case of ARC770 the log is very similar except the fact that it goes further to successful device detection.
Applied to u-boot-arc, thanks!
-Alexey
On Monday, December 21, 2015 at 09:34:08 PM, Alexey Brodkin wrote:
Hi,
On Thu, 2015-12-17 at 16:08 +0100, Marek Vasut wrote:
On Thursday, December 17, 2015 at 02:32:26 PM, Alexey Brodkin wrote:
Hi Marek,
On Thu, 2015-12-17 at 05:01 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 08:54:11 PM, Alexey Brodkin wrote:
Hi Marek,
Hi!
On Wed, 2015-12-16 at 17:52 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin
wrote:
> This commit adds support of USB 1.1 storage media on AXS103 > board. For some yet unknown reason USB 2.0 doesn't work on > AXS103 board issuing messages like this: > ------------------------>8------------------- > AXS# usb start > starting USB... > USB0: USB EHCI 1.00 > scanning bus 0 for devices... EHCI timed out on TD - > token=0x80008c80 unable to get device descriptor (error=-1) > 1 USB Device(s) found > ------------------------>8-------------------
Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
Thanks for that tip but it made no difference to me. I need to look deeper into that problem.
I remember seeing that stuff multiple times before, but it might be a different issue. It was usually triggered by some sort of corruption during the transfer. On ARM, that was often caused by cache issues.
Believe me I know how much of a grief caches bring so the first thing I do when seeing unexpected behavior I disable caches :)
Just a bit of a context here.
I'm playing with ARC SP board which consists of 2 parts: [1] Baseboard with all peripherals and their connectors [2] Daughterboard with CPU and DDR
Baseboard is connected to CPU-board via AXI tunnel.
And when CPU-board is the one with ASIC based on ARC770 that runs at 700 MHz I see USB 2.0 working perfectly fine.
But if I use CPU-board that sports FPGA with ARC HS38 CPU running at 75 MHz I see the first asynchronous tarnsaction on US 2.0 never happens.
Connect signaltap or chipscope ? :)
Well I don't have either of those tools sitting on my desk but if absolutely required I'll do that :)
In particular in ehci_submit_async() after we enable async. schedule setting CMD_ASE command STS_ASS gets set but then token's status stays active forever i.e. following is always true: --------------------->8--------------------- QT_TOKEN_GET_STATUS(token) & QT_TOKEN_STATUS_ACTIVE --------------------->8---------------------
Note USB host controller, phy and usb dongle are exactly the same. And USB 1.1 (OHCI) works perfectly fine at the same time.
Try adding #define DEBUG at the first line of common/usb.c , so we can get some more debugging info. Also adding the same into common/usb_hub.c helps.
Did that and here's my log:
--------------------->8--------------------- starting USB... USB0: ehci_register: dev='ehci@0xe0040000', ctrl=9fd94100, hccr=e0040000, hcor=e0040010, init=0 Register 1111 NbrPorts 1 USB EHCI 1.00 scanning bus 0 for devices... ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe004000 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=5 (0x5), type=0 (0x0), value=1, index=0 USB_REQ_SET_ADDRESS Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=9 (0x9), type=0 (0x0), value=1, index=0 USB_REQ_SET_CONFIGURATION Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=768, index=0 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=769, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=770, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=160 (0xa0), value=0, index=0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=8, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=16, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=4, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=20, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7b100, udev->dev='usb_hub', portnr=1 dev=9fd7b100, pipe=80000083, buffer=9fd7ae00, length=64, req=9fd7ad00 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI timed out on TD - token=0x80008c80 dev=0, usbsts=0x1, p[1]=0x1005, p[2]=0x0 unable to get device descriptor (error=-1) ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=1, index=1 Len is 0 1 USB Device(s) found AXS# --------------------->8---------------------
Makes any sense?
Am I reading it correctly that the root hub (the one built into the controller) is misbehaving here ?
Note in case of ARC770 the log is very similar except the fact that it goes further to successful device detection.
Applied to u-boot-arc, thanks!
Uh, sorry I didn't get back to you about this. I am wrestling my own issues with the DWC2 USB core :-/ Looks like it doesn't work with USB3340 LPM-capable PHY (it only starts in FS mode), but works with non-LPM-capable USB3300 PHY and starts in HS mode.
Did you figure your issue out by any chance ?
Hi Marek,
On Mon, 2015-12-21 at 23:18 +0100, Marek Vasut wrote:
On Monday, December 21, 2015 at 09:34:08 PM, Alexey Brodkin wrote:
Hi,
On Thu, 2015-12-17 at 16:08 +0100, Marek Vasut wrote:
On Thursday, December 17, 2015 at 02:32:26 PM, Alexey Brodkin wrote:
Hi Marek,
On Thu, 2015-12-17 at 05:01 +0100, Marek Vasut wrote:
On Wednesday, December 16, 2015 at 08:54:11 PM, Alexey Brodkin wrote:
Hi Marek,
Hi!
On Wed, 2015-12-16 at 17:52 +0100, Marek Vasut wrote: > On Wednesday, December 16, 2015 at 05:05:15 PM, Alexey Brodkin
wrote:
> > This commit adds support of USB 1.1 storage media on AXS103 > > board. For some yet unknown reason USB 2.0 doesn't work on > > AXS103 board issuing messages like this: > > ------------------------>8------------------- > > AXS# usb start > > starting USB... > > USB0: USB EHCI 1.00 > > scanning bus 0 for devices... EHCI timed out on TD - > > token=0x80008c80 unable to get device descriptor (error=-1) > > 1 USB Device(s) found > > ------------------------>8------------------- > > Try defining CONFIG_EHCI_IS_TDI , that _might_ help.
Thanks for that tip but it made no difference to me. I need to look deeper into that problem.
I remember seeing that stuff multiple times before, but it might be a different issue. It was usually triggered by some sort of corruption during the transfer. On ARM, that was often caused by cache issues.
Believe me I know how much of a grief caches bring so the first thing I do when seeing unexpected behavior I disable caches :)
Just a bit of a context here.
I'm playing with ARC SP board which consists of 2 parts: [1] Baseboard with all peripherals and their connectors [2] Daughterboard with CPU and DDR
Baseboard is connected to CPU-board via AXI tunnel.
And when CPU-board is the one with ASIC based on ARC770 that runs at 700 MHz I see USB 2.0 working perfectly fine.
But if I use CPU-board that sports FPGA with ARC HS38 CPU running at 75 MHz I see the first asynchronous tarnsaction on US 2.0 never happens.
Connect signaltap or chipscope ? :)
Well I don't have either of those tools sitting on my desk but if absolutely required I'll do that :)
In particular in ehci_submit_async() after we enable async. schedule setting CMD_ASE command STS_ASS gets set but then token's status stays active forever i.e. following is always true: --------------------->8--------------------- QT_TOKEN_GET_STATUS(token) & QT_TOKEN_STATUS_ACTIVE --------------------->8---------------------
Note USB host controller, phy and usb dongle are exactly the same. And USB 1.1 (OHCI) works perfectly fine at the same time.
Try adding #define DEBUG at the first line of common/usb.c , so we can get some more debugging info. Also adding the same into common/usb_hub.c helps.
Did that and here's my log:
--------------------->8--------------------- starting USB... USB0: ehci_register: dev='ehci@0xe0040000', ctrl=9fd94100, hccr=e0040000, hcor=e0040010, init=0 Register 1111 NbrPorts 1 USB EHCI 1.00 scanning bus 0 for devices... ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe004000 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=5 (0x5), type=0 (0x0), value=1, index=0 USB_REQ_SET_ADDRESS Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=256, index=0 USB_DT_DEVICE request ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=512, index=0 USB_DT_CONFIG config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=9 (0x9), type=0 (0x0), value=1, index=0 USB_REQ_SET_CONFIGURATION Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=768, index=0 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=769, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7c000, udev->dev='ehci@0xe0040000', portnr=0 req=6 (0x6), type=128 (0x80), value=770, index=1 USB_DT_STRING config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=6 (0x6), type=160 (0xa0), value=10496, index=0 USB_DT_HUB config ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=160 (0xa0), value=0, index=0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=8, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=16, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=3 (0x3), type=35 (0x23), value=4, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=0 (0x0), type=163 (0xa3), value=0, index=1 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=20, index=1 Len is 0 ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd7b100, udev->dev='usb_hub', portnr=1 dev=9fd7b100, pipe=80000083, buffer=9fd7ae00, length=64, req=9fd7ad00 req=6 (0x6), type=128 (0x80), value=256 (0x100), index=0 EHCI timed out on TD - token=0x80008c80 dev=0, usbsts=0x1, p[1]=0x1005, p[2]=0x0 unable to get device descriptor (error=-1) ehci_submit_control_msg: dev='ehci@0xe0040000', udev=9fd94380, udev->dev='usb_hub', portnr=0 req=1 (0x1), type=35 (0x23), value=1, index=1 Len is 0 1 USB Device(s) found AXS# --------------------->8---------------------
Makes any sense?
Am I reading it correctly that the root hub (the one built into the controller) is misbehaving here ?
Note in case of ARC770 the log is very similar except the fact that it goes further to successful device detection.
Applied to u-boot-arc, thanks!
Uh, sorry I didn't get back to you about this. I am wrestling my own issues with the DWC2 USB core :-/ Looks like it doesn't work with USB3340 LPM-capable PHY (it only starts in FS mode), but works with non-LPM-capable USB3300 PHY and starts in HS mode.
Did you figure your issue out by any chance ?
No unfortunately I wasn't able to figure out what's wrong there. For now I parked this activity waiting for response from our hardware guys. I spent way too much time on that and basically need to switch to other high-priority things.
If I ever get that problem resolved I'll let you know.
And thanks for your time anyway, that's much appreciated!
-Alexey
On Wednesday, December 23, 2015 at 12:59:28 PM, Alexey Brodkin wrote:
Hi Marek,
Hi! [...]
Am I reading it correctly that the root hub (the one built into the controller) is misbehaving here ?
Note in case of ARC770 the log is very similar except the fact that it goes further to successful device detection.
Applied to u-boot-arc, thanks!
Uh, sorry I didn't get back to you about this. I am wrestling my own issues with the DWC2 USB core :-/ Looks like it doesn't work with USB3340 LPM-capable PHY (it only starts in FS mode), but works with non-LPM-capable USB3300 PHY and starts in HS mode.
Did you figure your issue out by any chance ?
No unfortunately I wasn't able to figure out what's wrong there. For now I parked this activity waiting for response from our hardware guys. I spent way too much time on that and basically need to switch to other high-priority things.
Please let me know what was it, I'd be interested in what went wrong for future reference.
If I ever get that problem resolved I'll let you know.
And thanks for your time anyway, that's much appreciated!
Thanks!
btw can you put me in touch with some guys who work on the DWC2 OTG core? I have a few questions of my own, in particular with regard to the USB3340 PHY, which seems to have issues with the DWC2.
Best regards, Marek Vasut
participants (2)
-
Alexey Brodkin -
Marek Vasut