Neil,
Here's some loooooong info based on the information you sent. They correlate to
the answers you provided below plus more.
1. That's good that i2cdetect found the device on the bus. This tells me that
ALSA is not setting up the device driver properly (Through the MCASP pins). I
noticed in my development, everything has to be just right in order for that to
happen.
2. for the MCASP Pins, you are also using "P9.31 " /* mcasp0: mcasp0_axr3 */
3. Both axr2 and axr3 cannot be both inputs. AXR is bi-directional, but the
audio codec needs one to be set to transmit (X) and one to be receive (R). Why
it ever worked before is a mystery. And setting up their direction is two
parts... in the device tree pinmux and in the serialization of the "sound" node
of the device tree. I'll give an example below. I've always had to define
whether it's a PULLUP or PULLDOWN also and do not believe these can be left
free-floating.
4. If you are creating a ".dtbo" file, that is a CAPE OVERLAY, not a DEVICE
TREE file (which ends with ".dtb"). It's been stated to move away from CAPE
OVERLAYS as they are extremely buggy. You can create a Device Tree and it is
used an overlay to the active device tree. The reason you seen what you did is
that address "190" was being used by the Kernel and you can't allocate two
device pinmux using the same pin address.
5. To see issues, you should be using $ dmesg in your terminal. It outputs the
kernel log form /var/logs/ messages. It'll tell you if it's running the TLV320
in there. You can also see if your sound codec is being used by typing $
alsamixer in the terminal. This will bring up a GUI of your sound codec. It
should be something different than PulseAudio. Furthermore, add the following
line to your overlay in the fragment for sound {.....}, just below the
capability line: simple-audio-card,name = "Audio Name I Want";
Whatever you put as "Audio Name I Want" will show up in place of PulseAudio if
ASLA is using the TLV320 codec when you check alsamixer.
6. Whenever you change or create a Cape Overlay you MUST run
"/opt/source/bb.org-overlays/install.sh". You are doing most of what needs to
be done... except rebuilding the /boot/initrd.img-<Kernel build> file (mine is
initrd.img-4.19.94-ti-r50). Just running install.sh is all you need to do, it
will put everything in the firmware directory and rebuild the image.
So why does it have to be this way?.... Form my understanding, if your new cape
is different than the one in that image file or you created a new cape overlay,
it will not match what's in that image file. I believe this is done as sort of
a checksum to ensure it's a valid overlay for a device. That you cna't just
plug anything in and destroy the device. The idea was a cape can be added
(connected) and nothing done to the uEnv.txt file and the cape is automatically
loaded for use by detecting the cape, putting it's overlay in one of the four
cape manager slots and using it to overlay the active device tree. I bet if you
check $ dmesg in the terminal, you'll find a line that says it failed to load
BB-BONE-AUDI-02.
Device trees are in an entirely different location.....
/opt/source/dtb-<current kernel>-ti/src/arm. As an example, mine is
/opt/source/dtb-4.19-ti/src/arm. Be weary, they now add the last and newest dtb
directories as well. use the one that matches your kernel number in the
uEnv.txt file. If you create a device tree, the make file will use dtc to build
it from /opt/source/dtb-<kernel>-ti/. Here's an example of how I rebuild device
trees and use them. I copy "my_devicetree.dts" to
/opt/source/dtb-4.19/src/arm/. usually by just putting the uSD card in my
laptop.
$ cd /opt/source/dtb-4.19-ti/ $ sudo touch src/arm/*
sudo touch will change the timestamp of all files (*) in that
directory. If not you will get an error when building the device tree for the
time being in the future. $ sudo make src/arm/my_devicetree.dtb If
there are any errors, it'll tell you the line number. fix it. $ sudo cp
src/arm/my_devicetree.dtb /boot/dtbs/<kernel number>/
Then in the uEnv.txt file, I uncomment #dtb= to dtb=my_devicetree.dtb.
A device tree does not have to be built into the intird.img file.
Lastly, In your mcasp{.....} node fragment. You'll see numbers under the
serial-dir configuraiton. Those number correlate to te RX you are using. In
BB-BONE-AUDI-02, the first line is 0 0 2 1 and correlate to RX0 RX1 RX2 RX3. As
you can see RX2 is set as Recieve (or RX) and RX3 is set to Transmit (or TX).
Those need to match the input/output direction in the pinmux... which is not
the case we see. I never got my development audio board to work until I set the
direcitons accordingly. If RX2 is set to RX, then the pin should be an INPUT,
if RX3 is set to TX, then it's pin should be an OUTPUT.
I attached an example of the Cape Overlay I did before I moved to using a
device tree instead. This worked fine for my prototype device (not the exact
same as your audio cape device), but you can see how I had to change things to
make it work. If you are using a 3104, just change everything form 3106 to 3104
(I think it's 3 places).
Sorry it was a lot but I learned a lot over the last 2 years working on a linux
based Embedded System for my employer. And I like ppl to try and use
information to develop on their own.
Does the Audio Cape Device pinout actually match BB-BONE-AUDI-02?
On Thursday, January 14, 2021, 5:49:09 AM CST, Neil Cobbett
<[email protected]> wrote:
Hi Ray,
Thanks for the offer of help, very much appreciated! ;) I've been going around
in circles for days with this problem. I developed my own cape around the
TLV320 (in c. 2016) and it had been working fine previously. I've upgraded
from 3.x kernel to 4.x with some issues with device tree changes (in c. 2018)
but solved them pretty quickly. This time, again I want to upgrade to a later
kernel and use a RT kernel due to some timing 'jitter' issues I was having with
the collected data. The cape records the VLF radio spectrum (basically audio)
and is used to detect things like solar flares. It's very sensitive to phase
shifts in signal so needs very precise timing to keep running (I use a GPS
Pulse per second fed into the other channel of the sound card to act as an
accurate phase reference marker - GPS satellites use atomic clocks). I started
with a fresh Beaglebone Install using the latest LTS RT kernel rather than
working with a patched system with numerous 'hacks'. I moved my DTS files
across and recompiled but have gotten stuck with the McASP not working and ALSA
not detecting the soundcard. It is to do with either the DTS file or some step
with uBoot loading the DTBO and ALSA detecting the hardware.
Anyway, on to your questions:
1.I2C is using i2C2 'bus 2'TLV320 is mapped to 0x1bI can also see the device
assigned on this bus with the i2cdetect command.
2.McASP Pins:"P9.31", /* mcasp0: mcasp0_aclkx */
"P9.29", /* mcasp0: mcasp0_fsx */
"P9.28", /* mcasp0: mcasp0_axr2 */
"P9.25", /* mcasp0: mcasp0_ahclkx */
3.Direction and Mode setting of the multiplexer:pinctrl-single,pins = <
0x190 0x20 /*
mcasp0_aclkx.mcasp0_aclkx, INPUT | MODE0 */
0x194 0x20 /*
mcasp0_fsx.mcasp0_fsx, INPUT | MODE0 */
0x19c 0x22 /*
mcasp0_ahclkr.mcasp0_axr2, INPUT | MODE2 */
0x1ac 0x22 /*
mcasp0_ahclkx.mcasp0_axr3, INPUT | MODE2 */
NB: ^^^ not sure this direction setting ir tight but it has worked fine
previously so I have not touched it.
4.The dtbo worked fine in the last iteration using a 4.4 Kernel. I upgraded to
a 5.4 RT kernel (RT_PREEMPT patch). At first it complained with mapping the
pins:
[ 43.009888] pinctrl-single 44e10800.pinmux: pin PIN100 already requested by
ocp:P9_31_pinmux; cannot claim for 48038000.mcasp
[ 43.009914] pinctrl-single 44e10800.pinmux: pin-100 (48038000.mcasp) status
-22
[ 43.009926] pinctrl-single 44e10800.pinmux: could not request pin 100
(PIN100) from group pinmux_bone_audio_cape_audio_pins on device pinctrl-single
Doing a bit of searching on the web (where is the documentation for all this
new/changed information?) I found I now need to add the following to the DTS
file:
P9_25_pinmux { status = "disabled"; }; /* mcasp0_ahclkx */
P9_28_pinmux { status = "disabled"; }; /* mcasp0_axr2
*/
P9_29_pinmux { status = "disabled"; }; /* mcasp0_fsx */
P9_30_pinmux { status = "disabled"; }; /* mcasp0_axr0
*/
P9_31_pinmux { status = "disabled"; }; /* mcasp0_aclkx
*/
Like I say, I'm not sure if this is what needs to be done since I can't find
any documentation to confirm but after drilling into newer DTS files (AUDI-02),
I see that to define my own pins, I need to 'disable' them from some sort of
generic Devicetree mapping.
5.Running 'sudo /opt/scripts/tools.version.sh' to look for problems, I am now
seeing no conflicts with ^^4. added to my DTS file. However, Alsa is still not
detecting the soundcard; using aplay -l. I'm not sure if it is to do with me
misunderstanding ^^ 4. or I am missing a further step somewhere along the way.
I've done quite a bit of Alsa work before and I am used to editing asound.conf
files. I dsnoop to allow different experiments to connect to the same input
sound stream simultaneously. For some reason the Kernel is loading Alsa BUT
Alsa isn't seeing any soundcard hardware. (BTW I've disabled HDMI;
uboot_overlay_options:[disable_uboot_overlay_video=1) since this use to
conflict with adding an additional soundcard.
6.RE: 'If using a cape and making changes, use install.sh or it won't work.'
Can you explain what you mean here? Previously, I compiled dts in my own
directory with dtc to get dtbo, copied dtbo to /lib/firmware then pointed the
uEnv file at the dtbo file. Has this step changed or do I need to do another
intermediate step?
RE: '-The better option is to learn how to create your own device tree and put
it as an Overlay in the uEnv.txt file.' I think this is what I am doing already.
What would be really good to have is some diagnostic tools like we had in the
older 3.x kernel. Someway of easily checking the pin assignments and some sort
of debugging of the device tree. Also a reference document. A lot of the
stuff I find on line to explain how to create DTS files and add user defined
cape boards is out of date and mappings in /sys have changed.
I've attached by DTS file. NB: I have added fragment@0 to fix ^^^4 but other
than that the old 'working' DTS file is the same.
Thanks for offering to help Ray!Neil
On Thu, 14 Jan 2021 at 03:16, 'Raymond Willis' via BeagleBoard
<[email protected]> wrote:
Neil,I think I can help. I worked on a custom prototype board and set up my own
TLV320 with an Octavo RED board in predevelopment in the device tree and is
working fine. Some things you absolutely need to know before changing things in
the cape dts file.-What I2C bus and pinmux are you using.-What MCASP bus are
you using in pinmux? Definitely need 2 of the 4 RX pins. - You need to learn
how to set up your asound.conf file. This has so many possibilities based on
how you want to sample the audio. -If using a cape and making changes, use
install.sh or it won't work.-The better option is to learn how to create your
own device tree and put it as an Overlay in the uEnv.txt file.
If the actual cape hasn't changed at all (pins). Then I'll show you how to just
make a device tree of that cape overlay.
I'll provide more details tomorrow.
Regards, Ray
Sent from Yahoo Mail on Android
On Tue, Jan 12, 2021 at 6:37 PM, Neil Cobbett<[email protected]> wrote:
HI,
Has anyone managed to get the old/original Circuit Co Audio Cape Revision A
working on the later kernels?
This is the dts file associated with cape board and has worked fine on the
older 3.x kernels:
BB-BONE-AUDI-01.dts
It doesn't seem to be installed/supported as part of the latest /lib/firmware
directory. It compiles ok but when added to uEnv.txt it doesn't work:
debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh
[sudo] password for debian:
git:/opt/scripts/:[fe926a6a4cf5805041878d7df82b58c00b4f902e]
eeprom:[A335BNLTBWA51712EW004800]
model:[TI_AM335x_BeagleBone_Black_Wireless]
dogtag:[BeagleBoard.org Debian Buster IoT Image 2020-04-06]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot SPL
2019.04-00002-g07d5700e21 (Mar 06 2020 - 11:24:55 -0600)]:[location: dd MBR]
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot
2019.04-00002-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot SPL
2018.03-00002-gac9cce7c6a (Apr 05 2018 - 13:07:46 -0500)]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot
2018.03-00002-gac9cce7c6a]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BBBW-WL1835-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-I2C1-FAST-00A0]
UBOOT: Loaded Overlay:[BB-PWM2-00A0]
UBOOT: Loaded Overlay:[BB-UART1-00A0]
UBOOT: Loaded Overlay:[BB-UART2-00A0]
kernel:[5.4.87-bone-rt-r41]
nodejs:[v10.15.2]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[uboot_overlay_addr0=/lib/firmware/BB-UART1-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr1=/lib/firmware/BB-UART2-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr2=/lib/firmware/BB-PWM2-00A0.dtbo]
uboot_overlay_options:[uboot_overlay_addr3=/lib/firmware/BB-I2C1-FAST-00A0.dtbo]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-BONE-AUDI-01-00A0.dtbo]
pkg check: to individually upgrade run: [sudo apt install --only-upgrade <pkg>]
pkg:[bb-cape-overlays]:[4.14.20200403.0-0rcnee0~buster+20200403]
pkg:[bb-customizations]:[1.20200306.0-0rcnee0~buster+20200306]
pkg:[bb-usb-gadgets]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[bb-wl18xx-firmware]:[1.20200322.0-0rcnee0~buster+20200322]
pkg:[kmod]:[26-1]
pkg:[librobotcontrol]:[1.0.4-git20190227.1-0rcnee0~buster+20190327]
pkg:[firmware-ti-connectivity]:[20190717-2rcnee1~buster+20200305]
groups:[debian : debian adm kmem dialout cdrom floppy audio dip video plugdev
users systemd-journal bluetooth netdev i2c gpio pwm eqep remoteproc admin spi
iio docker
tisdk weston-launch xenomai cloud9ide]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1
root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0
lpj=1990656 rng_cor
e.default_quality=100 quiet]
dmesg | grep remote
[ 1.933071] remoteproc remoteproc0: wkup_m3 is available
[ 2.109940] remoteproc remoteproc0: powering up wkup_m3
[ 2.109966] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf,
size 217168
[ 2.110232] remoteproc remoteproc0: remote processor wkup_m3 is now up
dmesg | grep pru
dmesg | grep pinctrl-single
[ 1.565521] pinctrl-single 44e10800.pinmux: 142 pins, size 568
[ 1.921849] pinctrl-single 44e10800.pinmux: pin PIN18 already requested by
ocp:P9_14_pinmux; cannot claim for ocp:gpio-leds-cape-audio
[ 1.921870] pinctrl-single 44e10800.pinmux: pin-18
(ocp:gpio-leds-cape-audio) status -22
[ 1.921881] pinctrl-single 44e10800.pinmux: could not request pin 18 (PIN18)
from group pinmux_bone_audio_cape_led_pins on device pinctrl-single
[ 43.009888] pinctrl-single 44e10800.pinmux: pin PIN100 already requested by
ocp:P9_31_pinmux; cannot claim for 48038000.mcasp
[ 43.009914] pinctrl-single 44e10800.pinmux: pin-100 (48038000.mcasp) status
-22
[ 43.009926] pinctrl-single 44e10800.pinmux: could not request pin 100
(PIN100) from group pinmux_bone_audio_cape_audio_pins on device pinctrl-single
dmesg | grep gpio-of-helper
[ 1.577714] gpio-of-helper ocp:cape-universal: ready
lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
END
****
The BB-BONE-AUDI-02 is supported but uses different pins for the I2S / McASP
interface. Also the I2C mapping is different.
Can anyone point me at a working BB-BONE-AUDI-01.dts for the later BBB releases?
I've tried editing the original but after several failed attempts, I can't get
it to mount via alsa.
Many Thanks
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/9ec369e7-8985-4d6f-9937-92e1e830cf1dn%40googlegroups.com.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to a topic in the Google
Groups "BeagleBoard" group.
To unsubscribe from this topic, visit
https://groups.google.com/d/topic/beagleboard/CCt_WjfHBC8/unsubscribe.
To unsubscribe from this group and all its topics, send an email to
[email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/11045771.1057062.1610594190333%40mail.yahoo.com.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/CAA_pzB6vtUeuXkrzTsgVgURBKVv9%3DtOwKs9QFpzYVtv9_4mDQg%40mail.gmail.com.
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/1880959977.1145221.1610639928545%40mail.yahoo.com.
