BifferBoard with non working USB

[Pedro Maia Alves]

Hi,

I've just received one BifferBoard (single USB port, 8MB flash) and
when I try to connect anything on the USB port, I get the errors like
these on the console when booting with any device on the bus or after
plugging anything:

usb 2-1: new full speed USB device using ohci_hcd and address 2
usb 2-1: device descriptor read/64, error -62
usb 2-1: device descriptor read/64, error -62
usb 2-1: new full speed USB device using ohci_hcd and address 3
usb 2-1: device descriptor read/64, error -62
usb 2-1: device descriptor read/64, error -62
usb 2-1: new full speed USB device using ohci_hcd and address 4
usb 2-1: device not accepting address 4, error -62
usb 2-1: new full speed USB device using ohci_hcd and address 5
usb 2-1: device not accepting address 5, error -62
hub 2-0:1.0: unable to enumerate USB device on port 1

I'm using the factory firmware (uname -a):
Linux OpenWrt 2.6.32.20 #5 Mon Feb 7 23:21:40 GMT 2011 i486 GNU/Linux

I tried with three devices (pen drive, FTDI RS232 interface and
webcam) that work fine on my PC but gave these kind of errors on the
BifferBoard.

Any idea on what could be the problem.

Thank you,

Pedro Maia Alves

[Nicolas Le Falher]

Hi,

These usb device are connected directly to Bifferboard or through an usb hub ?

Nicolas

[Pedro Maia Alves]

Hi,

I connected these devices directly to the Bifferboard.
I tried several in order to understand if there could be a problem
with the USB device or not.

Thank you,

Pedro Maia Alves

[Andrew Scheller]

Is your PSU supplying enough current to power both the bifferboard and
the USB peripheral?

Lurch

> --
> To unsubscribe send email to bifferboard...@googlegroups.com

[Pedro Maia Alves]

Hi,

I'm using the "standard" EU power-supply sold by Bifferos (http://
bifferos.co.uk/buy/000006.html).
When I measure the voltage on the USB pins I measure always 5V (before
or after plugging the device) so I guess there should be no PSU
problem.

Thank you,

Pedro Maia Alves

[Nicolas Le Falher]

When Andrew says "current", is in mA, not in Volts.
Bifferboard needs a minimum of 250mA for run (without SD / USB devices).
But with Bifferos power-supply, you've 1.2A available, so it's ok.

I'm off, but if you want add some usb devices, you'll need some drivers.
On Openwrt repository, module packages is for 2.6.32.33 now (factory image running on 2.6.32.30).

@Bifferos : Maybe we may change factory image to a newer one ? Or maybe contact Florian to update Openwrt repo ?

Nicolas

[Pedro Maia Alves]

If the power supply was reaching the limit, the voltage on the USB
connector would for sure drop... So measuring volts is usually
enough...

Here it should not be a driver problem because the devices are not
even identified and enumerated and, at least for the USB pen disk,
there should be already support on the factory image.

I'm also discussing this with Bifferos but my next step will be to
update the image on the Bifferboard to a newer version to check if the
problem is still there on a newer kernel... But it takes time since
there is no ready-to-be-used image with a newer kernel. Or is there
such image that I can directly use?

Thank you,

Pedro Maia Alves

[Andrew Scheller]

> I'm also discussing this with Bifferos but my next step will be to
> update the image on the Bifferboard to a newer version to check if the
> problem is still there on a newer kernel... But it takes time since
> there is no ready-to-be-used image with a newer kernel. Or is there
> such image that I can directly use?

If you don't want to compile your own kernel & rootfs from
http://sites.google.com/site/bifferboard/Home/openwrt-git you could
try using the Slackware image
http://sites.google.com/site/bifferboard/Home/desktop-linux-distributions/slackware/newbie-instructions
- that definitely works with USB flash drives :)

Lurch

P.S. I'm of the opinion that the standard FactoryFirmware image
*shouldn't* be updated. If you need to do something on BB that the FF
doesn't support, you really ought to be compiling your own image from
Git. All IMHO of course.

