| Summary: | [Beagleboard xM] USB doesn't work with 3.10 kernel | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BSPs | Reporter: | Yi Zhao <yi.zhao> | ||||||||||
| Component: | bsps-meta-yocto | Assignee: | Liming Wang <liming.wang> | ||||||||||
| Status: | RESOLVED WONTFIX | QA Contact: | |||||||||||
| Severity: | normal | ||||||||||||
| Priority: | Medium | CC: | bruce.ashfield, dvhart, jukka.rissanen, ke.zou, kec200503, leonzhang0924, megharaj.ag, richard.purdie, sgw, yi.zhao | ||||||||||
| Version: | 1.5 | ||||||||||||
| Target Milestone: | 1.5.1 | ||||||||||||
| Hardware: | Beagleboard | ||||||||||||
| OS: | arm | ||||||||||||
| Whiteboard: | |||||||||||||
| OS type for building Yocto: | --- | Type of Regression: | --- | ||||||||||
| Verified: | Documentation change: | Don't know | |||||||||||
| Attachments: |
|
||||||||||||
|
Description
Yi Zhao
2013-09-17 09:06:03 UTC
Have any more detailed information? log. This usb can work on 1.6 20131119 build. git rev: master/215dab864e7cf74394840621ad0754db593708f1 This issue is fixed in 1.6 M1 and 1.5.1. We can close this bug. Verified it with 1.6 M1 rc1 build and 1.5.1 rc2 build. Tried with master/b908caca1af1d4150eafd3d3001ea19599657270 and the usb was not still working.
All the USB devices and network interface are not detected by the kernel (linux-yocto 3.10.25).
# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Connected USB devices are not seen.
My uEnv.txt file looks like this:
kernel_file=zImage
boot=bootz
dtb_file=zImage-omap3-beagle-xm.dtb
console=ttyO2,115200n8
mmcroot=/dev/mmcblk0p2 rw
mmcrootfstype=ext4 rootwait fixrtc
#loadaddr=0x80008000
#fdtaddr=0x80f80000
loadaddr=0x80200000
fdtaddr=0x80F80000
xyz_load_image=fatload mmc 0:1 ${loadaddr} ${kernel_file}
xyz_load_dtb=fatload mmc 0:1 ${fdtaddr} ${dtb_file}
mmcargs=setenv bootargs console=${console} ${optargs} root=${mmcroot} rootfstype=${mmcrootfstype} ${device_args}
xyz_mmcboot=run xyz_load_image; run xyz_load_dtb; echo Booting from mmc ...
loaduimage=run xyz_mmcboot; run mmcargs; ${boot} ${loadaddr} - ${fdtaddr}
Any idea what is going on here?
Created attachment 1791 [details]
dmesg output from beagleboard xM USB test - OTG port failure
This result was from a late Feb version - poky-7a30f308b071d6f42d673ab848b1d1a9adb5dc4c.
The beagleboard xM OTG port did not function with the poky-7a30f308b071d6f42d673ab848b1d1a9adb5dc4c (late Feb) build. I used an OTG host cable and the same flash drive that was recognized on the other ports. OTG host mode worked in dylan 3.4 kernel baseline. Here's the lsusb output that shows items recognized by the other ports. Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp. Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter Bus 001 Device 004: ID 046d:c408 Logitech, Inc. Marble Mouse (4-button) Bus 001 Device 005: ID 060b:5254 Solid Year Bus 001 Device 006: ID 0b27:0165 Ritek Corp. Please contact me if you can help (e.g. connect me with someone with more USB experience). I have the appropriate hardware and embedded experience but haven't needed to debug USB previously. I can also provide a SciTools Understand project file (with accurate file list and compile settings) if that would help. Created attachment 1816 [details] Small layer providing a fix for this problem I've tested this layer with a Beagleboard xM (rev C), poky 1.5.1 final (kernel 3.10.17), poky 1.6 M3 (kernel 3.10.28), and recent nightly builds (kernels 3.10.32 and 3.10.33). I have not observed any failures (EHCI or OTG). It works if the OTG host cable / hub is attached at power up or after power up. Trivial updates were made to a patch I found at: https://lkml.org/lkml/2013/7/26/88 I made the other small patch and confirmed that the most recent phy-twl4030-usb.c uses similar processing so I hope that this problem is also fixed in more recent Linux kernels. I forgot to mention that my test results did not use the dtb files. Making the Beagleboard xM work with dtb files is worthy of a problem report specific to that topic.
cat /proc/cmdline
console=tty0 console=ttyO2,115200n8 debug consoleblank=0 mpurate=auto buddy=none camera=none vram=16M omapfb.mode=dvi:hd720 omapfb.vram=0:8M,1:4M,2:4M omapdss.def_disp=dvi root=/dev/mmcblk0p3 rw rootfstype=ext3 rootwait
I believe I used the uEnv.txt below for the 1.6 M3 build:
bootfile=zImage
console=tty0 console=ttyO2,115200n8
dvimode=hd720 omapfb.vram=0:8M,1:4M,2:4M
mmcroot=/dev/mmcblk0p2 rw
mpurate=auto
optargs=debug consoleblank=0
uenvcmd=echo Booting ${bootfile} from mmc ...; fatload mmc ${mmcdev} ${loadaddr} ${bootfile}; run mmcargs; bootz ${loadaddr}
vram=16M
Even though we are moving away from the beagleboard, I had a look at the fixes for completeness sake. I couldn't apply this directly, since the patch headers need a Sign off and references to the upstream commit ID that is the source for the changes. If you make those changes, I can apply the patches. As for the configuration, it is enabling eth and disabling mass storage. For the mass storage, that is problematic since we do want it to work. Are you saying that it cannot work .. or that you weren't using the USB port, so you disabled the config ? Created attachment 1849 [details]
Updated fix for USB problem remaining in 1.6
This version of my USB OTG fix is not derived from other upstream patches so I do not reference upstream commit IDs. Because you were concerned about configuration changes I eliminated that portion of the fix. This version of the fix is much smaller and I have signed off.
Further reading is optional but may be useful if you want answers to your earlier questions.
The prior version of the USB OTG fix layer re-used (except for minor updates to match the Yocto 3.10 baseline) a change proposed by Kishon Vijay Abraham I. I created the smaller modification to phy-twl4030-usb.c. As far as I can tell, the change proposed by Kishon Vijay Abraham I was never included in a released Linux kernel even though it eliminated one of the problems in the current 3.10 baseline.
I replaced the Kishon Vijay Abraham I larger fix with a much smaller fix to eliminate the problem for Beagleboard xM. My other small fix remains with some added comments.
The USB OTG host mode feature only works in the current baseline if the "musb->gadget_driver = driver;" assignment statement in musb_gadget_start() is executed. The assignment statement is executed if CONFIG_USB_ETH or CONFIG_USB_ZERO (perhaps others) is enabled. The prior poky 1.5.1 baseline had specified CONFIG_USB_ETH and I haven't seen CONFIG_MASS_STORAGE work so I didn't worry about that configuration change.
Created attachment 1850 [details]
dmesg output associated with prior attachment
This is the dmesg output when I run my most recently provided USB OTG fix without configuration changes (except for CONFIG_PANEL_TFP410=y to eliminate omapfb problem).
In 1.6/master we're using beaglebone now and work is ramping down on the 3.10 kernel. If patches are proposed I'm sure Bruce will consider them but other than that this is now unlikely to get fixed. HI Kevin Cribbs, I have tried both Small layer providing a fix for this problem and Updated fix for USB problem remaining in 1.6 for linux kernel 3.10.17 . But the problem has not been solved. I am still getting the error, I am pasting the log below. I am using beagleboard-dora-10.0.0 for beagleboard. ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver ehci-omap: OMAP-EHCI Host Controller driver ehci-omap ehci-omap.0: Can't get PHY device for port 1: -6 usbcore: registered new interface driver usb-storage musb-hdrc musb-hdrc.0.auto: musb_init_controller failed with status -6 mousedev: PS/2 mouse device common for all mice Some say after removing the device tree everything worked fine, but that not the case with me. Please let me know, what can be possible. Since we want 3.10 kernel only, I guess it is fixed in the higher kernel but we want 3.10. Please point where I must look into. Please see the previous comment I made, this is not something we have any plans to fix. Thank you for the replay. Ha . I am still working on it, if at all I get any solution I will try my best to provide the patch. It is working in 3.8 and 3.14 I am taking those kernels to analyze the issue. But I am facing problem so as to where I am supposed to look into. Anyway thanks for you time. Hope I will fix this :( . |