Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 180 replies
  • Subscribers 720 subscribers
  • Views 29143 views
  • Users 0 members are here
Related

Driver fixes and updates to kernel 3.18.16 and 4.0.5

hiassoft

Edit: Current kernel versions and install/config instructions are also available from my webpage http://www.horus.com/~hias/cirrus-driver.html

 

During the last few weeks I fixed various issues in the Wolfson/Cirrus driver and rebased it so it works with the current RPi kernel versions (3.18.16 and 4.0.5).

 

You can download the patches from my GitHub repository. The 3.18 kernel with Cirrus drivers is in the cirrus-3.18.y branch, the 4.0 kernel with Cirrus drivers is in the cirrus-4.0.y branch. I'll rebase and update these branches from time to time so that the Cirrus driver and my changes will stay on top of the commit list.

 

If you just want to have an updated 3.18.16 kernel you can download precompiled binaries from here. Just unpack the tarball in the root directory. Before you do that it might be a good idea to update the firmware files (bootcode.bin, start*.elf and fixup*.dat in the boot directory) to the latest version.

 

Here's a list of my changes:

- Added the FLL1 setup back so that switching between 44.1kHz and 48kHz (and other sample rates) works fine.

- Don't register Arizona IRQ if it's set to 0. The Cirrus driver uses polling here and if we register an interrupt handler for irq 0 we get lots of "spurious interrupt" messages spamming dmesg in kernel 3.19 and newer. IRQ 0 is wrong anyway.

- Include DCVDD patches from the Cirrus linux-drivers repository. These patches make sure the WM8804 chip is initialized properly. Without this patch I sometimes had SPDIF audio out only on the right channel.

- Disable spidev0 in Cirrus device tree overlay. That's mainly a safety precaution so that userspace programs trying to access spi0.0 won't interfere with the WM8804 reset line. I'm not 100% sure this is needed at all, so maybe I'll remove it some time later.

 

And some important notes:

I haven't included the mmap patch, this is already supported in the upstream kernels but currently disabled by default. To enable mmap support add the following line to config.txt:

dtoverlay=i2s-mmap

 

If you compile the kernel on your own please note that the devicetree overlays have now been moved to arch/arm/boot/dts/overlays.

 

Kernel 4.0 now uses spi_bcm2835 by default (the older spi_bcm2708 module is available via a devicetree overlay) so you have to extend your /etc/modprobe.d conf file and add a pre-depend for spi_bcm2835 as well. It's safe to have both the old and the new module in here, so just use this configuration:

softdep arizona-spi pre: arizona-ldo1
softdep spi-bcm2708 pre: fixed
softdep spi-bcm2835 pre: fixed

 

so long,

 

