How to disable eMMC with Wireless Cape ?

[JoseGoncalves]

With the latest BeagleBone console testing image (Debian 10.3), I'm unable to completely disable eMMC in order to have a Wireless Connectivity Cape operating on the top of a BeagleBone Black.

What I've tried. First I've changed in /boot/uEnv.txt:

disable_uboot_overlay_emmc=1

what works like expected:

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh | grep -E '(boot|BOOT|Boot)'
[sudo] password for debian: 
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
[    1.794963] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
debian@beaglebone:~$ lsblk 
NAME        MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk0     179:0    0 14.4G  0 disk 
└─mmcblk0p1 179:1    0  896M  0 part /

After I enable the Cape overlay with:

dtb_overlay=/lib/firmware/BB-GATEWAY-WL1837-00A0.dtbo

the eMMC is activated by the kernel:

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh | grep -E '(boot|BOOT|Boot)'
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-GATEWAY-WL1837-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
uboot_overlay_options:[dtb_overlay=/lib/firmware/BB-GATEWAY-WL1837-00A0.dtbo]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
[    1.753157] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168
debian@beaglebone:~$ lsblk 
NAME         MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
mmcblk0      179:0    0 14.4G  0 disk 
└─mmcblk0p1  179:1    0  896M  0 part /
mmcblk1      179:8    0  3.6G  0 disk 
mmcblk1boot0 179:16   0    2M  1 disk 
mmcblk1boot1 179:24   0    2M  1 disk 

and, in this way, the Wi-Fi chip in the Cape is never enabled. Any hints on how can I fix this?

[RobertCNelson]

@JoseGoncalves that's crazy! did it just auto probe the eMMC?

So looking at, your log, the eMMC overlay was not loaded...

UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-GATEWAY-WL1837-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]

Now here is an example, from my build farm, with u-boot "enabling" the eMMC:

UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-01-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]

What does dmesg show you, normally it looks like:

[    1.914790] omap_hsmmc 48060000.mmc: Got CD GPIO
[    1.920094] omap_hsmmc 48060000.mmc: Linked as a consumer to regulator.1
[    1.954233] omap_hsmmc 481d8000.mmc: Linked as a consumer to regulator.1
[    1.987640] sdhci-pltfm: SDHCI platform and OF driver helper
[    2.002848] mmc0: host does not support reading read-only switch, assuming write-enable
[    2.017078] mmc0: new high speed SDHC card at address aaaa
[    2.028156] mmcblk0: mmc0:aaaa SE16G 14.8 GiB 
[    2.038676]  mmcblk0: p1
[    2.051779] mmc1: new high speed MMC card at address 0001
[    2.062805] mmcblk1: mmc1:0001 MMC02G 1.79 GiB 
[    2.068289] mmcblk1boot0: mmc1:0001 MMC02G partition 1 1.00 MiB
[    2.075064] mmcblk1boot1: mmc1:0001 MMC02G partition 2 1.00 MiB
[    2.081869] mmcblk1rpmb: mmc1:0001 MMC02G partition 3 128 KiB, chardev (244:0)

With this whole virus thing going on, i should have free time this weekend to do some spring cleaning and find my wireless gateway cape..

Regards,

[RobertCNelson]

@JoseGoncalves looks like there a gpio availbe to hold the eMMC in reset:

https://e2e.ti.com/support/processors/f/791/t/362808

[RobertCNelson]

(EMMC_RSTN)GPIO1_20

[RobertCNelson]

@JoseGoncalves can you test this overlay: just create a random file name in /opt/source/bb.org-overlays/src/arm/

then:

cd /opt/source/bb.org-overlays/
make
sudo make install

then add the overlay to /boot/uEnv.txt

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>

/ {
    /*
     * Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
     */
    fragment@0 {
        target-path="/";
        __overlay__ {

            chosen {
                overlays {
                    BB-BONE-eMMC1-in-reset-00A0 = __TIMESTAMP__;
                };
            };
        };
    };

    fragment@1 {
        target = <&gpio1>;
        __overlay__ {
            eMMC_RESET {
                gpio-hog;
                gpios = <20 GPIO_ACTIVE_HIGH>;
                output-high;
                line-name = "eMMC_RESET";
            };
        };
    };
};

[JoseGoncalves]

I will try that soon and let you know...

[RobertCNelson]

@JoseGoncalves i'm not sure about the HIGH vs low..

So first try:

                gpios = <20 GPIO_ACTIVE_HIGH>;
                output-high;

