Request: Simple procedure for enabling I2S support on Jetson Nano

Hi Nvidia,

I was wondering if there will be a concise and officially sanctioned way of enabling I2S on the 40 pin connector of the developer kit.

In an ideal world an option on the SDK Manager to enable SFIO before flashing the device would be great or alternatively a sticky forum topic with simple instructions would also suffice.

Reading the various forum posts, it is clear to me that I2S on the Jetson Nano is definitely functional due to the success that various people have had however the instructions are scattered across many posts and it is not clear if they apply to the latest Jetpack release.

Consider the following,

If I wanted to enable I2S from “fundamentals” I would have to follow these instructions
https://developer.download.nvidia.com/assets/embedded/secure/jetson/Nano/docs/customizing_the_jetson_nano_40-pin_expansion_header_v1.2.pdf?q8tBvg-iwz3ohvjvj7VvYg5Nsbe2vQliqS4W4BLKVKHO9fWFrKBYo0Cbgkb__4D4D2075_PmHMKr5iTd18VnGm1IIAhC5HRjVaEWlXQKbHyADHc1IXQfO-_1UdrpXCzueTk_6-EeOyEyLzLe-2XnE7MJAeLMQslGaD9XaYGSRbxS2uDTUuKdjT3nitzAZwxzhL25f8R5O2iF7pniByQsaygpHw

However this forum post indicates that there are issues with the procedure above
https://devtalk.nvidia.com/default/topic/1063105/jetson-nano/can-t-get-jetson-nano-to-boot-with-custom-pinmux-configuration-per-nvidia-instructions/post/5388777/#5388777

Alternatively I could attempt to configure the registers directly (albeit it is only suitable as a workaround) however I would require a serial console connected through one of the headers
https://devtalk.nvidia.com/default/topic/1049674/jetson-nano/audio-i2s-on-40-pin-connector/post/5338105/#5338105

@jax-mx released a customised DTB with instructions on how to flash the DTB
https://devtalk.nvidia.com/default/topic/1049674/jetson-nano/audio-i2s-on-40-pin-connector/post/5338647/#5338647
This worked for a few people however it no longer works on the latest Jetpack
https://devtalk.nvidia.com/default/topic/1049674/jetson-nano/audio-i2s-on-40-pin-connector/post/5373374/#5373374

I don’t wish to appear like I am ungrateful of the time and effort spent by people such as @jax-mx who does not work for Nvidia or the Nvidia Moderators such as @jonathanh and others who have been diligent in helping out the community on the forums. Quite the contrary. I simply would like to express some frustration on my part in my thus far fruitless attempts to achieve what I expected to be a relatively simple procedure to test the I2S interface on the developer kit.

As a Software Engineer, but not a specialist in hardware or low-level programming, I’d like to ask if Nvidia would be able to produce some kind of easy-to-follow recipe for people such as myself and others to enable SFIO functionality in order to use the I2S interface on the 40 pin connector.

Hello!

Thanks for the feedback and completely understand your frustration. This has not been a good user experience at all for what should be a straight forward thing to do.

Firstly, I recommend the following approach of re-building the bootloader if this is something that you have the ability to do. Currently, this is probably the easiest way to achieve this. Let me know if this is something that you can do or not?

Longer term we have been working to simplify the reconfiguration of the pins on the 40-pin header for all Jetson platforms. Once we do have a proper solution that is available for users, I will ensure that this is communicated to the various threads that have been struggling with this. I am sorry I cannot provide an exact date/schedule for this at the moment and so thanks for your patience.

Regards,
Jon

Hi @jonathanh,

Thank you for the reply. I am willing to try re-building the bootloader as the link suggests however I it would be great if I can confirm the steps that I would need to go through to do this.

  1. Using the instructions from the link [1], I need to download the kernel sources.
  2. Next I will need to apply the patch from the link that you provided [2].
  3. Compile the patched kernel based on the instructions from the link [1].
  4. Flash the updated kernel to the Jetson Nano using the command. sudo ./flash.sh -k LNX jetson-nano-qspi-sd mmcblk0p1

Does that sound about right? If so, I’ll certainly give it a go when I am back in the office on Monday.

