Trouble getting ALSA layer work with PCM5102A codec - Card not listed in aplay soundcards

silver2row · January 7, 2023, 5:16pm

Hello,

I am reading the TRM
I am looking back at older .dts files
I am piecing together what takes place and when…

	/* P9_28 (ZCZ ball C12) Audio   */
	P9_28_default_pin: pinmux_P9_28_default_pin {
		pinctrl-single,pins = <0x19c  0x27>; };     /* Mode 7, Pull-Down, RxActive */
	P9_28_gpio_pin: pinmux_P9_28_gpio_pin {
		pinctrl-single,pins = <0x19c  0x2F>; };     /* Mode 7, RxActive */
	P9_28_gpio_pu_pin: pinmux_P9_28_gpio_pu_pin {
		pinctrl-single,pins = <0x19c  0x37>; };     /* Mode 7, Pull-Up, RxActive */
	P9_28_gpio_pd_pin: pinmux_P9_28_gpio_pd_pin {
		pinctrl-single,pins = <0x19c  0x27>; };     /* Mode 7, Pull-Down, RxActive */
	P9_28_pwm_pin: pinmux_P9_28_pwm_pin {
		pinctrl-single,pins = <0x19c  0x21>; };     /* Mode 1, Pull-Down, RxActive */
	P9_28_spi_pin: pinmux_P9_28_spi_pin {
		pinctrl-single,pins = <0x19c  0x23>; };     /* Mode 3, Pull-Down, RxActive */
	P9_28_spi_cs_pin: pinmux_P9_28_spi_cs_pin { pinctrl-single,pins = <
		AM33XX_IOPAD(0x099c, PIN_OUTPUT_PULLUP | INPUT_EN | MUX_MODE3) >; };	/* mcasp0_ahclkr.spi1_cs0 */
	P9_28_pwm2_pin: pinmux_P9_28_pwm2_pin {
		pinctrl-single,pins = <0x19c  0x24>; };     /* Mode 4, Pull-Down, RxActive */
	P9_28_pruout_pin: pinmux_P9_28_pruout_pin {
		pinctrl-single,pins = <0x19c  0x25>; };     /* Mode 5, Pull-Down, RxActive */
	P9_28_pruin_pin: pinmux_P9_28_pruin_pin {
		pinctrl-single,pins = <0x19c  0x26>; };     /* Mode 6, Pull-Down, RxActive */
	P9_28_audio_pin: pinmux_P9_28_audio_pin {
		pinctrl-single,pins = <0x19c  (PIN_OUTPUT_PULLDOWN | MUX_MODE2)>; };	/* mcasp0_ahclkr.mcasp0_axr2 */

	/* P9_29 (ZCZ ball B13) Audio   */
	P9_29_default_pin: pinmux_P9_29_default_pin {
		pinctrl-single,pins = <0x194  0x27>; };     /* Mode 7, Pull-Down, RxActive */
	P9_29_gpio_pin: pinmux_P9_29_gpio_pin {
		pinctrl-single,pins = <0x194  0x2F>; };     /* Mode 7, RxActive */
	P9_29_gpio_pu_pin: pinmux_P9_29_gpio_pu_pin {
		pinctrl-single,pins = <0x194  0x37>; };     /* Mode 7, Pull-Up, RxActive */
	P9_29_gpio_pd_pin: pinmux_P9_29_gpio_pd_pin {
		pinctrl-single,pins = <0x194  0x27>; };     /* Mode 7, Pull-Down, RxActive */
	P9_29_pwm_pin: pinmux_P9_29_pwm_pin {
		pinctrl-single,pins = <0x194  0x21>; };     /* Mode 1, Pull-Down, RxActive */
	P9_29_spi_pin: pinmux_P9_29_spi_pin {
		pinctrl-single,pins = <0x194  0x23>; };     /* Mode 3, Pull-Down, RxActive */
	P9_29_pruout_pin: pinmux_P9_29_pruout_pin {
		pinctrl-single,pins = <0x194  0x25>; };     /* Mode 5, Pull-Down, RxActive */
	P9_29_pruin_pin: pinmux_P9_29_pruin_pin {
		pinctrl-single,pins = <0x194  0x26>; };     /* Mode 6, Pull-Down, RxActive */
	P9_29_audio_pin: pinmux_P9_29_audio_pin {
		pinctrl-single,pins = <0x194  (PIN_OUTPUT_PULLUP | MUX_MODE0)>; };	/* mcasp0_fsx.mcasp0_fsx */

