wejp said:
EvilDragon said:
Wir sind nicht ganz so doof, wie wir aussehen. Wir setzen die Prioritäten schon richtig.
Höchste Priorität hat das Pandora Grundgerüst. Das sind Treiber, Libraries und unter anderem auch das PND-System.
Das ist schön, wenn das so ist. Ich bin dennoch verwundert über den Zustand des WLAN-Treibers und das ist weniger als Vorwurf gedacht, sondern wirklich mehr Verwunderung. Falls sich später herausstellen sollte, dass die Performance durch ein Hardwareproblem so schlecht bleibt oder sogar gar nicht stabil möglich sein wird, habt ihr nämlich ein größeres Problem und es kann wohl niemand abstreiten, dass das im Bereich des Möglichen liegt. Natürlich hoffe ich, dass das nicht so sein wird.
notaz hat mit Michael rudimentäre Tests auf Minimal-Assembler-Basis gemacht, ein Hardware-Problem ist laut ihm, notaz und DJWillis so gut wie ausgeschlossen.
Nochmal: Der WiFi-Treiber geht - das Problem ist SDIO und das läuft auf noch keinem Linux-System korrekt, wie notaz selber schon erwähnt hat.
Da kommen täglich Patches, aber es wird dran gearbeitet.
Ein OS, wie bei Dingux, hatten wir auch ein paar Tage nach den Devboards laufen.
Hat Dingux 3D Hardware? Nein. Hat Dingux WiFi? Nein. Hat Dingux einen X Server mit Hardwarebeschleunigten Grafiktreibern? Nein.
Was bietet es denn? Einen Framebuffer (Standard), Sound (Standard), DPad und Buttons (Standard)... und das wars.
Du machst es dir hier sehr einfach und das ist nicht fair, weil es so nicht stimmt. Ich würde behaupten, dass die Arbeit die Booboo mit dem Kernel auf dem Dingoo hatte, weit über das hinaus geht, was nötig war, um einen rudimentären Kernel auf der Pandora ans laufen zu bekommen. Die Pandora ist schließlich zu großen Teilen mit dem Beagleboard identisch.
Ich denke es ist genau andersrum. Du siehst es sehr sehr einfach.
Mal kurz als Info, was notaz alles erledigt hat, damit alles ging:
a) Akku: Ladekontrolle, Abfrage des Status, etc. Alles nicht auf dem Beagleboard.
b) LCD (Timings, allgemeine Ansteuerung): Nichts mit Beagleboard.
c) WiFi / Bluetooth-Modul: Nicht auf dem Beagleboard.
d) Eigenes Tastatur- und Joystick-System (ink. Möglichkeit, DPAD als Tastatur und Joystick zu nutzen): Ebenfalls nicht auf dem Beagleboard.
e) Verstärker-Chip, etc. Auch alles nicht drin.
Viele weitere kleine Fixes, die ich schon wieder vergessen habe...
Eigentlich ist das einzige, was mit dem Beagleboard identisch ist, der SoC. Weder SDIO noch WiFi noch Bluetooth noch die LCD noch die Tastatur, etc. haben etwas mit dem Beagleboard zu tun.
Zudem hat notaz auch eine Menge Fixes dem Beagleboard zugetragen. Er hatte schon ein Devboard, bevor das Beagleboard erhältlich war...
Das was Du dort als "Standard" abtust, ist mit nichten so einfach, wie es einem der nichts mit der Entwicklung zu tun hat, erscheinen mag.
Habe ich nicht behauptet. Aber fast alles, was Booboo beim Dingoo machen musste, hat notaz bei der Pandora ebenfalls gemacht. Nur noch mit wesentlich komplexeren Teilen und Funktionen (wie erwähnt: Hardwarebeschleunigung, etc.)
Ein simples System ohne X, ohne Tastatur, mit DPAD, etc. lief schon seit über einem Jahr.
Auch notaz hat mir selber gesagt, dass der OMAP extrem unübersichtlich ist, weil er eben sehr komplex ist. Der GP2X und WIZ sind deutlich leichter und ein OS für diese kann man in kurzer Zeit anfertigen. Und ich denke, notaz weiß, wovon er spricht.
Den Dingoo stufe ich von der Hardware nicht komplexer als den WIZ ein - lasse mich aber gern eines besseren belehren.
grond hat mit seiner Bemerkung schon völlig recht, dass sich nur wenige finden werden, die am Kernel arbeiten werden. Dagegen wird es relativ viele geben, die an der Oberfläche schrauben können. Wenn ihr das mit den Prioritäten doch anders verteilt habt, als es durch MWestons Aussage erschien, ist das zwar gut, eine Hardware in Massen ohne funktionierende Treiber zu produzieren halte ich aber für gewagt.
Siehe OpenMoko, da war das ähnlich: Ein Telefon, welches 6 Monate nicht telefonieren konnte.
Mit notaz und DJWillis haben wir zwei Top-Leute am Grundsystem. Den Experten, den wir uns von TI gemietet haben (gegen Geld!) hätten wir uns sparen können. Nach zwei Monaten, in denen er an WiFi gearbeitet hat, ist nichts passiert. DJWillis hat den Treiber schließlich dann doch zum Laufen gebracht.
torpor hat sich selber auch schon gemeldet, mithelfen zu wollen. Von den 4000 Bestellungen sind viele Hacker und Devs dabei - wenn nur 10 am Kernel arbeiten, sind das fünfmal soviele wie vorher.
Dass sich da viel mehr viel schneller erledigen läßt, sollte klar sein
Wie gesagt hinkt der Vergleich gewaltig, weil für die Pandora-Plattform schon viele Teile fertig bereitlagen, durch die Existenz des Beagleboards. Der Dingoo musste erstmal dazu gebracht werden überhaupt einen Linux-Kernel zu booten, dann musste ein geeigneter Bootloader für den Dingoo realisiert werden und am Kernel waren trotz der Patches von Ingenic noch diverse Arbeiten nötig, die über die von dir genannten Sachen hinausgehen.
Wie gesagt, das taten die erstmal nicht. Vieles am Beagleboard wurde auch vom Pandora-Projekt übernommen. notaz hat eine Menge OMAP-Spezifischer Patches in den Mainline-Kernel übertragen.
Ich denke nicht, dass ich Booboos Arbeit unterschätze - aber ein System, welches nur ein paar Hardwarekomponenten hat, für die Treiber entwickelt werden müssen, ist definitiv simpler, als ein vollwertiges Desktop-System.
Neben dem Kernel hat notaz auch am X-Server schrauben dürfen:
Wußte jemand, dass ein X.Org-Server nicht mit zwei Tastaturen sauber arbeitet?
Kann jeder einfach nachvollziehen: Steckt an ein Notebook eine USB-Tastatur an und tippt auf beiden gleichzeitig rum. Lasst nebenher htop laufen: Die CPU-Last schnellt in die Höhe. Denn der X-Server ist tatsächlich noch auf eine Maus und eine Tastatur ausgelegt. Bei zwei Tastaturen kopiert er die Einstellungen jeweils neu hin- und her, wenn man jeweils die andere verwendet. Daher eine Riesenprozessorlast, die die Pandora zum Ruckeln veranlasst hat. Denn die Pandora hat quasi zwei Tastaturen: Eine normale und eine Zuschaltbare (DPAD + Buttons).
Komm da erstmal dahinter und bessere das dann mal im X.Org aus, das ist ein Riesenwust an Quellcode. Hat notaz gemacht.
Nächstes Problem: omapfb läuft nicht sauber zusammen mit dem XInput-Treiber des Touchscreens. Jede SDL-App in Fullscreen hat den X-Server gecrasht.
Auch hier heißt es: Erstmal rausfinden, warum die App den Server crasht und dann noch die Lösung dafür entwickeln.
Kommt am Beagleboard nicht vor, da wohl alle eine Maus verwenden...
Es gäbe noch zig andere Beispiele, die ich hier nennen könnte...
Ja, ich weiß mehr von der Pandora-Entwicklung als von der von Dingux. Trotzdem denke ich, dass ich auch dadurch, dass ich Open2x damals mitverfolgt habe, einigermassen einschätzen kann, was wo wieviel Arbeit macht.
Und da ist die Pandora eindeutig das deutlich komplexere System und ich bin froh, dass alle großen Probleme soweit beseitig sind. Bis eben auf SDIO.
