Just playing along here . . . I thought maybe HDMI had to be loaded to load the audio cape, but seems not. I’m going to start over with a fresh dts file and load the same one as evilwulfie to see if I can get to the bottom of things.
william@beaglebone:~$ sudo sh -c “echo ‘BB-BONE-AUDI-02’ > /sys/devices/platform/bone_capemgr/slots”
william@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
5: P-O-L- 0 Override Board Name,00A0,Override Manuf,WH-UART5
william@beaglebone:~$ dmesg | grep BB-BONE-AUDI-02
[66985.108405] bone_capemgr bone_capemgr: part_number ‘BB-BONE-AUDI-02’, version ‘N/A’
[66985.128912] bone_capemgr bone_capemgr: slot #6: ‘Override Board Name,00A0,Override Manuf,BB-BONE-AUDI-02’
Keep in mind I'm on 4.4.7-bone-rt-r9, not 4.1.x. Dunno if that matters.
Keep in mind I’m on 4.4.7-bone-rt-r9, not 4.1.x. Dunno if that matters.
We’re trying to determine that here. Were you able to get the audio cape loaded at all with a 4.1.x kernel ? We really do not want to move outside of a “stable” kernel if at all possible.
4.4.x is also an lts, the overlay patches between v4.1.x and v4.4.x are
almost identical..
getting really close to swap v4.1.x-ti for v4.4.x-ti... 
Regards,
For the record, I edited recompiled the same main board file as evilwulfie, and . . .
william@beaglebone:~$ sudo sh -c “echo ‘BB-BONE-AUDI-02’ > /sys/devices/platform/bone_capemgr/slots”
william@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
william@beaglebone:~$ dmesg | grep BB-BONE-AUDI-02
[ 47.785411] bone_capemgr bone_capemgr: part_number ‘BB-BONE-AUDI-02’, version ‘N/A’
[ 47.805914] bone_capemgr bone_capemgr: slot #4: ‘Override Board Name,00A0,OverrideManuf,BB-BONE-AUDI-02’
Actually, dahm it, I forgot to edit uEnv.txt . . .
4.4.x is also an lts, the overlay patches between v4.1.x and v4.4.x are almost identical…
getting really close to swap v4.1.x-ti for v4.4.x-ti… 
Regards,
Ok, so we’re not sticking to the traditional even / odd minor version number meanings ?
Nah, v4.1.x was just the outlieer...
ti's used: 3.14 -> 4.1 -> 4.4
Longterm release kernels
VersionMaintainerReleasedProjected EOL
4.4 Greg Kroah-Hartman 2016-01-10 Feb, 2018
4.1 Sasha Levin 2015-06-21 Sep, 2017
3.18 Sasha Levin 2014-12-07 Jan, 2017
3.14 Greg Kroah-Hartman 2014-03-30 Aug, 2016
3.12 Jiri Slaby 2013-11-03 Jan, 2017
3.10 Willy Tarreau 2013-06-30 Oct, 2017
3.4 Li Zefan 2012-05-20 Sep, 2016
3.2 Ben Hutchings 2012-01-04 May, 2018
Regards,
Ok, still not working.
Robert, so is there anything note worthy not working in 4.4* ? We have to know up front . . .
Oh, and right I dont know if it matter for any of this, but we’re trying to avoid ti kernels if possible, so . . . but it seems Rick is using a bone kernel, so ill give that one a shot.
It's in pretty good shape...
am335x:
remoteproc_pruss (not ported)
bbgw = wl1835 & mmc3 fighting either other...
uio_pruss = (v4.4.x-bone) is reported to have been working..
x15:
opencl: (remoteproc_<something>) not ready..
Regards,
Robert, one more question for now if you do not mind. Is there a location on the web where i can view or find this information out myself, without having to bug you all the time ? Well I mean version status, etc.
Thanks for the help, as always 
Ok it is still not working, I’m kind of at a dead end now. I dont know how to proceed from here.
william@beaglebone:~$ sudo sh -c "echo ‘BB-BONE-AUDI-02’ > /sys/devices/platform/bone_capemgr/slots"
william@beaglebone:~$ cat /sys/devices/platform/bone_capemgr/slots
0: PF---- -1
1: PF---- -1
2: PF---- -1
3: PF---- -1
william@beaglebone:~$ uname -r
4.4.7-bone-rt-r9
william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2015-03-01
william@beaglebone:~$ dtc -v
Version: DTC 1.4.1-g1e75ebc9
I’m still seeing this:
pin 82 (44e10948.0): 4a101000.mdio (GPIO UNCLAIMED) function davinci_mdio_default group davinci_mdio_default
pin 83 (44e1094c.0): 4a101000.mdio (GPIO UNCLAIMED) function davinci_mdio_default group davinci_mdio_default
Are these pins required for the ethernet MAC ? And are they interfering with the McASP module ?
Is the audio cape another one of those eeprom capes that need physical hardware in order to load properly ? Because I do not have the physical cape.
So much i dont know.
rick or robert where might i get this file ?
am33xx-es2.dtsi
Its not in the dts-rebuilder i installed and Ricks new dts file seems to
require it to compile
src/arm/am335x-boneblack-audio-emmc.dts:11:27: fatal error:
am33xx-es2.dtsi: No such file or directory
Designing hardware is so much more easier 
I remember firmware in the old days patch the code and burn some
bipolar proms install and continue
You probably need to switch to the 4.4.x branch.
Rick, that’s not the problem dtb-rebuilder and bb.org-overlays neither of these git’s have that source file.
am33xx-es2.dtsi is on the 4.4.x branch.. you had mentioned "
4.1.14-bone-rt-r17 " that's why i pointed out 4.1.x...
Regards,
Do’h just dawned on me hah ! Sorry Rick !
git clone -b 4.4.x https://github.com/RobertCNelson/dtb-rebuilder
Here ya go evilwulfie exact steps . . . just make sure you backup any files you have in there that you may need . . .
william@beaglebone:~$ rm -rf dtb-rebuilder/
william@beaglebone:~$ git clone -b 4.4.x https://github.com/RobertCNelson/dtb-rebuilder
Cloning into ‘dtb-rebuilder’…
remote: Counting objects: 7106, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 7106 (delta 2), reused 0 (delta 0), pack-reused 7095
Receiving objects: 100% (7106/7106), 4.74 MiB | 339 KiB/s, done.
Resolving deltas: 100% (3135/3135), done.