4. PrettyOS startet nur emuliert

PrettyOS startet nur emuliert

  • J

    Das Problem, das du beschrieben hast, haben wir erst letztens gefixt. War aber ueber etliche Revisionen drin, weil die meisten von uns auf Windows arbeiten, und wir es so nicht bemerkt haben. Eher durch Zufall hat es mal einer, beim Versuch es auf Linux zu kompilieren, gefunden.

    Wenn du wirklich die aktuelle Revision hast, duerfte zumindest das Problem mit dem kompilieren gefixt sein.
    Hast du wirklich die neuste Revision. Achtung, die die hier angegeben war, war nicht mehr aktuell.
    Mach einen Checkout von dieser URL (und pass auf, dass du wirklich die Head-Revision nutzt): svn://svn.code.sf.net/p/prettyos/code/trunk

    Die Zeile wird sicherlich in der naechsten Rev. geaendert; aber wegen dieser einen Zeile ne neue Rev rausbringen halte ich doch fuer uebertrieben. Aber da hab ich noch nix zu sagen, fuer Commits usw. sind Erhard und MrX verantwortlich.

    0
  • M

    ja, aber ich kann doch garnicht kompilieren.

    Der Fehler beim kompilieren lag also nicht daran, dass Du den Quellcode aus dem alten Repository bezogen hast? r1392 ist nicht mit GCC 4.7 kompatibel, r1407 schon. Außerdem müsste das kompilieren (auch mit der alten Revision) gehen, wenn Du den Prototypen einfach mal änderst...

    0
  • J

    Nein, unter Linux sicherlich nicht 😉

    0
  • ?

    der fehler ist der gleiche wie vorhin:

    userlib_cpp.cpp:10:42: Fehler: »operator new« nimmt Typ »size_t« (»unsigned int«) als ersten Parameter [-fpermissive]
    userlib_cpp.cpp:14:44: Fehler: »operator new« nimmt Typ »size_t« (»unsigned int«) als ersten Parameter [-fpermissive]
    make[1]: *** [userlib_cpp.o] Fehler 1
    make: *** [userlibs] Fehler 2

    0
  • J

    Auch bei einem frischen Checkout von der URL, die ich dir gegeben hab?
    Dann haette GCC unter Linux und Windows verschiedene new -Signaturen. Wuerde mich aber doch stark wundern...
    Notfalls aender mal die Signatur von Hand, wie bereits von MrX gesagt. Ach ja, und guck bitte, ob in ckernel.c die Version wirklich die neuste ist.

    0
  • ?

    Jonas OSDever schrieb:

    Auch bei einem frischen Checkout von der URL, die ich dir gegeben hab?
    Dann haette GCC unter Linux und Windows verschiedene new -Signaturen. Wuerde mich aber doch stark wundern...
    Notfalls aender mal die Signatur von Hand, wie bereits von MrX gesagt. Ach ja, und guck bitte, ob in ckernel.c die Version wirklich die neuste ist.

    Kernelversion ist laut ckernel.c "0.0.4.22 - Rev: 1407".

    0
  • J

    Sehr komisch. Das ist die aktuelle. Dann hat er GCC 4.7.2 wohl tatsaechlich verschiedene new -Signaturen auf Windows und Linux. Wie gesagt, aendere mal die Prototypen von Hand.

    0
  • ?

    Jonas OSDever schrieb:

    Sehr komisch. Das ist die aktuelle. Dann hat er GCC 4.7.2 wohl tatsaechlich verschiedene new -Signaturen auf Windows und Linux. Wie gesagt, aendere mal die Prototypen von Hand.

    ja gut, aber was soll ich jetzt da ändern? ich versteh noch nicht mal, wo hier jetzt das problem ist, in den prototypen, die der compiler bemängelt, kommt nirgends "size_t" vor 😕

    0
  • M

    long unsigned int wird geändert zu size_t

    0
  • ?

    Mr X schrieb:

    long unsigned int wird geändert zu size_t

    gut, jetzt wird erfolgreich kompiliert.

    muss ich mir jetzt manuell ein image zusammenschustern?

    0
  • M

    Nein, das liegt nun im Basisverzeichnis. Hat das mit svn gedownloadete überschrieben

    0
  • ?

    ok, ich habe jetzt die angesprochene assemblerzeile hinzugefügt und kompiliert.

    danach das ganze wieder mit dd aufm usb-stick geschrieben.

    neugestartet... und es geht wieder nicht 😞

    0
  • M

    Am Bootloader scheint noch mehr faul zu sein, ich untersuche gerade mal in Stage 1, ob dort die Nummer des Bootdevices richtig verwendet wird.

    0
  • ?

    Mr X schrieb:

    Am Bootloader scheint noch mehr faul zu sein, ich untersuche gerade mal in Stage 1, ob dort die Nummer des Bootdevices richtig verwendet wird.

    ich denk, es liegt irgendwo bei stage 2, weil es wird immernoch diese stage2-ladenachricht ausgegeben. danach springt der cursor mehrmals nach unten, danach bootet mein normales system.

    0
  • M

    Ersetz in boot.asm (stage 1) mal jedes "bootdevice" durch "DriveNum", und lösche Zeile 240

    bootdevice     db 0

    Eventuell geht es dann, oder evtl. geht's zumindest weiter.

    ich denk, es liegt irgendwo bei stage 2, weil es wird immernoch diese stage2-ladenachricht ausgegeben. danach springt der cursor mehrmals nach unten, danach bootet mein normales system.

    Ich bin inzwischen zu einem anderen Schluss gekommen. Stage 1 läd irgendwas, aber nicht den Stage 2 Bootloader, behauptet, er starte diesen nun, aber in Wirklichkeit startet halt irgendwas anderes.

    0
  • ?

    anscheinend ist der bootloader noch nicht so ausgereift.

    es funktioniert immernoch nicht.

    Da steht einfach "Loading Second Stage Bootloader...", dann springt der curser zweimal nach unten, danach seht da noch was, was nich nicht lesen kann, weils so schnell weg ist, danach bootet grub normal (hab dualboot).

    0
  • ?

    ich hab die lösung gefunden.

    bisher hab ich das image qemu immer als floppy angegeben ("-fda FloppyImage.img")

    jetzt hab ich das image mal als usb-stick emuliert ("-usb FloppyImage.img")

    und siehe da, hier ist wohl der fehler, qemu meldet:

    qemu-system-i386 -usb FloppyImage.img schrieb:

    Booting from Hard Disk...
    Loading Second Stage Bootloader...
    **************
    BOOT2.BIN missing

    was sagt ihr?

    0
  • M

    Interessant.

    In der Datei /documentation/test-results.txt sind einige Rechner aufgeführt, die Boot-Probleme von USB-Sticks und USB-Floppylaufwerken aufweisen.

    Es gibt welche, die booten danach von der Festplatte weiter. Und es gibt welche, die melden BOOT2.BIN als fehlend. Hab das bisher für verschiedene Symptome für das gleiche Problem gehalten.

    Nun jedenfalls habe ich einen PC, der vorher das Windows nach Stage 1 bootete getestet: Da geht es nun! Einen Fehler sind wir also los.

    Das Qemu das gleiche Problem mit -usb zeigt, wie deine beiden echten Rechner, ist nicht gesagt. Nach der BOOT2-Meldung sollte er aber auf einen Tastendruck warten, und danach resetten.

    0
  • ?

    Mr X schrieb:

    Interessant.

    In der Datei /documentation/test-results.txt sind einige Rechner aufgeführt, die Boot-Probleme von USB-Sticks und USB-Floppylaufwerken aufweisen.

    Es gibt welche, die booten danach von der Festplatte weiter. Und es gibt welche, die melden BOOT2.BIN als fehlend. Hab das bisher für verschiedene Symptome für das gleiche Problem gehalten.

    Nun jedenfalls habe ich einen PC, der vorher das Windows nach Stage 1 bootete getestet: Da geht es nun! Einen Fehler sind wir also los.

    Das Qemu das gleiche Problem mit -usb zeigt, wie deine beiden echten Rechner, ist nicht gesagt. Nach der BOOT2-Meldung sollte er aber auf einen Tastendruck warten, und danach resetten.

    ok, gut das problem ist anscheinend bekannt.

    aber was ist da der grund? ich mein, anscheinend tritt der fehler "zufällig" auf?

    also bei mir wartet der bootloader nicht auf tastendruck. auf beiden pc (64-bit und 32-bit) startet einfach das betriebssystem.

    0
  • M

    also bei mir wartet der bootloader nicht auf tastendruck. auf beiden pc (64-bit und 32-bit) startet einfach das betriebssystem.

    Dann würde ich behaupten, dass die Meldung BOOT2.BIN missing auch nicht angezeigt wurde. Dieses Problem wird meines Erachtens nach durch die o.g. Änderungen gelöst, zumindest auf einem System bei mir.

    0
Anmelden zum Antworten