[1] https://developer.ridgerun.com/wiki/index.php?title=Jetson_Nano/Development/Building_the_Kernel_from_Source
[2] https://devtalk.nvidia.com/default/topic/1061108/jetson-nano/i2s-audio-output-not-working/post/5374074/#5374074

Hello!

Yes, however, in step 3 you just need to re-compile the bootloader and in step 4 you are updating the bootloader. So actually, I would …

  1. Download, patch and build u-boot [0]
  2. Prepare for flashing u-boot [1]
  3. Place jetson into recovery mode by executing 'sudo reboot --force forced-recovery' from a terminal on the Nano.
  4. Flash u-boot [2]

Regards,
Jon

[0] Welcome — Jetson Linux<br/>Developer Guide 34.1 documentation
[1] Welcome — Jetson Linux<br/>Developer Guide 34.1 documentation
[2] Welcome — Jetson Linux<br/>Developer Guide 34.1 documentation

Thanks for the clarified instructions Jon.

I will definitely give this a shot on Monday.

Hi Jon,

You are a rock star! I followed the instructions that you provided on Friday and I think I have working I2S support. I can’t actually hear any sound because I don’t have the appropriate hardware yet however I have run a few test commands and it is looking good.

Pins look like they are not configured for GPIO so I assume they are configured for SFIO.

$ sudo grep "Name:\|J:\|BB:" /sys/kernel/debug/tegra_gpio
Name:Bank:Port CNF OE OUT IN INT_STA INT_ENB INT_LVL
 J: 2:1 00 00 00 00 00 00 000000
BB: 6:3 00 00 00 00 00 00 000000

Speaker test seems to work instead of producing an error.

$ speaker-test -c2 -twav -D plughw:CARD=tegrasndt210ref,DEV=0

speaker-test 1.1.3

Playback device is plughw:CARD=tegrasndt210ref,DEV=0
Stream parameters are 48000Hz, S16_LE, 2 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 32 to 8192
Period size range from 32 to 4096
Using max buffer size 8192
Periods = 4
was set period_size = 2048
was set buffer_size = 8192
 0 - Front Left
 1 - Front Right
Time per period = 2.862030
 0 - Front Left
 1 - Front Right
Time per period = 3.027461
 0 - Front Left
 1 - Front Right

For anyone reading this post in the future, here are the steps that I executed to generate the patched bootloader.

########################
# Compiling Boot Loader
########################
# This fix is required to put the GPIO into SFIO mode and therefore enable I2S on the 40 pin connector. The changes will persist between reboots.

export WORKSPACE=${HOME}/Workspace
export BOOTLOADER_WORKSPACE=${WORKSPACE}/bootloader
# Path to the patch file provided by @sharadg from Nvidia
# https://devtalk.nvidia.com/default/topic/1061108/jetson-nano/i2s-audio-output-not-working/post/5374074/#5374074
export PATCH_FILE=${BOOTLOADER_WORKSPACE}/i2s.patch

export L4T_ROOT=${HOME}/nvidia/nvidia_sdk/JetPack_4.2.2_Linux_GA_P3448

# Branch and Tag names for U-Boot
# The following values are for Jetpack 4.2.2 running L4T 32.2.1 (Release 32, Revision 2.1)
export UBOOT_BRANCH_NAME="l4t/l4t-r32.1-v2016.07"
export UBOOT_TAG_NAME=tegra-l4t-r32.2.1

# Placeholder values for the Jetson Nano.
# Note that this is different to the values specified in https://docs.nvidia.com/jetson/l4t/Tegra%20Linux%20Driver%20Package%20Development%20Guide/uboot_guide.html#wwpID0E0UK0HA
export PLATFORM=t210ref
export BOARD_AND_REV=p3450-porg

pushd .

# Setting up the L4T Toolchain
# The device tree compiler is not installed by default in Ubuntu 18.04
sudo apt install device-tree-compiler
# Download and extract the L4T Toolchain
# https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%20Linux%20Driver%20Package%20Development%20Guide/xavier_toolchain.html
export L4T_GCC_HOME=${BOOTLOADER_WORKSPACE}/l4t-gcc
mkdir ${L4T_GCC_HOME}
cd ${L4T_GCC_HOME}
wget http://releases.linaro.org/components/toolchain/binaries/7.3-2018.05/aarch64-linux-gnu/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz
tar xf gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu.tar.xz
# Setting the CROSS_COMPILE Environment Variable for the AArch64 toolchain
export CROSS_COMPILE=${L4T_GCC_HOME}/gcc-linaro-7.3.1-2018.05-x86_64_aarch64-linux-gnu/bin/aarch64-linux-gnu-