[Nicolas Le Falher]

>Here it should not be a driver problem because the devices are not even identified and enumerated and, at least for the USB pen disk, there should be already support on the factory image.

For sure, I say just for your futur use if you need some drivers, you may need to switch to a git image.

> If you need to do something on BB that the FF doesn't support, you really ought to be compiling your own image from Git.

I agree with that, but newer people may need just one additional package.
The only solution is compile a newer image from git, and reflash BB.
Maybe would good to support 2.6.32.33 instead 2.6.32.20 for support package from Openwrt repo no ?

Nicolas

[Andrew Scheller]

>> If you need to do something on BB that the FF doesn't support, you really
>> ought to be compiling your own image from Git.
> I agree with that, but newer people may need just one additional package.
> The only solution is compile a newer image from git, and reflash BB.
> Maybe would good to support 2.6.32.33 instead 2.6.32.20 for support package
> from Openwrt repo no ?

I'm sure Biff wouldn't mind if you created your own unofficial
pre-compiled LeFalherFirmware page on the wiki ;-)

Lurch

[Pedro Maia Alves]

For sure that I will need my own firware to put on the Bifferboard but
first the basic USB functionality must work with the "factory
firmware" or with any other standard firmware. For this debug purpose
a pre-compiled image would be great.

Anyhow I'm already compiling a new image from Git which has kernel
2.6.37.6 (I think).

Any further idea regardgin the reason the USB may not be working?

Thank you,

Pedro Maia Alves

[Nicolas Le Falher]

>I'm sure Biff wouldn't mind if you created your own unofficial pre-compiled LeFalherFirmware page on the wiki ;-)

Lurch, it's not that. Maybe you don't understand me :).
It's because when one person ask how add support for serial FTDI for example, the only reply is "take git, select package, wait minimum one hour, and flash your Biff".
It would be more easiest to manage this with "opkg update / opkg install <something>"

No ?

Nicolas

[Andrew Scheller]

Apologies to Pedro for going a bit Off-Topic ;)

Oh yeah, I totally agree that that would be the ideal situation. And
for any non-kernel-module packages, that *is* the situation :)

AIUI for it to also be the situation for kernel-module packages too,
one of two things would need to happen:
a) OpenWRT devs whole-heartedly accept Bifferboard as a
fully-supported OpenWRT platform, and incorporate all Biff's patches
into OpenWRT mainline. As we've seen that's unfortunately not gonna
happen.
or
b) Biff rolls his own OpenWRT repository, with all the required
packages, and then the FF gets updated to point at this new repo. I
suspect Biff is far too busy with other stuff for this to ever happen.

So we're currently stuck with the less-than-ideal option c) compile
your own kernel modules from git :-/
Unless an enthusiastic BB community member wants to tackle option b)
themself...?

Lurch

[biff...@yahoo.co.uk]

On May 6, 5:40 pm, Andrew Scheller <ya...@loowis.durge.org> wrote:
> b) Biff rolls his own OpenWRT repository, with all the required
> packages, and then the FF gets updated to point at this new repo. I
> suspect Biff is far too busy with other stuff for this to ever happen.

I easily can do this, however I just can't be arsed to backup all the
sources for each release, as I've done with the FF. As it happens
nobody has asked for those sources, I wonder why... :-).

I could, as I've mentioned before, just ignore the GPL and release
only the binaries until someone complains, at which point revert to
the current FF. It's interesting that the GPL, while encouraging free
software actually discourages me from releasing anything and making
things convenient for users. It's especially difficult in cases where
one GPL project rides on the back others, as is the case with
OpenWrt. I can host the packages themselves, but my hosting provider
won't be too chuffed if I host the sources too.

I've just thought of something - what happens if you (the distributor)
actually lose the sources, either through them becoming corrupted or
theft, or what have you. I guess you have to stop distributing. If
you're charging, I guess that's OK, but if you're distributing for
free, then it's a bit of a bummer.

Biff.