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?