# Downloading and Building U-Boot
cd ${BOOTLOADER_WORKSPACE}
git clone -n git://nv-tegra.nvidia.com/3rdparty/u-boot.git
cd u-boot/
git checkout -b ${UBOOT_BRANCH_NAME} ${UBOOT_TAG_NAME}

# Apply the patch file
patch -p1 < ${PATCH_FILE}

# Building U-Boot
# Note that there will be a series of warning messages at the end of the 'make' command.
make distclean
make ${BOARD_AND_REV}_defconfig
make

# The following section is intentionally commented out so that no potentially damaging changes are applied.
# If you are happy with everything up to this point uncomment the line and it will apply the new bootloader to the Jetson Nano.
#
# You may also wish to back up your current U-Boot binary because it will be overwritten when updating the L4T tree.
# "cp ${L4T_ROOT}/Linux_for_Tegra/bootloader/${PLATFORM}/${BOARD_AND_REV} ${HOME}/Desktop"
#
# Before flashing the Jetson, put it into recovery mode by running this command from a Terminal on the Nano.
# "sudo reboot --force forced-recovery"
#
# Update the U-Boot binary in the L4T tree
# cp u-boot{,.bin,.dtb,-dtb.bin} ${L4T_ROOT}/Linux_for_Tegra/bootloader/${PLATFORM}/${BOARD_AND_REV}
#
# Once the nano has rebooted into recovery mode, flash the new bootloader.
# cd ${L4T_ROOT}/Linux_for_Tegra
# sudo ./flash.sh -k LNX jetson-nano-qspi-sd mmcblk0p1

popd

Big thanks to Jon and Sharad for the instructions and patch to make this possible.

Hi Jon,

I finally managed to get some hardware to test the I2S interface but unfortunately I can’t hear anything. I was hoping that you may be able to offer some advice about where I may have gone wrong.

I am using a Hifiberry Amp2 [1] with two speakers (left and right).

I have upgraded to using Jetpack 4.2.3 running L4T 32.2.3.

$ cat /etc/nv_tegra_release
# R32 (release), REVISION: 2.3, GCID: 17644089, BOARD: t210ref, EABI: aarch64, DATE: Tue Nov  5 21:56:03 UTC 2019

From what I can tell I have the I2S interface working correctly on the 40 pin connector.

$ sudo grep "Name:\|J:\|BB:" /sys/kernel/debug/tegra_gpio
Name:Bank:Port CNF OE OUT IN INT_STA INT_ENB INT_LVL
 J: 2:1 00 00 00 00 00 00 000000
BB: 6:3 00 00 00 00 00 00 000000

Checking the GPIO configuration based on the post here [2]. The value for Reg: 0x7000314c is different to the linked post however I think that it still indicates that I2S is configured.

$ sudo grep dap4 /sys/kernel/debug/tegra_pinctrl_reg
Bank: 1 Reg: 0x70003144 Val: 0x00000044 -> dap4_fs_pj4
Bank: 1 Reg: 0x70003148 Val: 0x00000044 -> dap4_din_pj5
Bank: 1 Reg: 0x7000314c Val: 0x00000004 -> dap4_dout_pj6
Bank: 1 Reg: 0x70003150 Val: 0x00000044 -> dap4_sclk_pj7

Resetting the mixer controls.

$ alsactl init tegrasndt210ref
Reset Tegra APE sound-card controls

Verify that I2S4 is mapped to the ADMAIF1

