When is USB bus scanned

Colin_Bester · September 21, 2015, 10:02pm

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

RobertCNelson · September 21, 2015, 10:07pm

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,

William_Hermans · September 21, 2015, 10:11pm

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 ?

Colin_Bester · September 21, 2015, 11:32pm

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 · September 21, 2015, 11:40pm

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 · September 21, 2015, 11:52pm

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?

RobertCNelson · September 22, 2015, 2:01am

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

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..

Regards,

Colin_Bester · September 22, 2015, 8:48pm

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 · September 22, 2015, 9:03pm

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?

RobertCNelson · September 22, 2015, 10:06pm

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..

Regards,

Colin_Bester · September 22, 2015, 10:21pm

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.

RobertCNelson · September 22, 2015, 10:29pm

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:

github.com

RobertCNelson/boot-scripts/blob/master/tools/update_kernel.sh#L101


      
          	if [ "x${kernel}" = "x" ] ; then
          		major=$(uname -r | awk '{print $1}' | cut -d. -f1)
          		minor=$(uname -r | awk '{print $1}' | cut -d. -f2)
          
          		case "x${major}.${minor}x" in
          		x4.4x)
          			kernel="LTS44"
          			;;
          		x4.9x)
          			kernel="LTS49"
          			;;
          		x4.14x)
          			kernel="LTS414"
          			;;
          		x4.19x)
          			kernel="LTS419"
          			;;
          		x5.4x)
          			kernel="LTS54"
          			;;
          		x5.10x)

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..

github.com

RobertCNelson/boot-scripts/blob/master/tools/update_kernel.sh#L405-L441


      
          		echo "info: checking archive"
          		wget --no-verbose ${mirror}/${dist}-${arch}/LATEST-${SOC}
          		if [ -f /tmp/LATEST-${SOC} ] ; then
          
          			echo "-----------------------------"
          			echo "Kernel Options:"
          			if [ "x${show_old}" = "x" ] ; then
          				cat /tmp/LATEST-${SOC} | grep -v LTS314 | grep -v "LTS41 4.1." | grep -v LTS44 | grep -v LTS49
          			else
          				cat /tmp/LATEST-${SOC} | grep -v LTS314 | grep -v "LTS41 4.1."
          			fi
          			echo "-----------------------------"
          			echo "Kernel version options:"
          			echo "-----------------------------"
          			echo "LTS414: --lts-4_14"
          			echo "LTS419: --lts-4_19"
          			echo "LTS54: --lts-5_4"
          			echo "LTS510: --lts-5_10"
          			echo "-----------------------------"

This file has been truncated. show original

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.

Regards,

Colin_Bester · September 22, 2015, 10:36pm

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!

RobertCNelson · September 22, 2015, 11:00pm

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....

Regards,

RobertCNelson · September 22, 2015, 11:02pm

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..

Regards,