use of USB sound card freezes BBB

GoogleGroups
1

I have Debian Jessie installed on a BBB Rev C (Linux beaglebone 3.14.26-ti-r39 #1 SMP PREEMPT Mon Dec 8 01:52:29 UTC 2014 armv7l GNU/Linux)

And I have a USB sound card attached to a powered USB hub:

lsusb:
Bus 001 Device 003: ID 0d8c:000c C-Media Electronics, Inc. Audio Adapter
Bus 001 Device 002: ID 05e3:0608 Genesys Logic, Inc. USB-2.0 4-Port HUB
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

aplay -l:
**** List of PLAYBACK Hardware Devices ****
card 0: Black [TI BeagleBone Black], device 0: HDMI hdmi-hifi-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Set [C-Media USB Headphone Set], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0

Unfortunately, any attempt to direct audio output to the card freezes the BBB with no message to syslog. User LED’s 0 and 2 are constant on and LED’s 1 and 3 are constant off.

For example:
speaker-test -Ddefault:Set -c6 -twav

speaker-test 1.0.28

Playback device is default:Set
Stream parameters are 48000Hz, S16_LE, 6 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 2048 to 16384
Period size range from 1024 to 1024
Using max buffer size 16384
Periods = 4
was set period_size = 1024
was set buffer_size = 16384
0 - Front Left

Would anyone have an idea how to approach this?

Thanks.

2

First please upgrade to "3.14.26-ti-r43"

sudo apt-get update
sudo apt-get install linux-image-3.14.26-ti-r43
sudo reboot

There's been a few "musb" patches..

Although we may just have to disable "usb dma"

https://github.com/beagleboard/linux/blob/1d0defeba9685e616b05f7340111ab84c47ad762/arch/arm/configs/bb.org_defconfig#L3727

From:

CONFIG_USB_TI_CPPI41_DMA=y
# CONFIG_MUSB_PIO_ONLY is not set

to:
# CONFIG_USB_TI_CPPI41_DMA is not set
CONFIG_MUSB_PIO_ONLY=y

Right now, i'm keeping DMA enabled, so we can continue to test this
kernel as TI is still developing it, but we may have to end up in pio
mode to support every usb device..

Regards,

3

That’s kind of disappointing to hear. Pio sounds like it means a lot of overhead if you are using a lot of usb bandwidth. I’m interested as we are using a bit of usb and a usb audio codec…

Is this issue something exclusive to the ti kernel or also in mainline?

Chris

4

It's just the last few outlier bugs for the DMA controller behind the
musb ip block..

In v3.8.x we have PIO mode set by default too:

CONFIG_USB_MUSB_DSPS=y
CONFIG_MUSB_PIO_ONLY=y

https://github.com/beagleboard/linux/blob/1b8cd64cf49960d835591de1fee2282494858fa6/arch/arm/configs/bb.org_defconfig#L3345

So it's not really a regression from a v3.8.x -> v3.14.x upgrade point.

But if we start getting a fair number of user problems, i'm prepared
to push it back to pio mode quickly.

Regards,

5

Oh, this might be the issue I was experiencing with the later kernel. In my other email I just posted ("Changes in 3.19 (was: How to make BBB pins work after Ubuntu Trusty install?)"), I talked about the 3.18 kernel, but I probably meant 3.14. That was weeks ago and I just don't remember how I got to that situation (either upgrading the kernel or building my own).

In any case, my USB audio dongle playback was terrible on a kernel >3.8.x, works well on 3.8.

6

Thanks for (amazingly) quick reply.

Upgrade went smoothly; rebooted without hitch.

Speaker-test still freezes BBB. I haven’t looked to see if anything else behaves differently yet.

7

git clone https://github.com/beagleboard/linux
cd linux

git checkout origin/3.14.26-ti-r43 -b tmp
make ARCH=arm bb.org_defconfig

./scripts/config --disable CONFIG_USB_TI_CPPI41_DMA
./scripts/config --enable CONFIG_MUSB_PIO_ONLY

fakeroot make ARCH=arm LOCALVERSION=-ti-r43-tmp
CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- KDEB_PKGVERSION=1cross
KBUILD_DEBARCH=armhf deb-pkg

cp *.deb to bbb, then run:

sudo dpkg -i linux-image-*
sudo reboot

Regards,

8

git clone https://github.com/beagleboard/linux
cd linux

git checkout origin/3.14.26-ti-r43 -b tmp

I’m currently stuck here with:

$ git checkout origin/3.14.26-ti-r43 -b tmp
fatal: git checkout: updating paths is incompatible with switching branches.
Did you intend to checkout ‘origin/3.14.26-ti-r43’ which can not be resolved as commit?

still trying to diagnose.

9

Sorry about that... It's a tag not a branch so..

voodoo@hestia:~/linux$ git checkout 3.14.26-ti-r43 -b tmp
Switched to a new branch 'tmp'

Regards,

10

These steps die here. Do I have the wrong gcc? Was I supposed to run this on the BBB? Thanks!

~/linux$ fakeroot make ARCH=arm LOCALVERSION=-ti-r43-tmp
scripts/kconfig/conf --silentoldconfig Kconfig
Makefile:608: Cannot use CONFIG_CC_STACKPROTECTOR_REGULAR: -fstack-protector not supported by compiler
  CHK include/config/kernel.release
  UPD include/config/kernel.release
  WRAP arch/arm/include/generated/asm/auxvec.h
  WRAP arch/arm/include/generated/asm/bitsperlong.h
  WRAP arch/arm/include/generated/asm/cputime.h
  WRAP arch/arm/include/generated/asm/current.h
  WRAP arch/arm/include/generated/asm/emergency-restart.h
  WRAP arch/arm/include/generated/asm/errno.h
  WRAP arch/arm/include/generated/asm/exec.h
  WRAP arch/arm/include/generated/asm/ioctl.h
  WRAP arch/arm/include/generated/asm/ipcbuf.h
  WRAP arch/arm/include/generated/asm/irq_regs.h
  WRAP arch/arm/include/generated/asm/kdebug.h
  WRAP arch/arm/include/generated/asm/local.h
  WRAP arch/arm/include/generated/asm/local64.h
  WRAP arch/arm/include/generated/asm/msgbuf.h
  WRAP arch/arm/include/generated/asm/param.h
  WRAP arch/arm/include/generated/asm/parport.h
  WRAP arch/arm/include/generated/asm/poll.h
  WRAP arch/arm/include/generated/asm/resource.h
  WRAP arch/arm/include/generated/asm/sections.h
  WRAP arch/arm/include/generated/asm/segment.h
  WRAP arch/arm/include/generated/asm/sembuf.h
  WRAP arch/arm/include/generated/asm/serial.h
  WRAP arch/arm/include/generated/asm/shmbuf.h
  WRAP arch/arm/include/generated/asm/siginfo.h
  WRAP arch/arm/include/generated/asm/simd.h
  WRAP arch/arm/include/generated/asm/sizes.h
  WRAP arch/arm/include/generated/asm/socket.h
  WRAP arch/arm/include/generated/asm/sockios.h
  WRAP arch/arm/include/generated/asm/termbits.h
  WRAP arch/arm/include/generated/asm/termios.h
  WRAP arch/arm/include/generated/asm/timex.h
  WRAP arch/arm/include/generated/asm/trace_clock.h
  WRAP arch/arm/include/generated/asm/unaligned.h
  WRAP arch/arm/include/generated/asm/preempt.h
  WRAP arch/arm/include/generated/asm/hash.h
  CHK include/generated/uapi/linux/version.h
  UPD include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  UPD include/generated/utsrelease.h
  Generating include/generated/mach-types.h
  CC kernel/bounds.s
gcc: error: unrecognized argument in option ‘-mabi=aapcs-linux’
gcc: note: valid arguments to ‘-mabi=’ are: ms sysv
gcc: error: unrecognized command line option ‘-mlittle-endian’
gcc: error: unrecognized command line option ‘-mapcs’
gcc: error: unrecognized command line option ‘-mno-sched-prolog’
gcc: error: unrecognized command line option ‘-mno-thumb-interwork’
gcc: error: unrecognized command line option ‘-mfpu=vfp’
make[1]: *** [kernel/bounds.s] Error 1
make: *** [prepare0] Error 2

11

This just means it default to your default "x86" compiler, just force
linaro on your x86:

Follow the directions here:

https://eewiki.net/display/linuxonarm/BeagleBone+Black#BeagleBoneBlack-ARMCrossCompiler:GCC

Don't bother setting the CC bit..

Just make sure the update the "CROSS_COMPILE=" location

fakeroot make ARCH=arm LOCALVERSION=-ti-r43-tmp
CROSS_COMPILE=/usr/bin/arm-linux-gnueabihf- KDEB_PKGVERSION=1cross
KBUILD_DEBARCH=armhf deb-pkg

remember ^ this is one line..

Regards,

12

Oops!

13

Okay, audio seems to work, but of course now I don't know how to enable the ADCs. Is this where I have to make a complete dtb that's loaded at boot? This is what I'd use dtb-rebuilder for, right, but that's in 3.19?

I'm sorry, there are so many moving parts to this project, I'm having a hard time remembering where I was before I last downgraded to 3.8. I need to read two ADCs and read and set a handful of GPIOs (via sysfs is fine), and eventually I need some PRU code to be able to write quickly to one GPIO.

Thank you for your continued support!

14

So the ADC is pretty straight forward, for example the proxy cape uses
3 adc channels..

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-basic-proto-cape.dtsi

So if you add that node (with the 2 adc channels you need) to:

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-boneblack.dts

then it's just

make
sudo make install
sudo reboot

(this is with the 3.14-ti branch of dtb-rebuilder)

The best gpio example is in the argus dtsi

https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-argus.dtsi

Regards,

15

Okay, that seemed to re-enable the ADC, but it killed my GPIOs (which were working, actually). I didn't yet try to add a node for the GPIOs. I have many questions:

A) What does it mean for all those resulting .dtb files to be in the /boot/... directory? Do they all get loaded? Does only the main one ("am335x-boneblack")?

