Beiträge anzeigen

Diese Sektion erlaubt es dir alle Beiträge dieses Mitglieds zu sehen. Beachte, dass du nur solche Beiträge sehen kannst, zu denen du auch Zugriffsrechte hast.


Nachrichten - Svenska

Seiten: 1 [2] 3 4 ... 90
21
Lowlevel-Coding / Antw:Eigener Bootloader?!
« am: 08. June 2019, 23:12 »
Hallo,

der "klassische" Bootloader liegt im ersten Sektor des Bootlaufwerkes und wird von einem BIOS an die Adresse 0x7C00 geladen und dort ausgeführt (d.h. CS:IP zeigt auf die richtige Adresse, aber die genauen Werte sind nicht bekannt). Außerdem steht in DL das Bootlaufwerk (0x00 für Diskette, 0x80 für Festplatte). Dein Bootloader muss nun den Kernel auf dem Bootlaufwerk finden können, in den Speicher laden können und aufrufen können. Ich gehe mal von einer Diskette aus, da ist das alles einfacher.

Schritt 1: "Kernel finden". Entweder, du hast ein Dateisystem (z.B. FAT12) auf deiner Bootdiskette, dann muss dein Bootloader dieses Dateisystem soweit lesen können, um den Kernel zu finden. Oder du klebst den Kernel einfach hinten an den Bootsektor ran, dann weißt du, wo er anfängt. Du musst außerdem wissen, wie groß der Kernel ist.

Schritt 2: "Kernel laden". Das BIOS stellt dir den "int 13h" zur Verfügung, mit dem du Sektoren von den Laufwerken lesen kannst. Details gibt es z.B. bei RBIL. In Schritt 1 hast du rausgefunden, welche Sektoren du lesen musst, also musst du nur noch entscheiden, wo die Daten im Speicher hinsollen (unterhalb von 640 KB!) und die passende Anzahl der Sektoren lesen. Für Disketten musst du noch von LBA nach CHS umrechnen, oder du hast deine Sektoradressen direkt als CHS.

Schritt 3: "Kernel anspringen". In Schritt 2 hast du festgelegt, wo dein Kernel hingeladen wurde. Jetzt musst du noch wissen, wo der Einsprungpunkt ist (im Zweifelsfall das erste Byte, aber das hängt vom Kernel ab!), also machst du einfach einen FAR CALL an diese Adresse. Die genauen Werte für CS:IP legst du diesmal selbst fest.

Es gibt genug Bootloader, die du dir anschauen kannst. Vielleicht nicht gerade GRUB, aber der Bootcode von FreeDOS ist halbwegs gut kommentiert.

Hoffe, es nützt.

Gruß,
Svenska
22
Softwareentwicklung / Antw:GRUB4DOS funktioniert nicht
« am: 02. May 2019, 14:38 »
...die dann aber ziemlich sicher weder unter MS-DOS noch unter Windows was sinnvolles tut. Zumindest nicht, wenn in der .txt vorher das drinstand, was man in einer .txt so üblicherweise erwartet (nämlich halbwegs verständlichen Text).
23
Softwareentwicklung / Antw:GRUB4DOS funktioniert nicht
« am: 25. April 2019, 20:34 »
Man kann EXE-Dateien auch umbenennen. Das macht sie trotzdem nicht zu COM-Dateien.
24
Lowlevel-Coding / Antw:Manipulation TSC-Register - No-Go?
« am: 26. March 2019, 08:33 »
Du kannst ja mal das Verhalten anschauen, wenn du den Kernel mit "notsc" bootest.
Eventuell ist dieser Patch hilfreich: http://lkml.iu.edu/hypermail/linux/kernel/1806.2/04234.html

