Brainstorming Wifi !!!

[gino3.2.84]

Ich hab jetzt immer mal wider ideen hier gelesen woran es liegen kann das wifi nicht so klappt wie es soll, deswegen wollt ich hier einfach mal ein thema eröffnen, in welchem alle die ein wenig ahnung haben, oder einfach nur eine gute idee, dass sie dies hier kund tun.
Also ran an die tasten !!!

 

[gino3.2.84]

hab mal ein wenig gegooglet und evtl. was interessantes gefunden, ob es uns weiter hilft überlasse ich aber denen die es wirklich verstehen das ist mir alles zu hoch
http://permalink.gmane.org/gmane.comp.hardware.beagleboard.user/1952

 

[xyta]

Also der aktuelle Zwischenstand von ED war ja, soweit ich mich erinnere:

-Empfangsgeschwindigkeit mit Pandora-GIT: 7 kB/s
-Empfangsgeschwindigkeit mit abgespecktem Spezial-OS, was nicht viel mehr als WLAN und Bildschirmausgabe kann: 45 kB/s
-Sendegeschwindigkeit (Spezial-OS??): 300+ kB/s
-Die Datenverbindung zwischen OMAP und Chip scheint auf den ersten Blick OK zu sein, es lässt sich z.B. die Firmware des Chips fehlerfrei laden.


Sieht für mich stark nach einem Softwareproblem aus. ??

Ich frage mich z.B. ob man schon die Ursache weiss, warum das Pandora-GIT im Prinzip nochmal fast 40kB/s an Bandbreite (gegenüber der W-LAN-Testinstallation) "vernichtet"...

 

[morq]

gino3.2.84, das was du gefunden hast ergibt irgendwie Sinn^^

Also wenn der Treiber keine SDIO Interrupts nutzt sondern alles über Polling macht würde das erklären wieso das ganz bei einem Minimalkernel viel schneller läuft. Ich denke mal, das das Senden davon nicht betroffen ist ergibt auch sinn, denn da würde man eh keine SDIO Interrupts brauchen.
Ware natürlich ziemlicher zufall wenn Notaz und Co das noch nicht gefunden hätten, aber die erklärung macht durchaus Sinn und wäre ein eindeutiges Softwareproblem!

Sollte vll mal jemand weiterleiten, wäre schön wenn das die lösung ist.

 

[Letalis Sonus]

Das Thema wird auf dem englischen Board bereits hitzig diskutiert, die Idee wurde schon vor langem geäußert.
Die SDIO Interrupts werden bereits hardwareseitig umgangen, und zwar über GPIO, dazu ein Kommentar von notaz:

Forgot to stress it's SDIO interrupt support that has problems on OMAPs, not the SDIO stack itself. This has been shown to be the cause of slowness of wifi chip on Overo boards. However we have an option not to use SDIO interrupt at all as we have GPIO connected directly to wifi chip's IRQ line and can use that instead.
Unfortunately it doesn't help our case either.

 

[morq]

schade, wäre eine plausieble Erklärung gewesen.

 

[xyta]

Kann mir das jemand mal genauer erklären?

Der Unterschied zu vielen anderen Produkten war bei der Pandora angeblich ja, dass Wifi über SDIO und nicht GPIO angebunden ist. Und zwar, weil TI das in ihren Specs so empfiehlt . Soweit, so gut...

SDIO, so dachte ich bisher, wäre ein zu SD-Karten kompatibler Anschluss, bei dem man über eine Erweiterung des SD-Karten-Protokolls eben auch andere Geräte wie GPS oder WLAN anbinden kann. Ursprünglich für Erweiterungskarten für den SD-Slot gedacht, wird das offenbar inzwischen auch verwendet, um interne Peripherie anzubinden. Hab ich das soweit richtig verstanden?

GPIO ist das hier:
http://en.wikipedia.org/wiki/General_Purpose_Input/Output
Irgendwelche 8 Pins, welche sich relativ frei programmieren lassen.

MWeston hat sich also dafür entschieden, WLAN über SDIO anzubinden, weil TI das so als Standard vorsieht. Der Wifi-Chip scheint grundsätzlich beide Schnittstellen zu haben?! Jetzt scheint es aber einen generellen Bug beim OMAP zu geben, dass Interrupts über SDIO nicht funktionieren.

Interrupts sind dafür da, dass ein Peripheriegerät dem Prozessor sagt, dass es neue Daten hat. Das Gerät aktiviert dazu eine Meldeleitung. Der Prozessor unterbricht seine bisherige Arbeit, behandelt die Daten, und kehrt dann zu seinen anderen Aufgaben zurück.

Demgegenüber steht das Polling. Hier gibt es keine Meldeleitung. In einer Programm- oder Betriebssystemschleife werden die entsprechenden Eingangsports einfach immer wieder abgefragt. Das ist natürlich weniger Effizient, und wenn in der Programmschleife andere schwierigerer Code steht, wird der Port einfach seltener abgefragt. Ein klassisches Polling-Beispiel ist der Standard-PC-Gameport. Der läuft über Port 201h, der vom Spiel ständig abgefragt wird.

Jetzt hat der OMAP also einen bekannten Hardwarefehler, bei dem SDIO-Geräte über diese Schnittstelle keinen Interrupt auslösen können. Das heißt, der W-LAN-Chip kann sich über SDIO nicht melden, wenn ein neues Paket eingetroffen ist.

Die Lösung von MWeston war wohl, parallel zur SDIO-Anbindung die Interruptleitung über GPIO zu realisieren.

Wenn ich das richtig verstanden hab ist das so ähnlich, wie wenn ich eine externe Festplatte habe, die Firewire und USB kann. Der Hersteller empfiehlt den Betrieb über USB. Jetzt kann mein PC aber nicht genug Strom über USB für die Festplatte liefern. Also sorge ich dafür, dass die Platte Strom über die Firewireschnittstelle bekommt und wickle den Datentransfer weiter über USB ab.

So ähnlich hat es nach meinem Verständnis MWeston gemacht, indem er den reinen Datentransfer über SDIO laufen lässt, und die Interruptmeldung über die gesonderte GPIO-leitung abläuft. ??

Das Verhalten könnte beim WLAN also tatsächlich damit zusammenhängen, das was mit den Interrupts nicht funktioniert und der Chip über Polling läuft. So kommen nur die Pakete durch, die gerade im Puffer liegen, wenn der Prozessor diesen gerade abfragt. In der Zwischenzeit, wenn der Prozessor anderweitig beschäftigt ist, kommen tausende weitere Pakete an, die verworfen werden, sobald der Puffer voll ist.

Der wird vielleicht ein paar kB groß sein. Was darüber hinaus reinkommt wird verworfen. Beim richtigen Pandora-GIT kommt der Prozessor dank zahlreicher weiterer Threads des Betriebssystems dann seltener dazu, diese paar KB abzuholen und den Puffer für neue Pakete freizumachen.

Allerdings verstehe ich noch nicht, wie die Pandora dann mit 300kB/s Senden kann. Dürfte sie die Daten einfach fröhlich in die Welt blasen, würde das mit der Interrupt-Theorie ja noch zusammenpassen. Aber AFAIK gibts bei Netzwerken ja Kollisionserkennung. D.h. wenn jemand gerade Sendet, wird eine zufällige Zeit gewartet, bis die Leitung frei ist. Dann wird der Puffer der Netzwerkkarte gesendet und dem Computer über Interrupt mitgeteilt, dass er weitere Daten in den Puffer schreiben kann. So ähnlich sollte das doch mit den W-LAN-Kanälen funktionieren.

Eventuell könnte hier ein Versuchsaufbau was bringen:

Pandora1 sendet über W-LAN an Basisstation kontinuierlich Daten. Wenn jetzt eine weitere Pandora2 auch anfängt, an Basisstation Daten zu senden (gleicher Kanal), sollten mit der Zeit beide Pandoras Datenraten um 150 +/- 20 kb/s erreichen. Bei einem Interruptproblem könnten hier dagegen drastische Einbrüche auftreten, oder?

Interessant wär von allem ingesamt die Frage, ob dieser W-LAN-Chip überhaupt die Betriebsmodi SDIO und GPIO gleichzeitig unterstützt. Gibt er überhaupt eine Interruptmeldung über GPIO raus, wenn sämtliche sonstige Kommunikation über SDIO abläuft?

EDIT: Anscheinend schon.

Hier ist ein Blog von jemandem, der wohl exakt den WL1251 am beagleboard verwendet über SDIO und GPIO Interrupt handling:
http://greekclaud.blogspot.com/2009_08_01_archive.html

(Achtung, teilweise experimentiert er auch mit dem 1271)

Siehe letzter Eintrag:

Environment :

Host : Beagleboard B4
Kernel : 2.6.29-omap1
WiFi modile : Muruta WL1251 module


driver WL1251 from linux wireless 2009/09/18

Modification : Add GPIO interrupt handling at SDIO


root@beagleboard:/modules/objs# uname -a
Linux beagleboard 2.6.29-omap1 #35 Wed Aug 19 14:43:34 CST 2009 armv7l unknown
root@beagleboard:/modules/objs#
root@beagleboard:/modules/objs# cat load.sh

insmod rfkill_backport.ko
insmod cfg80211.ko
insmod lib80211.ko
insmod lib80211_crypt_ccmp.ko
insmod lib80211_crypt_tkip.ko
insmod lib80211_crypt_wep.ko
insmod mac80211.ko
insmod wl1251.ko
insmod wl1251_sdio.ko



Performance :


root@beagleboard:/modules/objs# ping 192.168.168.254
PING 192.168.168.254 (192.168.168.254): 56 data bytes
64 bytes from 192.168.168.254: seq=0 ttl=64 time=2.288 ms
64 bytes from 192.168.168.254: seq=1 ttl=64 time=3.144 ms
64 bytes from 192.168.168.254: seq=2 ttl=64 time=3.052 ms
64 bytes from 192.168.168.254: seq=3 ttl=64 time=3.144 ms
64 bytes from 192.168.168.254: seq=4 ttl=64 time=3.387 ms
64 bytes from 192.168.168.254: seq=5 ttl=64 time=4.669 ms
64 bytes from 192.168.168.254: seq=6 ttl=64 time=3.052 ms
64 bytes from 192.168.168.254: seq=7 ttl=64 time=3.052 ms
64 bytes from 192.168.168.254: seq=8 ttl=64 time=3.113 ms
64 bytes from 192.168.168.254: seq=9 ttl=64 time=3.327 ms

Power consumption : 190~200mA.

claud@claud-desktop:~/src/beagleboard/kernel29/compat-wireless$ iperf -c 192.168.168.77 -i 1 -t 10
------------------------------------------------------------
Client connecting to 192.168.168.77, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[ 3] local 192.168.168.25 port 53616 connected with 192.168.168.77 port 5001
[ ID] Interval Transfer Bandwidth
[ 3] 0.0- 1.0 sec 776 KBytes 6.36 Mbits/sec
[ 3] 1.0- 2.0 sec 792 KBytes 6.49 Mbits/sec
[ 3] 2.0- 3.0 sec 888 KBytes 7.27 Mbits/sec
[ 3] 3.0- 4.0 sec 760 KBytes 6.23 Mbits/sec
[ 3] 4.0- 5.0 sec 888 KBytes 7.27 Mbits/sec
[ 3] 5.0- 6.0 sec 896 KBytes 7.34 Mbits/sec
[ 3] 6.0- 7.0 sec 792 KBytes 6.49 Mbits/sec
[ 3] 7.0- 8.0 sec 824 KBytes 6.75 Mbits/sec
[ 3] 8.0- 9.0 sec 888 KBytes 7.27 Mbits/sec
[ 3] 9.0-10.0 sec 808 KBytes 6.62 Mbits/sec
[ 3] 0.0-10.0 sec 8.12 MBytes 6.80 Mbits/sec

