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?
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
