Porting botic patches to up to date kernel version
Hi miero, I have tried the image supplied by twluke with much success on my BeagleBone wireless. Since I would like to use archlinux and updated kernels I am currently trying to port your patches to linux-4.19.
Current status: Compilation works just fine after having done some obvious changes due to updated data structures in the ASoC API, however it currently does not work. In I2S mode I get "Transmit buffer underflow" error messages and no real lock on the DAC. DSD mode I still have to look into.
Do you have any ideas how to best troubleshoot? What is the general approach regarding further maintenance of the driver for upstream kernel updates?
Hi miero, I have tried the image supplied by twluke with much success on my BeagleBone wireless. Since I would like to use archlinux and updated kernels I am currently trying to port your patches to linux-4.19.
Current status: Compilation works just fine after having done some obvious changes due to updated data structures in the ASoC API, however it currently does not work. In I2S mode I get "Transmit buffer underflow" error messages and no real lock on the DAC. DSD mode I still have to look into.
Do you have any ideas how to best troubleshoot? What is the general approach regarding further maintenance of the driver for upstream kernel updates?
Last edited:
Sure, thanks a lot for your support! You can find the patches in linux-dev/patches/botic at botic7-v419 * coroner21/linux-dev * GitHub. Please note the following:
- Patches should apply cleanly to linux-am335x package in ArchlinuxARM (after source was prepared with makepkg -o)
- Please use -p2 patch option (currently too lazy to reformat the patches)
- The device trees are probably wrong (I am currently using one that I hacked together by copying botic changes to the BBBW device tree)
Please let me know if I can be of further assistance!
Does your kernel support device tree overlays? Because years ago I prepared DTS overlays, but I never tested them. But I guess they might "just work".
- add BBB Botic driver overlays * miero/bb.org-overlays@f01b76c * GitHub
- add BBB Botic driver overlays * miero/bb.org-overlays@f01b76c * GitHub
I tried them and even played around a little with them but somehow when loading the overlay the system did not boot anymore (which is probably more due to misconfiguration of u-boot on my part). At the moment I do not have the means to debug this further (missing serial console adapter) but definitely plan to revisit device trees and overlays once the driver itself would be working in up to date kernel.
Reporting back with progress (finally!): I am now able to get stereo I2S working perfectly fine on my ES9018 DAC with a modified patch (attached) using the sabre32 module for I2C DAC control. This is on latest BBB kernel for Arch Linux ARM.
To ensure that I did not mess anything up by accident, I for now only patched the botic card + codecs into the kernel not modifying any of the other existing source files. This means that as of now I did not enable DSD or sample rates higher than 192k.
In addition I had to change the overlay for McASP to enable ONLY ONE serializer (as needed for stereo I2S) since I was always getting buffer underruns in case more serializers were activated in device tree:
DSD and higher sample rates remain work in progress.
@miero: Are you still working on this, any updates? Let me know if I can be of assistance.
To ensure that I did not mess anything up by accident, I for now only patched the botic card + codecs into the kernel not modifying any of the other existing source files. This means that as of now I did not enable DSD or sample rates higher than 192k.
In addition I had to change the overlay for McASP to enable ONLY ONE serializer (as needed for stereo I2S) since I was always getting buffer underruns in case more serializers were activated in device tree:
Code:
fragment@4 {
target = <&mcasp0>;
__overlay__ {
pinctrl-0 = <&mcasp0_custom_pins>;
serial-dir = < /* 0: INACTIVE, 1: TX, 2: RX */
1 0 0 0
>;
tx-num-evt = <32>;
rx-num-evt = <32>;
};
};DSD and higher sample rates remain work in progress.
@miero: Are you still working on this, any updates? Let me know if I can be of assistance.
Initial updated botic driver for Arch Linux ARM
Found the cause of the major problem with buffer underruns in case more serializers were enabled: Apparently a code change in mcasp caused unused serializers not to be explicitly de-activated anymore which does not really work for our purposes.
Reversing this and applying another minor patch based on miero's initial patch set for the botic driver I am now able to get also DSD working and sample rates up to 384khz.
The updated driver based on linux-4.19 should work with the following (only stereo playback tested on my side though):
Since I do not need or use it I did not care to maintain the code for the record / SPDIF configuration: This updated driver only works in I2S / DSD mode and the serconfig parameter is not parsed anymore. In addition, my clocks are 45158400 and 49152000 so this is how the driver is configured per default (the usual module parameters can be used to overwrite this).
I have created a github repository and instructions are provided there if anyone wants to try this: GitHub - coroner21/linux-am33xbot: Arch Linux ARM Kernel with botic patches
Found the cause of the major problem with buffer underruns in case more serializers were enabled: Apparently a code change in mcasp caused unused serializers not to be explicitly de-activated anymore which does not really work for our purposes.
Reversing this and applying another minor patch based on miero's initial patch set for the botic driver I am now able to get also DSD working and sample rates up to 384khz.
The updated driver based on linux-4.19 should work with the following (only stereo playback tested on my side though):
- Standard I2S playback (up to 384khz on 8 channels)
- DSD playback (up to 4 channels tested only with DSD64 so far (I do not have any other DSD files))
- I2C control of an ES9018 DAC using sabre32 codec (use the botic codec for generic I2S DAC)
Since I do not need or use it I did not care to maintain the code for the record / SPDIF configuration: This updated driver only works in I2S / DSD mode and the serconfig parameter is not parsed anymore. In addition, my clocks are 45158400 and 49152000 so this is how the driver is configured per default (the usual module parameters can be used to overwrite this).
I have created a github repository and instructions are provided there if anyone wants to try this: GitHub - coroner21/linux-am33xbot: Arch Linux ARM Kernel with botic patches
Uploaded a kernel package: Uploadfiles.io - linux-am33xbot-4.19.12-1-armv7h.pkg.tar.xz
Please check sha256 sum before you install, this should be
Please check sha256 sum before you install, this should be
Code:
203dff780f7c055a202a6d56b4854a31521e0e220b6ca15663a7718b8dbeb239@miero: I found that mpd tends to prefer DSD_U8 over DSD_U32_LE and DSD_U32_LE over DSD_U16_LE. Since I would prefer to use DSD_U32_LE as DSD sample format per default (as it makes the highest DSD rates available), I configured the codec to only support DSD_U32_LE, however this seems to lead to some bad noise in the audio. Did you experience something similar, any tips on debugging?
I tried to tackle it by increasing the EDMA buffer size but this seems to not make any difference. For now the highest word length for DSD transfer seems to be 16bit at least on my system which means that with highest sample rate of 384khz DSD would be supported up to DSD128 only.
I tried to tackle it by increasing the EDMA buffer size but this seems to not make any difference. For now the highest word length for DSD transfer seems to be 16bit at least on my system which means that with highest sample rate of 384khz DSD would be supported up to DSD128 only.
Last edited:
Hi Miero! Many people are using your botic driver thankfully. Please explain how about writing a new botic driver for beaglebone black?Wow, thanks!
I'll try to test it too.
Last edited:
There is no reason for upgrade if the old kernel works well. The advantage of the updated driver is that it is ported to a newer kernel that is using overlays. So it should be possible to use it also on other BBB flavors (wireless, blue, green ...).
And no surprise, I had no time to test it yet...:-/
And no surprise, I had no time to test it yet...:-/
To me it is not using overlays which is the advantage: Nowadays everyone moved away from kernel overlays and instead u–boot overlays are used where the complete device tree is built once during boot.
The main advantage is that you are not bound to using decade old software (e.g. outdated mpd versions or the hassle people had to go through since they needed a new glibc version). The Debian version on twlukes image was not even fully functional with systemd...
In general every software needs some maintenance to remain usable over time.
The main advantage is that you are not bound to using decade old software (e.g. outdated mpd versions or the hassle people had to go through since they needed a new glibc version). The Debian version on twlukes image was not even fully functional with systemd...
In general every software needs some maintenance to remain usable over time.
Last edited:
Do you mind, the directory should contain Device Tree overlays?
Device Tree makes it possible to support many hardware configurations with a single kernel and without the need to explicitly load or blacklist kernel modules.
I've installed achrlinux on flash and used the kernel package.
default clk values are doubled
Code:
# cat /sys/module/snd_soc_botic/parameters/clk_44k1
45158400 vs 22579200
# cat /sys/module/snd_soc_botic/parameters/clk_48k
49152000 vs 24576000I presume that the values can be changed using kernel boot parameters, but for the moment I use echo val > /sys/....
Apart from this everything works fine.
using alsamixer for ess config is nice
I think that you should mention it in the github readme. I stumble on it as I was trying to access ess thru i2c with a python script and got some errors because the device was busy.Thanks for your effort
I've installed achrlinux on flash and used the kernel package.
default clk values are doubled
Code:# cat /sys/module/snd_soc_botic/parameters/clk_44k1 45158400 vs 22579200 # cat /sys/module/snd_soc_botic/parameters/clk_48k 49152000 vs 24576000
I presume that the values can be changed using kernel boot parameters, but for the moment I use echo val > /sys/....
Apart from this everything works fine.
using alsamixer for ess config is nice
Thanks for your effort
Wow great please accept my congratulations! Please describe step by step how you did it?
Have you tried to compile Linux source code and generate a bootable ISO image (Volumio)?
Last edited:
You can simply issue as root:
Code:
echo 'options snd_soc_botic clk_44k1=22579200 clk_48k=24576000' > /etc/modprobe.d/botic.confAfter reboot the clk frequencies will be set as needed per default.
using alsamixer for ess config is nice
Credit for this should be given to miero who implemented this codec driver with the i2c controls for ES9018 DAC.
I will update the readme a little bit to ensure that people that do not have the ES9018 do not run into problems.