Hi Ray, A bit more information:
This is my CODEC: tlv320aic3104 <https://www.ti.com/lit/ds/symlink/tlv320aic3104.pdf?ts=1610610048561&ref_url=https%253A%252F%252Fwww.ti.com%252Fproduct%252FTLV320AIC3104%253FkeyMatch%253DTLV320AIC3104%2526tisearch%253DSearch-EN-everything%2526usecase%253DGPN> For McASP, pin maps as follows: BBB P9 TLV320 P25 AUD_IN P40 P28 AUD_OUT P41 P29 FS/WCLK P39 P31 BCLK P38 The codec is clocked by a dedicated temperature controlled 12MHz oscillator The pin description in the DTS is a little misleading. Neil On Thu, 14 Jan 2021 at 11:48, 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 0x1b > I 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 >> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature> >> >> 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 >> <https://groups.google.com/d/msgid/beagleboard/9ec369e7-8985-4d6f-9937-92e1e830cf1dn%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> >> -- >> 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 >> <https://groups.google.com/d/msgid/beagleboard/11045771.1057062.1610594190333%40mail.yahoo.com?utm_medium=email&utm_source=footer> >> . >> > -- 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_pzB7M%3Dx7s%2BYA6Yu2iF4YhS4q4Bg0qwzaFSSqzFrUibb7qMg%40mail.gmail.com.
