@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

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

@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

@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