Thema: Erster Bootloader - Emulatorproblem...

[Anfänger]

Einen schönen guten Tag zusammen!

Ich stehe vor einem kleinen Rätsel. Ich habe einen Bootloader, der im MBR meines USB-Sticks liegt und den Bootloader einer vorhandenen FAT32 Partition laden soll.
Nun ist es aber so, dass das ganze zwar im Emulator (QEMU, VMPlayer, VBox) wunderbar läuft, auf einem echten PC allerdings nicht.
Zum testen versuche ich den OEM Namen im FAT32 Bootsektor auszugeben, im Emulator erhalte ich den gewollten Namen, auf dem PC lese ich garnichts, also null.
Wäre super, wenn sich jemand kurz die Zeit nehmen würde, um sich das Problem einmal anzuschauen, vielleicht ist es ja nur eine Kleinigkeit...
http://pastebin.com/K0w8m8ZK

Vielen Dank im Voraus!

[Svenska]

Hallo,

der klassische Ansatz wäre, zum Beispiel für verschiedene Phasen des Bootvorgangs ein Zeichen in die obere linke Bildschirmecke zu schreiben, um so einen Fortschritt zu beobachten. Dann siehst du, wo es hängt.

Mich irritiert das "[ORG 0x8000]" etwas. Sollte da nicht eher ein "[ORG 0x7C00]" oder so stehen?

