> I'm assuming that whenever you refer f_mass_storage.c you mean mass storage > gadget (ie. mass_storage.c; a gadget that uses f_mass_storage.c but has no > other composite functions). Sorry but I am playing catch-up on the organization and naming details of the composite and gadget frameworks. All I know is that the USB wrapper module for the Palm Pre directly references f_mass_storage.c for mass storage functionality. My kernel source tree does not contain mass_storage.c but only f_mass_storage.c in drivers/usb/gadget/. > As a matter of fact, Xbox being MS's creation you might want to try > setting the serial. As a simple test, I manually set the serial number to a known working serial but the outcome did not change. To be thorough, after this post, I will match all of the cosmetic differences highlighted in the diff below. > Do you specify a "file" module parameter? Or just leave it as removable? When loading the file_storage module, I do use the "file" parameter to specify which device to map. The stock Palm driver has this hard-coded to /dev/mapper/store-media, so I use the same. Following Alan's advice, I ran usbmon from my linux box against both modules. Using a stopwatch, I measured that ~5 seconds after inserting the file_storage module, the device was detected by the Xbox 360. Unsure of whether I could extrapolate this time to my linux host, I doubled the time and have thus truncated the results of the usbmon to only display the first 10 seconds from the moment the modules were inserted. I have attempted to decipher this data below. As reference and verification for the descriptor fields that follow, the diff for the lsusb -v output is: --- stock-descriptor 2010-09-13 14:51:56.873872616 -0700 +++ gadget-descriptor 2010-09-13 14:52:14.251372244 -0700 @@ -1 +1 @@ -Bus 002 Device 033: ID 0830:8004 Palm, Inc. +Bus 002 Device 032: ID 0525:a4a5 Netchip Technology, Inc. Linux-USB File Storage Gadget @@ -10,2 +10,2 @@ - idVendor 0x0830 Palm, Inc. - idProduct 0x8004 + idVendor 0x0525 Netchip Technology, Inc. + idProduct 0xa4a5 Linux-USB File Storage Gadget @@ -13,3 +13,3 @@ - iManufacturer 1 Palm Inc. - iProduct 2 Pre - iSerial 3 d72a02bfaf893ea97a357098a01c51584beefb10 + iManufacturer 1 Linux 2.6.24-palm-joplin-3430 with musb_hdrc + iProduct 2 File-backed Storage Gadget + iSerial 3 372041756775 @@ -23 +23 @@ - iConfiguration 4 Retail + iConfiguration 4 Self-powered @@ -36 +36 @@ - iInterface 0 + iInterface 5 Mass Storage When submissions and callbacks are identical they are not prefix'd with -/+ --- Stock Driver +++ Gadget Driver To begin, both modules have identical submissions and callbacks when getting port status and setting port features, with exception of the URB Tag and timestamp which I believe can be ignored: ffff88000d365cc0 969903059 S Ci:2:001:0 s a3 00 0000 0001 0004 4 < ffff88000d365cc0 969903089 C Ci:2:001:0 0 4 = 01050100 ffff88000d365cc0 969903107 S Co:2:001:0 s 23 01 0010 0001 0000 0 ffff88000d365cc0 969903111 C Co:2:001:0 0 0 ffff88000d365cc0 969903114 S Ci:2:001:0 s a3 00 0000 0002 0004 4 < ffff88000d365cc0 969903116 C Ci:2:001:0 0 4 = 00010000 ffff88000d365cc0 969903119 S Ci:2:001:0 s a3 00 0000 0003 0004 4 < ffff88000d365cc0 969903121 C Ci:2:001:0 0 4 = 00010000 ffff88000d365cc0 969903124 S Ci:2:001:0 s a3 00 0000 0004 0004 4 < ffff88000d365cc0 969903126 C Ci:2:001:0 0 4 = 00010000 ffff88000d365cc0 969903128 S Ci:2:001:0 s a3 00 0000 0005 0004 4 < ffff88000d365cc0 969903130 C Ci:2:001:0 0 4 = 00010000 ffff88000d365cc0 969903132 S Ci:2:001:0 s a3 00 0000 0006 0004 4 < ffff88000d365cc0 969903134 C Ci:2:001:0 0 4 = 00010000 ffff8800d6ed9780 970013033 S Ii:2:001:1 -115:2048 4 < ffff88000d365cc0 970013077 S Ci:2:001:0 s a3 00 0000 0001 0004 4 < ffff88000d365cc0 970013084 C Ci:2:001:0 0 4 = 01050000 ffff88000d365cc0 970013109 S Co:2:001:0 s 23 03 0004 0001 0000 0 ffff88000d365cc0 970013114 C Co:2:001:0 0 0 ffff88000d365cc0 970073026 S Ci:2:001:0 s a3 00 0000 0001 0004 4 < ffff88000d365cc0 970073253 C Ci:2:001:0 0 4 = 03051000 ffff88000d365cc0 970133031 S Co:2:001:0 s 23 01 0014 0001 0000 0 ffff88000d365cc0 970133041 C Co:2:001:0 0 0 Callbacks starts to change here as we get descriptors, I expected this based on lsusb output. ffff88000d365cc0 970133068 S Ci:2:000:0 s 80 06 0100 0000 0040 64 < - ffff8800c675ee40 288152198 C Ci:2:000:0 0 18 = 12010002 00000040 30080480 16030102 0301 + ffff88000d365cc0 970133371 C Ci:2:000:0 0 18 = 12010002 00000040 2505a5a4 16030102 0301 ffff88000d365cc0 970133397 S Co:2:001:0 s 23 03 0004 0001 0000 0 ffff88000d365cc0 970133402 C Co:2:001:0 0 0 ffff88000d365cc0 970193027 S Ci:2:001:0 s a3 00 0000 0001 0004 4 < ffff88000d365cc0 970193274 C Ci:2:001:0 0 4 = 03051000 ffff88000d365cc0 970253020 S Co:2:001:0 s 23 01 0014 0001 0000 0 ffff88000d365cc0 970253030 C Co:2:001:0 0 0 ffff88000d365cc0 970253037 S Co:2:000:0 s 00 05 0028 0000 0000 0 ffff88000d365cc0 970253224 C Co:2:000:0 0 0 #Get device descriptor ffff88000d365cc0 970283020 S Ci:2:040:0 s 80 06 0100 0000 0012 18 < - ffff8800a1686180 288306299 C Ci:2:035:0 0 18 = 12010002 00000040 30080480 16030102 0301 + ffff88000d365cc0 970284216 C Ci:2:040:0 0 18 = 12010002 00000040 2505a5a4 16030102 0301 #Get config descriptor ffff88000d365cc0 970284246 S Ci:2:040:0 s 80 06 0200 0000 0009 9 < ffff88000d365cc0 970284464 C Ci:2:040:0 0 9 = 09022000 010104c0 fa ffff88000d365cc0 970284486 S Ci:2:040:0 s 80 06 0200 0000 0020 32 < - ffff8800a1686180 288306544 C Ci:2:035:0 0 32 = 09022000 010104c0 fa090400 00020806 50000705 81020002 00070501 02000201 + ffff88000d365cc0 970284838 C Ci:2:040:0 0 32 = 09022000 010104c0 fa090400 00020806 50050705 81020002 00070501 02000201 #Get string descriptors ffff88000d3650c0 970284866 S Ci:2:040:0 s 80 06 0300 0000 00ff 255 < ffff88000d3650c0 970285212 C Ci:2:040:0 0 4 = 04030904 ffff88000d3650c0 970285233 S Ci:2:040:0 s 80 06 0302 0409 00ff 255 < - ffff88008de77f00 288306794 C Ci:2:035:0 0 8 = 08035000 72006500 + ffff88000d3650c0 970285589 C Ci:2:040:0 0 54 = 36034600 69006c00 65002d00 62006100 63006b00 65006400 20005300 74006f00 ffff88000d3650c0 970285611 S Ci:2:040:0 s 80 06 0301 0409 00ff 255 < - ffff88008de77f00 288306919 C Ci:2:035:0 0 20 = 14035000 61006c00 6d002000 49006e00 63002e00 + ffff88000d3650c0 970285963 C Ci:2:040:0 0 90 = 5a034c00 69006e00 75007800 20003200 2e003600 2e003200 34002d00 70006100 ffff88000d3650c0 970285985 S Ci:2:040:0 s 80 06 0303 0409 00ff 255 < ffff88000d3650c0 970286088 C Ci:2:040:0 0 26 = 1a033300 37003200 30003400 31003700 35003600 37003700 3500 #Set configuration 1 ffff88000d365480 970286379 S Co:2:040:0 s 00 09 0001 0000 0000 0 ffff88000d365480 970286839 C Co:2:040:0 0 0 #Get string descriptor ffff88008d4e0e40 970286937 S Ci:2:040:0 s 80 06 0304 0409 00ff 255 < - ffff8800af8fd3c0 288311168 C Ci:2:035:0 0 14 = 0e035200 65007400 61006900 6c00 + ffff88008d4e0e40 970287087 C Ci:2:040:0 0 26 = 1a035300 65006c00 66002d00 70006f00 77006500 72006500 6400 + ffff88008d4e0a80 970287184 S Ci:2:040:0 s 80 06 0305 0409 00ff 255 < + ffff88008d4e0a80 970287337 C Ci:2:040:0 0 26 = 1a034d00 61007300 73002000 53007400 6f007200 61006700 6500 #End device config ffff88008d4e0480 975283034 S Ci:2:040:0 s a1 fe 0000 0000 0001 1 < ffff88008d4e0480 975283306 C Ci:2:040:0 0 1 = 00 This is where bulk traffic starts flowing and where I see the largest divergence between the 2 drivers. It seems that both drivers begin iterating through scsi commands, the biggest difference I see is that from here, the stock driver only has bulk traffic where the gadget driver has a mix of control and bulk traffic. The stock driver data pattern never changes, it seems to endlessly iterate, incrementing the scsi command by 1 for each iteration. There is a singularity in the gadget driver output, it also begins to iterate through scsi commands but when it reaches 0d (which I coincidently can't find in the SCSI documentation) it gets an interesting response: ffff88008d4e0480 975509582 S Bo:2:040:1 -115 31 = 55534243 0d000000 c0000000 8000061a 003f00c0 00000000 00000000 000000 ffff88008d4e0480 975509638 C Bo:2:040:1 0 31 > ffff88002e841d80 975509735 S Bi:2:040:1 -115 192 < ffff88002e841d80 975510019 C Bi:2:040:1 -121 16 = 0f000000 080a0400 ffff0000 ffffffff ffff88008d4e0480 975510064 S Bi:2:040:1 -115 13 < ffff88008d4e0480 975612877 C Bi:2:040:1 -32 0 //Clear halt ffff88008d4e0480 975612910 S Co:2:040:0 s 02 01 0000 0081 0000 0 ffff88008d4e0480 975613245 C Co:2:040:0 0 0 ffff88008d4e0480 975613263 S Bi:2:040:1 -115 13 < The full output for the bulk data can be seen below. Stock driver http://pastebin.com/gLjQXYfb Gadget driver http://pastebin.com/f1ZyDSvZ The differences in configuration of the 2 modules seems cosmetic only, so I believe I need to focus on what is happening with Bo/Bi. I am a little outside of my knowledge area looking at the Bo/Bi data and need to spend some more time studying this area and the mass storage spec. Any comments are welcome. Regards, 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
