Hi Andreas,
On Mon, 21 Jul 2003, Major A wrote:
Ok, here we go. Attached the EZ-USB firmware release providing own
descriptors, EP0 standard requests and bulk sink/source support. Ready for
AN213x and FX - but not (yet) FX2. Successfully tested with ehci-hcd
and usbtest - as shown in
Martin,
Hi Andreas,
(Just nitpicking, my name is Andras, as in Andr\'as (TeX syntax).)
As you discovered it, would you mind to explain? My understanding was the
DISCON pin would float pretty long at H (maybe due to some similar
soft-pullup like they have on the ports) so it is required
Hi Andras,
On Mon, 21 Jul 2003, Major A wrote:
Hi Andreas,
(Just nitpicking, my name is Andras, as in Andr\'as (TeX syntax).)
Oops, seems I mixed it up with the german forename due to visual
similarity - Sorry!
As you discovered it, would you mind to explain? My understanding was the
Ah, OK. I used the 1.5k resistor, no external transistor. I don't know
what the actual cause was, but it looks like the DISCON pin never went
floating or didn't have sufficient impedance for a USB disconnect to
occur. The guys at Cypress recommended setting both DISCON and DISCOE
to 1,
On Sat, 19 Jul 2003, David Brownell wrote:
I'll try a bit more and post the firmware tomorrow regardless!
Great!
Ok, here we go. Attached the EZ-USB firmware release providing own
descriptors, EP0 standard requests and bulk sink/source support. Ready for
AN213x and FX - but not (yet) FX2.
Martin,
Ok, here we go. Attached the EZ-USB firmware release providing own
descriptors, EP0 standard requests and bulk sink/source support. Ready for
AN213x and FX - but not (yet) FX2. Successfully tested with ehci-hcd
and usbtest - as shown in the other mail it passes all current tests.
A little OT, but which compilers do you guys use for the FX/FX2
developement ?
cheers
---
This SF.net email is sponsored by: VM Ware
With VMware you can run multiple operating systems on a single machine.
WITHOUT REBOOTING! Mix Linux / Windows
David, Charles, and everybody:
This is just a quick summary of my recent results. I tried running the
usbtest endpoint-0 tests on two different computers, running the same
kernel and talking to the same USB device. The difference was that the
desktop system has an OHCI controller and the
On Sunday, July 20, 2003, at 08:34 PM, emanuel stiebler wrote:
A little OT, but which compilers do you guys use for the FX/FX2
developement ?
SDCC 2.3.x snapshots. I don't use the FX2, but I have been
experimenting with the FX and the AN2131 (original EZ-USB).
There are several sets of
Alan Stern wrote:
David, Charles, and everybody:
This is just a quick summary of my recent results. I tried running the
usbtest endpoint-0 tests on two different computers, running the same
kernel and talking to the same USB device. The difference was that the
desktop system has an OHCI
Charles:
Just for kicks, try applying this patch and running test 10. I don't
really know if it ought to make a significant difference, but it might.
This is kind of a shot in the dark.
Alan Stern
= uhci-hcd.c 1.54 vs edited =
--- 1.54/drivers/usb/host/uhci-hcd.cThu Jul 17
Alan Stern said:
On Fri, 18 Jul 2003, Charles Lepple wrote:
Same results on my laptop (Intel UHCI chip; the desktop uses a Via
chipset). I can send the logs, but it's just more of the same (test 10
failures, and the UHCI driver dumps its lists).
Maybe I can try running the test program on
Charles Lepple wrote:
Alan Stern said:
On Fri, 18 Jul 2003, Charles Lepple wrote:
Same results on my laptop (Intel UHCI chip; the desktop uses a Via
chipset). I can send the logs, but it's just more of the same (test 10
failures, and the UHCI driver dumps its lists).
Maybe I can try running the
On Friday, July 18, 2003, at 05:58 PM, David Brownell wrote:
Not sure about that. I admit I haven't looked very hard for the
source to
ep2_inout, but I was under the impression that it performs a loopback
on
data sent to the chip. There seem to be provisions in usbtest for
testing
without
On Wed, 16 Jul 2003, Charles Lepple wrote:
The patch below will log some additional debugging information. It might
help pinpoint where things go wrong during your test. Unfortunately, it
will generate a good deal of output even when things go right. Try to
run just the test that
Alan Stern said:
The information in the -g4 log was helpful. Here's another patch, which
is my attempt to fix the bug. It actually changes two things:
Cool, thanks! No more kernel panics-- my filesystem thanks you. However,
the test still reports failure.
Try this patch and run those tests
On Thu, 17 Jul 2003, Charles Lepple wrote:
Alan Stern said:
The information in the -g4 log was helpful. Here's another patch, which
is my attempt to fix the bug. It actually changes two things:
Cool, thanks! No more kernel panics-- my filesystem thanks you. However,
the test still
Alan Stern wrote:
I'm not sure about that last message from usbtest, though. Maybe David
can help explain what's going on.
David -- here's the result of one of Charles's tests with my debugging
output included (and some other stuff removed).
In short: Failed with status 0 means that a control
On Thu, 17 Jul 2003, David Brownell wrote:
Alan Stern wrote:
Remove_list is a list of URBs that were unlinked by the user.
Complete_list is a list of URBs that are ready to be sent to
giveback_urb(), either because they completed or because they were
unlinked. The URB's hcd-private
Alan Stern said:
Another theory would be that the EZ-USB chip is deeply broken,
but I thought they were more reasonable than that. (For all
that they're only 8 bit CPUs!)
Remember, Charles said that he was going through all this to test his
firmware. Isn't it possible that an error in his
The first four subtests (#0..#3) will run in a loop, 5000 times each.
At most four will be queued simultaneously: 0123012301230123.
- get device descriptor (18 bytes)
- get config descriptor (9 bytes, NOT including interfaces, etc)
- get altsetting for interface 0 (one byte, some
On Thu, 17 Jul 2003, David Brownell wrote:
OK, so it's possible that some of these problems start because the
chip is making a nonsensical response ... perhaps not unexpected,
since it wasn't actually running firmware at that point.
Since the test program is intended for detecting
On Thu, 17 Jul 2003, Charles Lepple wrote:
The firmware that I am loading is actually the ep2_inout firmware. (I am
trying to establish that the USB physical layer is sound, and I assume
that the EZ-USB chip is functional.)
I just finished testing with several other chips, and I can confirm
Alan Stern wrote:
On Thu, 17 Jul 2003, David Brownell wrote:
OK, so it's possible that some of these problems start because the
chip is making a nonsensical response ... perhaps not unexpected,
since it wasn't actually running firmware at that point.
Since the test program is intended for
On Tue, 15 Jul 2003, Charles Lepple wrote:
Before I round up the ksymoops log (it requires setting up a serial
console), should I try testing with a later version of usbtest? Is this a
known issue?
The log was easier to get than I expected. It's attached.
On second glance, it looks
Alan Stern said:
This is a problem in uhci-hcd. A struct urbp (private data structure) is
being accessed after it has been freed. More specifically, the list of
unlinked URBs (uhci-urb_remove_list) has been corrupted: it points to a
deallocated urbp. It would be nice to know how this could
Alan Stern said:
If you haven't done that, try running the test again with USB debugging
on. Or if you already have, look through the system log for messages from
the uhci driver.
Attached is the log with debugging enabled (first with firmware loaded,
then after rebooting, without firmware).
On Wed, 16 Jul 2003, Charles Lepple wrote:
Alan Stern said:
This is a problem in uhci-hcd. A struct urbp (private data structure) is
being accessed after it has been freed. More specifically, the list of
unlinked URBs (uhci-urb_remove_list) has been corrupted: it points to a
Charles Lepple wrote:
I was mistaken before when I said that usbtest would respond to signals
when the firmware was loaded; the only way I could see to terminate it was
to unplug the USB device.
Yes, that's a minor annoyance. Or sometimes not-so-minor, when
khubd can't un-block. It'd be a Good
On Wed, 16 Jul 2003, Charles Lepple wrote:
Attached is the log with debugging enabled (first with firmware loaded,
then after rebooting, without firmware). usbtest is currently wedged in
test_ctrl_queue (according to /proc/pid/wchan).
The debugging information isn't much help. All it shows
Alan Stern said:
It might be that the problem is triggered by a particular pattern of URBs
being unlinked and completed. The exact timing may matter as well.
Anyway, this bug shouldn't occur no matter what hardware or firmware you
use.
Definitely timing related-- the extra printks seem to
Charles Lepple wrote:
Before I round up the ksymoops log (it requires setting up a serial
console), should I try testing with a later version of usbtest? Is this a
known issue?
The log was easier to get than I expected. It's attached.
On second glance, it looks like an issue in uhci-hdc. I may
32 matches
Mail list logo
