Are you on TorizonCore or are you using our reference BSP? The process for enabling drivers differs a bit between the two. The community thread you’re referencing depicts someone using our reference BSP.
If you are using TorizonCore what version of our software are you using?
Do you want to also use the MAX98357A or are you just doing this as an excercise for a different driver?
I see, well normally we are happy to enable drivers for our customers on TorizonCore. But, you are on TorizonCore 5.7.0, which is an LTS release that we no longer add new features to, like new drivers.
So your options are the following then:
Either build TorizonCore using Yocto and integrate this new driver.
Also, what updates do I need to make to the device tree? Or we dont need to make any of device tree updates if the kernel module has been added?
I imagine you would still need to update the device tree. Though the exact details are dependent on the peripheral itself. I’ve never personally integrated this specific peripheral myself so I don’t know the exact details for the device tree here. You may be able to find documentation on the device tree for this peripheral in the Linux kernel somewhere.
Thanks for your response. Is there a link to exercise the first option of building TorizonCore using Yocto?
Also if I went to the non-LTS release TorizonCore 6.x.x - can this driver be added, if not already?
TorizonCore 6.X is still in active development by us. So yes we currently take requests to add drivers to this version of the software. This would enable the driver by default for use, but you would still need to make the necessary device tree changes on your side for whatever hardware configuration you have.
I followed the instructions for building external kernel modules. Got the image built but when was trying to deploy using SSH got the following error when trying to unpack.
Unpacking Toradex Easy Installer image.
An unexpected Exception occured. Please provide the following stack trace to
the Toradex TorizonCore support team.
Traceback (most recent call last):
File “/builder/torizoncore-builder”, line 221, in
File “/builder/tcbuilder/cli/images.py”, line 145, in do_images_unpack
File “/builder/tcbuilder/cli/images.py”, line 139, in images_unpack
images.import_local_image(image_dir, dir_list, dir_list, dir_list)
File “/builder/tcbuilder/backend/images.py”, line 282, in import_local_image
subprocess.check_output(tarcmd, shell=True, stderr=subprocess.STDOUT)
File “/usr/lib/python3.9/subprocess.py”, line 424, in check_output
return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
File “/usr/lib/python3.9/subprocess.py”, line 528, in run
raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command ‘cat /workdir/torizon-core-docker-verdin-imx8mp-Tezi_5.7.0+build.17-max98357a-t1.tar | cat | tar -xf - -C /storage/tezi.tmp’ returned non-zero exit status 2.
The error you got is related to issues with extracting the target tar file. Common issues can be with the tool not being able to find/see the tar file.
Where is the tar file relative to where you are executing torizoncore-builder images unpack? The file path needs to be in the same directory or a sub-directory from where you are executing the command.
As per your lsmod output it looks like you have the driver enabled now.
I would assume the issue is with your device tree changes now. When you copied the device tree changes from that other thread did you copy them from just the first post in the thread or did you include the answer as well?
Also is your hardware hooked up the same as the other customers? Because that customer’s overlay works for their setup, but it’s not clear whether your setup is the same as theirs.
Is the driver outputting any errors/logs in dmesg?
There is an option for CONFIG_SND_SOC_MAX98357A=m.
How is that option set?
I’m confused, why are you asking about this option? You already have the driver enabled in your image.
I’m not sure I follow. All setting that config option does is enable the same driver you’re already loading now. The difference being it would be built-in as part of the kernel rather than as a out-of-tree module. But the end result should be the same, it’s the same code and driver being loaded.
All this does is load the driver. Loading the driver does not necessarily mean your hardware peripheral gets noticed by the driver. For that you need a correct device tree configuration for your setup. Are you confident that your device tree is not an issue?
If you believe that enabling the config would make a difference then you can go and reference the method with Yocto that I talked about earlier. Then you can do a TorizonCore build with this config enabled yourself for testing.
Glad to hear you were able to amend your device tree changes. Though I’m not sure why you’re not seeing any controls. I assume this audio codec has built-in controls in the first place. Unfortunately I don’t have this specific codec lying around to test and validate it myself.
Perhaps berganas can comment with their experience using this codec.
Glad that helped! I didn’t see the controls in my project either. However, I didn’t need them for my use case and I could play the audio from the application using aplay, so I never looked more into it.