Hias

  • in reply to hiassoft

    Hi again,

    I resolved the darkice not starting after using aplay -l : said device = 0,0 rather than what I was using as 1,0

    Awesome, its using the on board mics at present, going to wire up for the line in for binaural audio.

     

    Warmest wishes.. you saved the day

     

    Regards

    Alan

     

    On test right now, and with luck 24/7 when the binaural microphone is connected

    http://philae.shoutca.st:8381/stream

  • Matthias, thanks so much for getting this working and posting all the information that is necessary as well as maintaing the kernel updates.

     

    I was was wondering if anyone knows if it's possible to record audio and play it back at the same time? I'm just getting started with this, but any guidance would be very much appreciated! Thank you!

  • in reply to parkej60

    I use darkice on the Raspberry Pi 3 with the cirrus logic audio card.

    I downloaded Jessie, updated it with apt-get update. installed (not sure if I needed to), LAME, vorbis, updated and upgraded, installed darkice - following this

    then performed the simple patch and edits to a few files, and added the audiocard script that I wanted to use to /etc/rc.local with a stop gap "sleep 20s" before adding "sudo darkice &" in the file.

     

    Darkice.cfg has an option to record to file dump, though I just stream the audio to an on-line Icecast server (or just use you're own from the darkice link).

     

    There are many other ways that I'm sure others will point you in the right direction too.

     

    Great fun.

  • in reply to parkej60

    I was was wondering if anyone knows if it's possible to record audio and play it back at the same time? I'm just getting started with this, but any guidance would be very much appreciated! Thank you!

    Yes, this'll work. The card is "full duplex" capable, you can record and play streams at the same time.

     

    An alternative to doing it in software (which will always have some latency) is to setup the card's mixer so that for example the signal on line-in is output on line-out with (almost) zero delay. Have a look at this thread for details:

    https://www.element14.com/community/message/114756/l/re-read-in-from-the-headset-jack-and-read-out-to-the-amplifier#1147…

     

    so long,

     

    Hias

  • in reply to hiassoft

    Hi Mattias, It's taken me a while to come back about this sorry. I've been trying every conceivable way to try to get this working but it's still not working for some reason. I have been trying to build from your repository, first using buildroot and then when it didn't work I tried to do it manually using the commands below :-

     

    I took your 4.1.y cirrus rpi-linux :-

    git status

    On branch cirrus-4.1.y

    Your branch is up-to-date with 'origin/cirrus-4.1.y'.

     

    I've used the following commands and built the kernel from your config , modules & dtb

     

    /opt/projects/rpi-linux$ /usr/bin/make -j5 -C /opt/projects/rpi-linux HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=arm INSTALL_MOD_PATH=/opt/projects/rpi-linux/modules CROSS_COMPILE="/opt/projects/buildroot-gr/buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabihf-" bcm2709_defconfig

     

     

    /usr/bin/make -j5 HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=arm INSTALL_MOD_PATH=/opt/projects/rpi-linux/modules/ CROSS_COMPILE="/opt/projects/buildroot-gr/buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabihf-" -C /opt/projects/rpi-linux zImage

     

     

    /usr/bin/make -j5 HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=arm INSTALL_MOD_PATH=/opt/projects/rpi-linux/modules/ CROSS_COMPILE="/opt/projects/buildroot-gr/buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabihf-" modules

     

     

    /usr/bin/make -j5 HOSTCC="/usr/bin/gcc" HOSTCFLAGS="" ARCH=arm INSTALL_MOD_PATH=/opt/projects/rpi-linux/modules/ CROSS_COMPILE="/opt/projects/buildroot-gr/buildroot/output/host/usr/bin/arm-buildroot-linux-gnueabihf-" dtbs

     

    I have at the moment manually put the Zimage ( as kernel.img ) in the boot directory

    moved the arch/arm/boot/dts/*.dtb to boot partition and arch/arm/boot/dts/overlays*.dtb to boot partition ./overlays

    I've moved the modules to /lib where they are at /lib/modules/v.1.20-v7/ also firmware was moved to /lib/firmware

     

    My config is the same as it was which is the same as yours. The /etc/modprobe.d/cirrus.conf is the same

     

    My board boots but there are no messages at all in dmesg about any of the card interfaces , i2c etc..

     

    I can't run vcdbg as although I have installed it there is no msg file, I do have dtdebug=on

     

    The rootfs is not raspbian though , it's custom from buildroot using packages I've told it to include. rpi-firmware is one of these which is where I get my startup.elf etc.. files

     

    The issue is that it doesn't even try to load the devices. In fact it doesn't even seem to see the i2c bus.

     

    I've compared my SDcard with one made with one of your pre-built images. My config.txt is the same. I noted that you originally loaded kernel7.img but don't see that in config.txt . Is that a change you did in startup? or is this to do with the older 3.18 version I have as an SDcard image?

     

    On my buildroot image my partitions do not seem to be named. I.E. if I put the SDcard I made in the PI2 I don't see boot named as the partition , how important is the name?

     

    Next I notice when I make dtbs from your config I get only rpi-2-b and rpi-3 device overlays, that is correct?

     

    I've run out of things to check

     

    Best Regards

     

    Rob

  • in reply to e14 Contributor

    I2C must be enabled if you build your own rootfs. By default in many distros it is not enabled!

    Clem

  • in reply to clem57

    Hi Clem, Not sure what you mean by that?  Surely if I'm using the bcm2709_defconfig for building the kernel provided by https://github.com/CirrusLogic/rpi-linux 

    in the 4.1.y branch the i2c will be part of the kernel configuration provided there and as long as my kernel, dtb and associated kernel modules built from here are on the rootfs partition ( in /lib ) then it should boot the card?  Or are there userspace libraries needed aswell?

     

    Best Regards

     

    Rob

  • in reply to e14 Contributor

    Hi Rob!

    I have at the moment manually put the Zimage ( as kernel.img ) in the boot directory

    You need to run "scripts/mkknlimg" from the kernel tree to generate kernel.img/kernel7.img, otherwise the devicetree stuff won't work at all. eg

    ./scripts/mkknlimg arch/arm/boot/zImage /boot/kernel7.img

     

    The kernel for RPi2+3 should usually be named kernel7.img, the kernel for RPi1 kernel.img - the GPU firmware uses these names by default (so you can have a system bootable both on RPi1 and on RPi2/3) but will automatically fallback to kernel.img when it can't find a kernel7.img.

     

    If you want to build kernel/modules/dtbs for RPi1 you have to do it in a separate directory (or completely clean the RPi2 binaries before) and use "make bcmrpi_defconfig". Then you'll get the dtb files for RPi1, but not for RPi2/3 - and of course kernel and modules runnable on the RPi1.

     

    As for debugging: try to get vcdbg log working, that's really helpful. It'll only work as root and outputs to stderr instead of stdout so eg on raspbian you have to use "sudo vcdbg log msg 2>&1 | less" to get output. Maybe you are missing some library on the target system, vcdbg links to /opt/vc/lib/libdebug_sym.so and /opt/vc/lib/libvcos.so on Raspbian - check with ldd.

     

    so long,

     

    Hias

  • I've uploaded a new precompiled kernel, based on kernel 4.4.6:

    http://www.horus.com/~hias/tmp/cirrus/cirrus-linux-4.4.6.tgz

    The source code can be found here: https://github.com/HiassofT/rpi-linux/tree/cirrus-4.4.6

     

    Changes since the last version:

    • Switch to kernel 4.4 series, version 4.4.6
    • Remove now obsolete non-devicetree code from driver

     

    Important notes if you update from kernel 4.1.y:

    1. Update the GPU firmware using sudo SKIP_KERNEL=1 rpi-update before installing the 4.4 kernel. Failing to do this may result in various errors or a non-booting system!
    2. Check that you have dtoverlay=rpi-cirrus-wm5102 in your config.txt, the old variant dtoverlay=rpi-cirrus-wm5102-overlay is no longer supported.

     

    Installation and configuration instructions and troubleshooting hints can be found on my website:

    http://www.horus.com/~hias/cirrus-driver.html

     

    so long,

     

    Hias

  • in reply to hiassoft

    Hi Hias, The issues I am having were due to the way devices were registered. The build system was using /tmpfs only . When I changed this to devtmpfs with eudev option the modules now try to load. However all is not well. Even if I use my rootfs with your prebuilt kernel and modules I get the same problem as myself :-

     

    [    3.977633] udevd[75]: starting version 3.1.5

    [    4.014171] random: udevd urandom read with 78 bits of entropy available

    [    4.062315] udevd[75]: specified group 'xenomai' unknown

    [    4.385334] snd-rpi-wsp sound: ASoC: CPU DAI (null) not registered

    [    5.144403] bcm2835-rng 3f104000.rng: hwrng registered

    [    5.155435] snd-rpi-wsp sound: ASoC: CPU DAI (null) not registered

    [    5.157030] bcm2708_i2c 3f804000.i2c: BSC1 Controller at 0x3f804000 (irq 79) (baudrate 100000)

    [    5.159863] gpiomem-bcm2835 3f200000.gpiomem: Initialised: Registers at 0x3f200000

    [    5.160797] spi spi0.1: setting up native-CS1 as GPIO 7

    [    5.206708] snd-rpi-wsp sound: ASoC: CODEC DAI wm5102-aif1 not registered

    [    5.321515] wm8804 1-003b: revision E

    [    5.322951] spi0.1 supply DCVDD not found, using dummy regulator

    [    5.343449] snd-rpi-wsp sound: ASoC: CODEC DAI wm5102-aif1 not registered

    [    5.365942] arizona spi0.1: Unknown device ID: 0

    [    5.377774] snd-rpi-wsp sound: ASoC: CODEC DAI wm5102-aif1 not registered

     

    edit : this is with kernel 4.1.19-v7 from your tgz together with the installed /lib copied into my rootfs. uname -a shows I'm using the correct kernel. Config.txt hasn't changed. The dtb files are definately the ones I copied over from the cirrus-4.1.19 /boot and so are the overlays

    I get the same issue if I build my own 4.1.20 kernel from scratch , install my modules and dtb from matching kernel and load this way. Exactly same messages

     

    The question is what am I missing. There is a difference between how Raspbian and my buildroot file system registers devices. Do you have any ideas of what to try? I need to add my own WIFI drivers to the image and make it really minimal wso using the raspbian really wasn't what I wanted.

     

     

    Best Regards

     

    Rob