$ amixer -c tegrasndt210ref sget "ADMAIF1 Mux"
Simple mixer control 'ADMAIF1 Mux',0
  Capabilities: enum
  Items: 'None' 'ADMAIF1' 'ADMAIF2' 'ADMAIF3' 'ADMAIF4' 'ADMAIF5' 'ADMAIF6' 'ADMAIF7' 'ADMAIF8' 'ADMAIF9' 'ADMAIF10' 'I2S1' 'I2S2' 'I2S3' 'I2S4' 'I2S5' 'SFC1' 'SFC2' 'SFC3' 'SFC4' 'MIXER1-1' 'MIXER1-2' 'MIXER1-3' 'MIXER1-4' 'MIXER1-5' 'AMX1' 'AMX2' 'AFC1' 'AFC2' 'AFC3' 'AFC4' 'AFC5' 'AFC6' 'OPE1' 'OPE2' 'SPKPROT1' 'MVC1' 'MVC2' 'IQC1-1' 'IQC1-2' 'IQC2-1' 'IQC2-2' 'DMIC1' 'DMIC2' 'DMIC3' 'ADX1-1' 'ADX1-2' 'ADX1-3' 'ADX1-4' 'ADX2-1' 'ADX2-2' 'ADX2-3' 'ADX2-4'
  Item0: 'I2S4'

$ amixer -c tegrasndt210ref sget "I2S4 Mux"
Simple mixer control 'I2S4 Mux',0
  Capabilities: enum
  Items: 'None' 'ADMAIF1' 'ADMAIF2' 'ADMAIF3' 'ADMAIF4' 'ADMAIF5' 'ADMAIF6' 'ADMAIF7' 'ADMAIF8' 'ADMAIF9' 'ADMAIF10' 'I2S1' 'I2S2' 'I2S3' 'I2S4' 'I2S5' 'SFC1' 'SFC2' 'SFC3' 'SFC4' 'MIXER1-1' 'MIXER1-2' 'MIXER1-3' 'MIXER1-4' 'MIXER1-5' 'AMX1' 'AMX2' 'AFC1' 'AFC2' 'AFC3' 'AFC4' 'AFC5' 'AFC6' 'OPE1' 'OPE2' 'SPKPROT1' 'MVC1' 'MVC2' 'IQC1-1' 'IQC1-2' 'IQC2-1' 'IQC2-2' 'DMIC1' 'DMIC2' 'DMIC3' 'ADX1-1' 'ADX1-2' 'ADX1-3' 'ADX1-4' 'ADX2-1' 'ADX2-2' 'ADX2-3' 'ADX2-4'
  Item0: 'ADMAIF1'

I get no errors when I try to play sample WAV file however I cannot hear anything. You can get a copy of the file here [3].

$ aplay -D hw:tegrasndt210ref,0 CantinaBand3.wav
Playing WAVE 'CantinaBand3.wav' : Signed 16 bit Little Endian, Rate 22050 Hz, Mono

I can run the speaker test command and it does not give any errors - but I also cannot hear anything.

speaker-test -c2 -twav -D plughw:CARD=tegrasndt210ref,DEV=0

speaker-test 1.1.3

Playback device is plughw:CARD=tegrasndt210ref,DEV=0
Stream parameters are 48000Hz, S16_LE, 2 channels
WAV file(s)
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 32 to 8192
Period size range from 32 to 4096
Using max buffer size 8192
Periods = 4
was set period_size = 2048
was set buffer_size = 8192
 0 - Front Left
 1 - Front Right
Time per period = 2.860768
 0 - Front Left
 1 - Front Right
Time per period = 3.027660
 0 - Front Left
 1 - Front Right

Do you have any idea why the sound isn’t working?

Regards,
Ben

[1] https://www.hifiberry.com/shop/boards/hifiberry-amp2/
[2] https://devtalk.nvidia.com/default/topic/1049674/jetson-nano/audio-i2s-on-40-pin-connector/post/5390631/#5390631
[3] https://www2.cs.uic.edu/~i101/SoundFiles/CantinaBand3.wav

Hello!

I have had a quick look at the hifiberry site but it is not 100% clear to me which DT overlay they use for this board. There is a hifiberry-amp overlay [0] but it is not clear if this is also applicable for the amp2 as the tas57xx looks a bit different and there is mention that the hifiberry-dacplus overlay [1] is relevant but does not appear to be the same chip on the board.

From what I can see I don’t think that you can just plug this board is and it will work. I think that the DT needs to be modified to work with this board.

