mainline BPi ALSA onboard audio support

13 4302
Edited by danboid at Feb 28, 2016 12:43

As of Linux 4.4.0, the mainline kernel has support for the BPi onboard audio, its just not enabled in the .dtb and .dts files yet and this still seems to be he case with 4.4.3.


See the link in the first reply to this post for the simple patch thats required to enable it.

If you're lazy and don't want to recompile your kernel you can get away with replacing your /boot/dtbs/sun7i-a20-bananapi.dtb with the one attached to this post. The attached BPi dtb has worked for me under Arch with both Linux 4.4.0 and 4.4.1. I don't own a BPro to supply and test a similar file but the process to patch the .dts file will be the same. See the second post in this thread for a guide on how to rebuild the kernel under Arch:

http://forum.lemaker.org/forum.p ... ad&tid=22694&extra=

NB You need have alsa-utils installed so that you can use alsamixer. To get sound output working at full volume,  both 'Power Amplifier DAC' and 'Power Amplifier Mute' have to be unmuted whilst everything else remains muted. Use the 'm' key to unmute those channels under alsamixer. To save your ALSA mixer settings run:

  1. # alsactl store 0
Copy the Code


5.82 KB, Downloads: 12

Edited by sashijoseph at Jan 15, 2016 12:32

seems this dts patch should enable the BPi codec
Enable BPi Audio Codec linked from  this thread

could you check?

Hi sashi!

Thanks for your reply!

That patch supposedly needs to be applied to a file called sun7i-a20-bananapi.dts but I have no such file on my Arch install.

There is a file called sun7i-a20-bananapi.dtb but its a binary file so nothing I can apply that patch to.

Edited by danboid at Jan 16, 2016 14:12

Thinking about it for more than a second, I obviously need to rebuild the kernel!

I've worked out how to get and manually patch the sources to do it the Arch Linux ARM way but without updating the PKGBUILD or having to integrate the patch the proper Arch way ie this is the lazy mans method to patch the ALARM kernel package:

  1. git clone https://github.com/archlinuxarm/PKGBUILDs.git
  2. cd PKGBUILDs/core/linux-armv7
  3. makepkg -o
  4. <apply patch>
  5. makepkg -e
Copy the Code

I have just started building the kernel now. I've never built a kernel for my BPi before but seeing as it takes about an hour to build Linux on my i7 laptop I expect its going to be at least a good few hours before the kernel builds and I get to test the patch.


I left my kernel building over night. I prefixed `makepkg -e` with the `time` command so I know that it took over 9.5 hours before the build failed with this error:

  1. CC [M]  sound/ac97_bus.o
  2.   MK_FW   firmware/am335x-pm-firmware.elf.gen.S
  3. make[1]: *** No rule to make target 'firmware/am335x-pm-firmware.elf', needed by 'firmware/am335x-pm-firmware.elf.gen.o'.  Stop.
  4. Makefile:943: recipe for target 'firmware' failed
  5. make: *** [firmware] Error 2
  6. ==> ERROR: A failure occurred in build().
  7.     Aborting...
Copy the Code

I found a possible fix to this error here:

http://stackoverflow.com/questio ... mware-bin-needed-by

I decided just to download the missing FW file rather than change the kernel config.

I was hoping I could save myself another 9.5 hours wait and that, after downloading that missing FW file, I could resume the failed build by simply by running `makepkg -e` again but unfortunately that doesn't seem to work so the kernel build has just started over from scratch.

Hopefully I don't hit any more roadblocks!

How long does 4.4.0 take to build on the Bpi? I realise it depends on what kernel config options you choose. Has anyone here already rebuilt the ALARM linux-armv7 PKGBUILD on their BPi (w/ SATA HD)?

Edited by danboid at Jan 17, 2016 04:04

Actually, `makepkg -e` must resume builds as I hit that same build error again really quickly even though I now have am335x-pm-firmware.bin in linux-armv7/src/linux-4.4/firmware so I'm going to have to try changing the kernel config to disable support for am335x-pm-firmware.bin.

I'm pretty sure doing that will require I start the build from scratch though.


I've just kicked off a clean build with the audio patch applied and this time CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR  have been commented out of the kernel config file so hopefully that will fix it.

Commenting out CONFIG_EXTRA_FIRMWARE and CONFIG_EXTRA_FIRMWARE_DIR didn't fix my build either -it's failed with the same error as before.

ALARM doesn't officially support the BPi although I've been running Arch just fine on my BPi for the last year or so. I'm currently trying to find out if any of the ALARM devs have had this issue when building the kernel.

I've not attempted to build a Linux kernel for at least a decade so I'm totally out of touch with the process and its pitfalls now. On the PC I could usually either find a package or repo with the needed kernel or I'd go as far as switching distro to avoid building a custom kernel. I never was a fan of messing with the plumbing!

Edited by danboid at Jan 17, 2016 18:41

I've got further in the build process now - with any luck it will get all the way to building a patched kernel package for me now.

The problem here is that the ALARM armv7 kernel is a very generic one which tries to support pretty much every ARM board using this CPU family out there, including of course the popular Beaglebone Black. It would seem these firmware files my kernel build was complaining about missing are required by some TI chipset on the BBB. Rather than spend any extra time working out how to disable BBB support in the kernel config, I thought it would be easier just to give it the files it wanted by copying them from the BBB kernel tree by doing something like this:

  1. git clone https://github.com/beagleboard/linux.git
  2. cp linux/firmware/am* linux-armv7/src/linux-4.4/firmware/
Copy the Code

The results are in!

It took me pretty much all weekend but I finally managed to build a patched Arch linux-armv7 4.4.0-2 package. Building this package on a BPi under 4.4.0 running off a SATA HD takes approx. 12.5 hours! Yes, twelve and a half hours!

By applying the above patch ALSA kinda works. I can play audio but its VERY quiet, even with the supposed volume control maxed out, which brings me onto the other issue. Not all of the ALSA mixer controls are present and the ones that are seem to be incorrectly labelled so it needs some work yet:

  1. $ amixer scontrols
  2. Simple mixer control 'Left Mixer Left DAC',0
  3. Simple mixer control 'Power Amplifier',0
  4. Simple mixer control 'Power Amplifier DAC',0
  5. Simple mixer control 'Power Amplifier Mixer',0
  6. Simple mixer control 'Power Amplifier Mute',0
  7. Simple mixer control 'Right Mixer Left DAC',0
  8. Simple mixer control 'Right Mixer Right DAC',0
  9. $ amixer controls
  10. numid=2,iface=MIXER,name='Left Mixer Left DAC Playback Switch'
  11. numid=5,iface=MIXER,name='Power Amplifier DAC Playback Switch'
  12. numid=6,iface=MIXER,name='Power Amplifier Mixer Playback Switch'
  13. numid=7,iface=MIXER,name='Power Amplifier Mute Switch'
  14. numid=1,iface=MIXER,name='Power Amplifier Volume'
  15. numid=4,iface=MIXER,name='Right Mixer Left DAC Playback Switch'
  16. numid=3,iface=MIXER,name='Right Mixer Right DAC Playback Switch'
Copy the Code

I have emailed the authors of that patch to let them know how I got on.

You have to log in before you can reply Login | Sign Up

Points Rules