Interne Verdrahtung und Chips in der Pandora

[xyta]

Ich habe mir gerade überlegt, wie es wohl ist, bei der Pandora ein ganz anderes Betriebssystem aufzuspielen. Da wird es ja interessant, wie die innere Hardware angebunden ist.

Beim PC ist es ja z.B. klar, dass die Tastatur über PS/2 oder USB läuft und SD-Karten mit einem Wandlerchip ebenfalls über USB angebunden sind. Grundsätzlich ist das auch beim Laptop so, nur dass die Leitungen direkt auf der Platine verdrahtet sind...

Ich könnte mir aber vorstellen, dass es bei der Pandora ganz anders läuft. ?? z.B. hat der OMAP ja einige SDIO-Ports, wo sich die SD-Slots vermutlich sehr direkt mit verbinden lassen...

Und wie die Tastatur in der Pandora angebunden ist kann ich mir im Moment auch nicht vorstellen. Ich schätze mal, sicher NICHT über internes PS/2.

Daher kann es ja im Prinzip sein, dass man mit anderen OS schon an der Tastatur scheitert. Womöglich kann man für die Tasteneingaben irgendwelche Bits in irgendwelchen Registern auslesen, und darf sich für das OS erst mal einen eigenen Tastaturtreiber schreiben? :huh: oder gibt es doch eine Art der Standardanbindung, wie z.B. einen Standard-Chip, der die Tasteneingaben für SDIO umsetzt und von mobilen OS erkannt wird?

Für Touchscreen, Sound und Grafik sehe ich auch gewisse Schwierigkeiten, allerdings sind das ja halbwegs genormte Einzelkomponenten.. Da müssten die Standardtreiber wahrscheinlich von den I/O-Kanälen auf die Pandora angepasst werden.

Aber Tastatur und Nubs könnten Probleme machen.

 

[EvilDragon]

Naja, was verstehst Du unter GANZ anderes Betriebssystem?

Mir fällt so keins ein, welches direkt so für ARM existieren würde und installierbar wäre.
Mit Ausnahme von Android, aber da das ja auch Linux basiert, kannst Du die Treiber von unserem OS gleich hernehmen.
Lowlevel-Sachen wie Tastatur, etc. sind ohnehin im Kernel drin, daher würde das bei Ubuntu ARM auch gleich funktionieren.

Was hast Du vor?

 

[ivanovic]

Naja, was verstehst Du unter GANZ anderes Betriebssystem?

Naja, ich schätze mal, das er damit sowas meint, wie wir es mal in der Vorlesung "Betriebssystembau" für x86 gemacht haben: Selbst ein (mini!) System schreiben, das z.B. Tastatureingaben verarbeitet, auf Interrupts reagiert und ähnliches.
Sprich nicht etwas fertiges hernehmen, sondern, einfach so aus Lust an der Freude, selbst schreiben.

 

[relei]

Hi,

wie die GPIOs genutzt werden steht im Quelltext der Boarddatei, genau wie SPI und I2C. Das sind aber alles standard Schnitstellen wofür man nur einen Treiber braucht .

Sound wird vom Power IC gemacht TPS3060(oder so), läuft dann aber auch über den OMAP.

Alles andere wird auf dem OMAP gemacht (siehe OMAP Dokumentation) für den man ja eh extra seine Programme/Betriebssystem übersetzen muss.

Die Verdrahtung ansich ist da ehr unwichtig.

Schönen Gruß
Rene

 

[SebbiUltimate]

Cool, an der Diskussion würde ich mich auch gerne beteiligen
@ Lowlevel:
Mal theoretisch: Wenn ich ein Assembler-Bootloader schreibe, geht das dann mit dem passenden Compiler gleich? Ist die Bootsignatur (0xAA55) Little oder Big Endian?
Muss ich sonst noch auf was achten?

Danke im Vorraus.

 

[relei]

Ob Little oder Big Endian weis ich nicht, das ist aber auch in der OMAP Beschreibung zu finden, du müsstest versuchen einen uboot (und x-loader) nach zu bauen, ich denke du wirst da beim beagleboard fündig.

 

[fusion_power]

Wenn "Lowlevel" bedeutet, dass plötzlich Games die volle Hardware-Power der Pandora ansteuern könnten, ohne Umwege, dann immer zu. Bin da sehr dafür. Bisher sieht man ja noch nicht wirklich viel von dem was möglich währe wenn alle Treiber und Kernel voll optimiert währen und nichts ( ausser den Coding Fähigkeiten der Programmierer vllt.) einer Hardwarenutzung entgegen stünde, wie sie z.B. auf der PSP oder dem kleinen NDS zu finden ist, wo auch quasi "ohne Unterbau" mehr aus der Hardware raus geholt wird, als je drin war.

 

[ivanovic]

Wenn "Lowlevel" bedeutet, dass plötzlich Games die volle Hardware-Power der Pandora ansteuern könnten, ohne Umwege, dann immer zu. Bin da sehr dafür. Bisher sieht man ja noch nicht wirklich viel von dem was möglich währe wenn alle Treiber und Kernel voll optimiert währen und nichts ( ausser den Coding Fähigkeiten der Programmierer vllt.) einer Hardwarenutzung entgegen stünde, wie sie z.B. auf der PSP oder dem kleinen NDS zu finden ist, wo auch quasi "ohne Unterbau" mehr aus der Hardware raus geholt wird, als je drin war.