As you can see from above 0x23 is an SPI pin. The 0x19c && 0x194 seem to be the McASP0 pins I have found so far. This may be helpful. I am not quite sure yet.

The reason I think so far that this may be helpful is that maybe the .bin file for the W3 wake controller is not on these pins?

Seth

P.S. I think this is a step closer. That bit of the .dts file is from TI.com in '12.

silver2row · January 7, 2023, 6:59pm

Okay. So, the clock freq. is bad. GPIO is not compatible. Do not get me wrong. GPIO works but not for the pins we need to alter to make the source run.

Still on it!

Seth

P.S. @vitorengcruz , any feedback is unconditionally good! Sarcasm, grunts, anything. I am not running for congress…ever. Dang it. Updates again…I was reading in McSPI and not McASP in '19. I need an update. My TRM is old and I read the incorrect section(s). Many, many, many sections. Blah. I would give up but no one else is jumping in. So, off to do it!

22.3.3.2.3 Frame Format is where I am located now. I am breaking soon. BBL! I am back. Okay, so.

I think, if you ever find time, this may provide some background if anything: Embedded processor voice-recognition systems | TI.com Training Series .

I will keep on it, though. I am at it again. Like previously explained:

EDMA is needed
The .dtsi will need these nodes
TDM mode is needed to handle i2s mode on the am335x
I will research EDMA .dtsi node mfg. This way, I can place it in its respective place
McASP1, okay. I will learn how to handle the &mcasp1 node in the .dtsi file and not the &mcasp0 node

Right now, as things get more complicated, EDMA may/may not be needed. I need to read the sections of the EDMA controller. For now, I think that McASP0 is w3 (just the wake-up controller).

And PRU has a hand in it. I know nothing about this idea. I saw that two pins muxed as PRU are needed as the interrupts and W3 is taken. I think going to use the second controller, McASP1 is available but I see no work done on it so far. This will take time. Mo’ searching and betta’ research!

vitorengcruz · January 9, 2023, 10:15pm

Hi @silver2row ,

In the mean time I try some other things, reverse engineering HDMI configs from DTSI and OVERLAY, using it to config McASP1 instead of McASP0. As far as I understood, something is bad in McASP1, as I modify the McASP0 to McAPS1 in both dtsi and overay files, with the respect GPIO modifications too… Nothing again from DMESG and ARECORD…

The project I’m working on is approaching Proof of Concept Phase, so I’ll move to USB microphone by now… I’m curious to know what went wrong in this I2S setup, as the articles describe simple step-by-step and claim tit works but I’m not get the same results. I’ll back to work on this topic as soon as possible.

Best Regards,

Vítor Cruz.

silver2row · January 9, 2023, 10:56pm

Hello,

A lot changes
a. The way the kernel is set up
b. The BBB and its software/firmware
c. DTS and ways to incorporate the files together has changed too
I hope you can get it working
a. Changing that HDMI .dtsi file may prove valuable
b. You may need to alter some steps I have taken so far in the above .dtsi
c. Too many changes and not enough people dedicated to this instance (I guess)
Like I was saying w/ the kernel and its changes in time
a. It is hard to find out what has changed unless one goes back kernel by kernel to see the merges
b. Without the proper workers doing so, time turns into an issue (as I am sure you are aware)
c. Checking on what was going on during the kernels 4.1.x+ may help

I saw that this idea was made during a specific kernel. The PCM5102a module may already be in the kernel now but I am not sure. It may have been easier then compared to now. I say that last sentence b/c Cape_Universal may have not been incorporated into the kernels for beagleboard.org boards and the am335x support.

Seth

P.S. If you want me to keep trying, I will keep on w/ it. Either using McASP1 or McASP0 may not be an issue but it may. Until I get some hardware to test, I am barking in the wind. I will try to find some supported PCM5102a chips to test. Oh and if you are planning on using USB, okay. No issue. I would hate to see that take place, i.e. as i2s is supported but making it work currently must have some work dedicated to it.