But also please try

                gpios = <20 GPIO_ACTIVE_LOW>;
                output-low;

[JoseGoncalves]

@RobertCNelson tried both options (active low and high) with the same results, i.e., eMMC is always initialized:

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh | grep -E '(boot|BOOT|Boot)'
[sudo] password for debian: 
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot-univ.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-ADC-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-in-reset-00A0]
UBOOT: Loaded Overlay:[BB-GATEWAY-WL1837-00A0]
UBOOT: Loaded Overlay:[BB-HDMI-TDA998x-00A0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[uboot_overlay_addr4=/lib/firmware/bone-emmc-reset.dtbo]
uboot_overlay_options:[uboot_overlay_addr5=/lib/firmware/BB-GATEWAY-WL1837-00A0.dtbo]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[enable_uboot_cape_universal=1]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]
[    1.753100] remoteproc remoteproc0: Booting fw image am335x-pm-firmware.elf, size 217168

debian@beaglebone:~$ dmesg | grep mmc
[    0.000000] Kernel command line: console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet
[    1.149811] omap_hsmmc 48060000.mmc: Got CD GPIO
[    1.150401] omap_hsmmc 48060000.mmc: Linked as a consumer to regulator.2
[    1.177569] omap_hsmmc 481d8000.mmc: Linked as a consumer to regulator.1
[    1.209884] mmc0: host does not support reading read-only switch, assuming write-enable
[    1.211736] mmc0: new high speed SDHC card at address 5048
[    1.217087] mmcblk0: mmc0:5048 SD16G 14.4 GiB 
[    1.223570]  mmcblk0: p1
[    1.329241] mmc1: new high speed MMC card at address 0001
[    1.348234] mmcblk1: mmc1:0001 M62704 3.56 GiB 
[    1.348852] mmcblk1boot0: mmc1:0001 M62704 partition 1 2.00 MiB
[    1.349458] mmcblk1boot1: mmc1:0001 M62704 partition 2 2.00 MiB
[    1.349863] mmcblk1rpmb: mmc1:0001 M62704 partition 3 512 KiB, chardev (244:0)
[    1.351487]  mmcblk1:
[    8.711169] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[   12.285785] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro

[JoseGoncalves]

@RobertCNelson The BB-GATEWAY-WL1837-00A0.dts already activates the eMMC reset:

        fragment@7 {
                target = <&gpio1>;
                __overlay__ {
                        eeprom_disable {
                                gpio-hog;
                                gpio = <16 GPIO_ACTIVE_LOW>;
                                output-low;
                                line-name = "eeprom_disable";
                        };
                        emmc_rst {
                                gpio-hog;
                                gpio = <20 GPIO_ACTIVE_LOW>;
                                output-low;
                                line-name = "emmc_resetN";
                        };
                        ls_buf_en {
                                gpio-hog;
                                gpios = <29 GPIO_ACTIVE_HIGH>;
                                output-high;
                                line-name = "LS_BUF_EN";
                        };
                };
        };

But the kernel seems to override that:

debian@beaglebone:~$ ./show-pins -v | grep MMC
P8.25 / eMMC d0                    0 fast rx  up  1 mmc 1 d0         mmc@481d8000 (pinmux_mmc2_pins)
P8.24 / eMMC d1                    1 fast rx  up  1 mmc 1 d1         mmc@481d8000 (pinmux_mmc2_pins)
P8.05 / eMMC d2                    2 fast rx  up  1 mmc 1 d2         mmc@481d8000 (pinmux_mmc2_pins)
P8.06 / eMMC d3                    3 fast rx  up  1 mmc 1 d3         mmc@481d8000 (pinmux_mmc2_pins)
P8.23 / eMMC d4                    4 fast rx down 7 gpio 1.04 << hi  P8_23 (pinmux_P8_23_default_pin)
P8.22 / eMMC d5                    5 fast     up  7 gpio 1.05 <!     P8_22 (pinmux_wlan_pins)
P8.03 / eMMC d6                    6 fast rx down 7 gpio 1.06 << hi  P8_03 (pinmux_P8_03_default_pin)
P8.04 / eMMC d7                    7 fast rx down 7 gpio 1.07 << hi  P8_04 (pinmux_P8_04_default_pin)
eMMC reset                        20 fast rx down 7 gpio 1.20 hi >>  eMMC_RESET
P8.21 / eMMC clk                  32 fast rx  up  2 mmc 1 clk        mmc@481d8000 (pinmux_mmc2_pins)
P8.20 / eMMC cmd                  33 fast rx  up  2 mmc 1 cmd        mmc@481d8000 (pinmux_mmc2_pins)