B) In the Argus example, all the &ocp/..._pinmux statuses are set to "disabled." Wouldn't I want the pinmux to be enabled ("okay")? What does it mean to disable the pinmux?

C) Can there be multiple &ocp, &am33xx_pinmux entries?

D) There's a comment on https://github.com/RobertCNelson/dtb-rebuilder/blob/3.14-ti/src/arm/am335x-bone-argus.dtsi#L56 that says the gpio controllers appear to be numbered starting at 1, but then list gpio controllers numbered 0.

E) What does "debug" and "shutdown" do?

F) I'm going to add version of each of these ampersand-nodes, and a root node, just like the argus ones, replacing "argus_ups" with "podtique", and adjusting the pins to what I need. Is that the right approach? That will result in am335x-boneblack.dts having multiple root nodes, and multiple &ocp and &am335x-pinmux nodes. Eventually, this suggests making a separate .dtsi with all the stuff for my cape, and just including it into .dts, right?

G) What should my uEnv.txt look like? It currently looks like this: http://pastebin.com/3fx5SDb9

Thanks!

16

So the ADC is pretty straight forward, for example the proxy cape uses
3 adc channels..

dtb-rebuilder/src/arm/am335x-bone-basic-proto-cape.dtsi at 3.14-ti · RobertCNelson/dtb-rebuilder · GitHub