Pech, das "Lowlevel" eben das NICHT bedeutet! Es bedeutet nur (und rein gar nix anderes) das jemand mal schauen möchte, wie es mit dem grundlegenden System erstellen so klappt. Das hat rein gar nix mit der resultierenden Geschwindigkeit von für das System erstellten Programmen zu tun.

Hardwareausnutzung ist immer eine Frage der Optimierung und wie viel Zeit man da rein steckt. Allerdings steht die verwendete Zeit (für Hobbyentwickler), die für "komplette" Optimierung nötig wäre (und das ist verdammt viel!) in keinem Verhältnis zu dem erzielten Gewinn. Die Optimierung an sich hat aber erstmal gar nichts mit einem vorhandenen Grundsystem zu tun. Insbesondere: wie soll man den Grafikchip komplett ausnutzen, wenn es *keine* Dokumentation dazu gibt, wie der genau anzusteuern ist (für Beschleunigung usw, einfaches, unbeschleunigtes darstellen eines Framebuffers ist kein Ding).

 

[fusion_power]

Naja, wenn Texas Instruments einen Chip verkauft müssen sie ja sicher stellen, dass man den auch nutzen kann. Alles andere währe ziemlich sinnfrei finde ich. Drum wundert es mich um so mehr, dass in Sachen Treiber immer so ein Krampf da ist, und alles ehr zäh statt flott von statten geht. Die müssen einfach nur gute Treiber machen und fertich. Dann müsste der User seine Programme auch nicht tot-optimieren weil vieles schon von "hause aus" gut läuft. Vielleicht würde auch eine art "Super Compiler" helfen, der schon alles an Optimierungen in ein Programm rein quetscht, was der OMAP her gibt, dann bräuchte der Coder sicher auch weniger Zeit mit Optimieren verbringen.
Ich bin mir auch sicher, das kommerzielle Games nicht jedes einzelne immer gleich aufwendig optimiert wird. Die haben sicher einfach alle HW-Specs eines Gerätes und können flockig genau dafür coden. Da sich die Specs nicht ändern, wird das dann sicher meisst mehr oder weniger das selbe sein, was man optimiert.
Und das war auch meine Hoffnung im Falle der Pandora. Die Hardware ist "fest", da ändert sich nix. Wenn man sie erst einmal gut kennt sollte jedes Programm von diesem Wissen profitieren können und eine reichhaltige "Datenbank" der Tricks vorhanden sein, mit denen man das letzte aus den Chips raus holen kann OHNE sich viel stress damit zu machen.

 

[relei]

Hi,

es gibt doch alles von Texas was man zu den Treibern wissen muss :huh:.

So einfach ist das nicht mit super Treiber machen, denn es gibt ja verschiedene Betriebssysteme. Auch ist es nicht so einfach alle optimierung automatisch ein zurechen, denn es kommt ja auch teilweise auf das Programm an was man schreibt.

Für kommerzielle Games und deren Konsolen gibt es meist eine eigene Entwicklungsumgebung die man kaufen und nutzen kann.... zugriff auf die eigentliche HW nehmen die meisten da nicht. Es ist auch einfacher so eine Entwicklungsumgebung zu entwickeln und zu verteilen da ja nur ein Betriebssystem funktionieren muss und das auch nur in einem bestimmten Umfang.

Schönen Gruß
Rene

 

[fusion_power]

Für kommerzielle Games und deren Konsolen gibt es meist eine eigene Entwicklungsumgebung die man kaufen und nutzen kann.... zugriff auf die eigentliche HW nehmen die meisten da nicht. Es ist auch einfacher so eine Entwicklungsumgebung zu entwickeln und zu verteilen da ja nur ein Betriebssystem funktionieren muss und das auch nur in einem bestimmten Umfang.

Schönen Gruß
Rene

Ah, sowas hatte ich dann im Sinn. Nicht die Software selber muss direkt an dei HW angepasst werden, sondern es ist in dem Falle dann die gute und angepaste Entwicklungsumgebung, die den Codern das Leben einfacher macht und dafür sorgt, dass die Programme auf NDS, PSP & Co. so gut performen?
Ja was gibts dann für OMAP ARM Chipsets in unserem Falle für gute Entwicklungsumgebungen, die ähnliches leisten können? Die Auswahl ist da ja eigentlich recht groß oder?

 

[EvilDragon]

Ah, sowas hatte ich dann im Sinn. Nicht die Software selber muss direkt an dei HW angepasst werden, sondern es ist in dem Falle dann die gute und angepaste Entwicklungsumgebung, die den Codern das Leben einfacher macht und dafür sorgt, dass die Programme auf NDS, PSP & Co. so gut performen?
Ja was gibts dann für OMAP ARM Chipsets in unserem Falle für gute Entwicklungsumgebungen, die ähnliches leisten können? Die Auswahl ist da ja eigentlich recht groß oder?

