zybo Problems with audio driver in Petalinux

[jaxc]

Hello, I am trying to connect to the DAC using petalinux, but I cannot get it to work. When petalinux is booted i get "axi-i2s: probe of 43c00000.axi_i2s_adi failed with error -2", I have tried to find information about this, but so far i haven't found anything.

So, what I have done:

I have synthesized the template design and imported the said design into Petalinux.

I have configured ALSA as this:

The device tree for the axi-i2s is as follows:

    amba_pl: amba_pl {
        axi_i2s_adi_0: axi_i2s_adi@43c00000 {
            compatible = "adi,axi-i2s-1.00.a";
            reg = <0x43c00000 0x10000>;
            clocks = <&clkc 15 &clkc 16>;
            clock-names = "axi", "i2s";
            dmas = <&dmac_s 0 &dmac_s 1>;
            dma-names = "tx", "rx";
            xlnx,bclk-pol = <0x0>;
            xlnx,dma-type = <0x1>;
            xlnx,has-rx = <0x1>;
            xlnx,has-tx = <0x1>;
            xlnx,lrclk-pol = <0x0>;
            xlnx,num-ch = <0x1>;
            xlnx,slot-width = <0x18>;
            };
        };

 

I am deeply grateful for any help, or any examples showing a working DAC interface.

 

Best regards

/Jaxc

[jkoller]

I can confirm this works!!  I built this using a standard petalinux 2015.4 flow, with the device tree saved as

.../subsystem/linux/configs/device-tree/system-top.dts

The kernel config (dummy.config) saved as:

.../subsystem/linux/configs/kernel/config

I am also booting with linaro root_fs, so I also copied 

.../build/linux/rootfs/targetroot/lib/modules/4.0.0-xilinx

to

[MY SDCARD ROOT_FS]/lib/modules/.

>>>>>

root@linaro-ubuntu-desktop:~# aplay -L
null
    Discard all samples (playback) or generate zero samples (capture)
pulse
    PulseAudio Sound Server
default:CARD=ZYBOSoundCard
    ZYBO-Sound-Card, 
    Default Audio Device
sysdefault:CARD=ZYBOSoundCard
    ZYBO-Sound-Card, 
    Default Audio Device
dmix:CARD=ZYBOSoundCard,DEV=0
    ZYBO-Sound-Card, 
    Direct sample mixing device
dsnoop:CARD=ZYBOSoundCard,DEV=0
    ZYBO-Sound-Card, 
    Direct sample snooping device
hw:CARD=ZYBOSoundCard,DEV=0
    ZYBO-Sound-Card, 
    Direct hardware device without any conversions
plughw:CARD=ZYBOSoundCard,DEV=0
    ZYBO-Sound-Card, 
    Hardware device with all software conversions
root@linaro-ubuntu-desktop:~# speaker-test

speaker-test 1.0.25

Playback device is default
Stream parameters are 48000Hz, S16_LE, 1 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 64 to 65536
Period size range from 32 to 32768
Using max buffer size 65536
Periods = 4
was set period_size = 16384
was set buffer_size = 65536
 0 - Front Left
Time per period = 1.375699
 0 - Front Left
 

Further, recording works!  at least at "dat" quality, or 48000Hz for now.

root@linaro-ubuntu-desktop:~# arecord -t wav -c 2 -d 5 -f dat input.wav
Recording WAVE 'input.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo

root@linaro-ubuntu-desktop:~# aplay -d 5 -f dat input.wav 
Playing WAVE 'input.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
 

this works, but will cause clicks in the audio: (I am fiddling with alsaloop to get a decent loopback from input to output)

root@linaro-ubuntu-desktop:~# arecord -c 2 -f dat |aplay -c 2 -f dat
Recording WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
Playing WAVE 'stdin' : Signed 16 bit Little Endian, Rate 48000 Hz, Stereo
 

 

Thanks!!!

[sbobrowicz]

Sorry I missed your post, I had some issues with my notification settings.
 

On 6/6/2016 at 1:46 PM, jkoller said:

I can use the prebuilt image and boot via jtag, or build my own (from all default configs), and boot that via SD card.  I haven't been able to boot custom images via JTAG, unless I package them as a prebuilt image first.  I'm not sure why, but I won't use JTAG for very long, once I get my rootfs back on line anyway.