Ansonsten gebe ich dir den Tipp, dich nicht näher mit dem Bootloader zu befassen. Es lohnt sich nicht:
- Du hantierst mit 16-Bit Code. Der stirbt, auf PCs mit EFI und auf anderen Plattformen sowieso.
- Du hantierst mit MBR-Partitionstabellen. Die gehen nicht für Festplatten größer 2 TB. Danach kommt GPT.
- Du hantierst mit einer antiken Umgebung. Jedes BIOS verhält sich anders und hat andere Bugs. Das ganze sauber zu implementieren (also jenseits von "geht auf meinen zwei Test-PCs und in Qemu) ist allein schon mehr Aufwand, den du vermutlich lieber in ein Betriebssystem stecken möchtest.
- Es gibt nicht viele Möglichkeiten, da irgendwas "anders" zu machen. Der Weg ist ziemlich stark vorgegeben, Abweichungen sind nicht möglich.
- Es gibt fertige Software, von klein/schnell/gut (SYSLINUX) bis hin zu groß/langsam/eierlegendeWollmilchsau (GRUB).

Gruß,
Svenska

[chris12]

mich verwirrt auch etwas, dass keine bootloader signatur angegeben ist ... sprich 0x55 0xAA

[streetrunner]

Hallo,

ich würde auch mal auf die fehlende Signatur tippen. Sieh dir mal den Code hier an:

http://www.lowlevel.eu/wiki/Eigener_Bootloader (weiter unten unter "Datenbereich")

Da kannst du sehen das der MBR auf 510 Byte "aufgeblasen" wird und am Ende 0xAA55 (noch mal 2 Byte mehr) angehängt werden. Ohne das wird dein Rechner den MBR gar nicht laden wollen.
Und sonst kann ich Svenska nur zustimmen, Grub ist viel zu einfach zu bedienen als das es sich lohnen würde eine Alternative selbst zu schreiben.

Gruß,
Streetrunner

[Anfänger]

Also, zunächst: 0x8000 weil sich der bootloader an diese Adresse kopiert.
Ich hantiere mit diesen "veralteten" Dingen, weil die mir bis jetzt völlig reichen. Mir ist klar, dass ich auf fertige Lösungen zugreife kann, allerdings ist das nicht Sinn  der Übung
Einen Fortschrittszeiger brauche ich nicht, weil das Programm nirgendwo hängt, das Problem ist einfach, dass anstatt des OEM namens, einfach 0 bzw nichts gelesen wird.
Die bootsignatur fehlt nicht, da der mir diese enthält und nicht mein bootloader...
Ansonsten würde ich ja nicht einmal so weit kommen

Gruß.

[Svenska]

Hallo,

Also, zunächst: 0x8000 weil sich der bootloader an diese Adresse kopiert.

Stimmt. Wozu machst du das eigentlich? Du kannst doch auch die Sektoren dahin kopieren und ein paar Bytes sparen.

Ich hantiere mit diesen "veralteten" Dingen, weil die mir bis jetzt völlig reichen.

Damit manövrierst du dich in eine Sackgasse, denn die Nachfolgetechnologien sind bereits jetzt auf dem Markt und nicht kompatibel.

Einen Fortschrittszeiger brauche ich nicht, weil das Programm nirgendwo hängt, das Problem ist einfach, dass anstatt des OEM namens, einfach 0 bzw nichts gelesen wird.

Bist du sicher, dass deine Lesefunktion auch funktioniert? Lasse dir mal die Rohdaten anzeigen.

Gruß,
Svenska

[Anfänger]

Wozu machst du das eigentlich? Du kannst doch auch die Sektoren dahin kopieren und ein paar Bytes sparen.

Ich schieb das Ding aus dem Weg, damit ich den FAT32-Bootloader, dahin kopieren kann. Natürlich lässt sich das optimieren, aber das mach ich alles später, wenn der Rest läuft.

Damit manövrierst du dich in eine Sackgasse, denn die Nachfolgetechnologien sind bereits jetzt auf dem Markt und nicht kompatibel.

Nunja, bis jetzt habe ich noch kein UEFI gesehen, welche nicht "BIOS-kompatibel" ist Und wie gesagt, für meine Zwecke reicht das so erstmal, ich will das Ding ja nicht verkaufen oder sowas

Bist du sicher, dass deine Lesefunktion auch funktioniert? Lasse dir mal die Rohdaten anzeigen.

Genau das ist der Punkt, das wird wohl eben nicht der Fall sein, sonst würde ich ja den richtigen String lesen. Allerdings habe ich noch keinen Debugger hergerichtet. Besseren Vorschlag als QEMU+GDB?

EDIT:
So, zum Thema Debug: Habe nochmal alles Funktionen im Emulator getestet, funktionieren wie sie sollen. Nun wüsste ich aber nicht, wie ich meine "echten" PC debuggen sollte
Der Punkt ist ja, dass auch beim echten PC die Lesefunktion erfolgreich ist (gerade nochmal getestet), allerdings stehen die Daten nicht da wo sie eigentlich stehen sollten...
Ich denke der Emulator "hilft" vielleicht irgendwo, wodurch ein Fehler verdeckt wird, was der echte PC eben nicht macht... nur habe ich keine Ahnung was das sein sollte.

Gruß

[kevin]

Ich hantiere mit diesen "veralteten" Dingen, weil die mir bis jetzt völlig reichen. Mir ist klar, dass ich auf fertige Lösungen zugreife kann, allerdings ist das nicht Sinn  der Übung

Was ist denn der Sinn der Übung? Ich kann nämlich keinen erkennen.

Zu deinem Problem würde ich dir empfehlen, mal noch ein paar andere Emulatoren (erstmal bochs, aber auch VBox, VMware usw.) zu probeiren, ob sich der Code dort anders verhält.

[Anfänger]

Was ist denn der Sinn der Übung? Ich kann nämlich keinen erkennen.

Lernen

Zu deinem Problem würde ich dir empfehlen, mal noch ein paar andere Emulatoren (erstmal bochs, aber auch VBox, VMware usw.) zu probeiren, ob sich der Code dort anders verhält.

[...]

im Emulator (QEMU, VMPlayer, VBox) wunderbar läuft

[...]

Gruß

[Jidder]

Zum testen versuche ich den OEM Namen im FAT32 Bootsektor auszugeben, im Emulator erhalte ich den gewollten Namen, auf dem PC lese ich garnichts, also null.

Das heißt es wird "Loading Partition..." auf dem PC ausgegeben, aber nichts danach?

[Anfänger]

Das heißt es wird "Loading Partition..." auf dem PC ausgegeben, aber nichts danach?

Korrekt.
Im Emulator erscheint danach eben der OEM String, im echten PC ist sozusagen ende.

[Jidder]

Verwendest du identische Images im Emulator und auf dem USB-Stick?
Der Code im MBR ist nicht von dir, oder?

Du könntest auch mal prüfen, welcher Wert in DL steht, wenn dein Bootsektor gestartet wird, indem du ihn ausgibst.

[Anfänger]

Verwendest du identische Images im Emulator und auf dem USB-Stick?
Der Code im MBR ist nicht von dir, oder?

Du könntest auch mal prüfen, welcher Wert in DL steht, wenn dein Bootsektor gestartet wird, indem du ihn ausgibst.

Ich verwende im Grunde kein Image, sondern direkt den USB-Stick
Der Stick samt Partition und MBR-Code wurde vom Herrn GParted erstellt, ich habe nur den Bootloader ersetzt.
DL stimmt mit 0x80...

Gruß

[Jidder]

Dann fällt mir auch nicht mehr viel ein. Ich hab nur eine Theorie, dass man den Stick nur mit den INT 13 Extensions ansprechen kann. (http://www.ctyme.com/intr/rb-0708.htm) Ob sowas überhaupt sein kann, weiß ich nicht. Du könntest in den MBR reinschauen (disassemblieren), und gucken welche BIOS-Funktionen da verwendet werden.

[Svenska]

Hallo,

Nunja, bis jetzt habe ich noch kein UEFI gesehen, welche nicht "BIOS-kompatibel" ist

Das ist egal, wenn statt MBR eine GPT vorhanden ist, außerdem sind die beiden Bootsysteme zueinander inkompatibel. Ich vermute, dass EFI-Firmwares das eine oder das andere unterstützen, aber nicht beides. Windows 9 wird vermutlich ein EFI voraussetzen.

Bist du sicher, dass deine Lesefunktion auch funktioniert? Lasse dir mal die Rohdaten anzeigen.

Genau das ist der Punkt, das wird wohl eben nicht der Fall sein, sonst würde ich ja den richtigen String lesen. Allerdings habe ich noch keinen Debugger hergerichtet. Besseren Vorschlag als QEMU+GDB?

Versuch's mal ohne Debugger. Einfach die Rohdaten anzeigen, ähnlich wie bei einem Hexdump.

Was ist denn der Sinn der Übung? Ich kann nämlich keinen erkennen.

Lernen

Musst du selbst wissen, ob das noch lernenswert ist. Das einzige, was du wirklich lernst, sind die historischen Fuckups der PC-Architektur (z.B. A20). Für Betriebssysteme will man Speicherschutz, den du in den besseren x86-Modi oder bei größeren Microcontrollern findest und zum Lernen der hässlichen Details gibt es Mikrocontrollerarchitekturen, die nicht zig-mal aufgebohrt wurden.

Gruß,
Svenska

[Anfänger]

Du könntest in den MBR reinschauen (disassemblieren), und gucken welche BIOS-Funktionen da verwendet werden.

Gesagt getan, habe einfach mal den MBR meiner Hauptfestplatte (Ubuntu) gedumpt und angeguckt. GRUB läd das ganze, wenn verfügbar, via Extended Read. Ansonsten so wie ich es mache... allerdings sieht es so aus (hab nur mal "kurz" drüber geschaut), als ob GRUB es vermeidet, den CHS-Eintrag der Partitionstabelle zu nehmen und sich den stattdessen selber zusammen baut.
Naja, werde mal schauen, ob das mit extended read funktioniert, allerdings würde ich viel lieber die Ursache/den Fehler wissen 

Das ist egal, wenn statt MBR eine GPT vorhanden ist, außerdem sind die beiden Bootsysteme zueinander inkompatibel. Ich vermute, dass EFI-Firmwares das eine oder das andere unterstützen, aber nicht beides. Windows 9 wird vermutlich ein EFI voraussetzen.

Wie gesagt, ich weiß ja ob ich einen MBR oder eine GPT habe, und jemand anderes wird meine kleine Bastelei wohl kaum sehen, von daher reicht mir das erst einmal so

Versuch's mal ohne Debugger. Einfach die Rohdaten anzeigen, ähnlich wie bei einem Hexdump.

--> NULL, die Daten werden im Optimalfall wo anders hin geladen, oder es werden, was ich eher glaube, die falschen Daten, an die richtige Stelle kopiert... da der USB-Stick sonst leer ist, wäre die 0 nicht umwahrscheinlich

Nunja, ich schau morgen mal nach, ob das ganze mit Extended Read und LBA funktioniert. Falls ja, wird möglicherweise was mit dem CHS-Eintrag nicht stimmen... wobei es ja bei den Emulatoren funktioniert... seltsam.... naja, ich schau mal und gebe dann Bescheid

Gruß

[Anfänger]

So, hier die versprochenen Resultate:
Extended read (ah 0x42) funktioniert.
Das "normale" read (ah 0x2) nach wie vor nicht. Ich habe noch einmal etwas genauer auf die Werte geschaut. Der CHS-Eintrag wird korrekt ausgelesen und in die entspr. Register übergeben. Auch der Aufruf (int 0x13) liefert ein Erfolgreich (kein carry flag, Status in AH = 0 = success) zurück, und hat angeblich einen sektor gelesen (AL = 1). Nur die Daten stehen eben nicht dort, wo sie eigentlich stehen sollten.
Ich kann mir nur noch vorstellen, dass das BIOS noch irgendwas mit der übergebenen Adresse anstellt, sodass ich letztenendes die Daten wo anders hin lade... Da fehlt mir allerdings die Erfahrung und das nötige Wissen, vielleicht hat jemand von euch da noch eine Idee?

Gruß

[Svenska]

Hallo,

entweder, dein BIOS unterstützt für USB-Geräte kein normales Read (oder ist buggy implementiert), oder die Geometrien stimmen nicht vernünftig überein. CHS unterstützt maximal 1024/16/63, also exakt 504 MiB.

Es gibt verschiedene Translation-Verfahren, um trotzdem größere Geräte zu unterstützen, die hängen aber vom BIOS ab. Es gibt da eine ziemlich genaue Beschreibung der verschiedenen BIOS-Typen und deren Implementation im Internet (http://www.uruk.org/orig-grub/PC_partitioning.txt), genau das richtige für Historiker, die sich damit rumprügeln wollen.

Das einzige, was ziemlich zuverlässig sein sollte, ist LBA.

Gruß,
Svenska

[Jidder]

Oder es ist so, dass die BIOS-Hersteller etwas wissen, das wir nicht wissen. Die Anforderungen von Microsoft fordern BIOS Enhanced Disk Drive Services - 2 (= INT 13h Extensions) für erfolgreichen USB-Boot. Vielleicht gibt es eine Spezifikation, die umgekehrt besagt, dass BIOSse erwarten, dass jedes OS auf einem USB-Stick die INT 13h Extensions nutzt. Oder (was ich für wahrscheinlicher halte) die BIOS-Hersteller ignorieren wie immer einfach alles bis auf Windows und weil Windows die Extensions nutzt, hat jeder, der sie nicht nutzt, verloren.
Und die BIOS-Hersteller schenken sich eventuell die Unterstützung der alten INT 13-Schnittstelle für USB, "weil sie veraltet ist" (naja was will man machen, wenn USB eingeführt wird, bevor das BIOS als Standardfirmware abgelöst wird)

[Anfänger]

Jep, so wird es sein.
Aber was soll's, dann nehme ich eben extended read, ist ja nicht so, als hätte ich da irgendwelche Vorgaben
Nehmen wir es also einfach als so gegeben, weil buggy oder nicht verfügbar oder sonst was
@Svenska: Nur am Rande, CHS sollte inzwischen 255 Heads unterstützen... wobei die Betonung auf "sollte" liegt. Bochs kommt damit auch nicht klar, wie ich feststellen musste. Kannst du hier http://en.wikipedia.org/wiki/Cylinder-head-sector (unter heads) auch noch einmal nachlesen, wenn du magst.
Naja, damit ist mein Problem wohl.... "gelöst"
Danke euch!

Gruß