[linux-dvb] Re: Unbranded USB DVB device afatech af9005

[Luca Olivetti]

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).
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?
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?)


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.

Bye
-- 
Luca

A: Because it destroys the flow of the conversation
Q: Why is it bad?
A: No, it's bad.
Q: Should I top post in replies to mailing lists?