So if you add that node (with the 2 adc channels you need) to:

dtb-rebuilder/src/arm/am335x-boneblack.dts at 3.14-ti · RobertCNelson/dtb-rebuilder · GitHub

then it's just

make
sudo make install
sudo reboot

(this is with the 3.14-ti branch of dtb-rebuilder)

The best gpio example is in the argus dtsi

dtb-rebuilder/src/arm/am335x-bone-argus.dtsi at 3.14-ti · RobertCNelson/dtb-rebuilder · GitHub

Okay, that seemed to re-enable the ADC, but it killed my GPIOs (which were working, actually). I didn't yet try to add a node for the GPIOs. I have many questions:

A) What does it mean for all those resulting .dtb files to be in the /boot/... directory? Do they all get loaded? Does only the main one ("am335x-boneblack")?

Only one "*.dtb" will get loaded by u-boot from /boot/

For most "capes" (that work in v3.14.x) i've created a single *.dtb
file for them.

am335x-boneblack-<cape>.dtb

This is what the commented out "#dtb=" variable in /boot/uEnv.txt is for.

Say if you have the "4dcape-70t" cape plugged in and you don't want to
edit anything between kernel versions you'd set:

dtb=am335x-boneblack-4dcape-70t.dtb

B) In the Argus example, all the &ocp/..._pinmux statuses are set to "disabled." Wouldn't I want the pinmux to be enabled ("okay")? What does it mean to disable the pinmux?

