Featured Articles
Announcing Pi
Technical Specifications
Raspberry Pi FAQs
Win a Pi
GPIO Pinout
Raspberry Pi Wishlist
Comparison Chart
Quiz
Group Actions
Engagement
  • Author Author: Former Member
  • Date Created: Date Created
  • Views 1289 views
  • Likes 1 like
  • Comments 8 comments
Related
Recommended

DIY Kernel: CirrusLogic's "Build the Code" Instructions Don't Work

Former Member

I just bought a new copy of the Cirrus Logic Audio Card.  I'm still waiting on delivery of the quadcore Pi 2, so my fallback option is to start off using it on my B+.

 

Rather than downloading and installing the Cirrus Audio linux os image, I'd prefer to keep my existing deployed linux installation and build a new kernel/driver to add support for the card on my existing system.  To do this I'm following CirrusLogic's official "Build the Code" instructions on github:

 

https://github.com/CirrusLogic/rpi-linux/wiki/Building-the-code

 

Unfortunately, the "Build the Code" instructions contain unresolved errors that prevent the user from completing a successful kernel build, unless he takes the time to understand the build instructions, recognize the errors, and fix them on his own.  As supplied, the CirrusLogic instructions are defective the just do not work.  It appears that CirrusLogic's official "Build the Code" guide is just defective.  It almost seems as if someone did a half-baked job of writing the instructions, as it looks like they didn't even bother to verify that the build instructions actually work, because as they are written they will not work.

 

Overall, I'm quite disappointed with my purchase for a couple of reasons:

 

1.  The CirrusLogic Audio card is being advertised as being compatible with the new quadcore RPi2, when the reality is that it doesn't work because the kernel drivers for ARM7 are vaporware.

 

2.  Falling back to using the CirrusLogic Audio Card with ARM6 on the RPi B+ isn't an option, as CirrusLogic's Official "Build the Code" guide contains errors and doesn't even work.

 

