Thema: Sektoren von Floppy Disk laden

[kevin]

Das ist dann aber immer noch nichts eigenes, sondern nur ein anderes fremdes Fertigprodukt.

[Gamepower]

tritt das problem auch mit "rawrite", oder "rawritewin" auf...? vieleicht löst sich das problem ja von selbst, wenn du einfach das programm zum schreiben der diskette wechselst...

[kevin]

Booten von USB geht im allgemeinen so, dass das BIOS ein großes Floppylaufwerk emuliert. Sollte sich also für einen Bootloader, der nur über BIOS-Funktionen drauf zugreift, genau gleich anfühlen. Sobald dein OS dann aber im PM ist, brauchst du natürlich wieder selber Treiber - und USB ist nicht ganz trivial.

[Jidder]

Hi,

ich hab mal deine Version 73 runtergeladen und seziert. Allerdings meine Vermutung nicht getestet, weil ich dazu zu faul bin ^^

Die BSS-Sektion deines Kernels beginnt an Offset 0x8860. Deine Kernel Binary ist allerdings kleiner. Die BSS-Sektion ist also nicht in der Datei enthalten. Dein selbstgebauter Bootloader lädt aber einfach wie blöde die Sektoren, die zu diesem Bereich gehören.

An dieser Stelle können sich also je nach Art der Erstellung der Diskette/des Images beliebige Daten befinden. Der Kernel erwartet allerdings, dass die BSS-Sektion mit Nullen gefüllt ist.

Wenn sie das nicht ist, dann gehen so Abfragen wie vermutlich in diesem Fall in paging.c schief:

Code: [Auswählen]

extern heap_t* kheap;
...
// kheap initialisiert?
if( kheap!=0 ) { kheap benutzen }

Den üblichen Kommentar kann ich mir nicht verkneifen: GRUB hätte die BSS-Sektion zuverlässig genullt.

[Jidder]

Kann man das via Linkerskript einbeziehen und auf Null setzen?

Glaube nicht

Dann wäre bei mir wohl kernel.asm der richtige Ort für diese Aktion?

Jep. Weil dein Kernel eine flache Binary ist, ist das auch der einzige Ort.

Ich hab keine konkrete Dokumentation gefunden, in der genaues zu COMMON beschrieben ist. Im Prinzip gehört es wohl auch in die BSS-Sektion und damit mit Nullen gefüllt. In meinem Standard-Linker-Skript ist sieht der .bss-Block deswegen so aus 

Code: [Auswählen]

.bss :
{
    *(.bss)
    *(COMMON)
}

[kevin]

Booten von USB geht im allgemeinen so, dass das BIOS ein großes Floppylaufwerk emuliert.

Hast Du dazu einen Link, habe das bisher nicht gefunden, möchte nicht vom Regen in die Traufe kommen. 

Hm, ich wüsste da jetzt nichts spezielles dazu. Aber viel mehr gibt es da ja auch gar nicht zu wissen als dass das BIOS einfach das richtige macht.

Wenn deine Probleme aber nicht an kaputten Disketten liegen, sondern an deinem Code, wirst du mit USB-Sticks vermutlich auch nichts gewinnen. Außer eben, dass du im PM nicht mehr so leicht einen Treiber geschrieben bekommst wie für echte Floppys.

[kevin]

Hm, also eigentlich ist ein Floppytreiber im PM/LM viel lowleveliger als das BIOS-Interface im RM. Das BIOS ist ja letztendlich nur eine Bibliothek, die das für dich erledigt. Auch wenn ihre Schnittstellen teilweise so gestaltet sind, dass man sich tatsächlich eine Weile damit aufhalten kann, sie richtig anzusprechen.

[kevin]

der Hinweis auf GRUB leider sinnvoll. Dennoch empfinde ich dies als Einengung, denn man wird praktisch auf einen Rechner gezwungen, der GRUB verwendet, damit zu Linux getrieben. 

Das ist Blödsinn und wird durch Wiederholung nicht richtiger. GRUB ist ein Bootloader, der mit Linux nur zu tun hat, dass das eins der vielen Systeme ist, das er laden kann. Warum sagst du nicht, man wird zu Hurd getrieben, da kommt er ja schließlich her? Oder zu tyndur, Xen, NetBSD usw., die kann er ja auch alle laden?

EDIT: Problem momentan entschärft. Der Algorithmus von PorkChicken ist zum Glück o.k. Das Schlimme ist, dass man bei allen Problemen im Kernel, die nicht überall gleichermaßen auftreten, den eigenen Bootloader im Verdacht hat.

Naja, das sagt viel darüber aus, wie sehr du deinem Bootloader vertraust. In dem Fall solltest du vielleicht nochmal eine Weile dran arbeiten, bis du ihm genug vertraust. Keiner hier sagt dir, du musst GRUB nehmen. Aber wir sagen, wenn du es nicht tust, musst du ernsthaft Zeit in deinen eigenen Bootloader investieren, bevor du mit deinem OS richtig anfangen kannst. Ob du dazu bereit bist, ist deine eigene Entscheidung.

OS steht z.Z. absolut stabil. Fehler ist eindeutig im VFS/RAM-Disk-Code von JM (bei root->nodes). Nach Umgehung der VFS/RAM Disk läuft das OS stabil:
http://www.henkessoft.de/OS_Dev/Downloads/85.zip

Hättest du nicht vorher sagen können, dass das eine tar-Bombe im zip-Format ist? 

Na gut, wie auch immer, gebaut bekommen habe ich es irgendwie. Ich nehme nur an, dass es nicht richtig ist, wenn nach "loading kernel" nur noch eine Zeile Sternchen kommt, oder? Wenn ich das Ding mal gebootet bekomme, würde ich mir vielleicht auch den PF anschauen. PFs debuggen ist aber sowieso die Alltagsarbeit in der OS-Entwicklung. Damit solltest du mit der Zeit selbst zurechtkommen.

Im Code sehe ich kein root->nodes, nur ein root_nodes. Wenn es tatsächlich daran liegen sollte, spricht das wohl für einen Fehler in deinem k_malloc. Möglicherweise ist der Fehler aber auch nur in diesem Block und kommt aber vom Zugriff auf eine andere Struktur. Da hilft nur Code disassemblieren und anschauen, was genau schiefgeht (oder einen gdb dranhängen und die einzelnen Werte ausgeben lassen).

Wer sich für OS-Entwicklung von Grund auf (also ohne GRUB) interessiert

Missverständnis. Bootloader-Entwicklung ist ein verwandtes Thema, aber kein Teilgebiet der OS-Entwicklung.

[DerHartmut]

tyndur ist aufgrund der langen Entwicklungszeit für viele bereits zu weit fortgeschritten und daher zu komplex.

Naja, also wenn man ein wenig Zeit investiert und sich durch den Quellcode liest und dabei noch die doxygen-Dokumentation nutzt, blick tman doch durch tyndur durch (gut, nicht in jede kleinste Ecke ).

Eine Einsteiger-Doku existiert nicht.

Das bringt mich auf eine Idee...man könnte doch den "alten" Soruce von ehemals LOST 0.1.0 nehmen und diesen "verdokumentieren", sodass für Einsteiger eine solide Basis vorhanden ist und man anhand von LOST lernen kann. Dann kann man sich in tyndur einlesen (was ja an und für sich kein Weltengroßer Unterschied ist (zumindest im kernel)).

Selbstverständlich gehört der Bootloader zum Betriebssystem dazu.

Das Betriebssystem braucht den Bootloader, damit es selbst geladen wird, dennoch sind Bootloader und OS (wie schon mehrfach in diesem Thread erwähnt) zwei verschiedene Baustellen mit völllig anderen Vorraussetzungen. Beispielsweise muss ein Bootloader nicht multithreading-fähig sein (wieso auch?) und braucht keinen Scheduler, keine 8oder keine vollständige) Hardwareabstraktionsschicht und auch kein großartiges Memory-Management. Wenn man sich den Source von GRUB2 ansieht, macht der Großteil des Source die Verarbeitung/Arbeit mit den unterschiedlichen Dateisystemen aus.

GRUB mag auch nicht jeder.

Gerade junge Leute wollen noch dazu ihr eigenes Ding durchziehen.

Gerade diesen jungen Leuten (womit ich mit mit meinem 18 Jahren einfach mal auch noch zuzähle *g*) sollte man klar machen, dass ein Bootloader nicht das ist was sie möchten, wenn sie ein OS entwickeln wollen. Einen Bootsektor-Kernel, der "Hallo Welt" ausgibt ist was feines für einen Anfänger. Doch spätestens wenn er seinen Kernel selbst laden muss, vergeht ihm die Freude. Da ist man doch erfraut, wenn der Kernel von GRUB geladen wird und man noch eine Menge Informationen (Multiboot sei dank) dazubekommt.

Soviel von meiner Seite, zurück in die angeschlossenen Funkhäuser.

[kevin]

Bootloader-Entwicklung ist ein verwandtes Thema, aber kein Teilgebiet der OS-Entwicklung.

Selbstverständlich gehört der Bootloader zum Betriebssystem dazu.

Nein. Das würde implizieren, dass zu jedem Bootloader genau ein Betriebssystem gehört und dass umgekehrt jedes Betriebssystem genau einen Bootloader hat. Dass ersteres nicht stimmt, sollte eigentlich jeder wissen, der hier mitbekommen, dass es mehr als einen gibt, der sein OS von GRUB booten lässt. Für letzteres nehme ich einfach mal Linux als Beispiel her - Lilo, GRUB, loadlin, syslinux und sicher noch ein paar mehr.

Wenn ich das Ding mal gebootet bekomme

Merkwürdig. PrettyOS verwendet inzwischen die von euch empfohlenen Cross-Tools. Linker-Skript und Makefile sind im zip-File dabei.

Ja, wie gesagt, kompiliert bekomme ich es. Zwar mit händischen Anpassungen der Makefile, aber das kriege ich grad noch hin. Es bootet nur nicht, wie ich mir das vorstelle (es sei denn, du sagst, eine Zeile voll Sterne ist alles, was passieren soll).

Der ist weg, seit ich das fehlerhafte Modul von JM umgehe. PFs kann ich inzwischen auch selbst finden. Das Problem war lediglich, dass er mit VFS/RAM Disk (83 er Version) nur auf manchen real PC aufgetreten ist, teilweise sogar auf dem selben PC verschiedene Reaktion.

Umgehen klingt aber nicht nach einem Fix.

Hast du denn wenigstens die genaue Ursache herausgefunden oder ist es möglicherweise noch ein Bug in deinem Code, der jetzt nur nicht mehr ausgelöst wird?

tyndur ist aufgrund der langen Entwicklungszeit für viele bereits zu weit fortgeschritten und daher zu komplex. Eine Einsteiger-Doku existiert nicht. Gerade junge Leute wollen noch dazu ihr eigenes Ding durchziehen. Selbst PrettyOS ist für einen Anfänger (C, Assembler, OSDEV) nicht in einer Woche begreifbar.

Für wirklich komplex halte ich tyndur nicht. Gerade der Kernel ist ziemlich einfach gestrickt. Aber zugegeben, man könnte ihn wohl wesentlich besser erklären.

Dass es nicht möglich ist, OS-Dev in einer Woche zu meistern, sollte klar sein.

[kevin]

Naja, also wenn man ein wenig Zeit investiert und sich durch den Quellcode liest und dabei noch die doxygen-Dokumentation nutzt, blick tman doch durch tyndur durch (gut, nicht in jede kleinste Ecke ).

Ich kenne auch nicht jede kleinste Ecke. Und bin eigentlich ganz froh darüber.

Das bringt mich auf eine Idee...man könnte doch den "alten" Soruce von ehemals LOST 0.1.0 nehmen und diesen "verdokumentieren", sodass für Einsteiger eine solide Basis vorhanden ist und man anhand von LOST lernen kann. Dann kann man sich in tyndur einlesen (was ja an und für sich kein Weltengroßer Unterschied ist (zumindest im kernel)).

Nein, bitte nicht auf 0.1.0 aufsetzen. Entweder der Code ist im aktuellen Zustand noch der gleiche oder es gibt gute Gründe, warum der Code nicht mehr so ist, wie er war.

[Jidder]

Was nun welche Zeile ist, wäre noch ganz gut zu wissen. Aber ich glaube, wenn du das selbst nachgeschaut hättest, würdest du diese Funktion nicht mit k_strcpy vergleichen.

Was macht die Zeile *dest = *dest++; denn deiner Meinung nach? Ich vermute mal das sollte dest++; heißen.

[kevin]

Ich nehme an, das Problem mit *dest = *dest++ ist, dass nicht definiert ist, ob beim Auswerten des linken *dest schon erhöht worden ist oder nicht.

Das mit dem '<--' finde ich aber schon übel. Da sollte ein Compiler laut aufschreien.

[kevin]

Ja, der Compiler hat meistens recht, wenn er warnt.

[kevin]

Dann solltest du deinen Kernel fixen und die Headerdateien selbst bereitstellen. Headerdateien aus deinem Hostsystem zu nehmen, funktioniert höchstens zufällig.

[Jidder]

Code: [Auswählen]

typedef __builtin_va_list va_list;
#define va_start(ap, X) __builtin_va_start(ap, X)
#define va_arg(ap, type) __builtin_va_arg(ap, type)
#define va_end(ap) __builtin_va_end(ap)
Und schon ist stdarg.h fertig

[kevin]

Zum Vergleich, in tyndur haben wir das:

Code: [Auswählen]

LOST_TOOLS_GCC=$COMPILER_PREFIX"gcc -m32 -g -c -fno-stack-protector -nostdinc -fno-leading-underscore -fno-omit-frame-pointer -Wall -Werror -Wstrict-prototypes -fno-strict-aliasing -O2 -fno-builtin -I ."Was du für wichtig hältst, ist natürlich ein Stück weit auch deine eigene Entscheidung.

[Jidder]

Ja. Damit kannst du im Kernel aber eh nichts anfangen.

[kevin]

Und vor allem hast du sie nicht implementiert. Was gcc an der Stelle nämlich macht, ist dass er einfach nur Aufrufe an die Standardbibliothek einbaut, die dann Prüfungen durchführen soll. Und die Standardbibliothek ist im Kernel bekanntlich deine eigene.

[kevin]

Keine Ahnung, ob es damit was zu tun hat, aber du solltest dir angewöhnen, Rückgabewerte zu prüfen. fwrite garantiert dir nicht, dass es so viel schreibst wie du dir gewünscht hast, es kann auch weniger schreiben (oder gilt das nur für write ohne f?). Deswegen ruft man es normal in einer Schleife so lange auf, bis alles geschrieben ist.