Eigenes OS?

PrettyOS [Version 0.1.0105] (C) 2009 henkessoft.de
Usable RAM: 3931391 KB  
RAM Disk at: 4008100Ch

Floppy Driver Test!

Bleibt dann hängen. Keine weitere Ausgabe. Das liegt aber nicht am Bootloader.

Zum Thema USB Stick unter WindowsXP kann ich folgendes beitragen:

Da mir die Seite von Erhard Henkes ein bisschen zu fortgeschritten ist,
habe ich erstmal diesen Bootrecord
http://lowlevel.brainsware.org/wiki/index.php/Eigener_Boot_Record
mit dem NASM Assembler als bootrecord.bin assembliert.

Mit dem HP USB Disk Storage Format Tool
http://www.chip.de/downloads/HP-USB-Disk-Storage-Format-Tool_23418669.html
habe ich nen asbachuralt 64MB USB Stick mit dem FAT Dateisystem formatiert.

Mit dem Hexeditor
http://wintotal.de/softw/index.php?id=2286
konnte ich unter Datei/Datenträger/Datenträger öffnen den USB-Stick öffnen, ebenso
die Datei bootrecord.bin.

Dann einfach per Copy and Paste den Bootrecord Salat in den USB-Stick Salat reinkopiert,
den USB Stick salat gespeichert.

Der USB-Stick ließ sich anschließend in der Tat booten, was mir die folgenden
Zeilen am Monitor nach einem Neustart bestätigten:

HELLO World!
This is no OS. Press any key to reboot.

Das könnte für den einen oder anderen hilfreich sein, der sonst nicht weiß, wie er
seinen Bootrecord am USB-Stick testen kann.
Wenn nicht, einfach diesen Beitrag löschen.

Erhard Henkes

Bleibt dann hängen. Keine weitere Ausgabe.

Daher hatte ich die Version 106 geschrieben mit DEBUG-Meldungen:

// floppy disk with DMA Buffer
    flpydsk_set_working_drive(0); // set drive 0 as current drive
	printformat("DEBUG ckernel.c: after flpydsk_set_working_drive(0)\n");
	sti();
	flpydsk_install(6);           // floppy disk uses IRQ 6
    printformat("DEBUG ckernel.c: after flpydsk_install(6)\n");
	k_memset((void*)DMA_BUFFER, 0x0, 0x2400);
	printformat("DEBUG ckernel.c: after k_memset\n");

    tasking_install(); // ends with sti()

Die Zeile "DEBUG ckernel.c: after flpydsk_set_working_drive(0)" taucht bei euch noch auf, d.h. es klemmt bei:

flpydsk_install(6);

... in flpydsk.c:

void flpydsk_install(int irq)
{
	irq_install_handler(irq, i86_flpy_irq);
	flpydsk_initialize_dma();
	flpydsk_reset();
	flpydsk_drive_data(13, 1, 0xF, TRUE);
}

Dort müsste man nun weiter debuggen, wo es in der Funktion blockt. Es ist sicher ein Unterschied zwischen einer USB-Floppy und einer Floppy. Das heißt das Thema Booten und Floppy-/...-/Treiber hängt stark zusammen.

abc.w

Erhard Henkes schrieb:

@abc.w: Könntest Du das makefile bitte auch auf Windows übertragen?

Ich weiß leider nicht, was wären unter Windows Alternativen für dd, mount, umount und eject...
Linux -> Windows:
mkfs.msdos -> format
dd -> rawwrite ?
mount -> ?
cp -> copy
ls -> dir
umount -> ?
eject -> ?

Erhard Henkes schrieb:

mount: Es wurde kein Dateisystemtyp für /dev/sdc angegeben
Werde den Typ vfat versuchen

Kann man da FAT12 eingeben für die Floppy, damit die RootDir gelesen werden kann?

Die Diskette habe ich mit mkfs.msdos FAT12 formatiert (Parameter -F 12). mount benutzt vfat, weil ich es in der Konfiguration des Linux Kernels aktiviert habe und dort unter Hilfe steht:

CONFIG_VFAT_FS:
This option provides support for normal Windows file systems with
long filenames. That includes non-compressed FAT-based file systems
used by Windows 95, Windows 98, Windows NT 4.0, and the Unix
programs from the mtools package.
The VFAT support enlarges your kernel by about 10 KB and it only
works if you said Y to the "DOS FAT fs support" above...

Erhard Henkes

Könntest Du in der 106er bitte diese ergänzte Funktion in flpydsk.c einbauen, um heraus finden, wo es bei Dir mit der USB-Floppy aussteigt:

void flpydsk_install(int irq)
{
    irq_install_handler(irq, i86_flpy_irq);
    printformat("DEBUG flpydsk.c: after irq_install_handler");
    flpydsk_initialize_dma();
    printformat("DEBUG flpydsk.c: after flpydsk_initialize_dma");
    flpydsk_reset();
    printformat("DEBUG flpydsk.c: after flpydsk_reset");    
    flpydsk_drive_data(13, 1, 0xF, TRUE);
    printformat("DEBUG flpydsk.c: after flpydsk_drive_data");
}