Power consumption : 190~200mA.

Vergleicht man die Einträge sieht man, dass die Interruptleitung sich wohl hauptsächlich auf die Pingzeit auswirkt. Der erste 1251er-Eintrag könnte in etwa dem entsprechen, was wir derzeit haben.

 

[morq]

Interessant wär von allem ingesamt die Frage, ob dieser W-LAN-Chip überhaupt die Betriebsmodi SDIO und GPIO gleichzeitig unterstützt. Gibt er überhaupt eine Interruptmeldung über GPIO raus, wenn sämtliche sonstige Kommunikation über SDIO abläuft?

Also das werden sie sicher getestet haben^^ So wie ich das sehe wird wohl einfach nur die SDIO Leitung die für den Interrupt zuständig ist an den GPIO anschluss des Omap geklemmt, was für den Chip kein unterschied machen sollte.

Aber AFAIK gibts bei Netzwerken ja Kollisionserkennung. D.h. wenn jemand gerade Sendet, wird eine zufällige Zeit gewartet, bis die Leitung frei ist. Dann wird der Puffer der Netzwerkkarte gesendet und dem Computer über Interrupt mitgeteilt, dass er weitere Daten in den Puffer schreiben kann. So ähnlich sollte das doch mit den W-LAN-Kanälen funktionieren.

Bei WLan gibt eis keine Kollisionskontrolle, da man keine möglichkeit hat eine Kollision zu vermeiden. Man "höhr" ob der Chanel frei ist, dann wartete man eine zufällige Zeit und sendet. Gab es eine Kollision oder ander übertragungsfehler kommt es zu einem ACK-Timeout.

Ich weiß nicht ob das ganze mutmaßen hier soviel bringt. Ist es ein Hardwareproblem sollte Mweston das dann an dem Debug Board merken wenn dieses fertig ist.

 

[xyta]

Ich seh grad dass dieser Claud-Blog offenbar vom selben Urheber stammt wie der Link von Gino....

--->Vielleicht sollten wir versuchen, diesen Claud Yu irgendwo aufzutreiben.

http://greekclaud.blogspot.com/2009_08_01_archive.html
http://groups.google.com/group/beagleboard/browse_thread/thread/25fcddf411c5da57/ec89bda9a40c0d2c?lnk=raot
http://markmail.org/message/h3i55qgkxcfqejpo
http://permalink.gmane.org/gmane.comp.hardware.beagleboard.user/1952

Eine freie Pandora, wenn er W-LAN zum laufen bekommt oder sowas...

In my case , on OMAP3530 the SDIO xfer fails in 2 cases.

1. source buffer is not in DMA:able space.
2. source buffer address is not 4 buf aligned.

BTW, I replaced both the omap_hsmmc and SDIO driver with drivers I ported from an omap 2430 implementation and solved all performance problems (4-bit mode with interrupts now working). This is on the 2.6.29-rc3 kernel with B7 beagleboard. I haven't looked yet but I'll bet this implementation uses pre- allocated kmalloced buffers as you suggested.

Using kmalloced DMA:able buffer before calling sdio_memcpy_fromio/sdio_memcpy_toio is a workaround.

drivers/mmc/host/omap.c switches to PIO when DMA is not possible due to constraints.

drivers/mmc/host/omap_hsmmc.c always attempts DMA. I tried host->use_dma = 0, but it didn't work.

compare definition of function mmc_omap_prepare_data in both the drivers.

Finially I get a workable WL1251 driver with beagleboard. The tcp performance ~10 Mbps with iperf. The DMA workaround is work like Kalpesh's hint. But the size of DMA need to adjust.

 

[fusion_power]

Versteh nicht viel aber klingt schon mal vielversprechend. Du solltest das schnellsten notaz morsen, wenn du es nicht schon längst getan hast.

 

[EvilDragon]

Danke.
Hab das ganze mal an notaz weitergeleitet

 

[xyta]

Also aus der Antwort im englischen Forum werd ich ja mal sowas von gar nicht schlau.

