I've compiled Linux 3.7.3 but ALSA reports no sound card for OLinuXino micro. Searched the Internet and found that sound is possible with Linux 2.6.35 but did not find where to find relative patches. Any suggestions?
Thanks in advance!
Hi,
I am also trying to fix this "no sound card" issue.
I have found this document, with quite a lot of information (chapter 14) :
http://wiki.emsym.com/images/6/6a/I.MX233%E6%A0%B8%E5%BF%83%E6%9D%BF%E4%BA%8C%E6%AC%A1%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97%E2%80%94%E2%80%94%E8%BD%AF%E4%BB%B6%E9%83%A8%E5%88%86.pdf (http://wiki.emsym.com/images/6/6a/I.MX233%E6%A0%B8%E5%BF%83%E6%9D%BF%E4%BA%8C%E6%AC%A1%E5%BC%80%E5%8F%91%E6%8C%87%E5%8D%97%E2%80%94%E2%80%94%E8%BD%AF%E4%BB%B6%E9%83%A8%E5%88%86.pdf)
Maybe it can help you out...
Thank you for this doc! I will read this and try.
Hi,
Did you have any luck with getting sound alive with a 3.x kernel?
Thanks,
-w-
Hi,
installed arch linux with kernel Linux olinuxino 3.7.2-3-ARCH and I have no sound :(
aplay -L -> no devices
Is it possible to switch back to an older kernel?
Thanks!
Quote from: Hellgringo on May 31, 2013, 03:08:08 PM
Hi,
installed arch linux with kernel Linux olinuxino 3.7.2-3-ARCH and I have no sound :(
aplay -L -> no devices
Is it possible to switch back to an older kernel?
Thanks!
Sound and video are not ported on kernel 3.x. You can switch on old 2.6.x.
I'm currently porting the sound driver for 3.9.5.
Quote from: Grawp on June 12, 2013, 03:45:50 PM
I'm currently porting the sound driver for 3.9.5.
Please keep us posted on your progress.
Quote from: Fadil Berisha on June 13, 2013, 10:04:31 AM
Quote from: Grawp on June 12, 2013, 03:45:50 PM
I'm currently porting the sound driver for 3.9.5.
Please keep us posted on your progress.
I certainly will. You can expect some report on Monday.
Sound driver is almost working. Everything seems to be functioning properly (judging from dumped registers' content while running aplay, volume control, etc..) expect for DMA transfer so there is no input/output yet.
I'm trying to use upstream mxs-pcm.
Grawp,
have you made any progress with the sound driver?
I tried porting this driver from 2.6.35 too, but I failed miserably so far (first time trying to hack a kernel module).
I would be interested to try out and help!
I'm sorry I completely forgot to report updates here.
I do have working audio output and input, full-duplex! (Just MIC, Line-in doesn't work yet).
I'll be posting patch to mxs ASoC maintainers when the code is clean&pretty enough (that should be next week).
About setting temporary git repository with the driver.... I would have to consult my employer. But I hope that the driver could make it to Linux by the end of the next week or week after next week. I don't know how often maintainers review patches and when they are merged. I have no experience contributing to Linux yet!
PS: The driver is written for 3.10 kernel.
This is really great!
Is there any chance of getting a patch before this enters the mainline?
I am looking forward to try this, and I am afraid it will take some time before the driver makes it into linux...
Either way, thank you for your quick answer.
Quote from: ggilles on July 04, 2013, 03:24:06 PM
This is really great!
Is there any chance of getting a patch before this enters the mainline?
I am looking forward to try this, and I am afraid it will take some time before the driver makes it into linux...
Either way, thank you for your quick answer.
Well you don't have to wait for mainline kernel. The driver will get to kernel/git/next/linux-next.git and even before that it will land in some development branch affiliated to the MXS or ASoC maintainer. At least I think so. I really don't have any experience with the process.
Just wait for the next week. I'll have more informations. I'm cleaning the code right now anyway.
Quote from: Grawp on July 04, 2013, 02:40:47 PM
I'm sorry I completely forgot to report updates here.
I do have working audio output and input, full-duplex! (Just MIC, Line-in doesn't work yet).
I'll be posting patch to mxs ASoC maintainers when the code is clean&pretty enough (that should be next week).
About setting temporary git repository with the driver.... I would have to consult my employer. But I hope that the driver could make it to Linux by the end of the next week or week after next week. I don't know how often maintainers review patches and when they are merged. I have no experience contributing to Linux yet!
PS: The driver is written for 3.10 kernel.
Very good news.
My suggestion is to publish in http://tech.groups.yahoo.com/group/olinuxino/ or here in this forum. That will insure some preliminary feadback before sending on mainline. For sure you will get response from experienced imx233 kernel developers. Kernel developers prefer to communicate with email and they do not track web forums.
Alternatively, you can contact directly Fabio Estevan, Freescale kernel developer. He is always ready to help others contributors.
Fadil Berisha
Quote from: Grawp on July 04, 2013, 04:19:00 PM
Quote from: ggilles on July 04, 2013, 03:24:06 PM
This is really great!
Is there any chance of getting a patch before this enters the mainline?
I am looking forward to try this, and I am afraid it will take some time before the driver makes it into linux...
Either way, thank you for your quick answer.
Well you don't have to wait for mainline kernel. The driver will get to kernel/git/next/linux-next.git and even before that it will land in some development branch affiliated to the MXS or ASoC maintainer. At least I think so. I really don't have any experience with the process.
Just wait for the next week. I'll have more informations. I'm cleaning the code right now anyway.
Yes, this is correct.
The flow is:
- You submit the patch into alsa-devel mailing list adding the ASoC maintainer (Mark Brown).
- People review your patch and make comments
- When Mark is happy with the patch, it will be applied into his ASoC tree
- His tree is synced with linux-next
- It will be then merged in the next merge window (kernel 3.12)
Let me know if you need help with the submission process.
Good job!
Regards,
Fabio Estevam
Quote from: Grawp on July 04, 2013, 02:40:47 PM
I'm sorry I completely forgot to report updates here.
I do have working audio output and input, full-duplex! (Just MIC, Line-in doesn't work yet).
I'll be posting patch to mxs ASoC maintainers when the code is clean&pretty enough (that should be next week).
About setting temporary git repository with the driver.... I would have to consult my employer. But I hope that the driver could make it to Linux by the end of the next week or week after next week. I don't know how often maintainers review patches and when they are merged. I have no experience contributing to Linux yet!
PS: The driver is written for 3.10 kernel.
Hi Grawp,
did you make any progress on this?
-- Gilles
PS: sorry to bother you again about this, it is just that I really want to get audio working
Quote from: ggilles on July 24, 2013, 02:19:08 PM
Hi Grawp,
did you make any progress on this?
-- Gilles
PS: sorry to bother you again about this, it is just that I really want to get audio working
I'm sorry. I haven't had much time to deal with it recently. We will set up a public git repository with the driver on Monday.
Grawp,
this is really great news.
If you are lacking time to setup a git repository, please consider sending a simple patch against kernel v3.10
git diff v3.10 > awesome_patch_everyone_is_waiting.patch
;-)
https://github.com/ITserve/imx23-audio.git
You should find option for MXS builtin driver in menuconfig.
Please report any bugs.
Hi Grawp,
I think this is missing the DTS entries, could you please push them as well.
Thanks,
-w-
Quote from: wigyori on July 30, 2013, 12:52:09 PM
Hi Grawp,
I think this is missing the DTS entries, could you please push them as well.
Thanks,
-w-
I've just added them. Use imx23-audio.dts or just copy the entries from it. They should work, but I can not guarantee it. I'll test it later... or just tell me if they work.
Grawp,
I have just finished compiling your kernel, added the dts entries, reboot, and IT WORKS!!
Thank you SO much for sharing this! :D
Best regards,
Nice work Grawp, works flawlessly. :) I see a couple todos in the code - do you need any help on those?
I'll push this into openwrt trunk so it would get some further testing, if you don't have objections.
Thanks,
-w-
Good job!
Is anyone planning to submit this upstream?
Regards,
Fabio Estevam
Quote from: wigyori on July 30, 2013, 11:38:08 PM
Nice work Grawp, works flawlessly. :) I see a couple todos in the code - do you need any help on those?
I'll push this into openwrt trunk so it would get some further testing, if you don't have objections.
Thanks,
-w-
There are actually more TODOs. I'll summarize them and push them to git as comments or as separate text files. Help would by appreciated then :) .
Just for quick info:
There are issues as not switching of the mic bias when recording is not active (register logic, values are used from 2.6 driver), no PM, register handling could be more elegant (regmap MMIO may be used).
I certainly don't have any objections against pushing the driver to openwrt trunk.
Can someone help me with getting the driver working on my iMX233 running arch linux?
I have tried the following with no success
Quote
git clone https://github.com/ITserve/imx23-audio.git
Cloning into 'imx23-audio'...
remote: Counting objects: 3143799, done.
remote: Compressing objects: 100% (626375/626375), done.
fatal: Out of memory, calloc failed
fatal: index-pack failed
Thanks!
Quote from: djchristos on August 02, 2013, 05:22:56 PM
Can someone help me with getting the driver working on my iMX233 running arch linux?
I have tried the following with no success
Quote
git clone https://github.com/ITserve/imx23-audio.git
Cloning into 'imx23-audio'...
remote: Counting objects: 3143799, done.
remote: Compressing objects: 100% (626375/626375), done.
fatal: Out of memory, calloc failed
fatal: index-pack failed
Thanks!
Seems you are trying to compile kernel in olinuxino directly. Surely it won't work or will take a very, very, very long time, as the available RAM isn't enough and processor is not very fast. The best you can do is to compile in a Linux PC (i.e. with Debian). You can follow this guide http://www.jann.cc/2012/08/23/building_a_kernel_3_x_for_the_olinuxino_from_sources.html but, instead of cloning koliqi git, clone ITserve Git repo
Hi Grawp,
Do you have the todo list? :) I guess a couple people are awaiting it. :)
Thx,
-w-
Quote from: TioRuben on August 10, 2013, 08:21:51 PM
Seems you are trying to compile kernel in olinuxino directly. Surely it won't work or will take a very, very, very long time, as the available RAM isn't enough and processor is not very fast.
Actually it shouldn't be that bad as the kernel is written in C which compiles on reasonably small RAM (compared to C++). I've compiled u-boot natively before and it was pretty fast (about 15 minutes). I would be surprised if compiling a kernel with a reasonable selection of modules took more then say an hour or so.
OTOH the git kernel repository is enormous and cloning it (and most other git operations) on the olinuxino will lead to trouble. Either do the git operations on some other HW or use a snapshot of a specific version.
HTH,
Harald
BTW: Now I mostly use openwrt for development work which is great except for one thing: I'd really like to edit the device tree natively on the olinuxino instead of writing a new kernel image every time.
Harald, one of the thing that's left in the todo list is to get uboot running and integrated for the imx233 boards. Once that's done, you'll be able to load in your custom DTB files at boot time without rebuilding the kernel.
did this ever make it upstream?
Hello,
As a newbie to compiling Linux kernels (though not to programming in general) I would be most grateful for some assistance in making use of this imx23-audio fork on my OlinuXino-MAXI.
In short, my basic problem is that I have successfully created a working SD card using this kernel, but I am unable to see any audio devices when I use aplay -l or -L.
To expand on this a bit more, the instructions I followed are here:
http://www.jann.cc/2012/08/23/building_a_kernel_3_x_for_the_olinuxino_from_sources.html#getting-the-code
I used the https://github.com/koliqi/imx23-olinuxino repository in accordance with above, but instead of using the kernel source from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git, instead I used https://github.com/ITserve/imx23-audio.
I went through the process of using menuconfig to configure the kernel closely in accordance with the above tutorial. What I did in addition to that was navigate through the sound card options and enabled support for the SOC imx23 audio.
The board now runs with the SD card and I'm able to use networking and so forth, but aplay and linphonec clearly show that no audio devices are present.
[root@alarm ~]# aplay -l
aplay: device_list:268: no soundcards found...
[root@alarm ~]# aplay -L
null
Discard all samples (playback) or generate zero samples (capture)
At this point in time I don't know if this is a problem with how I've compiled the kernel and built the SD card, or if it's a configuration of ALSA that's required.
Thanks,
Trev
Ah - I now seem to have got further, having realised that I needed to use the imx23-audio.dts file, rather than imx23-olinuxino. This now seems to have resulted in the sound device being listed. Testing will continue. :)
Quote from: TrevorPage on September 13, 2013, 12:48:48 PM
Ah - I now seem to have got further, having realised that I needed to use the imx23-audio.dts file, rather than imx23-olinuxino. This now seems to have resulted in the sound device being listed. Testing will continue. :)
Hi Trevor, I've been in the same boat as you. What did you do to "use" the imx23-audio.dts file?
Hello sos,
Sorry - I admit my post could have been more helpful. I am thinking of doing a post or a blog at some point to document what I've learned from this.
So, using the instructions at http://www.jann.cc/2012/08/23/building_a_kernel_3_x_for_the_olinuxino_from_sources.html#getting-the-code, the two main changes are:
- Under the heading 'Get the kernel source', instead following the instruction to clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git into /kernel, instead I cloned into /kernel the imx233-audio repository (https://github.com/ITserve/imx23-audio.git). When following the rest of the instructions in the blog, keep in mind that where you see /linux-stable/, on your machine it is /imx23-audio/.
- Under the heading 'Join zImage and imx23-olinuxino.dtb into a new file zImage_dtb', what you want to do is use imx23-audio in place of imx23-olinuxino, e.g:
cat arch/arm/boot/zImage arch/arm/boot/dts/imx23-audio.dtb > arch/arm/boot/zImage_dtb
Disclaimer: Please keep in mind that this is all very new ground to me, and I'd appreciate input / corrections on anything I've said.
Sos, I'd be very glad to help you get this built if I can. It would be useful to keep a dialogue going in here.
I'm personally still experiencing trouble. I have audio working now, but my main goal of getting linphone working on this board has still not been achieved due to terrible audio break-up and debug reports like "ALSA lib pcm.c:7843:(snd_pcm_recover) overrun occurred" when a call is in progress. I'm in an awkward situation now where:
1. I can get the imx233-audio fork of the Linux kernel to compile and give me working audio on the board, and this gives me a recent version of the kernel which I can keep updated, with working pacman, etc. But I have the above problem with linphone.
2. I could use the version 2.x Linux kernel that Olimex supply on the 2GB SD card, but the whole separate headache with this version of Arch Linux ARM is that pacman cannot updated it (a well documented issue which is OTT here). So I see no simple way of getting Linphone and dependencies onto it.
3. I could use the latest version 3.x Linux kernel from the Arch Linux ARM site, but of course this has no audio driver.
Ahh I see, well thats a useful bit of info thanks!
We're much in the same boat as you, we started with 2.6 official, but then found it doesn't have support for bluetooth. Then we went for later builds and found I2C and audio broken. Then we went for this 3.10 kernel in this thread and found I2C broken still, and the I2C patch made for 3.9.8 doesn't work on 3.10.
Finding it very hard to make any use out of this olimex stuff.
I'm a happy bunny now, having solved the problem with Linphone (I just had to edit ~/.linphonerc to use just the PCM audio codecs, as otherwise the CPU apparently couldn't cope with the chosen codecs).
Audio out and line in seem to work fine.
A great thanks to the author of the imx233-audio fork. I honestly don't know how I'd have got my application working if it wasn't for that work having been done.
Not specifically on the topic of audio, but I wonder if Olimex plan to supply SD cards that have a later build of Arch Linux ARM on it, with full compatibility of all the onboard stuff? As mentioned previously, when using Olimex's SD card with the 2.x kernel, pacman simply can't be used to update the system at all; you end up having to deal with the well known Arch Linux issues described at https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/ (https://www.archlinux.org/news/binaries-move-to-usrbin-requiring-update-intervention/) and various other places. For this reason I was never able to use pacman to install anything (much on it).
Please note that the driver uses LRADC1 pin as mic bias output.
It might be helpful to allow users use LRADC0 instead of LRADC1 for this purpose in case LRADC1 is already used.
sound/soc/codecs/mxs-builtin-codec.c:
__raw_writel(BM_AUDIOIN_MICLINE_MIC_SELECT,
mxs_adc->ain_base + HW_AUDIOIN_MICLINE_SET);
This code is responsible for selecting LRADC1 as mic bias output.
Change to this one for selecting LRADC0 instead:
__raw_writel(BM_AUDIOIN_MICLINE_MIC_SELECT,
mxs_adc->ain_base + HW_AUDIOIN_MICLINE_CLR);
Can anyone suggest why my audio output (using this kernel) occasionally just goes dead (i.e. no audio output at all), with a reboot required to restore it?
At the moment I can't pinpoint what event happens for it to suddenly go quiet. I can usually perform several Linphone VOIP calls to the Olimex board, and then I'll find that the next call has no audio.
Running a utility like speaker-test will just appear to run as normal without giving any errors, but there's just no sound.
If I make a call to Linphone while it's in this state, one thing that I do hear is a small click when the call ends. Similarly, terminating speaker-test while it's apparently in progress causes the small click. So it's like _something_ is happening.
I'd be extremely grateful for any suggestions on things to try, or ideas for things I should do to try to debug this. At present the audio suddenly going dead is a showstopper for me.
Edit 1: One observation is that speaker-test just stays stuck on "0 - Front left" when output is not working. When output is working, I see speaker-test printing that line together with a 'time per period' value cyclically.
Can I ask if someone can upload a 3.x kernel raw image with audio and wifi support to somehow (wetransfer or gdrive)?
Good to compile, also good to dd a row file :)
Thank you!
I am booting the latest filesystem from archlinuxarm.org whith this boot img bootlets.
https://drive.google.com/file/d/0B7PmAK6hZ3NZYjhhdDRIYUptVms/edit?usp=sharing
[root@alarm ~]# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: mxsbuiltinaudio [mxs-builtin-audio], device 0: MXS ADC/DAC mxs-builtin-codec-dai-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
[root@alarm ~]# uname -a
Linux alarm 3.10.0 #1 Mon Dec 30 00:20:51 MST 2013 armv5tejl GNU/Linux
Just to give a further update on my situation, I have now had success by doing the following:
- Use latest Arch Linux ARM SD card image from http://archlinuxarm.org/platforms/armv5/olinuxino (http://archlinuxarm.org/platforms/armv5/olinuxino)
- Then, following the advice of one of the notes on that page, I installed package linux-armv5 which replaced the default Olinuxino kernel with the mainline kernel.
Once that was done, it had support for the i.MX233 onboard audio as standard -- and it appears much more stable than my previous attempt when I compiled the kernel myself with that driver. I no longer have annoying problems with the audio driver suddenly going dead after a Linphone call had finished, or the kernel crashing. Actually, I have still seen the kernel crash on rare occasions which I suspect to be audio driver related, but making use of the watchdog timer solves that issue for me (see https://www.olimex.com/forum/index.php?topic=142.0 (https://www.olimex.com/forum/index.php?topic=142.0)).
I have no idea what the difference is between mainline kernel and 'default Olinuxino' kernel - maybe someone can enlighten me.
Please try this on 3.13.5 kernel.
patch: https://drive.google.com/file/d/0BxSCLeYUtcwnb3BTZl9TaTJ4UVk/edit?usp=sharing
dts: https://drive.google.com/file/d/0BxSCLeYUtcwnX3dwQklXdE1TN2M/edit?usp=sharing
Quote from: Grawp on March 13, 2014, 04:52:09 AM
Please try this on 3.13.5 kernel.
Hi,
I've a problem with mxs-builtin-audio: Almost every start of sound playback gives me a warning:
"DAC overflow detected". But after an hour of playing it hangs up with error:
"DAC underflow detected".
I copied Yours Driver into https://github.com/ITserve/imx23-audio and it works better, the overflow warning never appears, and it hangs after a few underflow warnings (not after the first one).
I attach my kernel .config file.
Have You ever made mxs-builtin-audio driver work for long time without mentioned errors? Do You hae any suggestions, so I can make it work fine?
.config -> https://drive.google.com/file/d/0ByL1cf6rr8JwT0tPYUpjRXUtaTQ/edit?usp=sharing
Hi g.glowacki,
I am using the latest patch from Michall on a 3.13.6 kernel:
Quote from: Grawp on March 13, 2014, 04:52:09 AM
patch: https://drive.google.com/file/d/0BxSCLeYUtcwnb3BTZl9TaTJ4UVk/edit?usp=sharing
dts: https://drive.google.com/file/d/0BxSCLeYUtcwnX3dwQklXdE1TN2M/edit?usp=sharing
I don't have the errors you mention. I was not sure if there was a problem after hours of playing, so I ran an experiment. I launched this command-line last friday:
aplay -c 2 -f S16_LE -r 22050 /dev/urandomAnd it is still running fine now (2.5 days).
Best
Quote from: ggilles on April 07, 2014, 09:28:37 AM
I don't have the errors you mention. I was not sure if there was a problem after hours of playing, so I ran an experiment. I launched this command-line last friday:
aplay -c 2 -f S16_LE -r 22050 /dev/urandom
And it is still running fine now (2.5 days).
Best
Hi ggilles,
Thanks for You replay. This error appears when I continuously open and close file, not when infinitely playing. Can You check sth like that:
while : ; do aplay -c 2 -f S16_LE -r 22050 <some small random data e.g. /bin/bash> ; done
Thanks a lot:)
GG.
This has been running for 1.5 hour now:
while true; do aplay -c 2 -f S16_LE -r 22050 -d 1 /dev/urandom; done
And it's still playing.
Still playing fine after 4 hours!
Thanks a lot ggilles and Grawp,
Thanks to Your suggestions and patch it's working now. After going to kernel 3.13.6 it's been working now for 5 days. I still get many underflows, however DAC doesn't hang up, I've no overflows also.
Maybe You have an idea, why the underflow may appear?
--
GG
By general an underflow is when the DAC has requested a data output sample, but hasn't got one.
I'm not sure the principle of work of this AUDIO driver now, but if it is not using DMA (Direct Memory Access) or if it is using DMA, but the DMA ISR (Interrupt Service Routine) has low priority or is not optimized enough it can cause this issue.
Again generally a DMA for DAC is used in a ping-pong buffer configuration, where while one buffer is streamed to the DAC another buffer is prepared with data samples. Other more common simpler configuration is a circular buffer, but that requires a little bit more precise work and with more CPU overhead/interference ;-)
Most likely the CPU/MCU/SoC is doing something else, more important (with higher priority) than processing the DMAforDAC ISR and thus postpone the reaction for the next buffer from the audio app.
I can only assume that the DMA is in circular mode with Half Transfer Complete Interrupt which signals when half of the current buffer is transfered so the driver knows when to update the upper half of the buffer and a Full Transfer Complete Interrupt so the driver knows when the buffer will be read from the beginning so the down half can be updated with new data. And as I said this requires more precise timing to handle and if the priority of the DMA ISR is low or the Task Scheduler is switching many tasks it can delay the procedure described above.
Other case is single shot DMA, where the driver continuously is waiting for Transfer complete interrupt of the DMA and when that occurs issues new buffer of single shot DMA transfer with new buffer, in this case is very realistic to have underflows ! But most cases for audio playing in SoC a circular DMA mode is used. I personally prefer ping-pong which is more sophisticated and handy, but not all SoCs or not all SoC's DMA channels support this mode.
You're not able to hear a distinct hang up of the DAC , because at 22kHz sample rate even if you have delayed action from the ISR the last transfered sample to the DAC's output buffer will remain for the next:
T=1/F=1/(22*10^3) ~ 45uS
until the next new sample arrive, if it is missed (underflowed) again it will remain another 45uS as most DACs have autorefresh function which keeps the last transfered sample alive.
This is quite a lot of time for the MCU and I will make this big assumption that you are missing only a few samples, i.e you are having a constant TONE for only a few hundred uS. Even if you lose for example 22 samples which is almost 1 mS you still have the following 22028 samples in that second and it will be very hard to catch that with your ears ;-) Use oscilloscope and you will see how many samples exactly you are missing by looking for how long the value on the DAC output is not changed (where this time is more than 1*T, i.e at least 2*T = 90us or more).
I really got into details, but hope this will help catch the issue:
1.Low ISR priority.
2.Too many processes for the task scheduler.
3.Small DMA buffer (that i forgot to mention, but is also a possibility).
1 and 3 depend on the driver , 2 depends on the system usage. Most likely it is case 1 or 2.
Here is one test you can do :-) :
Try running aplay with 'nice' and with highest possible priority to see if it is the task scheduler ;-)
Check:
man nice
(it is very simple and useful command to set priority of a process in linux)
Good Luck
ps: I'm also going to use the iMX233-OLinuxino-NANO for an audio related project so I will be following the development of the issue.
Hi, can anyone confirm if audio has been fixed in 3.x kernel or not?
does this patch work? and how do you use the patch if it does?
Do we have to compile the kernel with the patch? or just patch the installed kernel?
Is there a kernel built with audio IO driver working already? if there is do we have a download link
anywhere?
" Hi g.glowacki,
I am using the latest patch from Michall on a 3.13.6 kernel:
Quote from: Grawp on March 13, 2014, 04:52:09 AM
patch: https://drive.google.com/file/d/0BxSCLeYUtcwnb3BTZl9TaTJ4UVk/edit?usp=sharing
dts: https://drive.google.com/file/d/0BxSCLeYUtcwnX3dwQklXdE1TN2M/edit?usp=sharing
"
Quote from: benbiles on October 07, 2014, 01:41:24 PM
Hi, can anyone confirm if audio has been fixed in 3.x kernel or not?
Yes it works. I have kernel 3.13.x.
Quote from: benbiles on October 07, 2014, 01:41:24 PM
does this patch work? and how do you use the patch if it does?
I've patched the kernel and compiled it.
Quote from: benbiles on October 07, 2014, 01:41:24 PM
Do we have to compile the kernel with the patch? or just patch the installed kernel?
Yes. You need to patch kernel with previously mentioned patch.
Quote from: benbiles on October 07, 2014, 01:41:24 PM
Is there a kernel built with audio IO driver working already? if there is do we have a download link
anywhere?
I don't know.
Regards.
Hi g.glowacki,
Thanks for reply, is there any chance you could post an image of the patched working kernel you built somewhere?
can you explain where you get kernel 3.13.x. from? I have link too https://github.com/koliqi/imx23-olinuxino which is Latest Stable Kernel 3.7.1
and I have cloned https://github.com/ITserve/imx23-audio
trying to build this kernel now with patch..
Also, when you say working audio can you confirm that audio inputs line in L&R stereo and Mic input pin 34 / alsamixer is working cleanly with no random noise and or crashes & buffer under runs ??
Thanks again,
BEN
Quote from: benbiles on October 08, 2014, 06:51:30 AM
Also, when you say working audio can you confirm that audio inputs line in L&R stereo and Mic input pin 34 / alsamixer is working cleanly with no random noise and or crashes & buffer under runs ??
No.
Audio outputs work fine, but audio inputs (both mic and line) have a periodic noise in my setup. I could not track the origin of the issue.
Best regards,
-- Gilles
Hi Gilles,
So were you using kernel 3.13.x with these patches?
patch: https://drive.google.com/file/d/0BxSCLeYUtcwnb3BTZl9TaTJ4UVk/edit?usp=sharing
dts: https://drive.google.com/file/d/0BxSCLeYUtcwnX3dwQklXdE1TN2M/edit?usp=sharing
I am trying to build kernel with https://github.com/ITserve/imx23-audio patch but i'm not sure how to update to 3.13.x kernel
I guess I am waisting my time anyway if audio inputs are broken in both 2.x and 3.x kernels !
Thanks for the update..
Quote from: benbiles on October 08, 2014, 09:26:09 AM
So were you using kernel 3.13.x with these patches?
I am using kernel 3.13.6.
To update to 3.13.6, here is what I did:
1. clone the imx223-audio repository checkout the imx23-audio branch
2. generate a patch relative to the master branch: with something like
git format-patch master --stdout > audio.patch3. clone the stable linux kernel remository, checkout v3.13.6
4. apply the patch of step 2
git apply audio.patchyou should probably check that the patch applies cleanly first (with the --check option)
Anyway, if you need audio input this does not work better than the 2.x kernel.
-- gilles
PS: untested instructions!
Hi ggiles,
could you explain how I do this step?
3. clone the stable linux kernel repository, checkout v3.13.6
do I clone this with git and then add imx223-audio to the kernel folder and build?
https://kernel.googlesource.com/pub/scm/linux/kernel/git/stable/linux-stable/+/v3.13.6
I think I should build this regardless to learn a bit about patching the kernel etc..
I have built custom kernels in x86 linux but never ARM!
I was trying to build using these instructions but can't find the latest kernel for git..
To expand on this a bit more, the instructions I followed are here:
http://www.jann.cc/2012/08/23/building_a_kernel_3_x_for_the_olinuxino_from_sources.html#getting-the-code
I used the https://github.com/koliqi/imx23-olinuxino repository in accordance with above, but instead of using the kernel source from git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git, instead I used https://github.com/ITserve/imx23-audio.
I went through the process of using menuconfig to configure the kernel closely in accordance with the above tutorial. What I did in addition to that was navigate through the sound card options and enabled support for the SOC imx23 audio.
The board now runs with the SD card and I'm able to use networking and so forth, but aplay and linphonec clearly show that no audio devices are present.
I'm trying to get audio working on an Olinuxino, and the patch/dts file mentioned below are no longer available from google drive. Is there any other place they might be available? Thanks.
-Macphyter
---Edit:
Never mind, I found them. They're in the OpenWRT source tree here if anyone needs them:
https://dev.openwrt.org/browser/trunk/target/linux/imx23/patches?rev=37622
-Macphyter
Quote from: benbiles on October 08, 2014, 09:26:09 AM
Hi Gilles,
So were you using kernel 3.13.x with these patches?
patch: https://drive.google.com/file/d/0BxSCLeYUtcwnb3BTZl9TaTJ4UVk/edit?usp=sharing
dts: https://drive.google.com/file/d/0BxSCLeYUtcwnX3dwQklXdE1TN2M/edit?usp=sharing
I am trying to build kernel with https://github.com/ITserve/imx23-audio patch but i'm not sure how to update to 3.13.x kernel
I guess I am waisting my time anyway if audio inputs are broken in both 2.x and 3.x kernels !
Thanks for the update..
Hello everyone, I've been struggling to get a proper working kernel with audio support. I tried literally every single idea you guys have posted. I'm sharing the kernel oops:
The moment I try to run alsamixer, aplay -l, amixer, the system just freezes and I can't kill those processes!
I really need an explanation for this.
[ 3.790000] mmcblk0: p1 p2
[ 3.830000] mxs-sgtl5000 sound: failed to get mclk
[ 3.840000] mxs-sgtl5000: probe of sound failed with error -22
[ 3.850000] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[ 3.870000] mxs-builtin-audio mxs-builtin-audio: mxs-builtin-codec-dai <-> 80048000.mxs-builtin-cpu-dai mapping ok
[ 4.150000] ALSA device list:
[ 4.150000] #0: mxs-builtin-audio
[ 32.250000] sgtl5000 0-000a: Failed to get mclock: -2
[ 32.330000] i2c 0-000a: Driver sgtl5000 requests probe deferral
[ 32.590000] sgtl5000 0-000a: Failed to get mclock: -2
[ 32.690000] i2c 0-000a: Driver sgtl5000 requests probe deferral
[ 32.790000] sgtl5000 0-000a: Failed to get mclock: -2
[ 32.790000] i2c 0-000a: Driver sgtl5000 requests probe deferral
[ 34.440000] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 34.520000] pgd = c2f4c000
[ 34.650000] [00000004] *pgd=42f3d831, *pte=00000000, *ppte=00000000
[ 34.650000] Internal error: Oops: 17 [#1] PREEMPT ARM
Rado
Hi Rado,
could you please post the kernel version and it's relevant config / DTS?
Stefan
Hello Stefan, I've used the latest rootfs:
http://archlinuxarm.org/os/ArchLinuxARM-armv5-latest.tar.gz
+
u-boot.sb
[root@alarm ~]# uname -a
Linux alarm 3.19.3-1-ARCH #1 PREEMPT Fri Mar 27 19:59:26 MDT 2015 armv5tejl GNU/
The reason I need a working kernel is because every time I try to build a kernel by the www.jann.cc method:
http://www.jann.cc/2012/08/23/building_a_kernel_3_x_for_the_olinuxino_from_sources.html
I never get the zImage file? It never really compiles.
I've been on this for a month, researching how to make it work, it's for an audio project, but I'm seriously stuck.
Hi Rado,
i've looked at https://github.com/archlinuxarm/PKGBUILDs/tree/master/core/linux-armv5
and some of the audio patches are old or looks strange to me.
Maybe you should post the problem at archlinuxarm.org first.
Stefan
I'm wondering why it's so hard to enable sound on kernel >= 3.7 as there are kernel driver options for MXS audio:
Device Drivers --->
<*> Sound card support --->
<*> Advanced Linux Sound Architecture --->
<*> ALSA for SoC audio support --->
<*> SoC Audio for Freescale MXS CPUs --->
<*> SoC Audio support for MXS boards with sgtl5000
Someone maybe just tried these...?
SGTL5000 codec is only for MX28 not for MX23. Unfortunately this option is misleading.
Anyone here who can help building a 3.x kernel w/ working audio?
I cloned github.com/ITserve/imx23-audio, enabled the "SoC Audio for Freescale i.MX23 built-in codec" in menuconfig and did a successful clean build. Olinuxino (maxi) boots fine, but still says
[ 1.480000] ALSA device list:
[ 1.480000] No soundcards found.
Did I forget any step before??
Any help is welcome!
Chris
I never tested the audio driver.
But do you use the modified imx23-olinuxino-audio.dts from the repository?
Oh yes, imx23-audio.dts was missing, thanks for the hint!
By the way: Anyone here who ported the driver to kernel 4.x ? Taking the new and modified files from github.com/ITserve/imx23-audio and patching a kernel 4.x won't compile. :-(
It seems that Archlinux maintained these patches until Kernel 4.1:
https://github.com/archlinuxarm/PKGBUILDs/tree/c057ac8267323a3b71394593a742887334fe5275/core/linux-armv5
Maybe this is helpful.
Okay, i applied these patches against 4.3-rc1, but there were compiler errors.
I tried to fixed them and pushed it in my lcd repo:
https://github.com/lategoodbye/linux-lcd6610
Warning: I tested only that my mx233 still boot, but no functional tests.
What does dmesg say?
ALSA device list:
#0: mxs-builtin-audio
or
ALSA device list:
No soundcards found.
And what does aplay -l say?
First of all, i need to say that i configured the driver as module.
Also i noticed that my rootfs didn't contain any alsa stuff. So i installed the alsa-utils. But now i get a kernel oops :-(
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 4.3.0-rc1-next-20150914-g4657771-dirty (user@Duckbill) (gcc version 4.4.4 (4.4.4_09.06.2010) ) #6 Sat Sep 26 09:24:28 UTC 2015
[ 0.000000] CPU: ARM926EJ-S [41069265] revision 5 (ARMv5TEJ), cr=0005317f
[ 0.000000] CPU: VIVT data cache, VIVT instruction cache
[ 0.000000] Machine model: i.MX23 Olinuxino Low Cost Board
[ 0.000000] Memory policy: Data cache writeback
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pages: 16240
[ 0.000000] Kernel command line: console=ttyAMA0,115200 root=/dev/mmcblk0p2 no_console_suspend=1
[ 0.000000] PID hash table entries: 256 (order: -2, 1024 bytes)
[ 0.000000] Dentry cache hash table entries: 8192 (order: 3, 32768 bytes)
[ 0.000000] Inode-cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 0.000000] Memory: 48612K/65536K available (5565K kernel code, 351K rwdata, 1800K rodata, 248K init, 8201K bss, 16924K reserved, 0K cma-reserved)
[ 0.000000] Virtual kernel memory layout:
[ 0.000000] vector : 0xffff0000 - 0xffff1000 ( 4 kB)
[ 0.000000] fixmap : 0xffc00000 - 0xfff00000 (3072 kB)
[ 0.000000] vmalloc : 0xc4800000 - 0xff000000 ( 936 MB)
[ 0.000000] lowmem : 0xc0000000 - 0xc4000000 ( 64 MB)
[ 0.000000] modules : 0xbf000000 - 0xc0000000 ( 16 MB)
[ 0.000000] .text : 0xc0008000 - 0xc0739a5c (7367 kB)
[ 0.000000] .init : 0xc073a000 - 0xc0778000 ( 248 kB)
[ 0.000000] .data : 0xc0778000 - 0xc07cfdf8 ( 352 kB)
[ 0.000000] .bss : 0xc07cfdf8 - 0xc0fd254c (8202 kB)
[ 0.000000] SLUB: HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
[ 0.000000] Running RCU self tests
[ 0.000000] NR_IRQS:16 nr_irqs:16 16
[ 0.000000] clocksource: mxs_timer: mask: 0xffff max_cycles: 0xffff, max_idle_ns: 911346093 ns
[ 0.000000] sched_clock: 32 bits at 100 Hz, resolution 10000000ns, wraps every 21474836475000000ns
[ 0.000000] Console: colour dummy device 80x30
[ 0.000000] Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
[ 0.000000] ... MAX_LOCKDEP_SUBCLASSES: 8
[ 0.000000] ... MAX_LOCK_DEPTH: 48
[ 0.000000] ... MAX_LOCKDEP_KEYS: 8191
[ 0.000000] ... CLASSHASH_SIZE: 4096
[ 0.000000] ... MAX_LOCKDEP_ENTRIES: 32768
[ 0.000000] ... MAX_LOCKDEP_CHAINS: 65536
[ 0.000000] ... CHAINHASH_SIZE: 32768
[ 0.000000] memory used by lock dependency info: 5167 kB
[ 0.000000] per task-struct memory footprint: 1536 bytes
[ 0.070000] Calibrating delay loop... 226.09 BogoMIPS (lpj=1130496)
[ 0.070000] pid_max: default: 32768 minimum: 301
[ 0.070000] Mount-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.070000] Mountpoint-cache hash table entries: 1024 (order: 0, 4096 bytes)
[ 0.080000] Initializing cgroup subsys memory
[ 0.080000] CPU: Testing write buffer coherency: ok
[ 0.080000] Setting up static identity map for 0x40008400 - 0x40008458
[ 0.110000] devtmpfs: initialized
[ 0.160000] clocksource: jiffies: mask: 0xffffffff max_cycles: 0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.160000] pinctrl core: initialized pinctrl subsystem
[ 0.180000] NET: Registered protocol family 16
[ 0.190000] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.290000] Serial: AMBA PL011 UART driver
[ 0.300000] 80070000.serial: ttyAMA0 at MMIO 0x80070000 (irq = 17, base_baud = 0) is a PL011 rev2
[ 0.500000] console [ttyAMA0] enabled
[ 0.600000] mxs-dma 80004000.dma-apbh: initialized
[ 0.620000] mxs-dma 80024000.dma-apbx: initialized
[ 0.630000] SCSI subsystem initialized
[ 0.640000] usbcore: registered new interface driver usbfs
[ 0.650000] usbcore: registered new interface driver hub
[ 0.650000] usbcore: registered new device driver usb
[ 0.660000] pps_core: LinuxPPS API ver. 1 registered
[ 0.670000] pps_core: Software ver. 5.3.6 - Copyright 2005-2007 Rodolfo Giometti <giometti@linux.it>
[ 0.670000] PTP clock support registered
[ 0.680000] Advanced Linux Sound Architecture Driver Initialized.
[ 0.700000] clocksource: Switched to clocksource mxs_timer
[ 1.090000] FS-Cache: Loaded
[ 1.090000] CacheFiles: Loaded
[ 1.240000] NET: Registered protocol family 2
[ 1.260000] TCP established hash table entries: 1024 (order: 0, 4096 bytes)
[ 1.270000] TCP bind hash table entries: 1024 (order: 3, 36864 bytes)
[ 1.270000] TCP: Hash tables configured (established 1024 bind 1024)
[ 1.280000] UDP hash table entries: 256 (order: 2, 20480 bytes)
[ 1.290000] UDP-Lite hash table entries: 256 (order: 2, 20480 bytes)
[ 1.300000] NET: Registered protocol family 1
[ 1.300000] NetWinder Floating Point Emulator V0.97 (double precision)
[ 1.320000] futex hash table entries: 256 (order: 1, 11264 bytes)
[ 1.490000] jffs2: version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
[ 1.540000] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 249)
[ 1.550000] io scheduler noop registered (default)
[ 1.590000] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 1.600000] usbcore: registered new interface driver usb-storage
[ 1.620000] ci_hdrc ci_hdrc.0: EHCI Host Controller
[ 1.630000] ci_hdrc ci_hdrc.0: new USB bus registered, assigned bus number 1
[ 1.660000] ci_hdrc ci_hdrc.0: USB 2.0 started, EHCI 1.00
[ 1.680000] hub 1-0:1.0: USB hub found
[ 1.690000] hub 1-0:1.0: 1 port detected
[ 1.710000] mousedev: PS/2 mouse device common for all mice
[ 1.730000] stmp3xxx-rtc 8005c000.rtc: rtc core: registered 8005c000.rtc as rtc0
[ 1.740000] i2c /dev entries driver
[ 1.760000] stmp3xxx_rtc_wdt stmp3xxx_rtc_wdt: initialized watchdog with heartbeat 19s
[ 1.770000] 80010000.ssp supply vmmc not found, using dummy regulator
[ 1.820000] mxs-mmc 80010000.ssp: initialized
[ 1.850000] usbcore: registered new interface driver usbhid
[ 1.860000] usbhid: USB HID core driver
[ 1.870000] mmc0: host does not support reading read-only switch, assuming write-enable
[ 1.890000] mmc0: new high speed SDHC card at address 0001
[ 1.910000] mmcblk0: mmc0:0001 00000 14.9 GiB
[ 1.940000] NET: Registered protocol family 10
[ 1.950000] mmcblk0: p1 p2 p3
[ 1.980000] mip6: Mobile IPv6
[ 2.000000] sit: IPv6 over IPv4 tunneling driver
[ 2.020000] usb 1-1: new high-speed USB device number 2 using ci_hdrc
[ 2.030000] ip6_gre: GRE over IPv6 tunneling driver
[ 2.040000] NET: Registered protocol family 17
[ 2.040000] bridge: automatic filtering via arp/ip/ip6tables has been deprecated. Update your scripts to load br_netfilter if you need this.
[ 2.060000] Key type dns_resolver registered
[ 2.070000] registered taskstats version 1
[ 2.100000] stmp3xxx-rtc 8005c000.rtc: setting system clock to 1970-01-01 00:00:06 UTC (6)
[ 2.160000] ALSA device list:
[ 2.160000] No soundcards found.
[ 2.180000] uart-pl011 80070000.serial: no DMA platform data
[ 2.190000] hub 1-1:1.0: USB hub found
[ 2.200000] hub 1-1:1.0: 3 ports detected
[ 2.230000] EXT2-fs (mmcblk0p2): error: couldn't mount because of unsupported optional features (244)
[ 2.250000] EXT4-fs (mmcblk0p2): couldn't mount as ext3 due to feature incompatibilities
[ 2.270000] EXT4-fs (mmcblk0p2): INFO: recovery required on readonly filesystem
[ 2.270000] EXT4-fs (mmcblk0p2): write access will be enabled during recovery
[ 2.490000] usb 1-1.1: new high-speed USB device number 3 using ci_hdrc
[ 2.540000] EXT4-fs (mmcblk0p2): recovery complete
[ 2.570000] EXT4-fs (mmcblk0p2): mounted filesystem with ordered data mode. Opts: (null)
[ 2.570000] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
[ 2.590000] devtmpfs: mounted
[ 2.600000] Freeing unused kernel memory: 248K (c073a000 - c0778000)
[ 3.180000] random: systemd urandom read with 15 bits of entropy available
[ 3.220000] systemd[1]: systemd 215 running in system mode. (+PAM +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ -SECCOMP -APPARMOR)
[ 3.240000] systemd[1]: Detected architecture 'arm'.
Welcome to Debian GNU/Linux 8 (jessie)!
[ 3.340000] systemd[1]: Set hostname to <duckbill>.
[ 5.130000] systemd[1]: Cannot add dependency job for unit display-manager.service, ignoring: Unit display-manager.service failed to load: No such file or directory.
[ 5.160000] systemd[1]: Starting Forward Password Requests to Wall Directory Watch.
[ 5.180000] systemd[1]: Started Forward Password Requests to Wall Directory Watch.
[ 5.190000] systemd[1]: Expecting device dev-ttyAMA0.device...
Expecting device dev-ttyAMA0.device...
[ 5.220000] systemd[1]: Starting Remote File Systems (Pre).
[ OK ] Reached target Remote File Systems (Pre).
[ 5.250000] systemd[1]: Reached target Remote File Systems (Pre).
[ 5.250000] systemd[1]: Set up automount Arbitrary Executable File Formats File System Automount Point.
[ 5.260000] systemd[1]: Starting Dispatch Password Requests to Console Directory Watch.
[ 5.280000] systemd[1]: Started Dispatch Password Requests to Console Directory Watch.
[ 5.280000] systemd[1]: Starting Paths.
[ OK ] Reached target Paths.
[ 5.310000] systemd[1]: Reached target Paths.
[ 5.310000] systemd[1]: Starting Encrypted Volumes.
[ OK ] Reached target Encrypted Volumes.
[ 5.340000] systemd[1]: Reached target Encrypted Volumes.
[ 5.340000] systemd[1]: Starting Swap.
[ OK ] Reached target Swap.
[ 5.370000] systemd[1]: Reached target Swap.
[ 5.370000] systemd[1]: Starting Root Slice.
[ OK ] Created slice Root Slice.
[ 5.400000] systemd[1]: Created slice Root Slice.
[ 5.400000] systemd[1]: Starting User and Session Slice.
[ OK ] Created slice User and Session Slice.
[ 5.440000] systemd[1]: Created slice User and Session Slice.
[ 5.440000] systemd[1]: Starting /dev/initctl Compatibility Named Pipe.
[ OK ] Listening on /dev/initctl Compatibility Named Pipe.
[ 5.480000] systemd[1]: Listening on /dev/initctl Compatibility Named Pipe.
[ 5.480000] systemd[1]: Starting Delayed Shutdown Socket.
[ OK ] Listening on Delayed Shutdown Socket.
[ 5.520000] systemd[1]: Listening on Delayed Shutdown Socket.
[ 5.520000] systemd[1]: Starting Journal Socket (/dev/log).
[ OK ] Listening on Journal Socket (/dev/log).
[ 5.560000] systemd[1]: Listening on Journal Socket (/dev/log).
[ 5.560000] systemd[1]: Starting udev Control Socket.
[ OK ] Listening on udev Control Socket.
[ 5.600000] systemd[1]: Listening on udev Control Socket.
[ 5.600000] systemd[1]: Starting udev Kernel Socket.
[ OK ] Listening on udev Kernel Socket.
[ 5.630000] systemd[1]: Listening on udev Kernel Socket.
[ 5.630000] systemd[1]: Starting Journal Socket.
[ OK ] Listening on Journal Socket.
[ 5.660000] systemd[1]: Listening on Journal Socket.
[ 5.660000] systemd[1]: Starting System Slice.
[ OK ] Created slice System Slice.
[ 5.690000] systemd[1]: Created slice System Slice.
[ 5.690000] systemd[1]: Starting system-getty.slice.
[ OK ] Created slice system-getty.slice.
[ 5.730000] systemd[1]: Created slice system-getty.slice.
[ 5.730000] systemd[1]: Starting system-serial\x2dgetty.slice.
[ OK ] Created slice system-serial\x2dgetty.slice.
[ 5.770000] systemd[1]: Created slice system-serial\x2dgetty.slice.
[ 5.780000] systemd[1]: Starting Increase datagram queue length...
Starting Increase datagram queue length...
[ 5.860000] systemd[1]: Starting Create list of required static device nodes for the current kernel...
Starting Create list of required static device nodes...rrent kernel...
[ 5.970000] systemd[1]: Mounted POSIX Message Queue File System.
[ 6.010000] systemd[1]: Starting Load Kernel Modules...
Starting Load Kernel Modules...
[ 6.160000] systemd[1]: Mounted Huge Pages File System.
[ 6.190000] systemd[1]: Starting udev Coldplug all Devices...
Starting udev Coldplug all Devices...
[ 6.280000] systemd[1]: Mounting Debug File System...
Mounting Debug File System...
[ 6.500000] systemd[1]: Started Set Up Additional Binary Formats.
[ 6.540000] systemd[1]: Starting Slices.
[ OK ] Reached target Slices.
[ 6.560000] systemd[1]: Reached target Slices.
[ 6.560000] systemd[1]: Starting Remount Root and Kernel File Systems...
Starting Remount Root and Kernel File Systems...
[ OK ] Started Increase datagram queue length.
[ 6.850000] systemd[1]: Started Increase datagram queue length.
[ OK ] Started Create list of required static device nodes ...current kernel.
[ 7.110000] systemd[1]: Started Create list of required static device nodes for the current kernel.
[ OK ] Started Load Kernel Modules.
[ 7.190000] systemd[1]: Started Load Kernel Modules.
[ 7.200000] EXT4-fs (mmcblk0p2): re-mounted. Opts: commit=60
[ OK ] Mounted Debug File System.
[ 7.230000] systemd[1]: Mounted Debug File System.
[ OK ] Started Remount Root and Kernel File Systems.
[ 7.310000] systemd[1]: Started Remount Root and Kernel File Systems.
[ 8.350000] systemd[1]: Started Various fixups to make systemd work better on Debian.
[ 8.370000] systemd[1]: Starting Load/Save Random Seed...
Starting Load/Save Random Seed...
[ 8.450000] systemd[1]: Mounted Configuration File System.
[ 8.480000] systemd[1]: Mounted FUSE Control File System.
[ 8.480000] systemd[1]: Starting Apply Kernel Variables...
Starting Apply Kernel Variables...
[ 8.620000] systemd[1]: Starting Create Static Device Nodes in /dev...
Starting Create Static Device Nodes in /dev...
[ 8.800000] systemd[1]: Starting Syslog Socket.
[ OK ] Listening on Syslog Socket.
[ 8.860000] systemd[1]: Listening on Syslog Socket.
[ 8.860000] systemd[1]: Starting Journal Service...
Starting Journal Service...
[ OK ] Started Journal Service.
[ 9.090000] systemd[1]: Started Journal Service.
[ OK ] Started Load/Save Random Seed.
[ OK ] Started Apply Kernel Variables.
[ OK ] Started Create Static Device Nodes in /dev.
[ OK ] Started udev Coldplug all Devices.
Starting udev Kernel Device Manager...
[ OK ] Reached target Local File Systems (Pre).
[ OK ] Reached target Local File Systems.
Starting Create Volatile Files and Directories...
[ OK ] Reached target Remote File Systems.
Starting Trigger Flushing of Journal to Persistent Storage...
Starting LSB: Raise network interfaces....
[ 10.700000] systemd-udevd[76]: starting version 215
[ OK ] Started udev Kernel Device Manager.
[ OK ] Started Create Volatile Files and Directories.
[ 12.140000] systemd-journald[72]: Received request to flush runtime journal from PID 1
[ OK ] Started Trigger Flushing of Journal to Persistent Storage.
Starting Update UTMP about System Boot/Shutdown...
Starting Copy rules generated while the root was ro...
[ OK ] Started Copy rules generated while the root was ro.
[ OK ] Started Update UTMP about System Boot/Shutdown.
[ 15.830000] mxs-builtin-audio mxs-builtin-audio: ASoC: CPU DAI (null) not registered
[ 15.830000] mxs-builtin-audio mxs-builtin-audio: snd_soc_register_card failed (-517)
[ 16.050000] mxs-builtin-audio mxs-builtin-audio: ASoC: CPU DAI (null) not registered
[ 16.060000] mxs-builtin-audio mxs-builtin-audio: snd_soc_register_card failed (-517)
[ 16.110000] mxs_lradc: module is from the staging directory, the quality is unknown, you have been warned.
[ 16.270000] mxs-builtin-audio mxs-builtin-audio: mxs-builtin-codec-dai <-> 80048000.mxs-builtin-cpu-dai mapping ok
[ OK ] Found device /dev/ttyAMA0.
[ OK ] Reached target Sound Card.
[ 20.620000] Unable to handle kernel NULL pointer dereference at virtual address 00000004
[ 20.620000] pgd = c2eb8000
[ 20.630000] [00000004] *pgd=42ee8831, *pte=00000000, *ppte=00000000
[ 20.630000] Internal error: Oops: 17 [#1] ARM
[ 20.630000] Modules linked in: mxs_lradc(C) snd_soc_mxs_builtin_dai snd_soc_mxs_builtin_codec snd_soc_mxs_builtin_pcm industrialio_triggered_buffer snd_soc_mxs_builtin_audio
[ 20.630000] CPU: 0 PID: 125 Comm: alsactl Tainted: G C 4.3.0-rc1-next-20150914-g4657771-dirty #6
[ 20.630000] Hardware name: Freescale MXS (Device Tree)
[ 20.630000] task: c2dbda00 ti: c2eaa000 task.ti: c2eaa000
[ 20.630000] PC is at dac_put_volsw+0x20/0x54 [snd_soc_mxs_builtin_codec]
[ 20.630000] LR is at snd_ctl_elem_write_user+0x148/0x210
[ 20.630000] pc : [<bf00c264>] lr : [<c03fe7a4>] psr: 60000013
[ 20.630000] sp : c2eabe58 ip : c377ca80 fp : 00000000
[ 20.630000] r10: 00000001 r9 : c377cab8 r8 : c37b73c4
[ 20.630000] r7 : c37b7720 r6 : 011018e0 r5 : c37b7000 r4 : c37eac00
[ 20.630000] r3 : 00000000 r2 : 00e60000 r1 : c37eac00 r0 : bf00cacc
[ 20.630000] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none
[ 20.630000] Control: 0005317f Table: 42eb8000 DAC: 00000051
[ 20.630000] Process alsactl (pid: 125, stack limit = 0xc2eaa190)
[ 20.630000] Stack: (0xc2eabe58 to 0xc2eac000)
[ 20.630000] be40: 00000000 c0fa0704
[ 20.630000] be60: 00000001 00000000 c2dbde08 c00590bc 00000000 00000070 0000005b b6dc0000
[ 20.630000] be80: 00000000 c2c01254 00000000 60000013 00000000 80000005 c2c85513 c2ed1980
[ 20.630000] bea0: c37b7000 00000004 011018e0 c2eaa000 00000000 c03ff754 00000070 c00518b4
[ 20.630000] bec0: c2eabfb0 c0018f68 00000200 c0055500 c0785460 c0785460 c0785ca0 c0552c20
[ 20.630000] bee0: c0785460 00000000 00000000 00000005 c077f72c b6dcdd4c c2eabfb0 011018e0
[ 20.630000] bf00: c37af360 c2e38060 00000004 00000004 c2eaa000 00000000 00000000 c01244d4
[ 20.630000] bf20: 00000100 c0023738 c07d05a8 00000000 00000000 c0023b70 0000001c c3418000
[ 20.630000] bf40: 0110162a 00000004 0000000a ffff92dd 00400000 00000001 00000000 c3418000
[ 20.630000] bf60: 00000000 c3414260 00000000 c37af360 c37af360 011018e0 c2c85513 00000004
[ 20.630000] bf80: c2eaa000 00000000 00000000 c0124bcc bed76fdc 010f8038 00000002 00000036
[ 20.630000] bfa0: c00103e8 c0010240 bed76fdc 010f8038 00000004 c2c85513 011018e0 010f8558
[ 20.630000] bfc0: bed76fdc 010f8038 00000002 00000036 00000001 00000000 0000000a 00000000
[ 20.630000] bfe0: b6ee142c bed768d4 b6e4b9c8 b6cbe36c 20000010 00000004 00000000 00000000
[ 20.630000] [<bf00c264>] (dac_put_volsw [snd_soc_mxs_builtin_codec]) from [<c03fe7a4>] (snd_ctl_elem_write_user+0x148/0x210)
[ 20.630000] [<c03fe7a4>] (snd_ctl_elem_write_user) from [<c03ff754>] (snd_ctl_ioctl+0x164/0x738)
[ 20.630000] [<c03ff754>] (snd_ctl_ioctl) from [<c01244d4>] (do_vfs_ioctl+0x74/0x734)
[ 20.630000] [<c01244d4>] (do_vfs_ioctl) from [<c0124bcc>] (SyS_ioctl+0x38/0x5c)
[ 20.630000] [<c0124bcc>] (SyS_ioctl) from [<c0010240>] (ret_fast_syscall+0x0/0x1c)
[ 20.630000] Code: e0802002 e5d22068 e5933084 e1a02802 (e5933004)
[ 20.900000] ---[ end trace ed1d71c7af464ff3 ]---
Okay, i commited a bugfix for the kernel oops and here are the results of aplay:
# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: mxsbuiltinaudio [mxs-builtin-audio], device 0: MXS ADC/DAC mxs-builtin-codec-dai-0 []
Subdevices: 1/1
Subdevice #0: subdevice #0
Looks much better, thank you! :D +1
I only want to mention that the overflow and underflow issues still appear.
Someone in the Freescale community made an Alsa userspace programm to reproduce the issue within seconds:
https://community.freescale.com/thread/274320
From my point of view it's a combination of a driver bug and a chip errata.