Currently, it is new to me. I have not used i2s. I tried many years ago. Many years ago I tried but was unsuccessful. It had to do w/ Debian and not using Ubuntu w/ the configurations which did not make sense to me. Now, I think the issue was, back then, w/ the glibc version and cross-compilation.

Anyway…let me know if you think I should keep trying or not. This will give me some heads up on what to expect from building now and in the future for the PCM5102a module.

vitorengcruz · January 9, 2023, 11:34pm

@silver2row , unfortunately my time is running out to do it by I2S bus… I may be back to it as soon the project PoC is done. Thank you about all the effort to make it work. You can also buy a I2S microphone if you are interested to make it work with BBB too. This is the model compatible with mine:

Best Regards,

Vítor Cruz.

vitorengcruz · January 18, 2023, 11:24pm

Hi @silver2row, some updates of the last week…

BBB was able to detect a USB microphone (card 1, hw 1,0) as expected and now I can record audio from ALSA layer, just what I needed to make the PoC work. The downside is that the USB microphone is too big to fit into the final device’s Case, as it will be portable in the near future, we should have TWO microphones in the final version of the PoC, the USB microphone has poor quality of signal and so on…

Next week I’ll be back to work in this topic.

Any progress?

Best Regards,

Vítor Cruz.

silver2row · January 18, 2023, 11:31pm

@vitorengcruz ,

Not from me. I am sorry. I thought you got caught up in a time issue w/ the item in question needing to be done and finalized. I was not aware of you still trying. I will try again.

Seth

vitorengcruz · January 18, 2023, 11:46pm

@silver2row sorry, maybe I was not crystal clear. We are developing this project with agile, so I have to address this microphone impediment to other team mates, such as testers of the web application through BBB web browser, before I continue with I2S implementation.

I was expecting some trouble with USB and ALSA too, thinking it will have massive work to do in order to work it out. But no, it really put the “plug and play” statement to justice and work right away!

Now back to I2S mess…

P.S. So, with the USB microphone working, I’m sure the ALSA is working fine, the problem may be between the MCASP, PINMAP and ALSA configuration… I’ll try first disable all other peripherals shared with McASP pins, maybe, even if not in use, an SPI or other interface is in conflict and make the MCASP config failure to register the interface.

silver2row · January 19, 2023, 12:35am

https://docs.beagleboard.org/latest/books/beaglebone-cookbook/02sensors/sensors.html#i2c-tools

@vitorengcruz ,

The above links show how to manage i2c devices on the beagleboard.org boards.

Also…in Linux.

Further down that page, smbus is used. I am not sure if you are trying to use agile w/ smbus or not but this may be a way.

Seth

P.S. If you are using Linux and i2c, I say use smbus. From what I have seen, i2c in plain source gets complicated. Someone told me this idea and I viewed some simple i2c source. It looked complicated (at least to me). Oh and about McASP1, maybe try McASP0? I see it is fully functional already.

I know this may sound odd. First, tell me how I can help. Second, I can then tell you if I can search out ideas and research in my spare time to assist. i2c-2 is available on the BBB.

i2c-0 is not available due to Cape/EEPROM usage.

The first I2C bus is utilized for reading EEPROMS on cape add-on boards and can't be used for other digital I/O operations without interfering with that function, but you can still use it to add other I2C devices at available addresses.

The second I2C bus is available for you to configure and use.

That was taken from BeagleBoard.org - bone101

silver2row · January 20, 2023, 1:05am

Heyo @vitorengcruz ,

Seth here. I am going to build another kernel. Do you think that the BBB is slave or master for the /dev/i2c-* ?

Seth

vitorengcruz · January 20, 2023, 9:51pm

Hi @silver2row ,

Sorry about the delay. My microphone doesn’t use the I2C bus, just the HDMI chip does. In my application just have the I2S bus is enough as the microphone doesn’t need initial setup as HDMI TDA chip need.

I’m sorry @silver2row , it’s my first project using the BB boards…so I’m not sure what I need to do in order to make this ALSA layer connect with McASP configured as I2S Master… I thought following the tutorials is just enough, but not… This is my main obstacle right now.