So the *_pinmux status are for the cape-universal. If you'd like to
use "pin-config" in userspace you'd have to define those to a default
state. In our case with the Argus it's not fully converted over so we
control the pin stage in the am33xx_pinmux instea.

C) Can there be multiple &ocp, &am33xx_pinmux entries?

Correct.. It just overlays on top of each other. The dtc compiler will
match &node and combine them in the final dtb

D) There's a comment on dtb-rebuilder/src/arm/am335x-bone-argus.dtsi at 3.14-ti · RobertCNelson/dtb-rebuilder · GitHub that says the gpio controllers appear to be numbered starting at 1, but then list gpio controllers numbered 0.

Oh i need to double check that. Back in v3.8.x all the "gpio" was
off by one, which was fixed in mainline shortly after. So v3.14.x
"gpio" actually matches the am335x datasheet now..

E) What does "debug" and "shutdown" do?

Which reference is that too?

F) I'm going to add version of each of these ampersand-nodes, and a root node, just like the argus ones, replacing "argus_ups" with "podtique", and adjusting the pins to what I need. Is that the right approach? That will result in am335x-boneblack.dts having multiple root nodes, and multiple &ocp and &am335x-pinmux nodes. Eventually, this suggests making a separate .dtsi with all the stuff for my cape, and just including it into .dts, right?

Yeap, that's the best way.. Just edit your own *.dtsi and include it.

Btw, there's two ways of doing gpio's..

Say if you have a key event, and you want something done look at gpio-keys:

rtc example, gpio to wake up with:

There's a few other specially ways here:

G) What should my uEnv.txt look like? It currently looks like this: #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0uname_r=3 - Pastebin.com

That looks fine. If we ever ship a new default image, that's exactly
how the new default will look like.

Regards,

17

A) What does it mean for all those resulting .dtb files to be in the /boot/... directory? Do they all get loaded? Does only the main one ("am335x-boneblack")?

Only one "*.dtb" will get loaded by u-boot from /boot/

For most "capes" (that work in v3.14.x) i've created a single *.dtb
file for them.

am335x-boneblack-<cape>.dtb

This is what the commented out "#dtb=" variable in /boot/uEnv.txt is for.

Say if you have the "4dcape-70t" cape plugged in and you don't want to
edit anything between kernel versions you'd set:

dtb=am335x-boneblack-4dcape-70t.dtb

So, I should create something like "am335x-boneblack-podtique.dtb" and set that in uEnv.txt. And to create that, I could follow the Argus example as per your answer to question (F).

B) In the Argus example, all the &ocp/..._pinmux statuses are set to "disabled." Wouldn't I want the pinmux to be enabled ("okay")? What does it mean to disable the pinmux?

So the *_pinmux status are for the cape-universal. If you'd like to
use "pin-config" in userspace you'd have to define those to a default
state. In our case with the Argus it's not fully converted over so we
control the pin stage in the am33xx_pinmux instea.

The more I can do in user space, the happier I am, but I have to be able to do it from C-code (preferably without exec-ing some other program). I don't know anything about "pin-config", but vaguely recall that this is something you mentioned will be ready in the next few days, hopefully? Sadly, that will be too late for now, so I'm okay with just getting it right in the dtb.

E) What does "debug" and "shutdown" do?

Which reference is that too?

F) I'm going to add version of each of these ampersand-nodes, and a root node, just like the argus ones, replacing "argus_ups" with "podtique", and adjusting the pins to what I need. Is that the right approach? That will result in am335x-boneblack.dts having multiple root nodes, and multiple &ocp and &am335x-pinmux nodes. Eventually, this suggests making a separate .dtsi with all the stuff for my cape, and just including it into .dts, right?

