Posts made by sza2 sza2

@Xplatforms Hi,

First of all, I not an audiophile guy. Although my experience with the DAC mentioned in the topic title is pretty good - at least to my ears. You can also take a look at the sine wave I captured, there's no distortion, no noticeable noise on it, that's a quite good waveform.

I've tested the channels by a 20W class-D amplifier (TPA3100 based), and it was good too. Obviously, the analog part is sensitive to the digital noise generated by the Omega2.

Regarding the USB sound cards, there are huge differences between specific models. Years ago, I bought one for ~2USD but its sound is terrible (I've tested it with the same Omega2 HW a few month ago - that's why I decided to find some way to use the I2S DAC).

On the other hand, I heard the sound of a so called Hi-Fi USB sound card and that was rather like my I2S HW (I cannot decide whether it was better or worse, but about the same quality).

I cannot say anything about the resource side, I assume @luz is right.

/sza2

@luz Hi,

Finally, I had some time to capture the boot process.GPIO17 and UART TX lines were connected to Saleae Logic's inputs. I recorded the waveform from issuing the reboot command on previously booted system, through U-boot, until the next kernel boot (official Omega2 image).

Since I was not able to upload the captured file to this comment (although the zipped file was smaller than the 2MB limit), I put in on my Google Drive: omega2_boot.logicdata - if any of you interested in.

There are three spot where GPIO17 changes its state:

In U-boot at Resetting MT7628 PHY:

Where it is switched to Ethernet (there is a short period when it seems to configured as GPIO output (for ~70us)).

During kernel boot around MTD partitions check:

This takes ~700us.

And finally, SD init set those pins to normal GPIOs as I figured it out previously:

There are three voltage levels:

• ~2.5V (I assume this is when the pin is GPIO input and the logic analyzer pulls somewhat down the pin)
• ~1.5V (when the pin is configured for Ethernet)
• ~3.3V (probably the pin is configured as GPIO output)

So, based on the above, I suppose, it is proven that U-boot changes the state from normal GPIO to Ethernet.

/sza2

@luz Hi,

I cannot recall perfectly, but as far as I remember, those pins became ~1.65V during bootloader time. Actually, I saw a glitch on the line somewhere before it permanently set to 0V, and it was already during kernel boot (maybe around MTD initialization) but I did not dig deeper. Probably, later on I'll check it - although my online radio receiver already works, so there is no compelling reason

/sza2

Hi,

Yeah, probably I'm a thread necromancer... But I think I found why (when, how) the official Omega2 image sets AGPIO to digital IO, and which is not done by the original LEDE project.

I did the following trick, and it seems it succeeded: I connect one channel of my scope to one of the GPIOs (GPIO17) which was ~1.65V by default during boot and changed to 0V at a point in time and I attached the other probe to the TX line.

As it clearly show the next screenshot, the line switched to digital at SD card initialization:

It changes right after the kernel prints MSDC device init.. So, I searched for it in the kernel source and I found.

