Nachrichten

41

Softwareentwicklung / Re: Falscher Link in Cross-Compiler Artikel

« am: 06. September 2016, 11:32 »

Danke für den Hinweis, ich hab es geändert.

42

Lowlevel-Coding / Re: Festplatten Sektoren direkt einlesen

« am: 22. August 2016, 16:15 »

Gegenüber der Zeit, die die Hardware braucht, um die Daten tatsächlich von der Platte zu lesen, spielen die paar Portzugriffe keine große Rolle.

43

Lowlevel-Coding / Re: Festplatten Sektoren direkt einlesen

« am: 19. August 2016, 12:17 »

Bei Festplatten gibt es zwei unterschiedliche Einteilungen. Die eine ist die physische Schnittstelle zwischen der Festplatte selbst und dem Controller, das sind SATA und PATA. Das andere ist die Schnittstelle, die der Controller für die Software bietet, das sind IDE und AHCI. Das erste spielt für dich keine Rolle, du hast also keinen SATA-Treiber, sondern einen IDE- oder AHCI-Treiber. Ob dein SATA-Controller AHCI oder IDE zur Verfügung stellt, hängt in der Regel von einer BIOS-Einstellung ab. Beiden haben gemeinsam, dass sie den ATA-Befehlssatz benutzen, nur der Zugriff ist unterschiedlich. Einfacher ist die alte IDE-Schnittstelle, aber heutzutage ist AHCI der Normalfall.

Ich gebe dir einfach mal einen Sack voll Links auf den Weg mit:

Lowevel-Wiki zu IDE: http://www.lowlevel.eu/wiki/ATA
osdev.org-Wiki mit Beispiel zu minimalen Lesefunktionen von IDE: http://wiki.osdev.org/ATA_read/write_sectors
osdev.org-Wiki zu AHCI: http://wiki.osdev.org/AHCI
AHCI-Spezifikation: http://www.intel.com/content/www/us/en/io/serial-ata/ahci.html
Sepzifikation für den ATA-Befehlssatz: http://www.t13.org/Documents/UploadedDocuments/docs2007/D1699r4a-ATA8-ACS.pdf

44

Lowlevel-Coding / Re: Festplatten Sektoren direkt einlesen

« am: 19. August 2016, 10:52 »

Wenn du nicht im RM bist, wirst du versuchen, auf BIOS-Aufrufe komplett zu verzichten, sonden die Hardware direkt mit deinem eigenen Treiber anzusteuern. Speziell für Festplatten gibt es keinen Grund, das BIOS zu benutzen, wenn du einen Treiber hast. Also musst du auch nicht in den RM zurückwechseln und dir irgendeine Verlangsamung einfangen.

Wenn du mehr als 4 GB Speicher benutzen willst, ist das einfachste, du gehst gleich auf den Long Mode. Es gibt ein paar Krücken, um auch im PM mehr als 4 GB physischen Speicher zu benutzen, aber eben nicht gleichzeitig, weil der virtuelle Adressraum trotzdem auf 32 Bit beschränkt ist. (PSE-36 und PAE wären das, beide benutzen Paging dafür.)

45

Lowlevel-Coding / Re: physische Speicherverwaltung - Excpetion 5

« am: 16. August 2016, 11:17 »

Erstmal zu deiner Frage, was Exception 5 ist: Das könntest du ganz leicht selber herausfinden. Wie alles fürs OS-Dev wesentliche steht das im Intel-Manual Volume 3, und zwar logischerweise im Kapitel über Interrupts und Exceptions. Dort findest du dann: "Interrupt 5—BOUND Range Exceeded Exception (#BR)". Ich gehe nicht davon aus, dass dein Code absichtlich BOUND benutzt, von daher ist entweder deine Ausgabe falsch (nimm qemu -d int zum prüfen, wenn du das nicht schon hast) oder du führst etwas aus, was du nicht ausführen willst.

Ich weiß nicht genau, was du mit der Speicherverwaltung schon machst, aber der normale Ansatz wäre, alle Aufrufe in die Speicherverwaltung nach und nach auszukommentieren, um zu sehen, welcher das Problem erzeugt, und dann mit vielen kprintfs zu versuchen, herauszufinden, wo der Kernel etwas anderes macht als du denkst.

Eine Option könnte sein, dass der PMM eigentlich belegte Adressen herausgibt, so dass du z.B. deinen Kernelcode überschreibst, wenn du den Speicher benutzt. Wenn du dir alle Adressen ausgeben lässt, die er für Allokationen benutzt, solltest du sowas recht schnell sehen. Das gilt natürlich nur, wenn die erste Allokation das Problem auslöst. Wenn schon die Initialisierung reicht, damit Dinge kaputtgehen, könnte vielleicht der Code, der versucht, die Bitmap zu platzieren, schuld sein. Auch da einfach wieder Adressen ausgeben lassen und schauen, ob das das ist, was du erwartest.

46

Das Wiki / Re: Video-Tutorial auf YouTube

« am: 12. July 2016, 12:45 »

Da ist ja inzwischen ganz schön Material zusammengekommen. Ich fürchte, da werde ich nie dazu kommen, das alles anzuschauen.

Aber nur von den Videotiteln her muss ich jetzt doch mal mit dir schimpfen: GUI vor Multitaskung und Speicherverwaltung? Das ist genau das, wovon wir lange Mühe hatten, die Leute abzubringen, damit sie auf eine vernünftige Grundlage bauen. Ich glaube nicht, dass du deinen Zuschauern mit dieser Reihenfolge einen Gefallen tust.

Was osdev.org angeht - da gibt es schon ein paar spezielle Persönlichkeiten, nimm das nicht zu persönlich. (Ohne natürlich behaupten zu wollen, dass wir keine speziellen Persönlichkeiten hätten. )

47

Lowlevel-Coding / Re: [GCC Linker] ELF header in memory

« am: 28. June 2016, 15:48 »

Hm, ich sehe nichts, was man dafür machen müsste.

Benutzt du denn auch GRUB oder irgendeinen anderen Bootloader wie qemu -kernel oder syslinux?

48

Lowlevel-Coding / Re: [GCC Linker] ELF header in memory

« am: 28. June 2016, 09:54 »

Wofür brauchst du denn den Header im Speicher? Zugriff auf die Section-Header bekommt man ja mit Bytes 28-40 in der Multiboot-Info-struct . Und beim Rest wüsste ich nicht, wozu der nach dem Laden noch nützlich sein sollte?

49

Lowlevel-Coding / Re: kprintf char ausgeben

« am: 12. May 2016, 09:12 »

Was ich meinte, ist dass nicht jede Ausgabe von der Tastatur kommt (der größte Teil sind feste Strings) und dass nicht jede Eingabe auf dem Bildschirm sichtbar werden soll (z.B. Passwörter). Von daher würde ich diese beiden Sachen getrennt betrachten und erst ein Programm, das sowohl Eingaben nimmt als auch Ausgaben macht, verbindet beides miteinander.

Wenn eine Ausgabefunktion Keycodes benutzt, klingt das irgendwie komisch. Wie sollte das denn aussehen? Ein kprintf(), das ein Array von Keycodes statt einem String als Parameter bekommt, nur Zeichen ausgeben kann, die auch auf der Tastatur sind, und Funktionstasten ignoriert?

50

Lowlevel-Coding / Re: kprintf char ausgeben

« am: 11. May 2016, 11:59 »

Da du bei deiner Antwort nicht weiter auf die Übersetzung von UTF8 auf CP437 eingegangen bist, gehe ich davon aus, dass ich das so Umsetzen kann?

Hups, ganz vergessen.

Ich würde kprintf() (und vor allem die für den Userspace sichtbaren Terminals) UTF-8 nehmen lassen und erst den Konsolentreiber, der dann tatsächlich in den Videospeicher schreibt, die Umwandlung in CP-437 machen lassen. Das kann grob auf derselben Ebene passieren, wie man auch Escapesequenzen z.B. zum Cursor-Bewegen oder für farbige Ausgabe umsetzen würde.