[RobertCNelson]

@JoseGoncalves sorry, that's crazy, yeah your right, BB-GATEWAY-WL1837-00A0.dts had already defined it..

Regards,

[JoseGoncalves]

Investigated a bit on this and, looking at the schematics for BeagleBone Black Rev C, there is an inverter between the host GPIO and the eMMC RST_n line (active low). So, to reset the eMMC, we need to set it at high level, and BB-GATEWAY-WL1837-00A0.dts is setting it currently at low level.

Nevertheless, looking at the BBB's eMMC datasheet there is this note:

So, in order the eMMC reset pin to be responsive some programming must be done previously on the eMMC chip by u-boot.

[JoseGoncalves]

Additional info: eMMC Reset Line.

[JoseGoncalves]

I've installed the mmc-utils package on my BBB and were able to activate the RST_n pin on the eMMC chip:

debian@beaglebone:~$ sudo mmc hwreset enable /dev/mmcblk1
debian@beaglebone:~$ sudo mmc extcsd read /dev/mmcblk1 | grep RST
H/W reset function [RST_N_FUNCTION]: 0x01

Nevertheless, still no luck. It seems that the u-boot config for the GPIO 1.20 connected to the eMMC reset line is always ignored, i.e., its always in it's default state:

debian@beaglebone:~$ ./show-pins -v | grep eMMC
P8.25 / eMMC d0                    0 fast rx  up  1 mmc 1 d0         mmc@481d8000 (pinmux_mmc2_pins)
P8.24 / eMMC d1                    1 fast rx  up  1 mmc 1 d1         mmc@481d8000 (pinmux_mmc2_pins)
P8.05 / eMMC d2                    2 fast rx  up  1 mmc 1 d2         mmc@481d8000 (pinmux_mmc2_pins)
P8.06 / eMMC d3                    3 fast rx  up  1 mmc 1 d3         mmc@481d8000 (pinmux_mmc2_pins)
P8.23 / eMMC d4                    4 fast rx down 7 gpio 1.04 << hi  P8_23 (pinmux_P8_23_default_pin)
P8.22 / eMMC d5                    5 fast     up  7 gpio 1.05 <!     P8_22 (pinmux_wlan_pins)
P8.03 / eMMC d6                    6 fast rx down 7 gpio 1.06 << hi  P8_03 (pinmux_P8_03_default_pin)
P8.04 / eMMC d7                    7 fast rx down 7 gpio 1.07 << hi  P8_04 (pinmux_P8_04_default_pin)
eMMC reset                        20 fast rx down 7 gpio 1.20       
P8.21 / eMMC clk                  32 fast rx  up  2 mmc 1 clk        mmc@481d8000 (pinmux_mmc2_pins)
P8.20 / eMMC cmd                  33 fast rx  up  2 mmc 1 cmd        mmc@481d8000 (pinmux_mmc2_pins)

[JoseGoncalves]

I'm unable to disable the eMMC, even after asserting the RST_n line. As soon the mmc2 controller is enabled the kernel detects the eMMC and creates the device. To decouple this issue from the Wireless Cape, I've removed it, configure u-boot without virtual capes:

disable_uboot_overlay_emmc=1
disable_uboot_overlay_video=1
disable_uboot_overlay_audio=1
disable_uboot_overlay_wireless=1
disable_uboot_overlay_adc=1
#enable_uboot_cape_universal=1

created and compiled the following overlay:

/dts-v1/;
/plugin/;

#include <dt-bindings/gpio/gpio.h>
#include <dt-bindings/pinctrl/am33xx.h>