Yeap, that's the best way.. Just edit your own *.dtsi and include it.

Btw, there's two ways of doing gpio's..

Say if you have a key event, and you want something done look at gpio-keys:

linux/Documentation/devicetree/bindings/gpio/gpio_keys.txt at 3.14 · beagleboard/linux · GitHub

rtc example, gpio to wake up with:

dtb-rebuilder/src/arm/am335x-bone-rtc-01-00a1.dtsi at 3.14-ti · RobertCNelson/dtb-rebuilder · GitHub

There's a few other specially ways here:

linux/Documentation/devicetree/bindings/gpio at 3.14 · beagleboard/linux · GitHub

Hmm. Right now, my main thread loops at about 10 Hz, reading the state of the ADCs and GPIOs, and passes those to an object that manages another thread of execution. Each time through that second thread's loop, it uses the state that was set to adjust its behavior. That works pretty well for me, as neither thread is terribly busy. The one thing that would be nice eventually would be to use one of the GPIOs to let the whole thing go into a low-power sleep mode, and then wake on change. But for now, I can do without that.

G) What should my uEnv.txt look like? It currently looks like this: #Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0uname_r=3 - Pastebin.com

That looks fine. If we ever ship a new default image, that's exactly
how the new default will look like.

Will the capemgr lines be there? It's not clear to me if capemgr is deprecated or just temporarily broken and will be coming back.

Assuming it's gone, how do I disable HDMI? Just remove the #include lines that reference it from "am335x-boneblack.dts"?

Thanks!

18

Heya Rick,

First off let me say that I was exploring kernel 3.14.x myself in this respect before the holidays, and got “sucked” into doing some remodeling work for / with a friend who recently sold a house . . .

Anyway, from what I see in your uEnv.txt file you’re only loading an ADC overlay, on top of the standard *bone-black dtb. Hence why your GPIO pins are probably not working. However, since you did not say if your *bone-black.dtb is modified or not . . . yeah, I could not say that 100% for sure.

So here is a post by Tom King ( and Panto - IRC nick ) from early on after release.

http://elinux.org/BeagleBone_and_the_3.8_Kernel

There are some differences here now between 3.8.x, and 3.14.x. First of all, of course we do not have capemgr in 3.14.x, and I think we can use an #include statement in the main overlay to pull in additional overlays. I am a bit fussy here myself, as before the holidays, this is where I personally halted my own experiments. Anyway, Robert undoubtedly could answer this question better than I, but if you look in the main board file *.dtb you should find examples of #include commented out ( e.g. ##include ). which should give you a hint.

Combine that with the link ( informational purposes ) I gave above, and you should be able to modify the main board file to #include a custom overlay for the GPIO pins you need.

However, you seem to be using a 3.8.x kernel ?

cape_enable=capemgr.enable_partno=BB-ADC kind of denotes this but let us say for example you had your pin configs all setup in a file named BB-GPIO., your enable line would look similar to . . .

cape_enable=capemgr.enable_partno=BB-ADC, BB-GPIO

Comma separated overlay files . . .

Also, if you look very closely at the *.dtb files in the /boot/ directory, you’ll see files for various other hardware platforms such as *bone.dtb ( beaglebone white ), and other hardware platforms that Robert supports with / for his various build instructions.

As for the rest of your questions, I would have to defer to someone else more knowledgeable. Hopefully though the link I gave above would be able to answer most / all of those questions.

19

Ah, apparently google notifications ceased working for me, and it half past whiskey:30, and . . .

Yeah Robert’s got you covered.

Cheers :wink:

20

No worries, I appreciate the link.

And, I totally had it working, but now it's acting up. One of the symptoms is that when my program starts, it seems to hang up on something, and I can't kill it (even with sudo kill -kill). It's not exactly that, because it was playing audio just fine, but not responding to the interfaced controls. I hit Control-C, and the music stopped, but the app didn't exit.

I logged in again and rebooted the BBB, and now it won't even play audio. Very bizarre. I hope this isn't a wholly-unrelated-to-my-DTB-shenanigans issue (perhaps back onto the subject of this thread, USB sound card issues?).