TX2 NX - Failed to connect WiFi module over SDIO interface

[andrei.pata1]

Hi! I’m trying to connect the EWM-W306 (marvell 88w8997 chip) over the SDIO interface to TX2 NX on a custom board, but I get the following messages at system boot (the module is connected to sdhci-tegra 3440000.sdhci):

$ dmesg | grep "mmc1\|sdhci"
[    0.000000] Kernel command line: console=ttyS0,115200 root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2  video=tegrafb no_console_suspend=1 earlycon=uart8250,mmio32,0x3100000 nvdumper_reserved=0x1772e0000 gpt rootfs.slot_suffix= tegra_fbmem=0x800000@0x96081000 lut_mem=0x2008@0x9607e000 usbcore.old_scheme_first=1 tegraid=18.1.2.0.0 maxcpus=6 boot.slot_suffix= boot.ratchetvalues=0.2031647.1 vpr_resize bl_prof_dataptr=0x10000@0x175840000 sdhci_tegra.en_boot_part_access=1  
[    0.421631] iommu: Adding device 3460000.sdhci to group 0
[    0.513987] vddio-sdmmc1: 1800 <--> 3300 mV at 3300 mV 
[    4.362333] sdhci: Secure Digital Host Controller Interface driver
[    4.368522] sdhci: Copyright(c) Pierre Ossman
[    4.372880] sdhci-pltfm: SDHCI platform and OF driver helper
[    4.379480] sdhci-tegra 3460000.sdhci: Client registration for eMC Successful
[    4.392983] sdhci-tegra 3440000.sdhci: runtime pm disabled
[    4.403595] sdhci-tegra 3440000.sdhci: Client registration for eMC Successful
[    4.452986] mmc0: SDHCI controller on 3460000.sdhci [3460000.sdhci] using ADMA 64-bit with 64 bit addr
[    4.452988] mmc1: SDHCI controller on 3440000.sdhci [3440000.sdhci] using ADMA 64-bit with 64 bit addr
[    6.512995] mmc1: error -110 whilst initialising SDIO card
[    8.613052] mmc1: error -110 whilst initialising SDIO card
[   10.689018] mmc1: error -110 whilst initialising SDIO card
[   12.769039] mmc1: error -110 whilst initialising SDIO card
[   35.917337] vddio-sdmmc1: disabling

I tried various device tree settings and some kernel debugging but without success. I would need some hints on what / where to investigate next.
I’m using 4.9.201-tegra.
Bellow I listed some important details: device tree, full dmesg output, some debug info, partial schematic.

Device tree:

sdhci@3440000 {
		nvidia,ddr-tap-delay = <0xb>;
		nvidia,en-periodic-calib;
		cap-mmc-highspeed;
		compatible = "nvidia,tegra186-sdhci";
		clocks = <0x10 0x4c 0x10 0x10d 0x10 0x80>;
		cap-sd-highspeed;
		fixed-clock-freq = <0x1851960 0x1851960 0x16e3600 0x2cd29c0 0x16e3600 0x2cd29c0 0x59a5380 0xc28cb00 0x0 0x0 0x0>;
		resets = <0x10 0x23>;
		pinctrl-1 = <0x15>;
		clock-names = "sdmmc", "pll_p", "sdmmc_legacy_tm";
		id = <0x0>;
		pll_source = "pll_p";
		only-1-8-v;
		keep-power-in-suspend;
		nvidia,disable-rtpm;
		nvidia,min-tap-delay = <0x54>;
		nvidia,is-sdio;
		status = "okay";
		nvidia,max-tap-delay = <0x88>;
		interrupts = <0x0 0x40 0x4>;
		bus-width = <0x4>;
		ddr-trim-delay = <0x5>;
		phandle = <0xc6>;
		tap-delay = <0xb>;
		force-non-removable-rescan;
		reg = <0x0 0x3440000 0x0 0x210>;
		pinctrl-0 = <0x14>;
		mmc-ocr-mask = <0x0>;
		compad-vref-1v8 = <0x2>;
		trim-delay = <0x5>;
		pwrdet-support;
		reset-names = "sdhci";
		vmmc-supply = <0x12>;
		uhs-mask = <0x60>;
		linux,phandle = <0xc6>;
		non-removable;
		ignore-pm-notify;
		compad-vref-3v3 = <0x1>;
		vqmmc-supply = <0x16>;
		pinctrl-names = "sdmmc_e_33v_enable", "sdmmc_e_33v_disable";
		max-clk-limit = <0xc28cb00>;

		prod-settings { … };

		wifi@1 {
			compatible = "marvell,sd8997";
			phandle = <0xd1>;
			reg = <0x1>;
			linux,phandle = <0xd1>;
		};
	};

Debug info from the kernel:
Linux_for_Tegra/sources/kernel/kernel-4.9/drivers/mmc/host/sdhci-tegra.c:tegra_sdhci_set_tap(), variable’s values:

• tap = 0
• type = 2
• nvquirks = 4344 (0000 0001 0000 1111 1000)

dmesg_out.txt (54.5 KB)
TX2 NX Connection

WiFi Module Connection

Thanks!

[martijn.berger]

I think it is important to add that we are attempting to run this module in SDR104 mode.

[WayneWWW]

Why your device looks like out of order and missing some properties?
How did you modify and build it?

[andrei.pata1]

Build/Flash steps

I started by creating a copy of Linux_for_Tegra/sources/hardware/nvidia/platform/t18x/lanai/kernel-dts/tegra186-p3636-0001-p3509-0000-a01.dts

cp Linux_for_Tegra/sources/hardware/nvidia/platform/t18x/lanai/kernel-dts/tegra186-p3636-0001-p3509-0000-a01.dts \
  Linux_for_Tegra/sources/hardware/nvidia/platform/t18x/lanai/kernel-dts/tesseract-devicetree.dts

I added my file to the Linux_for_Tegra/sources/hardware/nvidia/platform/t18x/lanai/kernel-dts/Makefile

dtb-$(CONFIG_ARCH_TEGRA_18x_SOC) += tesseract-devicetree.dtb

I built the device tree like

make ARCH=arm64 O="$BUILD_DIR" -j"$(nproc)" dtbs

and the kernel like

make ARCH=arm64 O="$BUILD_DIR" -j"$(nproc)" Image

I copy the new device tree (build/arch/arm64/boot/dts/tesseract-devicetree.dtb) to the TX2 NX and make the changes in /boot/extlinux/extlinux.conf to use it:

LABEL primary
      MENU LABEL primary kernel
      LINUX /home/ubuntu/Image
      INITRD /boot/initrd
      APPEND ${cbootargs} quiet root=/dev/mmcblk0p1 rw rootwait rootfstype=ext4 console=ttyS0,115200n8 console=tty0 fbcon=map:0 net.ifnames=0 isolcpus=1-2 
      FDT /home/ubuntu/tesseract-devicetree.dtb

I copy and overwrite the Image to the TX2 NX.
I reboot the device.

Device tree altering steps

I kept the same "include"s in the new DTSI file (tesseract-devicetree.dts) except the:

#include "common/tegra186-camera-lanai-rbpcv2-imx219.dtsi"
/* plugin manager */
#include "common/tegra186-super-module-e2614-p3509-0000-a00.dtsi"

and I included our sensor file (which doesn’t have any sdhci changes).

I started from default for sdhci node and kept adding/changing/deleting properties. Here are the changes that were used for the generated device tree snippet that I shared in the first comment:

    // WiFi/Bluetooth module
    sdhci@3440000 {
        id = <0>;
        nvidia,is-sdio;
        fixed-clock-freq = <25500000 25500000 24000000 47000000 24000000 47000000 94000000 204000000 0 0 0>;
        max-clk-limit = <204000000>;
        // ddr-clk-limit = <48000000>;
        uhs-mask = <0x60>;
        // ddr-clk-limit = <104000000>;
        /delete-property/ ddr-clk-limit;
        /delete-property/ iommus;

        // enable-sdio-wakeup;
        // cap-sdio-irq;
        only-1-8-v;
        status = "okay";
        nvidia,disable-rtpm;
        force-non-removable-rescan;
        mwifiex: wifi@1 {
            compatible = "marvell,sd8997";
            reg = <1>;
        };
    };

Following the Build/Flash steps procedure I can see on the device my changes in this file.

---

Why your device looks like out of order and missing some properties?

What is it strange about it?

[WayneWWW]

Can you convert your dtb back to dts and attach it as a file here?

[andrei.pata1]

Here is the one from the running device (dtc -i fs /proc/device-tree -O dts -o /tmp/tree -f)
tx2_nx_running_on_device.dts (222.3 KB)

Here is the one just built (Linux_for_Tegra/kernel/dtc -I dtb -O dts build/arch/arm64/boot/dts/tesseract-devicetree.dtb > tesseract-devicetree.dts)
tesseract-devicetree.dts (220.3 KB)

[WayneWWW]

Hi,

So your SDIO is powered with 1.8v but not 3.3v, right?

[andrei.pata1]

We are using 1.8V as seen in the schematic on pin 44.

[martijn.berger]

@WayneWWW

t

Correct we intend to make it run at 1v8

[WayneWWW]

Just in case that we just had another users get wifi working on TX2. You can compare the device tree of both of your side.

CMD CRC error on SDIO interface used for Wifi on Jetson TX2

Hi All, We are using CY4354 wifi bt module on SDIO interface on JEtson TX2. After few hours of doing file transfer through tftp utility we are getting CMD CRC error and the TX2 custom board is rebooting. I am attaching here is the piece of device tree node and error log. DTS Nodes: sdmmc3: sdhci@3440000 { compatible = “nvidia,tegra186-sdhci”; reg = <0x0 0x3440000 0x0 0x210>; interrupts = < 0 64 0x04>; max-clk-limit = <204000000>; ddr-clk-limit = <48000000>; tap-delay = <11>; trim-dela…

[andrei.pata1]

We found the issue. The binary file for the WiFi chip was the incorrect one. No changes were needed for the Device Tree.

Thanks for the support!

[WayneWWW]

You mean the wifi firmware?

[andrei.pata1]

Yes.

[martijn.berger]

https://lkml.org/lkml/2020/5/15/613
Is where we found that Linux is not loading the binary that is present in linux-firmware