Luca Olivetti wrote: > En/na Manu Abraham ha escrit: >> Sorry, was looking at something else. >> >> Apollo Datasheet v1.1 9002/3/5 >> page 41 says >> >> In 2nd phase the host will download OFSM image to ASIC RAM, which is >> starting from 0x4100. >> In last phase, the host polls status register (0xC90B) to check if this >> downloading is successful or failed. >> So there is a firmware involved. > > Ok, now I have that document, and that page refers to firmware > downloading in MPEG TS mode, in usb mode the procedure is different > (however it is documented with source code). There is a nice picture of the USB mode on page 45 > I made some sniffing and I can see that the firmware downloading is done > according to the example software, but in the capture file I see some > things that aren't documented. > > Now comes the question: > > 0)everything (commands, replies, ts data) is done with bulk transfers > 1)all commands are sent on endpoint 2 > 2)to each command corresponds a reply that comes through endpoint 1 (but > usbsnoop identifies it as endpoint 0x81) > 3)what appears to be TS data comes through endpoint 4 (0x84 in usbsnoop) > > The fact that commands and replies are on 2 different endpoints means > that I cannot use dvb_usb_generic_rw/dvb_usb_generic_write, yes, no, or > am I just being stupid? will take a look in there. > I suppose I can just make a private copy of those functions where, > instead of using > > usb_sndbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint) > usb_rcvbulkpipe(d->udev, d->props.generic_bulk_ctrl_endpoint) > > I would hardcode > > usb_sndbulkpipe(d->udev, 2) > usb_rcvbulkpipe(d->udev, 1) (or 0x81?) > from pages 29 - 32 Endpoint 0 is the same as defined in USB 1.1 standard. Endpoint 1 is bulk-in. Endpoint 2 is bulk-out. Endpoint 3 is interrupt. Endpoint 4 is bulk-in. Endpoint 1 and 2 serve the control messages, while Endpoint 4 serves the video data packets. Endpoint 3 is reserved and currently not used. > Another stupid question: doesn't the usb protocol ensure data integrity? > Because it seems awkward to me that they go to such great lengths to a) > encode the packet length as the first 2 bytes of the packet data and b) > put a checksum on eack packet. Some cases the data transfer can go corrupt as well, but that would probably be a very small chance. Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