Offensichtlich benutzt der Linux-Scheduler den TSC. Das wiederum lässt vermuten, dass Timer-Interrupts zwar trotzdem feuern (zumindest, wenn es kein TICKLESS-System ist), aber der Scheduler nicht darauf reagiert.
25
Lowlevel-Coding / Antw:Manipulation TSC-Register - No-Go?
« am: 23. March 2019, 21:12 »
Ich wollte ja nicht direkt antworten, weil ich davon keine Ahnung habe. Aber dann sieht das Forum so tot aus. :-)

Zitat von: mh1962
Meine Frage: Ist eine Manipulation am TSC-MSR ein generelles No-Go und wenn ja, warum? Oder ist es nur Linux, was empfindlich darauf reagiert? Auch hier: Warum?
In erster Linie betrifft eine Manipulation am TSC nur Programme, die den TSC auch nutzen.

Mir ist aufgefallen, dass Linux den TSC systemabhängig als "unzuverlässig" deklariert (z.B. wenn er im idle stehen bleibt) und dann in bestimmten Situationen nicht nutzt bzw. neu synchronisiert. Daraus schließe ich einfach mal messerscharf, dass das von dir gesichtete Verhalten auch noch systemabhängig ist. :-)

Was das xen angeht, könnte ich mir durchaus vorstellen, dass du den TSC des Hosts manipulierst und dadurch die VM verwirrst. Dass dann die Uhrzeit stimmt, überrascht mich wiederum nicht - in virtualisierten Systemen ist es unhandlich, die Uhr anhand eines schnell tickenden Timers nachzustellen. Da kann man lieber den Host oder einen anderen Timer (RTC, HPET) fragen.

Dazu kommt noch, dass der TSC zwischen verschiedenen Prozessoren (oder Prozessor-Cores) nicht unbedingt synchronisiert sein muss. Auch das kann zu seltsamen Effekten führen, je nachdem, auf welchem Core der Thread nun gelandet ist. Das wäre ein sehr guter Grund, den TSC innerhalb von Xen nicht zu nutzen.

Zitat von: mh1962
Es scheint auch vom Alter des Linux-Kernels abzuhängen, wie ich kurz angetestet habe. Ältere Linux-Kernel haben WENIGER Probleme mit einer TSC-Manipulation... Also doch ein Problem nur in Linux, was vor nicht all zu langer Zeit erst "eingebaut" wurde?
Der Kernel läuft auch auf i486 (bis 3.7 auch auf i386), die keinen TSC haben (der kam mit dem Pentium). Würde mich nicht wundern, wenn die Abhängigkeiten diverser Subsysteme auf eine genaue Zeitquelle erst in neuerer Zeit gekommen sind bzw. der Kernel erst in neuerer Zeit den TSC als hinreichend zuverlässig dafür ansieht.

In jedem Fall ist WRMSR laut Wikipedia eine privilegierte Operation. Wenn du also an den Prozessor-Interna rumspielst, dann bist du selbst schuld, wenn danach etwas nicht mehr funktioniert. Ein Sicherheitsproblem ist es jedenfalls nicht, weil du vorher schon alle Rechte hattest.
26
Softwareentwicklung / Antw:Parallelport mit DMA hereinlesen
« am: 07. February 2019, 22:22 »
Ausser diese langsame Port IO.
Das Port I/O ist vermutlich nicht deine Bremse, sondern die daran angeschlossene Hardware (d.h. der Parallelport selbst).

Gibt es da andere Möglichkeiten?
Es gibt drei klassische PC-Schnittstellen: Parallelport (maximal 2.5 MB/s mit abgestimmter Hardware), serielle Schnittstelle (maximal 115.200 Bit/s entsprechend 11.52 KB/s) und Gameport (vier digitale Eingänge, so schnell wie der Parallelport; vier 8~10 Bit-Analogeingänge, sehr umständlich). Dazu kommen noch die Floppy-Schnittstelle (500 KBit/s für HD-fähige Controller) und die IDE-Schnittstelle (maximal 8~16 MB/s). Der ISA-Bus, über den sämtliche Geräte mit der CPU kommunizieren, schafft maximal 16 MB/s - für das gesamte System zusammen.

