When is USB bus scanned

[Colin Bester]

On debian 3.8.13 when is the usb port scanned for devices on startup? I am trying to debug why a normally work usb wifi adapter is now failing and not being detected on power up.

Is USB bus scan tied to a service I could somehow delay?

Any other way to force scanning and loading of usb wifi adapter?

Thanks

Colin

[Robert Nelson]

usb was nothing but a hack in v3.8.x... this was all fixed by v3.14.x...

I'll get you to leave 3.8.x by the wayside at some point. ;)

Regards,

--
Robert Nelson
https://rcn-ee.com/

[William Hermans]

Colin,

How are you powering the BBB ? If it's not by way of barrel jack, then you're doing it wrong . . . Powering by USB might work for a little while, but eventually it will not provide enough power. I got bitten by this myself, just using the CAN peripheral.

But what's changed since the last time it worked reliably ? Software? settings ?

--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups "BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beagleboard...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin Bester]

Robert, I'd love to leave 3.8.13 but it will be a long and slow process as the fixed cape overlays don't work for me ( I assume 3.14.x will give me same issues I had with 3.8.13-bone70 where due to pin definitions in overlays that I lost functionality - I'd love to chat if you have time for suggestions and possible solutions. If there are contractors out there willing to help, I'd be willing to chat.

Is 3.8.x still not the 'official' latest base?

[Colin Bester]

Powered via external power supply and not via usb port (which is definitely an issue).

Your question on what changed is a good one as that's what I always try and ask. As per a separate post (https://groups.google.com/forum/#!category-topic/beagleboard/beaglebone-black/ZceK86k1oZc) the only change is in wifi manufacturer.

The chipset is the same as what we were using previously and before I signed off on these new devices I ran tests on three different end devices with the same usb wifi adapter, rebooting devices and cycling power at least 50 times if not more.

What's weird is that the devices do work reliably for some time and then start acting up and when one starts to 'fail' if I plug it into a different beaglebone is works fine. Also plugging a new usb device into same beaglebone works - it's only that usb and that beaglebone combo that fails - doesn't make sense and I must be missing something.

[Colin Bester]

Fast learning it was a bit of a hack, but I do have to be honest in that it's been solid till now!

Any suggestions (for testing purposes) on whether I can somehow either delay detected USB devices or restart the bus scan at later time?

On Monday, September 21, 2015 at 5:08:34 PM UTC-5, RobertCNelson wrote:

[Robert Nelson]

On Mon, Sep 21, 2015 at 6:32 PM, Colin Bester <bester...@gmail.com> wrote:
> Robert, I'd love to leave 3.8.13 but it will be a long and slow process as
> the fixed cape overlays don't work for me ( I assume 3.14.x will give me
> same issues I had with 3.8.13-bone70 where due to pin definitions in
> overlays that I lost functionality - I'd love to chat if you have time for
> suggestions and possible solutions. If there are contractors out there
> willing to help, I'd be willing to chat.

In 3.8.x the cape firmware is built along with the kernel, this is why
you are stuck on that specific release.

With v4.1.x, all the cape overlays are external. So all you need to
do is boot with the latest v4.1.x-ti kernel, and then grab the
overlays

https://github.com/beagleboard/bb.org-overlays

make your changes to the lcd cape pins, then run the install to add
the overlays into the file system.

> Is 3.8.x still not the 'official' latest base?

It's the legacy base for wheezy.. All the weekly snaphots being
tested are v4.1.x-ti based..

[Colin Bester]

I will definitely experiment with 4.x but do need a production ready release with working bonescript - I haven't looked into using bonescript with 4.x yet.

Thanks

~Colin

[Colin Bester]

What's the difference between v4.1.x-ti versus v4.1.x-bone? I see http://elinux.org/Beagleboard:BeagleBoneBlack_Debian refers to bone and not ti?

Is this for beagleBONE or related to bonescript or something else?

[Robert Nelson]

bone = generic armv7 config optimized for the beaglebone's..

(note, these "optimizing" are becoming less important in every kernel
release, as things are becoming more generic and detectable, so at
some point, the .config diff between my 'armv7' and 'bone' will be no
more..)

ti: ti jumped on the v4.1.x lts release, so we are taking full
advanage of that.. (i've cherry picked a few things from ti's v4.1.x
that you see in our bone branch. cpufreq-volt, iodelay, etc..)

The "v4.1.x-ti" is what i'm testing/pushing by default..

[Colin Bester]

Thanks. I installed (via apt-get) 4.1.6-ti but when I ran the kernel update script under /opt/script/tools it updated to 4.1.8-boneX

Is it okay/advised to run the update kernel script and stick with its Linux version?

I am in process of downloading emmc flasher as I just bricked my BBB after editing uEnv.txt.

Should one add a dtb entry in uEnv or can we keep that line commented out and just use default?

I will go through examples tomorrow and try get base stack going with BBB rev C, LCD cape, i2c and PWM. Afterwards will look into audio.

Sent from my iPhone

> --
> For more options, visit http://beagleboard.org/discuss
> ---

> You received this message because you are subscribed to a topic in the Google Groups "BeagleBoard" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/beagleboard/6bKl8wzt8CI/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to beagleboard...@googlegroups.com.

[Robert Nelson]

On Tue, Sep 22, 2015 at 5:21 PM, Colin Bester <bester...@gmail.com> wrote:
> Thanks. I installed (via apt-get) 4.1.6-ti but when I ran the kernel update script under /opt/script/tools it updated to 4.1.8-boneX

odd, as i have the defaults setup to install the 'ti' branch:

https://github.com/RobertCNelson/boot-scripts/blob/master/tools/update_kernel.sh#L101

> Is it okay/advised to run the update kernel script and stick with its Linux version?

The script has about 30 seconds of thought put into it..

and a large number of possible combinations..

https://github.com/RobertCNelson/boot-scripts/blob/master/tools/update_kernel.sh#L405-L441

Use the flags:

--ti-channel --testing = v4.1.x-ti
--ti-rt-channel --testing = v4.1.x-rt-ti

> I am in process of downloading emmc flasher as I just bricked my BBB after editing uEnv.txt.
>
> Should one add a dtb entry in uEnv or can we keep that line commented out and just use default?

If your using an lcd, use one of the example dtb=xyz shown in /boot/uEnv.txt

> I will go through examples tomorrow and try get base stack going with BBB rev C, LCD cape, i2c and PWM. Afterwards will look into audio.

[Colin Bester]

I used --lts per documentation, maybe that's what caused it. I thought 'lts' sounded good as I want more stable and long term support so didn't question it. Gotta run but will continue tomorrow and try not too bug ya'll too much!

Sent from my iPhone

[Robert Nelson]

On Tue, Sep 22, 2015 at 5:36 PM, Colin Bester <bester...@gmail.com> wrote:
> I used --lts per documentation, maybe that's what caused it. I thought 'lts' sounded good as I want more stable and long term support so didn't question it. Gotta run but will continue tomorrow and try not too bug ya'll too much!

Oh that's perfectly fine too, i've setup the "--lts" option for users
that don't want massive jumps..

The problem with the "ti" repos

http://repos.rcn-ee.com/latest/jessie-armhf/LATEST-ti

ABI:1 STABLE 3.14.52-ti-r75
ABI:1 TESTING 4.1.6-ti-r16

3.14.x & 4.1.x are lts's from kernel.org ;)

whereas we've been testing 3.14.x for a good year, 4.1.x is still only
a few months old..

I'm pretty sure we are close to moving v4.1.x to stable....

[Robert Nelson]

err, forgot about the xenomai case.. We don't have an xenomai option
for v4.1.x, so those users are still stuck on v3.14.x..

So till we get xenomai for v4.1.x, it'll be stuck in testing..