Hello Dave and the list, Thanks for your reply, which is very helpful to make me concentrate on debugging the code instead of worrying about what I have done wrong. I have made some progress, I think.
A messy patch is attached with some "#if 0" left in case of more debugging is needed. With the patch, g_zero passes the tests that previously failed. I have also tested g_file_storage with Linux and M$ Windows XP, and g_ether with Linux and M$ Windows XP (RNDIS + linux.inf). The patch mainly takes care of the "read without checking if the data is properly written" problem as well as some glitches. I am not sure if the patch is done properly though. What's the standard op for submitting a patch? One note about the patch: with testusb.c's "-t14", using some specific "vary" values, say "7", the test aborts prematurely because the message read back is shorter than expected. Anyone having the same problem? I didn't see anything wrong on the device side, as everything seems to be handled properly. Aside from that, the results of the control and bulk tests are good. I haven't run the tests for 24+ hours as mentioned in the guide though... Please also see below: [Snip] > There's newer code, as I recall; search archives of this list in > the last month or two. I'd expect the newer code would be able to > work on that older kernel. I could not find the one you referred to. So, I decided to work from the version I got. :-) [Snip] > > One more strange thing is that if the debugging messages of > > s3c2410_udc.c are turned on, M$ WinXP will recognize the board as a > > mass storage device, when g_file_storage is used. I can even > > read/write small amount of data to it with extremely bad performance, > > of course. When the messages are turned off, the enumeration will > > succeed, but XP will later claim that there is something wrong with > > the drive. Does this indicate a race condition? > > Another option would be "gremlins", but they're harder to catch. "gremlins" as wicked spirits? :-) [Snip] > I don't know that there's ever been a fully functional one; sometimes > these things take time to solidify, especially when everyone looking > at the problem is a newbie either to Linux or to USB. ;) True. I'm learning though. :-) Cheers, brian -- brian iMaGiNaTiOn iS mOrE iMpOrTaNt tHaN kNoWlEdGe
s3c2410_udc.patch
Description: Binary data
