Eigenes OS?
-
Man setzt sich hin, liest die Spezifikationen für UHCI und EHCI, erkennt die Geräte über PCI und nutzt sie dann gemäß Spezifikation. Ja, so einfach kann das sein.
-
Ja, so einfach kann das sein.
Dann ist ja alles gut.
-
Erklärte Witze sind doof.
Ich dachte, Du meinst das wirklich ernst.
-
Erhard Henkes schrieb:
Ja, so einfach kann das sein.
Dann ist ja alles gut.
er hat aber recht, so wie's aussieht, steht im 'OpenHCI' spec alles wichtige drin, um die meisten USB-controller zum leben zu erwecken (nur eben ohne die USB2.0 funktionalität). man muss sich nur die zeit nehmen und sich damit auseinandersetzen. dann braucht man auch nicht 3 mal neu anzufangen (wer hat das gestern noch erzählt?). *fg*
btw, das buch mit dem vielversprechenden namen: 'USB Design by Example' konnte ich leider noch nirgends finden.
ach ja, für USB 2.0/'ehci': http://developer.intel.com/technology/usb/download/ehci-r10.pdf
-
ah, doch gefunden, bei esnips.com. link darf ich leider nicht posten, weil auf dem buch wohl ein copyright ist.
-
;fricky schrieb:
Erhard Henkes schrieb:
Ja, so einfach kann das sein.
Dann ist ja alles gut.
er hat aber recht, so wie's aussieht, steht im 'OpenHCI' spec alles wichtige drin, um die meisten USB-controller zum leben zu erwecken (nur eben ohne die USB2.0 funktionalität).
Außer Intelrechner, die benutzen nicht OHCI, sondern UHCI.
-
taljeth schrieb:
Außer Intelrechner, die benutzen nicht OHCI, sondern UHCI.
wie ich bis jetzt mitbekommen habe, ist 'uhci' die älteste variante (USB 1.0). wikipedia sagt zwar, 'intel und VIA' benutzen noch UHCI, aber meine kiste zeigt mir 2 openHCI (USB 1.1) interfaces an, obwohl der host-controller von VIA ist.
btw: wie weit wird UHCI heute noch verwendet?
für alle, die wissen wollen um was es geht, hier ein link zur erklärung von OHCI/UHCI/EHCI: http://en.wikipedia.org/wiki/Open_Host_Controller_Interface
-
OHCI und UHCI sind beide USB 1.x, nur von verschiedenen Herstellern.
-
fricky schrieb:
btw: wie weit wird UHCI heute noch verwendet?
Ich kann dir verraten, dass mein Laptop UHCI hat. Und der ist bald zwei Jahre alt, also noch nicht extrem veraltet.
-
XanClic schrieb:
fricky schrieb:
btw: wie weit wird UHCI heute noch verwendet?
Ich kann dir verraten, dass mein Laptop UHCI hat. Und der ist bald zwei Jahre alt, also noch nicht extrem veraltet.
ok danke, aber irgendwo muss man ja anfangen. ich glaub' ich werde mich erstmal auf 'openHCI' konzentrieren.
-
@ abc.w und +gjm+ : Hier eine Version, die mit USB-Floppy booten und bis in die Shell laufen sollte: http://www.henkessoft.de/OS_Dev/Downloads/107.zip
Will nur mal sehen, ob da alles klappt unter Linux mit USB-Floppy o.ä. zum Booten.
Die Shell wird mittels incbin in den Kernel eingeschleust. Das ist program.elf in der user-Subdirectory.
-
Perfekt!
PrettyOS [Version 0.1.0107] (C) 2009 henkesoft.de Usable RAM: 3931391 KB Ram Disk at: 4008100Ch <DIR> dev 35 file1 35 file2 35 file3 1825 shell $>_ $>hi <-- I am PrettyOS. Always at your service!P.S.: Ich habe Windows Vista (64 bit). Das sollte aber für das booten und testen von PrettyOS ohne Bedeutung sein.
-
Schön, das dies alles bestens auch unter Linux und mit USB-Floppy klappt.
Zum Erstellen von PrettyOS kann man Linux, WinXP, Vista, Windows7 verwenden.
-
Dieser Thread wurde von Moderator/in Marc++us aus dem Forum Assembler in das Forum Projekt: OS-Development verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
Wir möchten PrettyOS mittelfristig mit einem USB-Treiber ausstatten, da USB das moderne Bus-System ist. Hier ein Hinweis (aus dem IRC) von XanClic, wie man hierbei vorgehen könnte:
So, wenn ihr also unbedingt USB haben wollt. Ihr schreibt zuerst mal einen PCI-Treiber, der die Geräte auflisten kann und die USB-Host-Controller rausfindet. Dann lest ihr euch bei Wikipedia und in der OS-Dev-Wiki über USB ein.
Dann könnt ihr euch die Spezifikationen (OHCI, UHCI von den Hardwareherstellern bzw. s. Links bei WP; USB 2.0 von usb.org, ebenso die Massenspeicherspezifikation (Bulk only)) runterladen und anschließend damit einen hübschen Treiber schreiben.
-
Tobiking postete im bisherigen Google Groups Forum folgenden grundlegenden Beitrag, den ich für weitere Diskussionen nun hierher transferiere:
Ich habe noch ein paar Punkte die meiner Meinung nach geklärt werden
sollten bevor man groß anfängt Code zu schreiben. Das betrifft den
generellen Aufbau (Buildsystem etc.) und auch den Code selber, um
nicht später alles umschreiben zu müssen sobald sich etwas ändert. Im
IRC ist meist nicht die Zeit etwas größer zu Diskutieren, daher fang
ich das mal hier an.Zum Buildsystem:
- Wie im IRC auch kurz erwähnt denke ich sollte man den ganzen Build
Prozess auf Makefiles umstellen. Ich sehe keinen Vorteil darin für den
Bootloader .bat dateien zu nehmen. Ob es elegant ist die Makefiles
aufzuteilen oder eine große zu haben kann man dann noch überlegen
- Das Erstellen des Kernels sollte auch leicht unter Linux machbar
sein. Mit einem zweiten Makefile oder mit einem include dürfte es
eigentlich einfach machbar sein das es auf den meisten Linux systemen
problemlos funktioniert.Zum Code:
- Verschiedene Architekturen sind ja erstmal nicht angedacht, aber man
könnte trotzdem zumindest bei den Typen etwas Abstraktion einführen.
Dann wird statt unsigned int z.B. uint32_t oder u32 verwendet. Benutzt
man irgendwann einen anderen Compiler oder eine andere Architektur (64
Bit) kann man das mit einem typedef korrigieren. Bei den meisten
Strukturen kommt es ja genau auf die Größe an. Der gcc hat dafür sogar
einen Standard Header (stdint.h), den man ohne weiters nutzen kann. Da
gibt es auch noch ein paar andere Header die man nutzen kann und vor
allem Compiler spezifische Konstanten oder Macros enthalten.
- Struktur der Header. Zurzeit gibt es soweit ich gesehen habe einen
Header, der alles andere includiert. Das könnte irgendwann sehr
unübersichtlich werden. Ansonsten überlegen wie man die Header
ordentlich benennt. Mir ist da die Idee gekommen (und habs bei tyndur
ähnlich gesehen) das man sich an den C Standard orientiert.
Letztendlich schreibt man viele Funktionen die exakt so im C Standard
sind. Also kann man die Header auch angleichen.
- Naja Codestil allgemein ist nicht Lebensnotwendig aber schon eine
tolle Sache. Zeichensatz, Einrückung, ein paar Grundlegende Sachen
sollte man schon festlegen.Mir fällt mit der Zeit bestimmt noch einiges ein. Das ist aber erstmal
alles was mir so gerade einfällt.Zu guter letzt habe ich einfach mal mein Bastel OS hochgeladen in dem
ein paar der Punkte beachtet habe. Ich bin noch nicht so weit gekommen
und es hat an vielen Stellen noch Probleme, aber kann vielleicht die
ein oder andere Idee geben. Zu finden ist es unter:
-
Tutorial, Teil 3, Absatz über Abschnitt "FAT12 - Filesystem der Diskette":
VFS/Initrd wird in 0.1.0091 zum Laden der Shell umgangen, bis der Schwachpunkt (...) bitte ich um entsprechende Information.
Ist das hier geschilderte Problem noch aktuell?
-
Nein, dank ausführlicher Tests mit Cuervo und Unterstützung seitens PorkChicken im Low-Level-Forum wurde dieses Problem lokalisiert und gelöst.
-
[i]Aktuelle Arbeiten:
...
Ich habe diese Übersicht nach "Übersicht über PrettyOS (...)" verschoben.
-
Dies ist ja der Hauptthread, der meinen Einstieg in das "OSDEV" begleitet. Daher möchte ich mich hier sehr herzlich bei allen bedanken, die die bisherigen Gehversuche in die Welt des Kernels, der Treiber und des User-Spaces engagiert und tatkräftig unterstützen, sei es durch kleine Hilfestellungen, Hinweise, Diskussionen, Tests, eigene Experimente, kleine Aufsätze sowie Sourcecode. Ein funktionierendes OS ist die Summe vieler kleiner Schritte und Erkenntnisse. Ich wünsche diesem Subforum und unserer kleinen Gruppe um PrettyOS weiterhin viel Spaß, interessante Diskussionen und gutes Gelingen bei allen Vorhaben.