Sourcecode Fortschritt
-
rev. 368:
ehci/usb: zwei Abfragen hintereinander: erst device, dann configuration.
Allerdings läuft das auf qemu. Mit real PC gibt es noch Probleme, die mir aber bezüglich der Ursache noch nicht klar sind. Da bitte ich um Mithilfe bei der Ursachenfindung, damit wir uns von EHCI lösen und zu USB2 übergehen können.PrettyOS [Version 0.0.0.368] Console 1: EHCI Ports -------------------------------------------------------------------------------- >>> >>> function: showPORTSC >>> >>> function: checkPortLineStatus >>> Status of USB Ports <<< port 1: 0000100Dh, line: 00h SE0,power on, enabled, EHCI owned >>> Press key to start USB-Test. <<< >>> >>> function: testTransfer Test transfer with device address: 0 Enabling Async Schedule >>> >>> function: showPacket virtAddrBuf0: C0218000h 12h 01h 00h 02h 00h 00h 00h 40h 00h 00h 00h 00h 00h 00h 01h 02h 03h 01h >>> >>>function: showDeviceDesriptor length: 18 descriptor type: 1 USB specification: 2.0 USB class: 0000h USB subclass: 0000h USB protocol 0000h max packet size: 64 vendor: 0000h product: 0000h release number: 0.0 manufacturer: 0001h product: 0002h serial number: 0003h number of config.: 1 >>> >>> function: testTransfer Test transfer with device address: 0 Enabling Async Schedule >>> >>> function: showPacket virtAddrBuf0: C0220000h 09h 02h 20h 00h 01h 01h 00h C0h 00h >>> >>>function: showConfigurationDesriptor length: 9 descriptor type: 2 total length: 32 number of interfaces: 1 ID of config: 0001h ID of config name 0000h Remote Wakeup: no Self-powered: yes max power (mA): 0 port 2: 00001004h, line: 00h SE0,power on, enabled, EHCI owned port 3: 00001004h, line: 00h SE0,power on, enabled, EHCI owned port 4: 00001004h, line: 00h SE0,power on, enabled, EHCI owned >>> Press key to close this console. <<< -------------------------------------------------------------------------------- Thursday, April 15, 2010, 00:37:36 22 s runtime. CPU: 3746 MHz \
-
Erhard Henkes schrieb:
rev. 368:
Erhard Henkes, ich prophezeihe: PrettyOS wird dein Lebenswerk.
-
ich prophezeihe: PrettyOS wird dein Lebenswerk.
Ja, es hat schon etwas Faszinierendes.
Die Spannung lässt nicht nach. Gerade das Thema EHCI/USB oder später der Ausbau des Netzwerk-Codes stellen gewisse Anforderungen. Für viele sind aber auch die Themen Memory Management, Programming/Scheduling, Interprocess Communication oder Application Programming Interface reizvoller. Von den User-Programmen, eigenen Compilern usw. mal gar nicht anzufangen. Das lässt sich aber nur im Team bewältigen.
-
Erhard Henkes schrieb:
ich prophezeihe: PrettyOS wird dein Lebenswerk.
Ja, es hat schon etwas Faszinierendes. Die Spannung lässt nicht nach. Gerade das Thema EHCI/USB oder später der Ausbau des Netzwerk-Codes stellen gewisse Anforderungen. Für viele sind aber auch die Themen Memory Management, Programming/Scheduling, Interprocess Communication oder Application Programming Interface reizvoller. Von den User-Programmen, eigenen Compilern usw. mal gar nicht anzufangen.
Das lässt sich aber nur im Team bewältigen.
Na, dann wünsche ich Dir und deinem Team weiterhin viel Spaß und Erfolg.
-
@Z: wie wäre es, wenn Du bei uns mal mithilfst und auch Freude am Experimentieren/Tüfteln hast? Bei EHCI/USB könnte ich z.Z. einen Mitdenker/Tester gut brauchen.
Rev. 369:
- ehci/usb2: Debug-Prints reduziert, damit man die USB-Ergebisse besser sieht
Testen mit qemu: http://download.tyndur.org/temp/qemu-ehci.tgz
Konsole M (kernel/shell):
Port Change ehci_handler: USB Interrupt ehci_handler: USB InterruptKonsole 0:
>>> >>> function: initEHCIHostController >>> >>> function: startHostController (reset HC) DeactivateLegacySupport: eecp = 0000h No valid eecp found. >>> >>> function: enablePorts >>> >>> function: resetPort 1 >>> >>> function: resetPort 2 >>> >>> function: resetPort 3 >>> >>> function: resetPort 4Konsole 1:
>>> Status of USB Ports <<< port 1: 0000100Dh, line: 00h SE0,power on, enabled, EHCI owned >>> Press key to start USB-Test. <<< USB2: GET_DESCRIPTOR device, dev: 0 endpoint: 0 12h 01h 00h 02h 00h 00h 00h 40h 00h 00h 00h 00h 00h 00h 01h 02h 03h 01h length: 18 descriptor type: 1 USB specification: 2.0 USB class: 0000h USB subclass: 0000h USB protocol 0000h max packet size: 64 vendor: 0000h product: 0000h release number: 0.0 manufacturer: 0001h product: 0002h serial number: 0003h number of config.: 1 USB2: GET_DESCRIPTOR config, dev: 0 endpoint: 0 09h 02h 20h 00h 01h 01h 00h C0h 00h length: 9 descriptor type: 2 total length: 32 number of interfaces: 1 ID of config: 0001h ID of config name 0000h Remote Wakeup: no Self-powered: yes max power (mA): 0 port 2: 00001004h, line: 00h SE0,power on, enabled, EHCI owned port 3: 00001004h, line: 00h SE0,power on, enabled, EHCI owned port 4: 00001004h, line: 00h SE0,power on, enabled, EHCI owned
-
Erhard Henkes schrieb:
@Z: wie wäre es, wenn Du bei uns mal mithilfst und auch Freude am Experimentieren/Tüfteln hast?
Danke, aber nein. Ich bin in meiner Freizeit schon voll ausgelastet.
Du schaffst das schon.
-
Revision 370:
- Ergebnisse Codereview video.c
- Nicht-Multithreaded screenshot-Funktionen entfernt
- CDI-Header von Doxygen-Formatierung und für PrettyOS nicht relevanten Inhalten befreit
- bochs.bxrc: PANIC-Meldungen werden ignoriert -> Fehler beim Start fällt weg.
-
Revision 371:
kdebug(...) eingeführt (verbesserte Übersichtlichkeit und zentrale Wartbarkeit).
/// Diagnosis-Output - activates prints to the screen about some details and memory use #define _DIAGNOSIS_ #ifdef _DIAGNOSIS_ #define kdebug(...) \ settextcolor(3,0); \ printf(__VA_ARGS__); \ settextcolor(15,0); #else #define kdebug(...) #endifVielen Dank an noob_lolo für diesen konstruktiven und konkreten Ratschlag.
-
Rev. 372:
erweiterte Abfrage via USB2.0: device, config, interface, endpoints
Test mit qemu:
USB2: GET_DESCRIPTOR device, dev: 0 endpoint: 0 12h 01h 00h 02h 00h 00h 00h 40h 00h 00h 00h 00h 00h 00h 01h 02h 03h 01h length: 18 descriptor type: 1 USB specification: 2.0 USB class: 0000h USB subclass: 0000h USB protocol 0000h max packet size: 64 vendor: 0000h product: 0000h release number: 0.0 manufacturer: 0001h product: 0002h serial number: 0003h number of config.: 1 USB2: GET_DESCRIPTOR config, dev: 0 endpoint: 0 09h 02h 20h 00h 01h 01h 00h C0h 00h 09h 04h 00h 00h 02h 08h 06h 50h 00h 07h 05h 81h 02h 40h 00h 00h 07h 05h 02h 02h 40h 00h 00h length: 9 descriptor type: 2 total length: 32 number of interfaces: 1 ID of config: 0001h ID of config name 0000h remote wakeup: no self-powered: yes max power (mA): 0 length: 9 descriptor type: 4 interface number: 0 alternate Setting: 0 number of endpoints: 2 interface class: 8 interface subclass: 6 interface protocol: 80 interface: 0000h length: 7 descriptor type: 5 endpoint in/out: in endpoint number: 1 attributes: 02h max packet size: 64 interval: 0 length: 7 descriptor type: 5 endpoint in/out: out endpoint number: 2 attributes: 02h max packet size: 64 interval: 0Erläuterung: descriptor type
1: device
2: configuration
3: string (oben noch nicht genutzt)
4: interface
5: endpointAbfrage ist noch nicht variabel eingerichtet, klappt zur Zeit nur mit einem Interface und zwei Endpoints.
Die Spezifikation ist hier am einfachsten erklärt: http://www.beyondlogic.org/usbnutshell/usb5.htm
-
Rev. 373:
port reset und USB-Transfer koordiniert
-
Rev. 374:
TEST für ehci/usb2: nur zwischenschritt, um Host System Error auf real Hardware zu überwinden (noch re-init notwendig)
in ehci.c:
zeile 16-18:/// TEST const uint8_t PORTRESET = 3; /// TEST: only one port is reset!!! PORTRESET+1 is the indicated port /// TEST
-
Unser SVN bei source forge ist an diesem Wochenende down.
-
Wohl dem, der ein git hat.
Dann müsst ihr jetzt wohl ein Wochenende lang an tyndur basteln und euch dort Ideen holen.
-
Rev. 375:
TEST für ehci/usb2: nur zwischenschritt, um Host System Error bei mancher real Hardware zu überwinden (extended bei qtd eingefügt);
nur ein port, z.B. 7 (angezeigt 8), kann leicht umgestellt werden.
Zeile 16-19: ehci.c
/// TEST //const uint8_t PORTRESET = 7; /// TEST: only one port is reset!!! PORTRESET+1 is the indicated port #define PORTRESET j /// TEST@taljeth: danke für das nette Angebot. Wir holen uns gerne Ideen, nicht nur von týndur. Aber am liebsten basteln wir an unserem OS weiter.
Das kann sich aber noch ändern. Vor uns ist nichts sicher.
-
Rev. 376:
nun auch mit SET_ADDRESS
-
Revision 377:
* Maustreiber Fehlerbehebung (ACK wird jetzt erwartet)
-
Revision 378:
* Fehler bei Maus ohne Mausrad behoben
(EDIT: verdammt, kein neues Image hochgeladen..-.-)
-
Rev. 379:
nun läuft das mit SET_ADDRESS zumindest in qemu EHCI
--> nur noch QTD_SETUP und QTD_IOzu qemu: ist aber Blödsinn, wenn das bei qemu mit nicht angeschlossenem Gerät klappt, daher Umbau auf reale Verhältnisse in rev. 380
-
Rev. 380:
- jetzt nur bei attached device (also 0x1005), klappte bei einem ersten real PC Test noch nicht
Tests mit real PC:
anschließend noch mit device 0 getestet, ob SET_ADDRESS überhaupt geklappt hat:
brachte auch nur Nullen, das Adresse setzen könnte also auch dort geklappt haben!
-
Rev. 381:
PCI Command Register, Bit 2 (Bus Master) zusätzlich gesetzt
// pci bus data uint32_t num = ODA.pciEHCInumber; uint8_t bus = pciDev_Array[num].bus; uint8_t dev = pciDev_Array[num].device; uint8_t func = pciDev_Array[num].func; uint8_t irq = pciDev_Array[num].irq; // prepare PCI command register // offset 0x04 // bit 9 (0x0200): Fast Back-to-Back Enable // not necessary // bit 2 (0x0004): Bus Master // cf. http://forum.osdev.org/viewtopic.php?f=1&t=20255&start=0 uint16_t pciCommandRegister = pci_config_read(bus, dev, func, 0x0204); printf("\nPCI Command Register before: %x", pciCommandRegister); pci_config_write_dword(bus, dev, func, 0x04, pciCommandRegister /*already set*/ | 1<<2 /* bus master */); // resets status register, sets command register printf("\nPCI Command Register plus bus master: %x", pci_config_read(bus, dev, func, 0x0204)); irq_install_handler(32 + irq, ehci_handler); /// irq_install_handler(32 + irq-1, ehci_handler); /// work-around for VirtualBox Bug!Tobiking und Cuervo haben schon vollständige Transfers (set_address, device 18 byte, config 9+9+7+7 byte) gesehen, allerdings erst beim zweiten Hochfahren. Bei mir blieb es stabil negativ auf einem Test-PC.
Ob und inweiweit die sogenannten PCI Capabilities List (angezeigt beo 0x34) eine Rolle spielen, ist mir unklar.
capabilities list: 0x50
eecp: 0x68 (das haben wir zum BIOS/OS-Umschalten verwendet)Weiß jemand mehr über diese "pci capabilities list" bei EHCI (unterhalb eecp)?