-Claud Yu hat den originalen TI-Treiber verwendet, notaz den von Nokia/Palm

-und überhaupt geht das sowieso ganz und gar nicht, den der TI WL1251 von Claud Yu ist ein gaaanz anderer WL1251 als der TI WL1251 in der Pandora und mit diesem INKOMPATIBEL (???) :O

-und ich sollte wohl nicht mehr weiter nachhaken und noob-Fragen stellen, notaz hat gesagt das geht nicht und PUNKT.

Ja, ich weiss schon warum ich mich von dem englischen Forum immer möglichst ferngehalten habe. <_<

So, hab jetzt mal nach dem WL1251-Subtyp gefragt. Ohne den zu kennen bringt dieser Brainstorm-Thread sowieso nichts...

Ich finde jedenfalls überall im Netz nur allgemein den WL1251 Chipsatz allgemein, mit dem WL1251 als MAC, WL1251FE als Sende-Frontend und WL1251PW als Powermanager. Dann gibt es noch eine One-Chip-Lösung (WL1251BLYFBR) für VoIP, welche den WL1251 enthält.

 

[dingens]

^

http://www.jorjin.com.tw/Product_SiPmodule_WG7210.htm

 

[xyta]

Hm, wieso heisst es die ganze Zeit, der Chip wäre ein WL1251, wenn es tatsächlich ein WG7210 ist? ??

Grundsätzlich scheint es ja so zu sein, dass der WG7210 einen WL1251 enthält. Theoretisch kein Problem. Allerdings scheint diese Kombination von Bluetooth und W-LAN in einem Chip auch anderen Leuten Probleme zu bereiten.

Der SBC8100 Single Board Computer:
http://www.armkits.com/product/sbc8100.asp
verwendet diesen Chip ebenfalls, und er läuft derzeit nicht.

Das Problem nennt sich SDIO OMAP Multiplexer Support. ??
http://fred-zone.blogspot.com/2010/03/add-devkit8000-and-sbc8100-initial.html

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.

:

Den Treiber den wir brauchen bietet die Herstellerfirma noch nicht an.
http://www.jorjin.com.tw/Support_Overview.htm

Allerdings ist das gute, dass hier noch jemand für sein kommerzielles Produkt diesen Treiber braucht.

