iMX35 linux UTMI USB?

cancel
Showing results for 
Search instead for 
Did you mean: 

iMX35 linux UTMI USB?

1,188 Views
JoeBuczek
Contributor I

I am working with a customer who has an iMX35 based design running linux 2.6.31. They are wanting to use the (internal) UTMI USB peripheral in a device-only mode, ultimately, but even attempting to configure this port for host mode appears to cause the processor to hang(!).  The following register writes were captured, configuring the peripheral, and the processor hangs instantly upon writing to the 0x0184 (PORTSC1) register:

======> writel( val=0x00000000, regs=0xc487e148 )
Interrupt Enable Register (UOG_USBINTR)
     Disables all device interrupts

======> writel( val=0x00080b02, regs=0xc487e140 )
USB Command Register (UOG_USBCMD)
     Reset

======> writel( val=0x00000003, regs=0xc487e1a8 )
USB Device Mode (UOG_USBMODE)
     Host-only mode

======> writel( val=0x10000000, regs=0xc487e184 )
Port Status & Control (UOG_PORTSC1)
     UTMI/UTMI+
     16-bit UTMI
     Full speed
     PHY clock enabled

We've been over the reference manual pretty thoroughly and have find nothing that would seem to cause this behavior. We have a Freescale 3-stack evaluation board on order to attempt to see if we can get Freescale's own hardware and distribution can be configured such that it demonstrates the UTMI working.

 

The question for the community here is, "Has anyone here gotten the UTMI port working on iMX35 linux?"

 

Thanks in advance,

--Joe

Tags (1)
0 Kudos
8 Replies

640 Views
JoeBuczek
Contributor I

UPDATE: If I write to the PORTSC1 register once, it works, and I can read back what is written. If I write twice to it, the CPU hangs. I have done this from uboot on the i.MX353 and it fails, but the same experiment on the 3stack evaluation board (an i.MX357) does not fail. Here's the sequence:

 

mw.l 0x53ff4184 0x1c000804    <---- this works

mw.l 0x53ff4184 0x1c000804    <---- this HANGS

 

The same sequence typed into uboot on the MX35PDK (iMX357) works just fine. You can write that register over and over and the processor does not hang.

 

Can anyone with a i.MX353 design out there please try these commands in uboot on your board and post the results here? Alternatively, can anyone shed light on why writing the same value to PORTSC1 on an i.MX353 would cause the CPU to hang?

 

Thanks!

0 Kudos

640 Views
ClausStovgaard
Contributor III

Did you ever found a solution?

Cheers Claus

0 Kudos

640 Views
ClausStovgaard
Contributor III

I can recommend to look at RREFEXT also. That the resistor is mounted correct, and its value is inside spec.

0 Kudos

640 Views
mfuzzey
Contributor I

Hi,

I know this is old now but did you ever get this sorted out?

I'm seeing the same issue on a MX53 (with both a 2.6.35 and a 3.1 linaro kernel)

Cheers,

Martin

0 Kudos

640 Views
mfuzzey
Contributor I

Ok, replying to my own post for the benefit of search engines...

The problem turned out to be a hardware error on our custom i.MX53 board - USBOTG_VDAA25 and USB_OTGVDAA33 were being supplied through 200K resistores instead of 1 Ohm resistors hence the USB module was not supplied correctly.

0 Kudos

640 Views
fabio_estevam
NXP Employee
NXP Employee

Please try to select the following option: (taken from mx35_linux.pdf):

 

"CONFIG_UTMI_MXC_OTG—USB OTG pin detect support for UTMI PHY, enable UTMI PHY

for OTG support.

By default, this option is N."

Regards,

Fabio Estevam

0 Kudos

640 Views
JoeBuczek
Contributor I

Thanks very much for your immediate reply, Fabio. We tried the workaround, but no success.

 

The more fundamental issue I see is that simply attempting to write to UOG_PORTSC1 causes the CPU to hang. Period. This appears to me to be a very low level configuration issue, such as an internal clock not being supplied/enabled to the UTMI peripheral cell. Writing to UOG_PORTSC1 consistently hangs the processor, requiring a hard reset.

 

Can anyone suggest a reason for why writing to UOG_PORTSC1 would cause the mx35 processor to hang?

 

Thanks,

--Joe

0 Kudos

640 Views
fabio_estevam
NXP Employee
NXP Employee

Yes, I tested UTMI mode on a MX35PDK board running a mainline kernel (since kernel.org is down you can get it from pengutronix´s git).

 

From arch/arm/mach-imx/mach-mx35_3ds.c:

 

/* OTG config */

static const struct fsl_usb2_platform_data usb_otg_pdata __initconst = {

.operating_mode = FSL_USB2_DR_DEVICE,

.phy_mode = FSL_USB2_PHY_UTMI_WIDE,

.workaround = FLS_USB2_WORKAROUND_ENGCM09152,

 

Regards,

 

Fabio Estevam

0 Kudos