Hi Peter,
thanks for your help. Please see my comments below.
On Sun, 2012-04-08 at 12:47 +0000, Chen Peter-B29397 wrote:
> >
> > trying to establish a USB connection between my PC (host) and an
> > embedded system ARM-MX357 [1] (device), the link gets lost after ~40
> > Pings (g_ethernet) or some ttyG0 stresstest (g_serial).
> >
> > The ARM-MX357 Board is not yet supported by vanilla kernel with a
> > platform specific file. For testing purposes I wrote a minimal platform
> > file, and as far as I can tell everything works apart from a reliable
> > USB-Link. These are the lines to bring up USB:
> >
> > static const struct fsl_usb2_platform_data otg_device_pdata __initconst =
> > {
> > .operating_mode = FSL_USB2_DR_DEVICE,
> > .phy_mode = FSL_USB2_PHY_UTMI,
> > /*
> > .workaround = FLS_USB2_WORKAROUND_ENGCM09152, /*no hardware
> > part :-( */
> > */
> > };
> >
> > imx35_add_fsl_usb2_udc(&otg_device_pdata);
> >
> So, with ENGCM09152, your USB can't work?
I don't know. As I wrote in the next paragraph: As far as I can see the
hardware-fix isn't implemented and maybe this is the cause of this whole
linke-break-down-thing...
> > What bothers me is, the errata sheet [2] of the imx35 showing an
> > implementation error (ENGcm09152): The vusb-pin should be "enhanced" by
> > some resistors and a diode. This claimed hardware-fix isn't implemented
> > on the board (as far as I can see). So maybe this whole link-problem is
> > due to a hardware-bug...
> >
> I have no available hardware on hand, I am not sure if Fabio can help
> you test at freescale 3DS board to see if it exists at freescale's hardware?
>
> > What I wasn't testing is operating_mode = FSL_USB2_DR_HOST (host-mode)
> > because there is only a Mini-B-Port and my USB-Keyboard-Device for
> > example doesn't fit in there. Should I solder an adapter cable for
> > testing?
> >
> Or you need a Micro B(Male)-TO-Standard A(Female) switch cable.
Thanks, I will check that.
>
> > On the PC (host) I was able to sniff by usbmon:
> > At first all is normal, but after a while (~40 Pings vice versa) the
> > embedded system doesn't respond any more. Then, while testing the
> > connection with g_ethernet, the kworker thread eats all remaining cpu
> > time on the embedded board. Furthermore the host loses its usb0 ip
> > address.
> >
> How about works as mass storage?
After some read while write testing I get the trace below.
Unable to handle kernel NULL pointer dereference at virtual address 0000002c
pgd = c0004000
[0000002c] *pgd=00000000
Internal error: Oops: 17 [#1] ARM
Modules linked in: g_mass_storage fsl_usb2_udc
CPU: 0 Not tainted (3.4.0-rc1-00352-ga250237 #181)
PC is at nfs_clear_request_commit+0x8/0x9c
LR is at nfs_updatepage+0x190/0x458
pc : [<c01014d0>] lr : [<c0102c8c>] psr: 60000013
sp : c797dc50 ip : 000006a1 fp : 00001000
r10: c7a951a0 r9 : 00000000 r8 : 00000000
r7 : 00001000 r6 : c74ce5b0 r5 : 00000000 r4 : 00000000
r3 : 00000067 r2 : 0000006a r1 : c63a6220 r0 : 00000000
Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel
Control: 00c5387d Table: 87964008 DAC: 00000017
Process file-storage (pid: 712, stack limit = 0xc797c268)
Stack: (0xc797dc50 to 0xc797e000)
dc40: c051c620 00000000 c74ce5b0 c0102c8c
dc60: c7a419c0 c051c620 00000000 c051c620 00001000 c7a419c0 00000000 00000000
dc80: c02e7b80 00000000 00001000 c00f6c38 00001000 c797c000 c74ce668 00002200
dca0: 00000000 c02e7b80 00000000 c004f508 00001000 00001000 c051c620 c03fb03c
dcc0: 0001d000 00000000 c74ce5b0 c7a419c0 00001000 00000001 c797de98 00000001
dce0: 00002200 00001e00 c03fb03c c051c620 c03fa5dc c74ce5b0 c7a419c0 0001ae00
dd00: 00000000 00000000 c797de50 00004000 c797de98 c0050c80 0001ae00 00000000
dd20: c797de50 00004000 00000000 c04221e0 c04221a0 00000000 00004000 c04221b4
dd40: c797de18 c74ce668 00100100 c0260140 c7919800 00000001 00001c00 ffdff0a8
dd60: c7919800 c01d67cc c797dd68 00004000 c04221a8 00000000 0001ae00 c7a419c0
dd80: c74ce60c c797de18 c797de98 00000001 00000001 c0050d38 c797c000 00000001
dda0: 91827364 c797dda4 c797dda4 c797ddac c797ddac 00000000 c797de3c c74ce5b0
ddc0: 00004000 c797de18 c797de98 0001ae00 00000000 0001ae00 00000001 c00f6844
dde0: 0001ae00 00000000 00000001 c797de18 c797df20 c7a419c0 c797de98 fffffdee
de00: 00000000 0001ae00 00000000 c0079440 0001ae00 00000000 c8804000 c04225a8
de20: 00000000 00000001 ffffffff c7a419c0 00000000 00000000 00000000 00000000
de40: c7a0c820 c7a0c820 00000000 00000000 0001ae00 00000000 00000000 00000000
de60: 00004000 00000000 00004000 c0035048 c608e01c c7a0c820 00000017 c797c000
de80: 00000000 c791c580 c7954de0 c00350ec c7a0c820 c0400758 c7adc000 00004000
dea0: 00004000 c7a419c0 c7adc000 c797df20 0001ae00 04000000 00000000 c0079e64
dec0: c7a419c0 c7adc000 c796f880 bf00e510 c7a95180 00004000 0001ae00 bf00a634
dee0: 000001be 00000000 c797c000 c7adc000 00000000 c797c000 c797df14 00000200
df00: 00021600 00000000 00000000 00006800 04000000 00000000 3636323d c796f8b0
df20: 0001ae00 00000000 c797c000 bf00e510 00000000 bf00e510 c7a95180 00000000
df40: c797c000 c7adc000 bf00e557 bf00d068 bf00ddbc bf00dd9c 00000000 00000000
df60: 00000002 00000000 00000000 bf00e558 bf00e528 c7a0c820 bf00e552 bf00e555
df80: bf00e554 bf00e553 bf00e559 bf00e556 c7a0c820 bf00e5b4 c797dfc4 c02d9c2c
dfa0: 00000000 c7983e20 bf00e510 c797dfd4 bf00bf98 00000000 00000000 00000000
dfc0: 00000000 c0030b88 c000e280 00000000 bf00e510 00000000 c797dfd8 c797dfd8
dfe0: 00000000 c7983e20 c0030b04 c000e280 00000013 c000e280 1a4b1d04 890e0000
[<c01014d0>] (nfs_clear_request_commit+0x8/0x9c) from [<c0102c8c>] (nfs_updatepage+0x190/0x458)
[<c0102c8c>] (nfs_updatepage+0x190/0x458) from [<c00f6c38>] (nfs_write_end+0x22c/0x258)
[<c00f6c38>] (nfs_write_end+0x22c/0x258) from [<c004f508>] (generic_file_buffered_write+0x170/0x270)
[<c004f508>] (generic_file_buffered_write+0x170/0x270) from [<c0050c80>] (__generic_file_aio_write+0x3ec/0x434)
[<c0050c80>] (__generic_file_aio_write+0x3ec/0x434) from [<c0050d38>] (generic_file_aio_write+0x70/0xd8)
[<c0050d38>] (generic_file_aio_write+0x70/0xd8) from [<c00f6844>] (nfs_file_write+0xb4/0x160)
[<c00f6844>] (nfs_file_write+0xb4/0x160) from [<c0079440>] (do_sync_write+0xa0/0xe8)
[<c0079440>] (do_sync_write+0xa0/0xe8) from [<c0079e64>] (vfs_write+0xac/0x134)
[<c0079e64>] (vfs_write+0xac/0x134) from [<bf00a634>] (do_write+0x324/0x420 [g_mass_storage])
[<bf00a634>] (do_write+0x324/0x420 [g_mass_storage]) from [<bf00d068>] (fsg_main_thread+0x10d0/0x1580 [g_mass_storage])
[<bf00d068>] (fsg_main_thread+0x10d0/0x1580 [g_mass_storage]) from [<c0030b88>] (kthread+0x84/0x90)
[<c0030b88>] (kthread+0x84/0x90) from [<c000e280>] (kernel_thread_exit+0x0/0x8)
Code: e5023050 e12fff1e e92d4070 e1a04000 (e590302c)
---[ end trace db4d02d5dfc43370 ]---
>
> > With g_serial the connection lasts a bit longer and the kworker doesn't
> > rise after the lost.
> >
> > On the ARM-MX357, usbmon showed not a thing. Is this because of device
> > mode?
> >
> Yes, usbmon catches USB bus data, which is only for host mode.
>
> > I tested with current kernel git version (3.4 rc1), 3.2 and 2.6.33.
> >
> > Do you have an idea?
> >
> > Thanks for you input,
> > -- Christoph
> >
> > [1] http://www.freescale.com/files/dsp/doc/ref_manual/IMX35RM.pdf
> >
> > [2] Errata: ENGcm09152 Page 25,
> > USB: UTMI_USBPHY VBUS input impedance implementation error
> > http://cache.freescale.com/files/dsp/doc/errata/IMX35CE.pdf
> >
> >
>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