What do you think about my step by step? Did you realized I missing some steps or misconfigured the PCM5102a device?

Could you try to remap MCASP0 pins to the pin header of the BBB? From there, I believe you can generate some signals with a micro controller, such as an arduino, as a mock device mimicking the I2S signals, without the need to by an microphone or other specific device. I can help development some code for this Arduino. What do you think?

Best regards,

Vítor Cruz.

silver2row · January 20, 2023, 11:40pm

Hello,

I have some TI ARM boards laying around. They use the M4 on them. I can set up something and the main goal is to get i2c-2 working on the BBB as i2c-2 (Master). This has been done. The beagleboard.org people have many overlays already set up to handle such a feat.

For instance, /dev/i2c-2 now is in a /dev/bone/i2c/2/ set of file(s). Are you using smbus or do you have to do everything w/ the kernel yourself?

I was reading about how many rules and ideas are involved in the Agile philosophy.

I stopped reading it. It was enough to be its own scripture. For now, I know nothing about the Agile process nor will I know in the near future.

…

I know you are tired of reading dead-end hyperlinks. I am still trying to understand how I can be of any assistance. Right now, BeagleBoard-DeviceTrees/BONE-I2C2.dts at v4.19.x-ti-overlays · beagleboard/BeagleBoard-DeviceTrees · GitHub , that link w/ kernel 4.19.x works on the BBB boards…

So, if you use smbus in python3 or another i2c-tools type of script from another language, I think this DTS file will be beneficial.

It basically calls to more hyperlinked files that are freely available to view.

oh!

What kernel are you using or what kernel do you think you need to use?
What u-boot version are you using?

From what I understand, u-boot needs to be newer than the kernel. This may have changed. I also see…

No UART0 boot output on your part and I can understand why for now
I understand that this cannot be given simply b/c of Agile or your teammates working to make this work

Seth

P.S. I do not need scripts. I found many resources from the beagleboard.org people so far that seem to associate w/ i2c and hwmon (kernel) and smbus (python3/userland).

Right now and yes, I am this dull, I do not quite understand the connections being made to handle such a task in computing. So, w/out me understanding, I am at a loss.

a. Do you know about the /hwmon/ files?
b. Or…do you need to use C/C++ to handle the /dev/bone/i2c/2/ files?

silver2row · January 20, 2023, 11:49pm

// McASP
bone_mcasp_0: &mcasp0 {
    serial-dir = <  /* 0: INACTIVE, 1: TX, 2: RX */
		2 0 1 0
		0 0 0 0
		0 0 0 0
		0 0 0 0
	>;
};

Okay…so. I have no Earthly idea what this exactly means right now. I see and I still do not know.

USB is okay and one can hack the HDMI to make things (work) almost okay.

github.com

beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti-overlays/src/arm/bbb-bone-buses.dtsi

// SPDX-License-Identifier: GPL-2.0-only
/*
 * Copyright (C) 2020 Deepak Khatri <deepaklorkhatri7@gmail.com>
 * See Cape Interface Spec page for more info on Bone Buses
 * https://elinux.org/Beagleboard:BeagleBone_cape_interface_spec
 */

#include <dt-bindings/board/am335x-bone-pins.h>
#include <dt-bindings/gpio/gpio.h>

