[linux-dvb] Re: Unbranded USB DVB device afatech af9005
abraham.manu at gmail.com
Fri Dec 1 15:34:50 CET 2006
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.
More information about the linux-dvb