Die PC-Plattform ist trotz ihrer Erweiterungen bis vor ein paar Jahren ziemlich kompatibel zum PC/AT geblieben - also grob dem Stand von ungefähr 1985. Seitdem haben sich Betriebssysteme durchgesetzt, die Hardware halbwegs sinnvoll abstrahieren können und daher keine Kompatiblität auf unterster Ebene mehr brauchen.

Heißt konkret: Wenn du schnellere Schnittstellen benutzen möchtest (z.B. Ethernet, USB, Firewire oder SCSI), dann musst du dir die Treiber dafür selbst schreiben. Diese Treiber sind abhängig von der konkreten Hardware, die du in deinem PC stecken hast (Netzwerkchip, USB-Controller, etc.). Dafür bekommst du ordentliches Busmaster-DMA (wenn die Hardware das kann) und höheren Datendurchsatz.
27
Softwareentwicklung / Antw:Parallelport mit DMA hereinlesen
« am: 04. February 2019, 23:23 »
Wie kommt man denn mit Memoryzugriff statt Port-IO auf die Inputs
Ich habe keine Ahnung. :-D

Vielleicht sind die Register mit einem Offset gemappt, vielleicht sind die Register nur mit der passenden Zugriffsbreite (8/16/32 Bit) zugreifbar, vielleicht geht es auch überhaupt nicht. Keine Ahnung. Kurzes Googeln fördert auch keine "üblichen" MMIO-Zugriffsmuster für den Parallelport zutage.

Längliches Googeln findet Dokumentation zu den EPP/ECP-Modi. Das läuft alles darauf hinaus, dass der Parallelport das Handshaking selbst macht und damit deutlich schneller betrieben werden kann als mit dem klassischen "Daten schreiben, Strobe aktivieren, Warten, Strobe deaktivieren"-Zyklus. Es geht also nicht darum, einen Logikanalysator damit zu bauen. DMA-Zugriffe auf die klassischen Register sind scheinbar nicht vorgesehen, sondern man nutzt für DMA die ECP-Register (Offset 0x400), wo ein FIFO dahinter steht. Angeblich bekommt man dadurch starken Jitter (unregelmäßiges Timing). Nur ECP-Ports sind DMA-fähig. Ferner scheint ISA-DMA immer auf 4.77 MHz festgenagelt zu sein, weswegen man z.B. IDE nicht mit ISA-DMA benutzt, sondern entweder mit PIO-Zugriffen oder Busmaster-DMA.

Ich weiß ja nicht, was du genau vorhast... aber vermutlich kommst du weiter, wenn du einen Mikrocontroller mit dem Auslesen eines GPIO-Ports beauftragst und ihn dann über eine andere Schnittstelle rausschicken lässt. Ein Atmega32U4 kann USB Full-Speed und harte Echtzeit. Ein STM32 oder anderer ARM ist zwar nur eingeschränkt 5V-kompatibel, hat aber mehr RAM.

Viel mehr dürfte es dazu nicht zu sagen geben, glaube ich. :-)
28
Softwareentwicklung / Antw:Parallelport mit DMA hereinlesen
« am: 03. February 2019, 19:18 »
Beim 286 er mag das wohl schnell gewesen sein. Aber bei den heutigen Prozessoren hat man das Gefuehl, es haette jemand die Bremse reingehauen.
Port I/O hat keine Caches, keine Cache-Invalidierungsstrategien, kein Access Reordering, kein Coalescing etc, dafür ist es synchron. Logisch ist es aus heutiger Sicht langsam, aber dafür ist es eine Legacy-Schnittstelle und interessiert niemanden mehr.

