4. PrettyOS Fehler-/Testthread

PrettyOS Fehler-/Testthread

  • M

    Das kompilieren unter Windows sollte eig. auch nicht mehr so schwer sein 😉

    Das Problem mit dem Absturz unter VPC und VB hat ehenkes übrigens soeben behoben.

    Dafür hab ich folgendes entdeckt:
    Wir haben einen Schreibcursor. Dies hab ich erst jetzt gemerkt, da er bei mir nur unter Microsoft Virtual PC funktioniert (Nutze ich selten). Qemu und Virtual Box zeigen ihn schlichtweg nicht an.
    Das dürfte ein Fehler sein.

    Die zu schnelle Uhr unter Virtual Box besteht auch weiterhin.

    0
  • C

    So, hier alle meine Test-PCs für PrettyOS:

    http://prettyos.fanofblitzbasic.de/Computers/

    0
  • A
     

    D:\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS
nasmw -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloade
r/boot.bin
nasmw -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootload
er/BOOT2.BIN
del *.o
nasmw -O32 -f elf user/user_program_c/start.asm -Iuser/user_program_c/ -o start.
o
i586-elf-gcc user/user_tools/userlib.c -c -Iuser/user_tools -m32 -std=c99 -Wshad
ow -march=i386 -mtune=i386 -m32 -fno-pic -Werror -Wall -O -ffreestanding -fleadi
ng-underscore -nostdlib -nostdinc -fno-builtin -fno-stack-protector -Iinclude
process_begin: CreateProcess(NULL, i586-elf-gcc user/user_tools/userlib.c -c -Iu
ser/user_tools -m32 -std=c99 -Wshadow -march=i386 -mtune=i386 -m32 -fno-pic -Wer
ror -Wall -O -ffreestanding -fleading-underscore -nostdlib -nostdinc -fno-builti
n -fno-stack-protector -Iinclude, ...) failed.
make (e=2): Das System kann die angegebene Datei nicht finden.
mingw32-make: *** [initrd] Error 2

    Kann jemand damit was anfangen???

    Cygwin ist aus dem Pfad herausgenommen.

    0
  • A

    Nochmal ich: Revision 163 läuft unter VBox mehr oder wenige in einer Endlosschleife. Ständig wiederholt sich der USB-Status. Befehle scheinen aber abgearbeitet zu werden. Unter Qemu hingegen läuft das System normal.

    0
  • E
    Mod

    Ständig wiederholt sich der USB-Status. <--- wenn dich das stört, hier abschalten:

    initEHCIHostController(); // used only for first tests
    Zeile 188 pci.c auskommentieren

    oder:
    in Sun VBox einfach unter Änderungen / USB / USB 2.0 checkbox deaktivieren 😉

    0
  • ?

    Revision 162

    anubis2k5 schrieb:

    Kann jemand damit was anfangen???

    Ja, Das Problem hatte ich auch. 🙂 "mingw32-make.exe" findet die "i586-elf-gcc.exe" nicht. Versuch mal die "Umgebungsvariablen" korrekt zu setzen, so wie Cuervo es hier im ersten Beitrag beschrieben hat ( -> pdf).

    Mr X schrieb:

    Die zu schnelle Uhr unter Virtual Box besteht auch weiterhin.

    Das liegt an der "systemTimer_setFrequency" aus der "timer.c" Das "command byte" sollte besser auf "Mode 2" gesetzt werden:

    // timer.c Revision 162

void systemTimer_setFrequency( uint32_t freq )
{
(...)                                             
    // Send the command byte
//    outportb(0x43, 0x36); // 0x36 -> Mode 3 : Square Wave Generator
    outportb(0x43, 0x34); // 0x34 -> Mode 2 : Rate Generator
(...)
}

    Mr X schrieb:

    Wir haben einen Schreibcursor. Dies hab ich erst jetzt gemerkt, da er bei mir nur unter Microsoft Virtual PC funktioniert (Nutze ich selten).
    Qemu und Virtual Box zeigen ihn schlichtweg nicht an. Das dürfte ein Fehler sein.

    Der "Schreibcursor" ist ein Feature von "Virtual-PC". Wenn die "update_cursor" aus der "video.c" so hier verändert wird:

    // video.c Revision 162

