Thanks Samer,

I still need to work out how to do this.  I'm just returning to Beaglebone
after a few years break and 'everything' has changed ;)

At the moment I am loading DTBO's via the uboot loader but speaking with
Ray, he suggests doing it like you said.  I still need to work it out and
have a play.

Many thanks
Neil


On Fri, 15 Jan 2021 at 20:47, Samer Abbas <sam.abb...@gmail.com> wrote:

> 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 <
>> beagl...@googlegroups.com> 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
>>> <neil.c...@gmail.com> 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 beagleboard...@googlegroups.com.
>>> 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
>>> beagleboard...@googlegroups.com.
>>> 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 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
> beagleboard+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/beagleboard/78d1ab0c-b408-495b-afe6-abfd7213b86bn%40googlegroups.com
> <https://groups.google.com/d/msgid/beagleboard/78d1ab0c-b408-495b-afe6-abfd7213b86bn%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 the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CAA_pzB4_83Jqa7NSOoeV02_Z8RB1yjFQRO%2BBKTtsidCTno3inQ%40mail.gmail.com.

Reply via email to