Missing kernel modules in Driver Package

Autonomous Machines Jetson & Embedded Systems Jetson TX1
1

Hi!
I got your board pre-flashed with some Liunx image and I wanted to run the ALSA chain with XBAR, ADMAIF, I2S and so on. According to the documentation I wanted to configure the audio route via ALSA, but I turned out, that there are no simple controls called “AUDMUX1-1” and following. I investigated, that folder “sound” is missing from /lib/modules. I downloaded driver package and discovered it’s same there.
Even earlier I spotted this kernel ring message in dmesg and now I know where it came from:

tegra-snd-t210ref-mobile-rt565x sound.18: ASoC: Codec (null) not registered!

So my question is: how can I get those modules to work with alsa and Tegra ASoC driver?

Thanks
Piotr

2

Modules are only used if a feature is installed in the form of a module, versus integrated into the kernel (the feature might be there even if there is no module). So probably the first thing to do would be to find out which kernel feature provides what you want, and then compare it to the “/proc/config.gz” file (this file is a reflection of the running kernel’s config). Until you know the name of the kernel feature you won’t be able to really know what part is missing or just not configured.

One clue that perhaps it is a configuration issue and not a missing feature is the fact that tegra-snd-t210ref-mobile-rt565x sound.18 is mentioned at all. There also exists this directory, which would not exist if the driver did not support the hardware:

/sys/kernel/debug/asoc/tegra-snd-t210ref-mobile-rt565x

To make it easier to answer what commands or software requesting “AUDMUX1-1” are involved? A specific use case gives a starting point.

3

Hi linuxdev, many thanks for your response,

we are using a custom evaluation board with NVidia Jetson TX1 module.

Refering the directory: the point is that there’s no such one:

/sys/kernel/debug/asoc/tegra-snd-t210ref-mobile-rt565x

I assume it means our hardware does not support thie rt565x. However it’s enabled in /proc/config.gz:

CONFIG_SND_SOC_RT5639=y
CONFIG_SND_SOC_RT5659=y

Entire message from dmesg regarding this codec states as follows:

[    8.522221] tegra210_adsp_audio_platform_probe probe successfull.
[    8.535293] tegra-snd-t210ref-mobile-rt565x sound.18: ASoC: CODEC (null) not registered
[    8.549288] tegra-snd-t210ref-mobile-rt565x sound.18: snd_soc_register_card failed (-517)
[    8.561767] platform sound.18: Driver tegra-snd-t210ref-mobile-rt565x requests probe deferral

Is it possible, that failing driver prevents other (admaif, xbar, mixer, i2s and other ASoC components) from loading?

Going further,
"To make it easier to answer what commands or software requesting “AUDMUX1-1” are involved? A specific use case gives a starting point. "
I tried configuring an internal audio path in ASoC according to ASoC driver documentation:

amixer -c 0 sset 'AMX2-1 Mux' 'ADMAIF5'
amixer -c 0 sset 'AMX2-2 Mux' 'AFC1'
amixer -c 0 sset 'AMX2-3 Mux' 'ADMAIF6'
amixer -c 0 sset 'AMX2-4 Mux' 'ADX2-1'
amixer -c 0 sset 'I2S3 Mux' 'AMX2'

It involves those ALSA simple controls: AMX2-1 MUX, AMX2-2 Mux and others (I know I gave other example earlier, but it’s the same there). If I list simple controls using amixer scontrols I get:

Simple mixer control 'IEC958',0
Simple mixer control 'HDA Decode Capability',0
Simple mixer control 'HDA Maximum PCM Channels',0

no surprise then, that I get error

amixer: Unable to find simple control 'AMX2-1 Mux',0

Have you got any idea what’s going on here?

Thanks
Piotr

4

Having the config without the “/sys” entry does tend to validate the idea that the hardware was not found even though software support exists.

Regarding this specific detail, if hardware exists, it may be that the device tree needs to be altered for your custom setup, e.g., “/boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb” could be edited if it is a simple setup issue (dtb file information at the end of this reply). I do not know how custom setup might affect this, but regardless of whether hardware is actually missing or just not present at the expected address, the result would be the same and is one way driver load would fail as you have in your case. This is where I’d start since you’ve verified the drivers are in fact integrated into the kernel (there is no module load/unload since it isn’t a module).

Understand that what a mixer can see and change is through a driver to specific hardware, so failing to have a driver load would indeed make some of those interfaces disappear (it is possible there is some form of virtual interface which exists, but anything associated with real hardware will go away if the hardware or driver to the hardware fails).

To explore the “tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb” device tree blob file you can reverse compile it. The original source inside the kernel may have more of an explanation since the reverse compiled code does not contain comments, and some variable names may change and not be as explanatory, but even so reverse compile may be revealing.

dtc -I dtb -O dts -o /tmp/extracted_tegra210-jetson-tx1-p2597-2180-a01-devkit.dts /boot/tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb
# ...explore extracted_tegra210-jetson-tx1-p2597-2180-a01-devkit.dts...
less /tmp/extracted_tegra210-jetson-tx1-p2597-2180-a01-devkit.dts
# ...edit if wanted, then repackage...
dtc -I dts -O dtb -o /tmp/edited_tegra210-jetson-tx1-p2597-2180-a01-devkit.dtb /tmp/extracted_tegra210-jetson-tx1-p2597-2180-a01-devkit.dts

Note that in extlinux.conf the FDT key/value pair names this dtb file; if you want to try a different dtb with a different name just make a duplicate entry and edit the FDT file name; serial console would let you pick this alternate entry.

Serial console information is here if you choose to use it:
http://elinux.org/Jetson/TX1_Serial_Console

5

Hi Linuxdev,

Thanks for your response. I edited the tree but met some other difficulties, ended up re-flashing the board and it worked in terms that soundcard is now detected. However a new problem arose.

When I aplay a wave through i2s0, 1, 4, 5 the clock starts and seemingly transfer takes place (probably, because our boad does not have those on i/o pins). However selecting i2s2 (the one we’ve got access to) causes transmission to end quickly and no signal is observed.
Another clue could be, that looping this i2s2 (in alsa it’s I2S3) by typing:

amixer sset 'I2S3 Mux' 'I2S3'

causes bitclock and wordclock to generate.

Thanks for help in advance.
Piotr

6

I can’t help much there, I am not sufficiently familiar with this to give good advice. One thing I will note though which may have caused issues for others developing i2s is referred to in the TRM, section 5.2: “There is no clock switching protection for the audio sync clock so one needs to set up the desired clock source before enabling the audio transmit/receive device.”

So if you do anything which tries to change a clock after audio is up you will get undefined behavior. Be sure that before you do anything clocks are set up and that no clocks are changed in the middle of what you are doing.

7

Hi,

Thanks for your advice.
We’re actually still strugling with that issue, so any support (especially from NVidia themselves) would be appreciated.

If I set internal loopback directly (amixer sset ‘I2S3 Mux’ ‘I2S3’) or indirectly via mux->demux, clock is being generated even without aplay/arecord (which I believe is happening because of closing internal loopback), but aplay doesn’t make TX1 generate anything on the dataline, nor is arecord recording anything but zeros.

Setting:

amixer sset 'I2S3 Mux' 'ADMAIF5'
amixer sset 'ADMAIF5 Mux' 'I2S3'

causes aplay/arecord finish early and not starting clocks at all.

Thanks in advance!
Piotr