Thema: HAL

[ChristianF]

Ich dachte an so was, wie erst schauen, welche CPU vorhanden ist und dann den jeweiligen code ausführen, z.B. für 386 initialise_kernel_386(mbt).
 
Allerdings muss beim HigherHalf Kernel das Paging zuerst aktiviert werden, bevor irgendwas anderes gemacht werden kann, oder ich habe da was falsch verstanden.
Ich werde dass dan so lösen, dass ich bei GRUB die Auswahl lasse, was geladen werden soll.

• Kernel x86
• Kernel x86_64
• Kernel PowerPC

usw.
 
Gruß Christian

[bluecode]

Ich dachte an so was, wie erst schauen, welche CPU vorhanden ist und dann den jeweiligen code ausführen, z.B. für 386 initialise_kernel_386(mbt).

Wie gesagt, der Maschinencode sieht schon komplett anders aus, auch die ELF Datei sieht anders aus. Da kann nur Mist rauskommen, wenn du die auch nur versuchst zu laden. Und wenn du das dann auch noch auf einer anderen Arch ausführen willst wird da nur Mist rauskommen.
 

Allerdings muss beim HigherHalf Kernel das Paging zuerst aktiviert werden, bevor irgendwas anderes gemacht werden kann, oder ich habe da was falsch verstanden.

Das ist falsch. Du kannst in einem Assemblerstub soviel machen wie du willst, wenn du beachtest, dass die Labels eben auf die falsche Adresse zeigen.

Ich werde dass dan so lösen, dass ich bei GRUB die Auswahl lasse, was geladen werden soll.

Grub legacy kann afaik nur x86 (und nur mit Patch x64). Soll sich aber mit grub2 afaik ändern.

[Korona]

Ja, um verschiedene Kernels kommst du auch mit HAL nicht herum. Wenn du ein HAL benutzt ist aber der Anteil des Codes den du für jede Architektur neu schreiben musst geringer als ohne .
Wie bluecode gesagt hat würde ein Kernelimage für viele Architekturen schon allein vom Format der Instructions her nicht funktionieren.

Zum HigherHalf Kernel:
Du kannst natürlich auch solange Paging noch deaktiviert ist Teile des Systems initialisieren (z.B. lesen der GRUB Infos), nur ist das je nach verwendeter Programmiersprache schwierig zu handhaben. In C musst du alle Pointer auf globalen Addressen anpassen, in Assembly ist das ganze wsl. noch etwas übersichtlicher da du ja alle Speicherzugriffe die dein Kernel macht kennt (und somit die Gefahr geringer ist das du Zugriffe auf globale Variablen übersieht). Im Allgemeinen ist es jedoch empfehlenswert schnell Paging zu aktivieren um nicht ganz triviale Addressmanipulationen zu vermeiden .

[kevin]

Wie gesagt, der Maschinencode sieht schon komplett anders aus, auch die ELF Datei sieht anders aus. Da kann nur Mist rauskommen, wenn du die auch nur versuchst zu laden. Und wenn du das dann auch noch auf einer anderen Arch ausführen willst wird da nur Mist rauskommen.

Es sei denn, er hat einen genialen Hack gebastelt, der auf allen unterstützten Architekturen "zufällig" genau den passenden Sprung macht. Gibt ja auch Programme, die sich mit zig Sprachen kompilieren lassen, weil geschickt Kommentare usw. genutzt werden. Wäre mal ein lustiges Experiment.

[ChristianF]

Okay.
Bin grad am reorganisieren des Codes. 
Nun habe ich einen "Bildschirm Treiber", der Text mittels printf ausgibt.
Theoretisch müsste dieser doch auch in das HAL, zumindest solange, wie er vorhanden ist.
Denn der VideoRAM ist ja nicht überall an der Stelle 0xB8000, bzw. in meinem Fall 0xC00B8000.
 

Es sei denn, er hat einen genialen Hack gebastelt, der auf allen unterstützten Architekturen "zufällig" genau den passenden Sprung macht. Gibt ja auch Programme, die sich mit zig Sprachen kompilieren lassen, weil geschickt Kommentare usw. genutzt werden. Wäre mal ein lustiges Experiment.

Solch einen Hack habe ich leider nicht. 

* EDIT *
Ich habe da noch eine Frage bezüglich nasm und macros.
Kann ich folgendes Macro verwenden:

Code: [Auswählen]

%macro IRQ 1
    global irq%1
    irq%1:
        cli
        push byte 0
        push byte %1+32
        jmp irq_common_stub
%endmacro
Es wird keine Fehlermeldung ausgegeben, ich kann es momentan allerdings auch nicht ausprobieren.

[bluecode]

Denn der VideoRAM ist ja nicht überall an der Stelle 0xB8000, bzw. in meinem Fall 0xC00B8000.

Der VideoRAM ist auch nicht bei allen Architekturen gleich aufgebaut und bei einigen Dinger gibts sowieso nur Grafikmodi (afaik PDAs und irgendwie auch PowerPCs).