If you are looking from something that you can simply connect and test playback, I know that the raspiaudio mic+ board (with on-board speakers) works [2]. They show support for Jetson Nano on their website.

Regards,
Jon

[0] linux/hifiberry-amp-overlay.dts at rpi-4.19.y · raspberrypi/linux · GitHub
[1] linux/hifiberry-dacplus-overlay.dts at rpi-4.19.y · raspberrypi/linux · GitHub
[2] https://www.raspiaudio.com/

Hi Jon,

Thank you so much for having a look and suggesting the Raspiaudio MIC+ board. In terms of testing that we have I2S audio output working correctly, it certainly sounds like the best way forward.

During our investigation today we noticed that we are getting a value of 0x00000044 for dap4_din_pj5.

$ sudo grep dap4 /sys/kernel/debug/tegra_pinctrl_reg
Bank: 1 Reg: 0x70003144 Val: 0x00000044 -> dap4_fs_pj4
Bank: 1 Reg: 0x70003148 Val: 0x00000044 -> dap4_din_pj5
Bank: 1 Reg: 0x7000314c Val: 0x00000004 -> dap4_dout_pj6
Bank: 1 Reg: 0x70003150 Val: 0x00000044 -> dap4_sclk_pj7

By contrast according to this post [1], you got a value of 0x00000054 for dap4_din_pj5. I understand that this pin is for data input and so it would be for a microphone as opposed to a speaker. Does this mean that our microphone is misconfigured since our dap4_din_pj5 value is different to your value?

What should we do to correct this issue? I am happy to rebuild the boot loader as necessary if required.
Is the precise meaning of each bit (i.e bit[0:1] is for i2s mode, bit[4] is for output enable, …) documented somewhere that I can look up?

Regards,
Ben

[1] https://devtalk.nvidia.com/default/topic/1049674/jetson-nano/audio-i2s-on-40-pin-connector/post/5390631/#5390631

Hi Ben,

The difference between the value 0x54 and 0x44, is the output enable. With the value 0x44, the output is enabled and with 0x54 it is disabled. Given that this is signal is only used for input you do not need the output enabled. However, at the same time it does not matter if you have it enabled or not. So either value is fine for testing.

The values for these registers are documented in the ‘technical reference manual’ [0] under the sections ‘Pinmuxing’ and ‘Pinmux Registers’.

Regards,
Jon

[0] https://developer.nvidia.com/embedded/dlc/tegra-x1-technical-reference-manual

Hello!

I just wanted to let you know that we have release JetPack 4.3 (L4T 32.3.1) and we now have a tool included to assist with the reconfiguration of the pins exposed by the 40-pin header so that you no longer need to rebuild and reflash. Please see the following:

https://docs.nvidia.com/jetson/l4t/index.html#page/Tegra%2520Linux%2520Driver%2520Package%2520Development%2520Guide%2Fhw_setup_jetson_io.html%23

Regards,
Jon

Hi Jon,

That looks good! I am looking forward to giving that a shot as soon I can. The Raspiaudio MIC+ board that you previously suggested also just arrived in the mail today so that is very exciting too.

Thanks for the wonderful support that you have been giving us on this issue.

Regards
Ben

Hi Ben,

Just to let you know that we have identified an issue with the Jetson.IO tool on Nano when updating Nano using SD card image. However, there is a simple fix availabe. Details are here:

Regards,
Jon

Hi Jon,

Thanks to the Nvidia team for the new configuration tool. It will certainly make configuring the I2S interface much easier.

I tried to use this tool and have configured the 40 pin extension header to enable i2s1 (without enabling anything else). Unfortunately we could not get any sound from the amplifier card. Using an oscilloscope we tested pin 12 (SCLK) while VLC was playing audio and we did not see any signal.

Using the original bootloader method, we were successful in getting a signal from SCLK and managed to get audio using the Raspiaudio
MIC+ board.

Some debug information to follow,

$ cat /etc/nv_tegra_release
# R32 (release), REVISION: 3.1, GCID: 18186506, BOARD: t210ref, EABI: aarch64, DATE: Tue Dec 10 06:58:34 UTC 2019
$ sudo grep "Name:\|J:\|BB:" /sys/kernel/debug/tegra_gpio
Name:Bank:Port CNF OE OUT IN INT_STA INT_ENB INT_LVL
 J: 2:1 00 00 00 00 00 00 000000