Naja, der normale GCC kann NEON nutzen, SDL und OpenGL ES nutzen eh die Grafikhardware, also kannst Du mit jeder normalen C++-Entwicklerumgebung den OMAP gut nutzen.

 

[Creature XL]

Wenn "Lowlevel" bedeutet, dass plötzlich Games die volle Hardware-Power der Pandora ansteuern könnten, ohne Umwege, dann immer zu. Bin da sehr dafür. Bisher sieht man ja noch nicht wirklich viel von dem was möglich währe wenn alle Treiber und Kernel voll optimiert währen und nichts ( ausser den Coding Fähigkeiten der Programmierer vllt.) einer Hardwarenutzung entgegen stünde, wie sie z.B. auf der PSP oder dem kleinen NDS zu finden ist, wo auch quasi "ohne Unterbau" mehr aus der Hardware raus geholt wird, als je drin war.

Pech, das "Lowlevel" eben das NICHT bedeutet! Es bedeutet nur (und rein gar nix anderes) das jemand mal schauen möchte, wie es mit dem grundlegenden System erstellen so klappt. Das hat rein gar nix mit der resultierenden Geschwindigkeit von für das System erstellten Programmen zu tun.

Ich weiß das es kleinkariertes Kluggescheiße ist, aber Fakt ist nun mal das Du mehr Performance (von der CPU) bekommst, wenn Du z.B. Linux herausschmeißt.
Das Wird mit Sicherheit für den Anwender nicht bemerkbar sein, aber ist vorhanden. Des weiteren kann ich mir schon vorstellen das ein Treiber der nicht den Aufwand betreiben muss um in das Linux-Treiberframework "zupassen" flotter sein kann.
Wer schon seine Pandora hat, kann ja mal aus Spaß mit "top" gucken wie viel Prozent die CPU in "system (sy)" verbringt.

Wir sind uns aber sicher einig, dass sich der Aufwand nicht lohnen würde eigene Treiber zu entwickeln

Ich hab übrigens vor ein paar Wochen meine ersten Versuche in 386er-Assembler unternommen. Programm direkt in den Bootsektor gepackt. Also komplett ohne Linux/Windows. Nur BIOS. Dabei habe ein paar Sachen gelernt über die Funktion von PCs und BIOS. Kann mir sehr gut vorstellen das genau das der Grund ist, worum es dem OP ging.

 

[relei]

Fakt ist nun mal das Du mehr Performance (von der CPU) bekommst, wenn Du z.B. Linux herausschmeißt.

Und wer oder was verwaltet dann deine Hardware :-D , du brauchst Linux um überhaupt mit dem User in Kontakt treten zu können.

Auch wenn du Programme direkt im u-boot startest, wirst du mit den wenig sinnvolles anfangen können.

Fakt ist , du brauchst ein Betriebssystem und Linux ist dabei schon sehr Ressourcen schonend.

Schönen Gruß
Rene

 

[Creature XL]

Fakt ist nun mal das Du mehr Performance (von der CPU) bekommst, wenn Du z.B. Linux herausschmeißt.

Und wer oder was verwaltet dann deine Hardware :-D , du brauchst Linux um überhaupt mit dem User in Kontakt treten zu können.

Auch wenn du Programme direkt im u-boot startest, wirst du mit den wenig sinnvolles anfangen können.

Fakt ist , du brauchst ein Betriebssystem und Linux ist dabei schon sehr Ressourcen schonend.

Schönen Gruß
Rene

Ich sagte ja, dass es sehr aufwendig ist und sich nicht lohnen wird Vor allem wenn es um 3D-Grafik geht.

Linux ist mit Sicherheit sparsam mit den Resourcen, aber aufgrund des Multi-User Betriebes hat es schon ein paar "Bootlenecks". Ich bin kein Experte aber auch kein Neuling in Sachen Betriebsystem-Programmierung. Ist es nicht so, dass alle Daten die z.B. an die Soundkarte oder Netzwerkkarte geschickt werden sollen erst mal vom Userspace in den Kernelspace kopiert werden müssen? Und da in UNIX alles ein File ist - auch die Devices, wird ebenfalls ein Teil des Filesystemcodes durchlaufen.

Wer z.B. die alten Home-Computer kennt (C64 / Atari 8-Bit oder sogar Atari ST und AMIGA) darauf wurden fast alle Spiele ohne oder mit sehr wenig Hilfe vom OS Programmiert. Auf dem Atari 8-Bit gehen einige (ich auch) sogar so weit und schalten das OS komplett aus und schreiben die (simplen) ISR selber

 

[SebbiUltimate]

[Ist es nicht so, dass alle Daten die z.B. an die Soundkarte oder Netzwerkkarte geschickt werden sollen erst mal vom Userspace in den Kernelspace kopiert werden müssen? Und da in UNIX alles ein File ist - auch die Devices, wird ebenfalls ein Teil des Filesystemcodes durchlaufen.

Also meistens wird sowas mit Syscalls bewerkstelligt, die vom Kernel wiederum ans BIOS geschickt und per Interrupt gesteuert werden.