void update_cursor()
{
(...)
 position = 0;
 outportb(0x3D4, 0x0E);
(...)
}

    dann erscheint der Schreibcursor immer an Position (0,0) obwohl die Eingaben stets an der korrekten Position sind.

    0
  • G

    Cuervo schrieb:

    So, hier alle meine Test-PCs für PrettyOS:

    http://prettyos.fanofblitzbasic.de/Computers/

    Bei Deiner Sammlung fühle ich mich richtig heimisch 😉

    0
  • T

    Zum Fehler gerade warum sich VirtualBox bei mir mit einem Fehler verabschiedet:

    Es sieht so aus als wenn nach dem Aktiveren von Paging in den Bereich zwischen 0 und 20 mb geschrieben wird. Dieser Bereich ist zwar gemappt, aber (Außer 0xB8000) nicht zum schreiben freigegeben. Setze ich in paging.c in Zeile 252 noch MEM_WRITE läuft es. Wo das passiert und warum das scheinbar nur bei mir auftritt hab ich noch nicht überprüft.

    0
  • ?

    Revision 169 (und folgende)

    Wenn die KERNEL.BIN nach dem Kompilieren größer 52.732 Bytes ist, dann bleiben VPC und VB schon beim Booten stecken.

    Das Problem ist in der "Fat12.inc" und dort ab Label "LoadFile:".

    Kurz gesagt, wenn BX ein "Wrap-Around" macht (was heißt von z.B. 0xFF00 + 0x0200 auf 0x0100 kommt), dann muß das Segmentregister ES entsprechend aktualisiert werden (i.e. ES = ES + 0x0100). 🙂

    Anderenfalls überschreibt "ReadSectors" via [es:bx] etwas und/oder bleibt einfach im "int 0x13" stecken.

    0
  • E
    Mod

    Danke für den Hinweis. Ich habe die kernel.bin zunächst auf ca. 50 KB verkleinert (ab Rev. 175), damit wir da nicht anstoßen. Aber da muss uns was einfallen.

    0
  • ?

    Revision 175

    Zunächst einmal, entschuldigt bitte, daß ich noch bei Revision 175 bin. Aber ich schreibe gerade an einem Userprogramm, welches auf Festplatten zugreifen kann. Dazu mussten einige Dateien geändert werden und ich habe keine Lust, sie bei jeder neuen Revision wieder zu ändern.

    ~Eigentlich soll das ja ein Kerneltreiber werden. Aber die großzügigen Debugausgaben und ein kleines Menü zur bequemeren Bedienung beim Testen (typisch Windowser) haben leider den Umfang der KERNEL.BIN gesprengt. :(~

    Nun zum Thema:

    Wenn man in der Shell versehentlich eine falsche Eingabe macht, dann werden auch "leere" Einträge angezeigt. Das stört etwas beim Testen. Bislang löse ich das Problem via "Hotfix":

    // fat12.c Revision 175

uint32_t search_file_first_cluster(const char* name, const char* ext, struct file* f)
{
 (...)
   for(uint8_t i=0;i<224;i++)
   {
       read_dir(&entry, i, 19, false);

if ((&entry)->Filename[0] == 0) { break; } // <- wenn der eintrag leer ist, dann kommen auch keine mehr. also raus hier :)

    (...)
   }
 (...)
}

    Eventuell könnte der Hotfix mal verschwinden? 🙂

    Btw.:
    Ihr seid ja beim Thema USB ganz schön am ackern. 👍 Hoffentlich kommt dabei der Spaß nicht zu kurz!

    0
  • E
    Mod

    wenn der eintrag leer ist, dann kommen auch keine mehr. also raus hier 🙂

    Danke für den Hotfix, ist jetzt ab Rev. 186 eingebaut.

    0
  • E
    Mod

    Ihr seid ja beim Thema USB ganz schön am ackern. 👍 Hoffentlich kommt dabei der Spaß nicht zu kurz!

    Kein leichtes Thema, aber es macht Spaß im Verbund mit anderen Mitstreitern an diesem anspruchsvollen Thema "arbeiten" zu dürfen.

    0
  • E
    Mod

    @+gjm+: was genau würdest du ändern im assembler programm fat12.inc?
    Hier der von dir angesprochene Bereich, der nun versagt:

    ;******************************************************************************
; LoadFile ()
; ES:SI   File to load
; EBX:BP  Buffer to load file to
; AX      Return value: success 0, error -1
;******************************************************************************

LoadFile:
	xor	ecx, ecx					; size of file in sectors
	push ecx

.FIND_FILE:
	push bx						; BX=>BP points to buffer to write to; store it for later
	push bp
	call FindFile				; find our file. ES:SI contains our filename
	cmp	ax, -1
	jne	.LOAD_IMAGE_PRE
	pop	bp
	pop	bx
	pop	ecx
	mov	ax, -1
	ret

.LOAD_IMAGE_PRE:
	sub	edi, ROOT_OFFSET
	sub	eax, ROOT_OFFSET

	; get starting cluster
	push word ROOT_SEG				;root segment loc
	pop	es
	mov	dx, WORD [es:di + 0x001A]	; DI points to file entry in root directory table. Refrence the table...
	mov	WORD [cluster], dx			; file's first cluster
	pop	bx							; get location to write to so we dont screw up the stack
	pop	es
	push bx							; store location for later again
	push es
	call LoadFAT

.LOAD_IMAGE:
	; load the cluster
	mov	ax, WORD [cluster]		; cluster to read
	pop	es						; bx:bp=es:bx
	pop	bx
	call Convert_Cluster_to_LBA
	xor	cx, cx
	mov cl, BYTE [SecPerClus]
	call ReadSectors
	pop	ecx
	inc	ecx
	push ecx
	push bx
	push es
	mov	ax, FAT_SEG						;start reading from fat
	mov	es, ax
	xor	bx, bx

	; get next cluster
	mov ax, WORD [cluster]				; identify current cluster
	mov cx, ax							; copy current cluster
	mov dx, ax							; copy current cluster
	shr dx, 1   						; divide by two
	add cx, dx							; sum for (3/2)
	mov	bx, 0							;location of fat in memory
	add	bx, cx
	mov	dx, WORD [es:bx]
	test ax, 1						    ; test for odd or even cluster
	jnz	.ODD_CLUSTER

.EVEN_CLUSTER:
	and dx, 0000111111111111b	        ; take low 12 bits
	jmp	.DONE

.ODD_CLUSTER:
	shr	dx, 4				            ; take high 12 bits

.DONE:
	mov	WORD [cluster], dx
	cmp	dx, 0x0ff0				        ; test for EOF
	jb .LOAD_IMAGE

.SUCCESS:
	pop	es
	pop	bx
	pop	ecx
	xor	ax, ax
	ret

%endif
    0
  • ?

    Kurz gesagt, das Problem tritt genau hier auf:

    .LOAD_IMAGE:
 ; load the cluster
 mov ax, WORD [cluster]
 pop es
 pop bx
;-------genau hier-----
; falls bx == 0xFE00 dann bleibt ReadSectors hängen
;-------genau hier-----
 call Convert_Cluster_to_LBA
 xor  cx, cx
 mov  cl, BYTE [SecPerClus]
 call ReadSectors
(...)

    Wenn ReadSectors im "int 0x13" stecken bleibt, dann mag es sein, daß der Puffer [ES:BX] ungültig ist. Aber das kann ja nicht sein. 0xFE00 + 0x0200 (BytesPerSec) wäre dann genau die "Kante", also eigentlich ok. 😕

    Zumindest sitze ich grade dran. 🙂

    0
  • E
    Mod

    aktueller Kernel: 52.560 Bytes

    0
  • C

    aktueller Kernel (mit Mac erstellt): 52.432 Byte

    0
  • ?

    Die Sache ist schwieriger als gedacht. Einen Hotfix hätte ich schon, aber den poste ich lieber nicht weil der die Denkweise von angehenden Programmierern bis in alle Ewigkeit versauen würde. 🙂

    Probiert jetzt mal, falls Zeit und Spaß vorhanden, soviele Userprogramme wie möglich zu schreiben und bindet sie alle gleichzeitig mit ein. Die Userprogramme sollten möglichst "fett" und "verschwenderisch" sein, z.B. ein Menü, welches nur etwas anzeigt und sonst "nichts" macht.

    // makefile:

tools/CreateFloppyImage2 PrettyOS FloppyImage.bin (...) $(KERNELDIR)/KERNEL.BIN 
$(USERTEST)/HELLO.ELF $(USERTEST)/PROG01.ELF $(USERTEST)/PROG02.ELF (usw.)

    Möglicherweise gibt es noch ein "Folgeproblem" in der fat12.c.

    0
  • M

    ich hab jetzt mal 5 Progs eingebunden, je 4-7 Kb... Alles funktioniert noch.
    Worin sollte denn das Folgeproblem bestehen?

    EDIT: Einen Schönheitsfehler hab ich gefunden: Bei fdir verrutscht bei Dateinamen kleiner 3 Zeichen die Ausgabe...

    0
  • F

    Falls ihr das Problem noch nicht gelöst habt, es macht mehr Sinn bei einem Pointer ES:BX, BX immer "0" zu lassen und 0x20 (512bytes bei einem Segment-Register um 8 bits nach rechts geshiftet) auf es zu addieren, so umgeht ihr das 64kb Problem.

    Nur mal so als Denkanstoß!

    0
Anmelden zum Antworten