mwifiex_sdio on chromebook

Hello.
I am trying to debug the issue with incorrect initialization of WiFi chip on Samsung ARM Chromebook. And I search for assistance. I have posted my investigation results on launchpad.net (bug #1247512). Here is copy:

Marvell SDIO WiFi chip doesn't get initialized correctly on Chromebook. After some research I have managed to find that when Linux is doing initialization, it tries setting clock and power to SDIO controller for that chip. It is trying frequences hardcoded in linux/drivers/mmc/core/core.c: 400000, 300000, 200000, 100000 Hz. Opposed to that, chrome os kernel tries other frequences: 784314Hz and 50000000Hz. The last is staying as working frequency. I don't know, if it is matter for card what frequency does the host tries to gate.

When mainline kernel runs mmc_attach_sdio function it should get correct answer from card and so process card as SDIO. However it fails with timeout in that function.

I wonder if this depends on firmware loading. I see, that chrome os 3.4 kernel requires firmware. And mainline is probably simply doesn't load it by default. Currently, I don't know how to check it and how to configure kernel to load firmware for mwifiex_sdio.

I am ready to do further research, but I need some assistance.

Is there any manual on marvell chip?

Hi Alexander,

Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So 50MHz is correct.

What are you trying to do here? Are you trying to run a mainline kernel on your Chromebook?

You said mmc_attach_sdio function fails. The mwifiex_sdio driver and the firmware will not be loaded at all.

CONFIG_MMC_DEBUG=y, and collect the debug logs.

Regards,
Bing

04.11.2013 02:10, Bing Zhao пишет:

Ok, but mainline kernel doesn't try this frequency. It tries 400kHz at most.

Yes. I've got kernel 3.4 from Google Chrome OS. It works ok for mwifiex_sdio. But I want to run mainline kernel. As of 3.11 it is able to boot on Chromebook, but WiFi doesn't work.

Ok, that is clear.

This way seems not very useful, because there is also internal and external storage on mmc bus, so log quickly get garbaged with it. Dmesg seems to be overflowed and forgets early initialization. I have made a dirty hack to collect some useful info about initialization. I am attaching it. Please check, if I need to add something. Will it be useful this way?

index bf18b6b..c4a2b22 100644
@@ -1001,12 +1001,16 @@ EXPORT_SYMBOL(mmc_put_card);
 static inline void mmc_set_ios(struct mmc_host *host)
 {
 	struct mmc_ios *ios = &host->ios;
-
-	pr_debug("%s: clock %uHz busmode %u powermode %u cs %u Vdd %u "
+	
+	if(((char*)mmc_hostname(host))[3]=='2') {
+	  printk("%s: clock %uHz busmode %u powermode %u cs %u Vdd %u "
 		"width %u timing %u\n",
 		 mmc_hostname(host), ios->clock, ios->bus_mode,
 		 ios->power_mode, ios->chip_select, ios->vdd,
 		 ios->bus_width, ios->timing);
+	
+	  dump_stack();
+	}
 
 	if (ios->clock > 0)
 		mmc_set_ungated(host);

index 80d89cff..0773be2 100644
@@ -1133,11 +1133,14 @@ int mmc_attach_sdio(struct mmc_host *host)
 	int err, i, funcs;
 	u32 ocr;
 	struct mmc_card *card;
+	
+	printk("mmc_attach_sdio 1\n");
 
 	BUG_ON(!host);
 	WARN_ON(!host->claimed);
 
 	err = mmc_send_io_op_cond(host, 0, &ocr);
+	printk("mmc_attach_sdio err %d\n", err);
 	if (err)
 		return err;
 

@@ -1166,6 +1169,8 @@ int mmc_attach_sdio(struct mmc_host *host)
 		goto err;
 	}
 
+	printk("mmc_attach_sdio 2\n");
+	
 	/*
 	 * Detect and init the card.
 	 */

@@ -1182,11 +1187,13 @@ int mmc_attach_sdio(struct mmc_host *host)
 			host->ocr &= ~R4_18V_PRESENT;
 			err = mmc_sdio_init_card(host, host->ocr, NULL, 0);
 		}
+		printk("mmc_attach_sdio 3 err %d\n", err);
 		if (err)
 			goto err;
 	}
 	card = host->card;
 
+	printk("mmc_attach_sdio 4\n");
 	/*
 	 * Enable runtime PM only if supported by host+card+board
 	 */

@@ -1195,6 +1202,7 @@ int mmc_attach_sdio(struct mmc_host *host)
 		 * Let runtime PM core know our card is active
 		 */
 		err = pm_runtime_set_active(&card->dev);
+		printk("mmc_attach_sdio 5 err %d\n", err);
 		if (err)
 			goto remove;
 

@@ -1226,6 +1234,7 @@ int mmc_attach_sdio(struct mmc_host *host)
 			pm_runtime_enable(&card->sdio_func[i]->dev);
 	}
 
+	printk("mmc_attach_sdio 6\n");
 	/*
 	 * First add the card to the driver model...
 	 */

index 018f365..342b0c4 100644
@@ -1917,6 +1917,7 @@ static int dw_mci_init_slot(struct dw_mci *host, unsigned int id)
 
 	mmc->ops = &dw_mci_ops;
 	mmc->f_min = DIV_ROUND_UP(host->bus_hz, 510);
+	printk("f_min = %u;  %d", mmc->f_min, host->bus_hz);
 	mmc->f_max = host->bus_hz;
 
 	if (host->pdata->get_ocr)

index a42a506..145f376 100644
@@ -14,7 +14,10 @@
 # ARE EXPRESSLY DISCLAIMED.  The License provides additional details about
 # this warranty disclaimer.
 

WTF.

Luis

SGkgQWxleGFuZGVyLA0KDQo+ID4gWW91ciBDaHJvbWVib29rIHN1cHBvcnRzIFNESU8gaGlnaCBz cGVlZCBtb2RlIChTRElPIDIuMCBzcGVjKS4gU28NCj4gPiA1ME1IeiBpcyBjb3JyZWN0Lg0KPiAN Cj4gT2ssIGJ1dCBtYWlubGluZSBrZXJuZWwgZG9lc24ndCB0cnkgdGhpcyBmcmVxdWVuY3kuIEl0 IHRyaWVzIDQwMGtIeiBhdA0KPiBtb3N0Lg0KPiANCj4gPiBXaGF0IGFyZSB5b3UgdHJ5aW5nIHRv IGRvIGhlcmU/IEFyZSB5b3UgdHJ5aW5nIHRvIHJ1biBhIG1haW5saW5lIGtlcm5lbCBvbiB5b3Vy IENocm9tZWJvb2s/DQo+IA0KPiBZZXMuIEkndmUgZ290IGtlcm5lbCAzLjQgZnJvbSBHb29nbGUg Q2hyb21lIE9TLiBJdCB3b3JrcyBvayBmb3INCj4gbXdpZmlleF9zZGlvLiBCdXQgSSB3YW50IHRv IHJ1biBtYWlubGluZSBrZXJuZWwuIEFzIG9mIDMuMTEgaXQgaXMgYWJsZQ0KPiB0byBib290IG9u IENocm9tZWJvb2ssIGJ1dCBXaUZpIGRvZXNuJ3Qgd29yay4NCg0KSSBkb24ndCBrbm93IHdoeSB5 b3Ugd2FudCB0byBkbyB0aGF0LCBidXQgdGhlIG1haW5saW5lIGtlcm5lbCB3b24ndCB3b3JrIG9u IHlvdXIgQ2hyb21lYm9vayB1bmxlc3MgeW91IHBvcnQgYWxsIHBsYXRmb3JtIHNwZWNpZmljIGNo YW5nZXMgb3ZlciBmcm9tIGNocm9tZW9zLTMuNCB0cmVlLg0KDQo+IA0KPiA+IFlvdSBzYWlkIG1t Y19hdHRhY2hfc2RpbyBmdW5jdGlvbiBmYWlscy4gVGhlIG13aWZpZXhfc2RpbyBkcml2ZXIgYW5k DQo+ID4gdGhlIGZpcm13YXJlIHdpbGwgbm90IGJlIGxvYWRlZCBhdCBhbGwuDQo+IA0KPiBPaywg dGhhdCBpcyBjbGVhci4NCj4gDQo+ID4gQ09ORklHX01NQ19ERUJVRz15LCBhbmQgY29sbGVjdCB0 aGUgZGVidWcgbG9ncy4NCj4gDQo+IFRoaXMgd2F5IHNlZW1zIG5vdCB2ZXJ5IHVzZWZ1bCwgYmVj YXVzZSB0aGVyZSBpcyBhbHNvIGludGVybmFsIGFuZA0KPiBleHRlcm5hbCBzdG9yYWdlIG9uIG1t YyBidXMsIHNvIGxvZyBxdWlja2x5IGdldCBnYXJiYWdlZCB3aXRoIGl0LiBEbWVzZw0KPiBzZWVt cyB0byBiZSBvdmVyZmxvd2VkIGFuZCBmb3JnZXRzIGVhcmx5IGluaXRpYWxpemF0aW9uLiBJIGhh dmUgbWFkZSBhDQo+IGRpcnR5IGhhY2sgdG8gY29sbGVjdCBzb21lIHVzZWZ1bCBpbmZvIGFib3V0 IGluaXRpYWxpemF0aW9uLiBJIGFtDQo+IGF0dGFjaGluZyBpdC4gUGxlYXNlIGNoZWNrLCBpZiBJ IG5lZWQgdG8gYWRkIHNvbWV0aGluZy4gV2lsbCBpdCBiZQ0KPiB1c2VmdWwgdGhpcyB3YXk/DQoN CkFzIHNhaWQgYWJvdmUsIHRoaXMgd29u4oCZdCB3b3JrIGJlY2F1c2UgdGhlIENocm9tZWJvb2sg c3BlY2lmaWMgY2hhbmdlcyBhcmVuJ3QgcHJlc2VudCBpbiBtYWlubGluZSBrZXJuZWwuIEFueXdh eSB5b3UgY2FuIHRha2UgYSBsb29rIGF0IHRoZSBjaHJvbWl1bSBPUyBkZXZlbG9wZXIgZ3VpZGUu DQoNCmh0dHA6Ly93d3cuY2hyb21pdW0ub3JnL2Nocm9taXVtLW9zL2RldmVsb3Blci1ndWlkZQ0K DQpUaGFua3MsDQpCaW5nDQoNCg==
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

04.11.2013 23:46, Bing Zhao пишет:

It is ported at most already and mainline kernel works good on Chromebook. It is just peripheral problem.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

Not sure how chromium os architecture looks like, but you mean to say *you* ported code in chromium user-space to work with upstream/mainline kernel API's?

Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

05.11.2013 12:53, Arend van Spriel пишет:

No. There is work doing by somebody from google or somewhere else, by making mainline kernel work on Chromebook. Kernel 3.11 is the first mainline kernel, that is able to boot and work on Chromebook. Working parts is MMC controller, display controller, keyboard, etc. Not working is usb, wifi, rtc, temperature sensors, etc.

By a tradition of open source, as I am interested, and I have experience in kernel development, I have decided to debug wifi issue by myself. I don't know, why I should port anything. Everything that was needed is already ported - there is Chromebook device tree in kernel, there is all required drivers. There is just a problem with powering up Marvell wifi chip. I don't see, why fixing it requires any complex porting.

One thing worth doing is to compare 3.4 from chromeos and 3.4 mainline, and find, if there any specific wifi changes. But there is possibly not. --
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html

There doesn't appear a lot of effort into getting 3.11 working on the Samsung ChromeBook yet. There is some work on 3.8, which has more architectural similarities to 3.11. Offhand, the 3.4 version used a "regulator" setup for controlling the GPIOs that performed power sequencing and setup of the part, where as in 3.8 this work was moved to the device tree.

Therefore, for more insights into the changes you may have to do for 3.11, I'd suggest that it'd be more informative for you to look at the differences between mainline 3.8 and the "chromeos-3.8" branch of
https://chromium.googlesource.com/chromiumos/third_party/kernel-next

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html