Someone Got Our Wifi Chip Working On A Bb

[notaz]

I was curious to see if SPI interface could be attempted instead of SDIO. This is how OMAP3530 muxes the two:

mmc2_clk -> mcspi3_clk
mmc2_cmd -> mcspi3_simo
mmc2_dat0 -> mcspi3_somi
mmc2_dat2 -> mcspi3_cs1
mmc2_dat3 -> mcspi3_cs0

MMC2 is SD2, wifi is connected to MMC3 which has it's signals muxed on ETK_* pins, where SPI configuration is not available.

And I've said it multiple times, this is not SDIO problem! Am I such untrustworthy? I had to write a benchmark which reads/writes module's RAM over SDIO just to prove it to MWeston (which resulted being over 4MiB/s in both directions, BTW).

 

[kloplop321]

I trust you notaz; But like all others here, we would like the wifi to work-- With a free USB port open. Great job so far, wish you the best of luck

 

[Monk]

Am I such untrustworthy?

When things don't work, or aren't where they should be, sometimes you have to look "in the wrong places" for answers. Certainly if you've looked at everything and not found the problem, you need to look closely at even your most basic assumptions.

 

[fusion_power]

It sounds like there are MANY things that are NOT the cause of the slowness. So this looks like there are only a FEW things left, that cause the problem. it's getting tighter and tighter around the "bug" so I think notaz focus more and more to the core of the WiFi problem.
I mean, something has to be the reason, it can't "hide" I think.

 

[Exophase]

MMC2 is SD2, wifi is connected to MMC3 which has it's signals muxed on ETK_* pins, where SPI configuration is not available.

Okay, this differs from what MWeston told me a long time ago then.

And I've said it multiple times, this is not SDIO problem! Am I such untrustworthy? I had to write a benchmark which reads/writes module's RAM over SDIO just to prove it to MWeston (which resulted being over 4MiB/s in both directions, BTW).

It's kind of hard to keep track of exactly what you have and haven't done when there are a few comments scattered through whatever threads, along with things you haven't actually told us yet.

Personally if I had this I'd start trying to do basic basic demos outside of the OS, using the driver as a reference. I don't know how hard it is to actually get that going though, I assume that setting up SDIO and GPIO on OMAP is at least not that bad.

If the transfers to the chip over SDIO are fine and the drivers are fine otherwise then it seems like a hardware issue is a more likely culprit afterall. I guess ED said signal strength was verified and everything..

 

[gp32rich]

If the transfers to the chip over SDIO are fine and the drivers are fine otherwise then it seems like a hardware issue is a more likely culprit afterall. I guess ED said signal strength was verified and everything..

Here's a thought I'm trying not to have

 

[torpor]

notaz: please do not take the investigation of this problem personally. you do not need to defend yourself - we are not attempting to determine if you've done a good job, or not. what these questions are trying to do is determine if the hardware can be fixed with software, or not. its important not to take it personally, really.

my question: what about the alignment issue? are you *positive* - and I mean by double-checking, then triple-checking - that the compile/build of the driver is not screwing up the alignment of the transfer structures?

in my experience with network hardware, if you get packet transfers but some massive amount of them are corrupt/missing/unusable, and there are warnings in the documentation about fragmentation and alignment issues from chip to chip, then going through the alignment strategy with a fine comb, over and over until you really do get it, can often prove extraordinarily fruitful. the reason for alignment/fragmentation on these chipsets is simply because they're designed to not interfere with the cache line further through the pipeline, and the interface is aligned so as to allow larger strategies to cooperate, and so if there is a problem with alignment - one chip is overlaying the others 'zone of reference' - this can cause massive cache line losses, and thus: poor performance. extremely poor performance. so i say its something that must be checked very resolutely.

until some of us get hardware you're on your own notaz, and you are one of the few that can really answer the questions those of us who want to help are asking .. i can assure you that there will no longer be any notaz-offending dump questions as soon as *I* get *my hardware*.

 

[Monk]

notaz: please do not take the investigation of this problem personally. you do not need to defend yourself - we are not attempting to determine if you've done a good job, or not.

Can I reiterate that. AFAIK there's no Notaz-hunt. Look at the forum you're reading - if any offense were meant, even at the mildest level, the way things are said on here the unsult/s would be neon-bright and glowy. Since they aren't, IMHO nothing has been said that is meant in any way to slight you at all. Honest.

There may be more appreciation than you realise, because some of us (myself in particular) are not good at being all warm and cuddly.

 

[Fzero]

yeah and theres appreciation from people like me also who dont have a clue about wifi chips and SDIO [etc..] but are just hopeing that those of you that do know your stuff, like notaz, crack this problamtic issue sooner or later.
We grateful that you even putting in the time and work to investigate things.

thats my only comment in this thread until if/when it is sorted and someone posts "[insert name here] fixed it!"...
...then i will be back with praises and thanks!

till then, keep up the good work battling the machines, blasted wifi chips and SDIO and OMAP and stuff, nothing but grief eh

 

[Dead1nside]

Thanks Notaz. This really must be a Gordian Knot of a problem if you and DJWillis cannot figure it out yet. Makes me even more angry that this guy that just took OP's money and ran.

 

[notaz]

in my experience with network hardware, if you get packet transfers but some massive amount of them are corrupt/missing/unusable, and there are warnings in the documentation about fragmentation and alignment issues from chip to chip, then going through the alignment strategy with a fine comb, over and over until you really do get it, can often prove extraordinarily fruitful. the reason for alignment/fragmentation on these chipsets is simply because they're designed to not interfere with the cache line further through the pipeline, and the interface is aligned so as to allow larger strategies to cooperate, and so if there is a problem with alignment - one chip is overlaying the others 'zone of reference' - this can cause massive cache line losses, and thus: poor performance. extremely poor performance. so i say its something that must be checked very resolutely.

This sounds more like something on-chip firmware is supposed to be taking care of, and we have completely no control of that (unless somebody reverse engineers it). We have tried various firmwares from other wl1251 based devices, and they either work same or don't work at all.

The Nokia driver has alignment handling when transfering memory to/from chip and the fact that it works fine on similar devices makes it hard to believe alignment is at fault.

 

[Gerix]

There has been a lot of hatred aimed at the consultant. If he did anything wrong, I think there would be legal remedies available.

 

[Shock-Socks]

Am I such untrustworthy?

When things don't work, or aren't where they should be, sometimes you have to look "in the wrong places" for answers. Certainly if you've looked at everything and not found the problem, you need to look closely at even your most basic assumptions.

"when you have eliminated the impossible, whatever remains, however improbable, must be the truth."

i think it could also be said that when you have eliminated all possibilities whatever's left is the truth, regardless of how impossible.

(note: that i'm not saying this to imply that you are not doing a good job, i just enjoy good quotes.)

 

[Aninhumer]

There has been a lot of hatred aimed at the consultant. If he did anything wrong, I think there would be legal remedies available.

Indeed.
I somehow doubt he would accept £7000 upfront to spend as much time as necessary to solve an unknown problem.
That's the only situation where he would actually be doing anything wrong by "walking away with the money".

I suspect he was hired for a period of time to work on the WiFi problem, and he didn't manage to fix it in that time.
That's not really his fault, and you can't expect him to keep working without being paid.

 

[Loonie]

Am I such untrustworthy?

All I'm saying is that we've never seen you and Genghis Khan together at the same time. Coincidence?

 

[xyta]

I just googled for some more information, might be interesting for someone...

1.) Jorjin is a Chinese company. Among other things, they combine/integrate several chip designs of other companies into one chip. The Pandora uses their WG7210, which is an integrated combination of a TI WL1251 and some Bluetooth chip.

2.) The successor of the TI WL1251 is the WL1271. Jorjin combines the WL1271 with Bluetooth on an integrated chip called WG7310. Jorjin also offers a driver for their WG7310 for download, which is written for Android and based on the TI WL1271 reference driver.

In theory it should be possible to write a working driver for our WG7210. The WG7310 driver is deduced from the TI 1271 driver. (Perhaps it's more promising trying to deduce a WG7210 driver from the WL1251 driver, considering Jorjin's modifications of the TI WL1271 driver for the WG7310?? - I have no idea...)

There's definitely hope.

3.) We are obvoiusly not alone with that problem. The EMBEST SBC8100 also uses OMAP3 and the WG7210. According to that blog, wifi does not work due to an OMAP multiplexer problem:

OMAP Multiplexer support has a problem, it will cause kernel hangs, so we must disable OMAP_MUX. Due to SBC8100 has Wifi/Bluetooth module which is using MMC2(SDIO) with OMAP Multiplexer, the module doesn't work right now.

(OMAP Multiplexing)
So there's also another device using OMAP3 and WG7210 with a wifi problem.

4.) According to the Jorjin support site the driver for WG7210 and OMAP3 is being developed and not ready (!)

Conclusions:

A) I can't really understand why TI recommended that WG7210 chip to the Pandora team for use with OMAP3 although there semms to be no working driver yet. :rolleyes:

B) Other projects are also affected by this issue, so there's hope that someone will find a solution some day.

C) I can totally understand notaz' frustration and despairation. He has been coding for weeks, everything should work great, but for some jinxed reason it just doesn't...

 

[notaz]

2.) The successor of the TI WL1251 is the WL1271. Jorjin combines the WL1271 with Bluetooth on an integrated chip called WG7310. Jorjin also offers a driver for their WG7310 for download, which is written for Android and based on the TI WL1271 reference driver.

In theory it should be possible to write a working driver for our WG7210. The WG7310 driver is deduced from the TI 1271 driver. (Perhaps it's more promising trying to deduce a WG7210 driver from the WL1251 driver, considering Jorjin's modifications of the TI WL1271 driver for the WG7310?? - I have no idea...)

They did provide a driver though which is mostly the same as TI one that was opened with Android. It exhibits the same problem.

3.) We are obvoiusly not alone with that problem. The EMBEST SBC8100 also uses OMAP3 and the WG7210. According to that blog, wifi does not work due to an OMAP multiplexer problem:

OMAP Multiplexer support has a problem, it will cause kernel hangs, so we must disable OMAP_MUX. Due to SBC8100 has Wifi/Bluetooth module which is using MMC2(SDIO) with OMAP Multiplexer, the module doesn't work right now.

(OMAP Multiplexing)
So there's also another device using OMAP3 and WG7210 with a wifi problem.

This is not related, we don't even use kernel mux. And the module is working for us but it's too slow.

 

[xyta]

Hi notaz,

I just found another possible example for a device with OMAP3/WG7210 problems in Linux:

It's the Witstech A81:
http://www.witstech.com.cn/product_en.html

According to kathy of witstech, they also use the WG7210:
http://www.mobileread.com/forums/showthread.php?t=62570&page=3
(post #41)

The standard OS of that device is WinCE and obviously they got all hardware working there.

When you browse through the witstech forums with google language tools, you'll find the information that they are planning to adapt Android for the A81. They did already publish some betas of their adapted Android. And they got almost all the hardware working.

Exceptions: Sound, wifi and bluetooth! :rolleyes:

Originally they planned to release a full functional Android for their A81 at the end of March, but they haven't done it yet... So I assume that they also have problems with that damn WG7210... (but it's only an assumption)

 

[ben_dash]

Is this SBC, the SBC8100, not near identical hardware to the Pandora and claiming support for WiFi and BT using the WG7210 with an OMAP3530:

http://www.armkits.com/Product/sbc8100.asp

Are they lying, quite possible, or am I reading the spec incorrectly, also quite possible, or are they not doing SDIO?

Or did they actually get it to work?

 

[JayFoxRox]

Is this SBC, the SBC8100, not near identical hardware to the Pandora and claiming support for WiFi and BT using the WG7210 with an OMAP3530:

http://www.armkits.com/Product/sbc8100.asp

Are they lying, quite possible, or am I reading the spec incorrectly, also quite possible, or are they not doing SDIO?

Or did they actually get it to work?

3.) We are obvoiusly not alone with that problem. The EMBEST SBC8100 also uses OMAP3 and the WG7210. According to that blog, wifi does not work due to an OMAP multiplexer problem:

OMAP Multiplexer support has a problem, it will cause kernel hangs, so we must disable OMAP_MUX. Due to SBC8100 has Wifi/Bluetooth module which is using MMC2(SDIO) with OMAP Multiplexer, the module doesn't work right now.

(OMAP Multiplexing)
So there's also another device using OMAP3 and WG7210 with a wifi problem.

This is not related, we don't even use kernel mux. And the module is working for us but it's too slow.