4. PrettyOS Fehler-/Testthread

PrettyOS Fehler-/Testthread

  • E
    Mod

    Programme in die kernel.bin einbinden läuft über initrd.exe und incbin ..., nicht via FloppyImage ( ist wie kopieren der elf-Files nach Laufwerk A: ).

    0
  • ?

    Das Hauptproblem beim Laden der KERNEL.BIN lag lustigerweise in der "boot2.asm". Dort wird der Stack bei Label "entry_point:" wieder auf 0000:FFFF gesetzt. Dadurch gerät er in Konflikt mit allem, was ab 0000:0500 bereits geladen wurde (und noch wird).

    In der "Fat12.inc" gibt es einen "Denkfehler". BP ist kein Segmentregister. [BP:BX] geht nicht, aber [BP+BX] geht.

    Hier die sehr grob "gefixten" Versionen der boot2.asm und der Fat12.inc, damit der Spaß beim Programmieren weitergehen kann.

    Änderungen sind mit "==HOTFIX==" gekennzeichnet. Zumindest sollte damit jetzt eine KERNEL.BIN > 57 KB problemlos geladen werden. 🙂

    0
  • E
    Mod

    Danke! Du hast uns vor raschem GRUB bewahrt. 🙂

    0
  • ?

    Wie gesagt, ist nur sehr grob gefixt. Ab ca. 118 KB ist der Spaß wieder vorbei. Offenbar kommt sich da noch mehr ins Gehege. Ist zu erwarten, daß in nächster Zeit die KERNEL.BIN 118 KB erreicht? Eigentlich wollte ich an meinem Userprogramm weiterbasteln. 🙂

    0
  • M

    Eig. ist das nicht zu erwarten... Zumindest nicht in den nächsten paar Wochen. (Wenn Du Zeit&Lust hättest wär es natürlich schon schön, wenn Du auch die 118KB-Grenze beheben könntest, aber das ist nicht so eilig 🙂 ).

    Mach ruhig erstmal an Deinem Userprog weiter. wir haben ja grad mal 52 KB erreicht.

    0
  • E
    Mod

    Erstmal dickes Dankeschön! 🙂

    0
  • ?

    Via Hotfix sind ca. 250 KB möglich. Unangenehmerweise enthält der Bootloader fest vergebene Adressen, die sich langsam ins Gehege kommen. Aber darum kann man sich auch später noch kümmern.

    Hier mal ein Screenshot von meinem Userprogramm. PrettyOS lernt grade, was eine "Festplatte" ist. 🙂

    Btw. der 08. März 2010 ist bei mir ein Montag.

    0
  • F

    Ohne mir den Source-Code jetzt angeguckt zu haben, werfe ich einfach mal UnrealMode ein (kann sein das ihr das schon nutzt).

    Wie ladet ihr denn den Kernel, wird er erst komplett geladen und dann an eine andere Position verschoben/kopiert, wenn ja, dann kann man das immer gleich machen braucht so nur nen Buffer der so groß ist wie ein Cluster und kann (UnrealMode vorausgesetzt) Dateien beliebiger Größe laden.

    0
  • M

    +gjm+: Dein Treiber sieht Klasse aus!

    0
  • ?

    Vielen Dank! 🙂

    Nun gibt es aber ein Problem in der "time.c" mit dem Wochentag. Der Grund dafür ist, einfach gesagt, daß es zwei verschiedene "Arten" vom CMOS gibt:

    1. Register 0x06 zählt von 1 bis 7,
    2. Register 0x06 zählt von 0 bis 6.

    Per Software kann man nicht herausfinden, ob Register 0x06 von 1 bis 7 oder von 0 bis 6 zählt. Deshalb wäre es besser wenn der Wochentag anhand des Datums ausgerechnet wird. Dazu muß man nur von einem bekannten Datum bis heute die Anzahl vergangener Tage ausrechnen und dann einfach modulo 7.

    Der 01.01.1900 ist immer eine gute Idee. Der ist zufälligerweise ein Montag.

    0
  • E
    Mod

    1. Register 0x06 zählt von 1 bis 7,
    2. Register 0x06 zählt von 0 bis 6.

    Wirklich bekloppt so was.

    0
  • M

    Theoretisch wär ja wohl sogar noch mehr Mist denkbar... Rückwärts zählen z.B. 😉

    0
  • ?

    Revision 210

    Bochs kommt mit folgendem "Fliesskomma-Ausdruck" nicht zurecht und rechnet "falsch":

    // time.c Revision 210
unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) {

 day += 6; //1.1.2000 was Saturday
 day += (year-2000)*365.25;          // <- hier 

(...)
}

    VB und VPC schlucken ihn aber und rechnen korrekt. Vielleicht könnte die Routine so umgeschrieben werden, daß man auf eine "365.25" verzichten kann? 🙂

    0
  • M

    Ohja, stimmt, da gabs ja ein Problem mit Bochs+Fließkommazahlen...
    Ich werde ein Workaround erzeugen, kommt bald!

    EDIT: Ich hab mir mal Bochs runtergeladen und PrettyOS damit gestartet: Ich konnte keinen Fehler feststellen... 😕
    Bochs-Version: 2.4.2
    PrettyOS: Rev. 210

    0
  • ?

    Tatsächlich! Lag an der Version von Bochs:

    unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) {

 day += 6; //1.1.2000 was Saturday
 day += (year-2000)*365.25;

printformat("\n day : %X",day); // <- debug :)

(...)
}

    Nun geben Bochs (2-4-2), VB und VPC die gleiche Zahl aus. Hatte noch eine alte Version von Bochs. Also keine Revision notwendig. 👍

    0
  • ?

    Revision 239

    Bin grade über folgenden Workaround gestolpert:

    // ehci.c Revision 239
void initEHCIHostController(uint32_t number)
{
    initEHCIFlag = false;
    irq_install_handler(32 + pciDev_Array[number].irq, ehci_handler);
    irq_install_handler(32 + pciDev_Array[number].irq-1, ehci_handler); /// work-around for VirtualBox Bug!
(...)
}

    Offenbar scheint die Sun VirtualBox "gewisse" Problemchen mit dem USB-Support unter "gewissen" Host-Betriebssystemen zu haben.

    Wenn man folgendes macht:

    1. VM starten,
    2. im Menü der VM (Geräte->USB-Geräte) ein "USB-Gerät" auswählen (möglichst das richtige 🙂 ),
    3. die VM "neu starten" (Maschine->Zurücksetzen)

    dann ist ein Workaround nicht notwendig.

    0
  • E
    Mod

    Danke für den Hinweis!

    0
  • E
    Mod

    Zwei Sachen, die immer wieder erfolgen, wenn man neu aufbaut:

    1. del wird nicht gefunden, weil msys oder wie jetzt bei mir auf einem alternativen PC Win-AVR mit den entsprechden Pfaden auf der Platte hängen. Da muss man die entsprechenden Pfade eliminieren. Wir verwenden daher auch kein msys mehr.

    2. Das makfile bleibt hier bei [initrd] hängen:

    E:\PrettyOS\trunk\Source>del FloppyImage.bin
E:\PrettyOS\trunk\Source\FloppyImage.bin konnte nicht gefunden werden

E:\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS
nasm -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloader
/boot.bin
nasm -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootloade
r/BOOT2.BIN
del *.o
E:\PrettyOS\trunk\Source\*.o konnte nicht gefunden werden
mingw32-make: *** [initrd] Error 1

    Dieser Fehler ist hässlich, weil man die Lösung nicht leicht findet, zumindest geht es mir immer so.
    Es liegt an den beiden "delete *.o", die in den targets ckernel und initrd nichts finden, make-fehler produzieren und deshalb blockieren. Diese beiden kommen nun einfach weg! Könnte dann nur einen Linker Error geben.

    Diese beiden Punkte sind die typischen Probleme, denen man beim Einstieg in den Build-Prozess seitens Windows evtl. begegnen kann.

    Vorschlag mastamind im IRC: mit den wildcards nur die source dateien auflisten (nicht zwei mal)

    0
  • A

    Ich kann mich an alte DOS Zeiten nur schwer erinnern, aber bestand nicht die Möglichkeit mittels Errorleveln die Rückgabewerte eben von "Del" abzufangen und darauf zu reagieren? Helft mir wenn ich falsch liege...

    Nachtrag: Del liefert den Errorlevel 1 zurück, wenns nicht erfolgreich war. Alternativ kann man mittels "exist" vielleicht probieren, ob die entsprechende Datei existiert - mit etwas aufwand ist damit vielleicht auch eine Prüfung von mehreren Datein möglich.

    0
  • E
    Mod

    Del liefert den Errorlevel 1 zurück

    Ja, genau so wurde make ausgestoppt. Daher habe ich die beiden del *.o ab Rev. 245 erstmal gestrichen, damit sie auf diese Weise niemand beim Einstieg behindern. 🙂
    Danke für deinen Hinweis. Vielleicht schafft das jemand.

    0
Anmelden zum Antworten