From: Martin Peevski <martin@ronetix.at>
To: buildroot@busybox.net
Subject: [Buildroot] ALSA don't work
Date: Mon, 08 Oct 2012 17:38:57 +0300 [thread overview]
Message-ID: <5072E581.1000506@ronetix.at> (raw)
In-Reply-To: <5072D9D0.4030800@petroprogram.com>
On 08/10/12 16:49, Stefan Fr?berg wrote:
> 8.10.2012 14:44, Martin Peevski kirjoitti:
>>
>>> My bad. I forgot that in buildroot that hidden linux .config file
>>> is located under the
>>> buildroot/output/build/linux/-linux_version///directory
>>
>> Oh, sorry.
>> Yes, I see now the .config file and have the following configuration
>> the things you show me above:
>>
>> #CONFIG_SND_ATMEL_AC97C is not used
>> CONFIG_BUS_AC97C=y is entirely missing but it's missing and
>> for the system which works with another rootfs
>> CONFIG_SND_AT91_SOC_SAM9G20_WM8731=y
>> CONFIG_SND_SOC_WM8731=y
>>
>> How you think, is it possible Buildroot to change my custom Kernel
>> for which I'm supplied custom defconfig file?
>>
>
> So you did not give buildroot the default config file (at91sam9g45)
> but used your own ?
> (see at91sam9g45_linux_default_config.png)
>
> The default at91sam9g45_defconfig file that is shipped with Linux
> kernel and which buildroot uses if no custom file provided does not
> by default seem to contain the needed drivers. (see
> at91sam9g45_linux_default_config2.png)
>
> Only CONFIG_SND_ATMEL_AC97C=y is defined.
OK, I'm using my custom defconfig so everything must working good;
>
>
>>>
>>> Please see the attached linux_config.png file.
>>> That also shows how to check if you have the right drivers compiled.
>>>
>>> If you want to know how to check your drivers from actual /running/
>>> rootfs then
>>> please check attached file checking_linux_config_from_running_system.png
>>>
>>> Also, I have a very rudimentary linux config file for your board
>>> (at91sam9g45_config file)
>>>
>>> To use it just do the following:
>>> 1 ) Go to your buildroot directory
>>>
>>> cd
>>> /home/martin/Desktop/pm9g45-test/Development/rootFS/buildRoot/buildRoot/buildroot
>>>
>>> 2 ) Clean everything
>>> make clean
>>>
>>> 3) Make a minimal buildroot config, just uClibc, busybox and kernel
>>> make menuconfig
>>>
>>> From the buildroot Kernel section check the following (see
>>> buildroot_config.png):
>>> - Kernel configuration (Using a custom config file)
>>> -
>>> /your_directory_where_you_saved_my_custom_linux_config/at91sam945_config
>>>
>>> Keep the device management still static, /dev/management (Static
>>> using device table) under
>>> System configuration section. No need to use mdev (or udev) yet
>>> unless this won't work.
>>>
>>> 4) Double-check that kernel options are good before starting
>>> building (check especially the Sound section under Device Drivers):
>>>
>>> make linux-menuconfig
>>>
>>> 5 ) If buildroot config and linux kernel config looks good then
>>> build and pray
>>>
>>> make
>>>
>>>
>>> If that rootfs still does not have sound working then maybe it's
>>> time to try mdev (or udev).
>>>
>>>
>>>
>>>>> Still no sound for me. Can't run alsamixer. The attached file is
>>>>> with the edited device_table.txt which include and the audio nodes
>>>>> in /dev.
>>>>> I want to ask you some more questions:
>>>>>
>>>>> 1. Shall I do make clean when I made some addition to the System
>>>>> configuration or just make is fine?
>>>>>
>>>>> 2. Someone told me that he's doing such a task - making ALSA works
>>>>> with Dynamic /dev population and udev, using built-in drivers not
>>>>> modules for the Kernel. I try it out in Buildroot but was
>>>>> impossible to bild the system because error. However, please tell
>>>>> me, will such a System configuration makes my sound works? During
>>>>> that time i will configure the system in that way and will send
>>>>> you later the error message from Buildroot.
>>>>>
>>> mdev (or udev) will just handle the device population automatically
>>> under /dev.
>>> If your kernel does not have the right settings and drivers compiled
>>> either directly into to the kernel or alternatively
>>> as runtime loadable modules then mdev won't help either.
>>>
>>> In another words: *If the **drivers are not there *then using static
>>> device tables, mdev, or udev will be useless.
>>>
>>> Also, if you have not used your own custom kernel config file for
>>> your board, but the default config file, then it's
>>> a very high change that it does not have the needed drivers built-in.
>>>
>>>>> Thanks for the help! Martin.
>>>>>
>>>>>
>>>>>
>>>>>
>>>> Sorry, hit the Send button too early! :) Only to notice that at the
>>>> moment I haven't server to supply my custom Kernel version and now
>>>> I'm building only the rootfs without the Kernel. However, I build
>>>> the system with the same toolchain which was used for the Kernel
>>>> building begore. I hope that this isn't problem, is that true?
>>>>
>>>>
>>> No, it's not a problem to use the same toolchain but I still suspect
>>> that your kernel is missing something and that is a problem.
>>> (Can't check that because I didn't get your dmesg output or your
>>> linux config file.)
>>>
>>>> Sorry once again and hava a nice day!
>>>> Martin
>>>
>>> No prob.
>>> Stefan
>>
>>
>> Thanks for the great help, Stefan, but I try it with mdev because I
>> have no time to spent on that problem. Afer some cofiguration of the
>> target roots manually, and rebuild, it works! :) Now is possible to
>> start alsactl init, alsamixer , a play, asound. But:
>>
>> 1. Configure the ALSA with the fololwing commands:
>>
>> # alsactl init
>> Found hardware: "WM8731" "" "" "" ""
>> Hardware is initialized using a generic method
>> #
>> # aplay -l
>> **** List of PLAYBACK Hardware Devices ****
>> card 0: AT91SAMG20EK [AT91SAMG20-EK], device 0: WM8731 PCM WM8731-0 []
>> Subdevices: 1/1
>> Subdevice #0: subdevice #0
>> #
>>
>> Attached are the configurations for the Playback and Capture devices
>> made with alsamixer program.
>>
>>
>> 2. start arecord with the command:
>> arecord -d 10 -t wav test68.wav
>> but when I try to hear the created file with aplay nothing was
>> heared. Next copy the test68.wav to my PC and try there aplay also
>> nothing. Note that when I start aplay with another wav file on my
>> target, aplay not release the console and nothing is heared again.
>> Then I use ctrl + c to release it.
>>
>
> There is also a simpler way to test wav play.
>
> Give command:
>
> speaker-test -t wav -c2
>
> It will play a loop of "Front Left, Front Right" untill you exit with
> Ctrl-C
Yes, I test the command on my PC but when I include that package for my
target it was no on the target after build. No command speaker-test was
available on the target. I'll try to rebuild again the Buildroot with
that package. Any idea here?
>
>>
>> Can you, please check the result from the commands and the
>> attachments and help me turn at least aplay with ready wav files in
>> the rootfs?
>>
>
> Your alsactl init output is missing some information.
>
> Compare to mine:
>
> alsactl init
> Found hardware: "ICH" "Sigmatel STAC9700,83,84" "AC97a:83847600"
> "0x8086" "0x0000"
>
> (see also my_alsa_detection.png)
>
> So your alsactl init gives just your sound chip name and nothing else.
>
> Also, your alsamixer outputs seemed very weird and I noticed that in
> both screenshots
> there is no Chipset found.
>
> (see my version my_alsa_mixer_settings.png)
>
OK, I will check again the output with another rootfs. I think that is
possible the different output is due to that your looks from PC but my
is very small Linux.
> This is a dump question but:
>
> Are you *absolutely sure* that you are using the right kernel sources
> and the right custom
> kernel .config file for your kernel ?
> And also are you sure that CONFIG_SND_ATMEL_AC97C=y is not needed in
> your kernel ?
Yes, with another rootfs my sound is working. I'll compare it output on
ALSA commands with that from Buildroot.
>
> I still suggest you do the live running kernel config capture from
> your working system like
> I showed you in checking_linux_config_from_running_system.png from my
> previous post
> and compare it's settings to buildroot one.
Yes, everything which I'm asking you is happen on my board at the moment.
Thanks for the time and help!
Martin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20121008/58e69a86/attachment-0001.html>
next prev parent reply other threads:[~2012-10-08 14:38 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-05 14:42 [Buildroot] ALSA don't work Martin Peevski
2012-10-05 14:59 ` Stefan Fröberg
2012-10-05 15:34 ` Martin Peevski
2012-10-05 17:29 ` Stefan Fröberg
[not found] ` <50703E2A.5060702@ronetix.at>
[not found] ` <50704D34.2070002@petroprogram.com>
[not found] ` <50716DA7.4030200@ronetix.at>
[not found] ` <50716F47.1@ronetix.at>
2012-10-07 15:50 ` Stefan Fröberg
2012-10-08 11:44 ` Martin Peevski
2012-10-08 13:49 ` Stefan Fröberg
2012-10-08 14:38 ` Martin Peevski [this message]
2012-10-08 14:46 ` Stefan Fröberg
2012-10-09 10:52 ` Martin Peevski
2012-10-09 11:49 ` Stefan Fröberg
2012-10-10 14:52 ` Martin Peevski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5072E581.1000506@ronetix.at \
--to=martin@ronetix.at \
--cc=buildroot@busybox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox