mwifiex_sdio on chromebook

mwifiex_sdio on chromebook

[Alexander Varnin]

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?

RE: mwifiex_sdio on chromebook

[Bing Zhao]

CC: linux-mmc

Hi Alexander,

> 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.

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

> 
> 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.

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

> 
> 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.

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

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

CONFIG_MMC_DEBUG=y, and collect the debug logs.

Regards,
Bing

RE: mwifiex_sdio on chromebook

[Bing Zhao]

Q0M6IGxpbnV4LW1tYw0KDQpIaSBBbGV4YW5kZXIsDQoNCj4gSGVsbG8uDQo+IEkgYW0gdHJ5aW5n
IHRvIGRlYnVnIHRoZSBpc3N1ZSB3aXRoIGluY29ycmVjdCBpbml0aWFsaXphdGlvbiBvZiBXaUZp
IGNoaXAgb24NCj4gU2Ftc3VuZyBBUk0gQ2hyb21lYm9vay4gQW5kIEkgc2VhcmNoIGZvciBhc3Np
c3RhbmNlLiBJIGhhdmUgcG9zdGVkIG15DQo+IGludmVzdGlnYXRpb24gcmVzdWx0cyBvbiBsYXVu
Y2hwYWQubmV0IChidWcgIzEyNDc1MTIpLiBIZXJlIGlzDQo+IGNvcHk6DQo+IA0KPiBNYXJ2ZWxs
IFNESU8gV2lGaSBjaGlwIGRvZXNuJ3QgZ2V0IGluaXRpYWxpemVkIGNvcnJlY3RseSBvbiBDaHJv
bWVib29rLg0KPiBBZnRlciBzb21lIHJlc2VhcmNoIEkgaGF2ZSBtYW5hZ2VkIHRvIGZpbmQgdGhh
dCB3aGVuIExpbnV4IGlzIGRvaW5nDQo+IGluaXRpYWxpemF0aW9uLCBpdCB0cmllcyBzZXR0aW5n
IGNsb2NrIGFuZCBwb3dlciB0byBTRElPIGNvbnRyb2xsZXIgZm9yIHRoYXQgY2hpcC4gSXQNCj4g
aXMgdHJ5aW5nIGZyZXF1ZW5jZXMgaGFyZGNvZGVkIGluDQo+IGxpbnV4L2RyaXZlcnMvbW1jL2Nv
cmUvY29yZS5jOiA0MDAwMDAsIDMwMDAwMCwgMjAwMDAwLCAxMDAwMDAgSHouDQo+IE9wcG9zZWQg
dG8gdGhhdCwgY2hyb21lIG9zIGtlcm5lbCB0cmllcyBvdGhlciBmcmVxdWVuY2VzOiA3ODQzMTRI
eiBhbmQNCj4gNTAwMDAwMDBIei4gVGhlIGxhc3QgaXMgc3RheWluZyBhcyB3b3JraW5nIGZyZXF1
ZW5jeS4gSSBkb24ndCBrbm93LCBpZiBpdCBpcw0KPiBtYXR0ZXIgZm9yIGNhcmQgd2hhdCBmcmVx
dWVuY3kgZG9lcyB0aGUgaG9zdCB0cmllcyB0byBnYXRlLg0KDQpZb3VyIENocm9tZWJvb2sgc3Vw
cG9ydHMgU0RJTyBoaWdoIHNwZWVkIG1vZGUgKFNESU8gMi4wIHNwZWMpLiBTbyA1ME1IeiBpcyBj
b3JyZWN0Lg0KDQo+IA0KPiBXaGVuIG1haW5saW5lIGtlcm5lbCBydW5zIG1tY19hdHRhY2hfc2Rp
byBmdW5jdGlvbiBpdCBzaG91bGQgZ2V0IGNvcnJlY3QNCj4gYW5zd2VyIGZyb20gY2FyZCBhbmQg
c28gcHJvY2VzcyBjYXJkIGFzIFNESU8uIEhvd2V2ZXIgaXQgZmFpbHMgd2l0aCB0aW1lb3V0DQo+
IGluIHRoYXQgZnVuY3Rpb24uDQoNCldoYXQgYXJlIHlvdSB0cnlpbmcgdG8gZG8gaGVyZT8gQXJl
IHlvdSB0cnlpbmcgdG8gcnVuIGEgbWFpbmxpbmUga2VybmVsIG9uIHlvdXIgQ2hyb21lYm9vaz8N
Cg0KPiANCj4gSSB3b25kZXIgaWYgdGhpcyBkZXBlbmRzIG9uIGZpcm13YXJlIGxvYWRpbmcuIEkg
c2VlLCB0aGF0IGNocm9tZSBvcyAzLjQNCj4ga2VybmVsIHJlcXVpcmVzIGZpcm13YXJlLiBBbmQg
bWFpbmxpbmUgaXMgcHJvYmFibHkgc2ltcGx5IGRvZXNuJ3QgbG9hZCBpdCBieQ0KPiBkZWZhdWx0
LiBDdXJyZW50bHksIEkgZG9uJ3Qga25vdyBob3cgdG8gY2hlY2sgaXQgYW5kIGhvdyB0byBjb25m
aWd1cmUga2VybmVsDQo+IHRvIGxvYWQgZmlybXdhcmUgZm9yIG13aWZpZXhfc2Rpby4NCg0KWW91
IHNhaWQgbW1jX2F0dGFjaF9zZGlvIGZ1bmN0aW9uIGZhaWxzLiBUaGUgbXdpZmlleF9zZGlvIGRy
aXZlciBhbmQgdGhlIGZpcm13YXJlIHdpbGwgbm90IGJlIGxvYWRlZCBhdCBhbGwuDQoNCj4gDQo+
IEkgYW0gcmVhZHkgdG8gZG8gZnVydGhlciByZXNlYXJjaCwgYnV0IEkgbmVlZCBzb21lIGFzc2lz
dGFuY2UuDQoNCkNPTkZJR19NTUNfREVCVUc9eSwgYW5kIGNvbGxlY3QgdGhlIGRlYnVnIGxvZ3Mu
DQoNClJlZ2FyZHMsDQpCaW5nDQo=

Re: mwifiex_sdio on chromebook

[Alexander Varnin]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

04.11.2013 02:10, Bing Zhao пишет:
> Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So
> 50MHz is correct.

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

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

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.

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

Ok, that is clear.

> CONFIG_MMC_DEBUG=y, and collect the debug logs.  

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?

[-- Attachment #2: dirty-hack.diff --]
[-- Type: text/x-patch, Size: 2948 bytes --]

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index bf18b6b..c4a2b22 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -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);
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 80d89cff..0773be2 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -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...
 	 */
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 018f365..342b0c4 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -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)
diff --git a/drivers/net/wireless/mwifiex/Makefile b/drivers/net/wireless/mwifiex/Makefile
index a42a506..145f376 100644
--- a/drivers/net/wireless/mwifiex/Makefile
+++ b/drivers/net/wireless/mwifiex/Makefile
@@ -14,7 +14,10 @@
 # ARE EXPRESSLY DISCLAIMED.  The License provides additional details about
 # this warranty disclaimer.
 

Re: mwifiex_sdio on chromebook

[Alexander Varnin]

[-- Attachment #1: Type: text/plain, Size: 1032 bytes --]

04.11.2013 02:10, Bing Zhao пишет:
> Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So
> 50MHz is correct.

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

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

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.

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

Ok, that is clear.

> CONFIG_MMC_DEBUG=y, and collect the debug logs.  

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?

[-- Attachment #2: dirty-hack.diff --]
[-- Type: text/x-patch, Size: 3123 bytes --]

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index bf18b6b..c4a2b22 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -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);
diff --git a/drivers/mmc/core/sdio.c b/drivers/mmc/core/sdio.c
index 80d89cff..0773be2 100644
--- a/drivers/mmc/core/sdio.c
+++ b/drivers/mmc/core/sdio.c
@@ -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...
 	 */
diff --git a/drivers/mmc/host/dw_mmc.c b/drivers/mmc/host/dw_mmc.c
index 018f365..342b0c4 100644
--- a/drivers/mmc/host/dw_mmc.c
+++ b/drivers/mmc/host/dw_mmc.c
@@ -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)
diff --git a/drivers/net/wireless/mwifiex/Makefile b/drivers/net/wireless/mwifiex/Makefile
index a42a506..145f376 100644
--- a/drivers/net/wireless/mwifiex/Makefile
+++ b/drivers/net/wireless/mwifiex/Makefile
@@ -14,7 +14,10 @@
 # ARE EXPRESSLY DISCLAIMED.  The License provides additional details about
 # this warranty disclaimer.
 
-
+CFLAGS_main.o := -DDEBUG
+CFLAGS_sdio.o := -DDEBUG
+CFLAGS_sta_cmdresp.o := -DDEBUG
+CFLAGS_wmm.o := -DDEBUG
 mwifiex-y += main.o
 mwifiex-y += init.o
 mwifiex-y += cfp.o

Re: mwifiex_sdio on chromebook

[Luis R. Rodriguez]

On Mon, Nov 4, 2013 at 3:18 AM, Alexander Varnin <fenixk19@mail.ru> wrote:
>> What are you trying to do here? Are you trying to run a mainline kernel on your Chromebook?
>
> 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.

WTF.

  Luis

RE: mwifiex_sdio on chromebook

[Bing Zhao]

Hi Alexander,

> > Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So
> > 50MHz is correct.
> 
> Ok, but mainline kernel doesn't try this frequency. It tries 400kHz at
> most.
> 
> > What are you trying to do here? Are you trying to run a mainline kernel on your Chromebook?
> 
> 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.

I don't know why you want to do that, but the mainline kernel won't work on your Chromebook unless you port all platform specific changes over from chromeos-3.4 tree.

> 
> > You said mmc_attach_sdio function fails. The mwifiex_sdio driver and
> > the firmware will not be loaded at all.
> 
> Ok, that is clear.
> 
> > CONFIG_MMC_DEBUG=y, and collect the debug logs.
> 
> 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?

As said above, this won’t work because the Chromebook specific changes aren't present in mainline kernel. Anyway you can take a look at the chromium OS developer guide.

http://www.chromium.org/chromium-os/developer-guide

Thanks,
Bing

RE: mwifiex_sdio on chromebook

[Bing Zhao]

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==

Re: mwifiex_sdio on chromebook

[Alexander Varnin]

04.11.2013 23:46, Bing Zhao пишет:
> Hi Alexander,
>
>>> Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So
>>> 50MHz is correct.
>> Ok, but mainline kernel doesn't try this frequency. It tries 400kHz at
>> most.
>>
>>> What are you trying to do here? Are you trying to run a mainline kernel on your Chromebook?
>> 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.
> I don't know why you want to do that, but the mainline kernel won't work on your Chromebook unless you port all platform specific changes over from chromeos-3.4 tree.
>
>>> You said mmc_attach_sdio function fails. The mwifiex_sdio driver and
>>> the firmware will not be loaded at all.
>> Ok, that is clear.
>>
>>> CONFIG_MMC_DEBUG=y, and collect the debug logs.
>> 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?
> As said above, this won’t work because the Chromebook specific changes aren't present in mainline kernel. Anyway you can take a look at the chromium OS developer guide.
>
> http://www.chromium.org/chromium-os/developer-guide
>
> Thanks,
> Bing
>

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex_sdio on chromebook

[Alexander Varnin]

04.11.2013 23:46, Bing Zhao пишет:
> Hi Alexander,
>
>>> Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So
>>> 50MHz is correct.
>> Ok, but mainline kernel doesn't try this frequency. It tries 400kHz at
>> most.
>>
>>> What are you trying to do here? Are you trying to run a mainline kernel on your Chromebook?
>> 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.
> I don't know why you want to do that, but the mainline kernel won't work on your Chromebook unless you port all platform specific changes over from chromeos-3.4 tree.
>
>>> You said mmc_attach_sdio function fails. The mwifiex_sdio driver and
>>> the firmware will not be loaded at all.
>> Ok, that is clear.
>>
>>> CONFIG_MMC_DEBUG=y, and collect the debug logs.
>> 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?
> As said above, this won’t work because the Chromebook specific changes aren't present in mainline kernel. Anyway you can take a look at the chromium OS developer guide.
>
> http://www.chromium.org/chromium-os/developer-guide
>
> Thanks,
> Bing
>

It is ported at most already and mainline kernel works good on
Chromebook. It is just peripheral problem.

Re: mwifiex_sdio on chromebook

[Arend van Spriel]

On 11/05/2013 09:38 AM, Alexander Varnin wrote:
> 04.11.2013 23:46, Bing Zhao пишет:
>> Hi Alexander,
>>
>>>> Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So
>>>> 50MHz is correct.
>>> Ok, but mainline kernel doesn't try this frequency. It tries 400kHz at
>>> most.
>>>
>>>> What are you trying to do here? Are you trying to run a mainline kernel on your Chromebook?
>>> 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.
>> I don't know why you want to do that, but the mainline kernel won't work on your Chromebook unless you port all platform specific changes over from chromeos-3.4 tree.
>>
>>>> You said mmc_attach_sdio function fails. The mwifiex_sdio driver and
>>>> the firmware will not be loaded at all.
>>> Ok, that is clear.
>>>
>>>> CONFIG_MMC_DEBUG=y, and collect the debug logs.
>>> 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?
>> As said above, this won’t work because the Chromebook specific changes aren't present in mainline kernel. Anyway you can take a look at the chromium OS developer guide.
>>
>> http://www.chromium.org/chromium-os/developer-guide
>>
>> Thanks,
>> Bing
>>
>
> It is ported at most already and mainline kernel works good on
> Chromebook. It is just peripheral problem.

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>


--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex_sdio on chromebook

[Arend van Spriel]

On 11/05/2013 09:38 AM, Alexander Varnin wrote:
> 04.11.2013 23:46, Bing Zhao пишет:
>> Hi Alexander,
>>
>>>> Your Chromebook supports SDIO high speed mode (SDIO 2.0 spec). So
>>>> 50MHz is correct.
>>> Ok, but mainline kernel doesn't try this frequency. It tries 400kHz at
>>> most.
>>>
>>>> What are you trying to do here? Are you trying to run a mainline kernel on your Chromebook?
>>> 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.
>> I don't know why you want to do that, but the mainline kernel won't work on your Chromebook unless you port all platform specific changes over from chromeos-3.4 tree.
>>
>>>> You said mmc_attach_sdio function fails. The mwifiex_sdio driver and
>>>> the firmware will not be loaded at all.
>>> Ok, that is clear.
>>>
>>>> CONFIG_MMC_DEBUG=y, and collect the debug logs.
>>> 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?
>> As said above, this won’t work because the Chromebook specific changes aren't present in mainline kernel. Anyway you can take a look at the chromium OS developer guide.
>>
>> http://www.chromium.org/chromium-os/developer-guide
>>
>> Thanks,
>> Bing
>>
>
> It is ported at most already and mainline kernel works good on
> Chromebook. It is just peripheral problem.

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>

Re: mwifiex_sdio on chromebook

[Alexander Varnin]

05.11.2013 12:53, Arend van Spriel пишет:
>>>
>>
>> It is ported at most already and mainline kernel works good on
>> Chromebook. It is just peripheral problem.
>
> 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? 

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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex_sdio on chromebook

[Alexander Varnin]

05.11.2013 12:53, Arend van Spriel пишет:
>>>
>>
>> It is ported at most already and mainline kernel works good on
>> Chromebook. It is just peripheral problem.
>
> 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? 

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.

Re: mwifiex_sdio on chromebook

[Paul Stewart]

On Tue, Nov 5, 2013 at 1:12 AM, Alexander Varnin <fenixk19-JGs/UdohzUI@public.gmane.org> wrote:
> 05.11.2013 12:53, Arend van Spriel пишет:
>>>>
>>>
>>> It is ported at most already and mainline kernel works good on
>>> Chromebook. It is just peripheral problem.
>>
>> 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?
>
> 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.

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

> 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 majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: mwifiex_sdio on chromebook

[Paul Stewart]

On Tue, Nov 5, 2013 at 1:12 AM, Alexander Varnin <fenixk19@mail.ru> wrote:
> 05.11.2013 12:53, Arend van Spriel пишет:
>>>>
>>>
>>> It is ported at most already and mainline kernel works good on
>>> Chromebook. It is just peripheral problem.
>>
>> 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?
>
> 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.

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

> 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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html