Fw: Suche Linux-Anschluss im Raum Bi-Sennestadt

[Jan 'RedBully' Seiffert]

Pfeiffer wrote:
> Hallölle,
> 
> ersteinmal Danke für das erste Lebenszeichen aus der Linuxwelt. Nicht
> bezogen auf die Mailingliste, sondern auch auf erfolglose Versuche in
> den Foren Linuxpate & LearningLinux bezogen. Freut mich echt. Um so
> besser, dass du mir gleich programmtechnisch auf die Sprünge hilfst.
> 
Tja, es ist ein weites Feld, von einfach "Linux nutzen" ueber
"einrichten und coole Sachen konfigurieren", "selber Programmieren" bis
"in den Tiefen des Kernels graben und die Hardware kicken".

Du hast dir sehr hohe Ziele gesteckt, das sag ich mal so frei raus.
Hilfe und Info auf diesem Niveau sind dann doch etwas rarer.
Die Menge der Leute die du ueber das Windows DriverDeveloperKit befragen
kannst ist auch etwas kleiner.
Der Linuxvorteil ist hier, wenn es deine Anforderung nicht erfuellt und
du es in die Ecke pfefferst, hast du wenigstens kein Geld im vergleich
zum DDK zum Fenster rausgeworfen.

[snip - Intro]
[snip - M68K emulieren]
>> Hmmm, aber muss fuer die Kompatibilitaet nicht die Geschwindigkeit
>> eingehalten werden?
> Hier kommt einem die Hardwarearchitektur des Amigas entgegen, das System
> arbeitet eigenständig. Das Refresh der RAM-Bausteine die Buslogik
Das hatt ich auch erwartet, ist ja kein Intel design ;)

> und die Grafik,
Ja, da war was beim Amiga...

> Sound und I/O wird dort komplett über die CustomChips
> abgewickelt. Die CPU hat am Bus auch "nur" die zweit höchste Priorität
> und kann durch einen der CustomChips auch gestoppt werden. Dieses Design
> war vor 22 Jahren revolutinoär. Prozessorkarten für den Amiga sind
> eigentlich eigenständige Computer, die nur beim Zugriff auf die unteren
> 16MB (wo das Mainboard und die CustomChips liegen) sich mit dem Bus des
> Amigas synchronisieren und Daten austauschen, bei allen Operationen
> oberhalb der 16MB laufen diese Prozessorkarten asynchron zum 7,14MHz
> Takt, meistens mit 50MHz (68060 Karten).
Hmmmm...

> Bei Anbindung eines x86-Systems mit schnellerem Prozessor und
> ausgereiftem 68k-Emulator (UAE, Basilisk) sollte diese keine grosse
> Herausforderung in Sachen Geschwindigkeit sein.
> 

Gewschwindigkeit ist relativ, es gibt auch noch Latenz ;)
Nur weil viel GHz drauf steht, heisst das noch lange ncht, das deine CPU
nicht mit etwas anderem beschaeftigt ist.

[snip - treiber fuer bridge schreiben]
> 
> Der Bekannte der den FPGA mit der PCI-Bridge anfertigt verwendet als
> Basis die freie PCI-Bridge der TU Chemnitz.
> Daten zur Programmierung sind vorhanden,
Davon bin ich ausgegangen ;)
Wie gesagt, das so eine Bridge nachher recht transparent sein kann, OK,
denoch muss sie erstmal aufgesetzt werden (wenngleich dass das BIOS
schon machen kann, PCI erlaubt sowas)

> wir müssen jedoch noch bustechnische Anpassungen vornehmen.
> 
Sicher. Hmmm, wo ist denn mein M68k Assembler Buch?
Der M68K hatte nur MMIO, oder? Naja, kein io-bridging notwendig.
Und einen gesegneten Interupt-Mechanissmuss, den muesstet ihr in eurem
FPGA emulieren und dann einen PCI-Interrupt erzeugen.

>>> Der Adressbereich wird 16MB betragen und sollte ab Adresse $00000000 bis
>>> $010000000 gemapped werden.
> Uhps ... eine Null zuviel, beim programmieren wieder tödlich.
> 
Oeh, rechne, rechne, koennt das dann passen?

>> Oehm, und da geht es los...
>> 1) Der Physikalische Speicher an und ueber $000000000 ist belegt, x86
>> ISA-DMA area und BIOS und foo.
>> 2) PCI-Rescourcen liegen eher so bei $FFFFF...
>> 3) Aber das ist ja nicht schlimm, dafuer gibt es ja Virtuelle
>> Speichermapings
>> 5) Also dein Treiber stellt ein devicefile zur Verfuegung, worauf ein
>> (Userspace-)Emulator mit mmap (wofuer du die unterstuzung Programmieren
>> musst) sich "den Amiga" in seinen virtuellen Adressraum einblenden kann
>> 6) Das kann der Emulator theoretisch auch an Addresse $00000..., da ist
>> nur ein Problem: dort ist normalerweise das Programm/der Emulatorcode
>> selbst (bzw. ein bischen oberhalb der Addresse)
>>
> Ok, das liesse sich sicherlich auch über Offsets innerhalb des Emulators
> erledigen.
Denke das musst du sowieso!
Gab doch beim M68K den Addressmodus "displacement" wo man negative
displacements angeben kann? Sehr beliebt in in der short version bei
bootloadern um mit 0 - x irgendwas da hinten im Addr.-Raum anzusprechen
(Der Atari hatte da glaub ich das ROM). Naja, langes Raesteln kurzer sinn:
Du willst ja nicht, das dein emulierter Gast bei 0 - x im Stack deines
Emulators rauskommt.
Also muss eh jeder Speicherzugriff gegen die Grenzen getestet werden
(addr&0x0fff...).

