Eigenes OS?
-
Wenn das BIOS es unterstützt, sollte das Laufwerk über int 13h genauso aussehen wie ein ganz normales Floppylaufwerk auch.
-
Erhard Henkes schrieb:
Kannst Du Dir hier ziehen: http://www.henkessoft.de/OS_Dev/Downloads/106.zip
Vielen Dank! Stell da mal eine Seite rein auf der die Versionen schön sauber aufgelistet sind (zusammen mit den Chat-Protokollen).
abc.w schrieb:
Ausprobiert, geht nicht. Keine Ausgaben, BIOS geht dann weiter und bootet von der Festplatte...
Probier mal folgendes:
; boot.asm (version 106) ReadSectors: (...) ; mov dl, BYTE [DriveNum] ; ändern in: mov dl, BYTE [bootdevice] ; Da unklar ist welche "Nummer" das Bootdevice hat, (...) ; wird "bootdevice" schon die richtige Nummer sein.Setzt aber voraus, daß das BIOS "CHS-Zugriffe" auf ein USB-Gerät unterstützt (emuliert).
Die Version 106 startet auch "vollständig" von einem USB-Stick. Allerdings unter folgender Voraussetzung:- Der USB-Stick muß FAT12-formatiert sein.
-
@+gjm+: Danke für den Versuch. Kannst Du noch etwas dazu sagen, wie man einen USB-Stick sauber mit FAT12 formatiert? Siehe z.B. hier: http://forum.chip.de/partition-formatierung/fat12-formatieren-750786.html
..
-
Chat-Protokolle
... befinden sich in unserem Forum (bitte Badestrand anmailen)
Hier ist noch die Version 105 (106 war eine experimentelle Variante wegen des Floppy Treibers, um zu sehen, was bei echten PCs geht und was nicht
): http://www.henkessoft.de/OS_Dev/Downloads/105.zipSo sieht das bei mir mit Bochs (gebootet von echter Floppy) aus:
PrettyOS [Version 0.1.0105] (C) 2009 henkessoft.de Usable RAM: 1048124 KB Ram Disk at: 4008100Ch Floppy Driver Test! <Floppy Disc Root Dir> PRETTYOS 0 byte (lab) 1st phys. sec: 31 BOOT2.SYS 912 byte (arc) 1st phys. sec: 33 CKERNEL.SYS 33648 byte (arc) 1st phys. sec: 35 <DIR> dev 35 file1 35 file2 35 file3 1693 shell $> hi <-- I am PrettyOS. Always at your service! $>Die obere Auflistung betrifft die Root Directory der Floppy Disk, während nachstehend die RAM Disk Struktur (vom User-Bereich mit incbin in den Kernel eingeschleuste Programme, z.B. shell) dargestellt wird. Details findet man hier: http://www.henkessoft.de/OS_Dev/OS_Dev3.htm#mozTocId610721
-
Erhard Henkes schrieb:
Die obere Auflistung betrifft die Root Directory der Floppy Disk, ...
Und genau das ist ein großes Problem. Die boot.asm ist teilweise "hardcoded" und deshalb nur für eine Diskette geeignet. Wenn ein USB-Stick formatiert ist, hat er einen MBR und eine Partition. "Angesprochen" wird er vom BIOS (falls das BIOS das unterstützt) via CHS (wobei gilt: CHS = xxx 255 63 (xxx = je nach Größe)).
Normalerweise gehört die "boot.bin" in den ersten logischen Sektor der Partition (sprich ganz an den Anfang der Partition). Aber dann stimmt die gesamte "CHS-Zugriffslogik" nicht mehr. Prinzipell aber kein Problem das anzupassen.
Allerdings das unangenehmste an der boot.bin ist das Dateisystem:
Wenn man auf der Diskette eine Datei löscht und wieder raufkopiert, dann stimmt die Struktur des Root-Directory nicht mehr. Dummerweise werden gelöschte Dateien nicht gelöscht, sondern nur als gelöscht markiert. Was heißt, daß dann das Root-Directory einen Eintrag zuviel hat und geparst werden muß.
Entweder programmiert jemand einen 510 Byte großen FAT12-Parser (und für den USB-Stick am besten gleich einen FAT32-Parser) oder beim Bootloader muß auf die Vorzüge eines FS verzichtet werden.
-
Spätestens bei Bootmedien mit Partitionen wird aus Stage1 wohl sämtlicher Filesystem Code verschwinden müssen. Die Partitionstabelle liegt nämlich auch im MBR. Es sind also letztendlich nur noch 440 Byte nutzbar für Stage1. Die jetzige Stage1 ist mit 480 Byte also schon zu groß. Die Stage1 von Grub ist auch schon 400 Byte groß ohne jeglichen Filesystem Code.
Allerdings nutzt Grub einen anderen Trick aus. Der MBR besteht zwar nur aus den ersten Sektor des Bootmediums, aber der Rest des ersten Kopfes ist unbenutzt. Grub legt Stage2 also in diesen ungenutzen Platz auf dem ersten Kopf. Die Installationsroutine von Grub überprüft allerdings die Größe und kann die Stelle von Stage2 nachträglich in der compilierten Stage1 patchen.
-
Wenn Stage 1 die CHS der eigenen Partition selbst ermittelt (z.B. durch Auslesen der Partitionstabelle des MBR), dann müssen "Seltsamkeiten" wie bei GRUB erst nicht in Erwägung gezogen werden.
In der eigenen Partition ist Platz genug für "seltsames" (jedenfalls solange wie PrettyOS noch kein FS hat).
-
Dort sitzt aber normal schon ein Dateisystem, das seine eigenen Vorstellungen davon hat, wie der Platz genutzt wird. Ich denke, man wird eher nicht drum herumkommen, in stage1 ein paar Sektornummern von stage2 reinzupatchen.
-
Wenn die Position von Stage 2 der Stage 1 "nachträglich" mitgeteilt werden muß, dann ist es schlechtes Design.
-
Dann hat gutes Design leider die Eigenschaft, dass es nicht funktioniert.
-
Ich hab grad mal meine Grub Installationen geprüft. Auf der Diskette (ext2) und der Festplatte (ext3) liegt Stage2 im Sektor 1, also direkt hinter dem MBR.
Was würde man denn machen wenn das Dateisystem dann doch mal in Sektor 1 beginnt? Stage2 in die Zuordnungstabelle eintragen und hoffen das das Dateisystem nicht auf die Idee kommt die Datei zu verschieben (Stichwort defragmentieren bei ntfs)?
-
Du müsstest mal schauen, was GRUB auf einer Diskette macht, dort hat man diesen Platz ja nicht, wenn ich mich grad nicht täusche. Aber stimmt, mit Dateisystem und Defragmentierung hast du wohl verloren.
-
taljeth schrieb:
Du müsstest mal schauen, was GRUB auf einer Diskette macht, dort hat man diesen Platz ja nicht, wenn ich mich grad nicht täusche. Aber stimmt, mit Dateisystem und Defragmentierung hast du wohl verloren.
Stimmt, bei der Diskette ist es doch nicht Sektor 1. Ich habe mir mit Hexdump nur 1 byte anzeigen lassen...
Also bei der Diskette liegt Stage2 mitten auf der Diskette und ist im Dateisystem eingetragen. Also bräuchte man um sicher zu gehen wirklich einen Installer der mit dem Dateisystem auf dem Bootmedium klarkommen muss.
-
+gjm+ schrieb:
Probier mal folgendes:
; boot.asm (version 106) ReadSectors: (...) ; mov dl, BYTE [DriveNum] ; ändern in: mov dl, BYTE [bootdevice] ; Da unklar ist welche "Nummer" das Bootdevice hat, (...) ; wird "bootdevice" schon die richtige Nummer sein.Setzt aber voraus, daß das BIOS "CHS-Zugriffe" auf ein USB-Gerät unterstützt (emuliert).
Die Version 106 startet auch "vollständig" von einem USB-Stick.Hab's noch nicht ausprobiert, werde es noch nachholen.
Ich beobachte jetzt folgendes Verhalten: Mein BIOS scheint keine Probleme zu haben vom USB Stick zu starten. Ich habe auf dem Stick meinen Dummy-Bootloader kopiert, der mit int 13 einen Sektor lesen soll. Der Dummy-Bootloader scheint vom USB-Diskettenlaufwerk zu lesen (erkennbar an den Geräuschen vom USB-Diskettenlaufwerk :)).
Hier ist mein Dummy-Bootloader:[Bits 16] org 0x7C00 ; start address of bootloader xor ax, ax mov ds, ax mov es, ax mov fs, ax mov gs, ax mov si, szStartMessage call print_string CheckDriveStatus: mov ax, 0x0100 ; Check status of the first floppy disk mov dx, 0x0000 int 0x13 cmp al, 0x00 jne DriveStatusError mov ax, 0x0000 ; Initialize es:bx buffer address pointer mov es, ax mov bx, Buffer mov ax, 0x0201 ; Read sector to the buffer at es:bx mov cx, 0x0001 mov dx, 0x0000 int 0x13 mov si, szReadSectorDone call print_string jmp CheckDriveStatus DriveStatusError: mov si, szDriveStatusError call print_string jmp CheckDriveStatus ;****************************************************************************** ; Print String ; DS:SI null-terminated string ;****************************************************************************** print_string: .loop: mov ah, 0x0E ; BIOS function 0x0E: teletype lodsb ; grab a byte from SI test al, al ; NUL? jz .done ; if the result is zero: get out int 0x10 ; else: print out the character jmp .loop .done: ret szStartMessage db "Started from USB stick", 0x0D, 0x0A, 0 szDriveStatusError db "Drive status error", 0x0D, 0x0A, 0 szReadSectorDone db "Reading sector done", 0x0D, 0x0A, 0 TIMES 510-($-$$) hlt ; fill bytes until boot signature db 0x55 ; boot signature db 0xAA ; boot signature Buffer: ; Start of buffer
-
Hab noch ein wenig rumexperimentiert - mein BIOS weigert sich, vom USB-Diskettenlaufwerk zu starten. Geht einfach weiter und bootet von der Festplatte.
Nach dem Booten vom USB Stick ist bei mir übrigens DX = 0x0080. D.h. USB Stick = "1st hard disk"
-
mein BIOS weigert sich, vom USB-Diskettenlaufwerk zu starten
Hast Du nicht schon den BL Stage 1 davon gestartet, oder war das vom USB-Stick?
Er konnte doch nur den BL Stage 2 nicht nachladen, oder verwechsle ich da etwas?
-
Erhard Henkes schrieb:
mein BIOS weigert sich, vom USB-Diskettenlaufwerk zu starten
Hast Du nicht schon den BL Stage 1 davon gestartet, oder war das vom USB-Stick?
Er konnte doch nur den BL Stage 2 nicht nachladen, oder verwechsle ich da etwas?Stage 1 Bootloader habe ich bis jetzt immer nur vom USB-Stick starten können. Und dieser Stage 1 Bootloader kann irgendwie auf den USB-Diskettenlaufwerk zugreifen (der gleichzeitig am anderen USB Port angeschlossen ist), findet aber den Stage 2 Bootloader nicht.
Das habe ich auch alles mit meinem Dummy-Bootloader nachvollzogen. Und wie ich vorhin gepostet habe, USB-Sticks werden von meinem BIOS als "1st hard disk" abgebildet (int 13h mit DL = 0x80) und USB-Diskettenlaufwerke werden als "1st floppy disk" abgebildet (int 13h mit DL = 0x00). Und Booten vom USB-Diskettenlaufwerk geht interessanterweise nicht.
-
Du hast nicht zufällig einen GRUB auf der Platte? Ansonsten könntest du es mal mit "chainloader (fd0)+1" versuchen (also GRUB von der Platte booten und den wiederum den Bootloader von der Floppy laden lassen).
-
Stage 1 Bootloader habe ich bis jetzt immer nur vom USB-Stick starten können. Und dieser Stage 1 Bootloader kann irgendwie auf den USB-Diskettenlaufwerk zugreifen (der gleichzeitig am anderen USB Port angeschlossen ist), findet aber den Stage 2 Bootloader nicht. Das habe ich auch alles mit meinem Dummy-Bootloader nachvollzogen. Und wie ich vorhin gepostet habe, USB-Sticks werden von meinem BIOS als "1st hard disk" abgebildet (int 13h mit DL = 0x80) und USB-Diskettenlaufwerke werden als "1st floppy disk" abgebildet (int 13h mit DL = 0x00). Und Booten vom USB-Diskettenlaufwerk geht interessanterweise nicht.
Danke für die Zusammenfassung.
-
abc.w schrieb:
Das habe ich auch alles mit meinem Dummy-Bootloader nachvollzogen.
Der Stack sollte noch initialisiert werden.
abc.w schrieb:
Und Booten vom USB-Diskettenlaufwerk geht interessanterweise nicht.
Lade das Floppy-Image mal irgendwo hoch. Ich will es mir mal genauer ansehen.
abc.w schrieb:
Und wie ich vorhin gepostet habe, USB-Sticks werden von meinem BIOS als "1st hard disk" abgebildet (int 13h mit DL = 0x80) und USB-Diskettenlaufwerke werden als "1st floppy disk" abgebildet (int 13h mit DL = 0x00).
Das ist auch ok so. Das BIOS ist der Ansicht, daß es sich bei dem USB-Stick um eine Festplatte handelt. So soll das auch sein. Nun kannst du via CHS, INT13 und DL = 0x80 beliebig auf den USB-Stick zugreifen. Aber Vorsicht bei DL=0x81! Das wird wahrscheinlich die "echte" Festplatte sein.
Aber wie schon gesagt, die "boot.bin" ist "hardcoded" und nur für eine FAT12-formatierte Diskette geeignet! (FAT12 nur dehalb, weil man da (halbwegs) sicher sein kann, daß sich Dateien im Root-Verzeichnis an einer ganz bestimmten CHS-Position befinden).
Wenn du ganz vom USB-Stick starten willst, dann sind Anpassungen in der CHS-"Leselogik" erforderlich.
Die allgemeine CHS-Konfiguration für einen USB-Stick ist wie folgt:
CHS = xxx 255 63, wobei xxx je nach Größe des Sticks differiert.