2010/9/14 Zachary Burke <zachary.burke@xxxxxxxxx>: >> 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. > On a wild hunch (since the Pre uses MUSB, and we had a related issue reported with MUSB a while ago), are you passing the stall=n parameter to the module in the non-working case? If not, could you try with that parameter? - Anand -- 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