/ {
    /*
     * Helper to show loaded overlays under: /proc/device-tree/chosen/overlays/
     */
    fragment@0 {
        target-path="/";
        __overlay__ {

            chosen {
                overlays {
                    BB-BONE-eMMC1-in-reset-00A0 = __TIMESTAMP__;
                };
            };
        };
    };

    fragment@1 {
        target = <&am33xx_pinmux>;
        __overlay__ {
            emmc_reset_pin: pinmux_emmc_reset_pin {
                pinctrl-single,pins = <
                    AM33XX_IOPAD(0x850, PIN_OUTPUT_PULLUP | MUX_MODE7)  /* gpmc_a4.gpio1_20 */
                >;
            };

            emmc_pins: pinmux_emmc_pins {
                pinctrl-single,pins = <
                    AM33XX_IOPAD(0x880, PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn1.mmc1_clk */
                    AM33XX_IOPAD(0x884, PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn2.mmc1_cmd */
                    AM33XX_IOPAD(0x800, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad0.mmc1_dat0 */
                    AM33XX_IOPAD(0x804, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad1.mmc1_dat1 */
                    AM33XX_IOPAD(0x808, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad2.mmc1_dat2 */
                    AM33XX_IOPAD(0x80c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad3.mmc1_dat3 */
                    AM33XX_IOPAD(0x810, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad4.mmc1_dat4 */
                    AM33XX_IOPAD(0x814, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad5.mmc1_dat5 */
                    AM33XX_IOPAD(0x818, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad6.mmc1_dat6 */
                    AM33XX_IOPAD(0x81c, PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad7.mmc1_dat7 */
                >;
            };
        };
    };

    fragment@2 {
        target = <&gpio1>;
        __overlay__ {
            eMMC_RESET {
                gpio-hog;
                gpios = <20 GPIO_ACTIVE_HIGH>;
                output-high;
                line-name = "eMMC_RESET";
            };
        };
    };

    fragment@3 {
        target = <&mmc2>;
        __overlay__ {
            vmmc-supply = <&vmmcsd_fixed>;
            pinctrl-names = "default";
            pinctrl-0 = <&emmc_pins &emmc_reset_pin>;
            bus-width = <8>;
            status = "okay";
        };
    };
};

and added to the uEnv.txt file:

dtb_overlay=/lib/firmware/bone-emmc-reset.dtbo

after boot, I have the eMMC up:

debian@beaglebone:~$ sudo /opt/scripts/tools/version.sh | grep -E '(boot|BOOT)'
bootloader:[microSD-(push-button)]:[/dev/mmcblk0]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
bootloader:[eMMC-(default)]:[/dev/mmcblk1]:[U-Boot 2019.04-00002-g07d5700e21]:[location: dd MBR]
UBOOT: Booted Device-Tree:[am335x-boneblack-uboot.dts]
UBOOT: Loaded Overlay:[AM335X-PRU-RPROC-4-19-TI-00A0]
UBOOT: Loaded Overlay:[BB-BONE-eMMC1-in-reset-00A0]
/boot/uEnv.txt Settings:
uboot_overlay_options:[enable_uboot_overlays=1]
uboot_overlay_options:[disable_uboot_overlay_emmc=1]
uboot_overlay_options:[disable_uboot_overlay_video=1]
uboot_overlay_options:[disable_uboot_overlay_audio=1]
uboot_overlay_options:[disable_uboot_overlay_wireless=1]
uboot_overlay_options:[disable_uboot_overlay_adc=1]
uboot_overlay_options:[uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-19-TI-00A0.dtbo]
uboot_overlay_options:[dtb_overlay=/lib/firmware/bone-emmc-reset.dtbo]
cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet]

debian@beaglebone:~$ dmesg | grep -E '(mmc|hog)'
[    0.000000] Kernel command line: console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk0p1 ro rootfstype=ext4 rootwait coherent_pool=1M net.ifnames=0 lpj=1990656 rng_core.default_quality=100 quiet
[    0.164495] GPIO line 52 (eMMC_RESET) hogged as output/high
[    0.841668] omap_hsmmc 48060000.mmc: Got CD GPIO
[    0.842252] omap_hsmmc 48060000.mmc: Linked as a consumer to regulator.1
[    0.869217] omap_hsmmc 481d8000.mmc: Linked as a consumer to regulator.1
[    0.904876] mmc0: host does not support reading read-only switch, assuming write-enable
[    0.906722] mmc0: new high speed SDHC card at address 5048
[    0.912157] mmcblk0: mmc0:5048 SD16G 14.4 GiB 
[    0.918653]  mmcblk0: p1
[    0.939679] mmc1: new high speed MMC card at address 0001
[    0.945102] mmcblk1: mmc1:0001 M62704 3.56 GiB 
[    0.945861] mmcblk1boot0: mmc1:0001 M62704 partition 1 2.00 MiB
[    0.946467] mmcblk1boot1: mmc1:0001 M62704 partition 2 2.00 MiB
[    0.947004] mmcblk1rpmb: mmc1:0001 M62704 partition 3 512 KiB, chardev (245:0)
[    0.948690]  mmcblk1: p1
[    5.053455] EXT4-fs (mmcblk0p1): mounted filesystem with ordered data mode. Opts: (null)
[    8.614045] EXT4-fs (mmcblk0p1): re-mounted. Opts: errors=remount-ro

Only if I configure mmc1.clk and/or mmc1.cmd lines as gpios (MUX_MODE7), the eMMC device is not setup.

Any ideas why I can't disable the eMMC when mmc1.clk and mmc1.cmd pins are used by a Cape?

[JoseGoncalves]

So, it seems that eMMC reset pin is completly ignored by the Kingston eMMC that I have in my BeagleBone Black (could it be a problem with Kingston eMMCs?).

In a final effort to activate the Wireless Cape, I've addded to mmc-utils a command to set the eMMC inactive (CMD15 - GO_INACTIVE_STATE). I've booted the board with BB-GATEWAY-WL1837-00A0 overlay setup, issued the mmc's GO_INACTIVE_STATE command and then rebooted the board (without power down) to start it without the eMMC block device (mmcblk1) setup. Nevertheless, even with the assurance that the mmc bus is now not being used by the eMMC, the wlan interface is still not detected/activated by the kernel. At this stage, I'm assuming that I've a faulty Wireless Cape.

To confirm this it would be very nice that someone could check if this cape is working with the latest BeagleBone image (Debian Buster).

[premjithav]

Is there any patch available for this issue ?, we are also facing the same problem for wilink module. The emmc is not disabling through uboot overlay method. The mmc1 is always detected as emmc for sdio_detection.

[mvduin]

Actually based on some testing it seems that the reset input on the Kingston eMMC is rising-edge triggered and hence cannot be used to hold it in reset, whereas the Micron eMMC is low-level triggered thus it can be held in reset.

I've checked the eMMC specification and honestly it really does seem ambiguous. On one hand they do explicitly mention that internal reset should happen on rising edge, on the other hand they show a signal diagram where CLK is "do not care" while reset is held low, which to me would imply that commands are ignored during this time. And apparently the ambiguity isn't just me, since Micron and Kingston interpreted the spec differently.

[mvduin]

issued the mmc's GO_INACTIVE_STATE command and then rebooted the board (without power down) to start it without the eMMC block device (mmcblk1) setup. Nevertheless, even with the assurance that the mmc bus is now not being used by the eMMC, the wlan interface is still not detected/activated by the kernel. At this stage, I'm assuming that I've a faulty Wireless Cape.

One concern might be that whatever initialization sequences were performed by u-boot and the kernel could have ended up putting the wifi sdio into inactive state. SD and eMMC are not exactly supposed to be on the same bus, and iirc they have some important differences w.r.t initialization.

[JoseGoncalves]

Actually based on some testing it seems that the reset input on the Kingston eMMC is rising-edge triggered and hence cannot be used to hold it in reset, whereas the Micron eMMC is low-level triggered thus it can be held in reset.

Being so, we can reach the conclusion that this Cape is completly useless in any BeagleBone that has a Kington eMMC, right?

I assume that, for this Wireless Connectivity Cape to be working in the past, it was because BeagleBones were assembled with Micron eMMC, what seems not to be true anymore...

Nevertheless, for my specific use case, I've switched from the BB Black + Wireless Cape combo to the recently released BB Green Gateway, that has already LAN and Wi-Fi interfaces on board.

[mvduin]

I don't exclude the possibility it could be worked around in u-boot using some appropriate initialization to get eMMC into inactive state without messing up the wifi chip, but it would require someone digging into that

[mvduin]

Someone on IRC (Konsgnx) managed to get the wireless cape working by cutting the cmd trace to the eMMC ("which was available on the bottom layer") and powering the beaglebone via the 5V barrel jack instead of via USB (since the cape apparently uses VDD_5V instead of SYS_5V and therefore will not function when the beaglebone is powered solely via USB).

Nevertheless, even with the assurance that the mmc bus is now not being used by the eMMC, the wlan interface is still not detected/activated by the kernel. At this stage, I'm assuming that I've a faulty Wireless Cape.

Were you powering the beaglebone via USB by any chance?

[JoseGoncalves]

@mvduin Yes, I was powering the BeagleBone via USB. That would justify why I could not never get it to work, even after sending the GO_INACTIVE_STATE cmd to the eMMC. element14 should advirtise that power supply requirement (they have done a pretty bad job in documenting this board).

Nevertheless, at least for my application, this Cape is now history, because I'm now using the BeagleBone Green Gateway for that purpose.