Yea, JTAG boot in petalinux has also been a bit screwy to me too... I tend to avoid it. My favorite petalinux programming method is to use an SD card for BOOT.BIN, and have u-boot look for image.ub over TFTP. This lets you simply press the PS-RST button to use the new files after you run petalinux-build, no copying to SD necessary .

On 6/6/2016 at 1:46 PM, jkoller said:

 tigerVNC allows me to operate in a headless configuration, but still have command line and X programs, and using fluxbox as a window manager, it's fairly light on these processors and memory.

Thanks for tip, this makes a lot of sense. I will give it a shot next time I get a chance to.

On 6/6/2016 at 1:46 PM, jkoller said:

petalinux + Linaro as rootfs has the advantage of script builds and apt-get for the moment

This is my preferred environment for deploying projects that benefit from using third party software. Using petalinux + Xilinx SDK and debugging with TCF agent is awesome for developing your custom application, but trying to bring third party software into the petalinux environment can be a pain and often Yocto recipes don't exist. Deploying your application into a linaro rootfs makes installing additional software a breeze. Gotta love that apt-get. 

On 6/6/2016 at 1:46 PM, jkoller said:

Hopefully I don't get ".bit" again with hardware changes.

Solid.

On 6/6/2016 at 2:19 PM, jkoller said:

should the device tree autoconfig include directory be changed to point to the remote kernel code source directory, or does petalinux figure this out on it's own?

I might be wrong, but I don't think this is a setting that really matters. The help info on that setting says it is used as an include directory for DTC, which is the device tree compiler. I'm not really certain what it is that exists in there that the device tree compiler needs, but I'm pretty sure it is not something that we would have changed in our kernel fork compared to Xilinx's fork. I'll look into why this doesn't point to the project's kernel tree (aka the downloaded remote tree), but I don't think it will cause problems.

On 6/6/2016 at 2:19 PM, jkoller said:

I'd also like to modify the kernel source

This one is a toughy... If you just want to build a loadable module, I believe petalinux has a process for that, but significantly patching the kernel doesn't seem to be very well supported. I would advise against modifying stuff in the build directory since it is all pretty "volatile", but that might work despite being a bit hacky. My bet is that the cleanest way to accomplish this is to create a github account, fork our linux repo, push your needed changes to it, and then modify your petalinux project to point to your remote tree.

[jkoller]

