Hallo zusammen,
der erste Sektor eines USB-Sticks ist ja der Bootsektor. In diesen habe
ich ein wenig x86-Assembler-Code reingeschrieben und ans Ende des 512
Byte langen Sektors natürlich die Bytes 0x55 und 0xAA. Das ganze mit dem
HxD Hex-Editor. Diesen Stick wollte ich nun an meinem Laptop testen und
habe im Bios als einzig mögliches Boot-Device den USB-Stick angegeben.
Er wird auch erkannt, nur leider nicht als bootfähig, sondern nur
während des Startvorgangs, dass er angesteckt ist.
Hat irgendjemand eine Idee, was ich falsch gemacht haben könnte?
Unabhängig davon, ob Fehler im Assembler-Code sind, müsste der Stick
doch aufgrund seiner Bootsignatur (0xAA55) am Ende des ersten Sektors
als bootfähig erkannt werden, oder?
Vielen Dank und freundliche Grüße!
Danke für den Tip!
Wenn ich den ersten Sektor der Memtest-Binärdatei auf den Stick kopiere,
wird deren Code ausgeführt! Doch wie kriege ich jetzt raus, was davon
notwendig ist?
Hm, ich sehe gerade, dass bei Memtest Einträge in der Partitionstabelle
vorhanden sind... Sind diese notwendig zum Laden des Bootloaders? Ich
dachte immer, das Bios testet nur, ob die Bootsignatur am Ende vorhanden
ist
Christian schrieb:> Doch wie kriege ich jetzt raus, was davon> notwendig ist?
keine Ahnung, aber es ist doch sogar egal, überschreibe einfach den
enfang mit deinem code und schau was passiert.
Also an der Partitionstabelle kann es nicht liegen. DIe habe ich
dringelassen mit meinem Code. Aber seit wann hat denn der
Bootloader-Code etwas damit zu tun, ob er geladen wird oder nicht??
Christian schrieb:> Unabhängig davon, ob Fehler im Assembler-Code sind, müsste der Stick> doch aufgrund seiner Bootsignatur (0xAA55) am Ende des ersten Sektors> als bootfähig erkannt werden, oder?
Nö.
Am Anfang muss ein Sprungbefehl stehen. Entweder EB XX 90 oder E9 XX XX.
fchk
Das steht aber bei dem funktionierenden Code auch nicht am Anfang... Da
steht als erstes B8 C0 07 ... 0x07C0 ist ja die Adresse an die der
Bootloader geladen wird, aber B8? Was für ein Befehl ist das?
Vielen Dank für die Hilfe! Ich habe hier jetzt was gefunden zum
Unterschied zwischen VBR und MBR:
http://en.wikipedia.org/wiki/Boot_sector#Kinds_of_boot_sectors
Kann es sein, dass ich unbedingt einen VBR statt eines MBR benötige?
Mein Stick ist ja nicht partitioniert, allerdings aber auch nicht
formatiert...
.... schrieb:> Kann es sein dass hier MBR (Master Boot Record) und VBR (Volume Boot> Record) durcheinander gekommen sind?
ja scheint irgendwie so:
[..]
Der Volume Boot Record (kurz VBR) ist der erste Sektor (in der Regel 512
Byte) der jeweils korrespondierenden Partition eines Speichermediums
[..]
dort sollte ja eigentlich die Partitionstabelle stehen.
Christian schrieb:> Das steht aber bei dem funktionierenden Code auch nicht am Anfang... Da> steht als erstes B8 C0 07 ... 0x07C0 ist ja die Adresse an die der> Bootloader geladen wird, aber B8? Was für ein Befehl ist das?
mov ax,07c0h
Ist Dein USB-Stick partitioniert wie eine Festplatte oder ohne
Partitionstabelle wie eine Floppy? Woher kommt der funktionierende Code?
fchk
Den Code, der erfolgreich geladen wird, habe ich hierher:
http://www.memtest.org/#downiso
Ich glaube, mein Stick hat keine Partitionstabelle, da die Stringdaten
des funktionierenden Codes an der Stelle standen, wo eigentlich die
Partitionstabelle hätte sein müssen.
Muss der Stick denn mit FAT formatiert sein? Ich habe den Code auch mal
disassemblieren lassen, und da steht wie gesagt am Anfang ein
mov-Befehl. Ein Sprungbefehl am Anfang scheint also keine Voraussetzung
zu sein...
zeig doch mal bitte den code deines bootsectors... du versuchst dich
wohl in kernel programmierung, oder...? man beginnt da am besten mit der
guten alten diskette...
Peter II schrieb:> [..]> Der Volume Boot Record (kurz VBR) ist der erste Sektor (in der Regel 512> Byte) der jeweils korrespondierenden Partition eines Speichermediums> [..]>> dort sollte ja eigentlich die Partitionstabelle stehen.
Die Partitiontabelle steht im MBR und definiert, wo welche Partition
liegt. Jedenfalls bei primären Partitionen - bei extended Partitions
wirds komplizierter. In den ersten Sektoren der jeweiligen Partitionen
steht der VBR.
Hallo,
ja, letztendlich möchte ich natürlich eine Art kleinen Kernel
programmieren, der dann nur ein paar Signale über die parallele
Schnittstelle ausgeben soll.
Da ich leider kein Diskettenlaufwerk zur Verfügung habe, muss ich das
Ganze auf meinem USB-Stick machen. Im BIOS des PCs habe ich auch alles
so eingestellt, dass er nur vom USB-Wechseldatenträger booten kann.
Nun steht in sämtlichen Turorials zur Lowlevel und
Betriebssystemprogrammierung, dass das Bios schaut, ob im ersten Sektor
eines Speichermediums am Ende die Magic Number vorhanden ist und wenn
das der Fall ist, den Sektor in den Arbeitsspeicher lädt und asuführt.
Das tut mein Pc (Laptop) jedoch pffensichtlich nicht, denn mein Code
besteht nur aus einer Endlosschleife (eine Sprunganweisung immer wieder
an die selbe Stelle). Er zeigt immer die Meldung "Insert proper boot
device..." usw.
Was für Voraussetzungen muss denn mein Bootsektor haben, dass der Code
auch wirklich geladen wird?
Danke für eure Unterstützung!
Außerdem muss es doch irgendwo ein Dokument geben, dass beschreibt, auf
was das BIOS außer der Bootsignatur am Ende des MBR achtet... Es kann
doch nciht sein, dass das nirgendwo beschrieben ist :)
Bei mir funktioniert das Tool. Der USB Stick muss aber kleiner als 2047
MB sein, weil das HP-Tool den Stick im Superfloppy-Format beschreibt.
Ich verwende 512MB-Sticks, und damit habe ich kein Problem.
fchk
Christian schrieb:> Außerdem muss es doch irgendwo ein Dokument geben, dass beschreibt, auf> was das BIOS außer der Bootsignatur am Ende des MBR achtet... Es kann> doch nciht sein, dass das nirgendwo beschrieben ist :)
Doch, ist es. IBM schreibt im PS/2 Technical Reference Manual:
Interrupt 19H - Bootstrap Loader
Devices that are supported by Interrupt 13H read the boot record from
cylinder 0, head 0, sector 1. Devices that are supported by Interrupt
4BH read the boot record from logical block address 1. The boot
record is then read into system memory at address hex 0000:7C00.
The power-on self-test (POST) checks for the following characteristics
to validate a boot record:
• For a device with removable media, such as a diskette, the boot
record must contain valid code. For example, the value of the
first byte of the boot record must be greater than 6.
• For a device with nonremovable media, such as a fixed disk,
there must be a signature of hex 55AA at the end of the boot
record.
Parameters that identify the device from which the boot record was
obtained are passed to the boot record. Passing of these parameters
enables the boot record to continue the system boot operation.
In systems that do not support Interrupt 15H, Return Boot Device and
Key function ((AH) = D6H), the following information is passed to the
boot record:
(CS) = 0000H
(IP) = 7C00H
(DL) - Drive from which the boot record was read
In systems that support Interrupt 15H, Return Boot Device and Key
function ((AH) = D6H), information is passed also to the DX register. If
the access-mode bit (bit 5) is set to 0, the DX register is defined as
the
"boot device identifier"; if the access-mode bit is set to 1, the DX
register is defined as the "device key." The device key is a 16-bit
value that is returned by Interrupt 4BH, Allocate Device function
((AH)=B0H, (AL)=02H), (AX)=8002H. (The device key is available
also from Interrupt 15H, Return Boot Device ID and Key function
((AH) = D6H).)
The following information is passed to the boot record:
(CS) = 0000H
(IP) = 7C0H
(DX) - Boot device identifier or device key
When (DX) is a boot device identifier, (DH) and (DL) are
defined as follows:
(DH) - Device identifier
Bit 7 - Removable-media indicator
= 0 - Non removable media
= 1 - Removable media
Bit 6 - Reserved
Bit 5 - Access mode
= 0 - Device is supported by Interrupt 13H
= 1 - Device is supported by Interrupt 4BH
Bits 4 to 0 - Peripheral-device type
(DL) - Device instance
= 00H - First diskette drive (if the access-mode bit is set to 0)
- First CD-ROM drive (if the access-mode bit is set to 1)
= 80H- First fixed disk drive (if the access-mode bit is set to 0)
Dein Code ist nach Ansicht des BIOS also nicht valid.
fchk
Wow, vielen Dank für die Unterstützung. Die Informationen der
übergebenen Parameter sind auch sehr interessant.
Es wir nun aber ja gesagt, dass "zum Beispiel" das erste Byte größer als
6 sein muss. Das ist bei mir auch der Fall. Wo kann ich denn nun die
restlichen Voraussetzungen für validen Code finden?
Ich habe mir vor Jahren auch mal zum Testen einen winzigen Kernel
geschrieben... (der hat nichts anderes getan, als eine kurze Textmeldung
auszugeben und auf Knopfdruck den Bildschirm in verschiedenen Farben
einzufärben....) einfach just for fun.
Habe das damals auf Diskette geschrieben und jetzt mal geschaut, ob das
auch funktioniert, wenn ich das mit HxD auf einen USB-Stick schreibe...
Ergebnis: Ja, funktioniert genauso.
Hast Du in HxD im Menü Extras->Datenträger öffnen auch den Punkt
"Physische Datenträger" anstatt "Logische Datenträger" genutzt ?
Welchen Assembler nutzt Du ?
MS-DOS habe ich leider nicht.
Ich habe den USB-Stick als logischen Datenträger ausgewählt, weil mir
war ja schon bewusst, dass ich den Bootsektor an den physikalischen
Sektor 0 schreiben muss.
Ich benutze NASM.
Kannst du mir vielleicht den Code deines Bootloaders geben? Oder
zumindest das assemblierte Hexfile? Dann würde ich nämlich einfach mal
testen ob es damit funktioneirt :)
> Ich habe den USB-Stick als logischen Datenträger ausgewählt [...]
Das ist dann aber nicht korrekt. Weil dann der "Sektor 0" nicht der
physische Sektor 0 des Datenträgers sondern der logische Sektor 0 der
ersten Partition ist. Fieserweise endet dieser Sektor auch mit 55AA!
Allerdings steht auch deutlich FAT (oder NTFS) drin.
Wenn man den
> Bootsektor an den physikalischen Sektor 0 schreiben muss
dann muss auch der physische Datenträger ausgewählt sein.
..wie schon geschrieben: In HxD den "physischen" Datenträger auswählen,
da Du sonst an die falsche Stelle schreibst.
Ich hänge Dir hier mal meinen alten (geringfügig geänderten) Quelltext
und die fertig kompilierte Image-Datei zum Testen an.
Ist, wie gesagt, schon ziemlich alt. "Unschönheiten" im Quelltext gehen
allein auf meine Kappe ;-))
Gruß
Tom
Ja, ich habe natürlich den physischen Datenträger ausgewählt, habe es
nur in meinem Post oben verwechselt :)
Ich habe festgestellt, dass wenn ich den Stick als FAT32 formatiere, er
gar nicht erkannt wird. Mit FAT geht es (ich nehme an das ist FAT16).
Ich habe meinen eigenen Bootcode and die Stelle eingefügt, an die die
Sprunganweisung ganz am Anfang des MBR hinspringt. Den restlichen Code,
der durch das Formatieren vorhanden ist, musste ich merkwürdigerweise
drin lassen, denn wenn ich den mit Nullen überschreibe, aht es nicht
funktioniert...
Danke für deine Dateien, damit komme ich hoffenlich nochmal ein weiteres
Stück weiter :)
