How to get a working system with audio in 2015?

[jomag]

Hi

I have a couple Olinuxino i.MX233 Maxi that I don't use anymore, so I thought they would make excellent AirPlay receivers (using shairport).

So I tried to install Arch Linux using the instructions here:

http://archlinuxarm.org/platforms/armv5/olinuxino

That worked and I had a running system, even if it seems to be a bit unstable. I managed to get shairport to build and everything seems ok, until I try to start playing sound. Then it halts.

The kernel is 3.18.3-1-ARCH. If I understand it correctly there is still no audio support for that kernel on i.MX233?

First I tried to downgrade to 2.6.x but I soon gave up.

Then I went to the official Olinuxino documentation from Olimex and found that it was in a sad state: Lots of references to documentation that was not current anymore, with references to other documentation that was not current either, etc. The arch linux documentation finally led to that page I wrote above.

I tried to download the official Arch image with kernel 2.6, but the link pointed at a non-existing Google document.

So... What to do in 2015? Should I just give up on getting an Olinuxino i.MX233 with audio support to run?

[lambda]

Hi jomag,

I'm using my imx233-olinuxino boards with openwrt (mainline kernel) and that seems to work ok: Uptimes about a year so far.

I never bothered about sound, but the modules are there, so at least the drivers can be compiled on recent kernels successfully.

HTH,
Harald

[swahren]

Hi jomag,

I'm using my imx233-olinuxino boards with openwrt (mainline kernel) and that seems to work ok: Uptimes about a year so far.

I never bothered about sound, but the modules are there, so at least the drivers can be compiled on recent kernels successfully.

HTH,
Harald

Hi,

OpenWRT patches the mainline kernel (should apply with higher kernel versions):

https://dev.openwrt.org/browser/trunk/target/linux/mxs/patches-3.14

Currently i haven't tested the driver, but a lot of people complains about noisy sound.

Stefan

[Hellgringo]

Hi,

I also try to get sound working with my maxi board. I use the current buildroot (git) which is working out of the box with 3.18.2 kernel. Sadly there is no sound support, or I'm to dump to activate it. I downloaded the patches from openwrt for kernel 3.14 and patched 3.18.2. I only had to adapt a warn message, and it compiled. But if I start alsamixer I get the following kernel crash:

Code Select Expand


[    8.760000] Adress of mxs_adc_priv printk ffffff00 # added by me
[    8.760000] Unable to handle kernel paging request at virtual address ffffff04
[    8.770000] pgd = c3a68000
[    8.770000] [ffffff04] *pgd=43ffd831, *pte=00000000, *ppte=00000000
[    8.780000] Internal error: Oops: 17 [#1] ARM
[    8.780000] CPU: 0 PID: 89 Comm: alsamixer Not tainted 3.18.2 #8
[    8.780000] task: c3a80000 ti: c3a58000 task.ti: c3a58000
[    8.780000] PC is at dac_get_volsw+0x34/0x108


Does anybody have an idea what's going wrong?

[popy_pas]

Hi jomag,

I'm using my imx233-olinuxino boards with openwrt (mainline kernel) and that seems to work ok: Uptimes about a year so far.

I never bothered about sound, but the modules are there, so at least the drivers can be compiled on recent kernels successfully.

HTH,
Harald

Hi Harald.

Which openwrt revision are you running with such a long uptime?

thx
pOpY

[lambda]

Which openwrt revision are you running with such a long uptime?

I have various revisions of openwrt running. All seem to behave well.
I think the machine with the highest uptime has kernel 3.14.18 - I don't
track openwrt revisions.

I'd recommend to either use the latest release or the latest trunk. It
would be a lot of bad luck to pick a bad kernel and things generally
have been improved a lot.

About uptime: Maybe some issues people are seeing are actually problems
of the hardware: The bigger boards seem to be not quite noise immune.
Put them togethe with some relays into a metal box and you will get
a lot of crashes - often the watchdog recovers the board, but sometimes
even that fails. Put the relays in some distance to the board and add
proper noise filtering and a -MINI can have good uptime.

The -NANO seems to be more noise immune. Didn't see any crashes even
in harsh environments yet.

HTH,
Harald

[popy_pas]

Which openwrt revision are you running with such a long uptime?

I have various revisions of openwrt running. All seem to behave well.
I think the machine with the highest uptime has kernel 3.14.18 - I don't
track openwrt revisions.

I'd recommend to either use the latest release or the latest trunk. It
would be a lot of bad luck to pick a bad kernel and things generally
have been improved a lot.

About uptime: Maybe some issues people are seeing are actually problems
of the hardware: The bigger boards seem to be not quite noise immune.
Put them togethe with some relays into a metal box and you will get
a lot of crashes - often the watchdog recovers the board, but sometimes
even that fails. Put the relays in some distance to the board and add
proper noise filtering and a -MINI can have good uptime.

The -NANO seems to be more noise immune. Didn't see any crashes even
in harsh environments yet.

HTH,
Harald

Thx Harald for all the infos.

Results of our latest tests have confirmed that SPI2 (DMA) accessing an NOR flash has lead to our stability issues (kernel lock up). See last post here: https://community.freescale.com/thread/301137

Are you using SPI2 (with dma) on your board?

best regards
pOpY

[lambda]

Are you using SPI2 (with dma) on your board?

No.