13:01 <Siegurd> Hello! I finally make AD7771 work in DOUT mode and I get all 4 channels output at 128kSPS. Now it's software time.

13:12 <Siegurd> the oscilloscope shows 8.19203 MHz on CLK as described in datasheet.

13:37 <Siegurd> I found this example of mcasp driver: https://github.com/overlordtm/mcasp-spi/tree/master but it seems it does not support 4 channels input.

14:18 <zmatt> Siegurd: ehh that just looks like someone's pet project

14:18 <zmatt> unmaintained pet projec

14:19 <zmatt> while it would be nice to have a more general-purpose mcasp driver that doesn't require alsa, using the normal alsa driver is probably still the best way to go right now

14:20 <zmatt> let me see if I can make an example

14:22 <zmatt> Siegurd: and I can see why you'd want to use the highest sample rate... this thing has pretty crappy decimation filtering :P

14:53 <Siegurd> yeah)

14:54 <Siegurd> I can do filtering later after data placed in to influxDB

15:11 <zmatt> Siegurd: I added my first attempt at a suitable DT overlay to https://github.com/mvduin/overlay-utils (ad7771-mcasp0.dtsi)

15:15 <zmatt> alsa is a bit of a chore to deal with... :P

15:23 <Siegurd> should ad7771-mcasp0.dtbo be placed into /sys/kernel/config/device-tree/overlays/ ?

15:25 <zmatt> uhh, applying overlays at runtime has been deprecated for a very very long time

15:25 <Siegurd> so I need to patch system?

15:26 <zmatt> are you using beagleboard.org debian image?

15:27 <zmatt> on beagleboard.org images overlays are applied by u-boot and configured via /boot/uEnv.txt

15:27 <Siegurd> I use this eMMC version: https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshot-2023-08-05/31280

15:27 <zmatt> yeah

15:28 <Siegurd> I have also Debian 11 virtual machine running to compile kernel

15:28 <zmatt> you'll need to uncomment disable_uboot_overlay_audio=1 to disable HDMI-audio (since its pinout conflicts) and then configure the path to the ad7771-mcasp0.dtbo file into any of uboot_overlay_addr4..7

15:31 <zmatt> (those four variables are available for custom overlays, as well as the dtb_overlay variable... they're all equivalent basically. I'm actually not sure why those are even separate variables instead of just one variable containing a list of paths :P )

15:34 <Siegurd> I do cp /home/debian/ad7771-mcasp0.dtbo /boot/dtbs/5.10.168-ti-r68/overlays/

15:35 <Siegurd> and uboot_overlay_addr4=ad7771-mcasp0.dtbo and disable_uboot_overlay_audio=1 in uEnv.txt

15:35 <Siegurd> also to be shore  chmod +x "/boot/dtbs/5.10.168-ti-r68/overlays/ad7771-mcasp0.dtbo"

15:36 <zmatt> I'd suggest putting the overlay in /lib/firmware or really just about anywhere else (you can configure the full path into the variable) but not in a kernel-version-specific directory

15:36 <Siegurd> ok

15:36 <zmatt> otherwise if you update your kernel your system will no longer boot

15:37 <zmatt> (unless the error handling in u-boot is more graceful nowadays :P )

15:37 <zmatt> and dtbo files are not executables, it should not be chmod +x

15:40 <Siegurd> cp /home/debian/ad7771-mcasp0.dtbo /lib/firmware

15:40 <Siegurd> uboot_overlay_addr4=/lib/firmware/ad7771-mcasp0.dtbo in uEnv.txt

15:40 <Siegurd> done

15:40 <Siegurd> rebooting

15:41 <zmatt> time to discover if I screwed up ;)

15:41 <Siegurd> =D

15:42 <zmatt> my show-pins util is a useful way to check if at least the pinmux looks okay: https://github.com/mvduin/bbb-pin-utils/#readme

15:42 <Siegurd> the board hangs and 4 led's are on

15:43 <zmatt> that's sub-optimal

15:44 <Siegurd> I do quick image rewrite on eMMC

15:44 <zmatt> that's a bit of a sledge-hammer solution but it works I guess

15:44 <Siegurd> or you want to see uart output?

15:44 <zmatt> I do actually

15:45 <zmatt> it would be good to know where it failed

15:45 <Siegurd> ok, 15 minutes, I will connect usb-uart converter

15:46 <zmatt> actually, I think I found the issue already

15:46 <zmatt> I should have run my own check_overlay script before pushing to git :P

15:48 <zmatt> fix pushed

15:49 <Siegurd> ok, cuz I didn't found converter and starting to write BlackPill usart-usb transparent channel)

15:50 <Siegurd> image is flashing...

15:53 <Siegurd> copying new ad7771-mcasp0.dtbo

15:56 <Siegurd> it booting!)))

15:58 <Siegurd> installing show-pins

15:58 <zmatt> if I stop responding I fell asleep :P