======================
EDIT:
Also mein Ergebnis ist, dass TI OpenPandora ziemlich verarscht haben muss. <_<
Laut verschiedener Aussagen verschiedener Leute wurde der WG7210 von TI für das Projekt ja wärmstens empfohlen. Der Gag dabei ist, dass die Kombination OMAP 3xxx und WG7210 wohl derzeit eine der wenigen ist, für die es offenbar keinen funktionierenden Wifi-Treiber gibt! X-( X-( :dash: Und zwar weder für Linux noch Win CE.

Variante 1: TI hat keine Ahnung von ihren Sachen
Variante 2: TI hat sich gedacht, oha ein Open Source-Projekt! ?? Empfehlen wir doch eine Kombination, wo uns noch ein Treiber fehlt, die Leute da sind sicher motiviert, die Sache zum Laufen zu bringen. ;-> So haben wir dann am Ende ohne viel Aufwand eine Lücke im Treiberangebot geschlossen und können mit einer weiteren möglichen Hardwarekombination bei richtigen Großkunden aufwarten! :/

Ich hab jedenfalls den dumpfen Verdacht, wenn man als Open Source Projekt oder Kleinkunde was von TI will, sind die super nett und zuvorkommend und empfehlen ausschließlich Chipkombinationen, für die ein Treiber noch entwickelt werden muss, um gezielt Entwicklungsarbeit zu sparen! :grrr: <_<

Vermutlich ist das die Grundursache für dieses Problem! Da bekommt man richtig Lust, seinen Taschenrechner zu zertrümmern und sich bei Casio einen neuen zu kaufen! :slap:

Desweiteren sieht es so aus als säßen wir mit dem Hersteller des SBC8100 Single Board Computer hinsichtlich Wifi in einem Boot... MWeston sollte da mal hinmailen und auch fragen, warum sie gerade den WG7210 mit dem OMAP kombiniert haben, auf die Antwort wär ich gespannt....

 

[crosspoint]

Krass... Aber xyta könnte wirklich Recht haben. So ticken doch Unternehmen: Gewinnmaximierung bei gleichzeitiger Kostenminimierung. Und letztere soll hier wohl durch die Arbeit der Pandora-Entwickler erreicht werden... Wenn sich dieser Verdacht irgendwie bestätigen sollte, dann wäre es vielleicht ratsam den Code des Treibers, sofern es gelingt einen funktionierenden zu schreiben, vorerst unter Verschluss zu halten.

 

[Anonymous]

Was hat denn TI für ein Interesse an einem Treiber für einen bestimmten Wifi-Chip, der nicht einmal von ihnen stammt? Wäre es icht vor allem die Pflicht des Herstellers des Chips, für einen Treiber zu sorgen? Ansonsten bleibt anzumerken, dass TI selbst in der jüngeren Vergangenheit nicht gerade mit Treibern für eigene Chips geglänzt hat. Archos musste da oft für TI die Kastanien aus dem Feuer holen.

 

[fusion_power]

Beim nächsten Projekt sollte man wirlich nur Hardware verbauen, von der man weiß, dass sie treibermäßig ohne Probleme funzt, ich hab eigentlich angenommen, das ist die normale Vorgehensweise. Wenn man vorher schon weiß, dass es keinen (funktionierenden) Treiber gibt, dann mussm an sich anderweitig umsehen.
Ich bin immer noch recht sicher, dass es kein ernstes problem ist, eventuell reicht ein kleiner Fix um der Hardware/Software Beine zu machen.
In der Vergangenheit und der Geschichte der Computer wurde ja viel durch "Umgehungen" gefixt, meißt sogar Hardware-Bugs durch Software ausgetrickst, das gabs sicher seit dem C64. Drum bin ich sicher, die Devs bekommen das auch auf der Pandora hin.

Aber es sollte nicht in einem Produktionsstopp resultieren, das bringt nix. Ein Board-Neu Design ist sowieso utopisch, wann sollen die Letzten ihre Geräte bekommen, in einem Jahr oder 2?. Nene, Produziert was ihr könnt, über Details kann man dann später philosophieren. Craigix Aussage, dass die letzten 3000 Boards nicht rausgehen, bevor das WiFi Problem gefixt ist, werd ich nicht akzeptieren, ich will endlich meine Pandora.

 

[xyta]

Ich bin immer noch recht sicher, dass es kein ernstes problem ist, eventuell reicht ein kleiner Fix um der Hardware/Software Beine zu machen.

Das denke ich auch. Jorjin beweist es ja beim Nachfolger... Der Nachfolger unseres WL1251 von TI ist der WL1271 (also der reine W-LAN-Chip). Jorjin packt anscheinend ganz gerne TI WLAN-Chips zusammen mit Bluetooth auf ein Die. WL1251-Core+Bluetooth ist eben jener Jorjin WG7210. Auch beim Nachfolger haben sie das bereits gemacht: WL1271-Core und Bluetooth = Jorjin WG7310. Und für diesen WG7310 hat Jorjin bereits einen Android-Treiber entwickelt, für den .27er Kernel, Beagleboard und basierend auf dem 1271er Treiber von TI. (Interrupt über GPIO 162 / Expansion Pin 14! ) Den kann man sich auf der Jorjin-Seite runterladen.

Rein theoretisch sollte der Schritt WL1251 -> WG7210 nicht wesentlich komplizierter sein als der bereits erfolgte WL1271 -> WG7310... ??

Aber es sollte nicht in einem Produktionsstopp resultieren, das bringt nix. Ein Board-Neu Design ist sowieso utopisch, wann sollen die Letzten ihre Geräte bekommen, in einem Jahr oder 2?. Nene, Produziert was ihr könnt, über Details kann man dann später philosophieren. Craigix Aussage, dass die letzten 3000 Boards nicht rausgehen, bevor das WiFi Problem gefixt ist, werd ich nicht akzeptieren, ich will endlich meine Pandora.

Dem stimm ich voll zu. Je mehr Leute eine Pandora haben, desto eher wird das Problem gelöst sein. Ein Spatz in der Hand ist besser als die Taube auf dem Dach, oder eine Pandora ohne funktionierendes Wifi daheim zu haben ist besser als diese gar nicht zu besitzen... Ein Produktiosstopp wegen Wifi find ich aus logischen Gründen Schwachsinn. Allerdings ist mir auch bewusst, dass bei $7 pro W-LAN-Stick die Komplettauslieferung des ersten Batches dann $21.000 mehr kostet als geplant. Das Projekt ist ja von der grundsätzlichen Entwicklung ziemlich fertig, da ist halt die Frage, ob 21.000 Dollar noch für sowas da sind. --> Also bitte möglichst viel ausliefern aber ohne die Kasse zu sprengen!

Ausserdem wär ich dafür, Leute bei der Belieferung ganz weit vorzuziehen, die Referenzen bei der Linux/Embedded/Wifi-Programmierung vorweisen können (auch wenn ich selbst dadurch eher nach hinten rutsche...)

 

[a.tom]

Aber es sollte nicht in einem Produktionsstopp resultieren, das bringt nix. Ein Board-Neu Design ist sowieso utopisch, wann sollen die Letzten ihre Geräte bekommen, in einem Jahr oder 2?. Nene, Produziert was ihr könnt, über Details kann man dann später philosophieren. Craigix Aussage, dass die letzten 3000 Boards nicht rausgehen, bevor das WiFi Problem gefixt ist, werd ich nicht akzeptieren, ich will endlich meine Pandora.

Das unterschreib ich... für den Fall, dass es sich wirklich um ein Hardwareproblem handelt - und das halte ich für sehr unwahrscheinlich - findet sich sicher eine Lösung. Im schlimmsten Fall kann ich auch mit einem Wlan-Stick leben (von mir aus kauf ich mir den selber), aber jetzt wirds wirklich mal Zeit, dass produziert wird.
Dank xyta's Recherchen ist die Lage für mich jetzt relativ klar. Wenn sich der Treiber selbst beim Hersteller des Chips noch im "developing" Status befindet, kann man eigentlich nur abwarten - oder möglichst vielen eine fertige Pandora in die Hand geben zum Testen und Entwickeln.

Interessieren würd mich allerdings schon, in wie weit es Kommunikation zwischen den Pandora-Devs und Jorjin gibt und was die als Zeitrahmen für die Fertigstellung des Treibers angeben... weiß man darüber irgendwas?

 

[xyta]

So, laut notaz gibt es bei der Pandora weder ein Problem mit DMA, wie bei Claud, noch eines mit OMAP Multiplexing, da dieses bei der Pandora nicht verwendet wird. ??

Trotzdem hab ich noch einen Hoffnungsschimmer:


Der Wits A81:
http://www.witstech.com.cn/product_en.html

Selber OMAP wie bei der Pandora, UND ein WG7210 für Bluetooth und W-LAN.
http://www.mobileread.com/forums/showthread.php?t=62570 (Kathy-Post #41)
Standardbetriebssystem ist Windows CE, wo sie auch alles zum Laufen gebracht haben. Jetzt sind sie gerade dabei, Android-Linux für das Gerät zu portieren. Wenn man mit Google Language Tools durch das Forum auf der Witstech-Seite geht, gibt es auch entsprechende Threads. Anscheinend haben sie auch schon das meiste der Hardware in ihrer Beta zum Laufen gebracht, Ausnahme: Sound, Wifi und Bluetooth! :dash:

Also: Ihr offensichtlich selbst geschriebener WindowsCE-Treiber läuft problemlos, aber dass gerade Wifi und Bluetooth in der Android-Beta nicht läuft, könnte man so interpretieren, dass auch diese Firma hier mit Problemen kämpft.