BB: 6:3 00 00 00 00 00 00 000000
$ sudo grep dap4 /sys/kernel/debug/tegra_pinctrl_reg
Bank: 1 Reg: 0x70003144 Val: 0x00000015 -> dap4_fs_pj4
Bank: 1 Reg: 0x70003148 Val: 0x00000015 -> dap4_din_pj5
Bank: 1 Reg: 0x7000314c Val: 0x00000015 -> dap4_dout_pj6
Bank: 1 Reg: 0x70003150 Val: 0x00000015 -> dap4_sclk_pj7
$ amixer -c tegrasndt210ref sget "ADMAIF1 Mux"
Simple mixer control 'ADMAIF1 Mux',0
  Capabilities: enum
  Items: 'None' 'ADMAIF1' 'ADMAIF2' 'ADMAIF3' 'ADMAIF4' 'ADMAIF5' 'ADMAIF6' 'ADMAIF7' 'ADMAIF8' 'ADMAIF9' 'ADMAIF10' 'I2S1' 'I2S2' 'I2S3' 'I2S4' 'I2S5' 'SFC1' 'SFC2' 'SFC3' 'SFC4' 'MIXER1-1' 'MIXER1-2' 'MIXER1-3' 'MIXER1-4' 'MIXER1-5' 'AMX1' 'AMX2' 'AFC1' 'AFC2' 'AFC3' 'AFC4' 'AFC5' 'AFC6' 'OPE1' 'OPE2' 'SPKPROT1' 'MVC1' 'MVC2' 'IQC1-1' 'IQC1-2' 'IQC2-1' 'IQC2-2' 'DMIC1' 'DMIC2' 'DMIC3' 'ADX1-1' 'ADX1-2' 'ADX1-3' 'ADX1-4' 'ADX2-1' 'ADX2-2' 'ADX2-3' 'ADX2-4'
  Item0: 'I2S4'
$ amixer -c tegrasndt210ref sget "I2S4 Mux"
Simple mixer control 'I2S4 Mux',0
  Capabilities: enum
  Items: 'None' 'ADMAIF1' 'ADMAIF2' 'ADMAIF3' 'ADMAIF4' 'ADMAIF5' 'ADMAIF6' 'ADMAIF7' 'ADMAIF8' 'ADMAIF9' 'ADMAIF10' 'I2S1' 'I2S2' 'I2S3' 'I2S4' 'I2S5' 'SFC1' 'SFC2' 'SFC3' 'SFC4' 'MIXER1-1' 'MIXER1-2' 'MIXER1-3' 'MIXER1-4' 'MIXER1-5' 'AMX1' 'AMX2' 'AFC1' 'AFC2' 'AFC3' 'AFC4' 'AFC5' 'AFC6' 'OPE1' 'OPE2' 'SPKPROT1' 'MVC1' 'MVC2' 'IQC1-1' 'IQC1-2' 'IQC2-1' 'IQC2-2' 'DMIC1' 'DMIC2' 'DMIC3' 'ADX1-1' 'ADX1-2' 'ADX1-3' 'ADX1-4' 'ADX2-1' 'ADX2-2' 'ADX2-3' 'ADX2-4'
  Item0: 'ADMAIF1'

Thanks for your continued assistance Jon.

Regards
Ben

Hi Ben,

Thanks for the feedback. In the above you mention you are using I2S1 but the debug info is for I2S4? If you have an A01 board (which I believe you do from your other message [0]), then your board uses I2S1 and not I2S4. Can you dump the following …

$ sudo grep dap1 /sys/kernel/debug/tegra_pinctrl_reg

Regards,
Jon

[0] https://devtalk.nvidia.com/default/topic/1068583/jetson-nano/jetpack-4-3-l4t-r32-3-1-released/post/5414048/#5414048

Hi Jon,

Yes I’ll do that. I won’t be at work again until the 2nd January so there will be a delay.

Hope you have a great festive season.

Regards
Ben

Hi Jon,

Happy New Year!

I have dumped the requested information