CirrusLogic needs to take the time to  fix these problems, so that the product they're selling actually works like it's advertised to work.  Unfortunately, if you take the time to survey the web, you'll find plenty of people who are having problems getting the platform to work.  You shouldn't have to be a linux kernel developer, and you shouldn't have to recognize the errors in CirrusLogic's instructions and correct them yourself in order to get this product to work.  Overall, I'm quite disappointed.

  • in reply to Former Member

    bob p wrote:

     

    I've signed up for the waiting list for the IQaudiO Pi-DAC+.

     

    Hi Bob.  I've signed up too, but just checked the tindie site.  FYI they are reporting expecting more stock in late April.

     

    Cheers,

    John

  • in reply to timg73

    ...  I did not attempt cross-compilation, and followed the normal process for native compilation of a generic Debian kernel.  This worked well for me on a fresh installation of Raspbian, and although it took about 10 hours to complete I wasn't in a rush and just left it to run over night.

    Thanks for posting this.  10 hours is a trivial amount of time to spend compiling a kernel in the native environment of an embedded-type device.  As you said, it would be simple enough to allow the compile to proceed overnight.  Forcing the user to compile on an external linux box is a really bad idea.  Native compiling on the Pi is a direct, straightforward, and simple -- albeit lengthy -- process.  Expecting a user to succeed in cross-compiling a 32-bit OS on an alien 64-bit platform is just plain silly.  Anyone who thinks that is a good idea just doesn't realize that they are asking for trouble.  I've spent more than the equivalent of 10 hours of native compiling time just trying to solve these poorly conceived/totally avoidable cross-compiling problems.

     

    Note that the wiki instructions download much more data than necessary.  Replace the git-clone command by

    Indeed, the wiki instructions force the user to download ~2 GB of unnecessary bulk.  Thanks for posting your replacement command.  It does make things easier.  When I consider that the Cirrus instructions are forcing me to download ~2 GB of unnecessary bulk while your version of the command trims that bulk significantly, it's evident that someone at Cirrus didn't really understand what was necessary and what was not.  They just force you to download a lot of unnecessary bulk because they lack understanding of what is necessary and what is not.

     

    Alternatively you can skip downloading and  compiling the source entirely.  I've compiled the most recent "Cirrus Logic" kernel and uploaded it as a Debian package.  You can find it here:

    http://www.element14.com/community/thread/40824/l/kernel-as-deb-package

    Install as described, and modify /etc/modules & /etc/modprobe.d/raspi-blacklist.conf as detailed in the wiki.

     

    Thanks for posting this.  Insofar as we are using Fedora 21 x64 in-house, and I'm running Pidora/F18 on the Pi, the Debian-based dialects aren't the most direct solutions for me.  I think that instead of debugging the cross-compiling problem and rewriting the installation guide for the benefit of CirrusLogic, I think I'll just do a native compile on the Raspberry Pi.  I honestly don't understand why the authors of the Cirrus guide chose to force users to cross-compile on a different platform.  That's really dumb.  Considering that compiling natively on the Pi only takes ~10 hours, there's no reason not to do things the easy way.  By following their poorly-conceived directions and cross-compiling instead of performing a direct/native kernel build, I've wasted more seat-time in debugging the cross-compiler than the Pi would have expended in CPU-time performing a native compile.

    I'm not sure why Cirrus Logic don't distribute their patched kernel as a package.  The disk image seems unnecessarily cumbersome.

    In my opinion, the problem is that the people at CirrusLogic haven't put a lot of thought into the way that they're doing any of this.  To me, it looks as if some low-level developer is being allowed to run about willy-nilly without any oversight by a competent project manager, and that the absolute minimum possible amount of time was allocated to this project.  Without any doubt, the instructions and the support for the CirrusLogic card are just plain awful.  Distributing a disk image is unnecessarily cumbersome, and it forces the user to abandon all of the system configuration they have already done on their device.  Allowing a kernel/driver update as a package would be a much more thoughtful solution to the problem.

     

    Overall, none of Cirrus' actions seem particularly well-conceived, and the result has been that I've wasted more time on the CirrusLogic Audio Card than the card is worth to me.  if I had the opportunity to do this all over again, I'd avoid the CirrusLogic/Wolfson Audio Card and I'd avoid wasting so many hours of my life on this stinker of a device.

     

    I've signed up for the waiting list for the IQaudiO Pi-DAC+.  It would be nice to have something that works out of the box as advertised.  I'm a big fan of products that "just work" like they're supposed to.

  • in reply to cstanton

    > ... it could be that you have to 'sudo rm' the file. Did you try this?

     

    Thanks for your help.

     

    The error message states clearly and unambiguously that the problem is an ELF (Executable and Linkable Format) error.  To make sense of this, I guess someone has to possess a detailed understanding of file formats for executables and shared libraries on unix-like systems.  Maybe it would help to bump this problem up to the developers.

     

    Even if someone is not familiar with ELF, there are obvious clues that this problem is not an end-user permissions issue.  Take a close look at your quote of what I posted.  There's a pound-sign in the bash prompt.  I purposefully included it as part of the quote, specifically to communicate to the reader that the commands were being executed as root.  If they had been executed as a non-privileged user, then the pound-sign would have been replaced with a dollar-sign.  That's introductory Bash.  Using "sudo" to "rm" the file isn't part of the problem.

     

    > So I've still no idea what your other errors exactly were...

     

    Take a close look at the bash commands in the Cirrus guide, the errors are blatantly obvious.  The level of proofreading that went into writing the guide is nothing short of pathetic.  I'm not going to provide a complete list of fixes.  Someone at Cirrus and/or Element14 gets paid to do that, and I'm not going to do that person's job for them.  As others have mentioned in the forum, the lazy CirrusLogic developers will never take on the responsibility of doing their job properly if end users like me keep volunteering to do their job for them.

     

    Thanks again for your help.

  • in reply to Former Member

    So I've still no idea what your other errors exactly were, I'm not currently in a position to attempt to replicate (I'm sure I will later), but my preliminary thought on:

    # rm /tmp/modules.tgz

    -bash: /usr/bin/rm: /lib/ld-linux-armhf.so.3: bad ELF interpreter: No such file or directory

    Is that you typically have to be root to remove any files in /tmp/ - though It's not clear what the error alludes to, it could be that you have to 'sudo rm' the file. Did you try this?