Max98357a driver has been loaded and sound card has been created.
I have encountered the same problem and it is still under analysis. It may be necessary to change the driver of Max98357a.
PS: Please be careful with the order of pin connections, from left to right I guess.
TX+ TX- GND RX+ RX-
LRCK BCLK DO DI
If my understand has any mistake, please correct it.
I applied the above changes to cvi_board_init.c and do not see valid I2S signals on the TX+/- and RX +/- signals. I do see periodic bursts of noise on these pins that seem to be unrelated to audio activity.
Running aplay junk.wav on a valid WAV file delays for the proper duration of the audio file and the following appears in dmesg:
[ 309.296127] cvitek-i2s 4120000.i2s: Audio system clk=24576000, sample rate=8000
[ 311.290543] cvi_i2s_shutdown not start *dai = 000000003538aef8, *dai->playback_dma_data = 000000005c444c97
So it seems that there are still some kinks to work out of the max98357 driver. Great progress though!
I’ve confirmed that the mic input is working to capture audio. I injected a 440Hz sine tone into the lower terminal of the mic footprint (as viewed from the top with the “milkv” logo right-side up) and was able to capture the waveform at the proper frequency into a .wav file for analysis. I’ve attached an Audacity plot. Note that the 0dB full scale signal appears to be ~1Vpp so an ordinary electret microphone will generate a fairly weak signal.
For what it’s worth, the dmesg after capturing the mic input:
[ 2319.549587] cvitekaadc 300a100.adc: turn I2S3 aud_en on
[ 2319.549607] cvitekaadc 300a100.adc: adc_clk_on, I2S3 clk_ctrl0 = 0x180
[ 2319.553925] cvitekaadc 300a100.adc: adc_hw_params, set rate to 8000
[ 2319.553967] cvitek-i2s 4100000.i2s: Audio system clk=16384000, sample rate=8000
[ 2319.554117] cvitekaadc 300a100.adc: adc_on, before rxadc reg val=0x00000000
[ 2319.554131] cvitekaadc 300a100.adc: adc_on, after rxadc reg val=0x00000003
[ 2321.556547] cvi_i2s_shutdown not start *dai = 00000000e1b2f2ae, *dai->playback_dma_data = 00000000491c4aae
[ 2321.556599] cvitekaadc 300a100.adc: turn I2S3 aud_en off
[ 2321.556611] cvitekaadc 300a100.adc: adc_clk_off, I2S3 clk_ctrl0 = 0x80
Of note - you’ll see that same “cvi_i2s_shutdown not start” message even though the capture succeeded. Perhaps that’s not actually an error?
It looks normal, this is the interface called when i2s is closed, just printing a log. Please refer to cv1835_i2s.c for details.
For giggles I tried enabling the on-chip audio DAC in build/boards/cv180x/cv1800b_milkv_duo_sd/linux/cvitek_cv1800b_milkv_duo_sd_defconfig :
CONFIG_SND_SOC_CV182XA_CV182XADAC=y
CONFIG_SND_SOC_CV182XADAC=y
that built OK and now a new play device appears:
[root@milkv-duo]~# aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: max98357a [cv1835 max98357a], device 0: max98357a i2s HiFi-0 [max98357a i2s HiFi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 2: cv182xadac [cv182xa_dac], device 0: cviteka-dac 300a000.dac-0 [cviteka-dac 300a000.dac-0]
Subdevices: 1/1
Subdevice #0: subdevice #0
and playing to that device does not generate errors. The interesting thing is that now an additional line appears in dmesg when playing to either device (compare to my postings earlier in this thread above, note the cvitek-i2s-subsys lines):
[ 176.302750] cvitek-i2s 4130000.i2s: Audio system clk=16384000, sample rate=8000
[ 176.302835] cvitek-i2s-subsys 4108000.i2s_subsys: Set clk_sdma_aud0~3 to 16384000
[ 178.298603] cvi_i2s_shutdown not start *dai = 00000000f070b332, *dai->playback_dma_data = 00000000441b583f
[ 205.619981] cvitek-i2s 4120000.i2s: Audio system clk=24576000, sample rate=8000
[ 205.620068] cvitek-i2s-subsys 4108000.i2s_subsys: Set clk_sdma_aud0~3 to 24576000
[ 207.615152] cvi_i2s_shutdown not start *dai = 00000000fb404674, *dai->playback_dma_data = 0000000016d59df9
I still don’t see any activity on the TX+/- and RX+/- pins that seem to be related to audio though.
I’ve got a few other minor tweaks to the DTS that I’m going to try.
Did a little test to see if the internal audio DAC is actually working on the LED output pin: I disabled the LED blink script and then played a 440Hz tone out through the on-chip codec DAC connected to the LED pin and the LED blinked at a fast rate, suggesting that the on-chip audio output is working.
Big question is why the I2S bus signals aren’t showing up on the the TX+/- & RX+/- pins. Like dnech above I’ve confirmed that the pinmux control registers for those pins are all set to 7.
I captured the pin waveform and found that there is a regular interval of data transmission, even if the audio is not played. I am looking for any configuration abnormalities and unsure if it is related to ETH.
I’ve seen the regular burst of data too. No idea what it is and agree that it is unrelated to audio activity. It’s also very high frequency which would suggest that it’s 100Mbps ethernet, despite the fact that the pinmux registers are set to 7 which should be the I2S port. I’m wondering if the ethernet needs to be completely disabled - perhaps by removing it from the kernel configuration?
why did you decide that it is unrelated to audio activity?
Because I see these bursts of data coming out even before running aplay and also well after it completes.
I disabled several items in build/boards/cv180x/cv1800b_milkv_duo_sd/linux/cvitek_cv1800b_milkv_duo_sd_defconfig which appeared to be related to ethernet and I still see the bursts of data:
# CONFIG_STMMAC_ETH=y
# CONFIG_CV182XA_PHY=y
which had no effect on the apparent data bursts.
I tried using the devmem command line tool to read & write to the pinmux registers as suggested above by dnech. I was able to write and read back the expected values as written and attempted a variety of values - none had any effect on the signals observed on the ETH pins. I was still seeing the bursts of activity on the TX+/- pins regardless of the pinmux settings for addresses 0x030010c0 - 0x030010cc. It’s almost as if the documentation for those registers is incorrect, or else there’s some other settings that override their function.
You can close eth using following config.
ðernet0 {
status = "disabled";
};
Then abnormal waveforms will disappear.
Next, we need to see how to configure i2s.
I tried that and now I see completely different patterns of digital data on the TX/RX pins. I also can no longer ssh or ping the Duo over the USB RNDIS interface. The serial console on pins 16 & 17 still works and ifconfig shows net device usb0 with the expected IPv4 address, but nothing shows up on the USB port of the host.
Here’s what the TX & RX pins look like:
To me it still looks like two pairs of differential signals, i.e. ethernet, so it seems, you disabled the wrong interface?
Yeah, it really does - the RX pins (yellow/red) are inverse of the TX pins (blue/green). But notice - it’s really slow data, toggling at only a few Hz. Very weird.
I haven’t tried your suggestion of poking around in the 0x03009000 address range yet but I want to try that too. I notice that address space is marked “Reserved” in the datasheet. Yay - undocumented features!
Just disable eth0 in dtsi, it still can use ssh.
But if set eth to gpio in board_init.c, ssh fails.
// static void cv180x_i2s2_init(void)
// {
// printk("cv180x_i2s2_init\n");
// mmio_write_32(0x03009804, 0x0001);
// mmio_write_32(0x03009808, 0x0001);
// mmio_write_32(0x03009800, 0x0905);
// // Wait PLL_Lock, Lock_Status p5.0x12@[15] = 1
// mdelay(1);
// mmio_write_32(0x0300907C, 0x0005);
// mmio_write_32(0x03009078, 0x0F00);
// mmio_write_32(0x03009074, 0x0606);
// mmio_write_32(0x03009070, 0x0606);
// }
After rereading this thread for the third time, all this still looks like quite a daunting challenge! Couple of questions:
I will update the changes to duo256 in the future.