Zum Inhalt springen

rubycon

Mitglieder
  • Gesamte Inhalte

    13
  • Benutzer seit

  • Letzter Besuch

Alle Inhalte von rubycon

  1. Danke für den Link - sieht sehr interessant aus, obwohl er mir bei diesem speziellen Problem nicht weiterhilft. Anfangsadresse stimmt und nachdem ich die Destination MAC Adresse meiner Karte eingetragen habe, werden die Daten auch einwandfrei übertragen ( Wireshark zeigt auch keine Fehler an ) - ist aber nur eine Notlösung, um erstmal weitermachen zu können, denn nicht jeder hat ja meine Karte bei sich im Rechner.
  2. Hallo, ich habe einen kleinen Hardwaretreiber für den Realtek RTL8139 programmiert. Mein Problem besteht nun darin, daß der Chip die Destination MAC Adresse als Einzeladresse sendet, ich aber einen Broadcast brauche. Also er sendet momentan 00:FF:FF:FF:FF:FF, wobei der Chip das erste Byte automatisch einfügt. Kann mir da ein Hardwareguru sagen, welches Register benötigt wird, daß er die Adresse FF:FF:FF:FF:FF:FF sendet ?
  3. Die PXE Spezifikation scheint genau das Richtige dafür zu sein ...
  4. Ich möchte verstehen, wie man auf der untersten Ebene beim PC anfängt, zu programmieren - quasi den PC nicht mehr aus Sicht eines aufgesetzen OS wie DOS,Linux,Windows etc. sehen bzw. programmieren. Nach dem Einschalten initialisiert ja erstmal das BIOS die Hardware und lädt dann aus dem MBR den 512byte großen Bootloader an Adresse 0x7C00h und startet ihn. Ich möchte an dieser Stelle keines von den o.g. Systemen starten, sondern mit einem eigenen kleinen Kernel auf die Hardware zugreifen - die ganzen Komponentadressen des Mainboards sind ja im BIOS ab Adresse 0x0400h zu finden. Das "normale" Verfahren mit NASM o.ä. die Software zu programmieren, dann in ein Diskettenimage zu kopieren, bei vmWare das Image anzumelden und neu zu booten, erscheint mit ziemlich umständlich. Da aber im Phoenix BIOS des Guest PC aber auch über Netzwerk gebooten werden kann und dieses auch als ein virtueller Ethernetadapter im Manager des HostPCs erscheint, wäre es doch möglich, vom "Urschleim" beginnend, darüber zu programmieren . Mir schwebt da eine eigene IDE vor, mit der man über dieses Ethernet "booten", also auch debuggen kann. Nach dem Motto: 1. Mit der IDE einen neuen Befehl eingeben 2. In der IDE auf "Debug" klicken, was folgende Aktionen auslöst - Adapter wird verbunden, GuestPC wird rebootet und übers Netzwerk wird der Befehl oder das komplette Programm übertragen. Leider bin ich im Netzwerkbereich noch nicht mal ansatzweise fit und weiß nicht, welche Daten über TFTP gesendet werden - vielleicht kannst Du mir das weiterhelfen ? Welche Daten werden wie beim Booten über ein Netzwerk geschickt ? Vielen Dank im voraus
  5. Da ich mich momentan mit dem Aufbau von Mainboards beschäftige, dachte ich an die Möglichkeit, einen kleinen Kernel zu programmieren - ich meine damit nicht etwas Windows- oder Linuxmäßiges. Und weil z.B. vmWare Workstation einen PC bis auf BIOS Ebene simulieren kann, kam ich auf den Gedanken, daß es möglich sein müßte, mit einer Remotesoftware den virtuellen PC zu steuern, also auf dem realen PC mit Assembler oder C zu programmieren und auf dem virtuellen PC das Programm auszuführen bzw. Step by Step zu debuggen ? Gibt es da eine Remotesoftware, die möglichst bis auf Bootloader Ebene runterreicht ? Und wenn nicht, würdet Ihr Euch dafür interessieren ?
  6. Danke - ein wertvoller Tip. Ich habe von Anfang an in den Projekteigenschaften von Visual Studio angegeben, daß der Compiler C Code kompilieren soll.
  7. Herzlichen Dank für die Antwort, es ist eine Datentypumwandlung. Allerdings ist HwDeviceExtension ein Zeiger mit Typ PVOID. pDeviceExtension ist der Zeiger auf die Struktur "PDEVICE_EXTENSION". Zeiger nehmen doch bei x86 immer 4Bytes ein ? HwDeviceExtension und pDeviceExtension müßten demnach kompatibel sein ? Ist das der Grund, wieso der Compiler es anstandslos schluckt ? Nochmals herzlichen Dank - da hätte ich mich totsuchen können.
  8. Hallo, worin besteht der Unterschied zwischen beiden Zeilen? PDEVICE_EXTENSION pDeviceExtension = (PDEVICE_EXTENSION) (ConfigInfo->HwDeviceExtension); PDEVICE_EXTENSION pDeviceExtension = ConfigInfo->HwDeviceExtension; Der Compiler erzeugt in beiden Fällen den gleichen Code: MOV EDX,[EBD+ConfigInfo] MOV EAX,[EDX+04] MOV [EBD+pDeviceExtension],EDX Ich habe schon vergeblich in meinen Büchern gesucht, aber nichts gefunden. Vielen Dank im voraus
  9. Hat sich als ein typischer Anfängerfehler herausgestellt. StreamClassRegisterMinidriver( IN PVOID DriverObject, IN PVOID RegistryPath, IN PHW_INITIALIZATION_DATA &HwInitData ); Während die "normale" DriverEntry Routine so aussieht: NTSTATUS DriverEntry( IN PDRIVER_OBJECT DriverObject, IN PUNICODE_STRING RegistryPath ); ist die DriverEntry Routine für einen StreamClass Minitreiber anders definiert - so gilt es ab Win2000: ULONG DriverEntry( IN PVOID DriverObject, IN PVOID RegistryPath ); Natürlich stimmt IN PDRIVER_OBJECT und IN PUNICODE_STRING nicht mit IN PVOID überein, weshalb die Übergabe der beiden Zeiger fehlschlägt. Nun klappt alles bis zu diesem Punkt wunderbar - im Syser Debugger wird angezeigt, daß ein STATUS_SUCCESS zurückgegeben wird und damit der MiniTreiber erfolgreich registriert wurde.
  10. Im Mikroprozessorbereich bin ich grade dabei, ein Betriebssystem für einen Synthesizer vom älteren Zilog Z180 auf den neuen ZNEO umzuschreiben - mit dem alten Z80 habe ich vor ca. 8 Jahren meinen ersten privaten "Heimcomputer" gebaut und ein kleines OS programmiert - hat als Hobby angefangen. Nun habe ich für den Synthesizer neben MIDI auch eine USB Schnittstelle eingebaut und eine Firmware geschrieben, welche mit dem MS StreamMiniClass Treiber "usbaudio.sys" ab WinXP auch einwandfrei funktioniert ("MIDIoverUSB"). Leider unterstützt dieser Treiber MIDI nur unter WinME,WinXP und Vista - unter Win98,Win98SE und Win2000 wird MIDI nicht unterstützt. Und da ich sowieso einige MIDI Spezialfunktionen (z.B. Routing) einbauen möchte, beschäftige ich mich mit Treiberprogrammierung. Über den portcls.sys habe ich es mit einem MiniTreiber schon geschafft, eine PCI Experimentierplatine anzusprechen, allerdings unterstützen PortClass Audiotreiber nur interne Busse wie ISA oder PCI - mit USB funktioniert da nichts, weshalb ich nur über einen StreamMiniClass Treiber gehen kann und der sollte ab Win98 alle Systeme unterstützen. Mir ist schon bewußt, daß die StreamClass wesentlich schwieriger als die PortClass ist.
  11. Vielen dank für die Antwort, allerdings befürchte ich, daß es für mich als noch einige Zeit dauern wird, mir diese Methode anzueignen, da ich aus dem Mikroprozessorhardware/Assembler Bereich komme und mit Hochsprachen sowieso einige Verständnisprobleme habe. Ich werde es erstmal mit Visual Studio 2005 und der WDK 2008 ausprobieren und wenn es damit nicht klappt, dann muß ich eben in den sauren Apfel beißen und es mit einem normalen Editor probieren. Ist aber der Aufbau des Sourcecodes prinzipiell richtig ? Eine weitere Sache, welche ich noch nicht verstehe ist, daß die Struktur "HW_INITIALIZATION_DATA" in der strmini.h bereits mit einem Variablenbezeichner deklariert wurde,welcher auch "HW_INITIALIZATION_DATA" heißt. Wenn man dann auf ein Strukturelement zugreifen möchte, müßte es doch mit HW_INITIALIZATION_DATA.HwInitializationDataSize = sizeof(HW_INITIALIZATION_DATA); funktionieren oder mache ich da einen Denkfehler ?
  12. Ich benutze DDK 2600 und Windows2000SP4. In den Settings habe ich als Lib Path sowohl w2k als auch wxp versucht - die strmini.h habe ich eingebunden und in den Lib Ordnern von w2k/wxp ist auch die stream.lib vorhanden - müßte also eigentlich funktionieren. Wenn ich das 1394dcam Beispiel mit dem DDK "builde", wird der Treiber ohne Fehler erstellt. Hier mein vereinfachter Sourcecode: #include "strmini.h" #pragma code_seg("Init") extern "C" NTSTATUS DriverEntry(IN PDRIVER_OBJECT DriverObject,IN PUNICODE_STRING RegistryPath) { HW_INITIALIZATION_DATA HwInitData; // HwInitializationData Struktur leeren RtlZeroMemory(&HwInitData,sizeof(HW_INITIALIZATION_DATA)); // HwInitializationData Struktur initialisieren HwInitData.HwInitializationDataSize = sizeof(HW_INITIALIZATION_DATA); // Hier wird sonst die komplette Struktur initalisiert NTSTATUS ntStatus=0; ntStatus = StreamClassRegisterMinidriver(DriverObject,RegistryPath,&HwInitData); return ntStatus; } // DriverEntry
  13. Hallo, als ich anhand eines Beispiels in der DDK die Treiberprogrammierung erlernen wollte, trat bei mir ein Linkerfehler auf und ich weiß beim besten Willen nicht, wo der Fehler liegt. Das Beispiel ist der Sourcecode der Sony 1394DCam, welcher im DDK bei wdm/videocap zu finden ist. Dort wird in der DriverEntry Routine eine HW_INITIALIZATION_DATA Struktur initalisiert und danach mit "StreamClassRegisterMinidriver()" der MiniTreiber registriert - die strmini.h habe ich eingebunden. Der letzte Parameter von "StreamClassRegisterMinidriver()" ist ein Zeiger, welcher auf die HW_INITIALIZATION_DATA Struktur zeigt, die ich (wie im Beispiel ) "HwInitData" nannte. Der komplette Befehl lautet bei mir also: return StreamClassRegisterMinidriver(DriverObject,RegistryPath,&HwInitData); Leider gibt Visual C++ 6.0 einen Fehler heraus: DriverEntry.obj : error LNK2001: unresolved external symbol "long __stdcall StreamClassRegisterAdapter(void *,void *,struct _HW_INITIALIZATION_DATA *)" (?StreamClassRegisterAdapter@@YGJPAX0PAU_HW_INITIALIZATION_DATA@@@Z) Kann mir da freundlicherweise jemand weiterhelfen ?

Fachinformatiker.de, 2024 by SE Internet Services

fidelogo_small.png

Schicke uns eine Nachricht!

Fachinformatiker.de ist die größte IT-Community
rund um Ausbildung, Job, Weiterbildung für IT-Fachkräfte.

Fachinformatiker.de App

Download on the App Store
Get it on Google Play

Kontakt

Hier werben?
Oder sende eine E-Mail an

Social media u. feeds

Jobboard für Fachinformatiker und IT-Fachkräfte

×
×
  • Neu erstellen...