The issue I raised earlier has not been resolved yet. To verify if it is influenced by MCLK, I am now using the ORIN NANO devkit board. The matching ORIN NX 16G module.
L4T version： 35.6.2
Due to the regulations of the chip manufacturer, the chip must receive the MCLK clock immediately upon power-on. Therefore, it is necessary to ensure that the AUD_MCLK clock can be continuously and stably output.
Regarding the pinmux mapping relationship, it is configured using the script /opt/nvidia/jetson-io/jetson-io.py.
The modifications related to the device tree are as follows:
/*
* Top level DTS file for CVM:P3767-0000 and CVB:P3768-0000.
*
* Copyright (c) 2021-2022, NVIDIA CORPORATION. All rights reserved.
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; version 2 of the License.
*
* This program is distributed in the hope that it will be useful, but WITHOUT
* ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
* FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
* more details.
*/
/dts-v1/;
#include "tegra234-p3767-0000-p3768-0000-a0.dts"
/ {
p-link {
version = "L4T 35.6.2";
bsp_version = "V1.0";
};
sound {
fixed-pll;
clocks = <&bpmp_clks TEGRA234_CLK_PLLA>,
<&bpmp_clks TEGRA234_CLK_PLLA_OUT0>,
<&bpmp_clks TEGRA234_CLK_AUD_MCLK>;
clock-names = "pll_a", "pll_a_out0", "extern1";
assigned-clocks = <&bpmp_clks TEGRA234_CLK_AUD_MCLK>;
assigned-clock-parents = <0>, <0>, <&bpmp_clks TEGRA234_CLK_PLLA_OUT0>;
assigned-clock-rates = <368640000>, <49152000>, <12288000>;
};
aconnect@2a41000 {
ahub {
status = "okay";
i2s@2901100 {
status = "okay";
ports {
port@1 {
endpoint {
dai-format = "i2s";
remote-endpoint = <&cjc8988_ep1>;
};
};
};
};
};
};
i2c@c250000 {
status = "okay";
cjc8988: cjc8988@1a {
status = "okay";
compatible = "cjc8988";
reg = <0x1a>;
clocks = <&bpmp_clks TEGRA234_CLK_AUD_MCLK>;
clock-name = "mclk";
#sound-dai-cells = <1>;
sound-name-prefix = "CVB-RT";
port {
cjc8988_ep1: endpoint {
link-name = "cjc8988-playback";
remote-endpoint = <&i2s2_dap_ep>;
mclk-fs = <256>;
};
};
};
};
};
hdr40_snd_link_i2s: &i2s2_to_codec {
format = "i2s";
link-name = "cjc8988-playback";
codec {
sound-dai = <&cjc8988 0>;
prefix = "CVB-RT";
};
};
hdr40_snd_i2s_dap_ep: &i2s2_dap_ep {
dai-format = "i2s";
remote-endpoint = <&cjc8988_ep1>;
};
However, at present, each time the startup process needs to go through the following steps in order to enable the AUD_MCLK to output the clock signal. And it is impossible to consistently output a clock frequency of 12.288 MHz.
*** Please note that this reply is generated by LLM automatically ***
The issue you’re experiencing with the Jetson Orin NX Thor I2S audio seems to be related to the MCLK (Master Clock) signal, which is required for the audio chip to function properly. You’ve tried manually loading the kernel module using the insmod command, but it didn’t result in any output in the printk statements within the probe section. This suggests that the module is not being loaded or initialized correctly.
To troubleshoot this issue, you’ve switched to using the Orin Nano devkit board with the matching Orin NX 16G module and L4T version 3562. You’ve also modified the pinmux mapping relationship using a script and made changes to the device tree.
However, you’re still experiencing issues with the AUDMCLK clock signal. Specifically, you need to ensure that the AUDMCLK clock can be continuously and stably output, but currently, you need to go through a series of steps to enable the AUDMCLK to output the clock signal, and it’s not consistently outputting a clock frequency of 12288 MHz.
To resolve this issue, I would recommend the following steps:
Verify the pinmux configuration: Double-check the pinmux configuration to ensure that the AUDMCLK pin is correctly configured as an output. You can use the pinmux command to verify the pinmux configuration.
Check the device tree: Review the device tree modifications you made to ensure that they are correct and consistent with the Orin NX module’s requirements.
Use the dtc command: Use the dtc command to compile the device tree source file and verify that it’s correctly configured.
Verify the clock configuration: Check the clock configuration to ensure that the AUDMCLK clock is correctly configured and enabled.
Use a logic analyzer or oscilloscope: Use a logic analyzer or oscilloscope to capture the waveform of the AUDMCLK clock signal and verify that it’s correctly outputting a clock frequency of 12288 MHz.
Check the kernel logs: Check the kernel logs to see if there are any error messages related to the AUDMCLK clock signal or the audio module.
Try a different kernel version: If possible, try using a different kernel version to see if the issue is specific to the current kernel version.
In comparison to the Jetson Orin Nano Developer Kit, the Orin NX module has a different pinmux configuration and device tree requirements. Therefore, it’s essential to verify that the pinmux configuration and device tree modifications are correct and consistent with the Orin NX module’s requirements.
Additionally, you may want to consider seeking support from the chip manufacturer or NVIDIA’s technical support team, as they may be able to provide more specific guidance on configuring the AUDMCLK clock signal and resolving the issue.
*** Please give the thumbs up if you get answers you like. Or provide feedback to help us improve the answer. ***
Could you share the full dmesg and device tree for further check?
Do you mean AUD_MCLK not output the clock signal during boot up but it can output 12.288MHz clock signal after you configure the rate manually?
If so, could you share the bpmp-dtb in your case?
According to the latest DTS modification, after power-on, the clock output is immediately available. However, the clock signal collected by the oscilloscope is constantly changing and unstable.
The log dump of clock summary of various audio clocks looks correct, The video attached shows aud_mclk clock probe having huge variation in the measurement which is not expected behavior.
Could you clarify whether the aud_mclk stabilizes after the boot at some point?. If so, what is the clock rate at that time?.
Also did you tried measuring the I2S2 clock signals Fs and BCLK during playback or capture with Tegra as Master. Does it shows correct rate on oscilloscope?. As the clock source is common for both AUD_MCLK and I2S2, expecting both should be working.
At present, there is no measurement of the waveforms during playback and capture. Because the audio chip we selected can only function properly when it has a main clock (MCLK).
So I need to first ensure that AUD_MCLK can continuously and normally output a 12.288 MHz clock.
AUD_MCLK and I2S signals shall be probed without any dependency on codec. I would suggest to remove the codec related changes and connections on 40 pin header of Orin NX board. Let us first make sure these signals are measured with right rate.
Below steps to be performed as a first step to debug the issue
Flash the image without any codec change
Enable the AUD_MCLK and I2S pinmux on 40 pin header using jetson io tool (steps captured in bsp doc)
Configure I2S as master and perform a basic ADMAIF → I2S playback with speaker-test tool
Measure the AUD_MCLK and I2S signals with oscilloscope in this condition
That is to say, at present, I don’t need to connect the codec chip to the 40-pin pins. I only need to use the SDKmanager for flashing. Then, through the jetson-io.py method, I can configure it as AUD_MCLK and I2S. After that, I can directly capture and display the clock waveforms for capture and playback.
Use SDKmanager to flash Orin NX,
Use jetson-io.py to config pins,
Configure I2S as master and perform a basic ADMAIF → I2S playback with speaker-test tool
When capturing and playing, the corresponding clock waveforms are captured.
I will arrange the test as soon as possible and provide feedback promptly.
It seems that the routing configuration is incorrect. Currently, this feature is not needed. We will restructure our driver to use the correct routing.
