Anyone have an audio cape working in 4.1.x?

Does anyone have an audio cape working in 4.1.x? Would you share your specific kernel version, DTBO, and ASLA configurations?

Thanks!

In v4.1.x-ti this version still doesn't work:

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

I had fixed all the regulator/sound/etc issues, so it does load, but
sound just doesn't come out..

I'm out for the rest of the week, so can't test it.

Does installing v4.3.x-rc fix your audio cape? (for v4.1.x+ we are
using the same cape overlays..)

sudo apt-get install linux-image-4.3.0-rc3-bone0

Regards,

I'll try that when I get home. Since PRU UIO is broken past -ti-r10, I hadn't considered trying those, but I will. I'm also trying 3.8.13-bone77, but having a heck of a time getting all my stuff back-ported (just niggly little DT things, capemgr in a different place, etc.).

actually PRU uio is only broken in ti's v4.1.x branch.. as the
remoteproc_pruss driver isn't upstream yet, you can renable uio_prus
in v4.1.x-bone/v4.2.x-bone/v4.3.x-bone i've intentionally disabled it
in those branches just so users don't get to use to it..

Regards,

actually PRU uio is only broken in ti’s v4.1.x branch… as the
remoteproc_pruss driver isn’t upstream yet, you can renable uio_prus
*in v4.1.x-bone/v4.2.x-bone/v4.3.*x-bone i’ve intentionally disabled it
in those branches just so users don’t get to use to it…

I’d like a say in that matter myself. e.g. distinctive bone, and ti kernels. But I suppose that a kernel config option that can be changed later to something else ?

Here is the problem I’m seeing with being forced to move to remoteproc. Documentation on the web completely sucks. Essentially, it’s limited to a linux/Documentation/*.txt file. Which to me did not seem very informative. For me though, I tend to understand better if there is a working example. Setup, and all that. Then I can actually learn as I tinker with this example, and read the documentation bit by bit.

In the end, I think remoteproc seems like very cool software technology. However, if there is limited to no documentation on the subject. Then it pretty much is useless . . . I’ve already seen several blog posts concerning the BBB, and remoteproc. They all seem to be in a holding pattern, because they can not seem to get things rolling.

At least with using the PRU the “old way” we actually have something to work with . . .

I think at minimum, It would be good to at least know which config options must be selected, and how they must be selected in order to use the PRUs with current software.

actually PRU uio is only broken in ti's v4.1.x branch.. as the
remoteproc_pruss driver isn't upstream yet, you can renable uio_prus
in v4.1.x-bone/v4.2.x-bone/v4.3.x-bone i've intentionally disabled it
in those branches just so users don't get to use to it..

I'd like a say in that matter myself. e.g. distinctive *bone*, and *ti*
kernels. But I suppose that a kernel config option that can be changed later
to something else ?

*ti* = whatever ti.com want's to push, plus our overlay patches on top
to make it useful. :wink:

*bone* = mainline + overlay...

Here is the problem I'm seeing with being forced to move to remoteproc.
Documentation on the web completely sucks. Essentially, it's limited to a
linux/Documentation/*.txt file. Which to me did not seem very informative.
For me though, I tend to understand better if there is a working example.
Setup, and all that. Then I can actually learn as I tinker with this
example, and read the documentation bit by bit.

In the end, I think remoteproc seems like very cool software technology.
However, if there is limited to no documentation on the subject. Then it
pretty much is useless . . . I've already seen several blog posts concerning
the BBB, and remoteproc. They all seem to be in a holding pattern, because
they can not seem to get things rolling.

At least with using the PRU the "old way" we actually have something to work
with . . .

Which is why we still have Elias Bakken's pru patches from 3.8 still
in the tree..

Regards,

When you say reenable, do you mean by changing a config and building the kernel myself?

Also, is the distinction between -bone and -ti described anywhere?

Thanks,

CONFIG_UIO_PRUSS=m

in v4.1.x-bone/v4.2.x-bone/v4.3.x-bone

for v4.1.x, the remoteproc_prus changes broke it..

Regards,

-bone = mainline + overlays
-ti = mainline + ti.com tree + overlays..

Regards,

So, just so I'm clear, if I want to try with 4.3.x-bone, I need to build the kernel from source and set that config, right? You have it off by default in -bone?

Thanks,

Yeap... just:

git clone https://github.com/RobertCNelson/bb-kernel/
cd bb-kernel/
git checkout origin/am33x-v4.3 -b tmp
./build_deb.sh

(menuconfig loads -> enable uio_pruss)

copy linux-image*.deb to board, run: sudo dpkg -i linux-image*.deb
then reboot..

Regards,

What kind of stuff does TI add? remoteproc, obviously. What does one give up by not having TI's changes?

well "everything"...

Take: http://git.ti.com/gitweb/?p=ti-linux-kernel/ti-linux-kernel.git;a=shortlog;h=refs/heads/ti-linux-4.1.y
and raw line diff it directly against kernel.org's v4.1.8, you'll see
how massive the changes are...

ti follow's kernel.org' lts, so when v4.1.x got selected, they
"retired" v3.14.x tree and started developing on "v4.1.x" for all
currently supported products (am3/am4/am5/dra7/keystone/etc..) they
also submit these patches to mainline. They then release these
kernel's in their product sdk's..

Regards,

Thanks, building now.

Yeap… just:

git clone https://github.com/RobertCNelson/bb-kernel/
cd bb-kernel/
git checkout origin/am33x-v4.3 -b tmp
./build_deb.sh

(menuconfig loads → enable uio_pruss)

copy linux-image*.deb to board, run: sudo dpkg -i linux-image*.deb
then reboot…

Thanks for that Robert, it is as easy as I thought it might be - But I was not sure. As for what ti runs on their kernel, I personally do not care one way or the other. But I do have a problem with previously working bit and pieces becoming broken because of it. But I digress, this would be why it would be refereed to as a “testing branch” I suppose. So far though, I’m seeing mostly a lot of good in 4.x, and would hate to have to revert to the “stone age” as it were . . .

Do I need to do anything with bb.org-overlays or dtb-rebuilder before I reboot?

So.. what would you guys like me to do.. rip out remoteproc_prus so
uio_pruss works again, even thou all of ti's pru tools/wiki are being
updated for remoteproc_pruss.. I currently don't use the 'pruss' system, so
someone will have to maintain it for v4.1.x-ti..

The other option, when remoteproc_pruss doesn't exist just enable
uio_pruss...

Regards,

Nope, your overlays are already under /lib/firmware/ so just by
running dpkg above they got added to the initramfs. (this is nice
about separating the kernel from the *.dtbo objects)

Regards,

I think what you're doing is right, especially for the -ti builds. It's the guys at TI (or anywhere) that make changes that need to ensure old stuff doesn't break, and at the very least make it easy to move to the new thing.

That we can reproduce your build to turn off remoteproc and turn on pruss (and hopefully have it work in that case) is probably good enough.