Ich tippe auf "flpydsk_drive_data" als Hemmschuh.

Erhard Henkes

Ich weiß leider nicht, was wären unter Windows Alternativen für dd, mount, umount und eject...
Linux -> Windows:
mkfs.msdos -> format
dd -> rawwrite ?
mount -> ?
cp -> copy
ls -> dir
umount -> ?
eject -> ?

Anstelle rawwrite nehme ich lieber das primitive partcopy, weil ich rawwrite nicht aus dem makefile sauber ansteuern konnte. mount/unmount keine Ahnung. Format macht man vorher.

abc.w

Erhard Henkes schrieb:

Könntest Du in der 106er bitte diese ergänzte Funktion in flpydsk.c einbauen, um heraus finden, wo es bei Dir mit der USB-Floppy aussteigt:
...

Kleiner Verbesserungsvorschlag zu Debug-Ausgaben: gcc kennt __FILE__ und __LINE__, z.B.:

printformat("%s: %u", __FILE__, __LINE__);
printformat("DEBUG %s: after irq_install_handler (line %u)", __FILE__, __LINE__);

abc.w

Erhard Henkes schrieb:

Könntest Du in der 106er bitte diese ergänzte Funktion in flpydsk.c einbauen, um heraus finden, wo es bei Dir mit der USB-Floppy aussteigt:
void flpydsk_install(int irq)
{
    irq_install_handler(irq, i86_flpy_irq);
    printformat("DEBUG flpydsk.c: after irq_install_handler");
    flpydsk_initialize_dma();
    printformat("DEBUG flpydsk.c: after flpydsk_initialize_dma");
    flpydsk_reset();
    printformat("DEBUG flpydsk.c: after flpydsk_reset");    
    flpydsk_drive_data(13, 1, 0xF, TRUE);
    printformat("DEBUG flpydsk.c: after flpydsk_drive_data");
}
Ich tippe auf "flpydsk_drive_data" als Hemmschuh.

Bekomme folgende Ausgabe:

DEBUG flpydsk.c: after irq_install_handler
DEBUG flpydsk.c: after flpydsk_initialize_dma

Erhard Henkes

Aha! Der Reset ist also schon das Problem.

// reset controller
void flpydsk_reset()
{
	ULONG st0, cyl;
	flpydsk_disable_controller();
	flpydsk_enable_controller();
	flpydsk_wait_irq();

	// send CHECK_INT/SENSE INTERRUPT command to all drives
	int i;
	for(i=0; i<4; ++i)
		flpydsk_check_int(&st0,&cyl);
	flpydsk_write_ccr(0);              // transfer speed 500kb/s
	flpydsk_drive_data(3,16,240,TRUE); // pass mechanical drive info: steprate=3ms, load time=16ms, unload time=240ms
	flpydsk_calibrate(_CurrentDrive);  // calibrate the disk
}

Ja, da ist bereits ein flpydsk_drive_data(...) drinnen, aber auch ein flpydsk_wait_irq(). Ganz schön verschachtelt der ganze Kram. Könntest Du bitte weiter suchen?

Aha! Vielleicht ist ja alles ganz trivial:

// flpydsk.c (version 105+106)

// die 240 hier
void flpydsk_reset()
{
(...)
 flpydsk_drive_data(3,16,240,TRUE); // pass mechanical drive info: steprate=3ms, load time=16ms, unload time=240ms
(...)
}

// hat auf "data" keinen Einfluß: (240 & 0xF) -> 0
void flpydsk_drive_data(ULONG stepr, ULONG loadt, ULONG unloadt, int dma )
{
(...)
 data = ((stepr & 0xf) << 4) | (unloadt & 0xf);
 flpydsk_send_command(data);
(...)
}

Erhard Henkes

@ +gjm+: Bootest Du auch mittels USB-Floppy?

Aha! Vielleicht ist ja alles ganz trivial

Hast Du einen konkreten Verbesserungsvorschlag? Mit einem klassisch angebundenen Floppy-LW läuft es (fast überall, einige störrische PCs gibt es leider immer).

http://www.isdaman.com/alsos/hardware/fdc/floppy.htm
siehe Abschnitt "Fix Drive Data (x3h)"
http://www.isdaman.com/alsos/hardware/fdc/floppy_files/FixData.gif
Ich denke, dass die ganze Funktion falsch aufgebaut ist, 240 daher ein Fehler und 15 (0xF) als "Head Unload Time Entry" richtig ist.
Passt ja auch zu: flpydsk_write_ccr(0); // transfer speed 500kb/s

Auf jeden Fall erkennt man hier, dass Floppy-Treiber und Bootloader momentan bei PrettyOS von einer gemeinsamen Gruppe bearbeitet werden müssen. Wir sind ja schon mitten drin.

Also folgendes probieren:

// reset controller
void flpydsk_reset()
{
	ULONG st0, cyl;
	flpydsk_disable_controller ();
	flpydsk_enable_controller ();
	flpydsk_wait_irq ();

	// send CHECK_INT/SENSE INTERRUPT command to all drives
	int i;
	for(i=0; i<4; ++i)
		flpydsk_check_int(&st0,&cyl);
	flpydsk_write_ccr(0);              // transfer speed 500kb/s
	flpydsk_drive_data(3,16,0xF,TRUE); // pass mechanical drive info: steprate=3ms, load time=16ms, unload time=240ms (entry: 0xF) //http://www.isdaman.com/alsos/hardware/fdc/floppy.htm //Fix Drive Data (x3h)
	flpydsk_calibrate(_CurrentDrive);  // calibrate the disk
}

0xF anstelle 240

Erhard Henkes schrieb:

@ +gjm+: Bootest Du auch mittels USB-Floppy?

Asche auf mein Haupt! Das hätte ich lieber mal von Anfang an sagen sollen: Stage 1 in seiner jetzigen Form funktioniert nur mit Floppy-Laufwerken. Das er (scheinbar) auch mit USB-Floppys oder USB-Sticks funktioniert, hat einen ganz trivialen Grund: Das BIOS emuliert! Aber spätestens nach Stage 2 ist der Prozessor im PM. Dann ist Feierabend mit dem BIOS und PrettyOS läuft nur noch solange nach Plan weiter, bis es zum ersten Zugriff im PM auf das Laufwerk kommt. Effektiv testen (was heißt über Stage 2 hinaus) kann man PrettyOS z.Zt. nur mit einem physikalisch vorhandenen Floppy-Laufwerk. (Oder indem der Quellcode gelesen wird). Aber technisch gesehen ist es nach wie vor möglich, PrettyOS von einem USB-Floppy oder einem "pen drive" zu starten. Die Frage ist eigentlich nur, ob man im PM auf das "Bootgerät" zugreifen will oder muß (oder wird). Deshalb gibt es in dem Sinne leider auch keine Verbesserungsvorschläge.

Erhard Henkes

@ +gjm+: Du meinst der Floppy-Treiber kann nichts ausrichten, weil er nicht mehr an den Floppy-Controller heran kommt? Ich kann es nicht testen, weil ich kein USB-Floppy-LW besitze.

Auf jeden Fall haben wir einen Fehler im Floppy-Treiber gefunden. Wenn man bei 500K Transfer Rate die 240 ms Head Unload Time haben will, muss man 0xF eingeben und nicht 240. Analog muss man auch noch die Head Load Time Eingabe überprüfen. Da macht das offensichtlich aber nur Faktor 2 aus.
http://www.isdaman.com/alsos/hardware/fdc/floppy.htm

taljeth

Auf den FDC zugreifen, bringt offensichtlich nichts, wenn das Laufwerk ein USB-Gerät ist. In dem Fall bräuchtest du USB-Treiber. Das BIOS bietet dir halt den passenden Treiber über int 13h an, deswegen funktioniert das, solange du das BIOS benutzt.

Erhard Henkes

Das wirft nun für die OS-Community Grundsatzfragen für das Design auf, denn die meisten User haben heutzutage kein klassisch angeschlossenes Floppy-LW mehr, lediglich die USB-Variante.
@ taljeth: hast Du einen Link auf ein Beispiel, wo jemand mit USB-Treiber auf eine Floppy zugreift? Auf der anderen Seite wäre dann der USB-Stick die bessere Variante. Also entweder klassische Floppy oder USB-Stick?

Mal nicht so schnell jetzt. Im Prinzip darf in der ckernel.c nur nicht "direkt" (was heißt per Name) auf "irgendwas" in der flpydsk.c zugegriffen werden. Das ist eigentlich schon alles was vielleicht geändert werden sollte. Irgendwann kommt eh noch eine pendrv.c hinzu.

Erhard Henkes

@ +gjm+: Wir sind noch zusammen.

http://www.usb-center.de/Externe_USB-Floppy_-_USB-Diskettenlaufwerk_USB-1901.html

Im Prinzip darf in der ckernel.c nur nicht "direkt" (was heißt per Name) auf "irgendwas" in der flpydsk.c zugegriffen werden.

Richtig, da muss eine Abstraktionsebene dazwischen.

Ehrlich gesagt habe ich die USB-Floppy eigentlich für einen Hoax gehalten. Wenn PrettyOS USB im PM unterstützt, dann werden gleichzeitig eine ganze Reihe von Geräten unterstützt. Darauf sollte PrettyOS durch "Abstraktion" langsam vorbeitet werden. Aber bevor die Geräteflut hereinbricht.

Erhard Henkes

Heute abend um 21.20 h treffen wir uns im Channel #PrettyOS.

Erhard Henkes schrieb:

Heute abend um 21.20 h treffen wir uns im Channel #PrettyOS.

^^ vielleich schau ich auch mal rein.