Enabling HSUSB1 port on OMAP3430 labrador

Enabling HSUSB1 port on OMAP3430 labrador

[Kovacs Peter Tamas]

Dear All,

We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to 
the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).

I have all these USB related kernel config options enabled:
USB_EHCI_HCD
USB_OHCI_HCD
USB_MUSB_HDRC
TWL4030_USB

My guess was that either EHCI or the Inventra should be the one enabling 
that USB port on the OMAP, but no luck.
The external USB port on the MDK works fine with this configuration.

The pin multiplexing configuration in the board file omap3430-labrador.c 
in u-boot also seems to be correct (although the config of USB1_STP 
seems to be strange, but changing that didn't work either).

My assumption is that the ISP1507A does not need support from the 
kernel, as it acts as an ULPI transceiver only, but please correct me on 
this point if wrong.

What happens is that after connecting an USB mouse is that the LED is on 
for a sec, but nothing is written in the kernel log.
We can see that the transceiver is generating a clock signal, but for 
some reason, the STP is constantly high.

I've also tried setting the port to PHY or TLL, but didn't help. I guess 
PHY is the correct setting in this situation, right? 

Note, the ISP1507A is connected to the following pins of the BGA:
HSUSB1_STP (AF10)
HSUSB1_CLK (AE10)
HSUSB1_DIR (AF9)
HSUSB1_NXP (AG9)
HSUSB1_D0 (AF11)
HSUSB1_D1 (AG12)
HSUSB1_D2 (AH12)
HSUSB1_D3 (AH14)
HSUSB1_D4 (AE11)
HSUSB1_D5 (AH9)
HSUSB1_D6 (AF13)
HSUSB1_D7 (AE13)

Any suggestion on making this work is greatly appreciated.

Thanks for your help,
Peter

RE: Enabling HSUSB1 port on OMAP3430 labrador

[Gadiyar, Anand]

Kovacs Peter Tamas wrote:
> Sent: Tuesday, November 24, 2009 8:04 PM
> To: linux-omap@vger.kernel.org
> Subject: Enabling HSUSB1 port on OMAP3430 labrador
> 
> Dear All,
> 
> We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
> To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to 
> the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).
> 
> I have all these USB related kernel config options enabled:
> USB_EHCI_HCD
> USB_OHCI_HCD
> USB_MUSB_HDRC
> TWL4030_USB
> 
> My guess was that either EHCI or the Inventra should be the one enabling 
> that USB port on the OMAP, but no luck.
> The external USB port on the MDK works fine with this configuration.
> 
> The pin multiplexing configuration in the board file omap3430-labrador.c 
> in u-boot also seems to be correct (although the config of USB1_STP 
> seems to be strange, but changing that didn't work either).
> 

HSUSB1 is not supposed to be used with the labrador (do you have a link
to the board schematics with the mods?). HSUSB1 is the EHCI port.

Not sure why the pad conf is done in u-boot for this board, but maybe
it was a copy-paste thing. That being said, if you've got the part
installed correctly, it ought to work.

> My assumption is that the ISP1507A does not need support from the 
> kernel, as it acts as an ULPI transceiver only, but please correct me on 
> this point if wrong.

No support is needed for this part - it's supposed to work transparently.
However there is an errata for this part for use with the input clocking
mode - you need to delay the STP signal a little (to avoid CRC errors).
See the errata doc from NXP.

> 
> What happens is that after connecting an USB mouse is that the LED is on 
> for a sec, but nothing is written in the kernel log.

If it's EHCI, you won't be able to use a USB mouse (it's a low-speed device).
EHCI on OMAP3 supports high-speed only. You'll need to plug in a high-speed
device, or a hub with a built-in transaction translator.

> We can see that the transceiver is generating a clock signal, but for 
> some reason, the STP is constantly high.
> 
> I've also tried setting the port to PHY or TLL, but didn't help. I guess 
> PHY is the correct setting in this situation, right? 

PHY mode is the correct setting for this, yes.

> 
> Note, the ISP1507A is connected to the following pins of the BGA:
> HSUSB1_STP (AF10)
> HSUSB1_CLK (AE10)
> HSUSB1_DIR (AF9)
> HSUSB1_NXP (AG9)
> HSUSB1_D0 (AF11)
> HSUSB1_D1 (AG12)
> HSUSB1_D2 (AH12)
> HSUSB1_D3 (AH14)
> HSUSB1_D4 (AE11)
> HSUSB1_D5 (AH9)
> HSUSB1_D6 (AF13)
> HSUSB1_D7 (AE13)

These are the pads for EHCI. So I suppose that's what you're trying to use.

Note that EHCI on the OMAP3 supports only the input clocking mode. This
might mean you need to check if you've configured the PHY correctly for
this mode. (No XTAL required, OMAP provides the clock to the PHY).
NXP seems to have removed all mention of this mode from their
data sheets, so you might want to check with them.

Also, do you see a 60MHz clock when you probe the HSUSB1_CLK line?


On the 3430 SDP, we use the ISP1504C PHY (same family - very similar
behavior as the 1507). To make it work, we need to hold the PHY in
reset until after the EHCI controller was configured. This could be
done by using the PHY's reset line (early boards had this) or by
using the CHIP_SEL_n line (newer boards).



> 
> Any suggestion on making this work is greatly appreciated.
> 
> Thanks for your help,
> Peter

Regards,
Anand

Re: Enabling HSUSB1 port on OMAP3430 labrador

[Kovacs Peter Tamas]

Dear Anand,

thank you very much for your exhaustive answer and help. Unfortunately 
it seems there is no clock signal coming out of the HSUSB1_CLK line.

>> We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
>> To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to 
>> the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).
>>
>> I have all these USB related kernel config options enabled:
>> USB_EHCI_HCD
>> USB_OHCI_HCD
>> USB_MUSB_HDRC
>> TWL4030_USB
>>
>> My guess was that either EHCI or the Inventra should be the one enabling 
>> that USB port on the OMAP, but no luck.
>> The external USB port on the MDK works fine with this configuration.
>>
>> The pin multiplexing configuration in the board file omap3430-labrador.c 
>> in u-boot also seems to be correct (although the config of USB1_STP 
>> seems to be strange, but changing that didn't work either).
>>     
>
> HSUSB1 is not supposed to be used with the labrador (do you have a link
> to the board schematics with the mods?). HSUSB1 is the EHCI port.
>   
What do you mean not supposed to be used? HSUSB0 goes to the TWL4030 and 
then out of the casing. HSUSB2 goes to the ISP1702, but the pins are not 
wired out on the Logic MDK baseboard so we cannot use that. Thus only 
one possibility remains if we need an extra USB port inside the casing, 
which is HSUSB1.
> Not sure why the pad conf is done in u-boot for this board, but maybe
> it was a copy-paste thing. That being said, if you've got the part
> installed correctly, it ought to work.
>   
Yes, I can also see these pin multiplexing configs in 
arch/arm/mach-omap2/usb-ehci.c.
I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are PHY 
(couldn't find it in menuconfig, but this macro seems to be used in this 
single file).
Still, the clock goes high when powering the board on, and it remains 
there forever.

I recall seeing a TI-specific kernel source in another git repository, 
which had menuconfig options for setting PHY/TLL, maybe the USB code is 
different too?

>> Note, the ISP1507A is connected to the following pins of the BGA:
>> HSUSB1_STP (AF10)
>> HSUSB1_CLK (AE10)
>> HSUSB1_DIR (AF9)
>> HSUSB1_NXP (AG9)
>> HSUSB1_D0 (AF11)
>> HSUSB1_D1 (AG12)
>> HSUSB1_D2 (AH12)
>> HSUSB1_D3 (AH14)
>> HSUSB1_D4 (AE11)
>> HSUSB1_D5 (AH9)
>> HSUSB1_D6 (AF13)
>> HSUSB1_D7 (AE13)
>>     
>
> These are the pads for EHCI. So I suppose that's what you're trying to use.
>   
We suspect there might be a confusion here.
According to the Logic 3430 SOM board schematic, HSUSB1_CLK is AE10 (and 
also ETK_CLK, MMC3_CMD, GPIO_13).
According to the OMAP3430 Multimedia Processor Data Manual version N 
(OMAP3430_ES1.0_POP_DM_V_N.pdf), the AE10 pin can be ETK_CLK, HW_DBG1, 
GPIO_13 and SYS_NDMAREQ1, so it mentions HW_DBG1 as Mode3 instead of USB.
Then, in mach_omap2/usb-ehci.c, I can see  
omap_cfg_reg(Y8_3430_USB1HS_PHY_CLK); Does this mean that Y8 is 
configured as USB? According to the Logic schematic pin Y8 is UART1_RX 
or GPIO_151, but not USB at all.

So far we have used the pins as seen in the Logic schematic for creating 
an extension board with a number of SPI and GPIO signals, and everything 
worked perfectly. Why are the pins described differently?

> Note that EHCI on the OMAP3 supports only the input clocking mode. This
> might mean you need to check if you've configured the PHY correctly for
> this mode. (No XTAL required, OMAP provides the clock to the PHY).
> NXP seems to have removed all mention of this mode from their
> data sheets, so you might want to check with them.
>   
Thanks, this is our fault. The clock pin of the ISP1507 is output only, 
so it seems not to be compatible with the OMAP3430.
The clock pin of the ISP1504 can be configured for I/O, however this 
component is quite difficult to get, but it seems it's necessary.
> Also, do you see a 60MHz clock when you probe the HSUSB1_CLK line?
>   
Unfortunately not. There is a constant high in the CLK line during the 
whole poweron and boot process, no matter if I configure the USB to PHY 
or TLL. We've also tried another Logic OMAP MDK unit and the effect is 
the same.

Could you please suggest what can be the cause of no clock signal (and 
other ULPI signals) appearing at all?

Thanks,
Peter

Re: Enabling HSUSB1 port on OMAP3430 labrador

[Kovacs Peter Tamas]

Dear Anand, All,

>>> We are trying to make the HSUSB1 port on the OMAP3430 work as an USB 
>>> host.
>>> To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected 
>>> to the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).
>>>
>>> I have all these USB related kernel config options enabled:
>>> USB_EHCI_HCD
>>> USB_OHCI_HCD
>>> USB_MUSB_HDRC
>>> TWL4030_USB
>>>
>>> My guess was that either EHCI or the Inventra should be the one 
>>> enabling that USB port on the OMAP, but no luck.
>>> The external USB port on the MDK works fine with this configuration.
>>>
>>> The pin multiplexing configuration in the board file 
>>> omap3430-labrador.c in u-boot also seems to be correct (although the 
>>> config of USB1_STP seems to be strange, but changing that didn't 
>>> work either).  
>> Not sure why the pad conf is done in u-boot for this board, but maybe
>> it was a copy-paste thing. That being said, if you've got the part
>> installed correctly, it ought to work.
>>   
> Yes, I can also see these pin multiplexing configs in 
> arch/arm/mach-omap2/usb-ehci.c.
> I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are 
> PHY (couldn't find it in menuconfig, but this macro seems to be used 
> in this single file).
> Still, the clock goes high when powering the board on, and it remains 
> there forever.
>
> I recall seeing a TI-specific kernel source in another git repository, 
> which had menuconfig options for setting PHY/TLL, maybe the USB code 
> is different too?
After having no clock signal on the HSUSB1_CLK with the kernel pulled 
from from git.kernel.org/linux/kernel/linux-omap-2.6.git, I've tried 
some older ti-2.6.xx kernel branches from 
git.omapzoom.org/repo/omapkernel.git

branch ti-2.6.27-omap3 didn't compile.
branch ti-2.6.26-omap3 kind of works, but the HSUSB1_CLK is still dead.
branch ti-2.6.24-omap3 works, and during booting I can see a clock 
signal on HSUSB1_CLK, and also the STP signal seems to go high and back 
low as expected!

Is it possible that this feature is broken some months ago? I'll go and 
compare the relevant files, but your suggestions on how to make this 
work again in newer kernels are welcome.

Thanks,
Peter

RE: Enabling HSUSB1 port on OMAP3430 labrador

[Gadiyar, Anand]

[-- Attachment #1: Type: text/plain, Size: 6255 bytes --]

Kovacs Peter Tamas wrote:
> 
> Dear Anand,
> 
> thank you very much for your exhaustive answer and help. Unfortunately 
> it seems there is no clock signal coming out of the HSUSB1_CLK line.
> 
> >> We are trying to make the HSUSB1 port on the OMAP3430 work as an USB host.
> >> To do that, an ISP1507A ULPI HighSpeed USB transceiver is connected to 
> >> the HSUSB1pins (HSUSB1_STP, CLK, D-0..D7, DIR, NXT).
> >>
> >> I have all these USB related kernel config options enabled:
> >> USB_EHCI_HCD
> >> USB_OHCI_HCD
> >> USB_MUSB_HDRC
> >> TWL4030_USB
> >>
> >> My guess was that either EHCI or the Inventra should be the one enabling 
> >> that USB port on the OMAP, but no luck.
> >> The external USB port on the MDK works fine with this configuration.
> >>
> >> The pin multiplexing configuration in the board file omap3430-labrador.c 
> >> in u-boot also seems to be correct (although the config of USB1_STP 
> >> seems to be strange, but changing that didn't work either).
> >>     
> >
> > HSUSB1 is not supposed to be used with the labrador (do you have a link
> > to the board schematics with the mods?). HSUSB1 is the EHCI port.
> >   
> What do you mean not supposed to be used? HSUSB0 goes to the TWL4030 and 
> then out of the casing. HSUSB2 goes to the ISP1702, but the pins are not 
> wired out on the Logic MDK baseboard so we cannot use that. Thus only 
> one possibility remains if we need an extra USB port inside the casing, 
> which is HSUSB1.


I meant there was nothing connected to it on the default board.
The pads are possibly brought out to the expansion connector, but
I haven't checked the schematic - so I'm not sure. I don't think
anyone's tried hooking up a transceiver to that port.


> > Not sure why the pad conf is done in u-boot for this board, but maybe
> > it was a copy-paste thing. That being said, if you've got the part
> > installed correctly, it ought to work.
> >   
> Yes, I can also see these pin multiplexing configs in arch/arm/mach-omap2/usb-ehci.c.
> I have defined CONFIG_OMAP_EHCI_PHY_MODE there to make sure they are PHY 
> (couldn't find it in menuconfig, but this macro seems to be used in this single file).
> Still, the clock goes high when powering the board on, and it remains 
> there forever.
> 
> I recall seeing a TI-specific kernel source in another git repository, 
> which had menuconfig options for setting PHY/TLL, maybe the USB code is 
> different too?
> 
> >> Note, the ISP1507A is connected to the following pins of the BGA:
> >> HSUSB1_STP (AF10)
> >> HSUSB1_CLK (AE10)
> >> HSUSB1_DIR (AF9)
> >> HSUSB1_NXP (AG9)
> >> HSUSB1_D0 (AF11)
> >> HSUSB1_D1 (AG12)
> >> HSUSB1_D2 (AH12)
> >> HSUSB1_D3 (AH14)
> >> HSUSB1_D4 (AE11)
> >> HSUSB1_D5 (AH9)
> >> HSUSB1_D6 (AF13)
> >> HSUSB1_D7 (AE13)
> >>     
> >
> > These are the pads for EHCI. So I suppose that's what you're trying to use.
> >   
> We suspect there might be a confusion here.
> According to the Logic 3430 SOM board schematic, HSUSB1_CLK is AE10 (and 
> also ETK_CLK, MMC3_CMD, GPIO_13).
> According to the OMAP3430 Multimedia Processor Data Manual version N 
> (OMAP3430_ES1.0_POP_DM_V_N.pdf), the AE10 pin can be ETK_CLK, HW_DBG1, 

Not sure about this - if it says ES1.0, that's a really old silicon
version. The HSUSB block was not present in that chip and there are
very very few of these chips floating around.

ES2.0 and greater all have this block and all boards in the wild (including
the labrador) should have an ES2 or greater chip.

> GPIO_13 and SYS_NDMAREQ1, so it mentions HW_DBG1 as Mode3 instead of USB.
> Then, in mach_omap2/usb-ehci.c, I can see  
> omap_cfg_reg(Y8_3430_USB1HS_PHY_CLK); Does this mean that Y8 is 
> configured as USB? According to the Logic schematic pin Y8 is UART1_RX 
> or GPIO_151, but not USB at all.

No, this is incorrect. Go with the setting in mach-omap2/mux.c.
All packages have the same pads for HSUSB1 lines, so there should be
no issue with this.

> 
> So far we have used the pins as seen in the Logic schematic for creating 
> an extension board with a number of SPI and GPIO signals, and everything 
> worked perfectly. Why are the pins described differently?
> 
> > Note that EHCI on the OMAP3 supports only the input clocking mode. This
> > might mean you need to check if you've configured the PHY correctly for
> > this mode. (No XTAL required, OMAP provides the clock to the PHY).
> > NXP seems to have removed all mention of this mode from their
> > data sheets, so you might want to check with them.
> >   
> Thanks, this is our fault. The clock pin of the ISP1507 is output only, 
> so it seems not to be compatible with the OMAP3430.
> The clock pin of the ISP1504 can be configured for I/O, however this 
> component is quite difficult to get, but it seems it's necessary.

You might want to take a look at the NXP ISP1703. I believe it's
available now and does officially support the input-clocking mode.
(Disclaimer: I haven't personally used with my OMAP3 SDP , but I was
informed that it works)

Beagleboard and others use the SMSC 332x, but we have issues with
suspend-resume with this PHY. If you're designing fresh, you might
want to try the NXP PHY.


> > Also, do you see a 60MHz clock when you probe the HSUSB1_CLK line?
> >   
> Unfortunately not. There is a constant high in the CLK line during the 
> whole poweron and boot process, no matter if I configure the USB to PHY 
> or TLL. We've also tried another Logic OMAP MDK unit and the effect is 
> the same.
> 
> Could you please suggest what can be the cause of no clock signal (and 
> other ULPI signals) appearing at all?

Depends. DPLL5 not locked maybe? Current linux-omap code should have this
sorted out (other boards work great).

On current linux-omap, all you should need to do is add an
entry in the board file (attached patch should do it, compile
tested only), and enable EHCI in the menuconfig. Now when you
load the ehci module, you should be able to see the 60MHz clock
on HSUSB1_CLK.

Note that the clock won't be enabled until the ehci driver enables the
usb 120 MHz f-clock (which is divided to give out the ULPI clock).

- Anand

[-- Attachment #2: ldp-enable-ehci.patch --]
[-- Type: application/octet-stream, Size: 1078 bytes --]

Enable EHCI on OMAP3 LDP

For-test-only. No sign-off yet.
---
 arch/arm/mach-omap2/board-ldp.c |   12 ++++++++++++
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/arch/arm/mach-omap2/board-ldp.c b/arch/arm/mach-omap2/board-ldp.c
index c062238..1048f4a 100644
--- a/arch/arm/mach-omap2/board-ldp.c
+++ b/arch/arm/mach-omap2/board-ldp.c
@@ -374,6 +374,17 @@ static struct platform_device *ldp_devices[] __initdata = {
 	&ldp_gpio_keys_device,
 };
 
+static struct ehci_hcd_omap_platform_data ehci_pdata __initconst = {
+	.port_mode[0] = EHCI_HCD_OMAP_MODE_PHY,
+	.port_mode[1] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+	.port_mode[2] = EHCI_HCD_OMAP_MODE_UNKNOWN,
+
+	.phy_reset = false,
+	.reset_gpio_port[0] = -EINVAL,
+	.reset_gpio_port[1] = -EINVAL,
+	.reset_gpio_port[2] = -EINVAL,
+};
+
 static void __init omap_ldp_init(void)
 {
 	omap_i2c_init();
@@ -385,6 +396,7 @@ static void __init omap_ldp_init(void)
 	ads7846_dev_init();
 	omap_serial_init();
 	usb_musb_init();
+	usb_ehci_init(&ehci_pdata);
 
 	twl4030_mmc_init(mmc);
 	/* link regulators to MMC adapters */