Nachrichten

61

Lowlevel-Coding / Re: Bootfähiges Programm friert ein, wenn Enter gedrückt wird

« am: 16. March 2016, 10:26 »

Vermutlich Geschmackssache und auch eine Frage davon, ob man wissen will wie x86 funktioniert oder einfach nur irgendeine Architektur. Ich mag klassisches OS-Dev auf dem PC.

Mein Ziel ist es nicht ein Betriebssystem oder einen vollwertigen Bootloader zu schreiben, sondern mein grundsätzliches Verständnis für das Zusammenspiel von Software und Hardware auszubauen.

Du musst dir halt bewusst sein, dass du noch gar direkt auf Hardware zugegriffen hast. Du bist im Moment dabei, was über das Zusammenspiel von DOS-Programmen und dem BIOS zu lernen. Das ist sicherlich historisch interessant, aber heute nicht mehr ganz so praxisrelevant.

Man kann natürlich auch im Real Mode tatsächlich die Hardware ansteuern statt BIOS-Interrupts zu benutzen, aber in dem Fall ist der RM dann eher hinderlich als nützlich, weil er so viele Einschränkungen (vor allem im Hinblick auf die Speichergröße) mit sich bringt. Deswegen empfehlen wir eigentlich immer, GRUB (oder was anderes Multiboot-fähiges) als Bootloader zu benutzen und direkt im PM zu starten.

62

Lowlevel-Coding / Re: Bootfähriges Programm friert ein, wenn Enter gedrückt wird

« am: 15. March 2016, 19:49 »

Es ist Real-Mode-Assembler-Code. Reicht das nicht, um als komisch und idiotisch durchzugehen?

63

Lowlevel-Coding / Re: Bootfähriges Programm friert ein, wenn Enter gedrückt wird

« am: 15. March 2016, 16:08 »

Auf den ersten Blick: Wenn du mit jmp (bzw. je) nach LineBreak springst, dann kommst du mit ret nicht zurück. Was passiert ist, dass er dein gepushtes 0xd vom Stack nimmt und als Rücksprungadresse benutzt.

64

Lowlevel-Coding / Re: Byte aus speicher lesen, bit verändern und Byte wieder im speicher ablegen

« am: 14. March 2016, 11:57 »

Wenn du gar nicht weiterkommst, kannst du mal deinen kompletten Code irgendwo online stellen, dass man das im Komplettzusammenhang sehen und evtl. auch damit spielen kann. Ich bin mir noch nicht sicher, ob ich Zeit habe, das für dich zu debuggen, aber vielleicht springt ja jemand anderes ein.

65

Softwareentwicklung / Re: Os-Anfang

« am: 12. March 2016, 23:03 »

Hey, willkommen im Forum!

Erst einmal wäre es gut zu wissen, welcher Anleitung du gefolgt bist. Da du eine kernel.bin hast, gehe ich davon aus, dass es nicht unser empfohlenes Tutorial im Wiki ist, denn das nennt die Ausgabedatei anders. Das wichtigste zu wissen wäre, was du eigentlich geschrieben hast: Real-Mode-Code, der in den Bootsektor geschrieben werden muss, oder ein Multiboot-Kernel, der z.B. mit GRUB gebootet werden kann, oder was ganz anderes.

Grundsätzlich wird es nicht reichen, eine Datei einfach auf das Dateisystem auf dem Stick zu kopieren. Der Stick muss bootbar sein, das heißt du musst irgendeine Art Bootloader darauf installieren. Die Laufwerksbezeichnung spielt auf jeden Fall keine Rolle.

66

Lowlevel-Coding / Re: Byte aus speicher lesen, bit verändern und Byte wieder im speicher ablegen

« am: 09. March 2016, 13:13 »

wie meinst du das: "Adress- und Datenregister gleichzeitig mit einem outw zu setzen"?

Das hier:

Code: [Auswählen]

outportw(0x3c4,0x0102);//plane 0Ich hätte da eher sowas erwartet:

Code: [Auswählen]

outportb(0x3c4,0x02); // Adressregister auf Index von Map Mask Register setzen
outportb(0x3c5,0x01); // Mit Datenregister den Wert des MMR setzen

