Hi Neil,
Not sure if you already solved this but you are getting this error due to
following:
*[ 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*
Your custom board is loading *am335x-boneblack-uboot-univ.dts* as the
device tree. This dts adds *am335x-bone-common-univ.dtsi* which is already
claiming P9_31. So just comment anything related to P9_31 on
*am335x-bone-common-univ.dtsi* and rebuild
*am335x-boneblack-uboot-univ.dts.*
Thank you,
Samer
On Thursday, January 14, 2021 at 4:49:13 AM UTC-7 Neil Cobbett 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/78d1ab0c-b408-495b-afe6-abfd7213b86bn%40googlegroups.com.
