4.1 repo

Hey Guys,

Just a heads up, the 4.1 branch:

https://github.com/beagleboard/linux/tree/4.1

Is now based on ti's 4.1.x-ti release. (same thing we did with 3.14.x)

http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.1.y

(this really doesn't change anything from what we were doing with
4.1.x, it's just that it'll have more patches from ti for
am335x/am57xx parts. :wink: )

Regards,

Hey Robert,

Is there a list of things somewhere that do not work currently ? Personally, I want to make the leap, but I would not enjoy spending a lot of time messing with 4.1.x only to find there is / are problem(s) without any easy work around. Also, how is capmgr coming along ?

It really depends on what peripheral you need...

Here's the list of everything working:

https://github.com/beagleboard/bb.org-overlays/tree/master/src/arm

there are some issues with the audio rev b, but i can't find that
board for sale anywhere anymore. (i have the rev a)

If you need something specific that worked only in 3.8.x, just ask and
we will hack it up and try to fix..

Regards,

there are some issues with the audio rev b, but i can’t find that
board for sale anywhere anymore. (i have the rev a)

Hi Robert,

Could you elaborate on the issues you’re seeing with the Audio Cape? I’m having trouble using the audio system as described here, and I’m wondering if it’s the same Transmit Buffer Underflow problems you’re seeing.

Kind Regards,
Shadi

Most of the issues are now fixed:

https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-AUDI-02-00A0.dts

https://github.com/beagleboard/bb.org-overlays/commits/master/src/arm/BB-BONE-AUDI-02-00A0.dts

But i think audio (output) was still not working..

Now that the reset bug has a workaround, i'll try and look at audio
again today..

Regards,

But i think audio (output) was still not working…

Now that the reset bug has a workaround, i’ll try and look at audio
again today…

Ok. I’ll wait for your reply then.

Thanks for taking the time. Much appreciated.

Best,
Shadi

But i think audio (output) was still not working…

Hi Robert,

Did you get a chance to look at the audio out and whether it’s working?

Kind Regards,
Shadi

Is there any word on the audio cape rev B working with 4.1 in Ubuntu? I’ve gotten it working in Debian, but would like to get it working in Ubuntu. I’ve run into an error where the codec is unable to sync registers 0x1-0x1, -121 (whatever that means).

When I say I got it working in Debian, I meant to say I got it working on 3.8 in Debian. My mistake.

Hi Shadi,
I have same problem .( Transmit Buffer Underflow problem) .
I’m using kernel 4.1.1 and audio cape rev B ( that uses aic3104 codec) for playing audio.

I will be glad if you tell me that you solve the problem or not.

Regards,

Hi Hussain,

I have not been able to solve it. I’ve reported it to the ALSA developer list as well, but haven’t received an answer (yet):
http://mailman.alsa-project.org/pipermail/alsa-devel/2015-September/097147.html

Also, Rick Mann seems to be having similar problems getting an audio board working on 4.1 and later. You can read about it here:
https://www.mail-archive.com/beagleboard@googlegroups.com/msg31247.html

I’ve been meaning to try newer kernels to see if it is fixed, but haven’t found the time yet. Will report here if I get around to it.

Best Regards,
Shadi

Also, Rick Mann seems to be having similar problems getting an audio board working on 4.1 and later. You can read about it here:
https://www.mail-archive.com/beagleboard@googlegroups.com/msg31247.html

A better subject line would've been very helpful. I almost deleted this message without seeing it.

Yes, I'm seeing this. I had assumed it was a problem with my board. I finally got ahold of a production Audio Cape, but now I'm expecting to see the same problem.

For me, even though the DTB specifies a 12 MHz MCLK, I'm seeing 24 MHz when I measure with an oscilloscope. It's probable that's causing the buffer underflow issue.

Thanks for your attention and quick reply.

I have another problem.

I want to drive TLV320AIC23 codec to play and record audio.
I Migrated from kernel 3.8 to 4.1, because kernel 3.8 dose not support this codec, and

i couldn’t add this codec to kernel 3.8.

What is your idea? Is there any way to add this codec to kernel 3.8?

It is ideal for me to use kernel 3.8, because of stability of this version.But if i can drive codec in kernel 4.1

it is not a too bad solution!

Regards

3.8 isn't actually that stable, both mmc and usb are ticking time
bomb's just waiting to opps..

Regards,

I'd love to move to 4.x, if I could get the audio to work correctly. Still struggling with it (I have verified that both the audio cape and my own cape work great in 3.8.x).

Thanks Robert and Rick,
I’ll be appreciate if you inform about the result of your work on audio in 4.x.