Was ist, wenn ich im unrealmode 4GB physikalischen Speicher zur Verfuegung habe.  Wie geht das dann, ich meine, es waere ja dann keine Adressen mehr fuer das Mapping vorhanden??
Stichwort "Memory Hole". Eine 8 Bit ISA-Karte kann 1 MB adressieren (darum gibt es zwischen 640 KB und 1 MB ein Loch); eine 16 Bit ISA-Karte kann 16 MB adressieren (darum hat man bei alten BIOSen zwischen 15 MB und 16 MB ein Loch); eine PCI-Karte kann nur 4 GB adressieren, also macht man da das gleiche.

Wenn du 8 GB RAM hast, dann wirst du nur 3 GB oder 3.5 GB nutzen können, dann kommen die Speicherbereiche der PCI-Karten, und erst dann kommt der restliche Speicher. Das siehst du, wenn du ein 32 Bit-Windows auf einem System mit 4 GB RAM oder mehr installierst.
29
Softwareentwicklung / Antw:Parallelport mit DMA hereinlesen
« am: 02. February 2019, 00:59 »
Gegenfrage: Was ist MMIO eigentlich?

Antwort: Das ist am Speicherbus angeschlossene Hardware. Die Verhält sich ungefähr so wie RAM (aber mit anderem Timing), aber ist kein RAM.

Logischerweise können MMIO-Geräte nicht die gleichen Adressen benutzen wie der verbaute RAM, denn sonst würden bei einem Zugriff mehrere Chips gleichzeitig aktiv sein und sich gegenseitig stören. Der PCI-Hostcontroller mappt die Geräte also irgendwo in den Adressraum, wo kein RAM ist. Für die Software ist das aber dasselbe.

Port I/O ist eine Spezialität von x86 (und den Vorgängern und Kompatiblen) - die meisten Architekturen kennen sowas überhaupt nicht. Dort nutzt grundsätzlich sämtliche Hardware MMIO, erscheint also der Software gegenüber wie Speicher.
30
Softwareentwicklung / Antw:Parallelport mit DMA hereinlesen
« am: 31. January 2019, 19:52 »
Was hat es mit dieser Memory Address auf sich?
Mit ein bisschen Glück hast du dort die gleichen Register memory-mapped nochmal. :-)

Die Karte scheint ECP-fähig zu sein und wird von Linux direkt unterstützt. Ich habe dort mal kurz in den Code reingeschaut, und das parport_pc-Modul kann auch DMA, wenn der Port dazu fähig ist.

Das heißt, dass du sowohl MMIO als auch DMA mit diesem Port machen können solltest.
31
Softwareentwicklung / Antw:Parallelport mit DMA hereinlesen
« am: 31. January 2019, 09:30 »
Es ist nur so dass digital i/o-Karten oft genau diesen Baustein benutzen. Aber es scheint so dass dieses Problem eher nicht zu existieren, da diese Karten ein MMIO nicht unterstützen.
Das hängt schlicht davon ab, wie die Karten verdrahtet sind. Für MMIO muss der Karte ein Speicherbereich zugeordnet sein.

Bei ISA-Karten kann man das meist direkt sehen (oder anhand der Jumper erraten), bei PCI(e)-Karten kann man einfach nachschauen:
$ lspci -v
02:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 10)
        Subsystem: ASUSTeK Computer Inc. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller
        Flags: bus master, fast devsel, latency 0, IRQ 16
        I/O ports at d000 [size=256]
        Memory at ef404000 (64-bit, non-prefetchable) [size=4K]
        Memory at ef400000 (64-bit, non-prefetchable) [size=16K]

        Capabilities: <access denied>
        Kernel driver in use: r8169
        Kernel modules: r8169


Wobei das für MMIO nur notwendig ist, aber nicht hinreichend.
32
Softwareentwicklung / Antw:Parallelport mit DMA hereinlesen
« am: 02. January 2019, 22:38 »
Zumindest für ECP-fähige Parallelports sollte es gehen:
Zitat von: Wikipedia:en/Parallel_port
The Extended Capability Port (ECP) is essentially an entirely new port in the same physical housing that also adds direct memory access based on ISA and run-length encoding to compress the data, which is especially useful when transferring simple images like faxes or black-and-white scanned images. ECP offers performance up to 2.5 MByte/s in both directions.

