Re: [U-Boot] - Help with usb3503 hub enumeration
Hi, On Sun, Sep 15, 2013 at 4:55 AM, Suriyan Ramasami suriya...@gmail.com wrote: Hello All and especially Dan Murphy, Reading thru the mailing list Dan seems to have worked on usb3503a + LAN9730 enumeration wrt the OMAP5. Hence, I seek his help and anyone else! This is with regards to an odroid-u2. It is Exynos 4412 prime based. It has a usb3503a hub and also a LAN 9730 - I am guessing pretty much like the omap5. From the clock source and the PMIC perspective I do see that the usb3503a is powered up and gets a REF_CLK. (I can verify this as I can read and write via I2C to the usb3503a and get/set its configuration. Did you also check the basic host operation, if you have any external port coming out of USB2.0 PHY (not HSIC phy) where you can connect a mass storage device or n/w device may be and see if that's getting enumerated. Also, I do have the correct GPIO pins for the INT_N, RESET_N and HUB_CONNECT wrt the usb3503a. So are you doing a proper reset of USB3503 hub using RESET_N line ? Basically what i could see from Linaro's git also and they are doing a pull-down followed by pull-up of RESET_N and HUB_CONNECT gpios when setting up the HSIC phy. Please have a look at following patch if this helps: https://launchpadlibrarian.net/122816176/0001-DRIVERS-USB-Initialize-HSIC-PHYs-and-enable-network-.patch In the platform based ehci-exynos.c I do initialize the the USB_PHY, HSIC_1_PHY and HSIC2_PHY that is present in the Exynos 4412 SoC. These I have copied over from the Linux kernel (which has full usb support and works). Once this is done, I can see that the values for hccr and hcor appear correct as reported by Linux too. Can you attach the patch here which you are using for setting up the required PHY settings. In the first look there's PHY that is to be suspected. When it comes to starting up usb via usb start, I seem to hit the below sequence - with debug on ... The u-boot is quite an older u-boot, but I have ported most of the usb code over from the arndale port over at insignal - which seems to have usb working (they too have a usb3503a but with exynos5) My question is how do I debug this to get it working. Looks like the hcd does not see the usb3503a, am I correct? 8 (Re)start USB... USB: Exynos4412-ehci: init hccr 1258 and hcor 12580010 hc_length 10 Register 1313 NbrPorts 3 USB EHCI 1.00 samsung_gpiolib_4bit_output: base: 11000c60 offset: 5 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 5 value: 0 samsung_gpiolib_4bit_output: base: 11000c60 offset: 0 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 0 value: 0 samsung_gpiolib_4bit_output: base: 11000c60 offset: 4 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 4 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 5 value: 1 Read 32 from USB3503 SP_ILOCK s3c_gpiolib_set: reg: 11000c64 offset: 4 value: 1 Wrote 33 to USB3503_SP_ILOCK samsung_gpiolib_4bit_input: base: 11000c60 offset: 0 scanning bus for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength 25 if 0, ep 0 ##EP epmaxpacketin[1] = 8 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 0xFF Manufacturer u-boot Product EHCI Host Controller SerialNumber Vendor: 0x Product 0x Version 1.0 USB hub found usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x8 3 ports detected individual port power switching standalone hub global over-current protection power on to power good time: 20ms hub controller current requirement: 0mA port 1 is removable port 2 is removable port 3 is removable usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 get_hub_status returned status 1, change 103 local power source is lost (inactive) no over-current condition exists enabling power on all ports usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x2 length 0x0
Re: [U-Boot] - Help with usb3503 hub enumeration
Thanks Vivek for your response!
On Tue, Sep 24, 2013 at 2:10 AM, Vivek Gautam gautamvivek1...@gmail.com wrote:
Hi,
On Sun, Sep 15, 2013 at 4:55 AM, Suriyan Ramasami suriya...@gmail.com wrote:
Hello All and especially Dan Murphy,
Reading thru the mailing list Dan seems to have worked on usb3503a +
LAN9730 enumeration wrt the OMAP5. Hence, I seek his help and anyone else!
This is with regards to an odroid-u2. It is Exynos 4412 prime based. It
has a usb3503a hub and also a LAN 9730 - I am guessing pretty much like the
omap5.
From the clock source and the PMIC perspective I do see that the usb3503a
is powered up and gets a REF_CLK. (I can verify this as I can read and
write via I2C to the usb3503a and get/set its configuration.
Did you also check the basic host operation, if you have any external
port coming out of USB2.0 PHY (not HSIC phy)
where you can connect a mass storage device or n/w device may be and
see if that's getting enumerated.
Also, I do
have the correct GPIO pins for the INT_N, RESET_N and HUB_CONNECT wrt the
usb3503a.
So are you doing a proper reset of USB3503 hub using RESET_N line ?
Basically what i could see from Linaro's git also and they are doing a
pull-down followed by pull-up
of RESET_N and HUB_CONNECT gpios when setting up the HSIC phy.
Yes, I do a proper RESET_N pull_down followed by a pull_up. I can see
that the usb3503a goes into the ref_clk stage etc as the i2c
communication then starts working with the usb3503a. I end it with
raising the HUB_CONNECT so that it moves into the HUB_COMMUNICATION
stage. I can also verify this, as the document says that the i2c
communication will not happen anymore once the hub is in the hub
communication stage. And rightfully so, if I try to read a register
using i2c with the usb3503a (after pull up of hub_connect) I get an
i2c error.
Please have a look at following patch if this helps:
https://launchpadlibrarian.net/122816176/0001-DRIVERS-USB-Initialize-HSIC-PHYs-and-enable-network-.patch
Thank you for the link to this patch.
In the platform based ehci-exynos.c I do initialize the the USB_PHY,
HSIC_1_PHY and HSIC2_PHY that is present in the Exynos 4412 SoC. These I
have copied over from the Linux kernel (which has full usb support and
works). Once this is done, I can see that the values for hccr and hcor
appear correct as reported by Linux too.
Can you attach the patch here which you are using for setting up the
required PHY settings.
In the first look there's PHY that is to be suspected.
I also have debugged ehci-hcd.c to see the failing part, and it
appears that it goes thru the root hub enumeration stage well - as its
present in the hcd itself. Looks like the root hub has 3 ports. port1
and port2 seem to be configured but port 3 is not configured. I am
assuming port 1 is where the LAN9730 is sitting and port 2 is where
the usb 3503a is sitting.
From the scehmatics, I can further see that HSIC0 is connected to
LAN9730 and HSIC1 is connected to the USB3503A. I do not see anything
connected to the USB PHY, or I do not yet understand it fully.
While tracing thru ehci-hcd.c I can see that for root hub enumeration
all the submit_control_msg() are sent to ehci_submit_root() and these
seem to function - port enable, status change, get descriptor etc...
As soon as it does a get descriptor to the device on the port, the
submit_control_msg() calls ehci_submit_async(). This then builds the
QH, qTD structures, and starts the HCD to process async requests
(CMD_ASE). This is where, I have narrowed it down to the hcd getting
into a halt state.
I do not know why it gets halted, as I haven't debugged more. Is it
possible that the phy has not been set correctly, as you mention?
This is the ouput in the enumeration phase that I am referring to that
halts the HCD:
8
New Device 1
usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0
length 0x40
EHCI timed out on TD - token=0x80008c80
8
Also, there is nothing connected to the PHY that I can test basic
operation of the phy as you had mentioned earlier.
This is the code that initializes the phy etc
int ehci_hcd_init(void)
{
u32 phypwr, phyclk, rstcon, a, con, dat, offset, value, pull;
unsigned char i2c_dat;
unsigned val = 0;
unsigned int tmp;
/*
set XuhostOVERCUR to in-active by controlling ET6PUD[15:14]
0x0 : pull-up/down disabled
0x1 : pull-down enabled
0x2 : reserved
0x3 : pull-up enabled
*/
#define ETC6PUD 0x11000228
writel((__raw_readl(ETC6PUD) ~(0x3 14)) | (0x3 14), ETC6PUD);
rstcon = __raw_readl(ETC6PUD);
printf([SURI] - after set - ETC6PUD has value: %x\n, rstcon);
#define S5P_USB_PHY_CONTROL 0x10020704
#define S5P_HSIC_1_PHY_CONTROL 0x10020708
#define S5P_HSIC_2_PHY_CONTROL 0x1002070C
a = 1;
writel(a, S5P_USB_PHY_CONTROL); // This is what gives us the right hcd
a =
[U-Boot] - Help with usb3503 hub enumeration
Hello All and especially Dan Murphy, Reading thru the mailing list Dan seems to have worked on usb3503a + LAN9730 enumeration wrt the OMAP5. Hence, I seek his help and anyone else! This is with regards to an odroid-u2. It is Exynos 4412 prime based. It has a usb3503a hub and also a LAN 9730 - I am guessing pretty much like the omap5. From the clock source and the PMIC perspective I do see that the usb3503a is powered up and gets a REF_CLK. (I can verify this as I can read and write via I2C to the usb3503a and get/set its configuration. Also, I do have the correct GPIO pins for the INT_N, RESET_N and HUB_CONNECT wrt the usb3503a. In the platform based ehci-exynos.c I do initialize the the USB_PHY, HSIC_1_PHY and HSIC2_PHY that is present in the Exynos 4412 SoC. These I have copied over from the Linux kernel (which has full usb support and works). Once this is done, I can see that the values for hccr and hcor appear correct as reported by Linux too. When it comes to starting up usb via usb start, I seem to hit the below sequence - with debug on ... The u-boot is quite an older u-boot, but I have ported most of the usb code over from the arndale port over at insignal - which seems to have usb working (they too have a usb3503a but with exynos5) My question is how do I debug this to get it working. Looks like the hcd does not see the usb3503a, am I correct? 8 (Re)start USB... USB: Exynos4412-ehci: init hccr 1258 and hcor 12580010 hc_length 10 Register 1313 NbrPorts 3 USB EHCI 1.00 samsung_gpiolib_4bit_output: base: 11000c60 offset: 5 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 5 value: 0 samsung_gpiolib_4bit_output: base: 11000c60 offset: 0 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 0 value: 0 samsung_gpiolib_4bit_output: base: 11000c60 offset: 4 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 4 value: 0 s3c_gpiolib_set: reg: 11000c64 offset: 5 value: 1 Read 32 from USB3503 SP_ILOCK s3c_gpiolib_set: reg: 11000c64 offset: 4 value: 1 Wrote 33 to USB3503_SP_ILOCK samsung_gpiolib_4bit_input: base: 11000c60 offset: 0 scanning bus for devices... New Device 0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x40 set address 1 usb_control_msg: request: 0x5, requesttype: 0x0, value 0x1 index 0x0 length 0x0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 length 0x12 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x9 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x200 index 0x0 length 0x19 get_conf_no 0 Result 25, wLength 25 if 0, ep 0 ##EP epmaxpacketin[1] = 8 set configuration 1 usb_control_msg: request: 0x9, requesttype: 0x0, value 0x1 index 0x0 length 0x0 new device strings: Mfr=1, Product=2, SerialNumber=0 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x300 index 0x0 length 0xFF USB device number 1 default language ID 0x1 usb_control_msg: request: 0x6, requesttype: 0x80, value 0x301 index 0x1 length 0xFF usb_control_msg: request: 0x6, requesttype: 0x80, value 0x302 index 0x1 length 0xFF Manufacturer u-boot Product EHCI Host Controller SerialNumber Vendor: 0x Product 0x Version 1.0 USB hub found usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x4 usb_control_msg: request: 0x6, requesttype: 0xA0, value 0x2900 index 0x0 length 0x8 3 ports detected individual port power switching standalone hub global over-current protection power on to power good time: 20ms hub controller current requirement: 0mA port 1 is removable port 2 is removable port 3 is removable usb_control_msg: request: 0x0, requesttype: 0xA0, value 0x0 index 0x0 length 0x4 get_hub_status returned status 1, change 103 local power source is lost (inactive) no over-current condition exists enabling power on all ports usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x2 length 0x0 port 2 returns 0 usb_control_msg: request: 0x1, requesttype: 0x23, value 0x8 index 0x3 length 0x0 The request port(2) is not configured port 3 returns 8000 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 length 0x4 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3 length 0x4 The request port(2) is not configured port 3: get_port_status failed usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x1 length 0x0 port 1 returns 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x2 length 0x0 port 2 returns 0 usb_control_msg: request: 0x3, requesttype: 0x23, value 0x8 index 0x3 length 0x0 The request port(2) is not configured port 3 returns 8000 usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 length 0x4 Port 1 Status 500 Change 0 usb_control_msg: request:
