Lowlevel
Lowlevel => Lowlevel-Coding => Thema gestartet von: dldave am 10. February 2010, 17:09
-
Hallo,
Ich habe mich in der letzten Zeit ein wenig mit Lowlevel auseinander gesetzt und einen kleinen Bootloader geschrieben. Jetzt habe ich begonnen einen kleinen "Kernel" zu schreiben.
Aus irgend einen Grund kann ich in meinem "Kernel" plötzlich nicht mehr auf globale Variablen zugreifen. :?
Wenn ich von meiner main-Funktion aus auf eine Globale Variable zugreife dann hat sie IMMER den Wert 0.
Auserderdem habe ich plötzlich Probleme mit meiner printf-Funktion. Wenn ich sie mehrmals aufrufe dann wird kein Text mehr ausgegeben bzw der Bildshirm bleibt oder wird schwarz. (Vor ein paar Tagen hat alles noch Problemlos funktioniert.
Ich verwände gcc 4.4.3 unter ArchLinux
-
Kannst du den Code irgendwohin hochladen?
Mal völlig ins Blaue geraten: Variablen, die sich magischerweise nicht ändern lassen, hatte ich schonmal. Am Ende hat sich herausgestellt, dass sie an einer ROM-Adresse gelandet sind. Wo läuft denn dein Kernel bzw. wo liegen die Daten?
-
Link: http://svn.bluestain.net/david/Projekte/DAVEOS/trunk/
Ist zwar nicht mehr die Aktuellste version, aber hier hatte ich das Problem auch schon!
-
Kann mir Niemand helfen??? ??? :? :?
-
hatte das Problem auch schon einige male
Ursache: Der kernel wurde zu groß, und dadurch nicht vollständig vom bootloader geladen.
Da du ebenfalls einen eigenen bootloader verwendest, würde ich das mal als mögliche Ursache betrachten.
Ich empfehle dir grub zu verwenden (was dir die meisten hier wahrscheinlich empfehlen würden), oder vorerst FAT12 in dein bootloader implementieren - im wiki gibt's einige links zu guten pdf's.
-
hmm, dann werd ichs mal mit GRUB probieren!!!
Mein Bootloader ist wirklich sch**** :-D :-D
Danke für den Tipp
---------------------------------------------------------------
Ich habe mal schnell dieAnzahl der zuladenen Sektoren in meinem Bootloader geändert.
Das Problem mit meiner printf-Funktion scheint gelöst zu sein. Die Globalen Variablen haben aber immer noch den Wert 0 bzw einen den sie nicht haben sollen.
hmm, könnte es sein dass die Aktivierung des A20 Gate nicht funktioniert hat???
-
Wenn werte die 0 sein sollten, aber nicht 0 sind kann es daran (http://lowlevel.brainsware.org/forum/index.php?topic=2416.0) liegen :mrgreen:
das es Probleme mit dem A20 gate gibt ist auch möglich
einfach mal was an eine adresse schreiben, und von der adresse +1MiB lesen - ist es das selbe liegts daran :)
-
Ok, ich hab gerade einen Wert an der Adresse 0x15000 erstellt, und dann bei 0x115000 wieder ausgelesen. ES IST DER SELBE WERT :-P :-P
Ich hatte das A20 Gate mittels System Control Port A eingeschaltet, da die Variante mit dem Tastaturkontroller immer abgeschtürzt ist.
-
GRUB würde das mit dem A20-Gate automagisch machen. :-)
-
Bevor ich Grub einsätze (das werde ich so schnell wie möglich machen) möchte ich es mit meinem eigenen Loader schaffen . :-D :mrgreen:
-
Na ja, ich bezweifle, dass das per Tastaturcontroller fehlschlägt, immerhin sollte das sogar mit USB-Tastaturen funktionieren... Wenn ein System so wenig Kompatibilität zu diesen "alten" Methoden hat, würde mich das sehr wundern.
Ehrlich gesagt bin ich ja derzeit eher der Überzeugung, dass du etwas falsch abgeschrieben hast. :wink:
-
[..]Wenn ein System so wenig Kompatibilität zu diesen "alten" Methoden hat, würde mich das sehr wundern.[..]
Mein neuster PC (~4 Jahre alt) hat ebenfalls auch Probleme damit.
Es gibt eine methode per int 0x15 (?) die A20 geschichte zu regeln, hab es allerdings noch nicht ausprobiert
-
Ich arbeite mit Quemu. Damit sollte es eigentlich keine Probleme geben.
Ich habe das A20 Gate immer aktiviert bevor ich in den PM gewechselt habe.
Vieleicht könnte es daran liegen?!?
----------------------------------------------------------
Ok, ich hab gerade einen Wert an der Adresse 0x15000 erstellt, und dann bei 0x115000 wieder ausgelesen. ES IST DER SELBE WERT
Vieleicht liegt es nicht am A20-Gate. Egal welche Adresse mein char pointer hat
es wird immer das selbe Zeichen zurück geliefert.
char* str= (char*)0x15000;
char* str2= (char*)0x0; //0x115000;
int main()
{
*str='A';
str++;
*str=0;
str--;
k_clearscreen();
k_printf(str2);
return 0;
}
-
Ich arbeite mit Quemu. Damit sollte es eigentlich keine Probleme geben.
Ich habe das A20 Gate immer aktiviert bevor ich in den PM gewechselt habe.
Vieleicht könnte es daran liegen?!?
So ziemlich sicher nicht.
-
Ich habe total keine Ahnung wiso so eine "so einfache Sache" nicht läuft. :?
:-o
-
char* str= (char*)0x15000;
char* str2= (char*)0x0; //0x115000;
int main()
{
*str='A';
str++;
*str=0;
str--;
k_clearscreen();
k_printf(str2);
return 0;
}
Was sollte dieser Code tun und was tut er? str sieht mir bis auf die Initialisierung ziemlich unbenutzt aus.
Edit: Ah, du meinst, dass es trotzdem funktioniert, obwohl es keinen Sinn ergibt? Ich würde mal auf ein Problem mit deinem k_printf tippen.
-
Ich weise str eine Adresse zu und schreibe ein A hinein. Dann gebe ich str2 aus.
Egal auf welche Adresse str2 zeigt wird immer str ausgegeben.
Ich glaube eher nicht dass es an der printf Funktion liegt. Wenn ich mit if die Werte vergleiche komme ich auf das selber Ergebnis.
-
welche Adresse haben denn str und str2 (zur Laufzeit!)?
-
Ich verstehe nicht genau was du meinst.
Zur Laufzeit
str =0x15000
str2=0
-
wenn beim kopieren des kernels oder während des linkens was schief läuft könnte es sein, das die Daten der globalen variablen sich ändern - du hättest dann dort nicht die adressen drin stehen, die du ihnen im quellcode zugewiesen hast.
so kann es z.B. sein, das beide variablen auf 0x00000000 zeigen.
-
hmm, und wie kann ich so einen Fehler finden ???
Für das Linken habe ich das Linkerscript vom wiki genommen.
INPUT(bin/kernel_32.o bin/ckernel.o bin/video.o bin/memory.o bin/utils.o )
OUTPUT_FORMAT("binary")
ENTRY(start)
SECTIONS
{
.text 0x10000 : {
*(.text)
}
.data ALIGN (4096): {
*(.data)
}
.bss ALIGN (4096): {
*(.bss)
}
-
Methode 1:
printhex(str);
printhex(str2);
Methode 2:
if(str == str2) prints("error");
-
Also die beiden Zeiger zeigen zur Laufzeit auf die selber Adresse.
Aber wo liegt der Fehler??? Was mach ich falsch??? :|
-
mit
objdump -h ckernel.okannst du dir anzeigen lassen, wie dein Kompiler ckernel.c zerlegt
Alle dort genannten sections (außer .comment und .note.GNU-stack) sollten auch in deinem linkerscript auftauchen - falls nicht ist das der Punk an dem dir die Daten verloren gehen :)
-
Also die Ausgabe von objdump schaut eigentlich ganz gut aus oder ???
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00000067 00000000 00000000 00000034 2**2
CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
1 .data 00000004 00000000 00000000 0000009c 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00000004 00000000 00000000 000000a0 2**2
ALLOC
3 .rodata 00000006 00000000 00000000 000000a0 2**0
CONTENTS, ALLOC, LOAD, READONLY, DATA
4 .comment 00000012 00000000 00000000 000000a6 2**0
CONTENTS, READONLY
5 .note.GNU-stack 00000000 00000000 00000000 000000b8 2**0
CONTENTS, READONLY
-
rodata dürfte das wesentliche sein, das fehlte, wäre meine Einschätzung, siehe auch das Linkerscript (http://lowlevel.brainsware.org/wiki/index.php/Teil_4_-_Hello_World#Multiboot-Header_in_einer_eigenen_Sektion) aus der Wikitutorialserie.
-
Mach es einen Unterschied in welcher Reihenfolge die Sectionen angelegt werden?
-
Nein, eigentlich nicht. Es wurde glaube ich schon gesagt, aber ich sags einfach nochmal: Benutz einen gescheiten Bootloader, dann sind 90% solcher Fehler Geschichte.