> Auf der anderen Seite wäre eine mmap-Lösung eine feine und wie ich finde
> saubere Lösung.
> 
Naja, in Grenzen, 1:1 passen tut das nicht..

>> Was noch weitere unlustigkeiten zu Tage fördert.
>> Harware-Unterhaltung/Interrupts und Multitasking sind sich ein wenig
>> Spinnefeind.
> In welchem Bezug ist das zu verstehen? An welches Stelle wird
> Multitasking verwendet?

Oehm, in dem Moment wenn der Kernel hochgefahren ist? Der Kernel selbst
besteht schon aus mehreren Tasks.

> In meiner Phantasie müsste nur der Emulator gestartet werden,
Solange ein OS-Unterbau da ist, der etwas mehr als ein loader ist (DOS,
selbstgeschriebner boot-foo), wird das OS auch ungefragt Rechenzeit
"stehlen" und wenn es nur zum verwalten der HW (Timerinterupt, etc.) ist.

> dieser
> würde den Bereich PCI-Bridge als normalen Arbeitsspeicher verwenden. Die
> Hardware übernimmt den Transfer und das Busprotokoll, könnte also als
> Arbeitsspeicher mit extrem langen Reaktionszeiten verstanden werden.
> 
Der Emulator benoetigt ja noch weiteres RAM, was er auch besser lokal
hat (sonst kauf dir besser fluessigen Stickstoff und ein Satz Quarze,
mom, mittlerweile gibts ja ColdFire, die machen, suchsuchsuch, 266MHz
hmmm, erinnert sich noch wer an einen (humoristischen)Artikel ueber den
naechsten Atari TT mit eingebauter Herdplatte, mitgeliefert wird das
Buch "Cooking with the TT"), er wuerde nur die Zugriffe in/auf den Amiga
ausgeloesst durch entsprechende M68K Befehle dorthin umleiten.

>> Den Emulator in den Kernel? Uhhh...
>> Hmmm...
>> Echte Treiber fuer die devices schreiben? Mom, ne, der Gast im Emulator
>> soll sie ja benutzen, Doppelemulation ist doof.
>> RT-Linux? Interruptweiterleitung in den Emulator mit RT-Tasks...
> Auf Heise stand letztens was zu einem RT-Patch mit 50ns Rekationszeit.
> Aber wozu RT? Da müsstest du mich mal aufklären, das Amiga-System wartet
> in der Regel auf die CPU.
> 

Der Kernel wartet aber nicht auf deinen Emulator.

Warum nun Echtzeit? So etwas wie z.B. den V-Blanc interrupt (OK, falls
der Amiga sowas hatte) einfach an einen nicht RT-Emulator weiter zu
geben ist sinnlos. Der Kernel koennte auf die Idee kommen, deinen
Emulator einfach mal 100ms an die Seite zu legen, um sich seiner meinung
wichtigeren Dingen zu widmen. Nur Echtzeit garantiert dir ein Interuppt
aehnliches Verhalten, und du willst ja nicht, das deine Soundausgabe
stockt. Oder du verzichtest auf ein Betriebsystem.

Ich hatte mir das so gedacht:
Deine Amiga-Bridge kann den M68K-Interupt-Zyklus emulieren und loest
darauf einen PCI-Interupt aus.
Dein Linuxtreiber hat diesen Interupt registriert.
Der Emulator hat zwei Tasks, einen normalen, der "stumpf" M68K Befehl um
Befehl verarbeitet.
Der Interupthandler deines Treibers sichert die informationen aus dem
M68K-IACK-Zyklus weg und "stoesst" den zweiten Emulator-Task an, einen
RT-Task (den x86-interupt verlassend).
Dieser stopt den ersten Task, emuliert mit RT-Prioritaet nun den
"dazugehoerigen" M68K Interrupt-vector, wenn er damit fertig ist wird
die normale emulation weitergefuehrt (Wie auf der echten CPU).

Nebenbei bist du mit x86 der neueren Generation eh aufgeschmissen, dank SMI.

@JBG: Hmmm, ist wirklich ne interessante Frage wie schnell man wohl
M68K-Befehle emulieren kann. Aber ich denke schon, das man mit den
modernen GHz-Boliden die 50-66 MHz der letzten 68060 topen kann.

> Gruß
> Andre
> 

Gruss
	Jan

-- 
<King O.B.> was heisst MOM???
<Papa_Schlumpf> moment
<King O.B.> ich hab zeit...