Es sei denn, er hat einen genialen Hack gebastelt, der auf allen unterstützten Architekturen "zufällig" genau den passenden Sprung macht. Gibt ja auch Programme, die sich mit zig Sprachen kompilieren lassen, weil geschickt Kommentare usw. genutzt werden. Wäre mal ein lustiges Experiment.

Solch einen Hack habe ich leider nicht. 

So einen Hack gibt es im Allgemeinen auch nicht.

Der Nasm-Code lässt sich bei mir assemblieren. Es wäre nicht schlecht deine Fehlermeldung zu sehen. Evtl. irq_common_stub als extern deklarieren?

[Korona]

So einen Hack gibt es im Allgemeinen auch nicht.

IIRC habe ich mal so einen Hack für 2 oder 3 Architekturen gesehen. Ich weiß aber nicht mehr wo das war. Aber auch mit so einem Hack macht es natürlich keinen Sinn nur ein Kernel-Image zu verwenden. Der Hack wäre ja ausserdem nicht erweiterbar auf andere Architekturen.

[bluecode]

So einen Hack gibt es im Allgemeinen auch nicht.

IIRC habe ich mal so einen Hack für 2 oder 3 Architekturen gesehen. Ich weiß aber nicht mehr wo das war. Aber auch mit so einem Hack macht es natürlich keinen Sinn nur ein Kernel-Image zu verwenden. Der Hack wäre ja ausserdem nicht erweiterbar auf andere Architekturen.

Jo exakt den Hack habe ich auch gesehen, kann ihn aber nicht mehr finden. Aber wie du schon sagst, dass ist nur sehr beschränkt möglich und macht keinen Spaß zum Zusammenfrickeln.

[ChristianF]

Da ich sowas nicht machen will, bastel ich gerade an einer Funktion, die mir ausgibt und zurück gibt, welcher Prozessor installiert ist.
Je nachdem, ob das ein Intel 386 oder ein PowerPC  o.ä. ist, wird dann die entsprechende Funktion zur Initialisierung des Kernels ausgeführt.
 
Gruß Christian
 
PS: Ich hoffe, das geht so, wie ich mir das vorstelle 

[kevin]

Damit diese Funktion auf allen Prozessoren läuft, müßte sie eben genau dieser Hack sein. Normal baust du einfach für jede Architektur den Kernel einmal durch und hast dann für n Architekturen eben n Binaries.

[Korona]

Das ganze wird nicht funktionieren, da die Anweisungen der Prozessoren ganz anders aussehen. Auf dem x86 wird ein jmp Befehl zum Beispiel zu der Bitsequenz 0xFF 0x12345678 assembliert. Auf einem ARM, MIPS oder PPC Prozessor stellt die gleiche Bitsequenz einen völlig anderen Befehl dar, falls diese Bytesequenz überhaupt gültig ist. (aufgrund von Alignments auf RISC Prozessoren oder einfach dadurch dass es keinen Opcode gibt der mit 0xFF beginnt)

[ChristianF]

Aber zu irgendwas muss der Befehl CPUID ja gut sein.
Zumindest kann ich herausfinden, ob der installierte Prozessor z.B. mehr als 4 GB RAM unterstützt (Pentium Pro, glaub ich).
Des Weiteren kann ich auch herrausfinden, ob ich einen 64 Bit Prozessor habe und ob und wenn ja, welcher AMD prozessor installiert ist.
 
Mal schauen, was sich damit noch so alles anstellen lässt 
 
Gruß Christian

[FreakyPenguin]

Jo, dieser x86-Befehl gibt dir genauere Informationen über den x86-Prozessor aus. Das heisst aber nicht, dass andere Architekturen diesen Befehl auch unterstützen. CPUID wird meist nur benutzt um festzustellen, ob der Prozessor ein bestimmtes Feature unterstützt, bevor man es benutzt, damit der Prozessor nicht mit Exceptions um sich wirft.

[ChristianF]

Und genau das habe ich nun vor.
Obwohl mir die Verwaltung von max. 64GB momentan noch ein Rätsel ist, das es zu lösen gibt. 

Trotzdem Vielen Dank für die Antworten auf meine Fragen, die Reorganisierung meines Kernel-Codes ist nun in vollem Gange.

Gruß Christian
 
PS: Ich vereinfache mal wieder meine Speicherverwaltung 

[ChristianF]

Moin
Nochmal so eine konzeptionelle Frage :
Wäre es besser den PCI-BUS mit in den Kernel einzubauen, oder ihn als Treiber auszulagern?
 
Gruß Christian

[Korona]

Das lässt sich nicht allgemeingültig sagen, das kommt stark auf deinen Kernel an. Ich habe einen Microkernel also lagere ich den PCI Treiber aus. Monolithische Kernel möchten den PCI Bus vielleicht innerhalb des Kernels verwalten.

[bluecode]

Monolithische Kernel möchten den PCI Bus vielleicht innerhalb des Kernels verwalten.

Oder auch als Kernelmodul, aber ich denke PCI ist so wichtig, dass man das in einem monolitischen Kernel wahrscheinlich direkt (also nicht über Module) unterstützen möchte.

[ChristianF]

Nun gut.
Dann werde ich das als Treiber auslagern, da ich mich an einem Mikrokernel versuche.
 
Gruß Christian