Here is the corresponding snippet (it is located in linux-4.9.37/drivers/mmc/host/mtk-mmc/sd.c

static int __init mt_msdc_init(void)
{
    int ret;
/* +++ by chhung */
    u32 reg;

#if defined (CONFIG_MTD_ANY_RALINK)
    extern int ra_check_flash_type(void);
    if(ra_check_flash_type() == 2) { /* NAND */
	    printk("%s: !!!!! SDXC Module Initialize Fail !!!!!", __func__);
	    return 0;
    }
#endif
    printk("MTK MSDC device init.\n");
    mtk_sd_device.dev.platform_data = &msdclinux-4.9.37/drivers/mmc/host/mtk-mmc/sd.c0_hw;
if (ralink_soc == MT762X_SOC_MT7620A || ralink_soc == MT762X_SOC_MT7621AT) {
//#if defined (CONFIG_RALINK_MT7620) || defined (CONFIG_RALINK_MT7621)
    reg = sdr_read32((volatile u32*)(RALINK_SYSCTL_BASE + 0x60)) & ~(0x3<<18);
//#if defined (CONFIG_RALINK_MT7620)
	if (ralink_soc == MT762X_SOC_MT7620A)
    		reg |= 0x1<<18;
//#endif
} else {
//#elif defined (CONFIG_RALINK_MT7628)
    /* TODO: maybe omitted when RAether already toggle AGPIO_CFG */
    reg = sdr_read32((volatile u32*)(RALINK_SYSCTL_BASE + 0x3c));
    reg |= 0x1e << 16;
    sdr_write32((volatile u32*)(RALINK_SYSCTL_BASE + 0x3c), reg);

    reg = sdr_read32((volatile u32*)(RALINK_SYSCTL_BASE + 0x60)) & ~(0x3<<10);
#if defined (CONFIG_MTK_MMC_EMMC_8BIT)
    reg |= 0x3<<26 | 0x3<<28 | 0x3<<30;
    msdc0_hw.data_pins      = 8,
#endif
//#endif
}
    sdr_write32((volatile u32*)(RALINK_SYSCTL_BASE + 0x60), reg);
    //platform_device_register(&mtk_sd_device);
/* end of +++ */

    ret = platform_driver_register(&mt_msdc_driver);
    if (ret) {
        printk(KERN_ERR DRV_NAME ": Can't register driver");
        return ret;
    }
    printk(KERN_INFO DRV_NAME ": MediaTek MT6575 MSDC Driver\n");

#if defined (MT6575_SD_DEBUG)
    msdc_debug_proc_init();
#endif
    return 0;
}

It contains the part which actually do the job:

    reg = sdr_read32((volatile u32*)(RALINK_SYSCTL_BASE + 0x3c));
    reg |= 0x1e << 16;
    sdr_write32((volatile u32*)(RALINK_SYSCTL_BASE + 0x3c), reg);

It sets all the four bits of AGPIO_CFG (EPHY_GPIO_AIO_EN, bit 20..17 (GPIO14, GPIO15, GPIO16 and GPIO17)) to 1 - thus enabling them as digital GPIO.

So, it does not happen in any user space utility (like swconfig), but it happens in the kernel by enabling SD card.

Hope this is still useful for some of you

/sza2

@György-Farkas Hi,

Yes, I can set GPIOs flashing the mentioned official image to the board, however I need custom image as my I2S HW is not supported in any precompiled images.

The problem is that compiling the LEDE repo by default set GPIOs 14-17 to MDI_xxx (act as Ethernet ports) instead of GPIOs.

I can set those pins to GPIOs with devmem like stuffs at or after boot but that's far from elegant.

Regarding gpioctl, I did not download it directly, but installed by ./scripts/feeds install gpioctl-sysfs (from the top level directory of the installed SDK). However, it is available as part of libugpio. But it is just an interface to access /sys/class/gpio/*, it simply reads / writes those files.

/sza2

Based on MT7688 datasheet to use GPIO 14-17, EPHY_APGIO_AIO_EN bits in AGPIO_CFG have to be '1', anyway those pins are MDI_TP_P1 / MDI_TN_P1 / MDI_RP_P1 and MDI_RN_P1 correspondingly.

I made a small devmem like utility (I was not able to add devmem applet to busybox), setting the corresponding bits directly in the registers solved the problem, I checked on the hardware and I can control GPIO 15-17 now.

The question right now, what sets these bits in the official image (or what unset in my custom image)? Whether it happened from kernel or user space? What should I modify (config, source) to be able to use the necessary pins without hacking from user space with an aggressive utility which directly modifies the bits without caring about the consequences?

/sza2

Hi,

I compiled my image from a recently cloned LEDE git repo. Almost everything seems to work correctly except controlling some GPIO pins (15, 16, 17, 18, 19). I've tried to setup the function with omega2-ctrl and setting the pins through /sys/class/gpio/* interface, none caused any changes the voltage on the pins is ~1.55V (I've checked by scope as well, it is not toggling, it is a flat ~1.55V on all pins I cannot use / configure).

GPIO 45 / 46 seems OK, I can set them GPIO with omega2-ctrl gpiomux set command, and I can configure to in or out, can set or get value through the /sys/class/gpio/*.

I've tried the same HW using official image v0.1.9-b159.bin and I can control the GPIO pins 15, 16, 17 correctly (although in that image /dev/mem is not available, so even that omega2-ctrl is part of the image it is unusable...).

Can anyone suppose a way which direction to start to figure out what's the root cause?

Thanks,

/sza2

@luz Hi,

Glad to hear that I2S works - bad, that something else broken Currently, I don't plan to use any PWM stuff - but as a newbie I still struggling even with simple GPIOs (it works with official v0.1.9-b159 - so I'm almost sure it is a kernel configuration difference or some user space mistake I made).

/sza2

@luz Hi,

Actually, I did not apply all the patches. I modified some files manually as the patching was failed (probably the delta was to big to successfully apply - I did not spend so much time to figure out why).

I cloned the repo first last week commit 78057457912170ceba29792ef02ba441abe8f246 and I did a lot of tinkering, I don't remember the several config changes I made.

So yesterday I cloned again (cb2a3911e15df3be15126fc17fabe6f3671eee7b) to have a fresh copy and I did the following:

1. added MAX98357A related stuff to target/linux/ramips/modules.mk (based on your patch)
2. added target/linux/ramips/patches-4.4/0722-asoc-enable-max98357a-kconfig.patch
   (well, I'm not a kernel guru, so I don't understand why it is necessary to replace tristate with tristate "Maxim MAX98357A CODEC" in Kconfig but the compilation stopped with errors if I did not apply this)
3. added lines to OMEGA2.dtsi based on your patches (my current OMEGA2.dtsi) - modifications in mt7628an.dtsi was not necessary

The result of the above was a kernel which supports MAX98357A (thus PCM5102 too).

Hope this helps.

/sza2

PS: I like Saleae - however I ran into trouble due to its limitation that no continuous sampling to disk, but the maximum is the free RAM size. Although the support was good, they offer a full refund of price of the two Logic Pro 16 - well, we chose not to send back but use for other tasks

@luz Hi,

Thanks to your help it works now correctly, aplay plays the wav files.

I played a 2ch / 16bit / 44.1Hz wav (1kHz, 0dB).

The output on the I2S lines:

The waveform on the output of the DAC:

So, now we have to figure out why yours is crashing.

/sza2

@luz Hi,

Here is my diffconfig output. I did not find significant differences compared to yours.

Additionally, dmesg and lsmod.

I cannot see any MAX98357A related lines in dmesg and the use count of snd_soc_max98357a module is 0 reported by lsmod.

I have no clue.

Do you think you could share a binary image to test?

/sza2

Edit: I tried with several kernel configuration (enable / disable stuffs like GPIO / I2C / SPI /whatever - from which I thought that can influence: no success). If I enable "dummy" in sound drivers dummy device appears in /proc/asound/cards and then obviously displayed with alsactl init as well).

@luz Hi Luz,

It's been a long time that I opened this thread - and also that you were here...

Based on your guide I tried to mimic what you did to reproduce the issue but I stuck at the very beginning.

I've compiled an image with the default settings based on the following:

https://docs.onion.io/omega2-docs/cross-compiling.html

The image built successfully, and run correctly on Omega2.

Then I applied patches you shared, but I cannot find sound related menu in the menuconfig (kernel sound support appears, enabled, compiled, but there is no sound / alsa-utils available in the top level menu).

Actually, I patched OMEGA2.dtsi manually as the whole section:

 &i2s {
+       #sound-dai-cells = <0>;
        status = "okay";
 };

was missing.

Do you have any advice what else should I modify / configure (or what I missed)?

Thanks,

/sza2

Edit:

Finally I've managed to install alsa stuff by uncommenting some lines in feeds.conf.default and running an update, so now I have alsa.
However, I cannot see any soundcard:

root@LEDE:/# cat /proc/asound/cards
--- no soundcards ---
root@LEDE:/# cat /proc/asound/devices
 33:        : timer
root@LEDE:/# cat /proc/asound/timers
G0: system timer : 10000.000us (10000000 ticks)
root@LEDE:/# cat /proc/asound/version
Advanced Linux Sound Architecture Driver Version k4.9.34.

Thus alsactl init does nothing:

root@LEDE:/# alsactl init
alsactl: init:1758: No soundcards found...

The MAX98357A module (snd_soc_max98357a) is loaded:

i2c_core               20006 15 snd_soc_wm8960,v4l2_common,videodev,i2c_tiny_usb,i2c_mt7621,i2c_gpio,i2c_algo_pcf,i2c_algo_pca,i2c_algo_bit,i2c_mux_pca954x,i2c_mux_pca9541,i2c_mux_gpio,i2c_mux,i2c_dev,regmap_i2c
input_core             25126  5 uvcvideo,rotary_encoder,gpio_beeper,snd,input_polldev
regmap_core            32572  6 snd_soc_ralink_i2s,snd_soc_wm8960,snd_soc_core,regmap_spi,regmap_mmio,regmap_i2c,[permanent]
regmap_i2c              2298  1 snd_soc_wm8960
regmap_mmio             2020  1 snd_soc_ralink_i2s
snd                    41166 10 snd_soc_wm8960,snd_soc_core,snd_compress,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,snd_rawmidi,snd_seq_device,snd_hwdep
snd_compress            7076  0
snd_hwdep               4382  0
snd_mixer_oss          12761  1 snd_pcm_oss
snd_pcm                63733  5 snd_soc_ralink_i2s,snd_soc_wm8960,snd_soc_core,snd_pcm_dmaengine,snd_pcm_oss
snd_pcm_dmaengine       2907  1 snd_soc_core
snd_pcm_oss            35793  0
snd_rawmidi            15370  0
snd_seq_device          2191  1 snd_rawmidi
snd_soc_core          100019  5 snd_soc_max98357a,snd_soc_simple_card,snd_soc_simple_card_utils,snd_soc_ralink_i2s,snd_soc_wm8960
snd_soc_max98357a       1808  0
snd_soc_ralink_i2s      6320  0
snd_soc_simple_card     4304  0
snd_soc_simple_card_utils    2299  1 snd_soc_simple_card
snd_soc_wm8960         23360  0
snd_timer              15310  1 snd_pcm
soundcore               3836  1 snd

but it does not seem to used by any other module.

@CPU-Hacker PCM5102 does not have I2C interface.

Hi,

No one has any info on this?

/sza2

OK, it's not Omega2 + WM8960.

Actually it's LinkIt Smart + WM8960:

https://docs.labs.mediatek.com/resource/linkit-smart-7688/en/tutorials/audio-playback-and-recording

However both designs based on MT7688. Additionally, as far as I see, the firmware of Omega2 contains WM8960 kernel driver by default.

Probably I just mix these two stuffs.

/sza2

Hi,

I'd like to connect my PCM5102 I2C DAC board (technically it's a "Hifiberry-DAC") to Omega2.

I saw articles about other I2S peripheral (WM8960 based) but those seems overkill for my purpose (and additionally my PCM5102 based board is already built), it has a plenty of features accessible / control through I2C interface which is not necessary for me.

So, my question, is it possible to interface my PCM5102 based device to Omega2 (mainly firmware point of view, the hardware seems pretty straightforward since the I2S line are wired out on the Omega2 board)?

If possible, how? Which kernel modules do I need / is there anything I have to set to get sound on the output?

Thanks,

/sza2