I’m working to add external I2S input to the MilkV Duo. This is a continuation of work that was started over on this topic:
It appears that I’ve got input working and the source is in my own fork of the SDK V2 here:
This builds on the MAX98357A output driver that we got working last year by adding a new ALSA hardware card for the WM8782. Note that it’s not necessary to actually have a WM8782 connected - any device that can generate I2S data in signed 16 or 24-bit LE format should work. It’s also still necessary to use the ‘ethpoke’ application in my duo-examples repository to configure the I/O muxes:
At this time I’m still testing and cleaning up code so there may be additional changes as I progress, but things are hopeful.
I’ve been finding ways to simplify the amount of code required for external I2S - using the ‘simple-card’ driver eliminates the need for the ‘cv1835_max98357a’ driver and ‘cv1835_wm8782’ and the subsequent changes to the sound/soc/cvitek Makefile and Kconfig. However, despite the fact that the new I2S input driver appears in the ‘arecord -l’ device list and recording from it appears to proceed correctly, generating expected messages in syslog and an output file, the actual external I2S pins are not active. There must be further things required. I’m continuing to debug…
I’ve discovered why the input I2S device doesn’t appear to be connected to the external I2S pins - there are a set of muxes that are configured to route the various devices to the pins and the settings chosen for the muxes assume that I2S1 pins would be used, but we’re using the I2S2 pins. The driver code can be changed to prioritize I2S2 and this will help during concurrent operation, however it will mean that only concurrent operation of I2S1 and I2S2 will work since one of them will have to operate in ‘secondary’ mode, taking its clocks from the other which means it cannot operate alone without on-the-fly reconfiguration which the normal driver operation doesn’t allow. I’ll be giving that a try shortly…
SDK V2 appears to have ALSA installed - I’ve not had to make any changes to the buildroot configuration and aplay, arecord & alsamixer are all available.
Further progress. I studied the AIAO mux settings in cv1835_i2s_subsys.c and discovered that they were configured to use the I2S1 I/O pins which aren’t fully available on the Duo board. I revised the settings to use the I2S2 pins on the ethernet connector and now I2S input is working. The main problem with the older settings was that they didn’t hook up the connections between the master and slave ports of the internal channels correctly.
As noted earlier, there is a caveat - the input channel is operating as a slave to the output channel, so it only works concurrently. You cannot do I2S input only - the output channel must be running otherwise the input channel will get I/O errors. That’s fine for my application, but may cause issues for if you’re not aware of the limitation. Output only does work though, and that’s a more common use-case.
I’ve stripped out all the extraneous modifications leading up to this point and checked in the minimal changes to my github fork of SDK V2. I’m now using the ‘simple-audio-card’ linkage driver and the spdif tx/rx codec targets for generic I2S which greatly reduced the amount of code needed. Now the most critical changes are in the DTS file defining how the existing kernel drivers are hooked up.
Dug back into the past and applied the u-boot board.c modifications suggested by @dnech to my SDK V2 external I2S branch and it works. I added in the GPIO muxing changes as well since I found those necessary in my ethpoke userspace application. With this change ethpoke is no longer needed and audio operations will work immediately after bootup.
Yes - that was the first thing I did in this thread. It worked just fine. Since then I’ve made significant changes to the way the external I2S is enabled and gone to a more generic codec driver that should still work with the max98357a while also allowing I2S input if desired.
Note that while the drivers I’m using now don’t specifically mention the max98357a, they still output I2S audio in a form that the max98357a can use and require no new C code - just device tree changes. The only C code required in my current branch were modest additions to existing files to get the I2S2 output pins working properly.
A bit more followup on the I2S situation. One of the big issues getting in the way of using ordinary I2S codecs is that there didn’t seem to be an MCLK output for the codec to run off of. That forced me to look at some offbeat codecs that included a PLL to regenerate MCLK from the BCLK input and the only reasonably priced one I found also had pretty bad audio performance. This encouraged me to think harder and in the process I discovered that pin 25 on the CV1800B SoC (labeled AUX0) can actually be muxed to provide an MCLK output from I2S channel 1. I tweaked the pin setup code in a few places and was pleased to learn that this works. Details are here:
This MCLK output runs at the 3.3V levels while the other I2S bus runs at 1.8V so there will be some level translation required, but once that’s done you can use more conventional codecs with good audio characteristics.
Note also that the AUX0 pin is not brought out to headers - it’s only available on a tiny 0402 resistor (R17) so it’s difficult to wire up. But if you’re building your own system with bare CV1800B parts that’s no big deal.
Note also that the AUX0 pin may be used as a boot option selector in some systems. This doesn’t appear to be the case with the Milk-V Duo, but resistor R17 is pulled down to 0V nevertheless to keep the bootup consistent. Once the system is booted though that pin can be reused for other things, and having it as an MCLK output will not affect it at boot time.