Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
Raspberry Pi Wishlist
Actions
Forum Thread Details
  • Replies 180 replies
  • Subscribers 689 subscribers
  • Views 23021 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

Parents

  • Hias,

     

    Thanks for your hard work producing these kernel patches. Any chance of a precompiled 4.1.7 kernel?


    Paul

  • in reply to Former Member

    Thanks for your hard work producing these kernel patches. Any chance of a precompiled 4.1.7 kernel?

    Here's a precompiled tarball of the current 4.1.12 kernel:

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

     

    @Ed: thanks a lot for the Arch pkgbuild, that's really cool!

     

    so long,

     

    Hias

  • in reply to Former Member

    Esmi Schildburg wrote:

     

    thanks for your response. I will do that today evening. I'm know following a lead, that my noobs-installer could be the cause of the problem....could that be?

    I'm not familiar with noobs, but it could be - for example if you edited config.txt on the wrong partition. So I wouldn't rule that out as a possibility.

     

    A simple way to check if the dtoverlay was loaded is to look at the files in /proc/device-tree/sound/ .

     

    If the overlay is loaded you should have a file named "compatible" there with the contents "wlf,rpi-wm5102". You also should have a file "status" with contents "okay" and a file "i2s-controller".

     

    If these files are missing, something went wrong with the dtoverlay or the overlay files. The "vcdbg log msg" output should reveal the details. Ah, BTW, since you are using noobs you might have to add the "dtdebug=1" to the noobs config.txt file on the primary partition - but I'm not sure about that.

     

    so long,

     

    Hias

  • in reply to Former Member
    Ok, here are the logs

    Thanks! It looks like not only it didn't find the overlay but also booted an old kernel (4.1.7 instead of 4.1.13).

     

    So quite certainly the files the boot/* files in the tarball (kernel and overlay) ended up on the wrong partition.

    regarding NOOBS: I mounted mmcblk0p5 to copy the new kernel bootfiles in it (as I read in a nother board) - but they seem to be the same content as root/boot

    Hmmm... Sorry, can't help with that. I'm a total noob regarding NOOBS image

     

    so long,

     

    Hias

  • in reply to hiassoft

    okay, thank you - so the /boot - / NOOBS - thing seems to be the problem

     

    At the moment I am short on SD-Cards - I will try it with an raspbian image without noobs next week

     

    But thanks for your insight!

  • in reply to Former Member

    okay - solved^^

     

    I doublechecked - and well.... it seems I didn't really extract the tgz file - I just unpacked in in a tar file - so there was indeed no new kernel image

  • in reply to Former Member

    Esmi Schildburg wrote:

     

    okay - solved^^

     

    I doublechecked - and well.... it seems I didn't really extract the tgz file - I just unpacked in in a tar file - so there was indeed no new kernel

    Cool, glad you got it working!

     

    Did you have to do anything special regarding NOOBS?

     

    so long,

     

    Hias

  • in reply to hiassoft

    Since someone asked if the provided compiled kernel can be used with Arch Linux: I was able to use the provided 4.1.13 kernel without any problems on my Arch Linux based Runeaudio installation.

  • in reply to hiassoft

    Hello,

     

    Thanks for the great work! The availability of a precompiled driver is what actually decided me to order this card.

     

    I received my card yesterday, and successfully managed to install the 4.1.13 kernel onto the latest Raspbian Jessie Lite. I began by testing the line output, it worked nicely first attempt. A good start I told myself :-)

     

    However, what I am interested in in the first place is the SPDIF output. Sadely, I could not manage to make it work (I did ran the SPDIF_playback.sh use case). I could not detect any activity on my DAC coming from the card (I tried differents cables to make sure). The DAC works nicely with my CD player.

     

    Someone had success with the SPDIF output?

  • in reply to elb

    Hi Eric!

    However, what I am interested in in the first place is the SPDIF output. Sadely, I could not manage to make it work (I did ran the SPDIF_playback.sh use case). I could not detect any activity on my DAC coming from the card (I tried differents cables to make sure). The DAC works nicely with my CD player.

     

    Someone had success with the SPDIF output?

    SPDIF out is working fine here, I'm using it almost every day with OpenELEC.

     

    Try running "SPDIF_playback.sh -q", the '-q' option will suppress normal output and you'll only see errors on the console. If everything works fine you should see no console output at all.

     

    What kind of file did you try to play? SPDIF on the Cirrus card only supports 32-96kHz stereo files.

     

    so long,

     

    Hias

  • in reply to hiassoft

    Hi Mathias !

     

    What kind of file did you try to play? SPDIF on the Cirrus card only supports 32-96kHz stereo files.


    My DAC is a Wadia X32 dating from the 90's. It supports 16 bits 44.1/48 KHz. If the Cirrus card only supports 32-96KHz, then I'm stucked image.


    However that does not comply with the card documentation. Extract p. 17 under SPDIF Output:

    Supported Sample Rates     32, 48, 96, 192, 44.1, 88.2, 176.4, 192 KHz

    Sample depth     Max bit depth of samples     24     bits


    By the way, SPDIF_playback.sh -q gives no output at all.

  • in reply to elb

    Hi Eric!

     

    The Cirrus card should do 16-bit 44.1/48kHz stereo just fine (and, yes, it should go up to 192kHz as mentioned in the datasheet - sorry, my fault).

     

    No output from SPDIF_playback.sh -q is fine, too.

     

    Just tested again here, kernel 4.1.13 on a RPi2, playing a 44.1kHz 16-bit stereo WAV worked fine (I'm using a Behringer SRC2496 as a DAC here). So I'm not sure what's going wrong...

     

    so long,

     

    Hias

Reply
  • in reply to elb

    Hi Eric!

     

    The Cirrus card should do 16-bit 44.1/48kHz stereo just fine (and, yes, it should go up to 192kHz as mentioned in the datasheet - sorry, my fault).

     

    No output from SPDIF_playback.sh -q is fine, too.

     

    Just tested again here, kernel 4.1.13 on a RPi2, playing a 44.1kHz 16-bit stereo WAV worked fine (I'm using a Behringer SRC2496 as a DAC here). So I'm not sure what's going wrong...

     

    so long,

     

    Hias

Children
  • in reply to hiassoft

    Hi Mathias!

     

    I've done some tests during the weekend, unfortunately with no success. What happens is the led on the Wadia sparkles when connected to the SPDIF output of the Cirrus Logic card. When I play a file, the Wadia correctly detects the rate (I tried both 44.1 and 48 KHz, 2 rates supported by the X32), but it cannot achieve to lock on the SPDIF signal. The led does not fully light up, and I hear an internal relay switch randomly while the file is playing. Of course there is no sound.

     

    I also tried to power the card and the Pi via the auxiliary power input (with a 1 A power supply). Same result. Maybe I'll try a more powerfull power supply some time.

     

    I'd had the same result with a Hifiberry Digi, which is not very surprising because I think both cards use the same SPDIF module. So it seems there is an incompatibility between the WM8804 and old DACs (I've read a user reporting the same issue using a Hifiberry Digi with another 90s DAC). At least, I can enjoy the analogic output until I find another solution. This is already a major improvement other the Pi default sound :-)

     

    Anyway I'll continue to watch this thread, which is a great value for Cirrus card owners !

  • in reply to elb

    Hi Eric!

    I've done some tests during the weekend, unfortunately with no success. What happens is the led on the Wadia sparkles when connected to the SPDIF output of the Cirrus Logic card. When I play a file, the Wadia correctly detects the rate (I tried both 44.1 and 48 KHz, 2 rates supported by the X32), but it cannot achieve to lock on the SPDIF signal. The led does not fully light up, and I hear an internal relay switch randomly while the file is playing. Of course there is no sound.

    A quick google search turned up this old article: Wadia Digimaster X-32 digital processor Page 2 | Stereophile.com

    Many people bought X-32s only to discover that they would not lock to their CD players' digital outputs.

    ...

    Wadia has solved this problem by supplying with each X-32 an additional Read-Only Memory (ROM) chip. The socket-mounted ROM that comes in the unit configures the programmable gate-array chips described earlier. If the X-32 will not lock to your CD player, the ROM must be replaced with the extra chip supplied, which fortunately is very simple to do.

    This reads like your DAC is very picky about the input signals and the manufacturer was aware of the fact. If you still have the extra chip for your DAC you could give that a try.

     

    so long,

     

    Hias

  • in reply to hiassoft

    Hi Mathias!

     

    Thank you for your interest. Unfortunately, I don't have this extra chip, and after some searching on the net, it feels definitely hard to lay hands on one.

     

    This point does not surprise me much. Indeed some Wadia DACs owners I know are making and selling kits for CD players to replace the oscillator and improve the SPDIF signal accuracy and shape. The aim is to seek very low jitter. Too bad the Cirrus card cannot work with the X32, because it is a so brilliant machine. I would love to be able to make it work together with the Pi.

     

    Eric