$ sudo grep dap1 /sys/kernel/debug/tegra_pinctrl_reg
Bank: 1 Reg: 0x70003124 Val: 0x00006044 -> dap1_fs_pb0
Bank: 1 Reg: 0x70003128 Val: 0x00006054 -> dap1_din_pb1
Bank: 1 Reg: 0x7000312c Val: 0x00006004 -> dap1_dout_pb2
Bank: 1 Reg: 0x70003130 Val: 0x00006044 -> dap1_sclk_pb3

Regards
Ben

Hello Ben!

Happy new year. Sorry just got back to the office.

The above settings look good to me and so I am surprised that this is not working. Have you compared with the register settings that were working for you? Can you confirm that the bootloader changes you made are for DAP1 or DAP4?

Maybe you can also try …

$ alsactl init tegrasndt210ref
$ speaker-test -D hw:tegrasndt210ref,0 -r 48000 -c 2 -F S16_LE -t sine -f 500

Regards,
Jon

Hi Jon,

No luck unfortunately when running

$ alsactl init tegrasndt210ref
$ speaker-test -D hw:tegrasndt210ref,0 -r 48000 -c 2 -F S16_LE -t sine -f 500

There were no errors but there was also no sound. I am using the Raspiaudio MIC+ for testing.

Have you compared with the register settings that were working for you?
Do you mean comparing the register settings between L4T 32.2.3 with the bootloader patch and L4T 32.3.1 using jetson-io.py? I haven’t at this stage but I can certainly give that a shot next.

Can you confirm that the bootloader changes you made are for DAP1 or DAP4?
I didn’t change the bootloader in L4T 32.3.1. The only tool that I have used is the provided jetson-io.py configuration tool.
On L4T 32.2.3 when we did patch the bootloader, I used the patch from @sharadg
I2S audio output not working - Jetson Nano - NVIDIA Developer Forums
which seems to be changing DAP4.

I am not sure of the significance between DAP1/DAP4 and I2S1/I2S4. Previously using L4T 32.2.3 and patching the bootloader, we seemed to be using DAP4 and I2S4 and that appeared to work. The only reason that I switched to DAP1 and I2S1 on L4T 32.3.1 is that the jetson-io.py tool only provides an option for I2S1. I don’t have a preference either way - it is just an observation.

I also noticed the following

$ amixer -c tegrasndt210ref sget "ADMAIF1 Mux"
Simple mixer control 'ADMAIF1 Mux',0
  Capabilities: enum
  Items: 'None' 'ADMAIF1' 'ADMAIF2' 'ADMAIF3' 'ADMAIF4' 'ADMAIF5' 'ADMAIF6' 'ADMAIF7' 'ADMAIF8' 'ADMAIF9' 'ADMAIF10' 'I2S1' 'I2S2' 'I2S3' 'I2S4' 'I2S5' 'SFC1' 'SFC2' 'SFC3' 'SFC4' 'MIXER1-1' 'MIXER1-2' 'MIXER1-3' 'MIXER1-4' 'MIXER1-5' 'AMX1' 'AMX2' 'AFC1' 'AFC2' 'AFC3' 'AFC4' 'AFC5' 'AFC6' 'OPE1' 'OPE2' 'SPKPROT1' 'MVC1' 'MVC2' 'IQC1-1' 'IQC1-2' 'IQC2-1' 'IQC2-2' 'DMIC1' 'DMIC2' 'DMIC3' 'ADX1-1' 'ADX1-2' 'ADX1-3' 'ADX1-4' 'ADX2-1' 'ADX2-2' 'ADX2-3' 'ADX2-4'
  Item0: 'I2S4'