15:59 <Siegurd> P9.31 / hdmi audio clk 100 fast rx up 0 asp 0 tx clk mcasp@48038000 (asp0)

15:59 <Siegurd> P9.29 / hdmi audio fs 101 fast rx down 0 asp 0 tx fs mcasp@48038000 (asp0)

15:59 <Siegurd> P9.30 102 fast rx down 0 asp 0 data 0 mcasp@48038000 (asp0)

15:59 <Siegurd> P9.28 / hdmi audio data 103 fast rx down 7 gpio 3.17 << lo P9_28 (pinmux_P9_28_default_pin)

15:59 <Siegurd> P9.42 104 fast rx down 2 asp 0 data 2 mcasp@48038000 (asp0)

15:59 <Siegurd> P9.27 105 fast rx down 2 asp 0 data 3 mcasp@48038000 (asp0)

16:00 <Siegurd> P9.41 106 fast rx down 0 asp 0 data 1 mcasp@48038000 (asp0)

16:00 <Siegurd> P9.25 / audio osc 107 fast rx down 7 gpio 3.21 << lo P9_25 (pinmux_P9_25_default_pin)

16:00 <Siegurd> P9.41 / jtag emu3 109 fast rx 7 gpio 0.20 mcasp@48038000 (asp0)

16:00 <zmatt> please don't paste multi-line output into chat, use e.g. pastebin.com

16:00 <zmatt> but yeah that seems fine

16:02 <Siegurd> sorry I was in hurry

16:03 <zmatt> copy-pasting into pastebin takes like 2 seconds

16:03 <zmatt> being "in a hurry" is not an excuse for spamming chat

16:04 <Siegurd> https://pastebin.com/pdLshd87

16:05 <zmatt> anyway, you presumably now have a /dev/snd/pcmC0D0c device and (if the ad7771 has been setup and is outputting data) should be able to receive it via alsa (including using arecord)

16:05 <zmatt> hopefully

16:10 <Siegurd> here is /dev/snd/ https://pastebin.com/8Nree7jd

16:10 <zmatt> hm

16:10 <zmatt> check kernel log I guess?

16:11 <Siegurd> I did not wire ad7771 to BBB yet. Might it be a reason?

16:11 <zmatt> no, that would prevent it from working but not from appearing

16:11 <Siegurd> dmesg?

16:13 <zmatt> you can check kernel log with dmesg (although that may require sudo) or journalctl -k

16:13 <Siegurd> dmesg: https://pastebin.com/T5b2LAD0

16:14 <Siegurd> error on 30.062035

16:15 <zmatt> wait is my generic tdm-audio dai driver not in rcn's kernels.... I really thought it was

16:16 <zmatt> ummmm

16:16 <zmatt> mmmmmhhh ok that's an issue

16:17 <zmatt> I vaguely recall there was some other codec driver that was sometimes abused as a generic dai driver but I don't remember which, and I'm pretty sure there were good reasons I made the tdm-audio driver

16:19 <zmatt> alsa has no built-in way to just configure an interface to hardcoded settings, it _requires_ a codec driver representing the device attached to the interface :/

16:19 <zmatt> obnoxiously

16:20 <zmatt> my tdm-audio driver is a such a codec driver but generic and DT-configurable

16:23 <zmatt> but I guess either I never sent it to rcn for inclusion or I did but he didn't include it... I write it a long time ago so I don't really remember

16:23 <zmatt> ugh

16:25 <Siegurd> anything I can help you?

16:26 <zmatt> well I can planning on just going to get some sleep tbh

16:37 <zmatt> but basically the options are 1. forward-port my tdm-audio driver (https://github.com/dutchanddutch/bb-kernel/tree/am33x-v4.14/patches/drivers/sound patches 0001 and 0002) 2. find another codec driver that can be abused for the purpose (I think the spdif_receiver codec (compatible = "linux,spdif-dir";) may work) 3. forget about alsa and use PRU to receive the data from McASP 4. forget about McASP ...

16:37 <zmatt> ...and use PRU to receive the data directly from the AD7771

16:38 <Siegurd> Option 1 is most promising

16:40 <zmatt> 2 is the least effort if it works

16:41 <zmatt> how hard 1 is will depend on how much stuff has changed in alsa since kernel 4.14

16:41 <Siegurd> its ok for me to downgrade system image to 4.14

16:42 <zmatt> options 3 or 4 are definitely tempting, with 4 probably being easier than 3 but I've wanted to implement 3 for my own purposes for quite a while

16:43 <zmatt> ok, you'd still need to build a custom kernel which would be a bit of an annoyance

16:43 <zmatt> if it forward-ports cleanly maybe rcn can be convinced to adopt it into his kernels

16:43 <zmatt> but regardless, right now I'm going for option 0: zZzZzZ

16:44 <Siegurd> Ok) have a good sleep! And thank you!

16:45 <Siegurd> I will solder things up to be ready for test's