I did not have any problem with audio in 3.8. and now I’m trying to get the audio to work on uSomiQ Board.
uSomIQ AM335x is a BeagleBone Black clone with added more robust SLC NAND flash and it’s schematic is almost 1:1 copy of BBB.
I have trouble with it. Audio comes out but is noisy.
I’ve also tested board with the same kernel and RFS as BBB ( after some minor change in capemgr diver) but the result has not changed.
If you had any experience with this board, I’ll be glad if share your comment here.

Best regards.

Robert,
Any updates on this? I just moved from r21 to r35 and created the DTC for my TLV320AIC3104 as specified here: https://github.com/beagleboard/bb.org-overlays/commits/master/src/arm/BB-BONE-AUDI-02-00A0.dts
I can see and configure the device but it chokes on speaker-test; it makes one blip on the output then freezes. Does the audio output bug persist?
Thank you,
Bruce

No, i haven't gotten the audio cape to work yet. I've cleaned up the
boot errors enough where we don't really have any more hints of where
it's messed up, and i don't know enough of the asoc layer to fix it at
this point.

I've had reports that hdmi-audio works fine, so audio does work..
(just not this cape/overlay)

Regards,

I’m getting an overrun error at this point and not an underflow. I am also measuring 24MHz on MCLK regardless of what I specify.
These clocks are defined within the default am335x-boneblack.dtb. I pay special attention to the clk_mcasp0 as it specified the gpio-gate-clock which uses external oscillator, Y4, on the BBB to generate that signal. I’ve attempted modifying the clock-frequency value but it does not have an effect, I still see 24MHz on the output.

`
clk_mcasp0_fixed {
#clock-cells = <0x0>;
compatible = “fixed-clock”;
clock-frequency = <0x1770000>;
linux,phandle = <0x51>;
phandle = <0x51>;
};

clk_mcasp0 {
#clock-cells = <0x0>;
compatible = “gpio-gate-clock”;
clocks = <0x51>;
enable-gpios = <0x48 0x1b 0x0>;
linux,phandle = <0x54>;
phandle = <0x54>;
};
`

Also I’ve specified the clock within the simple-card binding as follows:

`
sound_master:simple-audio-card,codec {
sound-dai = <&tlv320aic3104_aq1>;
clocks = <0x54>;
/* system-clock-frequency = <12000000>; */
};

`

This allows me to use the defined clock, referenced by its phandle, for my codec. In this configuration it is the codec that is doing the clock generation as it is defined as the master. In my case, it is generating a BCLK and a WCLK but at a much higher frequency that what is expected, i.e, I issue an arecord test.wav, I should see BCLK at 8KHz but it is instead at 16KHz. Or is that what I should expect for BCLK considering Nyquist Theorem, etc, need to sample at twice the desired frequency? On second thought, this entire thing is configured for TDM and I am not very familiar with what I should be seeing vs. what I am seeing.

I’d also like to add that I am seeing data on both AIN and AOUT but its coming in much faster than we’d expect hence the:
root@beaglebone:~# arecord test.wav
Recording WAVE ‘test.wav’ : Unsigned 8 bit, Rate 8000 Hz, Mono
overrun!!! (at least 0.109 ms long)
overrun!!! (at least 0.064 ms long)
overrun!!! (at least 0.754 ms long)

or the

root@beaglebone:~# speaker-test

speaker-test 1.0.28

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 256 to 32768
Period size range from 128 to 16384
Using max buffer size 32768
Periods = 4
was set period_size = 8192
was set buffer_size = 32768
0 - Front Left
Write error: -32,Broken pipe
Write error: -32,Broken pipe
Write error: -32,Broken pipe
Time per period = 0.101305
0 - Front Left
Write error: -32,Broken pipe
Write error: -32,Broken pipe
Time per period = 0.054033

Not sure what to make of the Broken Pipe but there you have it.

It looks to me like the problem came about because the function prepare_unused_channel_list() in arch/arm/common/edma.c for 4.1 kernels was modified to use the device tree for determining which dma channels to enable (by clearing appropriate edma_unused bits in the edma struct). However, this function is called before processing of the cape device tree overlays begins. Since the base dtbo files do not have appropriate references to the McASPs, their dmas are not enabled. When the cape is loaded, it appears that everything works, but since dma is not enabled, the required dma transfers do not occur. Hence the underrun errors for play and overrun errors for record.

A simple workaround that worked for me was to add the following to arch/arm/boot/dts/am335x-boneblack.dts:

&mcasp0 {
status = “okay”;
};

This may not be the best solution. It seems to me that a better solution would be to modify the kernel so that if a device that uses DMA is enabled by a device tree overlay, the kernel would enable the DMA when it parses the overlay. However, I have practically no experience or knowledge of Linux at the kernel level, so may be completely off base.