/********/
/* LEDs */
/********/
&{/} {
	leds {
		pinctrl-names = "default";
		compatible = "gpio-leds";

		led_P8_03 {
			gpios = <gpio_P8_03 GPIO_ACTIVE_HIGH>;

This file has been truncated. show original

bbb-bone-buses.dtsi is the file called in the previously mentioned hyperlink stuff I brought up.

Anyway, in that file - the bbb-bone-buses.dtsi file is where I found this info. - that call to McASP0 is mentioned.

If you need to map or remap your McASP pins to handle McASP 0 or 1, the array or vector may need to be altered but that is for kernel 4.19.x from beagleboard.org.

Seth

P.S. Now, there are many files in the kernel and u-boot that are associated w/ the am335x and the BBB in question. Dang it…also.


// Bone sound
&ocp {
        clk_mcasp0_fixed: clk_mcasp0_fixed {
                #clock-cells = <0>;
                compatible = "fixed-clock";
                clock-frequeny = <24576000>;
        };
        clk_mcasp0: clk_mcasp0 {
                #clock-cells = <0>;
                compatible = "gpio-gate-clock";
                clocks = <&clk_mcasp0_fixed>;
                enable-gpios = <&gpio1 27 GPIO_ACTIVE_HIGH>;
        };
	bone_sound: bone_sound {
		bb-device = <0>; //BBB/BBG
	};
};

That bit of text was found in bbb-bone-buses.dtsi but you will need to hopefully have the kernel that handles am335x-bone-pins.h. Now, where is am335x-bone-pins.h? No clue. It states where it is located.

Right…but. /dt-bindings/board/ may be deceiving or not. I am not going to check right now. I will check probably when I get deeper in looking up and researching source.

vitorengcruz · January 21, 2023, 12:59am

This is all the aux IO direction configuration from McASP peripherals… Besides the Bit clock, and frame clock, the common signals from McASP, it is possible to use up to 16 aux channels as inputs or outputs for one McASP. For instance, I can input two I2S microphones and two I2S amplifiers sharing the same bit clock and frame clock from one single McASP. This enable one single McASP capture and playback capabilities.

This code is used to tell McASP wich channels are configured as input (RX), output (TX) and disabled (INACTIVE).

So, McASP aux0 is configured as data stream input, aux1, disabled, aux2 as data stream output, aux3 through aux15 are disabled.

Hope I was clear, please send me a feedback if something is not right with my explanation.

silver2row · January 21, 2023, 1:51am

No…I have not built the set up from your explanation.

And…I do not think things are misconfigured so far.

and Oh! I forget. You guys are building the kernel instead of using the already made kernels that already work. Okay.

So, maybe we are missing something. Are you allowed to provide some output of the boot? Is that okay?

I can then look up what you have available, what is missing, and what I think needs to happen.

So far, the DTS probably needs work.

So much so, I will need to take time out.

Look here:

#define AM335X_PIN_MCASP0_FSX			0x994
#define AM335X_PIN_MCASP0_AXR0			0x998
#define AM335X_PIN_MCASP0_AHCLKR		0x99c
#define AM335X_PIN_MCASP0_ACLKR			0x9a0
#define AM335X_PIN_MCASP0_FSR			0x9a4
#define AM335X_PIN_MCASP0_AXR1			0x9a8
#define AM335X_PIN_MCASP0_AHCLKX		0x9ac
#define AM335X_PIN_XDMA_EVENT_INTR0		0x9b0
#define AM335X_PIN_XDMA_EVENT_INTR1		0x9b4

These, all for XDMA_EVENT_INTR 0 or 1, are past tense b/c you need McASP1. Okay…

#define AM3_L3S_MCASP1_CLKCTRL AM3_L3S_CLKCTRL_INDEX(0x68)

Is the McASP1 the connector or is it the medium in b/t the connector and the am335x?

B/c…if McASP1 is the L3 interconnect, then reverting everything to another time and space would be a lot of work for me. I think you want to use kernel 5.10.x.

Needs DTS work
Needs proper kernel and u-boot
And then…the correct build needs to happen (toolchain, system, Kbuild options)

I need to revert back to the TRM.

Seth

silver2row · January 21, 2023, 2:30am

-int __init am33xx_dt_clk_init(void)
-{
-	struct clk *clk1, *clk2;
-
-	ti_dt_clocks_register(am33xx_clks);
-
-	omap2_clk_disable_autoidle_all();
-
-	ti_clk_add_aliases();
-
-	omap2_clk_enable_init_clocks(enable_init_clks,
-				     ARRAY_SIZE(enable_init_clks));
-
-	/* TRM ERRATA: Timer 3 & 6 default parent (TCLKIN) may not be always
-	 *    physically present, in such a case HWMOD enabling of
-	 *    clock would be failure with default parent. And timer
-	 *    probe thinks clock is already enabled, this leads to
-	 *    crash upon accessing timer 3 & 6 registers in probe.
-	 *    Fix by setting parent of both these timers to master
-	 *    oscillator clock.
-	 */
-
-	clk1 = clk_get_sys(NULL, "sys_clkin_ck");
-	clk2 = clk_get_sys(NULL, "timer3_fck");
-	clk_set_parent(clk2, clk1);
-
-	clk2 = clk_get_sys(NULL, "timer6_fck");
-	clk_set_parent(clk2, clk1);
-	/*
-	 * The On-Chip 32K RC Osc clock is not an accurate clock-source as per
-	 * the design/spec, so as a result, for example, timer which supposed
-	 * to get expired @60Sec, but will expire somewhere ~@40Sec, which is
-	 * not expected by any use-case, so change WDT1 clock source to PRCM
-	 * 32KHz clock.
-	 */
-	clk1 = clk_get_sys(NULL, "wdt1_fck");
-	clk2 = clk_get_sys(NULL, "clkdiv32k_ick");
-	clk_set_parent(clk1, clk2);
-
-	return 0;

-static const struct omap_clkctrl_bit_data dra7_mcasp2_bit_data[] __initconst = {
-	{ 22, TI_CLK_MUX, dra7_mcasp1_aux_gfclk_mux_parents, NULL },
-	{ 24, TI_CLK_MUX, dra7_mcasp1_ahclkx_mux_parents, NULL },
-	{ 28, TI_CLK_MUX, dra7_mcasp1_ahclkx_mux_parents, NULL },
-	{ 0 },
-};
-
-static const struct omap_clkctrl_bit_data dra7_mcasp3_bit_data[] __initconst = {
-	{ 22, TI_CLK_MUX, dra7_mcasp1_aux_gfclk_mux_parents, NULL },
-	{ 24, TI_CLK_MUX, dra7_mcasp1_ahclkx_mux_parents, NULL },
-	{ 0 },
-};

-	DT_CLK(NULL, "mcasp1_ahclkr_mux", "ipu_cm:0010:28"),
-	DT_CLK(NULL, "mcasp1_ahclkx_mux", "ipu_cm:0010:24")

Now, this is as far as I can get right now. It seems that this effort may take longer than expected.

While building, one would have to jump in the TRM for clks either for omapN or draN. I am really learning now since I cannot decipher kernel source w/out reading more kernel docs. and code.

Seth

P.S. Anyway, if that can assist you, good. If not, maybe build for omap5 or draN.

I am not good w/ clocks right now. I will keep on it, i.e. as this just keeps getting more interesting. I got the source from lore.

silver2row · January 21, 2023, 3:49am

Hello @vitorengcruz ,

Do you think you could set up the McASP1 in DTS since the changes took place? I exclaim changes b/c everything I am readin’ means something changed w/ DTS which entails things changing in the way the am335x talks to the rest of the BBB.

Outside of that idea, my almost last intuition here would be that calling the right address and offset for the line, #define AM3_L3S_MCASP1_CLKCTRL AM3_L3S_CLKCTRL_INDEX(0x68), would be the route.

If you need WiFi, use it but I think Ethernet for now is as good w/out WiFi.

Seth

P.S. i2s seems like it is done in some kernels, i.e. 4.19.x.

Not in 5.10.x b/c McASP0 is marked out from here: BeagleBoard-DeviceTrees/bbb-bone-buses.dtsi at v5.10.x-ti · beagleboard/BeagleBoard-DeviceTrees · GitHub .

But…I see here, BeagleBoard-DeviceTrees/am335x-bone-common-univ.dtsi at v5.10.x-ti · beagleboard/BeagleBoard-DeviceTrees · GitHub , something completely odd. P9.92 seems out of place.

And…I guess we just need to find the right drift. The TRM states the address of each of the McASP1, the rules that go along w/ them, and the offsets needing to take place w/in them all. I think I am out of ideas and need to put in some work. I will do it.

Ugh. So, p. 4179 of the TRM, model q, states this idea: 29 pi_x_dma_event_intr1 External pin (XDMA_EVENT_INTR1) . Now, I have no clue if this pin is available. But…to use it for McASP1, there are many rules. These rules are vast. Then, one has to understand the other benefits of the am335x. The model q TRM shows how to slowly configure things correctly w/in the entire system.

Anyway, p. 4183 shows some interesting info. about this entity of making it all work.

1. I will get better organized soon.
2. Until then, sorry for the articulations and ideas...
3. Anyway...the DMA engine is mentioned in the McASP understandings.

This is what leads me to believe either it is pinned out or not. If the pin exists, we have to find it, utilize it, and then you can move on w/ the build. Until then, not tonight, I will keep trying.

update

I was/am wrong. If you only just need i2c-2, you can use the /dev/bone/i2c/2/a pins, which are P9.21/22.

Or…you can use /dev/i2c-2/ in the /dev/ dir. plainly (I think). Since you are using USB now and only need to configure i2c-2 or another i2c-N device, I say use /dev/ or /dev/bone/.

vitorengcruz · January 22, 2023, 7:55pm

Hi @silver2row ,

I’m setting an action plan to get McASP1 as I2S bus and work with ALSA layer:

1 - With the latest Debian with LXQT desktop image (link here), WITHOUT any modifications, check if BBB can play a simple wave audio through McASP0 I2S configured by HDMI overlay.
PS: Some useful info:

Debian 9.9
Kernel 4.14.108-ti-r113.

Results:

I successfully play an wave file and got sound output from my HDMI desktop 23" Monitor’s P2 plug (headphones)

Conclusion:

The HDMI McASP0 overlay from latest Debian Image was configured correctly as I2S bus with ALSA support.
The TDA998x driver and HDMI dts source files are able to setup McASP0 as I2S and remap its’ data stream from ALSA layer.

2 - Get the 4.14 kernel files form Beagleboard Git repository and build it WITHOUT modifications. Check if the McASP0 still works as expected.
PS: Some useful info:

Debian 9.9
4.14.256-bone53

Results:

I successfully play an wave file and got sound output from my HDMI desktop 23" Monitor’s P2 plug (headphones)

Conclusion:

The HDMI audio output functionality of the kernel build works, so I assuming all that I need to make McASP0 works as a sound card is here.

2.1 - Update Kernel to 5.10 last release.

Results: TO DO

3 - Initialize McASP1 I2S with the TDA998x and HDMI dts sources. Check if aplay list it as a new sound card.

Results: TO DO

4 - Configure McASP1 I2S with one RX channel. Check if arecord list it as a new capture sound card.

Results: TO DO

5 - Configure McASP1 RX as Master. Check if the BBB output bit clock and frame clock from IO header.

Results: TO DO

Did you think it make any sense? In the mean time, I’ll update this post as I get progress with I2S.

silver2row · January 22, 2023, 8:50pm

Okay,

@vitorengcruz , the pins are available. I found them finally but the TRM shows little reference to them.

The datasheet on the other hand shows them. It may be a simple task. I will get back to you.

Seth

P.S. If you have the ZCE model PCM, the McASP1_aclkx is not available. You will need the ZCZ model.

Okay. I have an i2c device to use. I can alter the source to handle whatever really. Programming is not 100% great on my end for now. So, any snippets or commands are welcomed.

Also…

Please let me know which version you have, i.e. ZCE or ZCZ. This way I can take some better notes and display them w/out error.

silver2row · January 22, 2023, 9:54pm

@vitorengcruz ,

For the ZCZ model

Max. 6mA for any pin for the McASP1

Ball #B12
McASP0_ACLKR
mcasp1_aclkx
mode 3 I/O

and…

Ball #A14
McASP0_AHCLKX
mcasp1_axr1
Mode 3 I/O

and

Ball #C13
McASP0_FSR
mcasp1_fsx
Mode 3 I/O

and…

Ball #D13
McASP0_AXR1
mcasp1_axr0
Mode 3 I/O

and…

For ZCE and ZCZ

things are a bit more complicated b/c there are some MII pins that are on Mode 4 for each style of processor.

Seth

P.S. Instead of having to handle research, there is something to view from the datasheet. Also, this is taken directly from the TRM for the am335x…

DIR 
Digital audio interface receive. The McASP does not natively support receiving in the S/PDIF format.
The McASP supports I2S format output by an external DIR device.

So, I think if you are processing w/in the McASP1 device(s), an alternate “mapping” to another device may be needed, i.e. PRU?

I saw in the TRM that PRU has its place in the McASP references. On p. 4655 it shows it and they are being used for interrupts.