In halbwegs modernen PCI-Chipsätzen könnten die Register auch ein MMIO-Mapping haben. Das sollte dann im Datenblatt der Southbridge stehen (vielleicht steht das auch in den ACPI-Tabellen, aber das weiß ich nicht). Aber dann sind die Ports vermutlich auch ECP.

Klassische Parallelports (SPP) haben kein MMIO-Mapping und damit für den DMA-Controller nicht ansprechbar.
33
OS-Design / Antw:OsDev - Installer
« am: 02. July 2018, 13:41 »
Wenn du ein Betriebssystem von CD startest, dann laufen in vielen Betriebssystemen folgende Schritte ab:
1. Das BIOS (oder UEFI) lädt den Bootloader (z.B. ISOLINUX) von der CD und startet ihn.
2. Der Bootloader lädt deinen Kernel und eventuell weitere Module und startet den Kernel.
3. Der Kernel aktiviert die geladenen Module, findet die CD, aktiviert den Dateisystemtreiber und mountet dann das CD-Dateisystem.
4. Der Kernel sucht auf dem gemounteten Dateisystem nach einem oder mehreren Programmen und startet diese (unter UNIX ist das "init").
5. Das Betriebssystem ist dann aus der Sicht des Kernels fertig gestartet.

Einige Betriebssysteme benutzen eine andere Struktur, wo die Schrittfolge stattdessen so aussieht:
1. Das BIOS (oder UEFI) lädt den Bootloader (z.B. ISOLINUX) von der CD und startet ihn.
2. Der Bootloader lädt den Kernel und ein Image, eventuell weitere Module und startet den Kernel.
3. Der Kernel aktiviert die geladenen Module und erzeugt sich eine leere Ramdisk.
4. Der Kernel nimmt das geladene Image und erzeugt sich in der Ramdisk ein Dateisystem.
5. Der Kernel sucht in der Ramdisk nach einem oder mehreren Programmen und startet diese (unter UNIX ist das "init").
6. Das Betriebssystem ist dann aus der Sicht des Kernels fertig gestartet.

Etwas in der Art muss dein OS bereits können, sonst ist ein Installer nur wenig sinnvoll.

Dein Installer muss also die Festplatte so vorbereiten, dass die Schritte 1 und 2 beim Systemstart ausgeführt werden. Dabei gibt es bedeutende Unterschiede zwischen Systemen mit MBR (also der klassischen Partitionstabelle) und EFI (moderne Systeme). Ich beschreibe hier nur den klassischen Weg.

Das heißt im Extremfall, dass du einen Installer schreiben musst, der folgende Dinge tun kann:
1. einen Master Boot Record (MBR) installieren
2. eine Partitionstabelle und eine Partition erzeugen
3. diese Partition aktivieren und darauf ein leeres Dateisystem erzeugen
4. einen Bootloader auf diese Partition installieren und passend konfigurieren
5. deine Programme auf diese Partition zu kopieren (vor allem "init").

Willst du ein vorhandenes Betriebssystem nicht kaputtmachen, artet das schnell in sehr viel Arbeit aus. Außerdem hat es fast nichts mit deinem Kernel zu tun, also wenn du bisher nur einen Kernel hast, hast du noch einen langen Weg vor dir. Was du natürlich auch machen kannst ist, einen fertigen Bootloader wie GRUB zu benutzen. Damit ersparst du dir einigen Aufwand, aber wenn du kein Linux oder so für die Installation benutzen möchtest, ist das alles andere als einfach.

Beschreibe einfach mal, was du bisher hast und wie dein Betriebssystem bisher funktioniert. Dann lässt sich leichter herauskriegen, was ein vernünftiger Weg für dich ist.
34
OS-Design / Antw:OsDev - Installer
« am: 14. June 2018, 18:07 »
Hi,

