This may be a lengthy post, before I get into details, I will pose my question: Q. What tools can I use to determine why a closed host cannot see a linux-based mass storage peripheral that is implemented with f_mass_storage.c? BACKGROUND: I am attempting to use the Palm Pre (WebOS) phone as a mass storage device for the Xbox 360. Like Android-based devices, WebOS uses f_mass_storage.c (based on file_storage.c) to implement mass storage functionality using the bulk-only transport protocol. The Xbox 360 is a closed device - no access to logs, drivers, etc. The Palm Pre is open with full access to the kernel/module source. WHAT WORKS/WHAT DOESN'T: When I use f_mass_storage.c, the Xbox does not see the device. When I use file_storage.c, the Xbox can see and use the device. WHERE I'VE BEEN: Product/Vendor id - Thinking that perhaps the Xbox was blocking based on these, I found a working USB storage device and made the Palm Pre look identical to it. This is not the issue. usbmon - I have snooped traffic on the Palm Pre while using both f_mass_storage.c and file_storage.c, the results are identical both for the control requests and the return values. In the interest of verbosity, I will omit these results, if you are interested they can be seen here: http://mobilecoder.wordpress.com/2010/09/12/using-the-palm-pre-as-xbox-360-storage-part-2/ Intel USB Command Verifier - I ran the Chapter 9 tests as well as the Mass Storage tests against both drivers. The Chapter 9 test results were identical (All Passed), but the following Mass Storage tests contained warnings for f_mass_storage: Serial Number Test - Invalid characters in Serial Number Test Case 4,8 - No stall after zero-length data Command Set Test - No stall after zero-length data Power-Up Test - Could not find device after enumeration Following up on these, I ran the same tests against USB mass storage devices that work with the Xbox 360. Two of these working devices contained invalid characters in the serial number, so I believe this warning can be safely ignored. I am unsure what to make of the complaint about stalling after zero-length data, I am guessing it may be due to the omission of halt_bulk_in_endpoint() in f_mass_storage.c. I do not know what the implications of this omission are. If you do, please enlighten me. The Power-Up Test warning, I believe is due to the fact that it takes several seconds after insertion of the USB connector to put the device into mass storage mode. Again, I believe this can be safely ignored. dmesg - I looked for printk statements but found nothing of interest. NEXT STEPS: Short of continuing to compare the differences between f_mass_storage.c and file_storage.c, I am unsure of further diagnostics or data that I can collect. I will most likely litter both files with printk statements so that I can trace the execution path. If there is anyone familiar with these two modules that might know why one works while the other does not, I am eager to hear why. Recommendations for tools and documents for further study are also greatly appreciated. When abstracted, this is a very generic problem and I believe the process required to solve it would benefit all. Regards and thank you for your time, Zach -- 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