wenn es mit: [...] geht, sollte es ja auch mit einem byte gehen^^

Du meinst, dein int32_clear_screen_0x12() funktioniert? Das hattest du bisher nicht erwähnt.

67

Lowlevel-Coding / Re: Byte aus speicher lesen, bit verändern und Byte wieder im speicher ablegen

« am: 09. March 2016, 12:17 »

Hier gibt es ein bisschen mehr Doku: http://www.osdever.net/FreeVGA/vga/vga.htm

Bist du dir sicher, dass es eine gute Idee ist, Adress- und Datenregister gleichzeitig mit einem outw zu setzen statt erst die Adresse und dann die Daten jeweils mit outb?

(k_memcpy sieht okay aus. Nur das Textmodus-Testprogramm ist strenggenommen kaputt, weil Ausgabe nicht nullterminiert ist.)

68

Lowlevel-Coding / Re: Byte aus speicher lesen, bit verändern und Byte wieder im speicher ablegen

« am: 09. March 2016, 11:28 »

Auch hier nochmal herzlich willkommen im Forum, falls du die PN noch nicht gelesen hast.

Wenn du sagst, dass k_memcpy() die Daten nicht richtig liest, heißt das, dass du das Zwischenergebnis nach dem Holen der Bytes ausgegeben hast und schon das nicht stimmt? Dann müssen wir uns den Rest nämlich gar nicht erst anschauen.

Theoretisch denkbar ist, dass dein k_memcpy() nicht richtig funktioniert, kannst du es mal posten? Ansonsten wäre es wahrscheinlich, dass VGA doch nicht so funktioniert wie du denkst. Wie das genau geht, weiß ich aber auch nicht auswendig und müsste es erstmal nachlesen.

Und dann wäre natürlich noch die Frage, wieso du dir überhaupt Modus 12 antust, wenn es heute vernünftige Auflösungen mit genug Farben gibt.

69

Lowlevel-Coding / Re: [PCI] Interrupts ändern

« am: 04. March 2016, 14:05 »

Eigentlich hatte ich nicht vor das ganze AML zeugs jetzt schon zu verwenden

APIC != ACPI

Letzteres kann man wohl auch irgendwie benutzen, aber der APIC sollte genug können, um die Zuordnung zu machen. Im Netz habe ich auf die Schnelle das hier gefunden, vielleicht ist es nützlich: http://people.freebsd.org/~jhb/papers/bsdcan/2007/article/node5.html

Was ich nicht verstehe ist, warum im Status Register der jeweiligen PCI Karte der Status in Virtualbox nicht gesetzt wird
Geht das denn nur wenn auch min. 2 Geräte die gleiche IRQ haben und vorher nicht? o.o

Entweder du machst was falsch oder VirtualBox ist buggy. Bei einem Feature, das wahrscheinlich nicht besonders oft benutzt wird, würde ich das nicht ausschließen, dass es nicht oder nicht richtig emuliert wird.

70

Lowlevel-Coding / Re: [PCI] Interrupts ändern

« am: 04. March 2016, 11:02 »

Der PCI-Configspace hilft dir da leider nicht weiter. Wenn ich es noch richtig weiß, wird das IRQ-Feld da nur beim Start vom BIOS reingeschrieben, damit das OS die Information hat. Wenn du das überschreibst, änderst du also nur die Information für dich und nicht wirklich die Konfiguration des Geräts.

Ich habe selber noch nie die Interruptnummern umkonfiguriert, aber du wirst auf jeden Fall den APIC dafür brauchen, der PIC kann das meines Wissens nicht.

71

tyndur / Re: Nightly Builds

« am: 01. March 2016, 13:52 »

klar geht das, aber ich sag halt pro Job ein Repository und jeder Job wird in seinem eigenen Workspace ausgeführt. Schritt 1 ist halt git clone/pull. Mir erscheint es etwas bloated für jedes kleine Programm das komplette lpt-Repo zu haben^^

Naja, die Größe des lpt-Repos ist echt überschaubar, da sind ja nur ein paar Skripte und Patches drin:

Code: [Auswählen]