I did notice that this petalinux project sources a remote kernel from Digilent, and the configuration shows this.  So the kernel source is downloaded to {$PROJECT/build/linux/kernel/download/linux-digilent} before being built.  However, during project level petalinux-config, I noticed the autoconfig directory for device tree points to the default {/opt/petalinux-v2015.4-final/components//linux-kernel/xlnx-4.0/include} directory. My understanding is that both kernels are 4.0.0, so this will work until someone tries to build with a PMOD device that needs special drivers from the remote kernel...should the device tree autoconfig include directory be changed to point to the remote kernel code source directory, or does petalinux figure this out on it's own?

I'd also like to modify the kernel source.  Do you recommend I copy the Digilent kernel into $PROJECT/components/kernel first?  Or should changes be made within build/linux/kernel/download?  I'm not sure how the scripts and makefiles grab the source code for the kernel, and whether changes go into "download" or if they go into the linux-digilent directory.  I'll go through the makefiles, but your help could save me some time.  Thanks!

[jkoller]

Apologies for the long delay.  I did get the Zybo Base demo working, and audio seems to be working OK.  I think at this point I had a mix of petalinux not updating the BOOT.BIN with the correct .bit file (despite using the documented methods of forcing this rebuilt), but still using the expected system.dtb, so hardware and software were not aligned.

So, I made some (more) petalinux projects, based solely on the default files found in the petalinux quick-start found here:

https://github.com/Digilent/petalinux-bsps/wiki/Quick-start-guide

I can use the prebuilt image and boot via jtag, or build my own (from all default configs), and boot that via SD card.  I haven't been able to boot custom images via JTAG, unless I package them as a prebuilt image first.  I'm not sure why, but I won't use JTAG for very long, once I get my rootfs back on line anyway.

Next I'll try to get back to where I was...patch the linux kernel with preempt_RT, get a rootfs with all the software I am using (tigerVNC and a plethora of audio software), and then modify the hardware image to ditch the video hardware and free up the PL for custom logic.  tigerVNC allows me to operate in a headless configuration, but still have command line and X programs, and using fluxbox as a window manager, it's fairly light on these processors and memory.

Thanks for the updated quick start guides, and the BSP releases.  I will migrate to a custom Yocto build eventually, but petalinux + Linaro as rootfs has the advantage of script builds and apt-get for the moment.  Hopefully I don't get ".bit" again with hardware changes.

[jkoller]

Early next week, I'll try the zybo base design first, and see how that goes.  Thanks for that tip Tommy, and if that doesn't work, I'll look into an RMA, thanks Sam!

I also forget to mention, in the process, I found out the hard way about the makefile bugs for FSBL.  I see them mentioned in your new petalinux guide.  When I built images for testing the 12.000MHz clock for the codec, thinking back I'm not sure the FSBL and BOOT.bin were correctly made.  So 12.000MHz may still be an option for the full palette of sample rates.

 

[sbobrowicz]

If your codec isn't working, message Tom21091 on the forum to start an RMA request.

[TommyK]

Hi jkoller,

You can try running the prebuilt BOOT.bin file in the Zybo Base System Design Project to test if your Audio Codec is working or not.

[jkoller]

Damn.  Debugging further, and I started to hit several roadblocks during bootup.  So I retraced my steps and went back to the beginning with a new project, kernel, etc.  And now any time I enable the SSM2602, my boot sequence is stuck.  Any boot without it, and all is well.  I'll see if I can compile as a modprobe/module, and dig further, but I fear my codec is fried.  I'll see if I can debug the kernel, but I may just move on to USB audio....

( I had brought up an RT patched 4.4 kernel with low latency and such...)

[jkoller]

48000 and 32000 seems to work OK, but 44100 does not play tones correctly.  To check this, I used

speaker-test -f 440 -t sine -c 2 -r 44100 (or 48000/32000)

I hear the sine 440Hz is different, and using a chromatic tuner app on my phone, confirmed that 48k and 32k are correct.

[sbobrowicz]

Yup, switching to a 12 MHz clock was what I was alluding to when I said we were hoping to add support for additional frequencies in the future. Kudos for tracking this down and giving it a shot before we could. Please let us know how it works out. I'm curious to see if this fixes some of the additional problems we see with the audio too.

[jkoller]

As an experiment, I modified the hardware design, to change the clk_wiz_0 generator from 12.288MHz to 12.000MHz.  I also changed the device-tree file to match as follows:

i2s_clk: i2s_clk {

compatible = "fixed-clock";

#clock-cells = <0>;

clock-frequency = <12000000>;

clock-output-names = "i2s_clk";

};

Even though this is a USB mode, according to the ADI SSM260* spec, I can now see more typical rates available (such as  32kHz and 44.1KHz).  Not sure why, but it seems ok after playing back files recorded at different sample rates.  I tried to avoid software sample rate conversion, and the sample rates reported seemed correct, so maybe this way is easier than the alternative, which is to modify the driver and hardware to control the clk_wiz_0 to change the MCLK sent to the codec depending on the selected sample rate.

I still have more digging to do to verify this.

[sbobrowicz]

OK, we got this working. Here is what you need to do:

Your BOOT.bin built with the linux_bd project should work just fine. 

Please use the newly attached device tree instead of the one from my last post.

Make sure you have the most up-to-date kernel (on digilent github, same as above). You can use the .config included with my last post, but enable these two additional options as built in:

SND_SOC_SSM2602_I2C

SND_SIMPLE_CARD

You might also want to increase the CMA size to at least 40MB if you are using ubuntu desktop( this is in Driver Options-->Generic Driver Options). You can also add consoleblank=0 to the bootargs in the attached devicetree to prevent the desktop from getting into the unwake-able sleep state.

Note that currently only sample rates of 8KHz, 12KHz, 16KHz, 24KHz, 32KHz, 48KHz, and 96KHz are supported. This will hopefully be extended with a future release. The driver also seems to get into a state where playback stops working correctly. We have not been able to fully characterize this bug yet. In my experience, I seem to be able to trigger it with rapid start/pauses of playback, or when trying to playback on HP out or record on Line In in mono mode (these connectors are dual channel and should be used in stereo mode, e.g. -c 2 with arecord or aplay).

A petalinux BSP and a Yocto BSP for the ZYBO with video output on HDMI and Audio codec support is on the way, keep an eye on the ZYBO resource center which is where they will be posted/documented. 

plnx_fixed_snd.zip

Edit: fixed consoleblank suggestion

[jkoller]

I was able to recreate the hardware, export to SDK, use this kernel config you provided, and also copied the device-tree provided into a petalinux system-top.dts.  Builds and boots fine.  However, there is no ALSA sound card registered, and I do not have a /dev that matches the ADI SSM2603, so I am trying to build these drivers as modules, instead of built-in.  I'm using Linaro/Ubuntu as rootfs.  What from the petalinux build gets copied into my rootfs /lib/modules? (I think this needs to be done, since the modprobe can't be run as /lib/modules isn't populated yet).

I think it needs to come from build/linux/rootfs/targetroot, but there's a lot there, and I'd like to get the dir tree correct to avoid headaches in the rest of the module debug.

[sbobrowicz]

I just pushed a project called linux_bd here: www.github.com/digilent/ZYBO. The audio in that project is not tested, but it should be connected such that it works in linux.

I've attached a device tree that should work with it, but I admit I haven't even tried to build it yet. It was reverse compiled so it is pretty ugly. 

If you use that project and device tree with the linux-digilent kernel (on same github as above) then it might work. I've also attached a .config for the kernel that will enable video output on HDMI (remove the "dummy" from the filename). You will need to set the following 2 additional parameters using menuconfig:

SND_SOC_SSM2602_I2C (just search for it in menuconfig). 

   -> Kernel Hacking
      -> Compile-time checks and compiler options
           -> Debug Filesystem [*]

I'm not really certain if the Debug Filesystem is necessary or not.

None of this is tested yet, so sorry if it doesn't work. We are using these components to put together a petalinux and yocto BSP for the ZYBO, but it isn't ready yet. I hope this helps for now. BTW, I based all of this info on information I found in the zedboard_osd platform included with SDSoC 2015.4. That platform has audio enabled for the ZedBoard in linux. You might find the additional libraries and apps found in that package useful for testing alsa. Check out the "how-to-build-this-image.txt" in the boot folder of the platform for some additional info. 

zybo_audio.zip

[jkoller]

I am at this same place. Was this with the Digilent axi_i2s_adi_1.2 interface (as found in the latest digilent-vivado-library.git)?  I did not see this updated IP in a release zybo_base_system.

[jaxc]

Nice catch!

 

I will try with this when I get the time for it. 

 

/Jaxc

[RoTTe]

Hi,

The documentation from this part is basically ..... useless (and usually slows you with erroneous parts). An example:

clock-names = "axi", "i2s";

This line define the clocks for devm_clk_get on the Device Tree, if you check the driver (axi-i2s.c 3.15.x):

204         i2s->clk = devm_clk_get(&pdev->dev, "axi");
205         if (IS_ERR(i2s->clk))
206                 return PTR_ERR(i2s->clk);
207 
208         i2s->clk_ref = devm_clk_get(&pdev->dev, "ref");
209         if (IS_ERR(i2s->clk_ref))
210                 return PTR_ERR(i2s->clk_ref);

So you need to change your DT to something like this:
clock-names = "axi", "ref";

This make the driver to claim the clock and finalize the probe function but you're a long way to make it work.

I've got something functional with alsa and all controls (I can't use the xilly trick with pulseaudio and the fifo devices), but I'm out of time to sanitize the code. If you can wait some days ... there is hope ,D

 

Gerds,
GG.

 

 

[jaxc]

I will check this out. Thank you

 

/Jaxc

[sbobrowicz]

Hi daxc,

Last time I tried to mess with that driver was on the ZedBoard a few years back, and was not successful getting it to work. I don't think I'm going to be much help in getting it working on the Zybo now...

I've seen some posts out there about getting this working with the ZedBoard, maybe you can build on the work done there. Most of this work has been done by Lars-Peter Clausen and the other folks over at ADI.

 You will have to account for the fact that a different audio codec is on the ZYBO, but they both use the same i2s interface for audio and IIC interface for configuration, so the Vivado hardware configuration and most of the driver framework should be the same.

 

[JColvin]

Hi Jaxc,

I have asked some of our applications engineers about this; they will get back to you here on the forum.

Thanks,
JColvin