$ amixer -c tegrasndt210ref sget "I2S4 Mux"
Simple mixer control 'I2S4 Mux',0
  Capabilities: enum
  Items: 'None' 'ADMAIF1' 'ADMAIF2' 'ADMAIF3' 'ADMAIF4' 'ADMAIF5' 'ADMAIF6' 'ADMAIF7' 'ADMAIF8' 'ADMAIF9' 'ADMAIF10' 'I2S1' 'I2S2' 'I2S3' 'I2S4' 'I2S5' 'SFC1' 'SFC2' 'SFC3' 'SFC4' 'MIXER1-1' 'MIXER1-2' 'MIXER1-3' 'MIXER1-4' 'MIXER1-5' 'AMX1' 'AMX2' 'AFC1' 'AFC2' 'AFC3' 'AFC4' 'AFC5' 'AFC6' 'OPE1' 'OPE2' 'SPKPROT1' 'MVC1' 'MVC2' 'IQC1-1' 'IQC1-2' 'IQC2-1' 'IQC2-2' 'DMIC1' 'DMIC2' 'DMIC3' 'ADX1-1' 'ADX1-2' 'ADX1-3' 'ADX1-4' 'ADX2-1' 'ADX2-2' 'ADX2-3' 'ADX2-4'
  Item0: 'ADMAIF1'

$ amixer -c tegrasndt210ref sget "I2S1 Mux"
Simple mixer control 'I2S1 Mux',0
  Capabilities: enum
  Items: 'None' 'ADMAIF1' 'ADMAIF2' 'ADMAIF3' 'ADMAIF4' 'ADMAIF5' 'ADMAIF6' 'ADMAIF7' 'ADMAIF8' 'ADMAIF9' 'ADMAIF10' 'I2S1' 'I2S2' 'I2S3' 'I2S4' 'I2S5' 'SFC1' 'SFC2' 'SFC3' 'SFC4' 'MIXER1-1' 'MIXER1-2' 'MIXER1-3' 'MIXER1-4' 'MIXER1-5' 'AMX1' 'AMX2' 'AFC1' 'AFC2' 'AFC3' 'AFC4' 'AFC5' 'AFC6' 'OPE1' 'OPE2' 'SPKPROT1' 'MVC1' 'MVC2' 'IQC1-1' 'IQC1-2' 'IQC2-1' 'IQC2-2' 'DMIC1' 'DMIC2' 'DMIC3' 'ADX1-1' 'ADX1-2' 'ADX1-3' 'ADX1-4' 'ADX2-1' 'ADX2-2' 'ADX2-3' 'ADX2-4'
  Item0: 'None'

Should “ADMAIF1” be associated with “I2S1” instead of “I2S4”? Should “I2S1 Mux” be associated with “ADMAIF1” instead of “None”?

Regards,
Ben

Hi Jon,

I did a bit more digging and discovered something interesting.

I am using an A01 board

$ cat /sys/firmware/devicetree/base/compatible
nvidia,p3449-0000-a01+p3448-0000-a01nvidia,jetson-nanonvidia,tegra210

Looking at the jetson-io.py tool, it appears to load the available configuration from /opt/nvidia/jetson-io/Jetson/boards/p3449-0000-*
In my case I think it would be loading /opt/nvidia/jetson-io/Jetson/boards/p3449-0000-a01+p3448-0000-a01.board

For the a01 board, the variable “hdr40_pingroup_function” has a key for “i2s1” however for the a02 and b00 boards the key is for i2s4. Is that implementation correct or is it an oversight? Has the i2s interface changed between the a01 version and the newer versions?

Here are the relevant mappings for your convenience.

p3449-0000-a01+p3448-0000-a01.board

hdr40_pingroup_function = {
    'aud_mclk'      : 'aud',
    'i2s1'          : 'i2s1',
    'pwm0'          : 'pwm0',
    'pwm2'          : 'pwm2',
    'spi1'          : 'spi1',
    'spi2'          : 'spi2',
    'uartb-cts/rts' : 'uartb',
};

p3449-0000-a02+p3448-0000-a02.board

hdr40_pingroup_function = {
    'aud_mclk'      : 'aud',
    'i2s4'          : 'i2s4b',
    'pwm0'          : 'pwm0',
    'pwm2'          : 'pwm2',
    'spi1'          : 'spi1',
    'spi2'          : 'spi2',
    'uartb-cts/rts' : 'uartb',
};

p3449-0000-b00+p3448-0000-b00.board

hdr40_pingroup_function = {
    'aud_mclk'      : 'aud',
    'i2s4'          : 'i2s4b',
    'pwm0'          : 'pwm0',
    'pwm2'          : 'pwm2',
    'spi1'          : 'spi1',
    'spi2'          : 'spi2',
    'uartb-cts/rts' : 'uartb',
};

Regards
Ben