Thanks Vivek for your response! On Tue, Sep 24, 2013 at 2:10 AM, Vivek Gautam <[email protected]> wrote: > Hi, > > > On Sun, Sep 15, 2013 at 4:55 AM, Suriyan Ramasami <[email protected]> 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 = readl(S5P_USB_PHY_CONTROL); printf("[SURI] - after set - read S5P_USB_PHY_CONTROL: %x\n", a); writel(a, S5P_HSIC_1_PHY_CONTROL); a = readl(S5P_HSIC_1_PHY_CONTROL); printf("[SURI] - after set - read S5P_HSIC_1_PHY_CONTROL: %x\n", a); writel(a, S5P_HSIC_2_PHY_CONTROL); a = readl(S5P_HSIC_2_PHY_CONTROL); printf("[SURI] - after set - read S5P_HSIC_2_PHY_CONTROL: %x\n", a); #define EXYNOS4_USB20PHY_CFG 0x1001021C a = 1; writel(a, EXYNOS4_USB20PHY_CFG); #define EXYNOS4_PHYPWR 0x125B0000 #define EXYNOS4_PHYCLK 0x125B0004 #define EXYNOS4_RSTCON 0x125B0008 phyclk = 5; writel(phyclk, EXYNOS4_PHYCLK); /* set to normal of Device */ #define PHY0_NORMAL_MASK (0x39 << 0) phypwr = readl(EXYNOS4_PHYPWR) & ~PHY0_NORMAL_MASK; writel(phypwr, EXYNOS4_PHYPWR); /* set to normal of Host */ phypwr = readl(EXYNOS4_PHYPWR); #define PHY1_STD_NORMAL_MASK (0x7 << 6) #define EXYNOS4X12_HSIC0_NORMAL_MASK (0x7 << 9) #define EXYNOS4X12_HSIC1_NORMAL_MASK (0x7 << 12) phypwr &= ~(PHY1_STD_NORMAL_MASK | EXYNOS4X12_HSIC0_NORMAL_MASK | EXYNOS4X12_HSIC1_NORMAL_MASK); writel(phypwr, EXYNOS4_PHYPWR); /* reset both PHY and Link of Device */ #define PHY0_SWRST_MASK (0x7 << 0) rstcon = readl(EXYNOS4_RSTCON) | PHY0_SWRST_MASK; writel(rstcon, EXYNOS4_RSTCON); udelay(10); rstcon &= ~PHY0_SWRST_MASK; writel(rstcon, EXYNOS4_RSTCON); /* reset both PHY and Link of Host */ #define EXYNOS4X12_HOST_LINK_PORT_SWRST_MASK (0xf << 7) #define EXYNOS4X12_PHY1_SWRST_MASK (0xf << 3) rstcon = readl(EXYNOS4_RSTCON) | EXYNOS4X12_HOST_LINK_PORT_SWRST_MASK | EXYNOS4X12_PHY1_SWRST_MASK; writel(rstcon, EXYNOS4_RSTCON); udelay(10); rstcon &= ~(EXYNOS4X12_HOST_LINK_PORT_SWRST_MASK | EXYNOS4X12_PHY1_SWRST_MASK); writel(rstcon, EXYNOS4_RSTCON); udelay(80); hccr = (struct ehci_hccr *) 0x12580000; hcor = (struct ehci_hcor *)((uint32_t) hccr + HC_LENGTH(ehci_readl(&hccr->cr_capbase))); printf("Exynos4412-ehci: init hccr %x and hcor %x hc_length %x\n", (uint32_t)hccr, (uint32_t)hcor, (uint32_t)HC_LENGTH(ehci_readl(&hccr->cr_capbase))); mdelay(100); /* Here is where I reset the usb3503a */ /* GPX3_5 is NRESET, GPX3_4 is HUB_CONNECT and GPX3_0 is NINT */ /* The above is from the odroid-u2 schematics */ #define GPX3BASE ((void *) (0x11000C60)) /* Start */ gpio_direction_output(GPX3BASE, 5, 0); gpio_set_value(GPX3BASE, 5, 0); mdelay(100); /* RefCLK 24MHz */ gpio_direction_output(GPX3BASE, 0, 0); gpio_set_value(GPX3BASE, 0, 0); mdelay(100); gpio_direction_output(GPX3BASE, 4, 0); gpio_set_value(GPX3BASE, 4, 0); mdelay(100); // RESET pin set to 1 gpio_set_value(GPX3BASE, 5, 1); // Hub Wait RefClk stage mdelay(10); // Hub Configuration stage a = usb3503_read(USB3503_SP_ILOCK, &i2c_dat, (unsigned char) 1); val = i2c_dat; printf("Read %x from USB3503 SP_ILOCK\n", i2c_dat); // Reads 32 which is default // Other i2c can follow here if need be for configuring the usb3503a // Set CONNECT to 1 to move to hub configure phase. gpio_set_value(GPX3BASE, 4, 1); mdelay(10); // Make INT line as input. gpio_direction_input(GPX3BASE, 0); mdelay(10); return 0; } > >> >> 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 12580000 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: 0x0000 Product 0x0000 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 80000000 >> 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 80000000 >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x1 >> length 0x4 >> Port 1 Status 500 Change 0 >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 >> length 0x4 >> Port 2 Status 501 Change 1 >> port 2 connection change >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 >> length 0x4 >> portstatus 501, change 1, 480 Mb/s >> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x10 index 0x2 >> length 0x0 >> hub_port_reset: resetting port 1... >> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 >> length 0x0 >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 >> length 0x4 >> portstatus 503, change 10, 480 Mb/s >> STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 >> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 >> length 0x0 >> New Device 1 >> usb_control_msg: request: 0x6, requesttype: 0x80, value 0x100 index 0x0 >> length 0x40 >> EHCI timed out on TD - token=0x80008c80 >> hub_port_reset: resetting port 1... >> usb_control_msg: request: 0x3, requesttype: 0x23, value 0x4 index 0x2 >> length 0x0 >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x2 >> length 0x4 >> portstatus 503, change 10, 480 Mb/s >> STAT_C_CONNECTION = 0 STAT_CONNECTION = 1 USB_PORT_STAT_ENABLE 1 >> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x14 index 0x2 >> length 0x0 >> set address 2 >> usb_control_msg: request: 0x5, requesttype: 0x0, value 0x2 index 0x0 length >> 0x0 >> EHCI fail timeout STS_ASS set >> >> USB device not accepting new address (error=80000000) >> hub: disabling port 2 >> usb_control_msg: request: 0x1, requesttype: 0x23, value 0x1 index 0x2 >> length 0x0 >> usb_control_msg: request: 0x0, requesttype: 0xA3, value 0x0 index 0x3 >> length 0x4 >> The request port(2) is not configured >> get_port_status failed >> 2 USB Device(s) found >> scan end >> scanning bus for storage devices... 0 Storage Device(s) found >> scanning bus for ethernet devices... [0] IntIdVendor: 1060 >> IntIdProdcut: 60416 IdVendor: 0 IdProduct: 0 >> [1] IntIdVendor: 1060 IntIdProdcut: 38144 IdVendor: 0 IdProduct: 0 >> [0] IntIdVendor: 1060 IntIdProdcut: 60416 IdVendor: 0 IdProduct: 0 >> [1] IntIdVendor: 1060 IntIdProdcut: 38144 IdVendor: 0 IdProduct: 0 >> 0 Ethernet Device(s) found >> ----------------------------------------------------------------- >> >> _______________________________________________ >> U-Boot mailing list >> [email protected] >> http://lists.denx.de/mailman/listinfo/u-boot >> > > > > -- > Best Regards > Vivek _______________________________________________ U-Boot mailing list [email protected] http://lists.denx.de/mailman/listinfo/u-boot
