On Thu 7/22/2004 8:00 AM, rday wrote:
apparently, the onboard USB on the 850 is somewhat flaky, which is
why the USB SOF patch isn't even selectable in micropatch.c, is that
it?
I've been working in the background for over a year now to get the host-mode
USB interface working on our custom '850 hardware (running vxworks
(unfortunately)). The problem is not so much that the USB controller is
"flakey", it does what it does quite reliably. The real problem is that the
MPC850 USB controller was designed for target-mode applications and not
host-mode applications. Host-mode in the MPC850 is, at best, an
after-thought.
At the implementation level, there are (at least) two major problems:
0. The MPC850 USB controller is neither of the popular USB 1.1
implementation models (UHCI or OHCI). Since the controller is really an SCC
implemented in microcode in the CP, it has buffer descriptors (BDs) rather
than transfer descriptors (TDs). Further, it doesn't do any of the
tree-walking that a proper [UO]HCI does. It's pretty ugly if you're trying
to use a manufacturer-supplied driver.
1. The USB spec. says that the start of frame (SOF) pulse must be sent
within +/- 500 nanoseconds of the beginning of every 1 msec. frame
interval. There is no provision in the MPC850 hardware to do this
automatically and it's simply impossible to get anywhere close to this
timing with software. I haven't timed it, but I suspect the microcode patch
has trouble meeting this spec. as well. It does get a whole lot closer than
a software-only solution, though.
There's a bunch of other detailed problems that I won't bore everyone with.
Bottom line: Don't expect too much out of the MPC850 USB controller in
host-mode.
Regards,
Charlie
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Jul 22, 2004, at 1:10 PM, Wells, Charles wrote:
....... The real problem is that the
MPC850 USB controller was designed for target-mode applications and not
host-mode applications. Host-mode in the MPC850 is, at best, an
after-thought.
That's true. Having been a part of the early development of all of the
8xx
parts, there were lots of requirements that changed once the parts "hit
the street."
0. The MPC850 USB controller is neither of the popular USB 1.1
implementation models (UHCI or OHCI).
It's not the only one. I think there are more embedded controllers that
are not UHCI/OHCI than those that are. Since we work in the source
code world, it hasn't really been much of a problem.
..... I haven't timed it, but I suspect the microcode patch
has trouble meeting this spec. as well. It does get a whole lot
closer than
a software-only solution, though.
The microcode patch works quite well.
There's a bunch of other detailed problems that I won't bore everyone
with.
Bottom line: Don't expect too much out of the MPC850 USB controller in
host-mode.
There are Linux versions of software that work fine in many
applications.
USB in general doesn't rate high on my list of engineering successes.
I'm never surprised when I plug something in to any kind of system
and it doesn't work.
-- Dan
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
On Thu, 2004-07-22 at 19:35, Dan Malek wrote:
On Jul 22, 2004, at 1:10 PM, Wells, Charles wrote:
quoted
....... The real problem is that the
MPC850 USB controller was designed for target-mode applications and not
host-mode applications.
And even in target mode I see unexpected underruns, handshake timeouts
and a stucking interrupt endpoint. The software can recover from these
errors though.
There are Linux versions of software that work fine in many
applications.
USB in general doesn't rate high on my list of engineering successes.
very much right. It works, we don't know why :)
I'm never surprised when I plug something in to any kind of system
and it doesn't work.
-- Dan
Jaap-Jan
--
J.G.J. Boor Anton Philipsweg 1
Software Engineer 1223 KZ Hilversum
AimSys bv tel. +31 35 689 1941
Postbus 2194, 1200 CD Hilversum mailto:jjboor@aimsys.nl
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/