PrettyOS Fehler-/Testthread
-
Ohne mir den Source-Code jetzt angeguckt zu haben, werfe ich einfach mal UnrealMode ein (kann sein das ihr das schon nutzt).
Wie ladet ihr denn den Kernel, wird er erst komplett geladen und dann an eine andere Position verschoben/kopiert, wenn ja, dann kann man das immer gleich machen braucht so nur nen Buffer der so groß ist wie ein Cluster und kann (UnrealMode vorausgesetzt) Dateien beliebiger Größe laden.
-
+gjm+: Dein Treiber sieht Klasse aus!
-
Vielen Dank!
Nun gibt es aber ein Problem in der "time.c" mit dem Wochentag. Der Grund dafür ist, einfach gesagt, daß es zwei verschiedene "Arten" vom CMOS gibt:
1. Register 0x06 zählt von 1 bis 7,
2. Register 0x06 zählt von 0 bis 6.Per Software kann man nicht herausfinden, ob Register 0x06 von 1 bis 7 oder von 0 bis 6 zählt. Deshalb wäre es besser wenn der Wochentag anhand des Datums ausgerechnet wird. Dazu muß man nur von einem bekannten Datum bis heute die Anzahl vergangener Tage ausrechnen und dann einfach modulo 7.
Der 01.01.1900 ist immer eine gute Idee. Der ist zufälligerweise ein Montag.
-
1. Register 0x06 zählt von 1 bis 7,
2. Register 0x06 zählt von 0 bis 6.Wirklich bekloppt so was.
-
Theoretisch wär ja wohl sogar noch mehr Mist denkbar... Rückwärts zählen z.B.
-
Revision 210
Bochs kommt mit folgendem "Fliesskomma-Ausdruck" nicht zurecht und rechnet "falsch":
// time.c Revision 210 unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) { day += 6; //1.1.2000 was Saturday day += (year-2000)*365.25; // <- hier (...) }VB und VPC schlucken ihn aber und rechnen korrekt. Vielleicht könnte die Routine so umgeschrieben werden, daß man auf eine "365.25" verzichten kann?
-
Ohja, stimmt, da gabs ja ein Problem mit Bochs+Fließkommazahlen...
Ich werde ein Workaround erzeugen, kommt bald!EDIT: Ich hab mir mal Bochs runtergeladen und PrettyOS damit gestartet: Ich konnte keinen Fehler feststellen...
Bochs-Version: 2.4.2
PrettyOS: Rev. 210
-
Tatsächlich! Lag an der Version von Bochs:
unsigned int calculateWeekday(unsigned int year, unsigned int month, unsigned int day) { day += 6; //1.1.2000 was Saturday day += (year-2000)*365.25; printformat("\n day : %X",day); // <- debug :) (...) }Nun geben Bochs (2-4-2), VB und VPC die gleiche Zahl aus. Hatte noch eine alte Version von Bochs. Also keine Revision notwendig.
-
Revision 239
Bin grade über folgenden Workaround gestolpert:
// ehci.c Revision 239 void initEHCIHostController(uint32_t number) { initEHCIFlag = false; irq_install_handler(32 + pciDev_Array[number].irq, ehci_handler); irq_install_handler(32 + pciDev_Array[number].irq-1, ehci_handler); /// work-around for VirtualBox Bug! (...) }Offenbar scheint die Sun VirtualBox "gewisse" Problemchen mit dem USB-Support unter "gewissen" Host-Betriebssystemen zu haben.
Wenn man folgendes macht:
1. VM starten,
2. im Menü der VM (Geräte->USB-Geräte) ein "USB-Gerät" auswählen (möglichst das richtige ),
3. die VM "neu starten" (Maschine->Zurücksetzen)dann ist ein Workaround nicht notwendig.
-
Danke für den Hinweis!
-
Zwei Sachen, die immer wieder erfolgen, wenn man neu aufbaut:
-
del wird nicht gefunden, weil msys oder wie jetzt bei mir auf einem alternativen PC Win-AVR mit den entsprechden Pfaden auf der Platte hängen. Da muss man die entsprechenden Pfade eliminieren. Wir verwenden daher auch kein msys mehr.
-
Das makfile bleibt hier bei [initrd] hängen:
E:\PrettyOS\trunk\Source>del FloppyImage.bin E:\PrettyOS\trunk\Source\FloppyImage.bin konnte nicht gefunden werden E:\PrettyOS\trunk\Source>tools\mingw32-make OS=WINDOWS nasm -f bin stage1_bootloader/boot.asm -Istage1_bootloader/ -o stage1_bootloader /boot.bin nasm -f bin stage2_bootloader/boot2.asm -Istage2_bootloader/ -o stage2_bootloade r/BOOT2.BIN del *.o E:\PrettyOS\trunk\Source\*.o konnte nicht gefunden werden mingw32-make: *** [initrd] Error 1Dieser Fehler ist hässlich, weil man die Lösung nicht leicht findet, zumindest geht es mir immer so.
Es liegt an den beiden "delete *.o", die in den targets ckernel und initrd nichts finden, make-fehler produzieren und deshalb blockieren. Diese beiden kommen nun einfach weg! Könnte dann nur einen Linker Error geben.Diese beiden Punkte sind die typischen Probleme, denen man beim Einstieg in den Build-Prozess seitens Windows evtl. begegnen kann.
Vorschlag mastamind im IRC: mit den wildcards nur die source dateien auflisten (nicht zwei mal)
-
-
Ich kann mich an alte DOS Zeiten nur schwer erinnern, aber bestand nicht die Möglichkeit mittels Errorleveln die Rückgabewerte eben von "Del" abzufangen und darauf zu reagieren? Helft mir wenn ich falsch liege...
Nachtrag: Del liefert den Errorlevel 1 zurück, wenns nicht erfolgreich war. Alternativ kann man mittels "exist" vielleicht probieren, ob die entsprechende Datei existiert - mit etwas aufwand ist damit vielleicht auch eine Prüfung von mehreren Datein möglich.
-
Del liefert den Errorlevel 1 zurück
Ja, genau so wurde make ausgestoppt. Daher habe ich die beiden del *.o ab Rev. 245 erstmal gestrichen, damit sie auf diese Weise niemand beim Einstieg behindern.
Danke für deinen Hinweis. Vielleicht schafft das jemand.
-
Revision 252
VMWARE, VPC, VB und mein "realer" PC zeigen in der Statuszeile ca. 2400 MHz an. (In etwa auch korrekt). BOCHS allerdings nur 49 MHz
. Liegt aber daran, daß BOCHS bei rdtsc einen "eigenen" Zähler zurückgibt.Worauf soll eigentlich beim USB-Treiber geachtet werden? Zumindest auf dem "realen" PC reagiert er auf ein "PSTS_CONNECTED_CHANGE" und zeigt dabei äußerst wortreich viele bunte Zahlen an.
-
Revision 256
// pci.h revision 256 #define PCIARRAYSIZE 1024// pci.c revision 256 (...) pciDev_t pciDev_Array[50]; // <- nur 50 elemente ! (...) void pciScan() { // array of devices, PCIARRAYSIZE for first tests for(uint32_t i=0;i<PCIARRAYSIZE;++i) { pciDev_Array[i].number = i; } (...) }Diese for-Schleifen (auch in der ckernel.c) gehen ziemlich heftig über die "Arraygrenze" hinaus.
Dadurch zeigt z.B. VMWARE im "_DIAGNOSIS_"-Mode in der ckernel.c mehr Geräte an als "tatsächlich" vorhanden sind.
Allerdings könnte das nur durch einen unglaublichen Zufall ein Grund für einen (bei mir bislang nicht) vorhandenen "Host System Error" sein.
-
+gjm+ schrieb:
... Diese for-Schleifen (auch in der ckernel.c) gehen ziemlich heftig über die "Arraygrenze" hinaus.
Mit C++ hätte sowas nicht passieren können...
-
@+gjm+: Danke für den Hinweis! Dies war aber leider nicht die Fehlerursache.
Wir schaffen es einfach nicht, bei extended capabilities im EHCI dem BIOS die Herrschaft zu entreißen!
Siehe Rev. 258, da habe ich endlich mal richtig gecheckt, ob das überhaupt klappt. Vorher hatten wir da eine Fehlauswertung im Sinne von if(failed){print: alles ok}. Bei mir ergibt sich BIOS: 1 und OS: 0. Es macht auch keinen Sinn beides auf 1 zu zwingen, sonst hat man einen Gladiatorenkampf.
XanClic sieht momentan keinen logischen Fehler im Code. Vielleicht ist mit einer Funktion (pci read/write) was falsch, oder wir kapieren etwas noch nicht.
Wer mithelfen will: EHCI 1.0 spec, Kap. 5
Problem ist hier (EDIT: gelöst, war bei PCI):
void DeactivateLegacySupport(uint32_t num) { delay(2000000);settextcolor(9,0); printformat("\n>>> >>> function: DeactivateLegacySupport\n"); settextcolor(15,0); bool failed = false; // pci bus data uint8_t bus = pciDev_Array[num].bus; uint8_t dev = pciDev_Array[num].device; uint8_t func = pciDev_Array[num].func; eecp = BYTE2(pCapRegs->HCCPARAMS); printformat("\nDeactivateLegacySupport: eecp = %x\n",eecp); /* cf. EHCI 1.0 spec, 2.2.4 HCCPARAMS - Capability Parameters, Bit 15:8 (BYTE2) EHCI Extended Capabilities Pointer (EECP). Default = Implementation Dependent. This optional field indicates the existence of a capabilities list. A value of 00h indicates no extended capabilities are implemented. A non-zero value in this register indicates the offset in PCI configuration space of the first EHCI extended capability. The pointer value must be 40h or greater if implemented to maintain the consistency of the PCI header defined for this class of device. */ // cf. http://wiki.osdev.org/PCI#PCI_Device_Structure // eecp // RO - This field identifies the extended capability. // 01h identifies the capability as Legacy Support. uint32_t NextEHCIExtCapPtr = eecp + 1; // RO - 00h indicates end of the ext. cap. list. uint32_t BIOSownedSemaphore = eecp + 2; // R/W - only Bit 16 (Bit 23:17 Reserved, must be set to zero) uint32_t OSownedSemaphore = eecp + 3; // R/W - only Bit 24 (Bit 31:25 Reserved, must be set to zero) uint32_t USBLEGCTLSTS = eecp + 4; // USB Legacy Support Control/Status (DWORD, cf. EHCI 1.0 spec, 2.1.8) if (eecp >= 0x40) { int32_t eecp_id=0; while(eecp) { printformat("eecp = %x, ",eecp); eecp_id = pci_config_read( bus, dev, func, 0x0100/*length 1 byte*/ | (eecp + 0) ); printformat("eecp_id = %x\n",eecp_id); if(eecp_id == 1) break; eecp = pci_config_read( bus, dev, func, 0x0100 | NextEHCIExtCapPtr ); if(eecp == 0xFF) break; } // Legacy-Support-EC found? BIOS-Semaphore set? if( (eecp_id == 1) && ( pci_config_read( bus, dev, func, 0x0100 | BIOSownedSemaphore ) & 0x01) ) { printformat("set OS-Semaphore.\n"); pci_config_write_byte( bus, dev, func, OSownedSemaphore, 0x01 ); failed = true; int32_t timeout=200; // Wait for BIOS-Semaphore being not set while( ( pci_config_read( bus, dev, func, 0x0100 | BIOSownedSemaphore ) & 0x01 ) && ( timeout>0 ) ) { printformat("."); timeout--; delay(20000); } if( !( pci_config_read( bus, dev, func, 0x0100 | BIOSownedSemaphore ) & 0x01) ) // not set { printformat("BIOS-Semaphore being not set.\n"); timeout=200; while( !( pci_config_read( bus, dev, func, 0x0100 | OSownedSemaphore ) & 0x01) && (timeout>0) ) { printformat("."); timeout--; delay(20000); } } if( pci_config_read( bus, dev, func, 0x0100 | OSownedSemaphore ) & 0x01 ) { failed = false; printformat("OS-Semaphore being set.\n"); } if(failed==false) { /* USB SMI Enable R/W. 0=Default. When this bit is a one, and the SMI on USB Complete bit (above) in this register is a one, the host controller will issue an SMI immediately. */ pci_config_write_dword( bus, dev, func, USBLEGCTLSTS, 0x0 ); // USB SMI disabled printformat("BIOSownedSemaphore: %d OSownedSemaphore: %d\n", pci_config_read( bus, dev, func, 0x0100 | BIOSownedSemaphore ), pci_config_read( bus, dev, func, 0x0100 | OSownedSemaphore ) ); settextcolor(2,0); printformat("Legacy Support Deactivated.\n"); settextcolor(15,0); } else { settextcolor(4,0); printformat("Legacy Support Deactivated failed.\n"); printformat("BIOSownedSemaphore: %d OSownedSemaphore: %d\n", pci_config_read( bus, dev, func, 0x0100 | BIOSownedSemaphore ), pci_config_read( bus, dev, func, 0x0100 | OSownedSemaphore ) ); settextcolor(15,0); } } } else { printformat("No valid eecp found.\n"); } }Bei manchen PC gibt es dennoch Host System Error beim Einschalten der Async.List
-
Fehler war in der pci_write_byte-Fkt.
-
Also bei mir wird richtig BIOS owned 0 und OS owned 1 angezeigt, der Host System Error bleibt allerdings.
-
Revision 271
Solange KERNEL und USER den gleichen "Videobereich" (0xB8000) für Ausgaben nutzen, sollte KERNEL nach erfolgreicher Ausführung von "elf_exec" auf eigene Ausgaben verzichten. Sonst gerät die Ausgabe vom USER u.U. völlig durcheinander:
// file.c revision 271 int32_t flpydsk_load(const char* name, const char* ext) { (...) if( elf_exec( file, f.size ) ) // <- falls erfolgreich ... { } (...) // printf("\n\n"); // <- ... sollte auf ausgaben ab hier verzichtet werden flpydsk_control_motor(false); // <- hier drin dann auch sleepSeconds(3); return 0; }(Betrifft aber nicht die Statuszeilen).
Die Wirksamkeit des VirtualBox-Workaround kann ich nicht bestätigen. Bei mir hat VB ein Problem mit dem Host. Manchmal kann VB der gestarteten VM USB zur Verfügung stellen, manchmal aber auch nicht. Das hängt wahrscheinlich vom Wetter ab. Aber es liegt garantiert nicht am IRQ in der VM von VB. (Wäre ja erschreckend, wenn es so wäre).