erkläre mal ausführlicher, was du bereits hast und was du möchtest.

Dein OS (in erster Linie also dein Kernel) wird von einem Bootloader geladen. Es hängt vom Bootloader ab, ob der deinen Kernel von einer CD, einer Diskette, einer Festplatte oder über das Netzwerk lädt. Die bekannten Bootloader (GRUB, Syslinux) können alles, also beschäftige dich am besten mit der Dokumentation deines verwendeten Bootloaders.

Nachdem dein Kernel gestartet ist, muss er natürlich auch irgendwie auf die Festplatte zugreifen können. Also brauchst du Treiber für die Festplatte, die Partitionstabellen und mindestens ein Dateisystem. Das gilt aber genauso, wenn du von CD startest.

Gruß,
Svenska
35
Lowlevel-Coding / Antw:Mehtzeilige ausgabe eines C Kernels
« am: 26. May 2018, 15:06 »
Prima. ;-)
36
Lowlevel-Coding / Antw:Mehtzeilige ausgabe eines C Kernels
« am: 25. May 2018, 17:10 »
Hi,

der Video-RAM im Textmodus besteht aus linear 80x25 Zeichen (jedes Zeichen belegt zwei Byte, also insgesamt 80*25*2 = 4000 Byte). Das heißt, die ersten 80 Zeichen entsprechen Zeile 0 (die erste Zeile), die zweiten 80 Zeichen entsprechen Zeile 1 (die zweite Zeile), und so weiter.

Aus den Zeichenkoordinaten (x,y) berechnest du die Zeichenadresse mit der Formel (y*80 + x).
Wenn dir nicht klar ist, wie man darauf kommt, dann male dir das mal auf (Kästchenpapier). :-)

Für das Tutorial brauchst du aber die Byteadressen. Da jedes Zeichen zwei Byte groß ist, ist die Byteadresse einfach die Zeichenadresse mal zwei. Das Attributbyte (0x07 für "Hellgrau auf Schwarz") kommt ein Byte dahinter (also Byteadresse plus eins).

In einem printf benutzt man üblicherweise das Zeichen '\n', um eine neue Zeile anzufangen. Dazu musst du natürlich erstmal wissen, wo du gerade bist - am einfachsten definierst du dir zwei Variablen cursor_x und cursor_y, die angeben, wo das nächste Zeichen auftauchen soll. Immer, wenn du ein Zeichen geschrieben hast, aktualisierst du diese Variablen. Wenn du am Bildschirmende angekommen bist, musst du scrollen. Dazu verschiebst du einfach alle Zeichen (außer der ersten Zeile) um eine Zeile nach oben und machst die letzte Zeile wieder leer (z.B. 80 Leerzeichen reinschreiben).

Hoffe, das hilft. :-)
37
Offtopic / Antw:Gitlab
« am: 14. February 2018, 23:10 »
Puh, gute Frage, ich sehe das zum ersten Mal.
Frag am besten mal im IRC nach oder schicke die Pull-Requests direkt dahin. :-)
38
Offtopic / Antw:Gitlab
« am: 11. February 2018, 18:20 »
Das mag jetzt ne blöde Frage sein, aber welches Gitlab meinst du?
39
Das Wiki / Re: PHP Warnungen
« am: 07. April 2017, 23:34 »
Danke :-D
40
Das Wiki / Re: PHP Warnungen
« am: 06. April 2017, 12:50 »
da auch die Logs (irc.tyndur.org) bei mir nicht aktualisiert wurden/bzw. nicht aktuell waren.
Der IRC-Bot verliert manchmal die Fährte, wenn das Netz ein bisschen Schluckauf hat. Das ist aber schon länger bekannt und hat nichts mit dem Wiki nichts zu tun.
Seiten: 1 [2] 3 4 ... 90

Einloggen