Tatsächliche habe ich sowas schon versucht. Ich habe also für Pos1 den dazu gehörigen Keycode (71) an meine Ausgabe gesendet und dann entsprechend abgefragt.

Was meinst du mit Ausgabe? Der Keycode ist doch eine Eingabe und keine Ausgabe?

Im Prinzip verlagerst du bei so einem Interface die Übersetzung von Keycode nach UTF-8 in das aufrufende Programm. Das Programm kann dann erstmal schauen, ob es eine Funktionstaste ist, mit der es irgendetwas anfangen kann, und wenn nicht, versucht es ein lesbares Zeichen daraus zu machen.

51

Lowlevel-Coding / Re: kprintf char ausgeben

« am: 11. May 2016, 11:19 »

Am sinnvollsten wäre es, für solche Tasten ein Interface bereitzustellen, das Keycodes benutzt und nicht ASCII- oder Unicode-Zeichen. In der Praxis gibt es das letztere aber trotzdem und ist sogar ziemlich verbreitet. Unter Linux bekommst du Escapesequenzen, eingeleitet von \033 (auch als ^[ dargestellt). Wenn du mal auf der Konsole einfach "cat" machst und dann die Tasten drückst, kommen die auch genau so raus. Pfeil hoch produziert z.B. "^[[A". Unter DOS kamen dabei Zwei-Byte-Codes heraus, wobei das erste Byte \0 war. Für beides müsstest du im Internet komplette Tabellen finden, wenn du eins davon nachbauen willst.

52

Softwareentwicklung / Re: Interrupts durch Syscalls blockiert

« am: 08. May 2016, 18:29 »

Interrupthandler, die mit cli anfangen, sind kaputt. Aber ich nehme an, er regelt das über den Deskriptortyp (Trap Gate oder Interrupt Gate) in der IDT, und das ist völlig in Ordnung.

53

Lowlevel-Coding / Re: kprintf char ausgeben

« am: 06. May 2016, 22:36 »

Dein Editor wird die Umlaute vermutlich als UTF-8 abspeichern, deswegen sind das mehrere Bytes und ungültig für einen char, der nur ein einziges Byte speichern kann.

Der Zeichensatz, den die Grafikkarte für den Textmodus benutzt, wenn du nichts umgestellt hast, ist Codepage 437. Entweder du weist deinen Editor an, die Datei in diesem Zeichensatz zu speichern, oder du benutzt Escapesequenzen wie \x84 für ä, oder du baust in deinen Kernel UTF-8-Unterstützung ein, d.h. du wandelst deine UTF-8-Strings zur Laufzeit in CP-437 um. Letzteres ist wahrscheinlich das schönste, weil du dein OS dann nicht später komplett von einem beschränkten Zeichensatz auf Unicode umstellen musst, aber natürlich auch das komplizierteste.

54

Softwareentwicklung / Re: Interrupts durch Syscalls blockiert

« am: 06. May 2016, 18:43 »

Wieso macht das den Kernel einfacher? Ich habe mir Syscalls als einen Funktionsaufruf einer Funktion im Kernel vorgestellt. Und bei einem Interrupt wird der aktuelle Status einfach wie jeder andere gesichert (ausser, dass der Stack weiterverwendet wird). Das hat bis jetzt auch gut funktioniert.

Wenn du in den Syscall-Implementierungen globalen Zustand benutzt, brauchst du Locking, weil du nicht weißt, an welcher Stelle der Syscall von einem anderen Task unterbrochen werden könnte, der den globalen Zustand ebenfalls liest oder sogar ändert.

RDTSC gibt einen Zähler zurück, welcher mit einer nicht weiter definierten Taktrate incrementiert wird. Diese ist aber nicht gleich der Anzahl Takte, die bisher vergangen sind, da sich der Takt an die entsprechenden Verhältnisse anpasst, aber der Takt mit der der Zähler hochgezählt wird bleibt gleich.

Ich dachte, du willst einfach nur Zeit messen? Dafür ist RDTSC auf den meisten CPUs ziemlich gut geeignet.

55

Lowlevel-Coding / Re: kprintf char ausgeben

« am: 28. April 2016, 12:08 »

kc2c(int keycode) greift auf die Array zu, die die keycodes mappen. soweit so klar. Mein kprintf funktioniert z.B. mit kprintf("test"); Das meinst du mit "machst du ja für Strings schon", oder? Irgendwie muss ich meinem kprintf doch aber %c beibringen.

Okay, dein Ansatz sieht gut aus. Ich glaube, ich habe missverstanden, an welcher Stelle genau dein Problem liegt.

Du hast bisher wahrscheinlich gar keine Formatstring-Funktionalität in deinem kprintf(). Du hast aber sicher schon eine Schleife, die über die einzelnen Zeichen des Strings geht und sie dann ausgibt. An sich musst du nur hier prüfen, ob das Zeichen ein '%' ist und falls ja, statt das Prozentzeichen auszugeben, abhängig vom nächsten Zeichen irgendetwas anderes machen. Bei '%c' wäre das, dass du dir mit va_arg(ap, int) den nächten Parameter holst (schau dir Beispiele für die Verwendung von stdarg.h an, wenn du nicht weißt, wie Funktionen mit beliebig vielen Parametern gehen) und dann das Ergebnis als Zeichen ausgibst.

was bedeutet eigentlich das [0x7f]?

Das ist die Arraylänge (und sie ist natürlich falsch, müsste eins mehr, also 0x80 sein). Ich bin davon ausgegangen, dass deine möglichen Keycodes von 0 bis 127 gehen, dass du also direkt die Scancodes nimmt und die Funktion nicht für Breakcodes aufrufst. Das stimmt natürlich auch nur am Anfang, weil es noch die erweiterten Scancodes gibt, die aus mehreren Bytes bestehen.

56

Lowlevel-Coding / Re: kprintf char ausgeben

« am: 28. April 2016, 10:27 »

Im Prinzip ist alles, was du brauchst, ein großes Array, das dir die Scancodes auf ASCII-Zeichen mappt:

Code: [Auswählen]

static const char sc_to_char[0x7f] = {
  0, 27 /* Escape */, '1', '2', '3', ...
};
Und dann nochmal ein zweites Array für wenn Shift gedrückt ist.

Ach so, und die Umwandlung gehört natürlich nicht ins kprintf(), das einfach das ASCII-Zeichen ausgibt (machst du ja für Strings auch schon), sondern in deine Eingabefunktion.

57

Softwareentwicklung / Re: .img datei laufen lassen

« am: 25. April 2016, 09:40 »

Verstehe ich das richtig, dass du gerade ein Image produziert hast, aber keine Ahnung hast, was du da überhaupt getan hast und was das für ein Image ist?

Ich vermute, du hast irgendeine Form von Bootsektor geschrieben. Der sieht allerdings unterschiedlich aus, je nachdem, ob er für eine Festplatte (MBR oder Partition?), Diskette oder CD gedacht ist. Meine Vermutung ist, dass du eins von den alten Tutorials benutzt hast, die einen primitiven Floppy-Bootloader haben, der einfach von den nächsten paar Sektoren einen Kernel nachlädt. Dann musst du dein Image auf die Größe einer Diskette bringen (1440k, einfach hinten mit Nullen auffüllen) und es dann deinem Emulator als Diskettenimage geben (z.B. qemu -fda floppy.img).

Weil du aber hier eindeutig Dinge zu machen scheinst, die du nicht wirklich verstehst, und weil selbstgeschriebene (oder zusammenkopierte) Bootloader zuverlässige Quelle für zukünftige Probleme sind, deren Debugging kein Spaß macht, und weil anständige Bootloader eher fortgeschrittene Kenntnisse brauchen, würde ich dir dringend empfehlen, stattdessen einen Multiboot-konformen Kernel zu bauen und z.B. GRUB, syslinux oder den in qemu eingebauten Loader (-kernel) zum Booten zu benutzen.

Unsere allgemeine Empfehlung hier ist, mit dieser Tutorialreihe im Wiki anzufangen.

58

tyndur / Re: Der große tyndur-Blog-und-Twitter-Ersatzthread

« am: 04. April 2016, 00:08 »

Eine geöffnete Datei zu löschen macht den Dateisystemtreiber kaputt (führt zu use after free, also 0xd00fc0de). Das ist schade, weil Öffnen und direkt wieder Löschen eigentlich eine gängige Weise ist, mit temporären Dateien umzugehen. Konkret macht das auch mutt in mutt_pager(). Wenn man das unlink() auskommentiert, stürzt nichts mehr ab, aber aus irgendeinem Grund zeigt er trotzdem nur eine Mail an. Die temporäre Datei enthält statt der kompletten Mail nur ein einziges Byte, nämlich '\n'.

59

tyndur / Re: Der große tyndur-Blog-und-Twitter-Ersatzthread

« am: 02. April 2016, 17:40 »

Es gibt jetzt übrigens wieder neue Nightlies. Die URL, die neue Builds triggert, hatte sich verändert und deswegen gab es keine mehr.

Neben ein paar Bugfixes ist die Unterstützung für erweiterte Partitionen jetzt neu. Außerdem habe ich an Patches gewerkelt, die zusätzliche IDE-Controller unterstützen (was bei SATA im IDE-Modus häufiger mal vorkommt), aber das ist noch nicht in master, sondern nur in meinem ide-Branch. Testen konnte ich das leider noch nicht, weil ich meines Wissens keine Hardware rumstehen habe, bei der dieses Szenario vorkommt. Testberichte von euch wären also hilfreich.

Edit: Ups, sehe grad, dass die vorherigen Änderungen noch gar nicht erwähnt wurden. hdaudio hat einen größeren Treiberumbau hinter sich und tut inzwischen auf dem T500. Nachdem das Interface standardisiert ist, sollte es auch auf anderer echter Hardware gehen. e1000e ist nach wie vor ein bisschen hakelig, aber geht prinzipiell jetzt auch mit der aktuellen git-Version. Die fehlenden Instruktionen im VM86-Monitor sind auch ergänzt, so dass ich jetzt auch bunt bekomme (sobald ich mal ein serielles Kabel hatte, war das trivial zu debuggen ). Für rtl8168b ist der Treiber im Repo und wird gebaut, aber setup richtet diese Karte noch nicht automatisch ein. Soviel zur Hardwareseite.

Außerdem gibt es jetzt ein Verzeichnis dev:/fs/, indem Symlinks zu mountbaren Dateisystemen abgelegt werden. Für jedes CDI-Storage-Gerät, das auftaucht, werden die Dateisystemtreiber gefragt, ob sie damit was anfangen könnten, und wenn ja, wird der Link (Dateiname = Volumename) angelegt. Wenn man also dem Rootdateisystem einen Namen gibt, kann man z.B. von dev:/fs/tyndur-boot booten, ohne sich darum kümmern zu müssen, ob das jetzt IDE oder AHCI ist, oder ob es das erste oder zweite CD-Laufwerk ist.

Ich glaube, das war's, aber für die durchschnittliche Aktivität in tyndur ist das ja eine ganze Menge.

60

Das Wiki / Re: Video-Tutorial auf YouTube

« am: 23. March 2016, 14:38 »

Ich fürchte, ich werde generell kein Fan von Video-Tutorials mehr werden, da fehlt mir einfach die Möglichkeit, gezielt nach etwas zu schauen oder es zu überfliegen ohne massiv Zeit zu investieren, um das komplette Ding anzuschauen. Aber ich habe gehört, dass es andere gibt, die das anders sehen, und für die ist es natürlich schön, ein brauchbares Tutorial zu haben, das mehr als einen 512-Byte-Hello-World-Bootsektor abdeckt. Den ersten Teil der Serie habe ich mir mal angeschaut und obwohl ich das eine oder andere im Detail anders gemacht hätte, sieht mir das bis hierher alles vernünftig und vertretbar aus.

Nur schade, dass du es nicht auf Deutsch aufgenommen hast, das wäre gerade aus unserer Perspektive von Lowlevel noch schöner gewesen.