$ du -sh lbuilds/
2,6M    lbuilds/
Was du aber auf jeden Fall haben willst ist ein persdistenter lokaler Cache von den Tarballs, die lbuilds runterlädt. Also vermutlich distfiles/ als Symlink auf ein gemeinsames Verzeichnis außerhalb des temporären Testverzeichnisses. (Ich gehe jedenfalls davon aus, dass jeder Build in einem sauberen Verzeichnis gestartet wird?)

Ja, einfach die Adresse https://praios.lf-net.org/jenkins/job/T%C3%BDndur/build POSTen^^
Dann wird automagisch gebaut

Kann ich heute abend mal versuchen, wenn ich ein paar freie Minuten habe.

Nen Tyndur-Qemu kann ich starten, Jenkins kann den KVM-Host unter Praios steuern (und tut das z.B. für Ingerimm)

Ok, dann könnte das klappen. Dürfte trotzdem noch ein bisschen Gebastel geben bis das dann tut, aber du willst ja auch noch ein bisschen was zu tun haben.

72

tyndur / Re: Nightly Builds

« am: 01. March 2016, 12:04 »

Am coolsten wäre ja die lpt-Pakete alle als eigene Jobs im Jenkins einzutragen, dann werden die getrennt als OK/FAIL angezeigt und können einzeln aktualisiert werden.
Dafür wäre es am coolsten wenn jedes ein eigenes Git-Repo hätte ... Kann man ja per Submodul in das große Repo mit einbinden.

Hm, braucht es das? Kann man nicht mehrere Jobs pro Repository definieren?

Dann noch ein Script um das automatisch in ein lpt-Repo zu pushen und das Repo im Image mit drin wäre schonmal ne richtige Distri^^

Dieser Teil sollte eigentlich kein großer Aufwand sein. Lokal bei mir habe ich ja auch schon ein Skript, das lpt-Pakete einsammelt, ins lpt-Repo und eine packages.i386 erstellt. Mein Skript nimmt allerdings nur den Dateinamen auseinander und hat keine Paketbeschreibungen und so. Das sollte man richtig machen und die Paketinformationen aus dem Tarball nehmen. Aber das ist alles kein Hexenwerk.

Und zum Schluss noch eine Standardauswahl an Paketen als Config-Datei mit ins Týndur-Repo und beim Image bauen die lpt-Pakete in das rootfs rein entpacken

Dieser Teil ist ein bisschen tricky weil die Pakete Postinstall-Skripte haben, die natürlich unter tyndur laufen müssen und nicht unter dem Hostsystem. Das heißt, da müsste man einen qemu starten mit einem vollständig automatisiert laufenden tyndur, das die Skripte abarbeitet und dann herunterfährt.

Zum Schluss noch automatisch bauen wenn jemand pusht und fertig ist das coole automagische Buildsystem

Was brauchst du für sowas? Die entsprechenden git-Hooks gibt es ja, wenn ich da irgendeinen HTTP-Request abschicken muss oder so, ist das machbar.

73

tyndur / Re: Nightly Builds

« am: 01. March 2016, 09:32 »

Sehr cool. Jetzt müssen wir nur noch schauen, dass sich der Code auch ab und zu ändert.

In Bezug auf lpt sollten wir uns bei Gelegenheit übrigens mal was einfallen lassen, wie wir automatisch Pakete auf Images vorinstallieren können.

74

Lowlevel-Coding / Re: ATAPI CD/DVD-ROM lesen

« am: 10. February 2016, 14:30 »

Der Code sieht sehr nach IDE aus (außer dass auch da die Portnummern nicht passen würden, wenn ich mich nicht sehr täusche). Wenn du wirklich ein AHCI-Gerät hast, dann ist das nicht, wie du es ansprichst. IDE und AHCI sind zwei ziemlich unterschiedliche Interfaces, auch wenn beide zusammen mit dem ATA-Befehlssatz benutzt werden.

75

Lowlevel-Coding / Re: [QEMU] AC97 driver - Kein Sound

« am: 08. February 2016, 10:27 »

Ebenfalls komplett ohne Ahnung vom konkreten Chip, aber ich würde davon ausgehen, dass Daten nachfüllen allein nicht reicht, sondern man den Interrupt irgendwie acken muss (oft durch Schreiben in ein Interruptstatusregister).

76

Lowlevel-Coding / Re: Problem mit Multitasking [OSDEV - Einsteiger]

« am: 29. January 2016, 17:59 »

Tut es denn mit sti immer noch nicht? Das wäre auch das, worauf ich getippt hätte, und ich sehe es in deinem Code beim Initialisieren der IDT nicht.

Den Tutorialkernel zum Stand direkt nach der Implementierung von Multitasking findest du hier.

77

Lowlevel-Coding / Re: anfängerfrage: problem mit tutorial

« am: 21. January 2016, 18:50 »

Man kann nicht nur Paging, sondern allgemein keine x86-Prozessoren ohne Segmentierung benutzen. Ist einfach nicht abschaltbar, auch wenn man meistens nichts sinnvolles damit anstellt, wenn man Paging hat.

Bei x86_64 ist die Segmentierung noch ein bisschen verkrüppelt worden, indem für die meisten Segmentregister Basis 0 und volles Limit angenommen wird, d.h. selbst wenn man wollte, könnte man mit Segmentierung nicht mehr viel anfangen, aber konfigurieren muss man es immer noch. fs und gs berücksichtigen die Basis noch, deswegen werden die gerne für Sachen wie TLS benutzt.

78

Lowlevel-Coding / Re: anfängerfrage: problem mit tutorial

« am: 21. January 2016, 11:08 »

Bitfelder sind zwar nicht portabel, aber für solche (ohnehin nicht portablen) Datenstrukturen auch eine gute Idee.
Also eine Union aus dem Bitfeld und einem uint64_t (oder char[8]).

Du wirfst hier Portabilität zwischen Zielarchitekturen und Portabilität zwischen Buildumgebungen durcheinander. Bitfelder sind nie eine gute Idee, wenn du eine bestimmte Anordnung brauchst, weil die Anordnung schlicht undefiniert ist.

Solltest du der Funktion lgdt() nicht eher die Adresse von ptr mitteilen? Stimmt die ABI für den Aufruf?

Das ist auch das enizige ernsthafte Problem, das mir auffällt.

79

Lowlevel-Coding / Re: Vorhandene S-ATA-Controller werden nicht erkannt

« am: 16. January 2016, 15:13 »

Mit reinen ISA-Controllern meine ich welche, die an den Standard-I/O-Ports sitzen, zu denen es aber kein passendes PCI-Gerät gibt (damit kann man dann natürlich auch kein DMA machen).

80

Lowlevel-Coding / Re: Vorhandene S-ATA-Controller werden nicht erkannt

« am: 16. January 2016, 12:43 »

Ich habe es jetzt mal verglichen mit der Asugabe von lspci und da ist mir dann aufgefallen, dass mein Code immer nur die Funktion 0 des Gerätes prüft. Nach dem Fix erkennt es jetzt den onboard SATA Controller und findet somit auch meine SSD und HDD, die daran angeschlossen sind.

Prüfst du auch ordentlich, ob es überhaupt ein Multifunktionsgerät ist, bevor du die Funktionen prüfst, oder gehst du immer alle Funktionen durch?

Aber mal ne Frage zum CDI ATA-Treiber: Wie wäre es eigentlich, wenn man dort die Unterstützung von mehreren Controller einbaut, denn auf meinem anderen Test-PC habe ich zwei ATA-Controller aber nur der erste wird erkannt => es wird nur das CDROM-Laufwerk erkannt aber nicht die Festplatte, die sich am zweiten Controller befindet. Die Controller sind getrennt auf dem PCI-Bus.

Ich bin mir sicher, dass niemand etwas dagegen hat, den Code ins CDI-Repository zu übernehmen, wenn du den Treiber entsprechend erweiterst. Ich denke, man muss ein kleines bisschen aufpassen, dass man reine ISA-Controller nicht kaputtmacht (falls irgendjemand noch sowas hat...) und der erste Controller auch nicht doppelt auftaucht, aber an sich sollte die Erweiterung nicht schwer sein.