Before a more detailed reply let me give some explanations first, which applies to several of your points below:
All members of the EZ-USB family (i.e. AN21xx, FX and FX2) come with a default device identity (descriptor set) and a full default implementation of the EP0 standard requests. For many simple applications like the usbtest firmware this is basically all you need besides the real functional work. Note, a correct implementation of all the EP standard request isn't just a few more lines of code - it would be much more than all the functional testing features we are discussing so far. Hence, whenever possible I'd like to use the default device implementation coming with the ez-usb controller. Having this said there is an important consequence: using the default EP0 is an all-or-nothing decision. This means there is no way to use it but f.e. with some changes to the descriptors - or with some vendor-specific request added for EP0. Every such requirement would mean we have to provide our own full implementation of the whole EP0 thing - not only the few things we would like to change. Maybe we want to have our own EP0 implementation for test firmware later, but for a starting it's much easier to live with the default usbcore than to create a _correct_ implementation of all the EP0 standard requests - been there ;-) On Thu, 3 Oct 2002, David Brownell wrote: > > Yes, think so. For the FX it's not much more than modifying some > > of my existing stuff here. I believe I could easily change this to work > > with both 2131 and FX. FX2 would be a different story. I think it > > shouldn't be too hard to write it from scratch based on the TRM docs, but > > I don't have access to a FX2-SDK for testing. > > Thanks to Cypress, I do. Cypress has some code -- 'a3load' at least -- that IIRC the a3load is meant to load stuff into external memory, right? Yes, I believe something like this could be made working with all EZUSB only needing to be compiled against the corresponding register mapping. But as soon as this should implement some functionality on EP>0 it has the deal with the different endpoint setup and control status bits for the FX2 compared to FX/AN21xx. Anyway, it's using a vendor specific 0xa3-request on EP0 - see above! > runs on all three microcontrollers, and if we keep the logic simple we could > do the same thing. We'd likely just need a couple non-control endpoints per > device, and to the extent that handling an IRQ is just priming a pump, it's > not unreasonable to have both FX/an21xx and FX2 versions Yes. This is what I was meaning. Basically some firmware library with the common subroutines (like copying some bytes from here to there) and separate frameworks to integrate this with FX/AN21xx and different FX2 interfaces to the EP's. > > Wrt. to sourcing data, IMHO the following would be useful options: > > - 32 bit packet counter, current value transmitted in first 4 bytes of > > every packet > > - payload set to all-0 or all-1 to cover best/worst case bit stuffing > > It's easy to see what the host would do with an error (report/fail), but > it's less clear to me what a device would do if it notices a "skipped" > packet, or a byte with the wrong value. Maybe just halt the endpoint. IMHO this is completely up to the protocol you are running over the EP. Without this, the firmware has no idea how to notice a packet was skipped. I mean, if one packet (say OUT) with len follows another one there's nothing that tells you there was something in betwee - _if_ the toggles are right. If they aren't, the usual procedure applies... Note there is nothing like an urb or IRP on the device side. It is only seeing a sequence of packets with the toggles protecting just the order on the USB (and the CRC protecting the payload) - but if either host or device does bogus translation between urb and packets it's up to the protocol to recover. > > - always send max packet size (64 byte for FS), continous data stream > > Eventually we'd want to test all maxpacket sizes, but that sort of > stuff can IMO wait for a while. After all, we're running into problems > with urb queueing even before we start to look at the data ... :) Good point. But unfortunately this means we have to provide our own descriptors - thus we need to implement the whole EP0 thing - see above. > > - sending occasional short packages (1...63) at random > > - sending max size packets, but with a zero packet inserted at some rate > > Not at random ... at most, according to some pseudo-random sequence known > in advance to both host and device. They should know in advance what packet > will be coming. I was thinking about putting the actual length in the first byte... > We'll need to test short packet I/O ... so something as simple as a data > stream option to make the packet sizes go MAX, MAX-1, ... 2, 1, 0 would > be enough to test with. (Instead of a default that sends only MAX.) ... but you are right: it's sufficient and easier if we just send a defined sequence of lengths like this. > > - sending usb (micro-)frame number as packet payload so the host could > > measure latencies > > - use another OUT ep so the host could request a sudden functional STALL > > on the source ep. > > I'm not sure what you mean about microframes, those are only for high speed. Idea is to let the firmware use the frame counter as timestamp to indicate when the IN packet was sourced. The host has the same synchronized timebase making it easy to measure latencies. The AN21xx/FX both have a register to read the frame counter as seen by the last SOF token. IIRC the FX2 has an additional register to read the microframe number which would provide better resolution for HS. > As for requesting faults (like endpoint halts), I had thought those would > be done with control requests. Yes, basically there are the Set/Clear_Feature:STALL requests to do this. For the EZ-USB family these are be handled by the default usbcore - but: there are some further requirements in addition to just set/clear the ep-halted flag. Namely the toggles have to be reset and the EP needs to be rearmed. This can not be done by the usbcore, since it doesn't know which data should be submitted for an IN EP after clearing the stall f.e. If we want correct set/clear stall behavior triggered by the corresponding EP0 request we need our own EP0 implementation - see above. OTOH it's pretty easy to trigger the ep to halt using a dedicated ep!=0 and have it also preparing the target-ep to go on with the default USBcore ClearFeature:STALL later. > If for no other reason than to conserve the > use of endpoints ... the EZ-USB controllers have more than most, and it'd > be handy if people can use devices like SA-1100 based PDAs for testing. > So we shouldn't design the test protocol to rely on extra endpoints. Ok, this is an important point. I'd suggest to start with the EZUSB and the easy way using some dedicated ep-command. If we have our own EP0 implementation the same thing could just be called from EP0-SetFeature request. > >>And loopback is needed too. I'd like to see a loopback that buffers more > >>than a single packet, so the read side and write side of "loopback and check > >>data" style tests would have the opportunity to get out of sync. > > > > > > My loopback has the IN and OUT ep's both double buffered (2x64 byte, so > > the device doesn't need to NAK while the firmware processes the data) and > > a 2KB ringbuffer, i.e. the data stream is: > > > > USB OUT -> flip buffer -> ringbuffer -> flip buffer -> USB IN > > > > The whole thing is interrupt driven and the transfers between flip buffers > > and the ringbuffer is done via DMA. As long as the host keeps the reads > > and writes nearly balanced you'll never get a NAK from the device. I've > > measured 1.19e6 bytes/sec sustained throughput with usb-ohci and queueing. > > Well, that sounds exactly like what I want to know works for _all_ host > controllers!! But I'd make sure the host unbalances the reads and writes, > in some test modes, to make sure interesting behaviors get triggered! IMHO the easiest way to do so would be two chardev's in userland, one connected to the IN the other one to the OUT queue. Just start dd'ing stuff from/to these dev and then: use different blocksize, ^Z the reader or writer, different scheduling priorities, put some VM pressure, concurrent high interrupt load (ping -f over 100Tx link turned out to be a good test case). In general, I'm wondering whether it wouldn't be better not to have the testcases implemented in the driver module. Just forwarding the raw datastream to some chardev with ioctl might be an alternative - and people could write testcases in userland. > > I doubt there could be any useful firmware made working with both FX and > > FX2 because _all_ functional registers and endpoint buffers buffers have > > changed location. > > See above. The simpler we keep the test firmware, the easier this is to > achieve. Sure the autovector tables need switching, and FX2 needs to be > able to toggle between high speed and low speed mode ... but a "fill that > buffer" routine can use (auto)pointer + size, leaving not a lot of setup > that needs to be chip-specific. (I'd expect so, anyway.) And keeping For the fill or copy thing - yes, sure. That's the easy part. Few subroutines, working on all EZUSB, only a few bytes. The more difficult part is the specific EP handling. We'll see... > the behavior simple will make it easier for other devices (not EZ-USB) to > be used in testing. > > > > And if you think about running the test firmware downloaded to arbitrary > > ezusb-family based devices, there are further concerns even for a > > particular device: > > Most of which we should design to avoid. There's a lot that can be > done in just 4KBytes (in a byte-efficient ASM!), and running on every > possible hardware would mean revision-specific bug workarounds as > well as "how did vendor X use it" issues. Some modes are mainstream, > and others we can/should ignore. Well, call it paranoia, but if we want to ask people to run our firmware on their devices we should be sure this wouldn't do any harm there at least. Sure, we stay away from any IO - but can we be sure this is always a) the right thing and b) all that's needed to keep the hardware alive? F.e. what if we burn some silicon because we didn't know there was something attached to the GPIF bus which requires this bus to be tristated by the firmware or some slow memory-mapped device drives the bus at the wrong time because we didn't know we have to set additional memory stretch cycles or simply disable some output-enabling IO or whatever... Maybe I'm overdoing here wrt. what you can expect from consumer-grade devices' - my FX sits in an application with safety concerns so we have to be paranoid (and 3rd party firmware wouldn't be happy there because it doesn't know how to keep the watchdog from resetting the hardware once every second ;-) > The reason to try handling lots of devices is to make it easier for > people to use this without needing to get hardware-developer kits > (such as those at http://csx.jp/~fex/ezusb/buy-en.html) ... easier to > just go to the corner store and get a usb serial adapter to re-purpose, > but not the only choice. (I did once see an FX2 based kit, but I lost > its URL.) Ok, if it's about people buying cheap hardware, dedicated - probably permanent - to burn^H^H^H^Htest them, we could relax somewhat about concerns. But I don't see why we would need a lot of people doing these tests. The number of possible *-hcd combinations with HC hardware are rather limited so it should be sufficient to have a few SDK's at the right place to do the regression testing. Much cheaper than preparing the firmware to run in the field on whatever guest-device it might find. Martin ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
